With the discussion about OGN data happening in another thread, now is a good time to say that I have been forwarding ADSB locations to the OGN.position and a lower refresh rate but larger ranged ADSB position.
It's running on my raspberry pi at home alongside the SPOT/Inreach to OGN scripts.
I have been running it since Feb and seems to be working well.
Why did I do this? I got bored last year and wanted to do a project in python to learn the language more and this sounded like fun.
How will you know if the position is from ADSB or FLARM? Some OGN websites will show the receiver detecting the aircraft (or source of the data), "ADSBExch" is visible in that field when the position is coming from ADSB data.
How does it work?
This script connects to an ADSB API (for ADSB positions) and the OGN (for FLARM positions). The script listens to both sources and manages a traffic list composed of each unique aircraft's position, speed, altitude, etc from both sources.
If a glider position exists from ADSB and not from FLARM, that glider's position is pushed to the OGN from the ADSB source.
If a glider position exists from both ADSB and FLARM, that glider's ADSB position will only be pushed to the OGN when the FLARM source is 120 seconds older than the ADSB source. Thereby seamlessly transitioning between the high refresh rate FLARM
To be seen, you will need to have a Mode S (non ADSB and be within MLAT range) or a Mode S (with ADSB) transponder. The script is set up to run on my pi from 9a to 8p MST, 7 days a week. And at the moment it is only set up to scan the North Americanlat/lon range.
The API is queried at 10 second intervals then the valid positions are sent to the OGN. For tracking, the signal has a refresh rate of somewhere between 5 and 15 seconds. A much lower resolution than the OGN's 1-2 second position intervals but ADSB hasa much larger range.
With the discussion about OGN data happening in another thread, now is a good time to say that I have been forwarding ADSB locations to the OGN.position and a lower refresh rate but larger ranged ADSB position.
It's running on my raspberry pi at home alongside the SPOT/Inreach to OGN scripts.
I have been running it since Feb and seems to be working well.
Why did I do this? I got bored last year and wanted to do a project in python to learn the language more and this sounded like fun.
How will you know if the position is from ADSB or FLARM? Some OGN websites will show the receiver detecting the aircraft (or source of the data), "ADSBExch" is visible in that field when the position is coming from ADSB data.
How does it work?
This script connects to an ADSB API (for ADSB positions) and the OGN (for FLARM positions). The script listens to both sources and manages a traffic list composed of each unique aircraft's position, speed, altitude, etc from both sources.
If a glider position exists from ADSB and not from FLARM, that glider's position is pushed to the OGN from the ADSB source.
If a glider position exists from both ADSB and FLARM, that glider's ADSB position will only be pushed to the OGN when the FLARM source is 120 seconds older than the ADSB source. Thereby seamlessly transitioning between the high refresh rate FLARM
To be seen, you will need to have a Mode S (non ADSB and be within MLAT range) or a Mode S (with ADSB) transponder. The script is set up to run on my pi from 9a to 8p MST, 7 days a week. And at the moment it is only set up to scan the North Americanlat/lon range.
The API is queried at 10 second intervals then the valid positions are sent to the OGN. For tracking, the signal has a refresh rate of somewhere between 5 and 15 seconds. A much lower resolution than the OGN's 1-2 second position intervals but ADSB hasa much larger range.
On Thursday, April 7, 2022 at 5:40:49 PM UTC-6, davis.c...@gmail.com wrote:position and a lower refresh rate but larger ranged ADSB position.
With the discussion about OGN data happening in another thread, now is a good time to say that I have been forwarding ADSB locations to the OGN.
It's running on my raspberry pi at home alongside the SPOT/Inreach to OGN scripts.
I have been running it since Feb and seems to be working well.
Why did I do this? I got bored last year and wanted to do a project in python to learn the language more and this sounded like fun.
How will you know if the position is from ADSB or FLARM? Some OGN websites will show the receiver detecting the aircraft (or source of the data), "ADSBExch" is visible in that field when the position is coming from ADSB data.
How does it work?
This script connects to an ADSB API (for ADSB positions) and the OGN (for FLARM positions). The script listens to both sources and manages a traffic list composed of each unique aircraft's position, speed, altitude, etc from both sources.
If a glider position exists from ADSB and not from FLARM, that glider's position is pushed to the OGN from the ADSB source.
If a glider position exists from both ADSB and FLARM, that glider's ADSB position will only be pushed to the OGN when the FLARM source is 120 seconds older than the ADSB source. Thereby seamlessly transitioning between the high refresh rate FLARM
lat/lon range.To be seen, you will need to have a Mode S (non ADSB and be within MLAT range) or a Mode S (with ADSB) transponder. The script is set up to run on my pi from 9a to 8p MST, 7 days a week. And at the moment it is only set up to scan the North American
has a much larger range.The API is queried at 10 second intervals then the valid positions are sent to the OGN. For tracking, the signal has a refresh rate of somewhere between 5 and 15 seconds. A much lower resolution than the OGN's 1-2 second position intervals but ADSB
Hi Davis, cool project. Do you know if the pushed ADSB targets create duplication with existing FLARM targets on OGN displays?
Charlie
On Friday, April 8, 2022 at 7:43:50 AM UTC-7, gilles...@gmail.com wrote:position and a lower refresh rate but larger ranged ADSB position.
On Thursday, April 7, 2022 at 5:40:49 PM UTC-6, davis.c...@gmail.com wrote:
With the discussion about OGN data happening in another thread, now is a good time to say that I have been forwarding ADSB locations to the OGN.
It's running on my raspberry pi at home alongside the SPOT/Inreach to OGN scripts.
I have been running it since Feb and seems to be working well.
Why did I do this? I got bored last year and wanted to do a project in python to learn the language more and this sounded like fun.
How will you know if the position is from ADSB or FLARM? Some OGN websites will show the receiver detecting the aircraft (or source of the data), "ADSBExch" is visible in that field when the position is coming from ADSB data.
How does it work?
This script connects to an ADSB API (for ADSB positions) and the OGN (for FLARM positions). The script listens to both sources and manages a traffic list composed of each unique aircraft's position, speed, altitude, etc from both sources.
If a glider position exists from ADSB and not from FLARM, that glider's position is pushed to the OGN from the ADSB source.
If a glider position exists from both ADSB and FLARM, that glider's ADSB position will only be pushed to the OGN when the FLARM source is 120 seconds older than the ADSB source. Thereby seamlessly transitioning between the high refresh rate FLARM
American lat/lon range.To be seen, you will need to have a Mode S (non ADSB and be within MLAT range) or a Mode S (with ADSB) transponder. The script is set up to run on my pi from 9a to 8p MST, 7 days a week. And at the moment it is only set up to scan the North
has a much larger range.The API is queried at 10 second intervals then the valid positions are sent to the OGN. For tracking, the signal has a refresh rate of somewhere between 5 and 15 seconds. A much lower resolution than the OGN's 1-2 second position intervals but ADSB
position and a lower refresh rate but larger ranged ADSB position.Hi Davis, cool project. Do you know if the pushed ADSB targets create duplication with existing FLARM targets on OGN displays?
CharlieQuoted from Davis's original message
If a glider position exists from ADSB and not from FLARM, that glider's position is pushed to the OGN from the ADSB source.
If a glider position exists from both ADSB and FLARM, that glider's ADSB position will only be pushed to the OGN when the FLARM source is 120 seconds older than the ADSB source. Thereby seamlessly transitioning between the high refresh rate FLARM
https://i.imgur.com/808hJkM.png
Last Saturday had about 50 ADSB gliders being forwarded to the OGN, which is cool.
This python script continues to run on my pi at home. If anyone knows of a more professional hosting, feel free to reach out.
All,undesirable.
If you have a Mode S (non ADSB) transponder in your glider you will show up on the OGN via my ADSB script. If you also equip your Mode S glider with an OGN Tracker, two targets will show up! One from Mode S and one from the OGN Tracker. This is
This issue does not occur with ADSB equipped and FLARM equipped gliders because the icao IDs are the same. In the case of Mode S + OGN Tracker the icao IDs are different (the OGN Tracker has its own id that is not linked in any way to the N number ofthe aircraft).
To prevent this issue I have created a "black list" of icao IDs and N numbers that suppresses those ADSB positions leaving only the OGN Tracker position.effect until the next day.
So,
If you equip your glider with an OGN Tracker and now see two positions on the OGN, add your glider to OGNTrackerBlackList.csv at https://github.com/DavisChappins/ADSBtoOGN to fix it. This list is updated once a day at 4am PST so changes will not take
snipanyone have any experience doing this?
I am unsure about how many API requests I can do in a 24hr period from my IP before flightradar24 starts denying my requests so I'd like to host this on the cloud. Maybe several instances that have different IPs that could run at the same time....Does
Dan,
Good idea. I do have a 2nd pi lying around and signed up for a vpn on that pi.
Now that 2nd one is also running the same ADSB forwarding script as the first one, from a separate IP. I have been making about 2000 API calls per 24h and have not yet been blocked. For reference the website will do the same every 5s if left open.
If you are looking on glidertracker.org or similar and see the signal source as ADSBfr24 or ADSBFR24 the source is flightradar24 ADSB.
David,Davis,
What do you mean by "speed improvement"?
On Thursday, January 26, 2023 at 6:27:37 PM UTC-5, davis.c...@gmail.com wrote:
Dan,
Good idea. I do have a 2nd pi lying around and signed up for a vpn on that pi.
Now that 2nd one is also running the same ADSB forwarding script as the first one, from a separate IP. I have been making about 2000 API calls per 24h and have not yet been blocked. For reference the website will do the same every 5s if left open.
If you are looking on glidertracker.org or similar and see the signal source as ADSBfr24 or ADSBFR24 the source is flightradar24 ADSB.
how does the speed improvement come about? Do the messages somehow take a more efficient route? Offhand one might expect a less efficient route since an extra hop is required to go from the VPN to your real IP address.
I'm not doubting that this result has been observed but am genuinely curious and hoping to learn more.
Thanks,
...david
I'm not up on VPN technology but the vendor, NordVPN, in my case says
that they bypass my ISP's servers altogether. I can't see how they
could do that, since my ISP connects the wire to my house, which
connects to a fiber in the service box in the neighborhood, which I
would assume, connects to their servers.
On Fri, 27 Jan 2023 13:04:05 -0700, Dan Marotta wrote:
I'm not up on VPN technology but the vendor, NordVPN, in my case says
that they bypass my ISP's servers altogether. I can't see how they
could do that, since my ISP connects the wire to my house, which
connects to a fiber in the service box in the neighborhood, which I
would assume, connects to their servers.
Interesting.
Does the path a packet takes to reach a target destination from your
laptop, differ depending on whether VPN is on or off?
It would be worthwhile to see if 'traceroute' shows ant differences: it is
a toool that shows the route a probe message sent by it takes across t'interwebs, so sending the probe to the same destination with VPN on and then off should clearly show whether the path the probe message takes
depends on the VPN setting, and *may* also show time-of-flight
differences (provided they don't just get lost in Internet traffic queues, and switching delays).
--In older Windows (not sure above XP pro....sigh....) you are looking at a "traceroot"?
Martin | martin at
Gregorie | gregorie dot org
In older Windows (not sure above XP pro....sigh....) you are looking at
a "traceroot"?
On Fri, 27 Jan 2023 19:09:38 -0800 (PST), Charlie M. (UH, Pi & 002 owner/pilot) wrote:
In older Windows (not sure above XP pro....sigh....) you are looking atI suggested 'traceroute' because I noticed that Dan, like myself, is using Linux.
a "traceroot"?
On Fri, 27 Jan 2023 13:04:05 -0700, Dan Marotta wrote:
I'm not up on VPN technology but the vendor, NordVPN, in my case saysInteresting.
that they bypass my ISP's servers altogether. I can't see how they
could do that, since my ISP connects the wire to my house, which
connects to a fiber in the service box in the neighborhood, which I
would assume, connects to their servers.
Does the path a packet takes to reach a target destination from your
laptop, differ depending on whether VPN is on or off?
It would be worthwhile to see if 'traceroute' shows ant differences: it is
a toool that shows the route a probe message sent by it takes across t'interwebs, so sending the probe to the same destination with VPN on and then off should clearly show whether the path the probe message takes depends on the VPN setting, and *may* also show time-of-flight
differences (provided they don't just get lost in Internet traffic queues, and switching delays).
That would be interesting to try, Martin, but it's above my software paygrade. Perhaps you could supply the complete command? I have it installed but am not having success with working it.
traceroute libelle-systems.com
Martin,
Well, it looks backwards to me. Here is the output from the trace route command with VPN disconnected. I recognize my IP address (blotted out):
traceroute to libelle-systems.com (3.33.152.147), 64 hops max
1 xxx.xx.xx.xx 1.283ms 0.903ms 1.207ms
2 67.42.200.51 26.118ms 26.358ms 25.863ms
3 67.42.136.97 26.088ms 25.866ms 25.687ms
4 99.82.183.2 33.994ms 32.938ms 33.157ms
5 52.93.74.36 34.406ms 33.729ms 33.717ms
And here it is with the VPN connected:
traceroute to libelle-systems.com (3.33.152.147), 64 hops max
1 10.5.0.1 32.298ms 32.149ms 32.618ms
2 83.136.182.3 32.116ms 32.825ms 32.225ms
3 62.115.186.14 32.947ms 32.936ms 33.037ms
4 213.248.75.245 32.402ms 32.706ms 32.261ms
5 209.120.154.162 50.908ms 51.963ms 51.644ms
6 150.222.206.215 52.287ms 52.505ms 52.384ms
Can you explain this?
Dan
5J
On 1/28/23 16:21, Martin Gregorie wrote:
traceroute libelle-systems.com
Martin,
Well, it looks backwards to me. Here is the output from the trace route command with VPN disconnected. I recognize my IP address (blotted out):
traceroute to libelle-systems.com (3.33.152.147), 64 hops max
1 xxx.xx.xx.xx 1.283ms 0.903ms 1.207ms 2 67.42.200.51
26.118ms 26.358ms 25.863ms 3 67.42.136.97 26.088ms 25.866ms
25.687ms 4 99.82.183.2 33.994ms 32.938ms 33.157ms 5
52.93.74.36 34.406ms 33.729ms 33.717ms
And here it is with the VPN connected:
traceroute to libelle-systems.com (3.33.152.147), 64 hops max
1 10.5.0.1 32.298ms 32.149ms 32.618ms 2 83.136.182.3 32.116ms
32.825ms 32.225ms 3 62.115.186.14 32.947ms 32.936ms 33.037ms 4
213.248.75.245 32.402ms 32.706ms 32.261ms 5 209.120.154.162
50.908ms 51.963ms 51.644ms 6 150.222.206.215 52.287ms 52.505ms
52.384ms
Can you explain this?
On Fri, 27 Jan 2023 13:04:05 -0700, Dan Marotta wrote:
I'm not up on VPN technology but the vendor, NordVPN, in my case says
that they bypass my ISP's servers altogether. I can't see how they
could do that, since my ISP connects the wire to my house, which
connects to a fiber in the service box in the neighborhood, which I
would assume, connects to their servers.
Interesting.
Does the path a packet takes to reach a target destination from your
laptop, differ depending on whether VPN is on or off?
It would be worthwhile to see if 'traceroute' shows ant differences: it is
a toool that shows the route a probe message sent by it takes across t'interwebs, so sending the probe to the same destination with VPN on and then off should clearly show whether the path the probe message takes depends on the VPN setting, and *may* also show time-of-flight
differences (provided they don't just get lost in Internet traffic queues, and switching delays).
--There have been instances (and apparently still are) where specific services were being throttled at edge routers and VPN tunnels were able to improve performance substantially. I haven't done much testing recently but my VPN service with a static IP
Martin | martin at
Gregorie | gregorie dot org
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 19:35:34 |
| Calls: | 6,646 |
| Calls today: | 1 |
| Files: | 12,190 |
| Messages: | 5,327,321 |
