The stats look nice Too bad dump1090-fa and the graphs aren't working for you. Anything in particular you are having problems with? dump1090-fa installation should be straight forward, i've documented it here: https://github.com/wiedehopf/adsb-wiki/wiki/Installing-dump1090-fa After that the main change needed would be adding --net-only to the configuration file so it doesn't look for an rlt-sdr compatible receiver. You can just use this configuration as /etc/default/dump1090-fa if you want: Code: ENABLED=yes RECEIVER_OPTIONS="--net-only" DECODER_OPTIONS="--max-range 360 --lat 50.8658 --lon 7.1427" NET_OPTIONS="--net --net-heartbeat 60 --net-ri-port 29999 --net-ro-port 0 --net-sbs-port 0 --net-bi-port 0 --net-bo-port 0" JSON_OPTIONS="--json-location-accuracy 2" to apply the configuration: sudo systemctl restart dump1090-fa I've disabled all ports but the AVR input port which now is 29999 Use socat or nc to push AVR data into that port. If you are for example offering AVR data on localhost:30002 then you could use socat like this to transfer the data into dump1090-fa: socat -d -u TCP:localhost:30002 TCP:localhost:29999 The web interface at http://pi/dump1090-fa should now be showing aircraft. (uses lighttpd) The graphs are a simple install script and don't need any further configuration if dump1090-fa is displaying aircraft: https://github.com/wiedehopf/graphs1090#graphs1090 They use collectd/rrdtool to collect statistics and show them via lighttpd at http://pi/graphs1090/ You can then also feed flightaware if you would wish to do so by changing --net-bo-port 0 to --net-bo-port 30005 and installing piaware. After enabling the beast output port you should also be able to feed adsb-exchange If that's all a little bit much for you, i would test the product but not at the moment All the best for further development!
Wait .. all this to advertise a GNS FPGA device that can't send data to ADSBx but is for feeding FR24. Fr24 is more asinine in breaking feeders than FlightAware. Ok then .... Technically I think ADSBx can receive RAW/AVR on the same port as beast ... I have not tested it yet -- and by doing that you are going to use a ton of data ... so it's not really sane
It's not like you can't add AVR to beast translation to the software for the device. You can even use dump1090 to do it for you, AVR in, beast out. Also it's microprocessor not FPGA based as far as i understood.
Dan and I got 2 of these for $258 shipped direct from GNS. They must be on the sales wagon. That's $134 each. A single one is more than a complete dual SDR Pi setup with coax and antenna. Support documentation is pretty non-existent and very German, so we'll see if we can get it running. I don't see a hobbyist market for these until the price is closer to $20-30 USD, unless performance is somehow astronomical, which I doubt. And this this @Bill2002 guy seriously post about feeding FR24 and nothing else?
James, Dan, you will get tomorrow assist to feed into adsbexchange We will test our setup tomorrow for adsbexchange and will guide you. For my knowledge there is no need for dump1090 or other additional software. Just add a few simple terminal commands and it will work...especially for the new Raspi 4 the setup should be as easy as making a coffee nearly plug´n´play My colleague Stefan will guide you to make it happen ... By the way my feeder is now running on a Pi Zero is now solar powered ...totally autharc with WIFI. Works pretty good.... Just a hint because of performance.... It is a little bit I will say difficult to test performance... If you don't have a ADS-B generator source ....nearly not possible for "hobbyists" What we do here is to test with generators and we are able to simulate high maximum frame rates according to the specs and best sensitivity. It is complex to compare different receivers without having the correct equipment. The best way for for persons not having such equipment is to use a antenna splitter and compare different receivers. But it is not only the range...most interesting is the framerate and the update rate of all visible receivers to get a smooth and nice chain of the flight without any gaps. Our receiver is optimised for eating as much frames as possible ....so especial for high traffic areas near airports there will be a significant difference to SDR based receivers regarding framerate and range. One important point is that we need no CPU load from the Raspi. All the predecoding is done in the Module on the HAT. So the AVR data is CRC checked valided, corrected .... and is directly provided to /dev/ttyAMA0 serial port...so very simple.......hopefully not so much tecky .... regards Bill2002
Another pic about the feeder for those who are interested....the feeder is draining only 1W so I used a 10W solar panel for powering. Cost are below 100.00 USD without antenna
Or $100 hat .... So what you are saying is a $5 Zero W, IP6 case, $10 solar controller from china, $20 panel, and a few wires costs less than $100 ... Realistically the setup is closer to $250-300 ....
In total you are right...but I just have a Hat here ...so... including the solar panel mount ... Set solar + battery + power regulator approx. 80 USD panel holder apron 45 USD IP6 case 45 USD Antenna WLAN and ADS-B = 90 USD so yes you are right the setup indeed is roughly 300 bucks regards Bill2002
We checked the performance of socat on the RASPI. You will loose roughly 30% of data because of missing bits and bytes. We strongly recommend not to use socat on a RASPI based feeder. regards Bill2002
Could you specify on which data stream you used socat? If you used it on the resulting messages in AVR or beast format and it created a problem, then you might think about giving your TCP output some buffering directly in the program to avoid making quite as many system calls. As in make every TCP packet 1000 bytes and flush every 20 ms or something in case 1000 bytes was not collected by that time. Shoving around say 10 000 TCP packets per second will use quite a bit of CPU of the RPi from the system calls alone.
Rinetd Score:3/10 Limitation on number of connections. Socat Score:6/10 High ram consumption more connection=more RAM. Redir Score:8/10 Same as above but less consumption of RAM for about 20%. Haproxy Score:10/10 Is an http, https, and TCP load balancer but can be used to forward Tcp traffic only light usage of CPU and RAM. Iptables Score:10/10 Perfect usage is 0 CPU 12 MB RAM including the OS !. Iptables seems to be the best solution.
Here's what I got from their support. I suppose they want us to write the software to route whatever they are outputting in raw frames to dump1090 or to make it useful. Code: Hi James, our ADS-B HAT is a completely self-contained receiver that provides avr compatible Mode-S/ADS-B via a serial port at 3 Mbps, 8N1, no handshake. Provided you have followed our Raspberry Pi set-up instructions, the serial port is readily available on the Pi through /dev/ttyAMA0. If you want to feed this data over the network you may use socat. Quoting from you website’s feeding instructions, Send Beast, avr, or avrmlat to “feed.adsbexchange.com” port 30005 you would end up with a command-line like this: $ socat -d -d -u GOPEN:/dev/ttyAMA0,b3000000,crtscts=0,raw TCP4:feed.adsbexchange.com:30005 If you’d rather use another feeder you can also use socat to supply the data e.g. on the quasi-canonical local port 30003: $ socat -U TCP4-LISTEN:30003,reuseaddr,fork,max-children=1 GOPEN:/dev/ttyAMA0,b3000000,crtscts=0,raw Please note that socat is not really good in reading high-speed serial data so you can expect to lose some percentage of the data and also have the occasional malformed frame due to dropped bytes. Best regards, Christopher
"Schöne scheisse" , support should be support - not saying "this is not really good but we have nothing better to offer". At least not for the price.
It was hinted in the earlier discussion that they should be using the AVR format. For testing just shove into the raw input of dump1090 (raw = AVR) socat -d -d -u GOPEN:/dev/ttyAMA0,b3000000,crtscts=0,raw TCP4:localhost:30001 (dump1090-fa has that input disabled by default: change --net-ri-port 0 to --net-ri-port 30001) Then you can check on the map what falls out. But i'm curious as well why they don't use something self-written if socat isn't good enough to read from the serial port. Also it seems from the socat man pages, that the raw option is obsolute: Also baudrate seems to be an option that doesn't always work. I'd try this command line: socat -d -d -u GOPEN:/dev/ttyAMA0,ispeed=3000000,ospeed=3000000,crtscts=0,rawer TCP4:localhost:30001 This command line assumes dump1090 listening on 30001 obviously.
Only as short test ... having a HAT style form factor and power from GPIO is nice, I suppose. However ... It's it worth 5-6x or 10x the price of a USB SDR?
Got it receiving but no MLAT. Some odd issue with dump1090. I suspect this device was made with input from FR24, since it outputs raw and FR24 client uses raw and does funny things with the raw data - including FR24 mangling of MLAT so nobody can use it. As I told the company who built this FR24 guys are assholes. I stand by that. To make this work we need to hack on dump1090 to use a tty serial device. I don't think this company is going to put any effort into that, thus dead in the water for anyone but FR24.
I'd be curious what the dump1090exporter does. I'm not sure dump1090 understands AVR with timestamps. Could well be it just discards the timestamps. Anyway it's not too much to ask from the company to provide a program which exports from serial and offers beast data preferably via a TCP push client or listen port.
James, thanks for showing your results. to make clear the device is not made for any company. It is independently developed by GNS. It is a teaser for a new product category by using a HAT instead of USB. You can not compare the ADS-B HAT with cheap china made SDR dongles its complete different thing.... Anyway ....in your comparison there are two upcoming questions for me 1. you are not testing in parallel with a splitter 2. I am wondering about the range and framerate they are very low....what kind of antenna and cable you are using ? regards Bill2002
@wiedehopf dump1090exporter is stats for prometheus, nothing more. It's my understanding that: AVR doesn't have timestamps. Beast is AVR with a timestamp added, then binary encoded. The dump1090 / mlat-client setup that 90% of enthusiasts use will not be able to do MLAT with the HAT. You have to route the raw AVR to the RAW input port of dump1090, that prevents data from making it to MLAT. dump1090 needs to be updated to use the hat tty device or to use the device direct - just like it does with the SDR. We can hack it in to make it work from the input port, but that creates other potential issues. 1. splitter would reduce dB by half - but I could do that as well. I hooked it to my 42" omni and performance is inline with the $20 FA bluestick. It does appear to have better sensitivity than a FA Bluestick with gain set to max, is it 5x the improvement? 2. Those were sitting on my desk, inside, in stucco hose (metal cage). Outside it is comparable to FA stick. See below. The issue is it's FR24 specific currently because of raw avr output and how it must be routed to dump1090 (the most common install type). GNS Pi Hat: FA stick:
