$RC format sequencing etc.

This discussion was created from comments split from: RaceLogger bluetooth input format.

Comments

  • aol,

    Can I ask a couple of questions about the RC2 format strings and how to use them as I'm coding up the test rig for it as we speak (although no doubt will take a while as i've very little free time).

    Lets assume for a minute that I have different sample rates on different channels, so as an example I need to send frequent updates for analogue channel 2, while infrequent updates for analogue channel 1, can I send RC2 strings with no values in some fields some of the time or do I need to resend the previous value each time until it changes?

    $RC2,[time],[count],[xacc],[yacc],[zacc],[rpm/d1],[d2],[a1],[a2],[a3],[a4],[a5],[a6],[a7],[a8]*checksum

    For example something like this mocked up sequence:

    $RC2,194402.200,1,,,,12000,,,100,,,,,,*checksum
    $RC2,194402.400,2,,,,11000,,200,105,,,,,,*checksum
    $RC2,194402.600,3,,,,11500,,,120,,,,,,*checksum
    $RC2,194402.800,4,,,,12000,,,110,,,,,,*checksum
    $RC2,194403.000,5,,,,12000,,,140,,,,,,*checksum
    $RC2,194403.200,6,,,,11000,,220,140,,,,,,*checksum

    Obviously, the values that vary could be any one of the data points, not just the analogue channel data.

    I'm assuming non-sampled values can just be skipped rather than needing a 0 value.
    I'm also assuming that when you mean timestamp, you are talking time only (including .milliseconds) i.e. hhmmss.ss - i'm not sure subseconds are part of the spec, but my GPS unit sends them on the NMEA strings.

    Thanks in advance
  • Just one more question i've thought of while we're validating the spec ..

    acc fields are not used so far (RaceChrono v2.60 onwards: -1.000 = -1G, 1.000 = +1G)

    What are the max/min values for acc fields - the example indicates the scale, but not the max/min. i.e. I assume we can have -3.100 representing -3.1g

    Just working out how large the buffer needs to be to hold any possible combination of $RC2 formatted string.
  • edited June 2014
    Minimum and maximums are very high values. Somewhere around 100000 Gs :) I think the buffer you should use just depends on your hardware (G-sensor min/max).
  • Yeah - working with a range of +-9.999G for that.

    Whats the position with blank values from the previous post above ?
  • edited June 2014
    If you use empty (no number at all), RaceChrono will not draw graph for that position (or at least should not). If you use 0 then RaceChrono will display it as 0. Also the timestamp resolution in RaceChrono internals is milliseconds, so you should output millisecond timestamps to get best possible precision.
  • One more question about sequencing.

    Do the RC2 strings and GPS strings have to arrive in strict time sequence ?

    The reason I ask is that as I need to blend 2 data streams, I'm going to have to buffer the inbound GPS before streaming it out to avoid overlapping strings blending together in the output stream. If they have to be strict sequence on the stream its not an issue if it is a strict requirement as I can deal with it, I just need to know. Given both are timestamped to the millisecond, I wasn't sure if it made any difference to you?
  • edited June 2014
    There is no time sequence requirement at all. Sentences can come 100% independently from each other.
  • RaceChrono for Android supports now "RaceDAC with GPS" which is $RC2 sentences and NMEA sentences mixed.
  • How does it look RC2+NMEA
    $RC2......
    $NMEA....
    $RC2....
    ??
    How fast can i set the baud rate?
  • edited January 2016
    Use highest baudrate that works. The NMEA sentences start with $GP, and the order and interval between $RC2 and NMEA does not matter. When they are mixed, the $RC2 needs to have time stamps.
Sign In or Register to comment.