XCSoar With LNAV?

Hello Jean,

I did something similar using a Cambridge 302 and a Dell Streak 5
running XCSoar.Â* I used the serial output of the 302 to drive a K6BT
serial to bluetooth converter and connected to the Streak via bluetooth.

I now have a much more complex system in my Stemme:

PowerFLARM portable and ClearNav variometer connected to serial
splitters, one output of each splitter feeds a ClearNav II flight
computer while the other output of each feeds a serial to bluetooth
converter.Â* The Dell Streak is capable of paring with multiple bluetooth
sources and I have one input configured to read the variometer data and
another configured to read the FLARM data.

Note that there are many options for serial to bluetooth converters that
are considerably less expensive than the K6BT but I've had the K6
devices long before I learned of the less expensive options.

Good luck with your efforts and feel free to contact me offline if you
have any other questions.

Regards,
Dan

On 9/5/2017 4:52 AM, Jean dup wrote:
Hi all,

I am trying to set up a new system in my ship which consists of the following:
LX 160, Nano 4, Samsung Tab running XCSoar.
I would like to use the XCSoar as my PFD and would like to have the Nano GPS and Baro data on it as well as the LX160 Airspeed and TE.

Is this possible and how would the arrangement be?

Thanks a lot
Jean du Plessis


--
Dan, 5J

Thanks a lot Dan,
It seems that going the BT route would be the easiest. Not having played around with multiple BT devices connected at the same time before, I was a bit wary of the possibility of it.
Does it matter that the Tab will act as a master and the other devices as slaves or will the communication work both ways?
Sorry for asking the question and not just testing it.. I am currently in the UK and my glider in South Africa- so I'd like to hit the ground running with the set up as soon as I get back!
I'll have a look for possible serial to Bluetooth modules!

Thanks!
Jean

Jean,

I'm at home and my glider is at the airport 25 miles away, but I have
started the XCSoar simulator and, if I recall correctly, I configured
two devices something like the following:

Confg Devices A:Â* Cambridge CAI302 on COM1.Â* I think the baud rate
is 4800, but you can experiment with that.
Â*Â*Â* Â*Â*Â* Â*Â*Â* Â*Â*Â* Â*Â*Â* Â*Â*Â* Â*Â*Â* Â*Â* B:Â* COM2, Baud 19200, Driver FLARM.

Backing out to the Devices page, you can select Monitor to view message
traffic.

It really was not difficult using the K6 devices.Â* There is also a
hardware solution called IOIO that allows direct plug connection, but I
don't know if you can connect both a vario and a FLARM.

Good Luck!

Dan

On 9/5/2017 10:16 AM, Jean dup wrote:
Thanks a lot Dan,
It seems that going the BT route would be the easiest. Not having played around with multiple BT devices connected at the same time before, I was a bit wary of the possibility of it.
Does it matter that the Tab will act as a master and the other devices as slaves or will the communication work both ways?
Sorry for asking the question and not just testing it.. I am currently in the UK and my glider in South Africa- so I'd like to hit the ground running with the set up as soon as I get back!
I'll have a look for possible serial to Bluetooth modules!

Thanks!
Jean

--
Dan, 5J

I have a vario (CAI 302) and PowerFlarm connected via the IOIO solution that Dan mentions and it works beautifully. Happy to share how I wired it all up if you're interested as there needs to be some conversion between RS232 and TTL logic levels. Send me a PM if you want the details.

Robert

On Tuesday, September 5, 2017 at 1:51:19 PM UTC-5, Dan Marotta wrote:
Jean,

I'm at home and my glider is at the airport 25 miles away, but I have
started the XCSoar simulator and, if I recall correctly, I configured
two devices something like the following:

Confg Devices A:Â* Cambridge CAI302 on COM1.Â* I think the baud rate
is 4800, but you can experiment with that.
Â*Â*Â* Â*Â*Â* Â*Â*Â* Â*Â*Â* Â*Â*Â* Â*Â*Â* Â*Â*Â* Â*Â* B:Â* COM2, Baud 19200, Driver FLARM.

Backing out to the Devices page, you can select Monitor to view message
traffic.

It really was not difficult using the K6 devices.Â* There is also a
hardware solution called IOIO that allows direct plug connection, but I
don't know if you can connect both a vario and a FLARM.

Good Luck!

Dan

On 9/5/2017 10:16 AM, Jean dup wrote:
Thanks a lot Dan,
It seems that going the BT route would be the easiest. Not having played around with multiple BT devices connected at the same time before, I was a bit wary of the possibility of it.
Does it matter that the Tab will act as a master and the other devices as slaves or will the communication work both ways?
Sorry for asking the question and not just testing it.. I am currently in the UK and my glider in South Africa- so I'd like to hit the ground running with the set up as soon as I get back!
I'll have a look for possible serial to Bluetooth modules!

Thanks!
Jean

--
Dan, 5J

On Tuesday, September 5, 2017 at 3:52:29 AM UTC-7, Jean dup wrote:
Hi all,

I am trying to set up a new system in my ship which consists of the following:
LX 160, Nano 4, Samsung Tab running XCSoar.
I would like to use the XCSoar as my PFD and would like to have the Nano GPS and Baro data on it as well as the LX160 Airspeed and TE.

Is this possible and how would the arrangement be?

Thanks a lot
Jean du Plessis

Here's a nice thread about setting up a wifi device to allow connection.
http://www.postfrontal.com/forum/top...?TOPIC_ID=8467

I've just switched from a WinCE device that had a hardwired connection to an Android device that doesn't have an easy option for that. I'm considering either a BT or wifi connection.

Cheers,
Craig
7Q

As long as I have a couple of you experts reading this no-longer-properly-named thread, I have a question:

I'm running Top Hat on a Kobo e-reader. I wired up a USB/TTL converter to feed it data from my PowerFLARM since the Kobo doesn't have its own GPS.The GPS data and barometric altitude work great on Top Hat, all the time.

Top Hat also displays some--but not all--FLARM traffic info. Frequently not all targets displayed on my PowerFLARM screen appear on the Top Hat screen (same zoom level). Top Hat doesn't read the FLARM Net database I downloaded so there are no contest IDs displayed unless I have manually assigned a contest ID to them (in which case, they appear sometimes but not always, although my impression is that if a mapped-to-a-contest-ID target appears, it's usually labeled as such). Sometimes climb rates appear under the targets but not always. Occasionally I'll get a target with contest ID (that I've manually assigned) AND a climb rate, but that's rare.

The targets are on the FLARM display. The IDs and climb rates appear on the FLARMView screen when it's connected (currently I don't have a way of connecting it and the Kobo at the same time). When a target appears on the Top Hat screen and I click on it, I can then click thru to get detailed into, including ICAO identifier, climb rate, altitude, and distance (and I can then assign a contest ID if I know for sure who the target is).

I was speaking to Rob Dunning at Region 2 this weekend and he was puzzled by the erratic nature of this. Thoughts?

Chip Bearden

Interesting situation... Are you really sure that the Kobo is getting all of the GPS and baromatric data? Or, is it possible that it is getting 50% - 75% of it but the data is transmitted so often (every second) that you don't discern any data packet loss from those streams?

Like Rob, it is rather puzzling that one data stream is erratic and the other two not, which is why I ask the above question. Maybe try the monitor device feature for a few minutes and watch the data flow to see if you can detect any gaps. Maybe the USB conversion HW isn't quite up to snuff.

R

On Wednesday, September 6, 2017 at 2:02:28 PM UTC-5, wrote:
As long as I have a couple of you experts reading this no-longer-properly-named thread, I have a question:

I'm running Top Hat on a Kobo e-reader. I wired up a USB/TTL converter to feed it data from my PowerFLARM since the Kobo doesn't have its own GPS.The GPS data and barometric altitude work great on Top Hat, all the time.

Top Hat also displays some--but not all--FLARM traffic info. Frequently not all targets displayed on my PowerFLARM screen appear on the Top Hat screen (same zoom level). Top Hat doesn't read the FLARM Net database I downloaded so there are no contest IDs displayed unless I have manually assigned a contest ID to them (in which case, they appear sometimes but not always, although my impression is that if a mapped-to-a-contest-ID target appears, it's usually labeled as such). Sometimes climb rates appear under the targets but not always. Occasionally I'll get a target with contest ID (that I've manually assigned) AND a climb rate, but that's rare.

The targets are on the FLARM display. The IDs and climb rates appear on the FLARMView screen when it's connected (currently I don't have a way of connecting it and the Kobo at the same time). When a target appears on the Top Hat screen and I click on it, I can then click thru to get detailed into, including ICAO identifier, climb rate, altitude, and distance (and I can then assign a contest ID if I know for sure who the target is).

I was speaking to Rob Dunning at Region 2 this weekend and he was puzzled by the erratic nature of this. Thoughts?

Chip Bearden

Actually, I don't know for sure that there aren't dropouts or interruptions in the GPS/baro sentences data streams, just that there are no hesitations or flickering. The "missing" FLARM target data appear for one or several seconds, then disappear. The climb rates are more often missing than displayed but when they do display, they're also there for one or more seconds. The same with the IDs on the targets.

I
I'll try "monitor device" this weekend. What am I looking for: a FLARM target sentence that only appears once in a while even though there's a target within range continuously? Can I test that without having other FLARM-equipped aircraft in range? I can say when testing on the ground that power traffic targets move smoothly across the map display without any erratic behavior. I can't recall if the erratic targets are more likely when there are a lot of them vs. just one or two.

NOTE: found this in the FLARM Data Port Spec doc:
Data on other proximate aircraft, intended for connected devices with sufficient CPU performance. This sentence should be treated with utmost flexibility and tolerance on a best effort base. Individual parameters may be empty.. The sentence is only sent when port baud rate is 19.2k or higher. In case of serial port congestion or high CPU load, this sentence may be omitted for several objects independent of the alarm level.

So if I set the baud rate higher on the FLARM and the Top Hat device, would that cause any problems?

Chip Bearden

On Wednesday, September 6, 2017 at 3:27:50 PM UTC-4, wrote:
Interesting situation... Are you really sure that the Kobo is getting all of the GPS and baromatric data? Or, is it possible that it is getting 50% - 75% of it but the data is transmitted so often (every second) that you don't discern any data packet loss from those streams?

Like Rob, it is rather puzzling that one data stream is erratic and the other two not, which is why I ask the above question. Maybe try the monitor device feature for a few minutes and watch the data flow to see if you can detect any gaps. Maybe the USB conversion HW isn't quite up to snuff.

On Wednesday, September 6, 2017 at 2:24:34 PM UTC-7, wrote:
Actually, I don't know for sure that there aren't dropouts or interruptions in the GPS/baro sentences data streams, just that there are no hesitations or flickering. The "missing" FLARM target data appear for one or several seconds, then disappear. The climb rates are more often missing than displayed but when they do display, they're also there for one or more seconds. The same with the IDs on the targets.

I
I'll try "monitor device" this weekend. What am I looking for: a FLARM target sentence that only appears once in a while even though there's a target within range continuously? Can I test that without having other FLARM-equipped aircraft in range? I can say when testing on the ground that power traffic targets move smoothly across the map display without any erratic behavior. I can't recall if the erratic targets are more likely when there are a lot of them vs. just one or two.

NOTE: found this in the FLARM Data Port Spec doc:
Data on other proximate aircraft, intended for connected devices with sufficient CPU performance. This sentence should be treated with utmost flexibility and tolerance on a best effort base. Individual parameters may be empty. The sentence is only sent when port baud rate is 19.2k or higher. In case of serial port congestion or high CPU load, this sentence may be omitted for several objects independent of the alarm level.

So if I set the baud rate higher on the FLARM and the Top Hat device, would that cause any problems?

Chip Bearden

On Wednesday, September 6, 2017 at 3:27:50 PM UTC-4, wrote:
Interesting situation... Are you really sure that the Kobo is getting all of the GPS and baromatric data? Or, is it possible that it is getting 50% - 75% of it but the data is transmitted so often (every second) that you don't discern any data packet loss from those streams?

Like Rob, it is rather puzzling that one data stream is erratic and the other two not, which is why I ask the above question. Maybe try the monitor device feature for a few minutes and watch the data flow to see if you can detect any gaps. Maybe the USB conversion HW isn't quite up to snuff.

Different devices but,

PowerFlarm to S8 57,600 baud rate max for Powerflarm S8 to Ultimate Le (SeeYou PNA) 256,000 baud rate

All works great.

Richard
www.craggyaero.com

WRT baud rate, I would suggest setting to 57,600 if the Kobo can handle it. Your thought about CPU power is a good one. I don't really know but if I had to guess I would guess that the Kobo processor is pretty low end since all the device normally does is display relatively simple text.

R

On Wednesday, September 6, 2017 at 4:24:34 PM UTC-5, wrote:
Actually, I don't know for sure that there aren't dropouts or interruptions in the GPS/baro sentences data streams, just that there are no hesitations or flickering. The "missing" FLARM target data appear for one or several seconds, then disappear. The climb rates are more often missing than displayed but when they do display, they're also there for one or more seconds. The same with the IDs on the targets.

I
I'll try "monitor device" this weekend. What am I looking for: a FLARM target sentence that only appears once in a while even though there's a target within range continuously? Can I test that without having other FLARM-equipped aircraft in range? I can say when testing on the ground that power traffic targets move smoothly across the map display without any erratic behavior. I can't recall if the erratic targets are more likely when there are a lot of them vs. just one or two.

NOTE: found this in the FLARM Data Port Spec doc:
Data on other proximate aircraft, intended for connected devices with sufficient CPU performance. This sentence should be treated with utmost flexibility and tolerance on a best effort base. Individual parameters may be empty. The sentence is only sent when port baud rate is 19.2k or higher. In case of serial port congestion or high CPU load, this sentence may be omitted for several objects independent of the alarm level.

So if I set the baud rate higher on the FLARM and the Top Hat device, would that cause any problems?

Chip Bearden

On Wednesday, September 6, 2017 at 3:27:50 PM UTC-4, wrote:
Interesting situation... Are you really sure that the Kobo is getting all of the GPS and baromatric data? Or, is it possible that it is getting 50% - 75% of it but the data is transmitted so often (every second) that you don't discern any data packet loss from those streams?

Like Rob, it is rather puzzling that one data stream is erratic and the other two not, which is why I ask the above question. Maybe try the monitor device feature for a few minutes and watch the data flow to see if you can detect any gaps. Maybe the USB conversion HW isn't quite up to snuff.