Best way to transmit 'non standard' data for flight controlers

[3djc]

Hello,

I'm currently working on a proposal for a cleanflight smartport handling refresh. A lot of data can easily be sent using the current smartport implementation (vfas, alt,...), but there is more data that would be very usefull to get on the radio, and I'm trying to find the best way to do that.

There is one possibly simple to deal with, the number of sat currently seen by gps (GSat ?) : it is probably a good idea to know how much margin you have on your GPS lock before sending a drone away.

The other ones are more complex, as they are whole bunch of boolean values representing the current status of the flight controler, representing either enabled capabilities (BARO, MAG,..) or flight mode (ANGLE, HORIZON, RTH,....).

Any ideas on the best options for those ?

jc

[MikeB]

You may need to supply some more information. I, for example, have no real idea about what "cleanflight" is, and what, exactly it's smartport handling is currently doing.
There are some projects that are processing MavLink data and converting values to FrSky Hub/Sport protocol. I've recently been programming an Arduino Mini to do this. It sends information regarding the number of sats and the current GPS fix mode using the T1 (temperature 1) telemetry value.
It also uses some unused hub IDs to send other data. Hub IDs may be sent over the SPort connection.

Mike.

[3djc]

We do something similar (using temp for something it is not meant to) for non smartport telemetry, howver if feels wrong, I would rather use an unnalocated ID on smartport than send data where it does not belong.

Right now, we are sending VFAS, Vspd, Hdg, AccXYZ, Curr, Fuel tmp1 and 2, GPS, GAlt, Date, Gspd, that works fine.

My main issue right now is to send boolean status over smartport, idealy in a way that allows the user to do something meaningfull with it (ie change flighmode, raise alarm or audio annonce,,....). At this point in time, we have about 10 to 15 status that would be usefull on the radio. An example would be to let the user know the multirotor is actually in auto stablilisation mode .. or not !

jc

[Kilrah]

We are working on getting a bunch of IDs from FrSky that we could allocate to relevant multirotor stuff.
Also to get a dedicated channel straight to the Lua interpreter in OpenTX to allow creating custom displays without all of the FrSky prorocol overhead, and with bidiractional communication (enabling things like setting FC parameters from the radio).

I.e. it's a bit early to revamp sport support right now, should rather wait until the foundation for it has made its way into OpenTX to avoid doinh stuff twice.

BTW this is also being somewhat coordinated with the APM guys.

[3djc]

That would be fabulous Kilrah, any time estimate ? (I know very well it's 'when its ready', but does it roughly looks like 3 month, 6 month ? a year ?). Is there an issue open for that ?

I'll do some code housekeeping anyway, is there any issue if I take two random ID (say 0x1000 and 0x10010 to transport data) in the meantime ?

Thx lot (merci beaucoup même )

jc

[Kilrah]

We hope to have it in OpenTX 2.2, of which the release will be kinda dependent of when the FrSky Horus comes out. Maybe 3 months might be realistic.

I am against using random IDs because firstly it seems that someone else already started using these exact "not-so-random" ones potentially causing clashes/confusion, and mostly it is not very user-friendly to do something, have people start to get used to it then change it again 2 months later.

You of course do what you do, but on OpenTX we try to make sure that when we introduce something we do it once and right the first time, even if that means waiting 6 months more.

Maybe that could be done in betaflight, the concept of "fork in which we try stuff and that's thus inherently "experimental" " is cool, and there people using it should expect it.

[3djc]

I understand what you say, I'll keep sending them with known ID (tmp1 and 2), it hurts, but you make enough sense for me to bare the pain ;D

Will be watching that space closely then (let me know if you need some testing done)

Thanks a lot (yes, again, the OpenTX team is not receiving enough thanks for the great good it makes)

jc

[MikeB]

I just carried out an experiment with the SPort. It seems the transport of the SPort data is quite transparent. The first byte is normally 0x10. This is followed by the (2-byte) application ID. FrSky also define some other values for the first byte, so care needs to be taken if using anything else.
What I tried was using 0x11. I configured an Arduino Mini to act as a SPort device, but sent data with the first byte as 0x11 into a X8R. The Sport data frame was transmitted to a XJT and was then sent out by the XJT on the SPort connection.
This could be an interesting "backdoor" method of sending 'private' data.

Mike.

[midelic]

Interesting Mike,
I want to do this test myself when I get back home but with different expectation.
I want to know how the SPORT stuffed bytes are passed to XJT before before sending out by XJT.
I know stuffed byres are sent by sensor stuffed adding additionally one byte for each byte to be stuffed
for example 0x7E is split in 0x7D and 0x5e.
I want to know how "transparently" the RX packing these bytes,We know that in er9x/ersky9x /opentx the bytes arrived stuffed already so this end is clear.
But all the RX telemetry frames I've seen so far are very neat 6+3=9 bytes(in 2 frames without CRC added by Xjt).
If the data is passed transparently it should be more then 9 bytes ...So there is 2 possibilities.

1.The data is passed transparently(with stuffed bytes) but I have yet to see this frame.
2.The bytes are unstuffed inside the rx (make again 0x7E ,discard 0x7D and XOR-red the next with 0x20) and stuffed back the bytes by the XJT before sent serially to er9x/ersky9x/Opentx.
If you have this info will spare me some time if not when I get back home I intend to change the openxsensor code to output only stuffed bytes and monitor at the end with multimodule.

[MikeB]

As I understand it, data on the SPort bus must be stuffed, to prevent a 7E byte appearing other that as the first byte. This applies to both the Rx and the XJT. This must be true since you may put a "UART to SPort" sensor on the XJT bus and it operates exactly the same as one on the Rx.
Essentially, the "stuffed" frame at one end appears exactly the same at the other end, whatever goes on in between!
The transport is transparent, but the definition of packets on the SPort includes the stuffing.
By the way, don't try using byte values of 0x00 or anything above 0x1F instead of the 0x10. These values carry out other operations on the SPort to allow reconfiguration of sensors.

Mike.