"Do It Yourself" airborne proximity warning device

This project lends "Blue Screen of Death" an entirely new dimension of meaning http://en.wikipedia.org/wiki/Blue_Screen_of_Death

I'm an enthusiastic supporter and participant in the whole Open Software/Hardware and Maker movement, but given the stakes, I have very mixed feelings about this project. A collision warning system that you cannot trust can potentially cause more harm than good. What if the system tells you to "turn right" when you should "turn left"?

A collision warning system needs to be about as reliable and trustworthy as the software and hardware that implements the ABS in your car. Implementing an ABS system properly is a whole order of difficulty beyond developing something like the very wonderful and amazing XCSoar. A defect in XCSoar is unlikely to kill you.

One thing that can in some cases make open source software and hardware more reliable and trustworthy than proprietary systems is the effect of having a large developer community scrutinizing the source code and hardware. Linar's project presently has one developer. It also helps to have a large and diverse group of users banging on the system and reporting defects.

It is an exciting time when individuals like Linar can pull together a bunch of existing building blocks and rapidly prototype a new idea. But there is an inherent fragility in any system that relies on multiple "black boxes" and a collision warning system needs to be extremely robust. Black boxes often do not do what they are advertised to do, when you use them in unanticipated ways. Just because something works when you turn it on does not mean that it is reliable.

If Linar's approach has a real potential to deliver a collision warning system at lower cost and/or higher reliability than PowerFlarm, then I hope that he obtains the funding that will allow him to pursue this project in earnest. An opensource collision avoidance system has the potential to be superior to PowerFlarm. PowerFlarm might be more reliable and better functioning if they made the software open source (but their business model does not allow that).

Ok, lets get real here. This sounds like a nice little club project, and if the intent is to have all the club gliders equipped (as opposed to none with Flarm) then it has some value.

However, in the big scheme of things, it would have to be orders of magnitude less expensive and better performing to be able to overcome Flarm's lead (see France, Australia, etc.). And let's face it - most glider pilots are not going to cobble together a piece of kit like that - we'll pay extra for the fancy bells and whistles!

Let's take another example: I'm sure we can come up with a less expensive, better quality radio communications system to replace the old VHF system we now use for aircraft/ATC communications. But until everybody has a compatible system, you can only talk to the others who have the same system - so is your new system that much better? So we are stuck with an archaic AM radio system that you have to have, and it's good enough.

Now, what would be nice is an inexpensive ADS-B "out" box that would let gliders broadcast their position into the ADS-B "system" without needing a full up UAT/Mode S/WAAS IFR certified GPS setup. One of those, plus a PowerFLARM, would be a really nice setup.

Kirk
66

I've published today the parts list with price estimate:
https://rawgithub.com/lyusupov/Argus..._Estimate.html

I would like to express my appreciation to those subscribers of rec.aviation.soaring
who exposed the slides to honored soaring societies of Netherland and Poland
followed by a comment in native language.
Thank you very much!

On 12/09/2013 04:22 PM, Linar Yusupov wrote:

I would like to present you PDF slides of one DIY R&D project.
The slides are about open platform airborne proximity warning device.
It operates at ISM band radio but also capable to receive ADS-B reports at aviation frequency.

I wonder how easily this device could be converted into one that can
transmit glider airspeed during a winch launch back to the winch driver?
It would require an extra hardware module with a pressure sensor to
measure pitot/static pressure, an analogue to digital converter, a USB
interface and additional software in the main radio unit.

You would need a 2nd radio device in the winch coupled with a suitable
display unit.

Dedicated devices for transmitting airspeed from glider to winch have
been made before, both on an experimental/development basis as well as
on a commercial basis. However every glider that gets winched from a
site needs the device to benefit from the technology.

The proposal describes a low cost anti collision device. If it could be
extended to provide winch launch airspeed feedback, it would provide an
additional function at an incremental cost. It might be attractive for a
club where the whole fleet is targeted for fitting of these devices, to
incorporate this additional functionality, if that club also operates a
winch.

Obviously this device is an alternative to Flarm. Adding this new
functionality might differentiate it enough from Flarm to create a niche
market.

Good luck with your project.

Ian

On Thursday, December 19, 2013 1:23:08 AM UTC+4, Ian wrote:

I wonder how easily this device could be converted into one that can
transmit glider airspeed during a winch launch back to the winch driver?

Ian, the functionality you've mentioned about is falling into category of
"remote monitoring of an aircraft's telemetry".
There could be numerous applications of that functionality. One of the examples
is a first solo flight. Instructor, while on the ground, can prevent inadvertent low altitude stall.

Ground station device ("winch" device is your case) could be not necessarily "dedicated device".
Beacause of commonly used Wi-Fi technology, average Android tablet will likely be able to receive
and display the telemetry from an aircraft doing a close traffic pattern work.
Provided that tablet's built-in or external USB module is supported to work
in "monitor mode" ( http://wireless.kernel.org/en/users/Drivers ) .

Sensors, such as barometric, are typically low power consumption devices.
It is not necessary to feed them from USB bus. They can operate from a coin-sized battery for weeks
while submitting the measurement data troough Low Energy Bluetooth ver.4 protocol.
One known good example is the SensorTag ( http://www.ti.com/tool/cc2541dk-sensor ) USD25 device from Texas Instruments.
One can attach similar sensor to the pitot tube and submit data to Argus PM module by Bluetooth.


What I can do for now is - I can create a "Feature requests" list. And I'll put the count "1" on this particular feature.
When once upon a time the counter's value will become sufficent and there will be enough volunteers
to contribute something into this project - I will suggest them to implement this feature.

To trust or not to trust in a item built by yourself?
This is a question that has no a simple answer applicable for everyone.

There are numerous RVs, Cubs, Velocities and other kitplanes flying around us.
Majority of the aircraft's structures had been built by the owners themselves.
The aircrafts have received airworthiness approval from government agencies.
A pilot of such aircraft trust his(her) life to the self-built airframe, wings and controls
which are primary, life-saving elements for 100% time of each flight.
In some countries supplemental live-saving equipment such as pilot's emergency parachutes or
a ballistic recovery system are optional, not required by air law, for this experimental
category of aircrafts.
And majority of aviators worldwide treat these facts as Ok. How EAA driven Oshkosh Airventure
and Lakeland Sun-and-Fun will look like if there would no experimental aircrafts?

Sailplane pilots operate their aircrafts under visual flight rules.
Primary and most essential instruments for maintaining situational awareness under these rules are the pilot's eyes.
Any electronic aid designed to serve this purpose is considered as supplemental.
Regulations states that you should not 100% rely on indication of a supplemental aid.
Taking this into account how it is important if the aid is a "factory built" or built by yourself?

For those who already had an experience of building an electronic device with success
my advice is: use this project as example then do your own hardware design of the device
that you personally can trust onto.

A new design which is primarily considered as add-on for the Argus project has been recently released.
It is an IoT bridge between FLARM and Wi-Fi consumer devices. Codename for the design is SoftRF.

Areas of application:
---------------------
- a two-way bridge between FLARM and other traffic awareness designs ;
- alternative to Raspberry Pi based Open Glider Network (OGN) receiver ;
- wireless adapter for a smartphone or tablet to receive/transmit traffic information by iOS/Android app ;
- lightweight traffic awareness transceiver to carry onboard an UAV.

For more details, please, read these PDF slides:
http://github.com/lyusupov/SoftRF/raw/master/SoftRF.pdf

Linar Yusupov.

Dear soaring community!

I've recently released development update of the open SoftRF project.

Few highlights:
- transmit power is 10 mW, so operating range is similar to the "classic" FLARM has ;
- FLARM and SoftRF can see each other ;
- is compatible with Open Glider Network (OGN) ;
- most popular gliding software (SeeYou Mobile, XCSoar, ...) just works, "out of the box" ;
- on a hardware level, it has a DIY modular design with Arduino-style "shield".

Full document in PDF format can be downloaded from:
http://github.com/lyusupov/SoftRF/ra...-release-2.pdf

For more information, please, visit: http://github.com/lyusupov/SoftRF

With best regards,
Linar Yusupov.

With recent Fall'17 features upgrade, in addition to "Legacy" (FLARM AIR V6) radio protocol,
the SoftRF is now able to communicate using three other major ISM-band radio
collision avoidance "languages", such as:
- P3I Open (PilotAware) ;
- OGNTP (OGN tracker) ;
- FANET (Skytraxx)

Full compatibility "matrix" is availle he https://github.com/lyusupov/SoftRF#compatibility

One more new feature is support for Garmin GDL90 datalink format, which is widely used
on North America EFB software market (ForeFlight, Naviator, WingX,...).
For details, please, read this page: https://github.com/lyusupov/SoftRF/w...-compatibility

And SoftRF can now be integrated with RTL-SDR based ADS-B receivers, such as:
- airborne:
Stratux
PilotAware
- ground stations:
FlightRadar24
FlightAware
For example of integration, please, visit: https://github.com/lyusupov/SoftRF/w...%90B-receivers