You should think about upload bandwith. Below screenshots from station receiving more than 3000 aircrafts per day (5 different feeders installed). View attachment upload_2018-7-25_17-7-33.png View attachment upload_2018-7-25_17-8-10.png
I peak out around 140KB/sec. That's a high-coverage feeder (top 1000 on FlightAware) providing, on average, about 850K positions per day. I'm feeding ADSBx, FlightAware, FlightRadar24, PlaneFinder, and OpenSky. Sadly, ADSBx is far and away the biggest consumer of data, since there's no compression going on. Right now, I'm seeing roughly: 19.5KB/sec. - ADSBx 12KB/sec. - OpenSky 5KB/sec - FlightAware 3KB/sec - FlightRadar24 2.5KB/sec - PlaneFinder
When I setup a IoT feeder I am going to just feed ADSBx to keep well under the 64kb/sec limit. Has anyone done any power consumption testing on: PiZeroW+SDR(FAProStickPlus)+IoT Radio as a system? edit: We have one report of 2A draw. Any other data points to report?
Looking at TMobile's website it looks like the $20/year setup is for large quantity purchases. Embeddedworks looking like about double that at $39.44 / year. Still not bad but I want to go with the best deal reasonably available.
Okay Embeddedworks is silly. $11 UPS Ground is the cheapest "shipping" for a $39 SIM CARD... Any other ideas? I'll go check eBay.
I'm intrigued by the possibility of using a low data rate USB/4G dongle with a pi for ADSBx. If I can do that I'll be able to add a RX in a really excellent location (but with no internet available). I'm wondering: Is there a list of such devices with which a RPi 3 would be compatible? I would not think drivers would already be installed. And, I would not want to go too far down a rat hole on this. Any experience with this?
I do know a nice location too where connection is a problem... I plan to pass my HAM radio license this winter and it may well be my cheap solution. Using radio to TX data directly home instead of costly 4G... it will need lots of work to have it working but it is in my plan to make tests with it... Even if not using HAM frequency for production, a cheap radio license for commercial telemetry will do the trick... Reference I will use to base my work is : https://aprs.fi/page/ais_feeding where they feed ships location. If it works for ships, there is a way for aircraft...
Whole different magnitude of data. My feeder exceeds half a megabit just feeding ADSBx from time to time. If you have a decent site with any sort of real coverage, you aren't going to make it work over a 64Kbps data card... and you damn sure aren't making it work over amateur radio (unless you're talking about 1.2GHz DSTAR, and even then the rate would be very low). You could make it work with a high-power 2.4 shot, if you have solid LOS.
tvsjr: OK, I see that now. Even with a pi feeding just FA and ADXBx before "prime time" in the morning I see I've already exceeded that. My AIS feed to marinetraffic.com would work very nicely with that IOT plan but certainly not ADSB! xJMV: I dunno about amateur radio. If I had to link a great RX location with a POP where I had internet I'd probably use a bridge such as is available in many forms from Ubiquity. Likely 5GHz to help minimize QRM. Such an approach would be way less $$ than using amateur radio. I share tvsjr's view as to the feasibility of that idea.
In my area, I have no major airport except my local one (CYVO) already covered by my home feeder. There is a lot of international traffic already ADS-B that are traveling south (Montreal, Toronto or other major airport in USA). My goal is to increase mode S coverage as most of the regional flights that I catch use it. If you look around where I live, you will see there is a lot of peaks, but not much powerline or comms going on top. Prime sites are already used by telecoms and it is out of question for them to host a receiver without a costly contract... So the plan is to experiment a way to make a network out of whatever radio equipment that is available on the cheap and makes it works... HAM is just a way to experiment the thing without the needs for licensing and the fees associated with the process... I keep in my notes both your idea... it will certainly proves to be useful.
I built a solar powered feeder using the T-Mobile 64kbps USB IoT stick. Sorry I don't keep up on these threads more often. It uses UDP to send data to ADSBx servers. Requires a special setup on our end. We should write a client to compress the feed - but then we'd have to support beast, VRS, basestation, vrs compressed, AVR hex, ... and our own feeder client ... ugh If ADSBx was FlightAware or FR24 and had employees or was making a profit selling data or even had students slaving away .... maybe we could do it. Any volunteers?
I was thinking of a situation where one might plug a 4G USB modem directly into a Pi. Easy to do with a Windoze PC but not sure if the Pi would like it. I take it from you response that my question is somewhat idiotic -- so I'll withdraw it.
Well that means Windows has drivers. Dat how the puter werkz! But yes we use https://github.com/wlach/wvdial and whatever drivers are required for the USB dongle. Most of them use a generic driver to function so not an issue. There there are drivers built in to the kernel. https://wiki.debian.org/Modem/3G
A minor data point for anyone considering the TMO M2M solution James describes: I got one of these and am testing it for another application where the data rate is far, far lower than ADSB. The initial test is in a Peplink router where health checks can be easily implemented. What I am finding is that simple health checks (pings and DNS resolutions) often fail and the router marks the WAN as out of service. This occurs roughly 2-3X/hour. This occurred with a reasonable signal of -93dBm. At first I thought the health checks were failing because I had the WAN saturated but that was not the case. From my initial testing it appears that the TMO M2M plan may be incompatible with applications that require a persistent connection, even if the date rate is well below the limit of the service plan (e.g., <1Kb/sec). I'd love to hear others' experiences with this.
No problems here with the feeder that we can see at least using the USB Huawei E397 dongle. https://www.amazon.com/Unlocked-Huawei-E397u-53-Worldwide-Required/ To be fair we haven't tried it with any other hardware. That might be an issue with the Peplink hardware or firmware. On my Pi that's on the roof I can ping it every 5 seconds to read temps without issue on E397.
Hi James. Just an update ... I appreciate your lead on the TMO M2M and the Huawei. I have three of them now and all are working excellently and are installed in Peplink routers. The "disconnection" challenge I reported previously was found to be a "TMO issue." Example: Last week all three -- two of which were located hundreds of miles apart, went off-line in the middle of the night and recovered at almost exactly the same time. Your "lead" on this has really had a great impact here. So, TU! PS: EmbeddedWorks will ship the SIM for a much more reasonable $5 if asked.
Nice! 64K IoT don't work real well in high volume metro hubs like PHX (though we did figure out the using a special UDP setup we can do 1090, but 978+1090 exceeds even special UDP tricks), but we use them elsewhere with much success! $5!! wooooooo
