Telemetry update frequency ~8s

[kingfisher09]

Hi,

I'm using this library for a robot and it's working great! The only thing is that the telemetry update frequency is quite low. I am using the GPS altitude to represent the speed at which the robot is spinning since I just needed a nice float value that can be displayed on the transmitter. However despite setting the update frequency in the code to 2Hz, I'm only getting updates on my transmitter about every 8s. Is this something I can speed up? I actually only need this one value so if there is another telemetry channel that I can use that is faster, that would be fine!

Thanks!

[ZZ-Cat]

Okay, there are a lot of unknowns here.
I require more information.

Can you provide me with the following:

• On your transmitter module:
  • Packet rates (EG 50 Hz, 150 Hz, 333 Hz etc)
  • Telemetry ratio
• CRSF for Arduino:
  • What version you are using. EG v1.0.1.
  • Your CFA_Config.hpp settings
• Your source/sketch code:
  • How fast you're calling CRSFforArduino::update()
    Ideally, this SHOULD be called at least every 4 milliseconds or faster.
    If this is in your main loop(), what other things are present that could be blocking it? EG Things like delay(), long running for or while loops etc. Some third party libraries may use these in their API functions that could be slowing down your main loop`s execution.
  • Are you in a multi-thread environment? EG FreeRTOS, NuttX, ROS etc.
    I ask this, because CRSF fo Arduino is not currently optimised for multi-threaded environments.
• Your hardware target:
  • Architecture. EG ESP32, SAMD21, SAMD51, Teensy etc.
  • Development board. EG Adafruit Metro M4 Express.

Currently, CRSF for Arduino writes out a telemetry packet on every second RC packet from your receiver.
Keep in mind that the more telemetry packets you have, the slower your overall telemetry update rate will be.

[kingfisher09]

Thanks for the quick reply!

• I'm using a Matek ELRS receiver and Radiomaster Zorro Transmitter
• On the Zorro I'm using 500Hz with a 1:128 telem ratio
• I have not edited the default CFA_Config.hpp settings
• The sketch I'm trying this with is very simple, the only thing happening in the loop with the update call is reading a channel and writing GPS telemetry
• I tried with the Telemetry example and had the same update rate
• I'm using an Arduino Nano RP2040 Connect with the Earlephilhower Arduino core to allow for multi core operation (which I'm not using in this tester sketch)

[ZZ-Cat]

Thanks for the quick reply!

• I'm using a Matek ELRS receiver and Radiomaster Zorro Transmitter
• On the Zorro I'm using 500Hz with a 1:128 telem ratio
• I have not edited the default CFA_Config.hpp settings
• The sketch I'm trying this with is very simple, the only thing happening in the loop with the update call is reading a channel and writing GPS telemetry
• I tried with the Telemetry example and had the same update rate
• I'm using an Arduino Nano RP2040 Connect with the Earlephilhower Arduino core to allow for multi core operation (which I'm not using in this tester sketch)

Interesting. 🤔

I will try a similar set-up on my end with my Metro M4 Express and RadioMaster RP3, and use the same settings you have here, and see what happens.

I don't have any RP2040 targets on hand, unfortunately. But, I will see what I can do.

[kingfisher09]

Thank you! I should say that it doesn't really matter if the update frequency is very low. It would be nice to have faster but it's not critical.

[ZZ-Cat]

Thank you! I should say that it doesn't really matter if the update frequency is very low. It would be nice to have faster but it's not critical.

Yea, nah. If this is a bug in CRSF for Arduino, it's definitely something I need to get on top of.

I'm literally investigating it now.

[ZZ-Cat]

Test set-up

Okay, here is what I have tested:

• Hardware:
  • Development board: Adafruit Metro M4 Express
  • Architecture: SAMD51
• Receiver: RadioMaster RP3 Diversity
• Transmitter: RadioMaster Ranger
  • Packet rates tested: 500, D500, F500
  • Power setting: 25 mW (up to 1 W, dynamic power)
  • Switch Mode: Wide
  • Telemetry Ratio: 1:128
• Controller: RadioMaster TX16S Max Edition Mk1 with RadioMaster Ranger in its module bay
• Firmware
  • CRSF for Arduino v1.0.1
    • Sketch: telemetry.ino
      • GENERATE_RANDOM_GPS_DATA is set to 1, to simulate actual GPS data.
      • GPS telemetry was updated at a rate of 10 Hz (IE every 100 ms)
    • Everything in CFA_Configh.hpp is unchanged
  • EdgeTX v2.10.0-nightly 2023-11-30
  • ExpressLRS v3.3.1

Test conditions

Everything in the telemetry.ino files was left unchanged from its default, save for setting GENERATE_RANDOM_GPS_DATA to enable "simulation" of an actual GPS.

The entire set-up was running for five minutes, then the receiver side was powered down when I needed to change the packet rate on my RadioMaster's (IE my RadioMaster TX16S) side.

What I have found

500 Hz

Telemetry was updated roughly every four seconds.
This is reflected in the LUA script, where the 1:128 telemetry ratio translates to 78 bytes per second.

D500

Telemetry was updated roughly every second.
In the LUA script, the 1:128 telemetry ratio translates to 234 bytes per second.

F500

Telemetry updated roughly every four~five seconds.
In the LUA script, the 1:128 telemetry ratio shows the same 78 bytes per second transfer rate as the 500 Hz packet rate test.

Conclusion

I have my doubts that this is a genuine issue with CRSF for Arduino itself.
Keep in mind that your hardware may be different from what I have tested, given the SAMD51 is single-core, and your RP2040 is dual core. They both have similar clock speeds (120 MHz and 133 MHz, respectively), which should not be an issue.

The test I did serves as a "control" for you to test your optimisations against, and see if there is any noticeable improvement on your end.

Moving forward

As for your telemetry, you may try increasing your telemetry ratio in your ExpressLRS LUA script to something around the 1:32~1:16 marks which will give you 564 bytes per second and 1171 bytes per second respectively, on 500 Hz (NOT D500 or F500).

Further optimisations

In addition to increasing the telemetry ratio on your Zorro's side, you could go into CFA_Configh.hpp and turn off the following (by setting each one to 0):

• CRSF_TELEMETRY_ATTITUDE_ENABLED
• CRSF_TELEMETRY_BAROALTITUDE_ENABLED
• CRSF_TELEMETRY_BATTERY_ENABLED

This will disable Attitude, Barometric Altitude, and Battery telemetry at compile time; and they will not be populated on your Zorro's side.

This will leave CRSF_TELEMETRY_GPS_ENABLED and GPS telemetry will be the only telemetric packet that is sent back to your Zorro. Therefore, you may run slightly slower telemetry ratios (EG 1:32 or 1:64 and still get reasonable performance.

Additional

For shits and giggles, I decided to set the packet rate to 500 Hz and the telemetry ratio to 1:2, thus giving me a telemetry packet rate of 9921 bytes per second. On my telemetry screen (and the INAV glass cockpit screen), telemetry feedback performed admirably.
To push the envelope even harder, I set the packet rate to D500 and left the telemetry ratio at 1:2, which gave me a telemetry packet rate of 19921 bytes per second. Again, everything updated as it should and performed very well.