IQTLabs
Why not use piaware's JSON interface, to eliminate all the hassles of decoding the messages yourself?
It has a list of all the aircraft it's seen in the last 60 seconds, including time time last seen, co-ordinates, altitude, bearing & speed. This would render the adsb-mqtt step unnecessary, and simplify the tracker code.
Completely agree that it would simplify the system dramatically by switching to JSON.
We did an analysis of whether to use the SBS-1 messages and decode ourselves or use the JSON interface. The only technical reason we chose to use SBS-1 was timing. A key thing to know is that position (lat/long) and altitude come in as two separate ADS-B broadcasts at different times with different fix times.
- ADS-B Position (lat/long) broadcasts include the GPS time when the position was cut/broadcast. This is included in both the SBS-1 output and the JSON interface
- ADS-B altitude broadcasts also include the GPS time when the altitude was broadcast (altitude reports are separate from position reports in the ADS-B standard). This is included in the SBS-1 output but NOT in the JSON interface. JSON maintains the lat/long position as the source of time and adds on the altitude based on the most recent altitude report.
When does this matter? Really only when climb or descent rates are high - takeoff and landing and the camera close to the aircraft. We extrapolate the 3D trajectory based on the position and altitude times. If the altitude gets stale (missed reception, SDR processing gets overwhelmed, etc), the camera can quickly lose track of the aircraft. We ran into this in the field during testing.
Ultimately preserving this corner case may not be worth the added complexity of maintaining message decoding, but we decided to keep on SBS-1 and not switch to JSON at the time. We had field tested on SBS-1 for >20 hours and are confident in its performance, making the switch would have added technical and schedule risk to the project.
Going to leave this open to re-evaluate this decision
Appreciate the reply - I must admit I'd not considered those issues!
I wrote some stuff a while ago, which I'm still using to log planes into a PostGIS DB, and plot paths, do 3d animations, and feed the data into GoogleEarth for a plane's eye view movie.
My home's near an airport - I can see aircraft landing down in the valley, which is what inspired my interest in the 1st place. The slew calculations would be relevant given my closeness.
On Mon, 24 Jan 2022 at 07:50, mchadwick-iqt @.***> wrote:
Completely agree that it would simplify the system dramatically by switching to JSON.
We did an analysis of whether to use the SBS-1 messages and decode ourselves or use the JSON interface. The only technical reason we chose to use SBS-1 was timing. A key thing to know is that position (lat/long) and altitude come in as two separate ADS-B broadcasts at different times with different fix times.
- ADS-B Position (lat/long) broadcasts include the unix time when the position was cut/broadcast. This is included in both the SBS-1 output and the JSON interface
- ADS-B altitude broadcasts also include the unix time when the altitude was broadcast (altitude reports are separate from position reports in the ADS-B standard). This is included in the SBS-1 output but NOT in the JSON interface. JSON maintains the lat/long position as the source of time and adds on the altitude based on the most recent altitude report.
When does this matter? Really only when climb or descent rates are high - takeoff and landing and the camera close to the aircraft. We extrapolate the 3D trajectory based on the position and altitude times. If the altitude gets stale (missed reception, SDR processing gets overwhelmed, etc), the camera can quickly lose track of the aircraft. We ran into this in the field during testing.
Ultimately preserving this corner case may not be worth the added complexity of maintaining message decoding, but we decided to keep on SBS-1 and not switch to JSON at the time. We had field tested on SBS-1 for >20 hours and are confident in its performance, making the switch would have added technical and schedule risk to the project.
Going to leave this open to re-evaluate this decision
— Reply to this email directly, view it on GitHub https://github.com/IQTLabs/SkyScan/issues/21#issuecomment-1019564415, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADHTQ3CJDC224K2RNYCR7KTUXRSYNANCNFSM5MS4TOQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>
--
"I and the public know what all schoolchildren learn Those to whom evil is done Do evil in return" W.H. Auden, "September 1, 1939"