zz-cat / crsfforarduino Goto Github PK

View Code? Open in Web Editor NEW

122.0 7.0 18.0 406 KB

An Arduino Library for communicating with ExpressLRS and TBS Crossfire receivers.

License: GNU General Public License v3.0

C++ 100.00%

arduino-library expresslrs rc arduino crsf radio-control remote-control protocols

crsfforarduino's Introduction

CRSF for Arduino

Written and developed by

Cassandra "ZZ Cat" Robinson

Description

CRSF for Arduino brings the Crossfire Protocol to the Arduino ecosystem.
This library enables you to connect either a TBS Crossfire or ExpressLRS receiver to your development board, giving you access to telemetry and up to 16 11-bit proportional RC channels over a tried-and-true serial protocol.

The Crossfire Protocol (better known as CRSF) is used by both Team BlackSheep (in their Crossfire and Tracer receivers) and ExpressLRS. The latter of the two are well-known in the FPV drone community for their ultra low latency and long range control link.
By pairing CRSF for Arduino with an ExpressLRS transmitter and receiver, you have a control link between your RC handset and your development project that is robust in tough RF environments.

Documentation

CRSF for Arduino's documentation is now live.
Feel free to peruse the Wiki at your leisure.
For new users, it is strongly recommended that you read the documentation in its entirety.

Features

CRSF for Arduino comes packaged with these features:

16 11-bit proportional RC channels.
Diverse modern hardware support from the following architectures:
- ESP32, RP2040, SAMD21, SAMD5x, SAME5x, STM32, and Teensy 4.x.
Flight Modes, both custom and standard.
- Standard Flight Modes are based on the Flight Modes from Betaflight 4.3.
- Custom Flight Modes use text-based strings that you can assign custom names to for your bespoke purposes.
- Both Standard and Custom Flight Modes can be sent as Telemetry back to your controller.
Event-driven API.
Fully configurable.
- CRSF for Arduino can be tailored to suit the needs of your individual projects.
Telemetry.
- Attitude.
- Barometric Altitude.
- Battery.
- Flight Modes.
- GPS.

Software license

As always, I believe in freedom and I want to pass that freedom onto you. Which is why I am proud to license CRSF for Arduino to you under the GNU GPL v3.

Attributions

I give credit where credit is due. Because CRSF for Arduino isn't entirely my own idea, but built on the shoulders of giants. Here is a list of credits to those what helped to make this possible:

Inspiration for this library
- ExpressLRS
- Team BlackSheep FPV - The folks behind the CRSF protocol that both ExpressLRS and CRSF for Arduino uses.
References for CRSF for Arduino
- BetaFlight
- CRSF-WG
  - This is the official repository for The CRSF Protocol, which CRSF for Arduino is based on.
- RotorFlight
Third Party libraries
- Adafruit Industries
  - Adafruit_ZeroDMA
    - Author
    - License
  - Website

Contributing

If you would like to contribute to the development to CRSF for Arduino, here is what you can do:

Read my code of conduct and contribution guidelines;
Fork CRSF for Arduino;
Make your contribution to the codebase;
Submit your changes in your fork as a Pull Request back to CRSF for Arduino.

Your contributions are very welcome, and if it benefits the project and community, it will be merged into the Main-Trunk.

crsfforarduino's People

Contributors

Stargazers

Watchers

Forkers

ppetermann leonidchernichevskii mrrobot62 kristabel28 balinmitchell wolfthedesigner speshl albert-fit berickson aicortecs sheimy tzshin christophers090 velxundussa britannio ilcato eddy71

crsfforarduino's Issues

Docs guidance on how to wiring up a receiver.

Is there already an issue for this?

I have searched the issues and there is no existing issue for this feature request.

Is your feature request related to a problem?

I cannot find any reference in the GitHub or Wiki concerning how to configure pins or otherwise how to wire a receiver to my board or any other for that matter. (RPi Pico but I have lots of boards available.)

Describe the solution you'd like

Read any reference in the GitHub or Wiki concerning how to configure pins or otherwise how to wire a receiver to my board or any other for that matter. (RPi Pico but I have lots of boards available.)

Describe alternatives you've considered

I've (skim) read the Getting Started and Configuration wiki entries There i no mention of wiring that I can find.

Additional context

Using RPi Pico but I have ESP32, STM32F103 and Arduino alternatives also available.

CRSF frame parsing timeout repeatedly expires thus dropping all frames

Is there an existing issue for this bug?

I have searched the issues and there is no existing issue for this bug.

What development environment are you using?

PlatformIO

What board are you using?

Raspberry Pi Pico RP2040

What part of CRSF for Arduino is this bug related to?

RC Channels

Current behaviour

When I set up the library to get rc channel data, the callback will run but the channel data never changes.
I only encounter this issue when my Pi Pico is connected to the Adafruit PiCowbell CAN Bus.

Expected behaviour

The rc data should update as normal.

Steps to reproduce

I'm unsure how to reproduce this issue without the mentioned hardware.

Additional information

Removing the following lines fixes the issue.

CRSFforArduino/src/SerialReceiver/CRSF/CRSF.cpp

Lines 78 to 87 in 26952d5

    
           /* Reset the frame position if the frame time has expired. */ 
        
           if (currentTime - frameStartTime > timePerFrame) 
        
           { 
        
               framePosition = 0; 
        
               if (currentTime < frameStartTime) 
        
               { 
        
                   frameStartTime = currentTime; 
        
               } 
        
           }

So the frame expires before it is fully parsed, causing framePosition to be reset to 0 mid-way through parsing a frame and thus the CRC check will fail.

No such file or directory when compiling with PlatformIO and VsCode

Is there an existing issue for this bug?

I have searched the issues and there is no existing issue for this bug.

What development environment are you using?

PlatformIO

What board are you using?

Teensy 4.0

What part of CRSF for Arduino is this bug related to?

Build/Compile/Upload

Current behaviour

Compiling fails with "No such file or directory". This looks very similar to #19, but now the issue is with PlatformIO / VsCode and not the Arduino IDE.

   35 | #include "SerialReceiver/CRC/CRC.hpp"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
*** [.pio/build/blue/lib87d/CRSFforArduino/CRSFforArduino/src/CRSFforArduino.cpp.o] Error 1
.pio/libdeps/blue/CRSFforArduino/src/CRSFforArduino/src/Hardware/CompatibilityTable/CompatibilityTable.cpp:30:10: fatal error: ./CFA_Config.hpp: No such file or directory
   30 | #include "./CFA_Config.hpp"
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.
*** [.pio/build/blue/lib87d/CRSFforArduino/CRSFforArduino/src/Hardware/CompatibilityTable/CompatibilityTable.cpp.o] Error 1

Expected behaviour

No compiler errors.

Steps to reproduce

Using VsCode with a PlatformIO project, Add https://github.com/ZZ-Cat/CRSFforArduino to lib_deps in platformio.ini. Compile.

Additional information

I was able to "fix" the behavior for myself by creating a fork of the project at https://github.com/berickson/CRSFforArduinoFork where I #undef PLATFORMIO in several CPP files forcing it to use the same include paths that are used for Arduino. If I reference that repo from my platformio.ini libdeps, things compile fine.

Version 1.1.0 Development Tracking

I decided to create an issue for you all to see my priority list with development of Version 1.1.0, for the sake of transparency.
There is a milestone for Version 1.1.0, and you can keep up with my development schedule. However, this issue serves as a quick-glance central point-of-interest for you all to see where I am currently at with everything.

The list

The list here is based on my Development Schedule, where you can see what I am working on, and what's receiving my priority attention.
My workflow steps through each item in order of appearance for a given category.

In progress

Everything listed here is what's being actively worked on.

High Priority

Items listed here are where all of my focus is until every item in this sub-list is complete.

Write a source available licence directed at enterprises, and preserve the current licence for individuals only.
#103

Normal Priority

Items listed here is what I am working on, if there is nothing in my High Priority list.
New items are added on a "first-in, first-out" basis. IE New items are added to the bottom of this sub-list to ensure consistent progress is made.

#113

Low Priority

This sub-list is for items that may take a long time for me to get around to, given the quantity of my higher priorities.
Items are in "reverse chronological order" with the top-most item being the most recently added item, and the last item in this sub-list being the oldest item in this sub-list.
It is not imperative for me to complete anything added here, and some items MAY NOT make it into future releases for any reason.

#108

To-do

This sub-list is my "to-do" list.
New items are added here on a "first-in, first out" basis, where newer items are added to the bottom of this sub-list.
An item in this sub-list is assigned one of my three priorities when I promote it to "in progress".

#119

Planned

This is what I have rattling around in my mind, and need to get it out of the æther, and written here before my short-term memory loss gets the better of me.

Completed

This is the stuff what's been completed and will make it into the upcoming Version 1.1.0 release.

Stalled

Progress on anything listed here has ceased for any reason... usually it's because someone has ghosted me right after I tagged them in their Issue's linked Pull Request.
As per my Contribution Guidelines, I will use my discretion to determine what to do with a given item in this sub-list.
The rule of thumb here is to ensure that your Issue or Pull Request does not appear on this list. Once it's here, there are no guarantees it will make it into CRSF for Arduino's development, and your Issue or Pull Request is liable to be rejected.

Additional

During this time, I ask that you please be patient and understand that I am but one person working on CRSF for Arduino.
I have had my fair share of contributors as time has marched on, and they are not without my respect. I am very grateful for their efforts, and my contributors have been a huge help in lightening the load for me.

However, 98% of the time I am the only one working on CRSF for Arduino, and as its popularity grows, I need to prioritise my focus in order to preserve my work-life balance, negate burning myself out and to negate myself from being overwhelmed with a perceived "MUST do ALL the things... AT ONCE!!!!1111!!!11!"

If you are able, I encourage you to get involved with my project in the following ways:

Testing the code base on supported hardware;
Bug-testing and submitting feedback;
Pull Requests;

Note

For Pull Requests, you MUST have either GPG or SSH signing enabled before your first commit to your Pull Request's branch. All commits in your Pull Request MUST have the green verified badge next to them.
This is the same reason why you write your signature on an official document - It verifies that it's you that wrote the commit and not someone trying to impersonate you.

Refactor Compatibility Table

The situation

Currently, if CRSF for Arduino is flashed onto a target that is incompatible, you get the following message:
Incompatible device

This is all good and fine, assuming the device-on-question is legitimately incompatible.
However, say you wanted to flash to a target that has the same chip as the Arduino Zero, and you get the same message. In this scenario, it is not clear as to why it's not compatible, let alone informing you on how to go about requesting compatibility.

In both scenarios, CRSF for Arduino will not initialise.

Possible solution

If the architecture is already supported in the Compatibility Table, print a message along the lines of this in the Serial Monitor:

Your device has the same architecture as other supported targets. However, the device itself is not yet supported.

At that point, I could point you guys to here with something along the lines of:

You can request your development board by:
1. Go to https://github.com/ZZ-Cat/CRSFforArduino and click on the Issues tab.
2. Check that someone else hasn't bet you to the punch, regarding your Issue.
3. Click New Issue and select the Devboard Compatibility Request template.

Permissive execution on unsupported development boards with compatible architectures

This is where it could get a bit complicated (especially for PlatformIO users), but I would like to explore this possibility:

You have a development board with the same chip as the Arduino Zero.
Either your particular variant of the chip itself or your development board is not present in the Compatibility Table.
CRSF for Arduino could still execute safely, but display the above notices in the Serial Monitor when CRSF_DEBUG_ENABLED is set to 1 at compile time, instead of outright failing to initialise.
Additionally, a compiler warning could also be displayed.

I feel like there is a broad enough architecture support now to warrant relaxing some of the restrictions that the Compatibility Table imposes. If I keep it as it is right now, it's increasingly likely that it will become more of a hindrance, moving forward.

PPM output

Any support for PPM output and using Bluepill board?

Can I communicate and interact with TX?

Is there already an issue for this?

I have searched the issues and there is no existing issue for this feature request.

Is your feature request related to a problem?

I want to create a simple control system instead of Opentx, Because many tx communicate in half-duplex and only have one GPIO connection, I don’t know whether CRSFforArduino currently supports it.

Describe the solution you'd like

Use esp32 to communicate with tx, and then use mobile phone Bluetooth to communicate with esp32 for parameter configuration.

Describe alternatives you've considered

There is currently no open source alternative

Additional context

I just want to make a very simple remote control with no screen, only a switch button and voice broadcast, and the rest are set up through the mobile phone's Bluetooth. For example, a mini handle remote control or a car or boat remote control

Compiling fails for the Arduino Zero and entire Arduino MKR series boards

Is there an existing issue for this bug?

I have searched the issues and there is no existing issue for this bug.

What development environment are you using?

PlatformIO

What board are you using?

Arduino Zero

What part of CRSF for Arduino is this bug related to?

Build/Compile/Upload

Current behaviour

While I was conducting a compile test across all of the supported development boards in the Compatibility Table, I noticed that compiling firmware fails for the following development boards:

MKR Fox 1200
MKR GSM 1400
MKR NB 1500
MKR Vidor 4000
MKR WAN 1300
MKR WAN 1310
MKR WiFi 1010
MKR Zero
Zero (Debug Port)
Zero (Native USB Port)

As noted in the list above, this issue affects the Arduino Zero and the entire Arduino MKR series of development boards.

Expected behaviour

Compiling for the Arduino Zero and all Arduino MKR series development boards should succeed, as CRSF for Arduino is compatible with them.

Steps to reproduce

Select any one of the boards from the aforementioned list above.
Compile the selected target.
See error.

Additional information

Screenshots: Compiler errors for Arduino Zero. This applies to the entire Arduino MKR series too.

Additional: All other boards (Adafruit's Metro, Feather, and QtPy boards; Seeed Xiao; Teensy 3.x and 4.x; and the entire ESP32 line) are unaffected by this issue. It is only isolated to the Arduino Zero and all Arduino MKR boards.

fatal error: CompatibilityTable.h: No such file or directory

Discussed in #19

^{Originally posted by grey1808 May 31, 2023}
Greetings my friend! Please tell me what am I doing wrong. I'm sorry, I'm new to arduino and maybe the question is very obvious, but I can't figure it out.

I included the library and decided to compile your example, but it didn't work because I get an error at the compilation stage:

Arduino: 1.8.19 (Linux), Pay:"Arduino M0" /home/grey/Arduino/libraries/CRSFforArduino-Main-Trunk/src/lib/CRSFforArduino/CRSFforArduino.cpp:28:10: fatal error: CompatibilityTable.h: No such file or directory #include "CompatibilityTable.h" ^~~~~~~~~~~~~~~~~~~~~~ compilation terminated. exit status 1
Please tell me how to connect this CompatibilityTable.h

Re-factor UART pin assignments.

The situation

CRSF for Arduino defaults to Serial1 for UART.
For most targets, this means pins 0 and 1 for Rx and Tx, respectively.
This is okay if you're using Arduino or Adafruit Metro or Adafruit Feather targets, however this is problematic for targets that don't use pins 0 and 1 for UART - Especially Seeed Xiao and Adafruit QtPy boards that are built around ESP32 chipsets.

Possible solutions

Use hardware-dependent default pin-outs instead of arbitrary pin-outs

Looking at the pins_arduino.h header in each target's variants subfolder, there are references to RX and TX which set the default pin-outs for the first UART port. CRSF for Arduino could take advantage of this instead of defaulting to pins 0 and 1.

Use arbitrary UART port and pin assignments

This could effectively grant you the ability to tell CRSF for Arduino what particular pins your receiver is connected to and what UART port the pins are using. IE Customisable port and pin assignments.
The limiting factor here is the number of UART ports is hardware-dependent. Some targets have two possible UART ports, while others may have up to six possible UART configurations.

For targets that have only one UART port, you will not be able to take advantage of customisable UART pin-outs.
This is a hardware limitation that is outside the scope of CRSF for Arduino.

writeRcChannel - Control CRSF Transmitters with CRSFforArduino

Is there already an issue for this?

I have searched the issues and there is no existing issue for this feature request.

Is your feature request related to a problem?

I'm working on a transmitter and CRSFforArduino seems so close.

I'm not alone: #80

Describe the solution you'd like

writeRcChannel, just like readRcChannel, but backwards!

Describe alternatives you've considered

Reading the internals of the ExpressLRS code to figure out how I might be able to jerry-rig something.
Using PPM control instead

Additional context

Great project! Thank you!

"CRSF for Arduino initialization failed" error on ESP32

Is there an existing issue for this bug?

I have searched the issues and there is no existing issue for this bug.

What development environment are you using?

Arduino IDE

What board are you using?

Adafruit Feather ESP32

What part of CRSF for Arduino is this bug related to?

Other (please specify)

Current behaviour

First of all thanks for supporting this libraray! I think this is great job!

I'm trying to get it running on my ESP-WROOM-32 dev board with Betafpv light 2400 RX. I'm using this example. I changed rx port to 25 and tx port to 27 according to pinout diagram (also did try 16 and 17 which are physical pins of the board). But I'm getting this error: "CRSF for Arduino initialization failed".

So maybe I'm doing something wrong or this board is not supported yet?

Expected behaviour

crsf.begin() returns true

Steps to reproduce

My wiring:

receiver TX - RX2 (16 pin)
receiver RX - TX2 (17 pin)
receiver GND - GND
receiver 5V - VIN & 5V from power supply

Additional information

No response

Version 1.0.0 Development Tracking

Overview

Copied over from #49.

This is THE BIG ONE! =^/,..,^=

CRSF for Arduino's first official major release is slated to come out in early 2024, and this is the issue to track its development.

Once everything is all said-and-done here, Version 1.0.0 will be released to the public, and you will be able to access it from my Releases section.

To-Do List

In order of priority, here is what needs to be done before Version 1.0.0 is released:

Anything else that crops up will be added to this list.

Notes

Arbitrary/Custom UART assignments

Instead of writing this one myself, I found it better to bring up Arduino's HardwareSerial class as a parameter to CRSF for Arduino's constructor. Instead of you defining pins or ports as parameters to this constructor, you will be able to provide your own HardwareSerial implementation and pass that in.
This gives you greater flexibility, at the expense of increased code complexity. If you're doing this on SAMD21 and SAMD51 architectures, you already know what I am referring to when I say "complexity". I don't know how it is for you Teensy and ESP32 users. However, for us SAMD users... heh... Hide the Pain Harold intensifies.

Documentation

For the time being, I have decided to update the wiki right here on GitHub.
This will serve as the main documentation source in the meantime while I learn more about Docusaurus.

Throughout the development of Version 1.0.0, the main README will be updated to reflect recent changes per merged Pull Request to the Main-Trunk. This ensures that those that are cloning CRSF for Arduino directly off the Main-Trunk know what thar getting themselves into.

Codebase standardisation

The repository for the official CRSF Protocol is now available for public use.
At the time of writing this, the documentation for it is still being written for the existing protocol.

What I would like to do is have CRSF for Arduino be an accurate representation of the documentation of the CRSF Protocol itself. That way, if you would like to know more about the protocol itself, you can easily refer to that documentation and cross-reference it with my codebase here.

STM32 targets

Gods, I knew this was going to be a rabbit hole, but WOW! Just... WOW!
So, I added nearly the entire line-up of F103 and F4 targets. Literally the entire F405, F722, and H745 line-up.
Plus, I added Arduino's Nicla, Opta and Portenta H7 targets.
Doing STM32 support got very monotonous for me, and was starting to feel like I was bashing my head against a wall.
I feel like there's plenty of chipsets now for most people to be happy with. I didn't add literally all the STM32 chips. Because at this time, it simply isn't realistic to do it.
If someone wants me to add in their super-obscure target, they are more-than-welcome to hit me up in my Issues tab about it.

While I am on that note...

Issues

Please do not copy-and-paste the same phrase over-and-over in your Issue.
You need to be specific about what it is you need me to do. If you're too vague, I will ask you to be more specific.
If I get no response from you or your response is convoluted or incoherent, I will close your Issue and move on.

Bring back compatibility with the Arduino IDE

Okay, it looks like I broke my entire library, when I ported it over to PlatformIO.
That & since I did the port, I have seen its usage (via my insights) decline & basically stop.

I have recently discovered that PlatormIO has retained backward compatibility with practically every Arduino library in existence, & the original reason why I created CRSF for Arduino was to bring compatibility with ExpressLRS & TBS Crossfire RC receivers to the world of Arduino.
By going straight to Platform IO & (by extension) removing support for the Arduino IDE altogether, I feel like I have made a grave mistake in abandoning the handful of users that CRSF for Arduino was already starting to acquire. This was purely an unintentional side-effect that I did not take into consideration. Blatantly abandoning my user base goes against one of my core values as a developer, & I feel really bad for doing this to you guys.

So, to put things right, over the next few days, I will figure out a way to bring back compatibility with the Arduino IDE & at the same time try to retain forward compatibility with PlatformIO as well.

Keep an eye on my Pull Requests, & by the time I am done with this, I will put out a follow-up release of CRSF for Arduino - with full compatibility with the Arduino IDE.

PS: I am posting this here in my Issues tab as a reminder to myself to get this done.

Also, you guys are quite welcome to get in touch with me either here (in the comments section below) or over in the discussions tab.
I genuinely want to know your thoughts on my library, where you reckon I need to go with it, what could be done with it etc. I don't bite. =^/.~=

Without engagement from you guys, I can only make assumptions about what you want out of CRSF for Arduino. These assumptions are based exclusively on the data in my insights tab... & quite frankly, I am not a fan of doing that.

Read CRSF Telemetry Mirrored to Radio Aux Ports

Is there already an issue for this?

I have searched the issues and there is no existing issue for this feature request.

Is your feature request related to a problem?

I'm looking for more control over my existing RC radio, without having to build a custom one from scratch. Critically, I'm interested in keeping the existing radio hardware in-the-loop. I'm currently using a microcontroller to send an SBUS trainer signal to one of the radio's AUX ports control some of the RC channels. This approach works, but is incomplete because it doesn't give me access to the radio's telemetry information. I want to use that same microcontroller to read the radio's telemetry as it's being mirrored to the other AUX port.

Describe the solution you'd like

I'd like to be able to connect the TX line of one of my radio's AUX ports to a microcontroller and read the CRSF telemetry that is being mirrored to that port. This is likely similar to an RX-only version of #88.

Describe alternatives you've considered

I have considered using USB-VCP telemetry mirroring to read the telemetry on a PC using Python (example). However, this requires additional (and relatively large) hardware and is inconvenient.

I could also potentially use the above method with MicroPython on a microcontroller, but that will likely come with a large speed penalty, as well as implementation issues with other areas of my project that depend on Arduino libraries.

Additional context

I am using a Radiomaster TX16S running EdgeTX, and would prefer to use a Xiao RP2040 as the microcontroller.

Example CRSFforArduino example "rc_channels" not working, Library not installing correctly, no simple way to enter or change Rx/Tx pin numbers, not enough validation or testing before releasing.

Is there an existing issue for this bug?

I have searched the issues and there is no existing issue for this bug.

What development environment are you using?

Arduino IDE

What board are you using?

Adafruit Feather ESP32

What part of CRSF for Arduino is this bug related to?

Build/Compile/Upload

Current behaviour

The above Arduino IDE v2.x.x instructions to not work using the Add .ZIP Library function. It does work by extracting the ZIP and manually moving the CRSFforArduino-1.0.1 folder to the ".../Arduino/libraries" folder.

The code does compile now. However, there is no output for the rc_channels example. there is no serial monitor output such as "CRSF for Arduino initialisation failed!" or "RC Channels Example" or "Ready" as you might expect by reading the example code.

There is no Serial1.begin such as Serial1.begin(420000, SERIAL_8N1, D0, D1); in the setup() and no comments in the code where to configure the Rx/Tx Serial1 pins. I could not find any documentation that provides information to set up the board UART that is wired to the ELRS Rx.

I am using an Arduino Nano ESP32 connected via a USB port. My hardware setup works perfectly right out of the box with the AlfredoCRSF library once the Rx and Tx pins are changed to "crsfSerial.begin(CRSF_BAUDRATE, SERIAL_8N1, D0, D1);". This line of code is right in the setup() and easy to spot.

I am using a RadioMaster TX16S with a RadioMaster RP 2 Rx. My hardware test setup work perfectly with the AlfredoCRSF library.

At this point, I do not know what else I can do to help. What is required is more pre-release testing to ensure that a user can simple load a library and run an example and have it work right out of the box. Unfortunately, this has not been my experience. I read similar comments from another thread.

At some point down the road I will pick this up and do some more testing again should there be a 1.1 release.

Expected behaviour

A working example

Steps to reproduce

See above.

Additional information

No response

Strange behaviour

I am using Arduino Uno, transmitter radiomaster tx 12 and receiver Radiomaster RP3.
95% times the library does not register changes in transmitter channels.
What can be an issue and how can I debug it?

Support for Raspberry Pico

Minimum requirements

Core clock speed is 48 MHz or faster?
Is the CPU an ARM Cortex M0+ or later?
Is the host microcontroller's UART peripheral able to support 420,000 (or higher) baud rate(s)?
Is your development board currently supported in the Arduino IDE?

What development board would you like me to add?

Would it be possible to add RP2040 support? eg Waveshare RP2040 Zero or any other RP2040 based DevBoard like the original Raspberry Pi Pico.
Thanks!

Add Attitude/Artificial Horizon telemetry

Overview

Over time, I am adding full telemetry support as modules based on the types of telemetry being added. These are:

Each module will have its own Issue, Development Branch & Pull Request associated with it, with the end goal of CRSF for Arduino eventually having full telemetry support.
Over time, I will make my way through each module.

This Issue is to remind myself to add Attitude telemetry to CRSF for Arduino.

What's needed

Attitude telemetry requires the following values:

Roll (in radians per second)
Pitch (in radians per second)
Yaw (in radians per second)

Additional

Gear list

The gear that I am using for this is as follows:

Controller: RadioMaster TX16S Max Edition w/EdgeTX version 2.9.0 Nightly
- Lua script: iNav telemetry widget
Transmitter Module: RadioMaster Ranger w/ExpressLRS version 3.3.0
Receiver: RadioMaster RP3 diversity w/ExpressLRS version 3.3.0
Development board: Adafruit Metro M4 Express

Also...

I am no longer writing my own hardware drivers for each telemetric sensor, because it is better for you to provide your own appropriate sensor modules & their respective hardware drivers. Taking this approach removes the need for me to reinvent the wheel, as there is already a myriad of fantastic sensor drivers out there.
All I need to do here, is give you a means of passing data in from your sensors to CRSF for Arduino as telemetry.

Seeed Studio XIAO nRF52840 compatibility

Minimum requirements

Core clock speed is 48 MHz or faster?
Is the CPU an ARM Cortex M0+ or later?
Is the host microcontroller's UART peripheral able to support 420,000 (or higher) baud rate(s)?
Is your development board currently supported in the Arduino IDE?

What development board would you like me to add?

Hi, I'm trying to use a Seeed Studio XIAO nRF52840 with this library.

As far as I can tell it conforms to the requirements (I think it uses a Cortex M4 though I'm not quite clear on the specifics).

Could you add this functionality?

Teensy 3.x, 4.x

Minimum requirements

Core clock speed is 48 MHz or faster?
Is the CPU an ARM Cortex M0+ or later?
Is the host microcontroller's UART peripheral able to support 420,000 (or higher) baud rate(s)?
Is your development board currently supported in the Arduino IDE?

What development board would you like me to add?

PJRC Teensy 3.x, 4.x
Summary/Comparison table: https://www.pjrc.com/teensy/techspecs.html

Only Teensy 3.2 and 3.5 are 5V tolerant, but 3.x boards are being phased out. Definitely could just use a logic level converter to solve this issue though.

All Teensy boards are supported in Arduino IDE: https://www.pjrc.com/teensy/td_download.html
The additional board manager URL is https://www.pjrc.com/teensy/package_teensy_index.json

I'm not too sure where to find information about the exact baud rate, I believe that can be set. More information here: https://www.pjrc.com/teensy/td_uart.html
Teensy 4 is definitely able to support the requested baud rate. "On Teensy 4 boards, the serial ports normally are limited to 6 Mbit/sec baud rate. However, maximum baud rate can be increased to 20 Mbit/sec by reconfiguring the UART clock source."

Teensy 3.2: 72 MHz, Cortex-M4
Teensy 3.5: 120 MHz, Cortex-M4F
Teensy 3.6: 180 MHz, Cortex-M4F
Teensy 4.0/4.1: 600 MHz, Cortex-M7

The Teensy is a very commonly used board when higher speeds are demanded. Hope you will be able to add compatibility for the board. Thank you very much.

Process link statistics from incoming packets.

Overview

Before I start working on #69, I need to implement a means of processing the Link Statistics packet that's present in the CRSF stream from the receiver.

Details

In another RC related project of mine, I processed the RSSI, Link Quality, Signal-to-Noise Ratio and Transmitter Power fields of the Link Statistics. I wrote fail-safe logic that was a state machine, and it took priority above extrapolating normal RC channels data from the CRSF data stream from the receiver.
I used arbitrarily set thresholds for RSSI and Link Quality to determine what constituted a "fail-safe" - IE the receiver "losing sight" of the transmitter.

I may base my fail-safe implementation on that.
However, I am leaning more towards making CRSF for Arduino event-based, as evident by my Flight Modes implementation that was introduced in #47.

Add failsafe handling

Discussed in #51

^{Originally posted by hw999 December 4, 2023}
I would like to translate CRSF-channel information into a SBUS-data stream. The SBUS protocol has flags for lost frames and failsafe. I wonder : are there any such flags in the CRSF-protocol and if yes - are they implemented in the library? At first glance I did not discover anything that would show how FS and LF is handled.
Could you please spend a few sentences on how CRSF handles LF and FS ?

How this could be implemented

LF in this instance translates to "lost frame", which happens when a received RC frame fails the CRC check. In the context of SBUS, this is done in hardware, rather than in software. In the context of CRSF, this would need to be done in software.
A simple boolean flag could be retrieved from the serialReciever::CRSF::receiveFrames() function when the CRC on the received frame fails, and I could pass that flag up through to the Sketch Layer.

FS is the failsafe flag, which is a representation of the received frame that has this flag set.
This is where shit could get complicated, because there really is no way to determine a "proper" failsafe.
What most implementations do (or at least the ones I have seen, such as Betaflight, INAV, and RotorFlight) is they'll have a combination of a timeout, the number of consecutive CRC sum fails, and they'll likely be watching the link statistics for things such as RSSI and Link Quality.

There was another project (not listed here on my GitHub) that I worked on, and I wrote and tested my own logic for failsafe implementation.
This provides me with a solid frame of reference for what I could implement here in CRSF for Arduino. In that project, I wrote logic that watched the Link Quality and RSSI fields from the Link Statistics packet in the CRSF data stream from the receiver.

Arduino IDE builds are broken

Discussed in #92

^{Originally posted by ZZ-Cat March 5, 2024}
This means that if you try to build CRSF for Arduino v1.0.0 in the Arduino IDE, the build process will fail with the error
Compilation error: CRSFforArduino.hpp: No such file or directory.

This appears to be caused by a line break in one of the keys in CRSF for Arduino's library.properties file.
The key in question is the paragraph key, which is suspected to be the likely culprit.

I am currently investigating the cause of this bug, and if the above is the cause, then it's a fairly quick fix.
However, in my own experiences in coding, nothing is as straightforward (or as quick) as it may seem at face value. Once the fix is done, a cut from the Version 1.0.x Maintenance Branch will be available in the Releases section as Version 1.0.1.

This has been created from the PSA above, to get development of this bug into the pipeline.
Currently, this is top priority, thus delaying development of Version 1.1.0 until this is resolved.

ESP32

Minimum requirements

Core clock speed is 48 MHz or faster?
Is the CPU an ARM Cortex M0+ or later?
Is the host microcontroller's UART peripheral able to support 420,000 (or higher) baud rate(s)?
Is your development board currently supported in the Arduino IDE?

What development board would you like me to add?

It would be very helpful to have running version based on ESP32-DEV (like a WROOM)

Tensilica Xtensa LX6
32 bit Dual-Core @ 160 / 240Mhz

Most time a lot of libraries are compatible to ESP32 devices

Passthrough over CRSF

This is a quick minder to myself to add Passthrough over CRSF to my library.

I know for a fact that, by default, CRSF itself is pretty limited in terms of what telemetry devices it can support.
So, adding Passthrough may help with that. Not only that, adding Passthrough will make my library compatible with Yaapu's Telemetry Script.

Imagine flying a helicopter with that, eh? EH?
That's why I love doing this; make cool shit & put it on the internet. =^/,..,^=

Add Battery & Power Consumption telemetry

Overview

Over time, I am adding full telemetry support as modules based on the types of telemetry being added. These are:

This Issue is to remind myself to add Battery telemetry to CRSF for Arduino.

What's needed

Battery telemetry requires the following values:

Voltage (in millivolts)
Current (in milliamperes)
Energy (in milliampere-hours)
Battery remaining (as a percentage)

Additional

Gear list

The gear that I am using for this is as follows:

Controller: RadioMaster TX16S Max Edition w/EdgeTX version 2.9.0 Nightly
- Lua script: iNav telemetry widget
Transmitter Module: RadioMaster Ranger w/ExpressLRS version 3.3.0
Receiver: RadioMaster RP3 diversity w/ExpressLRS version 3.3.0
Development board: Adafruit Metro M4 Express

Also...

please support stm32 chip in arduino fremework and vscode pio

Is there already an issue for this?

I have searched the issues and there is no existing issue for this feature request.

Is your feature request related to a problem?

please support stm32 chip in arduino fremework and vscode pio

Describe the solution you'd like

please support stm32 chip in arduino fremework and vscode pio

Describe alternatives you've considered

please support stm32 chip in arduino fremework and vscode pio

Additional context

No response

Raspberry Pi Pico W

Minimum requirements

Core clock speed is 48 MHz or faster?
Is the CPU an ARM Cortex M0+ or later?
Does the host microcontroller have at least 32 KB of flash memory?
Is the host microcontroller's UART peripheral able to support 420,000 (or higher) baud rate(s)?
Is your development board currently supported in the Arduino IDE?

What development board would you like me to add?

It seems like this is the only change to make: britannio@d699599

Arduino Nano 33 IoT Not Compatible

Is there an existing issue for this bug?

I have searched the issues and there is no existing issue for this bug.

What development environment are you using?

Arduino IDE

What board are you using?

Arduino Nano 33 IoT

What part of CRSF for Arduino is this bug related to?

Compatibility Table

Current behaviour

With the debug flag enabled. I get the following when calling crsf.begin()

[Serial Receiver | INFO]: Initialising... 
[Compatibility Table | DEBUG]: Board is Incompatible device
incompatible.
Incompatible device

[Serial Receiver | ERROR]: Devboard is not compatible.

Expected behaviour

Expected crsf to begin.

Steps to reproduce

Issue can be reproduced with the channels example.

Additional information

Attempting to log the name that it is comparing against shows the name as empty.

    bool CompatibilityTable::isDevboardCompatible(const char *name)
    {
        // Debug.
        // Serial.print("[Compatibility Table | DEBUG]: Board is ");

        if (strcmp(name, deviceNames[DEVBOARD_IS_INCOMPATIBLE]) == 0)
        {
            // Debug.
            Serial.println("incompatible.");
            Serial.println(name);

            return false;
        }

        else
        {
            // Debug.
            // Serial.println("compatible.");

            return true;
        }

        // return strcmp(name, deviceNames[DEVBOARD_IS_INCOMPATIBLE]) != 0 ? true : false;
    }

GPS telemetry

Overview

After my disastrous first attempt at doing telemetry, I have decided to split adding full telemetry support up into smaller & easier to manage modules, based on the types of telemetry being added. These are:

Attitude/Orientation
Altitude
Battery
Current/Power Consumption
GPS

What's needed

This Issue is to remind myself to add GPS telemetry to CRSF for Arduino.

Therefore, I need to write code that reads GPS NMEA 0183 sentences & converts that into meaningful data that the CRSF protocol can work with. I will need to write a new GPS hardware driver as well.

The new driver will have similar features to my previous attempt, plus a few extra goodies:

Selectable update rates up to 10Hz (subject to GPS hardware availability)
- I have an idea that expands on this, where the update rate is dynamic, based on whether-or-not a connected Receiver is sending an Armed/Disarmed field in the RC Channels packet. For ExpressLRS, this is Channel 5 or "AUX1".
- Additionally, I would like to trial a low-power mode that kicks in when that same Channel 5 value is "Disarmed", & the GPS goes to its full update rates & full power when Channel 5 is "Armed".
- Both of these two things may not happen, at this stage. Because I don't see how much of a benefit this functionality could bring to CRSF for Arduino. So, no guarantees, here.
Automatic baud rate negotiation (subject to the selected update rate)
- Previously, I had this setup based on a pre-set baud rate (EG 115200) & the microcontroller would poll the GPS at incrementing baud rates until valid data came back & the baud rate matched that of the set baud rate. I may want to revise this, & have the baud rate set automatically based on the chosen set of NMEA sentences coming in from the GPS & the chosen update rate, as both of these things directly influence the final baud rate.
DMA (subject to hardware capabilities)
- This will be enabled globally at compile time, by default.
Hardware Serial
- For SAMD21 & SAMD51 microcontrollers, I will be using a hardware SERCOMx port & I will do my best to put it adjacent to the pins where you connect your ExpressLRS receiver. Some smaller development boards may not allow this.
- Another reason why older generation boards like the Arduino UNO R3 aren't compatible with CRSF for Arduino.

Once I have this working, you will be able to view Location, Ground Speed, Heading, Altitude & Number of Satellites in View on your EdgeTX controller.

Additional

Gear list

The gear that I am using for this is as follows:

Controller: RadioMaster TX16S Max Edition w/EdgeTX version 2.9.0 Nightly
- Lua script: iNav telemetry widget
Transmitter Module: RadioMaster Ranger w/ExpressLRS version 3.2.1
Receiver: RadioMaster RP3 diversity w/ExpressLRS version 3.2.1
Development board: Adafruit Metro M4 Express
GPS: Adafruit Ultimate GPS Breakout V3
- Yea, yea. I know it's outdated. But, it's what I currently have on-hand & getting things shipped to New Zealand takes way too long.

Also...

Despite what #3 & #5 will have you believe, I somehow managed to totally obliterate all existence of that code & I managed to do a "clean commit". This means that no code relating to any sensor hardware drivers exist, despite things like Pull Requests & Commits alike referencing them being added.

Still to this day, I have no idea how I even managed to do that, but it totally yeeted all of my work regarding telemetry.
Because of that, I am having to start this portion of CRSF for Arduino from scratch all over again. Yay. =-/.-=
...& it has taken me this long to get back into it & convince myself that it's definitely worth doing.
Especially now that I know that other people are benefiting from my project.

Automatic UART baud-rate configuration

Overview

According to my information there are some discrepancies between the "agreed upon" baud-rate for CRSF.
The official baud-rate is supposed to be 416666, not 420000. However, ExpressLRS receivers use 420000 as their baud-rate and I have mostly been developing CRSF for Arduino for use with ExpressLRS receivers.

I am aware that in CRSF v3, there is an automatic baud-rated negotiation that takes place. However, CRSF for Arduino currently supports CRSF v2.
CRSF v3 will not be implemented in the upcoming release of Version 1.0.0.

For now, this is to remind myself to write up auto-baud logic to help deal with some of the baud-rate inconsistencies between TBS receivers and ExpressLRS receivers.

Teensy 4.1 not working

Is there an existing issue for this bug?

I have searched the issues and there is no existing issue for this bug.

What development environment are you using?

Arduino IDE

What board are you using?

Teensy 4.1

What part of CRSF for Arduino is this bug related to?

Build/Compile/Upload

Current behaviour

The rc_channels code on a teensy 4.1 uploads but only boot loops. It gets stuck on the crsf->begin(); line.

Expected behaviour

Expect it to show the channels

Steps to reproduce

Upload the code to a teensy 4.1

Additional information

No response

	/* Reset the frame position if the frame time has expired. */
	if (currentTime - frameStartTime > timePerFrame)
	{
	framePosition = 0;

	if (currentTime < frameStartTime)
	{
	frameStartTime = currentTime;
	}
	}