Timestamp gets confused after a while

[ckuethe]

For some reason the timestamp gets filled with garbage after a while. Additionally, having timestamps based on uptime is not super handy - I'd rather have wall time so I know when a message was received, and if I need delta I can calculated it myself.

(-36 535.01113100) Type 5 (short surveillance ident reply) from 67e50e with ident 6208 (AIRBORNE ALERT)
(-30 535.64606225) Type 11 (all call reply) from a7f676 in reply to interrogator 0 with capability level 8
(-35 536.25195325) Type 4 (short surveillance altitude reply) from e8e32a at 37600ft (aircraft is on the ground)
(-35 536.32860550) No handler for message type 24 from d6b649
(-36 18446744073709551616.00000000) Type 4 (short surveillance altitude reply) from cb3e95 at 47825ft (aircraft is on the ground)
(-37 18446744073709551616.00000000) Type 5 (short surveillance ident reply) from c1546e with ident 5668 (AIRBORNE ALERT)
(-39 18446744073709551616.00000000) No handler for message type 24 from 2c720c
(-33 18446744073709551616.00000000) Type 0 (short A-A surveillance) from d6e7d8 at 38000ft (Vertical TCAS resolution only)
(-37 18446744073709551616.00000000) Type 5 (short surveillance ident reply) from c53bd2 with ident 2214 (SPI ALERT)
...
(-35 18446744073709551616.00000000) Type 0 (short A-A surveillance) from 8e6b98 at 900ft (speed 75-150kt)
(-35 18446744073709551616.00000000) Type 4 (short surveillance altitude reply) from 2cbc17 at 975ft (aircraft is on the ground)
(-37 18446744073709551616.00000000) Type 5 (short surveillance ident reply) from 151675 with ident 6324 (GROUND ALERT)
(-36 18446744073709551616.00000000) No handler for message type 24 from 8ac13a
(-29 18446744073709551616.00000000) Type 11 (all call reply) from a97e0a in reply to interrogator 0 with capability level 6
(-37 0.31159700) No handler for message type 24 from 34e131
(-36 0.52107475) No handler for message type 24 from 901439
(-29 0.86955675) Type 0 (short A-A surveillance) from 49a60a at 14400ft (speed 300-600kt)
(-33 1.04292925) No handler for message type 24 from b679fe

[bistromath]

Is this off latest master? We just recently fixed a bug here. Hope I didn't introduce another in the process.

--n

On Thu, Sep 24, 2015 at 11:51 AM ckuethe notifications@github.com wrote:

For some reason the timestamp gets filled with garbage after a while. Additionally, having timestamps based on uptime is not super handy - I'd rather have wall time so I know when a message was received, and if I need delta I can calculated it myself.

(-36 535.01113100) Type 5 (short surveillance ident reply) from 67e50e with ident 6208 (AIRBORNE ALERT) (-30 535.64606225) Type 11 (all call reply) from a7f676 in reply to interrogator 0 with capability level 8 (-35 536.25195325) Type 4 (short surveillance altitude reply) from e8e32a at 37600ft (aircraft is on the ground) (-35 536.32860550) No handler for message type 24 from d6b649 (-36 18446744073709551616.00000000) Type 4 (short surveillance altitude reply) from cb3e95 at 47825ft (aircraft is on the ground) (-37 18446744073709551616.00000000) Type 5 (short surveillance ident reply) from c1546e with ident 5668 (AIRBORNE ALERT) (-39 18446744073709551616.00000000) No handler for message type 24 from 2c720c (-33 18446744073709551616.00000000) Type 0 (short A-A surveillance) from d6e7d8 at 38000ft (Vertical TCAS resolution only) (-37 18446744073709551616.00000000) Type 5 (short surveillance ident reply) from c53bd2 with ident 2214 (SPI ALERT) ... (-35 18446744073709551616.00000000) Type 0 (short A-A surveillance) from 8e6b98 at 900ft (speed 75-150kt) (-35 18446744073709551616.00000000) Type 4 (short surveillance altitude reply) from 2cbc17 at 975ft (aircraft is on the ground) (-37 18446744073709551616.00000000) Type 5 (short surveillance ident reply) from 151675 with ident 6324 (GROUND ALERT) (-36 18446744073709551616.00000000) No handler for message type 24 from 8ac13a (-29 18446744073709551616.00000000) Type 11 (all call reply) from a97e0a in reply to interrogator 0 with capability level 6 (-37 0.31159700) No handler for message type 24 from 34e131 (-36 0.52107475) No handler for message type 24 from 901439 (-29 0.86955675) Type 0 (short A-A surveillance) from 49a60a at 14400ft (speed 300-600kt) (-33 1.04292925) No handler for message type 24 from b679fe

— Reply to this email directly or view it on GitHub https://github.com/bistromath/gr-air-modes/issues/76.

[ckuethe]

This is with the latest master.

I first noticed this a couple of days ago, then checked git an hour ago to see that you'd made some fixes to the timestamps and thought that maybe you'd fixed this bug... alas not.

I'm using 514414f6b3caed015176549a8ee75c456cd1567a

command line: "modes_rx -s osmocom -r 2.0e6 --location=30.205,-97.665"

[bistromath]

OK, I'll look into it. Seems I just can't get that right. ;)

You mentioned having UNIX time as a timestamp, I can do that. Right now it's using relative timestamps (start at zero) unless you have a GPSDO.

--n

On Thu, Sep 24, 2015 at 12:42 PM ckuethe notifications@github.com wrote:

This is with the latest master.

I first noticed this a couple of days ago, then checked git an hour ago to see that you'd made some fixes to the timestamps and thought that maybe you'd fixed this bug... alas not.

I'm using 514414f https://github.com/bistromath/gr-air-modes/commit/514414f6b3caed015176549a8ee75c456cd1567a

command line: "modes_rx -s osmocom -r 2.0e6 --location=30.205,-97.665"

— Reply to this email directly or view it on GitHub https://github.com/bistromath/gr-air-modes/issues/76#issuecomment-143029502 .

[jaroszna]

Not sure if this is related, but when using GPSDO for time stamps, after running for about 214 seconds the time stamps jump -428 seconds. After this jump, the time stamps are "shaky" (i.e. time stamps are out of order despite latitude and longitude being in order). I checked to see if perhaps the sql output was being corrupted, but the time stamps are "jumping" (after 214 seconds) upon exiting preamble_impl.cc.... Any help would be appreciated!

(I also included a graph showing decoded packet count vs time offset from first packet arrival:)