NMEA serial output for FLARM, anyone?

[ssokol]

A backer contacted me a few minutes ago and was interested in adding support for serial output of NMEA sentences to a FLARM port on a glider. From the backer:

I would like to use FlightBox to output NMEA formatted traffic data to the Raspberry Pi serial port so I can use it with glider flight computers, like the LX Nav LX 9000 and the Naviter Oudie. They both look for traffic data in the Flarm data port NMEA format I believe. There seem to be some Python programs available to convert to NMEA output but none output to the serial port to my knowledge.

I'm not personally familiar with FLARM, but from a quick google search it appears that the data format is public, while the actual radio system is highly proprietary. Anyone have any experience with it?

[duecedriver]

Hey.. Musk is looking for a astro navigation package to put on the Dragon 2 Mars mission.. perhaps if he threw a couple bucks at your kickstarter we could roll something up for him too...?

[bradanlane]

Pizza

[duecedriver]

hey if we cant get ahrs working because of gravitational vectors.. it will work better in Zero G... hehe

get a sense of humor...

[ssokol]

Thanks. The glider guy was interested in helping out and told me that he had several friends who could help with the code. I really am not trying to push the community.

On Saturday, January 23, 2016, bradanlane notifications@github.com wrote:

Pizza

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/218#issuecomment-174239843.

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441

[bradanlane]

While this is the first I've seen of FLARM, it's not the first NMEA request. I actually think FLARM is closer to the Stratux mission than some of the navigation related inquiries.

Perhaps the initial effort would work as a fork?

[ssokol]

I think that works as a start. Eventually I would like to see whatever results rolled back in. And not just for commercial reasons.

On Saturday, January 23, 2016, bradanlane notifications@github.com wrote:

While this is the first I've seen of FLARM, it's not the first NMEA request. I actually think FLARM is closer to the Stratux mission than some of the navigation related inquiries.

Perhaps the initial effort would work as a fork?

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/218#issuecomment-174245458.

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441

[duecedriver]

Flarm is a form of Tcas and has a transmit requirement. Tx would be futile if he wants stratux to be a flarm box

If he just wants a flarm formatted output of traffic from stratux of ads-b targets not other flarm to input into the flight computer it would have to be a hardline out of the pi serial to serial. I don't know of a nema traffic format though

If he really means Nmea we would first need the exact format of the traffic message.

Flarm traffic message should be published somewhere

If he really just wants Nmea gps out to the flight computer it would Be a bit of a Rube Goldberg way of getting that data since a simple gps hookup would be cheaper and easier.

[ssokol]

From what he told me, all he wants is the raw traffic data. No expectation that we provide the resolution and alarm functions of the actual FLARM system.

I think his goal is simply to convert traffic to a format he can accept. More than just basic GPS. Not trivial, but not a huge burden.

On Saturday, January 23, 2016, duecedriver notifications@github.com wrote:

Flarm is a form of Tcas and has a transmit requirement. Tx would be futile if he wants stratux to be a flarm box

If he just wants a flarm formatted output of traffic from stratux of ads-b targets not other flarm to input into the flight computer it would have to be a hardline out of the pi serial to serial. I don't know of a nema traffic format though

If he really means Nmea we would first need the exact format of the traffic message.

Flarm traffic message should be published somewhere

If he really just wants Nmea gps out to the flight computer it would Be a bit of a Rube Goldberg way of getting that data since a simple gps hookup would be cheaper and easier.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/218#issuecomment-174246306.

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441

[duecedriver]

This should be all you need

I however am completely opposed to rolling this into stratux. It should be a special fork for the VERY few that use it. Too much overhead to crap up the data stream unless it can be turned off

. FLARM allows input and output. Sentences consist of NMEA-0183-standard GPRMC, GPGGA and GPTXT sentences and NMEA-0183-style proprietary sentences that start with PFLA, in addition to Garmin®’s proprietary sentence PGRMZ6. FLA has been officially assigned by NMEA as the FLARM manufacturer code on July 26, 2004. All sentences must start with “$” (0x24) and end with the checksum delimiter “*” (0x2A), followed by two checksum characters and (0x0D0A). For matters of simplicity, the following document does not mention these characters although they must be provided in sentences to FLARM and are part of the answers given by FLARM. Fields are delimited with the “,” (0x2C), even when the field content is omitted. The field length might vary. Sentences must always include valid characters. The sentences are not case-sensitive except where explicitly stated. The maximum number of characters in a sentence is 82, consisting of a maximum of 79 characters between the starting delimiter “$” and the terminating delimiter . Sentences not following this syntax must be ignored without further consequences by the receiving device. Design your application fault-tolerant.

[cyoung]

@ssokol - there were a couple requests for it before but it didn't seem to be in high demand.

There are a couple users testing serial GDL90 output now, when that is tested more and integrated it would likely be a good time to look at this output type.

We output now in GDL90 format and X-Plane simulator "XATT" messages. These can be turned on/off in the config, port number changed, etc.

Integrating new types of data output is a great idea as long as it is not superfluous. FLARM is fairly well established in the glider community, so I'd say it fits.

If someone wants to add this it's a fairly trivial addition to the serialout branch. I would add it myself if we had someone that is dedicated to testing it and giving feedback.

[ASW27B]

I made the request of Steve. Most gliding computers accept serial communications and can display traffic on the computer's moving-map display so long as it is in the NMEA-0183-standard format. I believe it is just the GPRMC and GPGGA sentences. The reason Flarm was included in the request is because the Flarm dataport spec is the standard that most gliding computers understand.(http://www.ediatec.ch/pdf/FLARM%20Data%20Port%20Specification%20v7.00.pdf). Flarm has more than 20,000 units sold worldwide. The idea is to add ADS-B and TIS-B traffic to the existing serial NMEA stream that PowerFlarm sends to the glider flight computer. The easiest solution would be to use a serial NMEA Mux (K6Mux does this) to merge the Flarm data with the ADS-B traffic from FlightBox. I'd be happy to do testing if that would help.

[cyoung]

Ah, so you want to merge two traffic data sources? Do you have some example output and does the FLARM have any identifying features for a traffic target that would allow us to merge targets (hex code for ModeS targets, or something else?)

[ASW27B]

At the simplest level I'm looking to make ADS-B traffic information available to any display that takes serial NMEA - which is what gliders use. It doesn't necessarily need to be merged with Flarm traffic to be useful but it would help. That way, glider traffic, most of which use Flarm exclusively, can be merged with ADS-B traffic and displayed on a glide computer's moving map display.

In the eventual situation where a glider is equipped with Flarm, ADS-B Out (and/or a Mode C or Mode S transponder), you might want to de-dup targets. That's not currently a practical issue, but it could be should the glider exemptions for transponder or ADS-B carriage change or if TABS moves forward in a way that includes gliders. Right now it's nearly impossible to get ADS-B Out into a glider legally.

Flarm currently comes in two flavors, one with ADS-B 1090ES In and PCAS and one with just Flarm (it's made in Switzerland so they didn't bother to implement UAT at all). Should it become an issue, every Flarm unit broadcasts a unique ID, which if you are carrying a Mode S transponder is the ICAO ID, so it should be possible to de-dup targets that are transmitting position on multiple systems. Or you could live with some duplicate targets - better two than none.

I don't have example output - I assume you mean a capture of the NMEA stream? That would require flying with some other Flarm-equipped gliders if you want actual targets included.

[cyoung]

A minimal set of NMEA sentences which causes the display that you want - that would be great. Even with a simulated target or targets.

[duecedriver]

Let's look at this from a practical system engineering standpoint.

First and foremost. He is not asking for stratux to receive or interpret the data stream from the flarm which iscprobably good since it looks like they are going to encrypt it.

Second. He is asking for stratux to take its existing targets list and output them as a flarm formatted nmea target. The sentence format is in my above post that you didn't read

That serial output gets wired into a nmea mux box like what they use on boats that will combine the nmea sentences from the flarm and the stratux pi and forward them via serial to the flarm input on the special display.

Now for limitations.

Tis-b will likely be useless unless you are around someone with ads-b out to provide a puck

1090 traffic might be useful if you glide in the flight levels or around a major airport

Because you are using a mux box the traffic gets combined there so no deddpe is possible in the pi

What have I missed

[cyoung]

@duecedriver - the info you pasted isn't complete.

@ASW27B - Here is the information we have to construct the output: https://github.com/cyoung/stratux/blob/master/main/traffic.go#L66-L89

[duecedriver]

http://www.ediatec.ch/pdf/FLARM%20Data%20Port%20Specification%20v7.00.pdf

For spoon feeding

[ASW27B]

First goal is to get UAT direct traffic. Gliders currently have no way to add that today. Second goal is to get access to TIS-B traffic for the case that gliders carry ADS-B Out (which is looking increasingly likely). PCAS is nearly useless for gliders because they fly in such close proximity to each other. Third goal is to get an ADS-B In receiver to talk to glider instruments regardless of combining with Flarm.

PowerFLARM carries 1090ES In and de-dups internally If you really wanted to de-dup Flarm traffic for gliders also carrying UAT Out you would need to bring the PowerFLARM NMEA stream into the Pi and do it there (which means two serial ports), but it seems unlikely that many gliders would equip with Flarm and UAT Out - 1090ES Out seems far more likely for a number of reasons so taking on a whole merge/de-dup effort seems like overkill. I was trying to keep the ask as simple as possible.

[duecedriver]

UAT is UAT.. cant be limited to direct only.. once you have it you will be listening for messages on that frequency which will include ground uplink traffic if in someones up puck.. and weather, but flarm displays probably won't use it and can't go out over nmea serial.. and unless you are into xcountry gliding .. the weather is what is was where you took off and are going back to.. but could use an iPad for if you wanted it.

since the powerflarm box is doing 1090ES...no need for one here or to include those targets in your stream..

the systems engineering flow above is correct per your comments.. or has something been missed or glossed...

[cyoung]

None of this is relevant, all traffic targets are combined and output in the same way in the current GDL90 report.

[cyoung]

@ASW27B - so I assume you need from stratux GPS position output barometric pressure alt output and stratux needs to draw alert zones (PFLAO)?

[duecedriver]

@cyoung

he doesn't need or want a GDL-90 report.. he needs the ADS-B TIS traffic packaged into a new format and send over a nmea wired serial connection to a nmea multiplexer that will add that target stream to the nmea target stream coming from his powerflarm box.. that multiplexer will send the combined traffic picture to his flarm display...

totally different stream, over a different port, using a different message format...

[ASW27B]

PFLAO appears to be new to v7 of the data port spec. I don't think you need to do anything with it. I believe it's a command you load into the Flarm config file to use Flarm to alarm upon entry to things like TFRs, drop zones, etc.

I believe baro altitude is what Flarm uses but it's off of cockpit air. Is baro altitude available on the Pi? I was assuming GPS altitude would be what you'd have to work with.

[ghost]

@cyoung - this looks pretty straightforward. I'm interpreting @ASW27B 's request as a traffic stream of UAT (and possibly 1090ES) traffic data. Take a look at the PFLAA message in Section 7.2 of the spec posted yesterday.

Format is `PFLAA,,,,

,,,,,, ,` with the various parameters as described in the spec. Because this reports relative distance (rectangular coordinates: meters north, east, and vertical relative to ownship), a GPS position fix is required to be to calculate horizontal distances to target. Baro altitude would be as well, to get accurate vertical distance. A fully-provisioned Stratux (GPS + 10-axis AHRS) already has both types of position on the current code. If Stratux is just being used as a traffic source only (i.e. no GPS and no AHRS) I don't see why position data couldn't be extracted from the RS-232 output of the FLARM box. Assuming you've installed and RS-232 converter on the Pi... split the Tx line off the PowerFLARM. Wire one side to Stratux, and the other to the first channel of your NMEA MUX. (The Pi RS-232 output would go to the second channel of the MUX). Current Stratux NMEA parsing will pull GPS fix data from the RMC / GGA messages; you'd need to add parsing for the PGRMZ baro altitude message. Then it's just a matter of filtering the traffic map to nearest targets, running it through the relative distance calculation, formatting and [checksumming](https://github.com/cyoung/stratux/blob/master/main/ry835ai.go#L317-L320) the output string, and sending them out the port, once per second.

[duecedriver]

@AvSquirrel you have hit the issue on the head... because I believe that in the requesters setup.. the powerflarm box is doing all the collision calcs.. and flarm only presents traffic if its a collision hazard unlike ADS-B EFB that shows them all.

so the message that leaves powerflarm to the display includes the collision alarm details..

will outputting only a traffic position show up on a flarm display.. some of which are just lights in sectors by the look of it on the more simplistic display heads.. not necessarily graphical/map based..

[duecedriver]

interesting snipet...

How FLARM works

Each FLARM device determines its position and altitude with a highly sensitive state of the art GPS receiver. Based on speed, acceleration, heading, track, turn radius, wind, altitude, vertical speed, configured aircraft type, and other parameters, a very precise projected flight path can be calculated. The flight path is encoded and sent over an encrypted radio channel to all nearby aircraft at least once per second.

At the same time, the FLARM device receives the same encoded flight path from all surrounding aircraft. Using a combination of own and received flight paths, an intelligent motion prediction algorithm calculates a collision risk for each received aircraft based on an integrated risk model. The FLARM device communicates this, together with the direction and altitude difference to the intruding aircraft, to the connected FLARM display. The pilots are then given visual and aural warnings and can take resolutive action.

The newer FLARM devices which are based on the improved PowerFLARM technology also incorporate a very accurate ADS-B and transponder (SSR) Mode-C/S receiver. This enables all transponder equipped aircraft to be included in the collision prediction algorithm and is especially valuable when flying in controlled airspace.

In addition to issuing collision warnings, many displays also show nearby aircraft on a radar screen. This helps pilots to “see and avoid”, before a collision warning becomes necessary.

so to me .. only an INTRUDING aircraft generates an output to the display.. likely due to the simplicity of the display types and the design philosophy of not making flarm a heads down device but to keep the user outside until their is a collision potential...

[duecedriver]

not like you can plot traffic on this...

http://www.lxavionics.co.uk/images/small-flarm-mouse-display.jpg

perhaps and its a big perhaps.. since I believe that the flarm position sent by the flarm box is all RELATIVE position.. it wouldn't even work on this.. unless you make it realative to your own position either as stated above.. gps on the stratux.. or perhaps if there is a gps out on the flarm box.. some way to capture that...

thought about taking the stream from the flarm box into stratux to act as the nmea mux but that won't work because I believe the only output from the flarm is only when there is an intruder traffic to report.. so if you had an ads-b target to roll in, nothing would be coming from the flarm.. no regular position update or anything so no location to compare...

it would almost certainly require a stratux gps position source.. and it (stratux) would have to calculate a proximity just like a flarm box and decide to send out only traffic within a set relative distance..with an alarm type/level

in my opinion

[ASW27B]

Flarm outputs alarms for warning of collision threats as well as passing traffic absolute position and altitude regardless of collision threat (which I believe is the standard NMEA sentences). There are very simple Flarm collision warning displays that just show alarms and rough relative altitude and direction for the threat target. There are also more sophisticated moving map displays that show all traffic. Some of those displays do audio traffic alerts for any target that gets within 1sm and 1000' - which is different from the more sophisticated "you are on a collision course" Flarm alarms. This ask is about just sending the traffic data to a moving map display, not about collision alarms - just to keep it simple. I think the GPRMC and GPGGA sentences are all you need to display traffic.

[duecedriver]

I just read that powerflarm has ads-b and mode c abilities build in or as add ons..

flarm being an active traffic (TCAS) like device that warns only of a hazard vs ADS-B stratux which is a show everything surveillance type code.. this is taking a 9g turn from easy town...

in my opinion it would be a total re-write of what stratux does and how it does it....

my opinion...

perhaps this would be a better place for the op to look into...?

http://wiki.glidernet.org

[duecedriver]

@ASW27B right.. but WHERE IS THE LOGIC DONE on plotting, alarming, etc..

does the display have the smarts or is it the output of the powerflarm telling the display what, where, and how to display it..

the display would have to parse the contents of those 2 sentences.. and the stratux would have to fully populate them in order to be properly plotted.. assuming that the language and message structure is the same regardless of what kind of flarm display one has....

[ASW27B]

Moving map displays like LX Nav's LX 9000 plot targets based on NMEA sentences. It also does some simple traffic proximity alerts though I don't know if it does this off of relative position and altitude calculated by Flarm or on its own. Flarm passes special $PFXXX sentences for collision alarms. I'm not asking for Stratux to replicate every Flarm feature. Flarm is just the one device that can send NMEA traffic over serial in a way that a moving map display can plot it. Aside from sending traffic data in a readable serial NMEA format I'm not asking to implement any of the rest of the Flarm dataport.

[ASW27B]

The LX LED display you linked to is the original Flarm display format for collision warnings only. Here is one of the moving map displays that displays traffic (Flarm and 1090ES).

http://www.lxnav.com/products/lx9000.html

[ASW27B]

Here's a video of two glider displays in action. The upper one is just traffic. The lower one is a full moving map display with traffic overlaid and several minutes of track history for each target. The display does all of that work itself off of simple NMEA traffic position sentences.

https://www.youtube.com/watch?list=PLH8uYt3fuY9Gml7Cj5uhgAcE0RYVunYue&v=ID3sw4SL5xw

[duecedriver]

just to keep it simple. I think the GPRMC and GPGGA sentences are all you need to display traffic.

GPRMC - NMEA minimum recommended GPS navigation data

GPGGA - NMEA GPS 3D-fix data

so no data there for traffic targets.. just position information and both I believe are sent at 1hz

you would need the PFLAA for something to plot

PFLAA - Data on other proximate aircraft Syntax: PFLAA,,,, ,,,,,, ,

the details for this sentence are in the spec that I posted above so you can read the populated values for yourself.. this is where it might get interesting depending on how fault tolerant the display is to missing info since it would be hard to say if stratux can do them all...

one thing I did notice and I hope I am not the only one.. but the dude that pulled the pin on the grenade and rolled it into the room, you know the guy getting paid by the requester, left the building 2 days ago....

[ssokol]

one thing I did notice and I hope I am not the only one.. but the dude that pulled the pin on the grenade and rolled it into the room left the building 2 days ago....

If you're referring to me, I'm tied up with the day job right now. I'm also a noob at Go. I could possibly hack in NMEA-out, but it would need to be reviewed and revised by pros. Should have more time for coding next week.

Steven Sokol 408 Camelot Drive Liberty, MO 64068

mobile: +1 816-806-8844 fax: +1 816-817-0441

[ASW27B]

I've sent a link to this thread to a glider friend who rewrote most of the Flarm firmware when they added 1090 ES In and also wrote the code for one of the more popular glide computers. Apparently it's just a couple of sentences you need to forward.

Stand by...

[duecedriver]

yeah.. like the 3 above... problem is populating them with flirm (TCAS) type info...

looks like some of the flarm type fields could be hard coded for choices that won't matter..

but it looks as if stratux would have to have a gps in order to calc target lateral and vertical offset, track etc...

[ASW27B]

I'm not sure but I don't think you need all the relative position stuff to display traffic. Doing the TCAS-like stuff is optional (more likely ill-advised) in my view.

If you wanted to calculate a simple proximity puck to generate a warning for traffic that would require onboard GPS. FlightBox (Steve's Kickstarter project that got this discussion started) has that I believe. The Flarm collision alarms are generally reserved for targets you are on a path to hit writhin 10-15 seconds or less. You probably don't want to set the urgent alarm off unless it's truly urgent or it will be on constantly. It's very hard to keep the collision alarm quiet in a thermal with 20 gliders within a thousand feet of each other - you have to do a lot of path extrapolating. Therefore, I think replicating the Flarm collision prediction-estimation algorithm is out of scope.

As I said before, I believe some of the glide computer/displays do some sort of proximity calculation off the raw position data for your glider versus any traffic and gives a synthetic voice warning of any traffic within a mile and a thousand feet vertically. I'll ask them how they do that.

Andy

[duecedriver]

if all you want is a map with traffic on it.. feed stratux straight to a EFB device and call it a day..

but the research that I have done today point at flarm working far differently than you think it does.. you cant just feed it the targets lat long and it will show up on a flarm device ..

if you can show me in a design spec where I am wrong have at it.. but the 2 sentences you ref above only give you current position and nothing else.. the third nmea sentence that I showed you is the flarm traffic message and its based on offsets from your position...

[ASW27B]

I'll get the details.

[DRNadler]

There's a bit of confusion here and Andy asked me to help. Pardon if some of this is redundant but I hope it gets everyone on the same page.

First, some background, without which none of this makes sense. The application is for gliders, which often fly hundreds of miles each flight, and are typically equipped with, among other things:

• FLARM traffic and collision-warning system
• a flight computer which displays a moving map with traffic (from FLARM-format input)
• often, transponders

To summarize the FLARM traffic and collision-warning system:

• basic FLARM uses proprietary radio system to broadcast position and hear other's positions
• PowerFLARM adds 1090 ADSB-in plus PCAS for transponders
• closing in on 30,000 units flying worldwide, >1k and growing in North America (all PowerFLARM).
• outputs NMEA-183 data-stream to the flight computer
• messages include collision warning and general traffic info (in addition to myriad other stuff)
• dozens of makes of flight computers know how to process and display FLARM-format info
• PowerFLARM usually does not include a display (relies on external products)

Andy's objective: Get traffic information not already provided by FLARM onto flight computer's moving map (UAT, TIS-B).

Stratux suggestion:

• produce FLARM-format traffic sentences so flight computers can display additional traffic
• Stratux-produced NMEA-datastream will be externally merged with FLARM's for flight computer
• DO NOT try to replicate collision avoidance (PFLAU sentence)
• the ONLY relevant sentence is: "PFLAA - Data on other proximate aircraft"
• because PFLAA sentence uses relative position, it is necessary to know current position
• current position is output by FLARM (GPRMC), or add a local GPS to RPi

Hope that helps! Best Regards, Dave

[duecedriver]

@DRNadler

Can I assume you have read my posts above before you posted yours?

otherwise... thanks for the flarm sales pitch... now down to specifics..

your last sentence about outputting a flarm PFLAA sentence, as I mentioned above.. is the only way to inject traffic.. and you say not to include collision avoidance.. i figured that...

however PFLAA contains in its message format, per the formal spec.. for alarm and other flarm 'stuff'... can they be left blank or filled with generics..

also, where is the logic done for collision alarm.. in the display or the powerflarm box.. i.e... the OP wants to take the nmea from a flarm box and mux them with stratux flarm output sentences and sent to the display from the mux.. great.. easy.. however does/can the display use that data for collision alarm or will it be display only since the alarm type seems to be generated upstream at the flarm box.. and it will never see the output of the stratux since its going directly to the display via mux box...

the stratux will need to have a gps to do the proximity calcs in order to fill in those sentence fields since it will not see the messages from the flarm on its current location unless the mux is bi-directional..

[ASW27B]

Just to clarify - Dave wrote or re-wrote a lot of the Flarm code and has been the primary developer on a couple of glide computers so he is one of the most knowledgeable people on the planet on this topic, which is why I asked him to weigh in. Let me try to help bring this to a common understanding of what would need to be done.

your last sentence about outputting a flarm PFLAA sentence, as I mentioned above.. is the only way to inject traffic.. and you say not to include collision avoidance.. i figured that...

Yes - for UAT traffic the Flarm alarms (which are optimized mostly for close-in glider-to-glider threats) aren't really all that suitable. In addition, there is no practical way to replicate the Flarm collision algorithm, which is fairly complex because of the glider-glider scenario - Nor is there a way feed UAT targets into the Flarm. We should consider both of these paths closed and just stick with injecting UAT traffic for display.

however PFLAA contains in its message format, per the formal spec.. for alarm and other flarm 'stuff'... can they be left blank or filled with generics..

Leave them blank I believe.

also, where is the logic done for collision alarm.. in the display or the powerflarm box.. i.e... the OP wants to take the nmea from a flarm box and mux them with stratux flarm output sentences and sent to the display from the mux.. great.. easy.. however does/can the display use that data for collision alarm or will it be display only since the alarm type seems to be generated upstream at the flarm box.. and it will never see the output of the stratux since its going directly to the display via mux box...

Correct - per the above comment, the Flarm collision algorithm will never see the Stratux traffic which will will go straight to the display along with the Muxed traffic from Flarm. Therefore the NMEA traffic from Stratux will not be carrying any of the Flarm alarm sentences. At some point in the future it might be an interesting project to try to generate collision warning alarms based on some reasonable algorithm that filters out non-urgent threats, but it is a VERY complex task that I don't think people need right now as most UAT traffic will be GA not gliders, PLUS, there is a workaround. Some glide computer manufacturers (including the most popular ones from LXNav) look at the traffic relative position form PFLAA and provide audio alerts for targets that enter a puck with a radius of 1 sm and +/- 1000' in altitude (this is independent of any Flarm input - JUST on the traffic relative position from the PFLAA sentence). This seems sufficient for this type of traffic.

the stratux will need to have a gps to do the proximity calcs in order to fill in those sentence fields since it will not see the messages from the flarm on its current location unless the mux is bi-directional..

Yes correct - I think it is best to use the on-board GPS to get current position to do the relative position calcs rather than monkey around with bringing in the Flarm GPRMC NMEA sentence. Plus, I think making the Stratux functional as a standalone source for ADS-B traffic maximizes the potential utility to more users than making it super-dependent on getting Flarm GPS data. Not every glider in the US carries Flarm and it costs $800 without ADS-B 1090ES and $1500 with ADS-B 1090ES.

I think the right answer here is for the Stratux to output PFLAA sentences for relative position of traffic as well as the current position GPRMC sentence - both calculated off the internal GPS. This way Stratux and be used as a low-cost traffic source for gliders that have no other traffic or collision device to detect all types of traffic. Because of this use case I'd pass all traffic - UAT, 1090ES and TIS-B. You can always not install the radio for 1090ES if you want to combine with Flarm.

This would rely on logic in the display for any traffic warnings - many displays have this feature. I spoke to LXNav who is one of the leading global suppliers and they have agreed to support NMEA traffic input of this type - I believe they intend to take on de-duping, traffic warnings etc. Even if they don't it should still work fine to feed the display PFLAA and GPRMC sentences - it knows how to handle those today.

For use with Flarm it becomes a Muxing exercise. The K6Mux allows you to pass or block specific sentences so you could just pass the PFLAA sentences and block the GPRMC from Stratux if you were worried about passing two position sentences from two different GPSs (the position estimate differences are likely to be small so it ought to work either way). I'd probably block the GPRMC from Stratux if I already had one from Flarm just to avoid any potential for jitter in the position on the display.

I think this boils down to a simple exercise - create and put on the serial port all traffic using the PFLAA sentence and current position using the GPRMC sentence.

Does that make sense? What am I missing?

Andy

[cyoung]

Got what I need, thanks guys. It's on the list

[ghost]

@cyoung, @DRNadler -- Prototype: https://github.com/AvSquirrel/stratux/tree/traffic-20160129

Invoke with the -flarm flag on the command line. This version outputs the PFLAA and GPRMC messages to stratux.log; you'll need to rework it a bit to direct outout to the serial port.

Features:

• Generates a PFLAA message every second for all valid ADS-B targets if Stratux has a valid GPS lock
• Relative position (meters north, east, and vertical) is calculated for all traffic targets located within ±2^15 meters north / south / east / west of ownship position; message is flagged invalid for targets farther away. Relative vertical position is based on pressure altitudes; if a pressure transducer is not installed, GPS altitude will be substituted. This can introduce errors of hundreds of feet in nonstandard atmospheres. Current Stratux builds support Bosch BMP180 sensors connected to the I2C bus; parsing pressure altitude from FLARM PGRMZ messages would be an easy change.
• Climb rate, ground speed, track, and ICAO address are populated from Stratux ADS-B data
• Alarm levels have been prototyped; level 1 is set for traffic within 1 NM horizontally and 1000' vertically; level 2 is set for traffic within 0.5 NM horizontally and 500' vertically. These can be modified or zeroed if desired.
• A GPRMC message is generated every second based on ownship GPS position. Validity flags are set per received solution type and age of data.
• Messages are checksummed per NMEA format.
• -demo command line flag will generate three targets that circle ownship position. This option can be used to validate that traffic messages are being passed and parsed correctly.

The below (anonymized) output was extracted from stratux.log, and is what you would expect to see over a serial port once you code that in.

$PFLAA,0,11461,-9272,1436,1,AFFFFF,51,0,257,0.0,0*7A
$PFLAA,0,2784,3437,216,1,AFFFFE,141,0,77,0.0,0*56
$PFLAA,1,-1375,1113,64,1,AFFFFD,231,0,30,0.0,0*43
$PFLAA,0,-3158,3839,1390,1,A858F3,302,0,123,-12.4,0*6B
$GPRMC,084854.40,A,44xx.xxx38,N,093xx.xxx15,W,0.0,0.0,300116,,,D*43
$PFLAA,0,11621,-9071,1437,1,AFFFFF,52,0,257,0.0,0*7F
$PFLAA,0,2724,3485,218,1,AFFFFE,142,0,77,0.0,0*58
$PFLAA,1,-1394,1089,65,1,AFFFFD,232,0,30,0.0,0*4C
$PFLAA,0,-3158,3839,1384,1,A858F3,302,0,123,-12.4,0*6E
$GPRMC,084855.40,A,44xx.xxx38,N,093xx.xxx15,W,0.0,0.0,300116,,,D*42

[ASW27B]

Nice work! (fast too).

I just got a RPi, but none of the other parts - was waiting for FlightBox to ship, but I might have to get some components. I'm totally new to RPi so I'll need how to figure a bunch of stuff out before I can test anything. That and serial port output.

I know you just prototyped the alarms - I'm curious to see how it behaves. It's my understanding that Flarm calculates projected paths for ownship and receives projected paths for all Flarm targets and only issues an alarm if the paths project to be in pretty much the same place at the same time - so it filters out a lot of proximate traffic that's not on a collision course. Consequently, the displays that process alarm sentences (PFLAU?) make very loud and continuous wailing noises and flashing target direction indictions to really grab your attention - because alarms indicate a collision threat that's very serious - without evasive action you WILL be hitting someone. You probably don't want that level of hysteria for proximity alone, but getting fancier is a very challenging task. Should be interesting to play with and, as you said, you can always zero the alarms out if it's too annoying too much of the time.

Some of the more sophisticated glider computer/Flarm displays do their own proximity calculations and give you a single voice warning when any target first crosses into a 1mi/1000' proximity puck, but that's not generated by Flarm.

I'm curious if any of the EFB apps do proximity or collision warnings of any kind. Seems like a useful feature.

[zendesigner01]

HI,

I'm also a glider pilot looking for exactly the same thing when i found the stratux device today. We use Flarm as our main traffic collision system, but it does not warn for motorized planes and heavy metal (airbus etc..)

There is already a commercial system available for ADSB IN - translationg towards EMEA stream and flarm output. But it costs around 900€.

So if we can replace this by a raspberry PI we are sure intrested. Let me know if i can be of any help.

i have a flight computer, flarm and K6mux setup already today. Will figure out what to order to test the Stratux setup.

Bart

[DRNadler]

Bart, PowerFLARM has ADSB-In 1090 option including transponder warning (PCAS). Not the "pure" model. Outside of USA that gets you all you are looking for. Have a look at the FLARM site... Hope that helps, Best Regards, Dave

PS: Do not confuse USA-specific solutions with ADS-B in Europe...

On 2/4/2016 5:44 AM, zendesigner01 wrote:

HI,

I'm also a glider pilot looking for exactly the same thing when i found the stratux device today. We use Flarm as our main traffic collision system, but it does not warn for motorized planes and heavy metal (airbus etc..)

There is already a commercial system available for ADSB IN - translationg towards EMEA stream and flarm output. But it costs around 900€.

So if we can replace this by a raspberry PI we are sure intrested. Let me know if i can be of any help.

Bart

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/218#issuecomment-179764577.

Dave Nadler, USA East Coast voice (978) 263-0097, drn@nadler.com, Skype Dave.Nadler1

[zendesigner01]

hi Dave

thanks i know , but i already have a normal flarm, flight computer and transponder with ADSB out in my glider.

So i think replacing my existing flarm for a powerflarm might set me back a huge cost as well. the powerflarm is 1600€ purchase price.

I maybe should have mentioned that i'm from Europe Belgium. Does your comment mean that the Stratux setup would not work in europe ?

Bart

ps: i found a link for programming the rasp for serial output (towards the K6mux) http://www.instructables.com/id/Read-and-write-from-serial-port-with-Raspberry-Pi/

[zendesigner01]

hi Dave, all,

Let me first explain my intrest.

I'm looking for a cheaper device then the commercial ones available to deliver ADSB-In traffic over an NMEA stream on a serial connection, containg sentences towards my K6mux nmea combiner where i will filter out only PFLAA/U sentences.

This will be inputted into my SEEYOU navigation software to display Traffic on a moving map. Secondarely if seeyou could alert for it same as it does for the flarm stream that would be great.

I ordered the raspberry pi 2 and the dongle , so will be able to test in a week or two.

Bart