This page describes a personal project being carried out by several individuals known to us as the 'Open Flight Alarm' or 'OpenFLARM' for short. It has no connection with the company FLARM Technology AG of Switzerland who produce, in our opinion, an over-priced commercial product with similar but far from identical functionality to that which we describe below.
This website describes our quest to build a device solely for our own personal use and in no way should it be construed as an offer to sell any product or service whether named 'OpenFLARM' or otherwise, nor that any person working on the project is in any way trading under such a name.
So, now we have that out of the way:
The OpenFLARM project is a quest to design a device for light aircraft pilots that collects data about other aircraft in the vicinity and presents that data to a navigation device, for example an iPad running Sky Demon.
Whilst devices such as this already exist in the market they are hugely expensive. OpenFLARM was concieved for the single reason of bringing an affordable system within reach easy reach of every light aircraft pilot.
Our target is to release an 'open source' hardware design and example software such that a device can be built for around £50. Anybody will be free to build, modify or contribute should they wish.
The name is derived from the word 'Open' denoting the open software/hardware ethos and the words 'Flight' and 'Alarm' referring to it's functionality.
The device we envisage is a small carry-on unit intended to be temporarily mounted on top of the coaming ('dashboard' for non pilots!) of a light aircraft. It transmits the aircraft's position in a similar way to a transponder and receives the position messages from other aircraft in the vicinity. This data is then analysed and sent to a compatible navigation system, for example Sky Demon, such that traffic in the vicinity is shown on the moving map.
Such a device will have a built in GPS receiver which brings the handy side-effect of also acting as a source of location data to connected devices meaning reliance is not placed on the navigation device's built in receiver which are often poor.
Unlike other systems on the market, OpenFLARM as it's name suggests is completely open-source. The hardware, software and the air-side protocol will be published such that anybody can analyse the functionality, contribute changes or additional features, build a 'clone' device of their own or even completely redesign the device to their own specification with no agreements to sign or payments to make.
We believe that this ethos, which is commonplace within the IT sector, is key to realising our objective putting the technology within easy reach of private/hobby pilots and help break the current monopoly held by a commercial company. It also brings with it the advantages that the device is constantly being peer reviewed meaning that bugs are likely to be spotted sooner and new features can be contributed by third parties.
We are aiming for our device to cost under £50 to produce which is probably less than 0.5 hours flight time for most light aircraft pilots. Compare this to other commercially available systems, which typically cost upwards of £300 just for the reciever and another £150 for the additional device needed to make it talk to an iPad. However, we do not intend to enter commercial production ourselves but instead will be publishing all the design documents you require to build your own unit should and will encourage third parties specialists to produce devices based upon our work.
OpenFLARM is entirely unrelated the commercially available system named simply 'FLARM'. In comparison to this system, OpenFLARM will be:
You may also be interested to read this post made recently to several GA websites (by a third party).
ADS-B is a standard based around an expansion of the transponder technology that is commomplace in GA aircraft already. However like all other systems, in order to provide a collision-avoidance function it relies on a critical mass of aircraft to have had their transponders upgraded with a GPS device which, as it is connected to an aircraft system, has to have undergone an approval process. Because of this, the upgrade is prohbitively expensive for most light aircraft pilots, flying clubs, etc and it is therefore a long way from achieving this critical mass within light aircraft operators at this time.
Of course we understand that ADS-B is commonplace in commercial aviation, and for that reasons we hope that in the future we will be able to integrate ADS-B functionality into OpenFLARM. However at the current time it is not possible to do so within the other design limitations, in particular the price point, of our device and in any case the current low level of adoption of ADS-B in light aircraft means it is not a huge limitation at this time to not be compatible.By the way, if you think ADS-B is the magic bullet for this application you may be interested to watch this video from the DEFCON hacker conference. ADS-B is seriously flawed in that it has no mechanism to verify the source of a position report, ie it is trivial to spoof positions, make aircraft appear from nowhere, and all manner of other nasty things with <£500 worth of commonly available hardware. Hopefully the commercial aviation community will completely replace ADS-B with a more modern alternative that is accessible and affordable for light aircraft pilots before we are all forced to invest in a flawed technology.
OpenFLARM will be able to detect aircraft carrying FLARM devices but not vice-versa. This is because FLARM encrypt the data they transmit, do not publish any details about their protocol and have patented parts of their collision avoidance technology to prevent others from creating compatible devices. Clearly this gives the company producing FLARM a huge commercial advantage and allows them to demand large sums of money for their devices but, like most monopolies, is ultimately bad for the market and in this case, flight safety.
Everything that is known about the FLARM system has been learnt from reverse engineering and we are hugely grateful to Hiram Yaeger for both his efforts in this field and for publishing FLARM PROTOCOL VERSION 4 and GLIDER ANTI-COLLISION RADIO PROTOCOL VERSION 6. Also worthy of mention are Pawel Jalocha of the Open Glider Network for his guidance and more recently Stanislaw Pusep for publishing his FLARE project on Github which has been a great source of help.
Whilst OpenFLARM will be able to receive and interpret FLARM signals it will not be possible to transmit signals that FLARM users can see without infringing the manufacturers patent. We are of course open to an approach from FLARM's manufacturers on this subject.
Update 5/7/2017: It seems FLARM Technology AG think the best way to deal with this matter is to threaten us with unfounded legal action (claiming trademark infringement) so it is unlikely we will see any co-operation any time soon.
OpenFLARM is a standalone, carry-on device intended to be placed on the coaming during a flight, not affixed permanently to the aircraft or connected to any built-in systems. For this reason it does not require approval or type certification in the same way that standalone navigation devices (eg iPads) do not. The radio system is designed to operate with an ISM 'License Free' band such that it does not require any specific licensing to be used in the air. This is the same situation as with the commercially (carry-on) FLARM device despite what the manufacturer would have you believe!
Our design uses a 32bit ARM Cortex M0+ CPU at 48MHz at it's heart. Compare this to the ATM128 used by our closest competitor, a 16MHz 8bit device, and you can see that OpenFLARM is massively more powerful especially when it comes to the floating point maths required to calculate traffic position relative to the user.
For compatibility reasons we use the same Nordic nRF905 radio chip to transit and receive aircraft positions. Whilst there are other, better performing radios out there it was felt that compatibility with the existing market was a key consideration. The nRF is configured with an external SMA connector so either a small 'rubber duck' style aerial can be used or a more sophisticated setup for increased range.
The GPS engine is a ublox NEO-6 which is a 50 channel system capable of accuracy up to 2.5m. Again this is brought out to an external RP-SMA connector so that an external aerial can be positioned for the best view of the satellites.
Finally we have utilised a WiFly RN-171 from Microchip Technology to act as the bridge between the OpenFLARM and your navigation software. This is very similar to the device used at the heart of the Butterfly Connect units commonly used for connecting to other collision avoidance systems.
As above, OpenFLARM is fully open source, and in line with this here is the schematic. We encourage people to produce their own version, suggest improvements, help us spot problems, or anything else they feel would be useful to the project.
Update 5/7/2017: work is continuing on the project and the first software version will be released soon.
Update 28/2/2017: the first prototype units are complete and trials in the air will commence as soon as we have some suitable weather.
Update 4/5/2016: the first run of prototype PCBs has arrived and we will shortly begin assembly and testing We have built a number of working proof-of-concept units and tested their integration with an iPad running Sky Demon (Screenshot). The final PCB design is currently being completed, after which we will produce a small run of prototype units which will be distributed to members of a local flying club to test. On the assumption that no major flaws are found we expect to begin full production in late 2016
You can join our mailing list using the form below to be kept up to date with the progress of the project. We promise to only send you emails regarding OpenFLARM.
OpenFLARM.co.uk. Last updated 28/2/17.