Error in datastream

[Etienne]

Hi All

I've found another bug in the datastream of my D100, running firmware version 5.4...

Check out the timestamp and more specifically, the data frame id (in bold) in the following excerpt:

14040253+098+00033010000+0031+000+01+10990059FE018F
14040254+098+00033010000-0022-003+01+1099005AF90193
14040355+098+00033010000-0022-003+01+1099005AF90195
14040356+098+00033010000-0022-004+01+1099005AF90197
14040357+098+00033010000-0022-004+01+1099005AF90198
14040358+098+00033010000-0022-004+01+1099005AF90199
14040359+098+00033010000+0031+000+01+10990059FE0196
14040360+098+00033010000+0031+000+01+10990059FE018E
14040361+098+00033010000+0031+000+01+10990059FE018F
14040362+098+00033010000+0031+000+01+10990059FE0190
14040363+098+00033010000+0031+000+01+10990059FE0191
14040300+098+00023010000-0022-001+01+1099005AF90188
14040301+098+00023010000-0022-001+01+1099005AF90189
14040302+098+00023010000-0022-002+01+1099005AF9018B

In red is the change in time from 14:04:02 to 14:04:03, where the frame id doesn't go back 0.

In blue is the frame id rollover from 63 to 0, where the time doesn't increment.

My understanding from the docs is that it should look like this:

14040263+098+00033010000-0022-003+01+1099005AF90193
14040300+098+00033010000-0022-003+01+1099005AF90195

I have a sneaking suspicion it has to do with the time being updated by the GPS after the stream starts outputting (i.e. the 0-63 frame counter isn't reset to 0 when the internal clock is updated by the GPS).

This makes analysis of datastream recordings virtually impossible, as it leads to sentences being swapped when trying to arrange them in chronological order.

Could this be added to the bug-fix list for 5.5?

Thanks
Etienne

 

[dynonsupport]

This behavior is actually known, and isn't easily changeable because of the way different internal timers work within those units. The end result is that you're correct - the 1/64 frames don't always match with the seconds ticking. Sorry we're not able to fix this.

 

[Etienne]

Darn... That's a real problem. The workaround then is to keep track of the order that the messages arrive, then implement my own 1/64 counter and zero it whenever the seconds change.

Now that I think of it, couldn't the code that produces the stream do the same thing? It would only need a couple extra bytes of variable space, and a handful of lines of code. With each frame, you store the least significant seconds character (1 byte), and compare it to the following frame's. If it's different, then zero a 1/64th counter (1 byte), which is incremented with every sentence, and use that counter in the stream.

There's no hard and fast rule that requires a particular internal frame counter to appear on the data stream is there?

Just think, if you open-sourced the code, I'd fix it for you ;D

 

[dynonsupport]

Without getting into the innards of the EFIS, trust us when we say that it's not easily possible.

 

[Etienne]

Ok