SoftRF am XCVario

[iltis42]

There is a brandnew project using a generic hardware plus MK2 software: http://www.lilygo.cn/prod_view.aspx?TypeId=50033&Id=1163 as Flarm and also GPS source.
Datatransfer has been demonstrated with a baudrate of 38400, with Tx + Rx Inversion set to Normal.

More info to come...

[domnantas]

Would be great to be able to connect XCVario, SoftRF, and XCSoar. That would be a great budget setup. As far as I know, there is a limitation for a single Bluetooth connection though: https://github.com/lyusupov/SoftRF/wiki/Badge-Edition#two-seater Maybe

SoftRF --GPS + Traffic via Bluetooth--> XCVario --GPS + Traffic + Baro via Wifi/BT--> XCSoar

would be possible, where XCVario would forward the Flarm/OGN messages

[iltis42]

XCVario is already flying together SoftRF and the "SkyMap" App (not free but worth the few bucks) in an Lambada UL. Attached i have here some pictures from the housing. We may ask the builder for more info.
SoftRF features a serial interface and so does XCVario what brings both together with the settings from the above posting.

[domnantas]

That is very interesting! I have the same SoftRF device, I'm wondering what's that additional board inside – is it UART -> RS232 driver?

[gf408]

Hi,
I am the guide with the Lambada. The additional board is the BMP280 Pressure sensor. I added an external antenna for the gps signal and an external antenna for the loran. The range extended approx. 50%
Meanwhile I changed the system to SoftRF-Mini with a special case, suitable to fix inside a standard slot in my instrument panel.

To connect the mini device you need a converter 12/5Volt. Therefor the housing has more thickness. Now I changed the second time. Instead of the additional 12 Volt car sockets I installed an USB socket to be able to update SoftRF-Mini without disassembling

[domnantas]

That's wonderful! How does the SoftRF-Mini communicate with XCVario?

[mspudi]

I have tested that everything is normal. Vario can receive GPS. I haven't tested FLMA yet

[moshe-braner]

I have gotten SoftRF (on a T-Beam) talking to XCvario via a serial cable. I used a TTL-RS232 converter board, although the XCvario does not need it (according to the manual), but with RS232 levels (more or less) and an RJ45 jack this T-Beam is now FLARM-compatible in serial connections to any other device, which is nice. The cable connection also powers the T-Beam via the XCvario - I also built a 12V-5V converter inside the T-Beam case. It is connected to the XCvario S2 jack via a standard ethernet cable with the wire for pin 7 cut. Of course the factory-supplied XCvario multi-purpose cable can be used instead - make sure it is plugged into S1!

That said, I would like to see a way to send the GNSS+traffic data from SoftRF to XCvario without the need to build a serial connection, as it takes significant work to build, and only some people know how to do that. Such a wireless connection would be useful is, for example, a club glider has a standalone XCvario but no FLARM, and a pilot brings along a portable SoftRF device. Or the club adds a SoftRF device - this is happening in several clubs in the USA right now, but most do not have an XCvario at this point. The question is: what is to be gained from that connection? That depends what else the pilot uses. If not using anything else, then the traffic warnings on the XCvario are good to have. If using XCsoar or Tophat on an android device with audio, then that device, receiving the data directly from SoftRF, can give voice-warning about traffic. And one would like to see the traffic on the moving map. In that case there is no real need to connect SoftRF to the XCvario too. But ideally data from both SoftRF and XCvario would reach XCsoar in combination, to gain both traffic display and better airspeed and wind speed and vario data. Moreover, if the android device does not have audio, for example on an e-reader for the sunlight readable e-paper display, the traffic warning on XCvario is still desirable - and the e-reader also needs GNSS data, which it can get from SoftRF. Can the three devices be connected wirelessly?

One obstacle is that XCsoar/Tophat want to connect to an existing Wifi network, and the standard version of SoftRF creates a Wifi network, as does XCvario. XCsoar cannot connect to two networks at the same time. Conversely, if using Bluetooth, connections are limited (just one?), and the Android device wants to be "master", while XCvario and SoftRF are slave clients, thus XCvario and SoftRF cannot communicate with each other. If a Bluetooth Master mode would be added to XCvario, then SoftRF could connect to XCvario, but not to XCsoar at the same time. If a WiFi UDP listener mode were added to XCvario, then both it and XCsoar could listen to the data from SoftRF, both connecting to the Wifi network created by SoftRF, but then XCsoar won't get XCvario data. Does a UDP connection have a callback channel? If so, then maybe SoftRF could be configured to receive that, and re-send to XCsoar? Or can potentially add TCP capability to SoftRF. So many options, none perfect!

[iltis42]

@gf408 afaik you had connected SoftRF directly to XCVario without a converter using just a plain cable, right?

[moshe-braner]

No, I used an RS232 level converter (MAX3232). My reading of the manual says that that was not necessary, since XCvario can handle either level. (Is this done via direct programming of a GPIO pin?) That is a very nice feature of XCvario! Maybe I should have tried it without the converter, to see how well it would work? But I thought that while I do the work, I might as well make this T-Beam/SoftRF as hardware-compatible with FLARM as I can, in case I want to plug it into some other system some day. (Clearnav, SN10, etc.) The serial TX/RX pins on the T-Beam work at 3.3V level AFAIK, officially much too low for input into most other systems. (Just so as to drive another MAX3232 inside the other device? :-)

Oh and the plain (standard ethernet) cable was almost, but not quite, OK for connection to the S2 jack on the XCvario, because if plugged into a real FLARM the +12V would feed from pin 8 to pin 7 (as they are shorted together inside the FLARM) and then back to the CAN bus. That is why I cut the pin 7 wire in the cable, even though I also did not connect pin 7 inside the T-Beam. It would have been better if the CAN bus on S2 used some other pin.

This is not quite the right forum, but I should mention briefly that connecting the 5V power to the T-Beam is a challenge too, since there is no access to the USB 5V power line. I fed it to the (empty) battery holder, via a diode to drop the voltage to about 4.4V.

[moshe-braner]

Is it true that you can only use Bluetooth or Wifi at the same time on the ESP32? How is it that if SoftRF is set to use Bluetooth, you can still change its settings via its web interface (on the WiFi network it creates)? And how is it that you can change settings on the SkyView (another ESP32 device in the SoftRF family, a kind of FLARM view device), via its own WiFi network, while it is receiving the data from SoftRF via Wifi - where the SoftRF creates the network for that? WiFi AP and station modes simultaneously? Or while receiving the data from SoftRF via Bluetooth? I know it's the same radio hardware for both. So how is it done?

[iltis42]

No, I used

The question was for the original builder flying the Lambada

[iltis42]

use Bluetooth or Wifi at the same time on the ESP32?

This is possible theoretically, hence on a poor performance (1). Once a continuous datastream is required, e.g. here for low latency of Vario needle, this is no option. In principle you can do either or with just one radio chip. The question here to do a quick change between both protocols and there are timing and resource constraints.

1. https://esp32.com/viewtopic.php?t=6707&start=30

[moshe-braner]

I have indeed noticed that the SoftRF settings-setting web server is slow if it is using BT at the same time.

How about this use case: XCvario listens to SoftRF via BT. When it receives data (GNSS and traffic), or has vario data to send, it sends to XCsoar via WiFi. (UDP may be "cheaper" in CPU load than TCP.) It could also be the opposite, receive from SoftRF via UDP and send to XCsoar via BT, but the e-readers I prefer for use do not have BT. Either way, each connection is one-way. Bidirectional use is not needed in this use case. How much of the time does the data transmission from XCvario to XCsoar take? Can limit how often XCvario sends data, once a second would be enough. So most of the time XCvario could be listening to the transmissions from SoftRF. And if it misses hearing such a transmission occasionally, that is not a problem. Would that work?

[moshe-braner]

Another approach is to modify SoftRF to allow it to be a client on the WiFi network created by XCvario. XCvario would need to listen to packets from SoftRF and send packets to XCsoar, as two clients on the same WiFi network (the one created by XCvario). Source code is already in place in SoftRF to be a WiFi client. But how to tell SoftRF the network name and password, and how to change settings on it later? Can the web server part of SoftRF keep working when it is a WiFi client? I think so, since that is done in OGNbase (another ESP32 project I work on, based on SoftRF source code). OGNbase connects to the "house" WiFi since it needs to send data to OGN over the internet. And it also has the web-server UI. It also stores and reads settings from a config file stored in SPIFFS.

This approach needs a new version of SoftRF. I can experiment with modifying SoftRF to be a wifi client. But XCvario would also need modification, to have it accept GNSS and traffic data from a (second) WiFi client. Ideally via UDP, since currently SoftRF does not use TCP. Source code for that is available, for example, in XCsoar. In this type of use can also send the data (from XCvario to XCsoar) via UDP instead of TCP.