Interfacing PAW with LX90X0 nav computers and Flarmview units

[PaulRuskin]

Hi All

I'm planning to try and integrate a PAW with the LX9070 nav computer and Flarmview 57 in my glider.

Before I reinvent the wheel, has anyone done this before?

Thanks

Paul

[PaulRuskin]

OK - I think I conclude that no-one else has done this yet.  In this post, I'll make a brief explanation of what we're trying to do.  In the next, I'll say what I think is needed.

The LX Nav 9000 series of flight computers are fairly common in the gliding world.

In the picture below is an LX9070. (the big bit of glass in the middle).  It gives moving map, navigation, task and  a lot of performance data to the glider pilot.  Integrated within it is a Flarm, and one contact can be seen (FOX) in the glider's 6 o'clock.  On the far right is an LX Flarmview57, which is a small, dedicated screen for traffic information.  Again, FOX can be seen in the glider's six o'clock.

As an aside, the glider is climbing in wave at 500 feet per minute through 11000 feet.  IIRC the airway shown wasn't active that day.

So the task is to put a PilotAware into this system in a sensible way to maximise effectiveness.  Next post - how.

Paul



(if the image isn't shown it's here: https://www.dropbox.com/s/pypuvmj5eege43p/LX%20image%20for%20post.JPG?dl=0

[PaulRuskin]

So how to go about this?

1. Minimum

I think the minimum solution is to provide a serial output from the PAW with at least PFLAA NMEA sentences showing traffic information.  It may already be there, in which case could someone point me to a spec.

The LX9070 contains a Flarm unit, which it uses for its own purposes, but also provides a Flarm output which can be connected to a display  such as the Flarmview via a standard Flarm cable (RS232).  The Flarmview has two such ports, so a second data source such as an ADSB source or PAW can be connected.  Job done.

The LX9070 also has an external Flarm input.  However, at this stage, I don't know whether it can take two sources, or by using that port you'd be turning off the internal source (in which case you'd need to mix the two inputs and feed them back in).  I'll find out.

So, given the simple solution, I think we could get at least a Flarmview working.  Possibly both.  It's a little rough and ready, and (at least when OGN-R is running, there could be two sources of local Flarm traffic).

2. Slightly more complicated.

It might be sensible to limit the traffic fed into the LX kit by range and vertical range (like the PAW Radar display does).  We're really not worried about airliners tens of thousands of feet above, and don't want to see them.  Traffic within 2-5000 feet would be completely sufficient.  A configuration item possibly.

3. Fuller implementation

a.  Clearly (if PAW doesn't have it already) traffic data out could be generalised, perhaps by choosing which NMEA sentences are sent via a series of tick boxes (LX do it this way for their Flarm data out).  Choices are, in that case, GPGGA, GPRMC, GPGSA, PFLAU, PFLAA and some specific LX ones.

b.  LX have an implementation with a Garrecht TRX-1090 ADSB receiver.  What happens is the internal Flarm unit on the LX9000 is fed into the TRX-1090 where ADSB traffic is added and deduplicated, and then the output fed back into the displays (9070 and Flarmview in my case).  It would prevent duplicate traffic (the same contact from both Flarm and PAW). PAW could do something similar, but it would be important that the PFLAA sentences (the alarm ones) were passed on promptly and other sentences fed directly through.  There is the issue of the available number of USB ports on the PAW, but I guess that's soluble.

Paul

[Admin]

Hi Paul,

I will try to get a more detailed answer later, in the menatime, have you seen this document ?
http://www.pilotaware.com/wp-content/uploads/FLARM-IN-via-LX-Nav-FlarmMouse.pdf

thx
Lee

[PaulRuskin]

Thanks - yes, I've seen that.

I've just had another conversation with LX support, and we obviously miscommunicated in our earlier exchange.

I've confirmed that the 9070 can only take either external input or use its internal Flarm.  What's new is that they say on the Flarmview, the two ports "are just a splitter", by which I think they mean they are physically connected (edit: now confirmed).  That means, I think, that there are two options.

1. Use an external active multiplexer to combine the data from the Flarm unit and the PAW, and feed the output of that into the two products.  Would work, though not particularly elegant since it requires another unit (though they are available).

2. Feed the Flarm into the PAW (as in the Flarm mouse document that you mention - so ought to be standard), and then take a serial output from the PAW back into both LX products.  I think that would work fine providing all the Flarm packets going into the PAW get passed through to the output (they have the important anti-collision stuff on).  However, as I mentioned earlier, I can only see one spare USB output on the PAW unit I have, and we'd need two.

I'm happy to pull my LX kit out of my glider over the winter and put it on a bench to test this stuff.

Paul

[Paul_Sengupta]

If you don't need the Wifi in your set up, I think maybe you could remove the Wifi dongle. You then wouldn't be able to see the status screen or anything on a phone or tablet but it might work. The other thing is to remove the GPS and use the GPS supplied from the Flarm.

I've not tried it recently, but the other thing is to possible put the "standard" dongles on a USB hub. I had an early implementation of PAW running on my Pi 1 B with only two USB ports but using a USB hub.

[PaulRuskin]

If you don't need the Wifi in your set up, I think maybe you could remove the Wifi dongle. You then wouldn't be able to see the status screen or anything on a phone or tablet but it might work. The other thing is to remove the GPS and use the GPS supplied from the Flarm.

I've not tried it recently, but the other thing is to possible put the "standard" dongles on a USB hub. I had an early implementation of PAW running on my Pi 1 B with only two USB ports but using a USB hub.

Good points.

I think there are all sorts of reasons you'd want to keep the wifi (the configuration and status functionality especially).  The other two options are good though:

If the PAW can use the Flarm's GPS, there's one less antenna, which is good.  Lee - can it do that?

Else a small hub is pretty cheap if the software can cope with the extra ports (I note that the config page has boxes specifically for four USB ports).

Paul

[Admin]

Good points.

I think there are all sorts of reasons you'd want to keep the wifi (the configuration and status functionality especially).  The other two options are good though:

If the PAW can use the Flarm's GPS, there's one less antenna, which is good.  Lee - can it do that?

Yes this works, if you unplug the GPS dongle, it will revert to using the GPS supplied by Flarm

thx
Lee

[PaulRuskin]

OK - we're really getting somewhere.

So we can feed the Flarm input to the PAW.

All we need to do is

1. know how to get the traffic output (the equivalent of what's seen on port 2000) to one of the USB-serial ports.  Is that in one of the existing setups Lee?

2. And make sure that all the sentences that come from the Flarm appear on the outputs (since the LX kit will need the GPS fixes and the priority Flarm sentences.  Is that the current behaviour?

Paul

[Admin]

OK - we're really getting somewhere.

So we can feed the Flarm input to the PAW.

All we need to do is

1. know how to get the traffic output (the equivalent of what's seen on port 2000) to one of the USB-serial ports.  Is that in one of the existing setups Lee?

2. And make sure that all the sentences that come from the Flarm appear on the outputs (since the LX kit will need the GPS fixes and the priority Flarm sentences.  Is that the current behaviour?

Paul

I think there is a FLARM input and FLARM output option on the RS232 interface, this is what we use to connect to an external navigation display when WiFi is not available

IIRC there was a todo to combine the FLARM In/Out into a single Connector, but you can do it today with 2xRS232

2. And make sure that all the sentences that come from the Flarm appear on the outputs (since the LX kit will need the GPS fixes and the priority Flarm sentences.  Is that the current behaviour?

I think the priority bit of the PFLAU Flarm sentence may be discarded, it would be a simple fix to maintain this, but I think right now it gets set to 0 on the way out

Thx
Lee

[PaulRuskin]

Hi Lee

IIRC there was a todo to combine the FLARM In/Out into a single Connector, but you can do it today with 2xRS232

That's a nice to have, but not essential.  Would save a USB/232 converter and a port, but shouldn't change the functionality.

I think the priority bit of the PFLAU Flarm sentence may be discarded, it would be a simple fix to maintain this, but I think right now it gets set to 0 on the way out

This one is much more important.  Assuming you mean the AlarmLevel field (you have the Flarm Dataport Spec?) it is, I think, that sentence that the Flarm uses to communicate an imminent collision.  No glider pilot is going to install PAW if that gets lost!  But that raises a few questions:

- preserving the status you've said is easy - great.  It's essential.

- but is the PFLAU sentence always preserved?  Example:  when I put this in my glider, I'll be transmitting Flarm, PAW and Mode S (maybe ADSB too one day if I can do it legally).  I come across another similarly equipped glider, and we're close to a collision.  The Flarm generates a PFLAU sentence with the AlarmBit set, and sends it to the PAW.  The PAW needs to deduplicate that contact with the PAW and mode S contacts it has received.  Which packet does it preserve?

- are there any circumstances where the PFLAU packet could get dropped due to congestion at any point in the system (processing or serial ports?).  Flarm make quite a big thing about dropping the PFLAA packets gracefully in preference to the PFLAU (alarm) packets.

Thanks


Paul

[exfirepro]

Hi Paul /All,

I have been watching this thread with interest, though not ‘contributing’ while I was away in India (really ‘carp’ internet for the last 8 days where we were staying - which is unusual for India, the Helpdesk ‘World Capital’),

Certainly all sound feasible if (perhaps that should be when) Lee can do the ‘fix’ to ensure the FLARM anti-collision priority traffic is maintained.

Be aware that during our early ‘direct-FLARM connection’ testing we did have some issues when using the FlarmMouse gps to supply PAW. We got occasional loss of position reports which after discussion with LX were put down to the extremely small gps antenna inside the FlarmMouse. This was why Lee configured PAW to use its ‘own gps’ by default if connected. In your case, as your 9070 uses an external gps antenna it should be fine (it works fine using a gps feed from a PFCore).

Regards

Peter

[Admin]

- are there any circumstances where the PFLAU packet could get dropped due to congestion at any point in the system (processing or serial ports?).  Flarm make quite a big thing about dropping the PFLAA packets gracefully in preference to the PFLAU (alarm) packets.

The reason flarm prioritizes, is based upon the serial baud rate, as low as 9600 does not leave much room for manoeuvre, but when connected to PAW, you can connect over serial at upto 2mbit. So comms from flarm to paw should not be an issue. When PAW transmits over serial or wifi, it currently prioritizes on distance first. So we could prepend to this, the alarm level that flarm reports, so order of traffic would be
Alarm3
Alarm2
Alarm1
Distance

Not a big deal to be honest

Thx
Lee

[JCurtis]

I made a box recently that received multiple serial streams and combined them into a single output (RS232 or IP), it could prioritise the order depending on the received packet content.  It could also take inputs from IP, collate, and squirt them out a serial port (or IP) too.  Total latency through the system was <40ms (0.04 seconds).

To just do a smart serial combiner without the ethernet would be quite easy for up to a total of 6 serial ports with packet type priority.  Naturally doesn't matter about the serial speeds being different, the box had quite large buffers to manage the queues.

Would something like that be of any use for hooking up multiple systems, could also filter packets and even modify them en-route too if needed?

[PaulRuskin]

The reason flarm prioritizes, is based upon the serial baud rate, as low as 9600 does not leave much room for manoeuvre, but when connected to PAW, you can connect over serial at upto 2mbit. So comms from flarm to paw should not be an issue. When PAW transmits over serial or wifi, it currently prioritizes on distance first. So we could prepend to this, the alarm level that flarm reports, so order of traffic would be
Alarm3
Alarm2
Alarm1
Distance

Lee - if you could do that, it would be brilliant.  I'll start working on a test setup.

The other reason they prioritise I think is the limited processing power in some of the units.  But there seems to be an option to bump up the data rates in the LX products.  It might be though that we will end up with different data rates on the Flarm in and PAW out streams - so keeping the flexibility to have two different interfaces might be useful.

Paul