Timestamp

[Tyoluyi]

Excuse me, could I ask how to export the timestamp info for each message through your flow chart? Thank you

[mhostetter]

Can you elaborate on exactly what you'd like?

If you just want the timestamps to print for each message, you can connect a Message Debug block to the ADS-B Decoder's decoded output. You should also set Print Level to None on the decoder. See below:

***********************************
* MESSAGE DEBUG PRINT PDU VERBOSE *
((vertical_rate . -128) (speed . 418.403) (datetime . 2019-07-23 02:10:38 UTC)
(latitude . 38.9556) (snr . 22.1123) (callsign . ENY3980 ) (icao . abb282)
(heading . -137.809) (longitude . -77.4204) (altitude . 36000) (timestamp . 1563847838)
(df . 17) (num_msgs . 12))
pdu_length = 112
contents = 
0000: 01 00 00 00 01 01 00 01 01 00 01 00 01 00 01 01 
0010: 01 00 01 01 00 00 01 00 01 00 00 00 00 00 01 00 
0020: 01 00 00 01 01 00 00 01 00 00 00 00 01 01 00 01 
0030: 00 00 01 01 00 01 01 01 01 00 01 00 00 00 01 01 
0040: 00 01 00 01 01 00 00 00 00 00 00 00 01 01 00 00 
0050: 00 01 00 00 01 00 00 00 01 00 01 00 01 01 01 00 
0060: 01 00 00 00 01 01 00 00 00 01 00 01 00 01 01 00 
***********************************

If you would like the timestamps/datetimes to display in Verbose printing mode, that's something that could be easily added.

[Tyoluyi]

Dear mhostetter Hi, I’m a graduate student and I’m working on ADSB and MLAT based on SDR. I’m trying to get the timestamp for each message and then send the TOA data & ICAO address to the server in order to realize MLAT by TDOA. Thank you

…

On Tue, 23 Jul 2019 at 03:18, Matt Hostetter ***@***.***> wrote: Can you elaborate on exactly what you'd like? If you just want the timestamps to print for each message, you can connect a Message Debug block to the ADS-B Decoder's decoded output. You should also set Print Level to None on the decoder. See below: [image: image] <https://user-images.githubusercontent.com/12112573/61677469-cc74f180-accd-11e9-810f-35aac4371e64.png> *********************************** * MESSAGE DEBUG PRINT PDU VERBOSE * ((vertical_rate . -128) (speed . 418.403) (datetime . 2019-07-23 02:10:38 UTC) (latitude . 38.9556) (snr . 22.1123) (callsign . ENY3980 ) (icao . abb282) (heading . -137.809) (longitude . -77.4204) (altitude . 36000) (timestamp . 1563847838) (df . 17) (num_msgs . 12)) pdu_length = 112 contents = 0000: 01 00 00 00 01 01 00 01 01 00 01 00 01 00 01 01 0010: 01 00 01 01 00 00 01 00 01 00 00 00 00 00 01 00 0020: 01 00 00 01 01 00 00 01 00 00 00 00 01 01 00 01 0030: 00 00 01 01 00 01 01 01 01 00 01 00 00 00 01 01 0040: 00 01 00 01 01 00 00 00 00 00 00 00 01 01 00 00 0050: 00 01 00 00 01 00 00 00 01 00 01 00 01 01 01 00 0060: 01 00 00 00 01 01 00 00 00 01 00 01 00 01 01 00 *********************************** If you would like the timestamps/datetimes to display in Verbose printing mode, that's something that could be easily added. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#22?email_source=notifications&email_token=AMV34EA7QRUUSL7ZZFN3H3TQAZS65A5CNFSM4IF5ZKY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2RWURI#issuecomment-514026053>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMV34EHI6774JVVNJSKDNATQAZS65ANCNFSM4IF5ZKYQ> .

[mhostetter]

For performing TDOA geolocation, you will need better time accuracy. Changes to gr-adsb are needed for that. You should probably timestamp the signal time of arrival in the ADS-B Framer. And the framer should probably determine fine time referenced to the USRP time tags (from the USRP's GPSDO) and not UNIX system time. You will need microsecond, or nanosecond, time accuracy to get good geolocation.

[Tyoluyi]

Thank you for your instruction, I'll carry out the change. Moreover, could I ask whether this ZMP PUB message sink can be used for message transmission like transmit from this computer to another computer? Sorry for too many problems. I'm a green hand. Thank you

[mhostetter]

Yes, you can PUB/SUB across machines. You should set the ZMQ PUB Message Sink block's Address field to tcp://*:5001. Let me know if that doesn't work.

[mhostetter]

I added this feature (with time referenced to the flowgraph's initial Unix timestamp) in #26. It's not nanosecond accurate, but is significantly better than before. Please check it out and let me know your thoughts.

[Tyoluyi]

Thank you. I have a question. Why don't we tag a timestamp in framer.py but in demod.py?

…

On Fri, 26 Jul 2019 at 00:32, Matt Hostetter ***@***.***> wrote: I added this feature (with time referenced to the flowgraph's initial Unix timestamp) in #26 <#26>. It's not nanosecond accurate, but is significantly better than before. Please check it out and let me know your thoughts. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#22?email_source=notifications&email_token=AMV34EDRYSTRDHX73F3G35DQBIZ2FA5CNFSM4IF5ZKY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD23CBJI#issuecomment-515252389>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMV34EBQS4J26CG7DCLJDDDQBIZ2FANCNFSM4IF5ZKYQ> .

[mhostetter]

You're right. That's probably a better place to put it. In either block, the way I have it implemented currently is the start time of the flowgraph is saved (from current UNIX timestamp) and then the burst time is determined by the SOB (start of burst) sample, at the given sample rate. Both blocks should produce the same answer. I guess I put it in demod.py because that is where the demodulated burst metadata is produced and the PDU is created. framer.py just adds a SOB tag to the sample stream.