Like many enthusiasts I use aircraft tracking sites as an aid for this hobby and a few years back I started 'feeding' a number of the sites with data via one of the cheap single board raspberry pi computers. The advantage of feeding these sites with data, is that you normally get free premium access to the data and historical data, as well as no ads on your screen.
The thing about feeding multiple sites is that it was quite a complex affair of downloading the basic program, such as the flightaware piaware program and then adding each extra feeder clients, such as Planefinder, FR24, Radarbox, flightaware, ADSB-Ex etc.
Normally the best part of a day but the time you had entered all your details for each client and checked it was all working correctly.
So what is the point of this post you may be thinking? Well, there is a new feeder image site that has been set-up, with the aim of making it pretty simple to feed multiple sites, without any need to delve into programming, all by downloading just their one image from the site. I've been using the image for a couple of months now and have found it to be very stable and everything on my raspberry pi is working well, with it feeding 15 different tracking sites at the same time without any problems [You can select what sites you choose to feed]
It is very easy to set up and I reckon, I had it all up and running in less than an hour.
If you are interested in doing this then head over to their site and have a look, there are details about how to set the whole thing up.
Note, I have no connection with this site other than being a user of their image.
https://adsb.im/home
Thank you for posting this message. I was unaware of ADSB.im.
I'vee just visited the site and am impressed, especially the layout and informative content.
As soon as my guests have departed, I'll download and test the RPi image.
If it does what it claims, it will be a very useful option for feeding data sharing sites.
I've now downloaded an SD card image and installed it in a spare RPi. The online instructions have a few areas that could be more precise but they're mostly clear and easy to follow.
Once I had the RPI running with an attached ADS-B SDR and antenna, it was very easy to add selected feeders.
I would recommend ADSB.im (https://my.adsb.im/home) for those wanting to setup an ADS-B receiver based on SBC (Single Board Computer) such as an RPi and, optionally, feed a wide range of data sharing services, such as FR24, FlightAware, PlaneFnder and ADS-B Exchange.
This is a really useful utility.
It definitely does do what it 'says on the tin' I waited until I had used it for a couple of months before posting, to check it was stable and everything worked okay and it does.
There are other advantages as well, in that you can view a whole range of graphs, covering everything from amount of aircraft tracked, CPU usage, CPU temperature, RAM usage etc etc.
It has an 'auto' gain control that take a few days to settle down after first install [but you can also manually change the gain] in you are in an area that gets swamped with lots of aircraft.
It has easy 'one' button back up controls
When you need to update to the latest Flightaware release etc, again that is all handled with a one button download.
Everything is controlled by a web interface, so after the first set up, the pi can be anywhere in range of your wi-fi. Mine is located in the loft next to the antenna.
For those that worry about having a pi or other SBC [single board computer] on 24/7. I plugged a power meter into the pi. Even with supplying all the sites [15 in all] it is drawing just over 4W. I worked out my electricity usage for a year is just less than £12, so much less than even buying one premium membership on any of the well known tracking sites, as a feeder I get premium access to all the data for free.
Quote from: Spotter with No Name on September 26, 2024, 02:05:13 PMIt definitely does do what it 'says on the tin'.
Agreed. Feature rich utility. Thanks again for bringing this to our attention. It deserves much wider recognition.
QuoteThe online instructions have a few areas that could be more precise but they're mostly clear and easy to follow.
Any area's that you found unclear, the dev (Dirk) is very open to suggestions to make things more easy to use. I've done a little bit of testing for ADSB.im eariler in the year and it should work with a wide range of SDRs, RLT-SDR, airspy, sdrplay rsp1a etc.
Maybe I've missed something?
I've used ADSB.im to setup two new feeds for FR24 and FlightAware.
When I view the feed status for each, the local IP address is not within my address range. Consequently I can't access the PiAware local map nor the one for FR24.
Has anyone else noticed this anomaly?
Quote from: Anmer on September 27, 2024, 10:18:19 AMMaybe I've missed something?
I've used ADSB.im to setup two new feeds for FR24 and FlightAware.
When I view the feed status for each, the local IP address is not within my address range. Consequently I can't access the PiAware local map nor the one for FR24.
Has anyone else noticed this anomaly?
I may be misunderstanding the problem, but can you not overlay a second IP address/network mask on the client computer's NIC so that it can see the other address range ?
Quote from: DaveReid on September 28, 2024, 08:32:21 AMI may be misunderstanding the problem, but can you not overlay a second IP address/network mask on the client computer's NIC so that it can see the other address range ?
What I'm trying to understand is what's assigning the odd IP address?
I can see what appears to be a virtual device (same MAC address as my RPi) with a local range IP address assigned by the router. But for the FlightAware and FR24 data feeds, my sharing has a different IP address - 172.18.0.5. Where does this come from?
Quote from: Anmer on September 28, 2024, 10:23:41 AMQuote from: DaveReid on September 28, 2024, 08:32:21 AMI may be misunderstanding the problem, but can you not overlay a second IP address/network mask on the client computer's NIC so that it can see the other address range ?
What I'm trying to understand is what's assigning the odd IP address?
I can see what appears to be a virtual device (same MAC address as my RPi) with a local range IP address assigned by the router. But for the FlightAware and FR24 data feeds, my sharing has a different IP address - 172.18.0.5. Where does this come from?
Maybe a router/hub setting? Most routers allocate Class C NAT addresses (192.168.xxx.xxx) to devices on a local network, but it seems yours is allocating Class B addresses (172.xxx.xxx.xxx) under certain circumstances.
Can the router be told not to allocate the latter, via a setting on its web interface, perhaps?
Thanks Dave.
It's not a router assigned IP address.
I can see the device attached to my local network with a 192.168.1.nnn address. I'm convinced the IP address 172.18.0.5 is assigned by ADSB.im. I was hoping those members who have used ADSB.im would respond to this message.
If I replace the SD card in the RPi with one just running PiAware, installed directly and not via ADSB-im, the same 192.168.1.nnn address is assigned and I can see it in my PiAware stats page. I can also access my local PiAware map
Somewhere during the ADSB.im process, a rogue IP address is assigned. This prevents the local maps being displayed.
When I replace the new PiAware SD card with the one created by ADSB.im, the IP address changes to 172.18.0.2. And a different MAC address.
Until I can understand what's going on I can't recommend using ADSB.im.
Hi Anmer
The ADSB.im image runs using a load of docker containers.
172.18.0.5 is an internal IP to the docker network that resides on the machine. IF you replace with the 192.168.1.n address of the pi you are using then it 'should work', hopefully. Why the image is pointing you to an internal IP address I have 0 idea.
I asked on discord - pointing at this thread.
Thanks Rik, but not sure how the suggested solution will work?
Do you have a link to the message thread?
I believe what you are experiencing is a result of trying to click on the FlightAware link BACK to your local feeder. And because the feeder image runs several different feeders in separate Docker containers, the FlightAware link points to that FlightAware Docker container, not to the actual feeder.
Simply use the local name or IP address to access your device. That's what Rick meant with http://192.168.1.x (you likely will have used this when setting up the adsb.im Feeder image).
In most home networks http://adsb-feeder.local should work. Additionally, a second name based on the site name that you set up initially will be offered. Something like http://dirksfeeder.local
The default map doesn't work for you? Available as "live map" on the webinterface?
Regardless, you can find the FA map if you click the FA status link on the main page on the local IP you already found.
You'll see that it leads to http://192.168.2.xxx:8082/
Quote from: wiedehopf on September 29, 2024, 10:40:18 PMThe default map doesn't work for you? Available as "live map" on the webinterface?
The ADSB.im map works.
Quote from: wiedehopf on September 29, 2024, 10:40:18 PMRegardless, you can find the FA map if you click the FA status link on the main page on the local IP you already found.
You'll see that it leads to http://192.168.2.xxx:8082/
This wasn't working for me. Nor was the FR24 local map.
I will now make some more tests following the post by dirkhh.
I have now run a further test.
I have an RPi connected to my router via Ethernet cable. It's running a PiAware feed, downloaded directly from FlightAware. The locally assigned IP address is 192.168.1.72. When I select the PiAware SkyAware link on my FlightAware
My ADS-B page I'm able to view the FA PiAware map.
The RPi also has a feed to FR24. On entering the 192.168.1.72 IP address into a browser I get to the FR24 Decoder Status page from where I can view the FR24 local map.
If I swap the SD card for one created by ADSB.im, with both FlightAware and FR24 feeds, the RPi still has a locally assigned IP address of 192.168.1.72. However, both FlightAware and FR24 status pages show an IP address of 178.18.0.5 and 172.18.0.2 respectively, as explained in the earlier messages.
If I now enter 192.168.1.72 into a browser, I get the ADSB.im Feeder Status page. Selecting
Map displays the ADSB.im map.
Selecting
FR24 Status displays the attached page.
On my FlightAware status page for the ADSB.im PiAware feed, the
PiAware SkyAware option now shows
View Live Data. Selecting this returns nothing as the link is to 178.18.0.5:8080
Quote from: wiedehopf on September 29, 2024, 10:40:18 PMRegardless, you can find the FA map if you click the FA status link on the main page on the local IP you already found.
You'll see that it leads to http://192.168.2.xxx:8082/
I don't have a FlightAware Status link on the ADSB.im Feeder page (see attached). However, I can confirm that entering 192.168.2.72:8082 does display my FA PiAware map.
So, in conclusion, creating feeds to FlightAware and FR24 via ADSB.im removes the normal options to view the FlightAware and FR24 local maps.
And it also removes FlightAware's local MLAT data on port 30105.
FR24 does not have a local map, only a status page.
port 31005 is available and has combined MLAT results from the aggregators that are active and provide MLAT results.
FA doesn't provide MLAT results for all planes you receive, it's somewhat random, quite a few planes are censored as well.
Much better to feed lol or live or fi or exchange to get better MLAT results.
Status page for FA is available via the link in the top table, see picture.
Thanks but FR24 does have a local map, see attached.
Sorry, I meant a Status link similar to that for FR24, see attached.
FlightAware local MLAT is available on port 30105. This doesn't appear to be available from ADSB.im PiAware.
The FR24 map, is that on the fr24 image?
Haven't seen that interface before.
31005 "doesn't appear to be available", how do you arrive at that conclusion?
For me the port is open and provides data.
Quote from: wiedehopf on September 30, 2024, 11:52:43 AMThe FR24 map, is that on the fr24 image?
Haven't seen that interface before.
Yes.
Quote from: wiedehopf on September 30, 2024, 11:52:43 AM31005 "doesn't appear to be available", how do you arrive at that conclusion?
For me the port is open and provides data.
I said 30105 not 31005.
FA returns all local MLAT. Its website may not show all MLAT but port 30105 does.
Well thus the port for MLAT results is different from FA. Yet they are available on 31005.
Didn't quite notice we were talking about 2 different ports with the digits jumbled a bit.
local FA mlat results are indeed censored.
Some military aircraft won't even be in the FA MLAT results, quite a few private aircraft only give MLAT results without the hex / callsign.
Quote from: wiedehopf on September 30, 2024, 06:01:39 PMlocal FA mlat results are indeed censored.
That's not my understanding nor experience.
I will run some further checks.
adsb.im has been updated so that FA links are easier to find on the local adsb.im status page.
Plus there have been optimizations so it runs well on a pi zero 2 with only 512 MB of memory. (though you shouldn't quite check all the aggregator boxes as it will run out of memory then, but you can still enable plenty)
In regards to FA mlat, the issue isn't even only the anonymous results, it's that in areas with many receivers in your area you sometimes just don't get MLAT results despite MLAT working well and the flight being available on the FA site for everyone.
Their system uses a handful of receivers to get a each position, if your receiver isn't used you don't get results for that flight. If it is used, you get positions for 3 minutes (sometimes well beyond receiver range).
For this flight for example, it took FA way longer than the other services to give me MLAT results.
Also i've attached an image of what an anonymized MLAT result from FA looks like, you get a hex starting with an ~ in the FA map you get a corresponding ModeS aircraft in the list that has the correct hex and callsign but no position.
Some aircraft being completely removed from MLAT results i'm pretty sure about but with the unreliability of getting MLAT results, can't be 100% sure. The factors described are more than sufficient for me that i can't recommend relying solely on FA MLAT results.
It's simple enough to feed airplanes.live, adsb.lol, adsb.fi or adsbexchange which usually give good MLAT results.
Would be very interest in trying this program (ADSB.im). One question I need to know is can it be used to feed BaseStation.
Thanks in advance.
Quote from: Oldfella on October 09, 2024, 09:49:36 PMWould be very interest in trying this program (ADSB.im). One question I need to know is can it be used to feed BaseStation.
ADSB.im is a utility that helps install selected data sharing feeds onto an SD card for use in some
Single Board Computers, such as a Raspberry Pi.
In itself it doesn't feed BaseStation.
But one can use ModeSMixer2.exe to access decoded data from the SBC and "feed" BaseStation.
It's the availabilty of decoded data and ModeSMixer2 that feeds BaseStation, not ADSB.im.
I would not recommend modesmixer on adsb.im.
Edit: misread that, i suppose you're talking about running it on the windows box running basestation. (still shouldn't be necessary unless SBS isn't the right format)
30003 is open on adsb.im and you can just pull SBS.
You can also push / tcp connect from adsb.im using the ultrafeeder arguments on the Expert page.
For example to push SBS to port / ip use this: adsb,192.168.2.81,23500,sbs_out;
Quote from: wiedehopf on October 10, 2024, 08:20:22 AMEdit: misread that, i suppose you're talking about running it on the windows box running basestation.
Yes, MMS2 running on Windows.
Quote from: wiedehopf on October 10, 2024, 08:20:22 AM(still shouldn't be necessary unless SBS isn't the right format)
30003 is open on adsb.im and you can just pull SBS.
So, data in BaseStation format is available on Port 30003 on the SBC?
Quote from: Anmer on October 10, 2024, 09:05:55 AMSo, data in BaseStation format is available on Port 30003 on the SBC?
Yeah that's pretty much for every SBC running dump1090-fa or readsb and adsb.im while running readsb in a container exposes the commonly used ports.
Thanks. So what IP address do I set in BaseStation for port 30003?
The RPi's actual address is 192.168.1.72 though ADSB.im has allocated it 178.18.0.5.
If I set BaseStation's network address to 192.168.1.72:30003 it doesn't connect.
Nor if I use 178.18.0.5:30003
Quote from: Anmer on October 10, 2024, 12:39:08 PMThe RPi's actual address is 192.168.1.72 though ADSB.im has allocated it 178.18.0.5.
This IP "allocation" is your misunderstanding.
ADSB.im allocates no addresses, the OS just uses DHCP like pretty much any other system to get an IP.
178.18.0.5 is the IP that the FA feeder sees in its container.
It's NOT the IP of the RPi.
I know it's not the RPi's IP address, But the IP address of 178.18.0.5 hasn't been assigned by my router.
As posted by Rikgale earlier, which I assume is correct?:
Quote from: rikgale on September 29, 2024, 03:37:49 PMThe ADSB.im image runs using a load of docker containers.
172.18.0.5 is an internal IP to the docker network that resides on the machine.
So the outstanding question is what IP address should BaseStation use to get the data that you say is made avilable by ADSB.im on port 30003?
The RPi only has one IP on your local network so you won't reach it using another IP.
Are you able to answer the question?
QuoteSo the outstanding question is what IP address should BaseStation use to get the data that you say is made avilable by ADSB.im on port 30003?
You said that ADSB.im makes suitable data available on port 30003:
Quote30003 is open on adsb.im and you can just pull SBS.
If I configure BaseStation for a network connection using the RPi IP address and port 30003, not data is available. But I can get it using ModeSMixer2, which you said wasn't needed.
That suggests suitably decoded data for use by BaseStation isn't available from ADSB.im on port 30003. I could be wrong but so far, I can't get at it!
Sample output of the port:
nc 192.168.2.80 30003
MSG,8,1,1,4D2412,1,2024/10/10,15:18:25.247,2024/10/10,15:18:25.306,,,,,,,,,,,,0
MSG,4,1,1,3C542B,1,2024/10/10,15:18:25.249,2024/10/10,15:18:25.306,,,408,204,,,0,,,,,0
MSG,5,1,1,3C66C3,1,2024/10/10,15:18:25.253,2024/10/10,15:18:25.306,,27875,,,,,864,,0,,0,
That's SBS / Basestation protocol.
Possibly the Basestation software can't TCP connect but needs the data pushed into a listen port?
I'm not familiar with it.
Also not familiar which format it needs exactly, you'd think it can use the data format with its name.
Thanks.
BaseStation expects decoded data in a usable format. It was designed to work with the Kinetic SBS/Puck receivers which output the decoded data. I suspect the data on Port 30003 from ADSB.im isn't in the required format. ModeSMixer2 converts and outputs the data in a suitable format which is why it is needed in this instance.
I guess the "push" option doesn't output suitable data either?
Which format are you specifying with modesmixer?
I guess it needs sbs10001 protocol as indicated here: https://www.rtl-sdr.com/tech-minds-using-basestation-software-with-any-adsb-hardware-xrange2-demonstration/
Baffling that software can't even use the format it originally introduced.
Might as well ingest beast from 30005 with ModesMixer then as it has more data than the SBS protocol.
Not sure how much of that carries over into sbs10001 when transcoding with ModesMixer but might as well (at least if it works).
The push option is the same dataformat as 30003, not sbs10001 protocol.
Thanks for the reply.
QuoteWhich format are you specifying with modesmixer?
Here is a typical ModeMixer2 config:
@echo off
CMD /c I:\MSM2\modesmixer2.exe --inConnect 192.168.1.136:30003 --inConnect 192.168.1.136:30105 --filter-nocountry --outServer sbs10001:10002
exitWhere the IP address is that of the RPi running Dump1090-fa.
Just one question. How do you know this statement is correct?
QuoteBaffling that software can't even use the format it originally introduced.
What software? BaseStation uses the decoded data from the SBS/Puck receivers. Nothing has changed in 20 years.
As it says in your link:
QuoteIn his latest video Tech Minds demonstrates how you can use the ModeSMixer software to translate ADS-B data coming from an RTL-SDR compatible program like dump1090 into the BaseStation data format.
Thanks Anmer and Wiedehopf for your inputs regarding my question of using ADSB.im to feed BaseStation. I'm somewhat confused as to whether ADSB.im can feed BaseSation or not. I have tried all the suggestions posted here and like Anmer had no luck in doing so.
Thanks again.
It may help if I post a summary?
- ADSB.im makes it easier to set up an SD card for use in an SBC (such as an RPi) with selected feeds to third parties. It does this well.
- ADSB.im has its own map and aircraft list as well as unique management features.
- However, ADSB.im creates a false "local" IP address, as explained earlier. This can cause some third party options to fail or require a different approach.
- Decoded data in BaseStation format isn't available via ADSB.im on port 30003
- As with any other RPi/SDR setup, ModeSMixer2.exe can be used access data from the RPi and make it available to BaseStation.
So,
Yes, one can use ADSB.im and acess the available data to run BaseStaion - but only via ModeSMixer2.
Actually there is some confusion in terminology.
Generally the output from port 30003 is called "Basestation" format, which created this confusion.
The correct name of port 30003 data format is "msg"
The correct name of format used by BaseStation software is "sbs"
These two formats ("msg" and "sbs") are different.
The decoders like dump1090 and readsb do NOT produce "sbs" format.
Sergesero has successfully incorporated conversion of data from dump1090 in beast/msg/raw formats to "sbs" format in "ModeSMixer2".
You can get a "sbs" data formatserver in "ModeSMixer2" by adding following parameter:
--outServer sbs10001:10001
Then set the Basestation software
Settings>>Hardware Settings>>Network as follows:
Address: IP of RPi
Port: 10001
Please see attched screenshots. Click screenshots to enlarge these to full size.
Additional info
The only decoder which is capable to provide listning port in sbs format is ModeSDeco2 by Sergsero. Please see attached screenshot of relevant part of output of command "modesdeco2 --help". Please click on attached screenshot to see latger size.
(1) To Download Windoows & Linux versions of ModeSMixer2, ModeSDeco2 & AcarSDeco2, visit page linked below:
https://github.com/abcd567a/mm2/releases/tag/v1
(2) Automated install scripts For installation of ModeSMixer2, ModeSDeco2 and AcarSDeco2 on
- Raspberry Pi OS (32-bit / 64-bit)
- Ubuntu amd64/x86_64
- Debian amd64/x86_64
Visit following sites:
- ModeSMixer2: https://github.com/abcd567a/mm2/blob/master/README.md
- ModeSDeco2: https://github.com/abcd567a/md2/blob/master/README.md
- AcarSDeco2: https://github.com/abcd567a/ad2/blob/master/README.md
These scripts install the systemd facility for status/start/stop/restart
Few days ago I have updated these sites, so now these scripts install the required dependency packages as well.
.
Quote from: abcd567 on October 30, 2024, 01:34:22 PM(1) To Download Windoows & Linux versions of ModeSMixer2, ModeSDeco2 & AcarSDeco2, visit page linked below:
ModeSMixer2 and ModeSDeco2 can also be downloaded from this forum's Software (https://radarspotting.com/forum/index.php?action=tportal;sa=download;dl=cat7) area, as can AcardSDeco2 for Windows.
Quote from: Anmer on October 30, 2024, 01:44:11 PMModeSMixer2 and ModeSDeco2 can also be downloaded from this forum's Software (https://radarspotting.com/forum/index.php?action=tportal;sa=download;dl=cat7) area, as can AcardSDeco2 for Windows.
Thank you Anmer for providing the link for downloads from Rdarspotting. You have a huge collection of software which are not easily available otherwise.
I am looking for Ubuntu / Debian versions of AcarSDeco2. Do you, or anyone else in this forum, has any idea from where it can be downloaded? Thank you.