FLARM NMEA UDP and TCP prototype

[ghost]

This is a functional prototype for output of FLARM-formatted NMEA position, traffic, and status messages over TCP and UDP. The intent is to translate ADS-B / TIS-B position into a format than can be understood by glider computers and UK/EU-oriented EFB software. Ref previous issues #218 and #475.

Code:
https://github.com/AvSquirrel/stratux/tree/flarm-network

Description: Once per second, the following NMEA sentences are generated by new code in traffic.go:

• One GPRMC (GPS "recommended minimum") position message, synthesized from mySituation data
• One PFLAA (FLARM data on proximate aircraft) message for each nearby target with known position.
• One PFLAU status / priority message, indicating number of aircraft tracked.

These messages are passed to a new message handler (sendNetFLARM()), which in turn passes the messages to the existing network handler for port 10110 UDP output (if enabled in the UI) and to a new port 2000 TCP handler. The latter is needed to support software that uses Butterfly Connect / AIR Connect hardware.

Also included in the most recent build are four demo traffic targets that circulate around your current GPS position, useful for validation / troubleshooting.

Hardware requirements 1-2 SDRs, and a GPS. Most non-US users will prefer to use a single SDR for 1090 MHz mode S ADS-B. GPS is required because FLARM traffic messages are based on relative position.

Setup and use instructions To build from source, clone my repository or add as a remote, checkout the network-flarm branch, and make / make install. Or, wait until I post a compiled .sh build of 1b1024d later today.

XCSoar works fine with the default Stratux network settings. Enable "FLARM NMEA over UDP" in the Stratux UI. Dive down into the XCSoar devices menu, and add new device (UDP connection, port 10110, and FLARM format).

RunwayHD is an easy setup as well. In the FLARM device option, select AIR Connect hardware, 192.168.10.1, port 2000, and any 4-digit code for the password.

SkyDemon is more fiddly, since you can't specify port / IP settings, and it's hardwired to look at 192.168.1.1. This means changing network settings on your Stratux (/etc/network/interfaces and /etc/dhcp/dhcpd.conf) to point to the 192.168.1.1 address and 192.168.1.x network. Once that's done and you reboot, you should be able to use 6000 as a passcode and get it to connect. I was able to get it to show position in my testing but not traffic on iOS 10.0.1.

Other known issues / future improvements Bearingless traffic for non-ADS-B mode S isn't currently supported. Too much variation in antennas, gain settings, dongles, etc, between users to have one setting that will work for everyone. It might be possible to add an auto-calibration feature.

[cyoung]

1. When synthesizing the GPRMC message you'll probably want to use the mutex on mySituation (or at least make a local copy).
2. How are these apps handling port 10110 wrt sleep mode detection? If well-behaved, we don't need globalSettings.NetworkFLARM. Additionally, the port 2000 listener is pretty much zero cost unless someone is using it, so it can be default on.
3. Creating a general listener type "network output" might be interesting. I wonder if there are any other uses for this.

[ghost]

.sh update file for the most recent build (1b1024d): (Network FLARM) update-stratux-v1.0r1-1b1024de7f.sh.zip

@cyoung --

When synthesizing the GPRMC message you'll probably want to use the mutex on mySituation (or at least make a local copy).

Noted. This is a read-only function and there's nothing thread unsafe in SituationData, so I'd prefer not to do anything that could be a potential block. Local copy should be sufficient.

How are these apps handling port 10110 wrt sleep mode detection?

I haven't tested enough to see if they're well behaved. :-) My concerns were more about unforeseen interactions with other EFBs (e.g. what happens if I start slinging 10110 UDP packets at ForeFlight or FlyQ) and overall load on the WiFi adapter. 10110 is the IANA assigned port for NMEA-0183, so it's possible that some apps could be listening for position data, and I don't know what would happen if they saw both GPRMC on 10110 and GDL90 ownship position on 4000.

Additionally, the port 2000 listener is pretty much zero cost unless someone is using it, so it can be default on.

taps nose. You'll notice that globalSettings.NetworkFLARM doesn't disable the listener.

Creating a general listener type "network output" might be interesting. I wonder if there are any other uses for this.

It's a natural interface for a plug-in architecture, isn't it? Might be a nice way to provide data for some of the "nice to have" improvements that have been floated but are too large / esoteric to be part of the core project.

[cyoung]

At one point we had three ports set up by default. The X-Plane simulator data port was disabled since it stopped working in FF. GDL90 output port 43211 was disabled because all of the straggler EFBs got onto port 4000. FF and most others won't be affected, Stratux will just process ICMP_DEST_UNREACH for port 10110 and shut it down. The reverse is probably more of a concern - do any of these apps listen on port 4000? In any case, we could refactor some of this to improve on the network handling - mutual exclusion on ports and/or the listener.

[ghost]

@cyoung --

I ran a test where I disabled port 4000, and then observed the reaction in five different EFBs. The GPRMC sentence is part of the FLARM-style serial / WiFi data stream, so any 10110-aware applications should have identified Stratux as external GPS.

ForeFlight, FlyQ, WingX, and FltPlan Go (Android) all ignored it. Avare, through the Avare I/O handler, can be made to manually connect to 10110, but that would not occur in normal use (user has to manually set the correct port).

Port 4000 on the other applications (RunwayHD, SkyDemon, XCSoar) isn't an issue at the moment; if they understood GDL90, there would be no need to create a FLARM-formatted output.

I've pushed a few more commits to this branch. f943e3b is the latest "stable" version for XCSoar and RunwayHD. It adds (temporary) controls to enable/disable the synthetic traffic targets, and to enable/disable both port 4000 and port 10110 output. It also resolves a persistent traffic alarm issue in RunwayHD.

The most recent commit (0075877) creates a FLARM v7.0 "bearingless" target in addition to the normal known-bearing target for each in-range ADS-B target, and will be removed from the next normal commit. This is merely a proof-of-concept to understand how the various EFBs plot bearingless range rings, and to possibly support future range estimation for non-ADS-B Mode S targets. That's a feature that will be more useful in Europe compared to North America, owing to the Eurocontrol Mode S mandate.

0075877 also adds synthesized GPGGA / GPGSA messages to allow compatibility with SkyDemon, which requires a GPS altitude message and DOP data before it will show traffic. Adding these extra messages has uncovered some message order issues with the TCP server that I need to dig into. Buffering the message channel has helped a bit, but something is still acting like a stack when several messages hit it in short order, when I want queue behavior.

To-do items:

• Debug TCP server message order
• Determine which criteria (if any) should flag alarms in the PFLAA / PFLAU sentences, and update PFLAU sentence with relative bearing / distance to nearest alarm target.
• Create regression algo to use extended squitter "GEOMETRIC HEIGHT DIFFERENCE FROM BARO. ALT" data to estimate pressure altitude from GPS height. Flight testing this weekend suggests that this could be accurate to within ±200 feet.
• Create regression algo to estimate distance to non-ADS-B Mode S targets.

[UKJohn]

Back in Late September I launched a request for help to get NMEA out and Keith (AvSquirell) helped and provided this fork for people who are using European EFB in their aeroplanes.

The last version 1b1024de7f worked in its basic form but he was working on Mode C bearingless targets and other things on the todo list.

But I have not heard from him for a month and have not seen any postings from him. Was he affected by the Hurricane perhaps - does anyone know if he is o.k ?

John

[JohnOCFII]

But I have not heard from him for a month and have not seen any postings from him. Was he affected by the Hurricane perhaps - does anyone know if he is o.k ?

I saw @AvSquirrel Tuesday. He is fit as a fiddle. I'm sure he'll chime in when he has a chance.

[ghost]

Yep. Still here. No hurricanes in the upper midwest; just lots of other projects and lots of GORGEOUS autumn weather keeping me from working on this. I really need a couple of slow work weeks with lots of freezing rain to get me to buckle down.

@UKJohn and I had been bouncing some ideas back and forth, and I got things developed to the point where it worked in SkyDemon\ in addition to RunwayHD on commit 0075877, as noted on Sept 26. This commit also added a demo / proof-of-concept for "bearingless" traffic output, as it is so noted in the FLARM NMEA protocol. My implementation created a separate traffic target for each "real" target, but with bearing data removed. EFBs that are aware of this method will show bearingless targets as distance rings, as can be seen below:

**SkyDemon is unfortunately hard-coded to specific server addresses depending on the FLARM PIN assigned. I've had the best luck using a PIN of 6000, and modifying interfaces and dhcpd.conf to point to 192.168.1.1, rather than 192.168.10.1.

The other actions from Sept 26 are still open:

• Create regression algo to use extended squitter "GEOMETRIC HEIGHT DIFFERENCE FROM BARO. ALT" data to estimate pressure altitude from GPS height. Flight testing this weekend suggests that this could be accurate to within ±200 feet.

This is that test data. All but a handful of hits had residuals of less than ±200 feet.

• Create regression algo to estimate distance to non-ADS-B Mode S targets.

I was able to collect a ton of RSSI vs distance data a couple weekends ago in a well-controlled experiment. The PDF below outlines my methods.

Stratux RSSI vs Distance Analysis 2016-10-09.pdf

Using an outdoor 1090 MHz antenna located on the grounds of a towered airport nearest to a major international golf tournament three weeks ago, I collected / logged RSSI, distance, bearing, and altitude data for all ADS-B position messages received for at least an hour, and for as much as four hours, for each of five dump1090 gain settings. I used a modified (uncommitted) version of commit 0075877 that logged all DF17 position messages to a new sqlite table, in addition to the once-per-second traffic updates.

This testing showed that, although RSSI can vary by 10-15 dB at any given distance for any given airplane, there seems to be a hard upper bound of RSSI versus distance, proportional to -5*log2(distance). In other words, double the distance, and RSSI decreases by 5. Moreover, traffic closer than a certain threshold (dependent on antenna and software gain setting) will never have an RSSI greater than about -1. With the default gain setting, all traffic closer than about 3-4 nautical miles has a peak RSSI of -2 to -1. Reducing software gain decreased this threshold (i.e. with gain reduced by 30 dB, RSSI varied with distance for traffic more than 0.16 NM away) but maximum range was also reduced.

The long and short of this is that there should exist a dump1090 gain setting for each antenna / SDR combination that will allow discrimination of distance down to about 0.5-1 NM, and give a total usable range of 30-60 NM. This assumes that I can capture enough data points for each airplane to get a good indication of peak RSSI over some relatively short timeframe, and only feed those values into the algo. Depending on how consistent this is for "common" Stratux antenna combinations (e.g. Nooelec Mini2 or Nano2 with telescoping antennas or dmurray high gain antennas), I might be able to do this with a fixed distance offset -- it would save the complexity of needing to build a regression against ADS-B traffic.

[Axtel4]

The charts look like they were created by JMP.

[UKJohn]

They look similar to the base maps for RunwayHD and Skydemon that we have in the UK. The use of port 6000 is correct for skydemon and it seems to be a way that another ADSB decoding and Flarm system in the U.K called piltoaware , allows for the way different EFB's display traffic esp bearingless mode c and s traffic. I think the RunwayHD EFB is the better EFB to use for testing as there are some peculiarities with Skydemon (the hard coded IP is one example)

When you have a version to trial for bearingless returns I would be happy to test Keith. I also have done some RSSI v distance measurements and aircraft that coud be a threat seem to be in the -2 - 5 range of RSSI measurement, but the displayed RSSI on the WebUI does seem to range wildly, is this a feature of the 1090 hardware or dump1090. I think to cater for different installations of Stratux and aerial positioning you could offer a "sensitivity" option on the WebUI to alter the signal strength RSSI value that will cause an alert on the EFB screen.

[tklenke]

Did you guys finish this (NMEA output on UDP) off? Looks like maybe it's still a work in progress?

[UKJohn]

There is a version that Keith (AvSquirrel) built for me to test with U.K EFB's and I have been running this for some weeks with no real issues, but there is some work to do on warnings for close aircraft threats and also Keith was doing some work on detecting Mode S and Mode C returns to calculate and give warnings about bearingless targets.

John

On 09/12/2016 06:21, tklenke wrote:

Did you guys finish this (NMEA output on UDP) off? Looks like maybe it's still a work in progress?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/489#issuecomment-265942766, or mute the thread https://github.com/notifications/unsubscribe-auth/AVx5Tr_f5fVjbkzl4ESGEP31kx4Qvmlkks5rGPNqgaJpZM4KCxS5.

[tklenke]

Thanks John,

I'd like to use it with XCSoar here in the States. Sounds like this is coming but not ready for prime time. I'll keep watching for it!

Keith or Cyoung, if you need a tester I'd be happy to help. I've done a fair amount of software development, including Linux, but haven't yet started climbing the Rasberry Pi learning curve.

Tom

On Fri, Dec 9, 2016 at 1:40 AM, UKJohn notifications@github.com wrote:

There is a version that Keith (AvSquirrel) built for me to test with U.K EFB's and I have been running this for some weeks with no real issues, but there is some work to do on warnings for close aircraft threats and also Keith was doing some work on detecting Mode S and Mode C returns to calculate and give warnings about bearingless targets.

John

On 09/12/2016 06:21, tklenke wrote:

Did you guys finish this (NMEA output on UDP) off? Looks like maybe it's still a work in progress?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/489#issuecomment-265942766, or mute the thread https://github.com/notifications/unsubscribe-auth/AVx5Tr_ f5fVjbkzl4ESGEP31kx4Qvmlkks5rGPNqgaJpZM4KCxS5.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/489#issuecomment-265972802, or mute the thread https://github.com/notifications/unsubscribe-auth/AASU0r1Ml9u0TBIdHuuSH6jMbzMXSdWiks5rGSIfgaJpZM4KCxS5 .

-- Thomas Klenke 1899 Rolling Brook Ct Reno, NV 89519 v: 775-393-9611

[JS1CG]

NMEA UDP worked great with XCSoar on my test; seemed to run much smoother than the previous build. Any perspective on possible advantages/disadvantages to porting the NMEA data through the GPIO header vs the USB port?

[soarak]

JS1CG, did you use a USB to serial converter? What is your hardware configuration?

[JS1CG]

Good morning,

I have an rPi3 with remote dual 1/2 wave (1090es, 978UAT) antennas, remote GPS puck plugged into the top center USB port on the rPi, a powered USB hub plugged into the top right USB port on the rPi with an OFS USB-serial cable, generic mouse, and keyboard plugged into the powered USB hub. I have an AC adapter powering the rPi, and an HDMI monitor to follow along and exit gracefully from the program so I don't brick the rPi.

I erased then flashed a SanDisk USB card with the image (Stratux-v1.0r1-945c8bf6bc.img), fired up the Stratux, went to the Settings page in the UI, and updated the SD card with AvSquirrel's FLARM Serial Output update (Update-Stratux-v0.8r1-c306bf6f74.sh). I'm connecting the OFS USB-serial cable from the powered hub thru a RJ45-DB9 adapter to a QVS USB serial convertor to my MacBook USB port (Com4, 38400, 8 data, 1 parity, no stop, no flow control). I have a Windows Bootcamp on my Mac, and am running a desktop version of XCSoar. This worked OK, but was better when I flashed another SD card with the UDP build (Network FLARM update-stratux-v1.0r1-1b1024de7f.sh), enabled FLARM NMEA over UDP on the Stratux UI, and UDP port 10110/Flarm format in XCSoar.

Unfortunately, I won't be able to use UDP for my real-life application. My goal is to mux ADS-B and FLARM output together, and port the data to an LX9000, an EFIS that accepts/displays NMEA in FLARM format, but doesn't support UDP. I wonder if the GPIO might be neater from a connectivity standpoint than USB, although that would probably still require a TTL level convertor. Not sure how baud rates are handled with the GPIO. I've just started playing with the rPi and have very little programming experience. I've been in contact with Andy Blackburn, who had been trying to do the same without luck, though I think he may have cabling issues.

Thanks for all the great work! It's amazing what you're able to accomplish on github.

Charlie

On Tue, Jan 31, 2017 at 5:40 AM, soarak notifications@github.com wrote:

JS1CG, did you use a USB to serial converter? What is your hardware configuration?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/489#issuecomment-276352963, or mute the thread https://github.com/notifications/unsubscribe-auth/AXP3E4pHomwvRz7fElmd8XYupsMYXWj1ks5rXyutgaJpZM4KCxS5 .

[soarak]

Charlie, I have the same goal. I would like to display the traffic on an LX9000 or on a FlarmView. All gliding EFIS accept Flarm format over serial connection. I thought that AvSquirrel made the Flarm formatted traffic sentences available through usb-serial converter. My impression was from reading another request that the code was working with the exception of port conflict between GPS and USB-Serial converter that needed to be resolved. I might have missed something. I guess I got excited too early. I don't know enough about rPi to know if a serial connection can be established to send Flarm sentences out.

This solution could be awesome not only for glider pilots but also for other pilots. FlarmView display costs $250 and it is very good in direct sunlight, a perfect screen for traffic awareness and small enough to be positioned on a glare shield of any airplane.

[JS1CG]

I think there is a conflict between the USB-serial cable and GPS puck when both are plugged directly into USB ports on the rPi. I was not able to see any GPS position data ($GPRMC) on the XCSoar Terminal monitor in this configuration, despite the GPS working on the Stratux UI. After plugging the USB-serial cable into a powered USB hub (leaving the GPS plugged into the rPi), I could see both GPS and FLARM ($PFLAA) data on the Terminal, and the simulation worked, including the dozens of aircraft swirling around my position. As I won't have a powered USB hub in the cockpit, I'm interested in porting the NMEA data out the GPIO potentially.

[soarak]

I just spent a few minutes reading about a serial port in rPi. Your suggestion is probably the best solution, although I think, resolving the conflict is possible. What GPS are you using? I think some values were hard coded based on another thread, if I remember correctly. I hope @AvSquirrel will return here when he has some time and clarifies this. Thank you in advance.

[JS1CG]

I have a remote GPS puck with a 5ft cable that plugs into a USB port. I got it from Open Flight Solutions (50 channel WAAS/EGNOS); I have to check the make/model when I get home.

[soarak]

From another thread. I think, the auto-detection of the third GPS was probably not disabled.

"the FLARM demo code from a few weeks ago is re-integrated into my development branch. I'm ready to add the serial output part of it, and get update files ready for you this weekend, but I need to confirm which GPS and serial hardware you're using. You said:

RS-232: 'p12303 converter now attached to ttyUSB0' GPS: 'the recommended GPS board' Is the the GPS the RY835AI or VK-172? Either of those GPS modules will work fine with what I've put together; I'll just have disable autodetection of a third GPS (BU-353) that's been supported in recent builds, since it defaults to using the same port as your RS-232 adapter."

[JS1CG]

My GPS puck has a generic G-mouse sticker on it which I think is third party marketing and not useful. When I step through the loading of the Stratux UDP program, it reports detection of a U-blox 7 GPS/GNSS Receiver, which is the GPS chip manufacturer, though they make a few chips in the U-blox 7 line, so I'm not sure of the specific chip in my GPS.

On Tue, Jan 31, 2017 at 4:29 PM, soarak notifications@github.com wrote:

From another thread. I think, the auto-detection of the third GPS was probably not disabled.

"the FLARM demo code from a few weeks ago is re-integrated into my development branch. I'm ready to add the serial output part of it, and get update files ready for you this weekend, but I need to confirm which GPS and serial hardware you're using. You said:

RS-232: 'p12303 converter now attached to ttyUSB0' GPS: 'the recommended GPS board' Is the the GPS the RY835AI or VK-172? Either of those GPS modules will work fine with what I've put together; I'll just have disable autodetection of a third GPS (BU-353) that's been supported in recent builds, since it defaults to using the same port as your RS-232 adapter."

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/489#issuecomment-276527560, or mute the thread https://github.com/notifications/unsubscribe-auth/AXP3E0fOpggZM7nofkgzo0EvonsHGSzWks5rX8P0gaJpZM4KCxS5 .

[soarak]

JS1CG please read this: https://www.reddit.com/r/stratux/comments/5ptdbw/rs232_output/?st=iymzsz4r&sh=8afcffe5

Especially notes related to "Stratux Serialout" Can you send me a message to my email account listed in github.

[JS1CG]

On another related note, I've been trying to port AVSquirrel's original FLARM NMEA build (Update-Stratux-v0.8r1-c306bf6f74.sh) to a Naviter Oudie device, and, although I'm seeing the $GPRMC and $PFLAA sentences on the devices' Terminal program, no traffic is appearing on the map. Based on a previous comment, I wonder if this device also needs $GPGGA, $GPGSA sentences for traffic to display, similar to AVSquirrel's observation for SkyDemon:

0075877 https://github.com/cyoung/stratux/commit/0075877273bdcba9c1f48b260546ab2e2b8e89d8 also adds synthesized GPGGA / GPGSA messages to allow compatibility with SkyDemon, which requires a GPS altitude message and DOP data before it will show traffic.

Is there a build that outputs these additional sentences that I can try on the Oudie?

On Wed, Feb 1, 2017 at 8:02 AM, charles gillespie gillescpg@gmail.com wrote:

My GPS puck has a generic G-mouse sticker on it which I think is third party marketing and not useful. When I step through the loading of the Stratux UDP program, it reports detection of a U-blox 7 GPS/GNSS Receiver, which is the GPS chip manufacturer, though they make a few chips in the U-blox 7 line, so I'm not sure of the specific chip in my GPS.

On Tue, Jan 31, 2017 at 4:29 PM, soarak notifications@github.com wrote:

From another thread. I think, the auto-detection of the third GPS was probably not disabled.

"the FLARM demo code from a few weeks ago is re-integrated into my development branch. I'm ready to add the serial output part of it, and get update files ready for you this weekend, but I need to confirm which GPS and serial hardware you're using. You said:

RS-232: 'p12303 converter now attached to ttyUSB0' GPS: 'the recommended GPS board' Is the the GPS the RY835AI or VK-172? Either of those GPS modules will work fine with what I've put together; I'll just have disable autodetection of a third GPS (BU-353) that's been supported in recent builds, since it defaults to using the same port as your RS-232 adapter."

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/489#issuecomment-276527560, or mute the thread https://github.com/notifications/unsubscribe-auth/AXP3E0fOpggZM7nofkgzo0EvonsHGSzWks5rX8P0gaJpZM4KCxS5 .

[tklenke]

Sorry if this is a stupid question. Is this (AVSquirrel's) version outputting the serial NMEA data to the USB serial port only, or is it also sending the serial data via UDP (or TCP) over the Stratux defined wifi connection? i.e. what are the physical connection options for AVSquirrel's version? USB-Serial only or maybe WiFi or GPIO?

If it's spitting out NMEA data on the wifi or GPIO connection then I think I can get the data into XCSoar for Android, which would be awesome for me.

[JS1CG]

Both of these versions port data through the USB port. The first version transmits data in the RS232 format from the rPi USB port, through a USB-to-serial cable to a COMM port on a computer/device. The second version transmits data in the UDP format from the rPi USB port, through a USB-to-serial cable to a computer/device with UDP 10110-port capability. UDP and TCP are both Ethernet protocols, that are evidently more common in UK/EU EFB software. TCP is a transmission protocol which requires hand-shaking; UDP does not. So, UDP is faster, but less accurate than TCP, which might not be a bad trade-off in frequently transmitted, relatively slow-to-change info, like aircraft position reports. To the point, you need NMEA out for XCSoar, but neither of these versions ports NMEA data by WIFI or GPIO at present.

[UKJohn]

I am running the Avsquirrel version and can confirm it spits out Flarm format data via the Wi-Fi and works with XCsoar, Skydemon, RunwayHD and other Android and Ios electronic flight books.

John

On 02/02/2017 01:08, tklenke wrote:

Sorry if this is a stupid question. Is this (AVSquirrel's) version outputting the serial NMEA data to the USB serial port only, or is it also sending the serial data via UDP (or TCP) over the Stratux defined wifi connection? i.e. what are the physical connection options for AVSquirrel's version? USB-Serial only or maybe WiFi or GPIO?

If it's spitting out NMEA data on the wifi or GPIO connection then I think I can get the data into XCSoar for Android, which would be awesome for me.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/489#issuecomment-276835271, or mute the thread https://github.com/notifications/unsubscribe-auth/AVx5TtKkoBfJqWW-KWOsOZXWIEHLj-gIks5rYSyEgaJpZM4KCxS5.

[JS1CG]

Interesting. I'll play a bit more to see if I can get XCSoar to work wirelessly over UDP. I didn't realize that you could set the baud rate on the XCSoar with the Manage button. I'm surprised it worked with my serial cable.

[ghost]

See latest comment on #571.

I posted a revised version of my September commits (and a .sh upgrade file), with support for UDP, TCP, and USB-to-serial adapters, but rebased on latest v1.2+ Stratux code. Verified against XCSoar, but may need some tweaking to get the correct alert levels.

[JS1CG]

On Tue, Mar 7, 2017 at 11:06 PM Keith Tschohl notifications@github.com wrote:

See latest comment on #571 https://github.com/cyoung/stratux/issues/571.

I posted a revised version of my September commits (and a .sh upgrade file), with support for UDP, TCP, and USB-to-serial adapters, but rebased on latest v1.2+ Stratux code. Verified against XCSoar, but may need some tweaking to get the correct alert levels.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/489#issuecomment-284955683, or mute the thread https://github.com/notifications/unsubscribe-auth/AXP3E4zyx2XelZeScdLUTwGPPCLY2J8fks5rjkVGgaJpZM4KCxS5 .

Fantastic! I'm imaging an SD card with v1.21 now (base and FLARM update). I'll let you know how it goes.

Charlie

[UKJohn]

Can I use the update facility if my existing SD card has "update-stratux-v1.0r1-1b1024de7f.sh" or do I have to make a fresh download of the base 1.2 and then use Keiths update.sh file ?

Thankyou

John

On 08/03/2017 14:52, JS1CG wrote:

On Tue, Mar 7, 2017 at 11:06 PM Keith Tschohl notifications@github.com wrote:

See latest comment on #571 https://github.com/cyoung/stratux/issues/571.

I posted a revised version of my September commits (and a .sh upgrade file), with support for UDP, TCP, and USB-to-serial adapters, but rebased on latest v1.2+ Stratux code. Verified against XCSoar, but may need some tweaking to get the correct alert levels.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub

https://github.com/cyoung/stratux/issues/489#issuecomment-284955683, or mute the thread

https://github.com/notifications/unsubscribe-auth/AXP3E4zyx2XelZeScdLUTwGPPCLY2J8fks5rjkVGgaJpZM4KCxS5 .

Fantastic! I'm imaging an SD card with v1.21 now (base and FLARM update). I'll let you know how it goes.

Charlie

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/489#issuecomment-285061521, or mute the thread https://github.com/notifications/unsubscribe-auth/AVx5TuVP4ss-zcsB2usTxtrZs1-i-1Xpks5rjsChgaJpZM4KCxS5.

[ASW27B]

@AvSquirrel, @cyoung,

Four of us from #571 have now taken the v1.2r1-1b17cb4101 release and connected it to 4 different test bench setups with various combinations of glider displays connected via USB-Serial converters that are based on compatible (mostly Prolific) chipsets. All four have been up and running for the past week or so collecting test data from the ground. Stratux connected standalone as well as Stratux MUXed with FLARM output (using the K6Mux RS-232 NMEA MUX) are showing targets as expected, and we have seen Stratux-generated collision alarms from low-flying aircraft.

We are working to set up at least one development environment to contribute to future evolution of this project. In the mean time there are a couple of tweaks that are important for further testing, if there is time available to make a few minor adjustments.

1) We’d like to add three separate on/off switches in the Stratux Web UI: ADS-R traffic, TIS-B traffic, Traffic Alarms (i.e. $PFLAA and $PFLAU “AlarmLevel” always set to 0 when the switch is set to “off"). It appears that this version of the code is generating only $PFLAA alarms, so $PFLAU "AlarmLevel" may already always be set to 0.

2) Add a Web UI user input to suppress targets with more than ’N' thousand feet of altitude separation - where ’N' is an integer the user can input. This will declutter the display.

3) For TIS-B targets, set $PFLAA “AcftType” to “E”. This is an alternate code for “unknown”. This would allow display developers to draw a “position uncertainty ring” around the reported location for TIS-B targets to indicate inherent position measurement error and latency of TIS-B traffic.

Note: We have observed multiple cases of "AcftType" codes changing mid-flight for the same aircraft. Different "AcftType" codes (especially 0, 8 and 9 which make up most of the traffic we are seeing) are depicted with different symbols on many displays, so this behavior is worth looking into.

4) Add an option in the Web UI to set the baud rate to 19.2 kbps. Some of the simple traffic displays don’t support higher baud rates.

That’s it. Thanks!

Andy, Andzerj, Charlie and John

[ASW27B]

@cyoung

You asked for protocol documentation, requested hardware support, development environments etc.

Documentation - Here is the latest Flarm data port spec.

https://drive.google.com/open?id=0Bw1ChKkWEYLNNlp2dUNyRDd0Tzg

Hardware and Development - Navigation and traffic display systems that support Flarm traffic adhere to the data port spec. Implementations are reasonably consistent with some cosmetic differences. XCSoar is the leading Open Source glider computer platform with Mac and PC simulators available and UDP support to avoid the inconvenience making serial connections to hardware for development testing. (Note: This UDP connection feature is somewhat unique to XCSoar and a few other Android apps, mentioned above. The vast majority of glider instruments still connect exclusively via RS-232). https://www.xcsoar.org.

The most popular commercial product is the Naviter Oudie series. The Oudie is a full-featured navigation display with Flarm traffic and collision alarm support. These are very widely deployed in gliders and the Oudie is also used by hang gliders and paragliders. The Oudie is portable, relatively inexpensive ($375-625) and has a PC simulator that we can confirm works with the current Stratux Flarm/NMEA traffic output. http://www.naviter.com/products/oudie-2/

A third, very broadly deployed device is the LXNav FlarmView. It is a very simple traffic and collision warning device. It is also very inexpensive ($220). If you like we will send you one to evaluate.

Note: As has been mentioned in #571, FlarmView really could be an excellent GA traffic and collision warning device should there be interest in going down a path of more sophisticated collision alarms - like was started here with @AvSquirrel.

Beyond that, the two most popular in-panel glider navigation platforms that display traffic are the LXNav LX 9XXX series and the ClearNav. These systems cost many thousands of dollars. The LX 9XXX series shares some of its code base with the Naviter Oudie, so there may be some benefit from testing with the Oudie first. We would recommend that testing these systems happen last, with a small team of testers who already have this equipment installed and have an understanding of ADS-B, the Flarm Data Port spec and stratux - starting with the four glider owners on this thread. This avoids expensive hardware testing on your part should some of this equipment generate unique behaviors. Lastly, we are connected to the management of the companies that make these instruments and should be able to get cooperation if needed.

That should cover the vast majority of systems in gliders.

Thanks for the great support.

Andy, Andzerj, Charlie and John

[cyoung]

Great! Thanks for collecting this information.

Add an option in the Web UI to set the baud rate to 19.2 kbps. Some of the simple traffic displays don’t support higher baud rates.

This should be present in the "Settings" menu if you're using a /dev/serialout_ device.

[ASW27B]

@cyoung - Baud setting is not jumping out at me on the Settings menu. We're running Prolific USB-Serial devices.

[JS1CG]

We did have a baud setting option in the original UDP.

On Mar 15, 2017, at 12:53 PM, Andy Blackburn notifications@github.com wrote:

@cyoung - Baud setting is not jumping out at me on the Settings menu. We're running Prolific USB-Serial devices.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[cyoung]

Try changing your udev rule to make the device /dev/serialout0 instead of prolific0 or whatever it calls it. Should be working at that point.

[JS1CG]

Sorry, I inadvertently sent that to you instead of the test group.

Charlie

On Wed, Mar 15, 2017 at 1:08 PM, cyoung notifications@github.com wrote:

Try changing your udev rule to make the device /dev/serialout0 instead of prolific0 or whatever it calls it. Should be working at that point.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/489#issuecomment-286847807, or mute the thread https://github.com/notifications/unsubscribe-auth/AXP3EyRBkj8FnsEWocCsk7SMXiotl_5Oks5rmDcSgaJpZM4KCxS5 .

[ASW27B]

@cyoung and @AvSquirrel

We’ve spent some time this week with different setups, including the Ping EFB radio which helps reduce the current draw versus SDRs. One thing we’ve noticed is the switches in the Settings UI to turn on/off 1090ES and UAT don’t work with Ping. It would be better if those switches worked with PingEFB as well - even if that simply meant suppressing the corresponding traffic in the event you can’t simply turn off the specific radio on the Ping.

We did some traffic logging in the SF Bay area where there is plenty of traffic to observe. TIS-B traffic everywhere. There is some odd behavior with traffic types and “AcftType” changing on the same aircraft. The attached spreadsheet breaks down the $PFLAA sentences and sorts them by ICAO ID. The leading status sentences have been stripped.

Some questions/observations - starting with the line in the spreadsheet to look at:

Line 156: 2B040F switches back and forth between ut and et target types. Presumably TIS-B will broadcast on both frequencies. It’s interesting that there are no duplicates. Does stratux de-duplicate targets?

Line 761: A075A3 ICAO ID has it’s aircraft ID change from N129FE to DX1219. I get where the ICAO ID comes from, I’m less sure about the N-Number or other ID. The more concerning issue is that the ‘AircraftID” goes from 0 to 9. We’ve seen a number of cases of “AircraftID” changing from 0 to 9 and 0 to 8, but also 8 to 9. These changes alter the symbol used to depict the aircraft on many displays. It's also perplexing how many aircraft have "AcftType" = 0. Do most aircraft not transmit this data or is it getting lost?

Line 1052: Traffic type changes from ea to ur to et, with some changes in ‘AcftType”. I guess this is possible, it's just perplexing why "AcftType" isn't consistent, at least across ea and ur.

Line 1327: Lots of switching between traffic type ea and ua, but in this case no change in “AcftType”. It’s not clear how an aircraft can be both 1090ES Out and UAT Out. In general, are the e and u codes the frequency band that was received or the one that the aircraft originally transmitted on? It would seem from this that it's the first one.

Generally things are working pretty well.

That’s it for now.

Andy

NMEA Log.xlsx

[UKJohn]

I would appreciate some pointers please. Since Sept last year I have been running v1,0r1b1024de7f after loading Keiths .sh update to give me Flarm output via Port 2000 via Wi-fi connection to my EFB on an Ipad.

I have now made a new image of latest v1.2r1 9ee46170ff.img and this runs ok but it does not have TCP/UDP so I then use the update option on the UI to update with Keiths 1b17cb4101.sh, but this seems to crash the RPI and the red power LED comes on flashes and then nothing works except the Ublox GPS green light starts flashing.

Am I doing the right thing to get the latest version including Flarm via Wi-Fi port 2000 ?

Would appreciate some help please.

John

[ASW27B]

Works perfectly for me. Loaded the current version of stratux as of 2 weeks ago and the revised Flarm NMEA code that restores serial output over USB. Updating the code works. The RPi boots. Targets appear on the UI and over the USB-serial. Do you have the RPi connected to an HDMI display to confirm that is it crashing? There is some finicky-ness about what device plugs in to which USB port, but I thought this was related to running USB-serial converters.

[UKJohn]

Ok, thanks Andy, I just wanted to confirm I am getting the correct base image and correct .sh file as I dont get the UI screen you posted 10 days ago with the Flarm NMEA over port 10110 or do I only get that once I have updated succsefully with the 1b17cb4.sh ?

It seems odd thatthe RPI red LED keeps flashing at me, and I wonder whether it is damaged somehow.

Cheers John

[ASW27B]

Here's a shot of the home screen with the version number, and a shot of XCSoar running on my Mac connected over WiFi with the Flarm traffic screen popped up showing actual ADS-B traffic. Seems to be working.

[UKJohn]

Thankyou Andy - I am beginning to think its my RPi hardware that has failed. I dont think the red power LED on the main board should blink, but be illuminated all the time it is connected to power.

John

On 26/03/2017 00:18, Andy Blackburn wrote:

Here's a shot of the home screen with the version number, and a shot of XCSoar running on my Mac connected over WiFi with the Flarm traffic screen popped up showing actual ADS-B traffic. Seems to be working.

screen shot 2017-03-25 at 3 45 25 pm https://cloud.githubusercontent.com/assets/8769091/24327086/4e8753f6-117c-11e7-8029-458f3699294f.png

screen shot 2017-03-25 at 3 50 54 pm https://cloud.githubusercontent.com/assets/8769091/24327087/4ea4f866-117c-11e7-9cd2-9b8818ecb605.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/489#issuecomment-289248931, or mute the thread https://github.com/notifications/unsubscribe-auth/AVx5Tp_1f1PZ8EkIx0Law6I-WuC2VZbMks5rpa7mgaJpZM4KCxS5.

[UKJohn]

Well - I have now got a fresh image loaded and updated it with the same version as you have Andy, but I get no Flarm format Data, just GDL90. I do not have any options on the "Settings" tab on the UI (192.168.10.1) that would allow me to enable Flarm via Port 2000 and switch off the GDL90 format data.

I can see traffic on the UI scrolling through, but no NMEA format data output on the TCP port 2000.

I must be doing something wrong - OR , did the NMEA out (that Keith built previously) on TCP get dropped in this version.

Thanks for your help.

John

On 26/03/2017 00:18, Andy Blackburn wrote:

Here's a shot of the home screen with the version number, and a shot of XCSoar running on my Mac connected over WiFi with the Flarm traffic screen popped up showing actual ADS-B traffic. Seems to be working.

screen shot 2017-03-25 at 3 45 25 pm https://cloud.githubusercontent.com/assets/8769091/24327086/4e8753f6-117c-11e7-8029-458f3699294f.png

screen shot 2017-03-25 at 3 50 54 pm https://cloud.githubusercontent.com/assets/8769091/24327087/4ea4f866-117c-11e7-9cd2-9b8818ecb605.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/489#issuecomment-289248931, or mute the thread https://github.com/notifications/unsubscribe-auth/AVx5Tp_1f1PZ8EkIx0Law6I-WuC2VZbMks5rpa7mgaJpZM4KCxS5.

[JS1CG]

Hi John,

I had not used the TCP 2000 port before, but I can confirm that UDP 10110 works with XCSoar, but TCP 2000 does not, with base image 1.21 and update 1.21. The red light on my rPi is on solid, and the green light blinks. So, it may be that the new base/update does not support TCP 2000.

Charlie

On Sun, Mar 26, 2017 at 6:26 AM, UKJohn notifications@github.com wrote:

Well - I have now got a fresh image loaded and updated it with the same version as you have Andy, but I get no Flarm format Data, just GDL90. I do not have any options on the "Settings" tab on the UI (192.168.10.1) that would allow me to enable Flarm via Port 2000 and switch off the GDL90 format data.

I can see traffic on the UI scrolling through, but no NMEA format data output on the TCP port 2000.

I must be doing something wrong - OR , did the NMEA out (that Keith built previously) on TCP get dropped in this version.

Thanks for your help.

John

On 26/03/2017 00:18, Andy Blackburn wrote:

Here's a shot of the home screen with the version number, and a shot of XCSoar running on my Mac connected over WiFi with the Flarm traffic screen popped up showing actual ADS-B traffic. Seems to be working.

screen shot 2017-03-25 at 3 45 25 pm https://cloud.githubusercontent.com/assets/8769091/24327086/4e8753f6- 117c-11e7-8029-458f3699294f.png

screen shot 2017-03-25 at 3 50 54 pm https://cloud.githubusercontent.com/assets/8769091/24327087/4ea4f866- 117c-11e7-9cd2-9b8818ecb605.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/489#issuecomment-289248931, or mute the thread https://github.com/notifications/unsubscribe- auth/AVx5Tp_1f1PZ8EkIx0Law6I-WuC2VZbMks5rpa7mgaJpZM4KCxS5.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/489#issuecomment-289279878, or mute the thread https://github.com/notifications/unsubscribe-auth/AXP3E4oorxHnLn_vE4LpbJAVS9gZJbAdks5rpllngaJpZM4KCxS5 .

[VulturARG]

Hi, I tried to use this version of stratus flarm, but I can't. I new in raspberry and don't know much about linux.

I download the stratux V1.2r2 image, burn it in a flash and put in my raspberry 3 model B. Work fine with an USB GPS ublox 7 and generic srd with rtl2832u r820t2.

After that, I tried to compile this version in another flash with Raspbian Jessie full. I cloned https://github.com/AvSquirrel/stratux.git.

I tried make

pi@raspberrypi:~/stratux$ make _make xdump978 make[1]: Entering directory '/home/pi/stratux' cd dump978 && make lib make[2]: Entering directory '/home/pi/stratux/dump978' gcc -c -O2 -g -Wall -Werror -Ifec -fpic -DBUILD_LIB=1 dump978.c fec.c fec/decode_rs_char.c fec/init_rs_char.c Mensajes del ensamblador: Error fatal: no se puede crear dump978.o: Permiso denegado Mensajes del ensamblador: Error fatal: no se puede crear fec.o: Permiso denegado Mensajes del ensamblador: Error fatal: no se puede crear decode_rs_char.o: Permiso denegado Mensajes del ensamblador: Error fatal: no se puede crear init_rs_char.o: Permiso denegado Makefile:12: recipe for target 'lib' failed make[2]: ** [lib] Error 1 make[2]: Leaving directory '/home/pi/stratux/dump978' Makefile:23: recipe for target 'xdump978' failed make[1]: [xdump978] Error 2 make[1]: Leaving directory '/home/pi/stratux' Makefile:10: recipe for target 'all' failed make: * [all] Error 2_

after that sudo make:

**pi@raspberrypi:~/stratux $ sudo make Makefile:6: *** GOROOT is not set!. Alto.**

I don't have idea how I can modificate the stratux image using .sh file

Any help will be appreciated

Regard,

Luis

[ASW27B]

Luis,

I'm not sure I understand what you did.

Assuming you have a good Stratux setup, the procedure is to run the modification code that you have downloaded to your computer from the following link:

https://github.com/cyoung/stratux/files/826743/update-stratux-flarm-v1.2r1-1b17cb4101.sh.zip

Just click on the update button on the Stratux WebUI Home page, navigate to the file and go. You don't put anything directly on the microSD card on your RPi - or compile anything.

Hope that helps.

Andy

[VulturARG]

@ASW27B Thanks Andy!!!

It was just what I needed.

[eishboet]

Hi

I'm sorry for waking this thread, but I have noted an issue with the flarm update.

First off, the update works, I can now see traffic in SD, however, I've noted that the GPS/AHRS page in UI no longer displays an active GPS fix. The GPS (VK-162) data is definitely being received by SD.

Have any of you noted this issue?

Thanks,

Deanen

[sridel]

Hey guys, first a big thank you for the fantastic work you are doing.

My question: Besides turning on FLARM NMEA over UDP Port 10110 in the UI, is there anything else I need to do? I've followed all the instructions to the letter, however I am unable to get XCSoar to see anything coming in over UDP. I do see traffic in Avare when I listen on 4000. Same problem when running XCSoar on my Mac and also Android phone (unrooted).

Any suggestions?

Thanks in advance!