LTM AUTO serial port speed lowered to 4800 bps

[DzikuVx]

This is proof of concept for issue #183 .
If LTM serial speed is set to AUTO, port is initialized with 4800pbs. I was considering going down to 2400 but lets first check how it behaves at 4800. Unfortunately I'm unable to test it in any reasonable future (days) so maybe one of you can do it @sppnk @stronnag @digitalentity

[digitalentity]

@DzikuVx wow, you're fast! 👍

[stronnag]

Some thoughts: This also needs to be coordinated with the MSP rate as one valid use case is MSP pre-armed (for preflight checks), LTM after arming. Not having the same baud rate will break this use case.

If no one beats me to it, I will test 4800 at the weekend (as it involves reconfiguring two radios).

[DzikuVx]

Does both have to use the same bps?

[stronnag]

If you mean the radios, the same air speed (which I want to reduce), but I can have different serial speeds air and ground side.

If for the MSP and LTM case, they need to be the same because the radio serial side is fixed.

[DzikuVx]

Yeap, looks like you are right here. Either way, let's first check of LTM only will work at 4800

[sppnk]

For the baudrates I guess it depends on the setup. I have a BT adapter for MSP (115200bps) for preflight config, and LTM in the same wire for telemetry when armed (9600bps right now).

[DzikuVx]

@stronnag Had you a chance to test it?

[stronnag]

Yes, I tested it. Not surprisingly it works just fine, as we only send average c. 270 bytes/sec, so we have perhaps a 40% headroom.

What is perhaps more interesting is the attached patch, which works down to 2400bps (the minimum for my 3DR). This provides c. 170 bytes/sec LTM; might be interetsing the the long range folks
ltm2400.dif.txt

In line too:

--- /tmp/ltm.c  2016-05-10 16:44:17.131723852 +0100
+++ src/main/telemetry/ltm.c    2016-05-10 17:04:54.096261224 +0100
@@ -22,7 +22,7 @@
  * Effective for ground OSD, groundstation HUD and Antenna tracker
  * http://www.wedontneednasa.com/2014/02/lighttelemetry-v2-en-route-to-ground-osd.html
  *
- * This implementation is for LTM v2 > 2400 baud rates
+ * This implementation is for LTM v2+ INAV extensions
  *
  * Cleanflight implementation by Jonathan Hudson
  */
@@ -80,7 +80,7 @@

 #define TELEMETRY_LTM_INITIAL_PORT_MODE MODE_TX
 #define LTM_CYCLETIME   100
-#define LTM_AUTO_BAUD_RATE 4800
+#define LTM_AUTO_BAUD_RATE 2400

 extern uint16_t rssi;           // FIXME dependency on mw.c
 static serialPort_t *ltmPort;
@@ -261,7 +261,7 @@
 #define LTM_BIT_OFRAME  (1 << 3)
 #define LTM_BIT_NFRAME  (1 << 4)

-static uint8_t ltm_schedule[10] = {
+static uint8_t ltm_fast_schedule[10] = {
     LTM_BIT_AFRAME | LTM_BIT_GFRAME,
     LTM_BIT_AFRAME | LTM_BIT_SFRAME | LTM_BIT_OFRAME,
     LTM_BIT_AFRAME | LTM_BIT_GFRAME,
@@ -274,6 +274,21 @@
     LTM_BIT_AFRAME | LTM_BIT_SFRAME | LTM_BIT_NFRAME
 };

+static uint8_t ltm_slow_schedule[10] = {
+    LTM_BIT_AFRAME,
+    LTM_BIT_GFRAME,
+    LTM_BIT_AFRAME | LTM_BIT_SFRAME,
+    LTM_BIT_OFRAME,
+    LTM_BIT_AFRAME,
+    LTM_BIT_OFRAME,
+    LTM_BIT_AFRAME | LTM_BIT_SFRAME,
+    LTM_BIT_GFRAME,
+    LTM_BIT_AFRAME,
+    LTM_BIT_NFRAME
+};
+
+static uint8_t *ltm_schedule;
+
 static void process_ltm(void)
 {
     static uint8_t ltm_scheduler;
@@ -343,8 +358,10 @@

     if (baudRateIndex == BAUD_AUTO) {
         bps = LTM_AUTO_BAUD_RATE;
+        ltm_schedule = ltm_slow_schedule;
     } else {
         bps = baudRates[baudRateIndex];
+        ltm_schedule = ltm_fast_schedule;
     }

     ltmPort = openSerialPort(portConfig->identifier, FUNCTION_TELEMETRY_LTM, NULL, bps, TELEMETRY_LTM_INITIAL_PORT_MODE, SERIAL_NOT_INVERTED);

[DzikuVx]

This is nice. BTW, what kind of ranges do you get on your 3DR?

[stronnag]

Don't laugh, I just pootle around the local recreation ground in LOS, so never more than 200m (and I always have good telemetry).

[digitalentity]

I'm not sure if I can merge this now or delay it to be done together with #365

[DzikuVx]

Definetly delay, this is mainly an experiment

[digitalentity]

I was thinking the same way.

[stronnag]

Wait for #365, as we need the same rate across MSP and LTM to be useful. And we can do the low speed option included above to please the long range folks.

[stale]

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help.
This issue / pull request will be closed if no further activity occurs within two weeks.

[stale]

Automatically closing as inactive.