connection to LXNAV S80/S100

[Moshe Braner]

Has anybody tried connecting a T-Beam to an LXNAV S100 or S80 via the PDA port?  It is attractive (relative to the GPS/FLARM port) because it provides 5V power and TTL-level serial, thus no converters are needed to power the T-Beam and to transfer data.  But will the S100 or S80 accept traffic data via the PDA port?  Will it also forward that data (traffic and also GPS) via Bluetooth (e.g., to XCsoar on a phone)?  Will it also send additional data via Bluetooth such as airspeed, climb rate and wind?  The additional data is a reason to connect via the S80/S100, rather than directly from the T-Beam to the phone via Bluetooth or Wifi.

[Ryan Wood]

I connect to an S7 via PDA port with an ESP32 IOIO device. It receives the FLARM data (there is some sensitivity around the NMEA naming conventions, however). It forwards the aggregated FLARM + airspeed/vario/etc out of the TX on the PDA.

The S7 doesn't have bluetooth but my assumption would be that it would be the same based on what the PDA ttl output is.

This is said with the caveat that for some reason the FLARM indicator/warnings stopped working on my S7 this season (using T-echo to ESP32 via BLE to S7) the only thing that would've changed is updating the T-echo so perhaps there was another change to the NMEA that broke this.

Ryan

[Moshe Braner]

Thanks Ryan.  Can you explain what you mean by "there is some sensitivity around the NMEA naming conventions"?

Also are you saying the data coming into the TTL RX pin in the PDA port is echoed to the TX pin?

If I were to connect a T-Beam I'd only connect the TX pin of the T-Beam to the RX pin of the Sxx, via a 100 ohm resistor to give the ESP32 in the T-Beam some protection, and not connect the RX pin of the T-Beam since (1) there is nothing useful SoftRF on the T-Beam can do with incoming serial data, and (2) that RX pin on the T-Beam is already connected to the USB interface chip.  So, even if the Sxx is sending data out on its TX pin, that would not be connected to anything -- unless I want to connect it to some other device, e.g., a Kobo Mini running Tophat.

[Ryan Wood]

Hi Moshe,

I had to go dig up the code to recall it, but the S7 did not accept/forward sentences with $GN instead of $GP.

Yes the data on the TTL RX pin is echoed on the TX pin, plus the addition of the S7 data as well.

I mainly mention it to say that it won't be surprising if the bluetooth-supported varios (S80/S100) will act the same way.

The benefit of routing vario TTL TX to the T-Beam RX of course is to use the T-Beam as an IOIO device (eg. vario doesn't have native BT, you want to use Wifi / BLE / UART capabilities, connect more than 1 phone/device, etc).  I believe you had added a feature a couple years ago to allow for some IOIO type usage with the T-beam. (There will be duplicate sentences if both native T-Beam data and aggregated (T-Beam + vario) Sxx data are being broadcast).

Ryan

--
You received this message because you are subscribed to a topic in the Google Groups "SoftRF_community" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/softrf_community/W58quTfs23A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to softrf_communi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/softrf_community/b723aa4c-bb8d-4c8a-9924-26f683fcc396n%40googlegroups.com.

[Moshe Braner]

Yes I added that feature a while back.  But you'd have to use the "secondary serial port", on other pins, not the one labeled "RX" on the T-Beam board, since it is already connected to the USB interface chip.  You can't have two data sources competing for control of the same wire.  And my SoftRF code tries not to echo data to the same port it came from.  Nor does it forward GPS data since it has its own.  See the docs.  I'll try and change the code so that it is always $GP rather than $GN - or should that be a setting?  (Some GNSS modules, especially on non-GPS constellations, may output $GN.)

[Ryan Wood]

I believe it was only the T-echo that had $GN. I think the T-beam was $GP.

I think if $GP is more universally compatible, it might just "work" to use it across the board.

Ryan

To view this discussion visit https://groups.google.com/d/msgid/softrf_community/3dd49669-7cca-4de3-9fb0-d48fcf1d440bn%40googlegroups.com.

[VirusPilot]

Ryan, Moshe,

generally speaking I would not recommend to "patch" the NMEA sentences coming from the GPS because this may have side effects on other connected devices. For our background, the Talker ID setting in the GPS is typically set to AUTO which means that $GNxxx is used in case of a multi-constellation solution while $GPxxx or $GLxxx or $GAxxx identify a navigation solution derived from a single GNSS system like GPS or GLONASS or GALILEO. Btw, in case $GNxxx is sent, this does not necessarily identify a non-GPS constellation, it just identifies a multi-constellation solution. More about Talker IDs here: https://gpsd.gitlab.io/gpsd/NMEA.html#_talker_ids

Stefan