search

flightaware / dump1090

Dump1090 is a simple Mode S decoder for RTLSDR devices
Other
917 stars 236 forks source link

Question about the time value #163

Closed pgiacalo closed 2 years ago

pgiacalo commented 2 years ago

I have 3 questions about the "Time" value reported by flightaware's dump1090. The sample output below was captured on Nov 7, 2021 at ~05:00AM UTC). 1) What is the epoch used for the reported time value? 2) Is the value generated locally by dump1090 or is the value decoded from the received ADS-B message? 3) Is the time value given in the local time zone or GMT?

Update: It seems that the reported Time is the running time of the dump1090 client and not a clock time, correct?

*8daa7b10990929abb0901cf0ac8a; CRC: 000000 RSSI: -16.7 dBFS Score: 27 (DF17_KNOWN) Time: 3015331.50us DF:17 AA:AA7B10 CA:5 ME:990929ABB0901C Extended Squitter Airborne velocity over ground, subsonic (19/1) (reliable) ICAO Address: AA7B10 (Mode S / ADS-B) Air/Ground: airborne Geom - baro: 675 ft Ground track 139.6 Groundspeed: 456.9 kt Baro rate: 2240 ft/min NACv: 1

mutability commented 2 years ago

Assuming you're using a rtlsdr dongle, the timestamp is time since start of capture (based on the number of samples from the dongle, not system time). ADS-B does not transmit a timestamp.

For data originally from a Mode S Beast, it's essentially the same but time since power-on.

For data originally from a Radarcape, the displayed timestamp is actually misinterpreted (the Radarcape does provide a time-since-UTC-midnight timestamp, but dump1090's debug output doesn't interpret it as that)

pgiacalo commented 2 years ago

Thank you very much for that helpful info. Yes, I am using flightaware's (blue) rtlsdr dongle. One other note/question, please. When I view flightaware's dump1090 output on port 30003 (sample below), there are date and time fields (for "date message generated" & "time message generated" ). These timestamps must be added by dump1090, correct?, since ADS-B does not transmit a timestamp, as you mentioned. These also appear to be in the local timezone -- values taken direct from the local system clock?

MSG,7,1,1,A8AD4E,1,2021/11/07,13:35:35.824,2021/11/07,13:35:35.846,,30225,,,,,,,,,, MSG,3,1,1,AA9B65,1,2021/11/07,13:35:35.934,2021/11/07,13:35:35.956,,21650,,,36.57809,-121.76445,,,0,,0,0 MSG,3,1,1,A8557A,1,2021/11/07,13:35:36.092,2021/11/07,13:35:36.119,,34000,,,36.34872,-121.31630,,,0,,0,0 MSG,8,1,1,ACC1E4,1,2021/11/07,13:35:36.205,2021/11/07,13:35:36.229,,,,,,,,,,,,0 MSG,7,1,1,AA9B65,1,2021/11/07,13:35:36.270,2021/11/07,13:35:36.284,,21650,,,,,,,,,,

mutability commented 2 years ago

Yes, those are from the local system clock and in the local timezone. (30003 output is super legacy)

pgiacalo commented 2 years ago

Is there a better port to receive the data from? And why is it better? Thank you.

mutability commented 2 years ago

Depends on what you're trying to do. 30003 output is OK if you need nothing beyond exactly what's in there, but there are some output quirks and there will never be any extension of that format to provide extra data because downstream apps that consume the format tend to be very fragile.

The canonical output is Beast-format data on 30005, which includes every received message, but you will need to have your own decoder & state tracking.

Alternatively you might also want to look at the json output (aircraft.json), which is nominally there to support SkyAware, but you can also poll it to get snapshots of currently tracked flights.

pgiacalo commented 2 years ago

Thank you. Those were very helpful answers.