This is very encouraging:
ADS-B is an air traffic surveillance technology that enables aircraft to be accurately tracked by air traffic controllers and other pilots without the need for conventional radar.
This article explains how to attach and configure a MAVLink based ADS-B receiver by uAvionix called PING™. Please visit their website for technical specs including RF characteristics and connector pinout.
Comments
@JB Mission Planner does have ADS-B support via RTLSDR but I think it was removed. I don't know why. Feel free to post a MP feature request.
You keep going on and on about the $20 RTLSDR. I'm confused, what is an RTLSDR based ADS-B have that this doesn't? It's not price because in order to crunch the data you need to slap on a Linux-class companion computer and now you're no longer talking low-power, low-price, low-heat and low-size. Not to mention USB was never intended for use in high vibration environments thus making it a horrible permanent solution to deploy. Those who fly with that are pressing their luck.
Sounds like you fly while tethered to a GCS at all times. Many people do not. This solution serves everyone.
This is not a new concept, there's a group for you here and I see posts from 3.5 years ago. Pull-requests are welcome. Less talking and more doing!
Thanks Tom for the link.
Would be nice to see a simple ADSB add-on for MP using a RTLSDR. Might need to seriously look at it after the challenge when I have some more time.
-
@ Martin
I'd take it another step further and say that UAVs need to help distribute the internet as well as UAV location data using wifi mesh networks and picocells onboard! They could also generate their own passive radar grids to monitor anything else in the air or ground without producing any additional RF noise to congest the airwaves. ;-)
There's also the question whether having a ADSB TX onboard is useful or wise. I can't image a full size aircraft trying to avoid a UAV, a UAV should always avoid the aircraft which only requires a ADSB receiver system, nor do I think it wise that GA should even have to monitor UAV flights (why have a TX on there otherwise?) and add to the airspace clutter they already have to contend with. Sure it might be helpful if the UAV shows their location, maybe short range, should the UAV sense and avoid fail and the GA needs to duck and roll instead, but I'd prefer that the UAV is no where near "normal" GA flights are in the first place. At a minimum under a certain altitude. I'm also not particularly worried about UAVs crashing into each other provided they are under a certain size. GA must always simply have the right of way no matter what.
Based on that we could have ADSB aware UAV's flying in every aircraft connected to a GCS with a $20 RTLSDR dongle or even just a internet connection. I've suggested this months ago but haven't seen it happen yet. The PXH implementation is a great step in the right direction, it's just missing the RTLSDR GCS link IMHO.
Regards JB
Wow that's fantastic.
@JB There is a new MAVLink packet that it uses so if your companion computer speaks that, then you're good to go.
@lkaros I don't know about CAN but this would be a good candidate since it hogs up a precious serial port.
@Martin you're talking about Altitude Angel. ADS-B was not intended for tens of thousands of aircraft in the same proximity where they all just jam each other. In the future drones will need to graduate to an internet based system. But until then, here's something.
I tend to think along the lines JB mentioned...
If the future of drones is "moving away from RC protocols and using more mobile/Internet standards" (as rightfully mentioned in the thread about the new Hobbyking transmitter), the ADS-B integration should also follow that approach IMO. Having the stuff onboard and plug and play still has disadvantages (power consumption, radio emittance if done bidirectional, space & weight issues).
So why not have that unit on the ground and deliver the information via telemetry to the aircraft? Possibly somewhere in the cloud (logically, physically of course still in the same area)?
Additionally, and this is the big advantage cost wise, this approach could serve also a larger number of aircraft in the same area at the same time.
As soon as we have Internet on the aircraft (any the trend goes in that direction) there could be service providers from which this data could be fetched via webservices. Or so.
In my system flightzoomer I already have a server at home where any communication to and from the aircraft passes by. From there I could easily serve a large number of aircraft that connect to that server.
Looks great!
Any plans to add UAVCAN as interface?
So by that are you also saying the ADSB PXH implementation will only function with this specific hardware? (I know this is the third time I'm asking this!)
I realise the PnP nature of the product Tom and that it can function independently, but as a "consumer" I can't see why I should buy even more gear if what I have already can do the same, at least for avoidance purposes using RX, with a bit of integration. I think from a marketing point of view, unless the device is priced as aggressively as other hardware that can be tasked for this purpose, it's unlikely to see much adoption which IMHO would be a shame. This is of course not your fault BTW! :-)
I hope you don't see my comments as being hostile in any way, I'm only trying to be pragmatic about such developments.
Best Regards JB
Hey Tom
I don't quite understand what you mean with your SDR statement.
I was just wondering if it matters where the ADSB information is sourced from and if it's possible to use alternative ADSB receivers/transponders to activate the PXH avoidance parameters you have implemented.
I already run RTLSDR/BladeRF for RF monitoring (for telemetry and wifi etc) and trying to avoid onboard interference through proximity to other electronic emitters. Having the ADSB RX hardware onboard and on the ground already would mean that it's more a matter of interfacing the existing hardware and software components to achieve the same ADSB PXH integration, without the need for any other hardware, and leaving the opportunity to develop other applications ranging from passive radar for avoidance etc. to a full flying 3G/4G pico-cell using SDR.
In fact a RTLSDR dongle plugged into the ground GCS would likely result in the same ADSB RX functionality as this device at possibly only a marginally lower sensitivity and could use telemetry to provide the required ADSB mavlink packages to the PXH. An onboard companion computer could do the same of course. MP already supports ADSB to some degree so triggering the avoidance should be possible as well IMHO. Or are you saying this is what you have already done? If so awesome! ;-)
In the mean time I will look into contacting the vendor to see their release time frames and the SITL implementation.
Thanks for your help.
Regards JB
No word on product release, I suggest contacting the vendor and order one when available. There's SITL support so algorithm development can happen now.
-
1
-
2
-
3
of 3 Next