The Mode-S Beast can do this and they talk about it on their website(I had the ADSBmini on in transit and will order a Beast when they are back in stock). wiki.modesbeast.com/Mode-S_Beast:System_Assembly
It has the ability to combine up to 4 antenna sources and pick out overlapping packets.
You can use four directional antennas that each target 90 degrees or a virtual with some directionals for augmenting interesting traffic.
You can do the same thing with multiple RPIs and antennas feeding into a consolidation RPI. An RPI3 probably has the CPU to even handle a few dongles at once, it would just need an update in software to cater for this.
So is the “High performance VHDL ADS-B decoder” a Mode S Beast or radarcape on steroids? It is not a “one trick pony” and could be used for a huge amount of things from EME, D-STAR and satelite reception to wide band applications like DTV, UAT and ADS-B.
I may put up a few directional antennas. I have about 75 degrees blocked by apartment buildings but heywhatsthat.com suggests I have a clear view for the other 280 odd degrees. I’ll probably start with a vertical and get a 10 element Yagi pointed out to sea for Atlantic traffic.
Yes, I should update that to label it properly. It’s pulled from a quick and dirty spreadsheet where I dumped the raw data. The axes are number of aircraft on the x-axis, and messages per second on the y-axis.
The data was gathered using sbsmeter1 which saves it in CSV format. The numbers are not strictly counting the raw ads-b messages but those produced in the basestation format used by the SBS-1 receiver.
What is interesting is that the message rate rises in a linear fashion until around 80 aircraft are visible where it is around 1000/sec, but above that the increase slows. The practical limit for the rtl dongles seems to be around 1600 messages total per second. I’ve occasionally seen a peak of 250 aircraft simultaneously but the message rate never went above an absolute maximum of about 1650.
Here is the total message rate plotted against the number of aircraft:
The number of TCAS messages is very large compared to ADS-B messages containing positions - the effect of the increased traffic on those is very pronounced:
This was recorded over about 8 hours from the middle of the day to night when traffic falls off. I’d like to be able to automate gathering data like that - I think that the message rate per aircraft is a much better indicator of receiver performance the the overall rate since there are so many factors that affect it. I think there is probably sufficient data in the various json files to pull it out and collate somehow, but I’m not a programmer so it will take me a long time to get anything working, let alone useful.
I’d be quite interested to see what the limits of other receivers are - other SDRs like Airspy and SDRPlay have better ADCs with 12 bits, which gives better dynamic range so I am wondering whether they are similarly limited. It’s possible that if dump1090 is grabbing the first frame it sees and ignoring overlaps, then they may not show a significant advantage despite the higher quality hardware.
Unfortunately Flightawares MLAT processing doesn’t appear to support using multiple directional antennas (bi-quads at the same location) and dongles.
I tried running a number of instances of dump1090 mutability and combining the feed in different ways but couldnt get the MLAT server to accept the combined results.
It could still just be fed in as individual recievers but where is the fun in that? … “” **Hint Hint Obj ** “”
How do you resolve the overlapping packets in this case?
Also the license is being cleaned up a bit more to allow modification and distribution, sorry about that oversight!
I suggest you use an established OSI-approved license; trying to roll your own is tricky to get right and it will be a barrier to anyone who wants to use it without paying a lawyer to review the license.
Run a separate piaware per antenna and it’ll work.
The main obstacle to processing a combined feed is that there’s no existing protocol that lets you identify different receivers in the message stream, so something new would have to be invented (and then it wouldn’t work with all the existing software, unless you also wrote some conversion utilities). Possible, but not high on my list since there’s an existing solution.
Whoa very cool, definitely interesting seeing quantifiable evidence of collisions.
ADS-B is modulated via ASK. It is unlikely that two transmitters have the same exact timing meaning that a modulated bits from 2 transmitters will have slightly offset transition edges. Since the length of a modulated bit is a fixed number defined by the spec, transitions that occur within that period are evidence of constructive interference due to a collision. Unfortunately all of the SNR gets wiped away if two transmitters are #1 transmitting packets that are received with the same RSSI #2 have their symbol times line up #3 have their LOs and distances line up in such a way that the received signals deconstruct, the chances of all of these happening are very slim.
I am likely going to license this under a flavor of GPL. Please hang tight!
FWIW dump1090 can’t use that trick at 2.4MHz because it just doesn’t have enough samples to see edges within the pulses; it barely has enough samples to see the pulse itself. Having more samples helps a lot!
… “” **Hint Hint Obj ** “”