support for LTM protocol

[sppnk]

For airplanes mainly and iNav, LTM is a very compact protocol for telemetry. This could allow to share one port for telemetry and OSD. LTM is a one-way protocol, not polled.

In iNav/cleanflight, we can have MSP when unARMED and LTM when ARMED, so we could have also the configuration options from sticks inputs when unARMED. The OSD just had to check the 'STATUS' frame when in LTM mode to change to MSP mode....

More on LTM here: https://github.com/stronnag/mwptools/blob/master/docs/ltm-definition.txt

[ShikOfTheRa]

Once mavlink is completed I intend to add in a generic support .

One issue here - to add LTM, but retain MSP there may not be enough memory to do both. LTM telemetry receive should be very straightforward though.

Any other FC use LTM?

[ShikOfTheRa]

Added to the development wishlist.

[sppnk]

Thank you !

[sppnk]

Hi @ShikOfTheRa, here is a development based in minimosd supporting LTM.

[https://github.com/digitalentity/ltm-osd-simple]

@digitalentity is the main developer of iNav branch of Cleanflight and AFAIK he uses a LTM osd. It would be nice to catch the same wire of rx input on osd and connect to the model telemetry system (in my case is openlersng).

It would be good to have a good solution, because in some FC's (CC3D) is almost mandatory to share the same port for MSP and telemetry, as 'softserial' ports doesnt work well.

[digitalentity]

@ShikOfTheRa, please keep in mind that I did ltm-osd-simple as a suitable OSD for myself, it's actually not intended to be widely used :smile: However LTM is slowly becoming a common telemetry protocol (Cleanflight/Betaflight/Raceflight/INAV) and EzGUI/mwp for groundstations. Having it supported by more tools it is a good thing to have!

[sppnk]

here the great antena tracker of @raul-ortega : [https://github.com/raul-ortega/amv-open360tracker], also supporting LTM

[tracernz]

However LTM is slowly becoming a common telemetry protocol (Cleanflight/Betaflight/Raceflight/INAV)

Not to mention Tau Labs/dRonin where it originated. ;-)

It was originally developed by KipK for his Ghettostation antenna tracker https://github.com/KipK/Ghettostation and support added to Tau https://github.com/TauLabs/TauLabs/pull/1074.

[ShikOfTheRa]

I get the feeling LTM would be welcomed! Ok its moved up the list....

[ShikOfTheRa]

@digitalentity thanks. Are any of the extended settings available via MSP for iNAV? Be nice to add them into the menu adjustment options

[digitalentity]

@ShikOfTheRa No, I don't have MSP extensions to access INAV-specific settings yet

[ShikOfTheRa]

Something interested in doing? must admit I like what done with iNav. If any desire to let me know and I'll add in pages to support

[sppnk]

what will be the behaviour of LTM in scarab-osd? Do you plan to include both MSP and LTM at the same time or MSP when unarmed and LTM when armed? (like iNav does). thks.

[ShikOfTheRa]

It may be a choice of one or the other. Depends on how much memory it takes and if can run both at same time. Clever idea to support different when unarmed.

[ohhorob]

The unarmed/armed behaviour is how Cleanflight shares Blackbox logging with MSP on UART1.

Makes a lot of sense for a similar behaviour for Groundstation/OSD telemetry. You typically only want MSP for changing settings while disarmed. Then while in the air, the telemetry serial link will benefit from the more efficient and one-way LTM protocol.

'stronnag has some documentation for LTM over in https://github.com/stronnag/mwptools/blob/master/docs/ltm-definition.txt

He also has mwp auto-switching between the two protocols on the same serial input.. https://github.com/stronnag/mwptools/blob/67995f58c9ffa040ef345a08878a406d42726c79/common/serial-device.vala

[ShikOfTheRa]

Just a case of having enough memory to operate both. ohhorob - simultanoeous is not an issue - actually this is pretty much how it works with Naza and mavlink now.

[ohhorob]

Looks like you already pulled in some LTM code :)

https://github.com/ShikOfTheRa/scarab-osd/commit/7708786758a2163fb37a9f7e8eb256a9d54f6b2f

[tracernz]

LTM seems like a bit of a weird protocol for this... It's an extremely minimal protocol designed only for low bandwidth links (1200 baud)... These are literally the only things in it...

 *              Protocol details: 3 different frames, little endian.
 *                * G Frame (GPS position) (2hz @ 1200 bauds , 5hz >= 2400 bauds): 18BYTES
 *                  0x24 0x54 0x47 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF  0xFF   0xC0   
 *                   $     T    G  --------LAT-------- -------LON---------  SPD --------ALT-------- SAT/FIX  CRC
 *                * A Frame (Attitude) (5hz @ 1200bauds , 10hz >= 2400bauds): 10BYTES
 *                  0x24 0x54 0x41 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xC0   
 *                   $     T   A   --PITCH-- --ROLL--- -HEADING-  CRC
 *                * S Frame (Sensors) (2hz @ 1200bauds, 5hz >= 2400bauds): 11BYTES
 *                  0x24 0x54 0x53 0xFF 0xFF  0xFF 0xFF    0xFF    0xFF      0xFF       0xC0     
 *                   $     T   S   VBAT(mv)  Current(ma)   RSSI  AIRSPEED  ARM/FS/FMOD   CRC

What is the advantage over MSP for example (already a lightweight protocol if you only support the same messages)?

[sppnk]

@tracernz , the use of LTM in clenaflight/iNav controllers (or others) will be useful when arming, so we could share the same USART for OSD and telemetry at very low baudrates (1200, 2400..).

LTM is designed for long range telemetry systems.

[tracernz]

Can you not reduce the MSP message set and achieve the same thing?

[digitalentity]

@tracernz MSP isn't actually a telemetry protocol - it's a bi-directional for one so it's really usable only onboard the quad or on a short-range aircraft. When you go really long range you usually have an uplink for your R/C and a very slow downlink (1200-2400) for one-way telemetry. LTM is very low rate and it's one-way. You can channel it back to the ground via long-range one-way link or even via your VTX audio channel. Why not use it for both OSD and sending flight telemetry to the ground?

[tracernz]

MSP can also be uni-directional (although CF removed that functionality for some reason) ;-), and the sender then gets to choose exactly what messages it supports and sends. No real reason not to use LTM except the extra maintenance burden every time a new protocol is introduced. That's a pretty strong reason generally, and especially when imposed on other projects :-P.

[ShikOfTheRa]

It is a pain to maintain more options for sure! I get why its of value to some. Hopefully it will be simple to get running. Assume we will loose some functionality - such as sensor status / modes etc. Not really looked at it fully yet.

@digitalentity merged your code in. Its early days need testing and tiding up before ready. Want to get it working then tidy it up. Hopefully next week can do some testing / debug and get it working

Just wanted to be sure your OK with this being in MWOSD. Added you into the credits.txt

[digitalentity]

@ShikOfTheRa thanks! Protocol implementation is mostly done by @KipK for his GhettOSD, I only did a few tweaks and adapted for my OSD code. I'll be happy to test LTM for MWOSD as soon as you will confirm it's ready for testing!

[ShikOfTheRa]

@digitalentity this can be tested now. I don't have anything to test it with so not sure what is working or not! directions / angles etc may be wrong too. Test carefully!!

bits of interest... //#define iNAV // Uncomment this if you are using latest iNAV version from repository //#define TELEMETRY_LTM // Uncomment this if you are using a LTM telemetry feed (under development)

It uses a lot of memory to run both MSP and LTM. Am sure this can be improved significantly so by defualt it is off. Once its all working perhaps can look at todying it all up. //#define FORCE_MSP

[sppnk]

Great @ShikOfTheRa, I will test ASAP.

How is the switch between MSP and LTM? It should be with the arming flag. Thnx.

[ShikOfTheRa]

Hi - at moment... MSP enabled by default unless LTM is enabled with TELEMETRY_LTM FORCE_MSP runs both at same time ( you may need to use Arduino 1.6.x to compile to free enough memeory)

Once know its working can look at doing that if inav and ltm enabled at same time. Have to remember there may be non iNAV users who require LTM at all times - even when disabled

[sppnk]

Oh, good. Running both at the same time is a good idea. I plan to connect a bluetooth adapter, an OSD and the wires for LTM telemetry to my openlrsng to the same USART.

Great.

[sppnk]

Hello, not tested yet, but If I understand well, the serial baudrate has to be the same for MSP and LTM when sharing, isnt it?

So, could I add a #define BAUDRATE 1200 in config.h in order to have telemetry at 1200 bauds? I dont know if the OSD will continue working well at that low baudrate or we only will have a lower refresh of data? I think that for airplane in long range flights is enought.

[jflyper]

I have a question on MSP to LTM transition upon arming.

1. MSP client polls FC state for arm status.
2. FC switches to LTM upon arm.
3. MSP can't poll FC state any more.

So the MSP can't use "arming state" to "switch" from MSP to LTM.

Is this true?

P.S. The current LTM support runs MSP and LTM in parallel (or in serial) to avoid this problem, I guess.

[sppnk]

Yes, that is what I understand. Both protocols run in parallel.

[ShikOfTheRa]

@sppnk - yes same baud. Haven't worked out the actual, but suspect this is good for around 1 update every second at 1200 baud

[ShikOfTheRa]

@jflyper currently it runs both at same time - and just processes whatever is received. LTM or MSP

Not sure if trying MSP when armed causes any performance overhead issues with FC - if it does then, could put a timer to revert to MSP if not receiving LTM message every 2 seconds. prevent issue above.

[jflyper]

@ShikOfTheRa Yeah, I noticed both running in Serial.ino such that it falls through into MSP code after returning from SerialLTMReceive().

It made me uncomfortable for the first few minutes, but quickly understood the benefits. It should not cause major performance issue, because the state machine will discard the incoming bytes belonging to different protocol in the first few lines.

The reason I rose the above question was that people in CF github some times talk about advanced features about LTM such as changing baud rate when armed and going into the LTM mode, so I just wanted to understand/clarify the use case.

[ShikOfTheRa]

Changing Baud on the fly would be a pain, but it is achievable. I get why they would, but personally I think its not worth the code effort

[sppnk]

I think that if we can run OSD at 1200 everything will be good. The range of shared LTM telemetry will be long.

[ShikOfTheRa]

Anyone tested this yet?

[sppnk]

Sorry, not yet.... !

[silver13]

hey, I'm pretty sure pitch and roll are reversed in the"A" frame...

the protocol is described as pitch, then roll, but I get the other way around on the osd. I had to implement LTM myself so take this with a grain of salt.

[ShikOfTheRa]

OK, thanks for the ti1. Have you tried - or is this on something else you have worked on?

[silver13]

I tried it on mwosd , I coded the tx part. I think some of the unit scaling might be off, and if sending a large mode to mw_ltm.mode results in some garbage on the screen. The rssi scaling is low, a 255 (max) results in 25 rssi. The volts are in 100s of mv, I think they should be in mV. The rest of the data I used was dummies. Attitude also worked .

Thanks for supporting this, I actually have only tx serial on the board.

[ShikOfTheRa]

OK, amended RSSI and voltage scaling. Reversed roll/pitch.

Are you sending MSP over LTM?

I'll probably have to rethink LTM approach a little. As example, I think for mode, the value depends upon if is MSP, mavlink or uavtalk values over LTM.

Will have to read up on it a little as never used myself.

[silver13]

I'm using LTM only, but that's just me. I know it's not really intended to be used like this.

[jflyper]

@silver13 @ShikOfTheRa

The rssi scaling is low, a 255 (max) results in 25 rssi.

LTM encodes RSSI (0-100%) to 0-255?

[EDIT] Yeah, look like is. See #288 and #289 for details.

[ShikOfTheRa]

Am going to close this - any further issues, re-open or create a new issue

[sppnk]

Hi. It seems not much people using this. Should be possible the following:

• INAV is disarmed: use MSP only for configuring.
• INAV armed: send LTM only (possibly at selectable baudrates)
• INAV disarmed (landed aircraft): use MSP to show statistics.

This is because it is a mess to have both connected to my telemetry, as it 'passthought' everything down, and then EZGUI cannot work correctly.

I dont know if this could be done, as it seems not much people is using LTM the way it is implemented now. Thks.

[jflyper]

The hardest part is the baudrate change. If we can handle that with a nice small code, then we just let MSP and LTM reside in the firmware. Of course, there is a size issue, too.

Let me give it a thoughts about it.

[sppnk]

thanks. The main goal of all of this will be to have CC3D working with planes with GPS, MWOSD and a reliable telemetry downlink. As you know, CC3D is the cheapest stm32 FC in the market, and for airplanes is an awesome election. I have several planes working with CC3D, but without telemetry everything is more insecure, in special for long range flights.

[jflyper]

@sppnk Are you good at micro soldering?

[sppnk]

I hope so, hehe. What are you thinking about?

[jflyper]

Couples of autobaud design options; one of them may require jumping serial RX to some other pin ㊙️