Question about the time value

[pgiacalo]

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]

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]

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]

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

[pgiacalo]

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

[mutability]

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]

Thank you. Those were very helpful answers.