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.
Thanks Tom :)
I wrote to company, but not have any contact yet.
@Vladimir, Nothing keeps them from implementing the mavlink packet. It should be plug-and-play for them once they do that. You'd have to talk to them about support for it since I don't know anything about that project other than that have amazing TCAS support :) @earthpatrol
Is it possible to integrate PING with other AP ( like a Paparazzi ) ?
Does anyone know when ADSB_enable will be working in apm copter?
What an amazing advance. Do you guys know when the Transceiver (Ping2020) and PingNav will be available? I sent some emails inquiring about this but I had no clear answer. Neither about the price. It would be great to know this information so we can plan to include this to our current project.
the PING ADS-B receiver from uAvionix is now in stock at UAV store :-)
anything more here?
No companion computer is a nice feature/assurance for beyond LOS activities.
@JB--we're using the 'rumbling of a grumpy old man' solution you described to good success.
We've gone down the path of the RTLSDR since we're typically flying in controlled areas, well-known airspace, i.e. scheduled activities--hence Ping would be overkill. But for ad-hoc flight plans or uncontrolled airspace, something like onboard ADS-B or at least the LTE connection would be needed unless you can get info to a local ATC access point.
In the end, either make the GCS wireless connection rock solid [so one can off load logic] or put more logic [sesnors] on board.
No Probs and thanks again for the links. I'm surprised MP has dropped support, I'll need to have another look.
Sorry about the rumblings on of a grumpy old man, but no companion computer is required for reception or processing if the GCS PC is used and the packages are sent via telemetry to the UAV. I don't have any vested interests in RTLSDR, in fact the opposite is true in that the packages can be sourced from any ADSB receiver or online. A very long cable to tether the aircraft is also not required. ;-) Accordingly there's no wobbly USB, weight, cost, vibration penalty doing it that way whatsoever. Operating without telemetry aka fully autonomously for extended periods, is not what I would consider safe operation procedure for any application when sharing airspace with other users. GA uses radios for safety as well, so i'd imagine using some form of telemetry will remain prevalent and facilitates relocating ADSB, or any other safety devices out of the aircraft as required.
We've been operating our S&R and challenge UAV's using custom 4G/LTE Android based cameras for imaging, recognition and telemetry along with custom Android GCS with real time image/geotagged thumbnails handling etc and some real time in cloud image processing etc over 4G mobile since 2013 (in fact that's how we were forced to go at the 2014 OBC because our companion computer failed in flight!). So there has been some actual work going into what we do and we are developing further into that direction to create a mature platform before release. The safety aspect is a high priority for us, in S&R creating more victims to rescue is the last thing we want to do.
I respect your efforts and have praised them thus far, so I'm not sure why you are responding so defensively to comments that weren't even directed at yourself. My only intention is to further the cause of safe UAV operations and don't mind being competitive on which system is best suited and the fastest way to make them safer. I simply feel your ADSB contributions would benefit from supporting different types of hardware as well. I'll leave it at that.