Skip to content

CRSF rewrite to be 'more' spec compliant #3198

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 45 commits into
base: master
Choose a base branch
from
Open

CRSF rewrite to be 'more' spec compliant #3198

wants to merge 45 commits into from

Conversation

pkendall64
Copy link
Collaborator

@pkendall64 pkendall64 commented May 2, 2025 •
edited
Loading

This is a rather large set of code changes to extend our CRSF implementation to be more compliant with the CRSF specification. https://github.com/tbs-fpv/tbs-crsf-spec/blob/main/crsf.md

Notes

  1. Adds a new framework with three new classes for implementing the CRSF spec
    1. CRSFRouter - this is the head class of the CRSF framework. The endpoint is responsible for maintaining the routing table and for forwarding messages to the correct endpoints and/or connectors.
    2. CRSFEndpoint - the target for CRSF messages, this will handle all messages directed at it's device_id.
    3. CRSFConnector - a connection to another device in the CRSF network.
  2. Adds implementation of the above classes
    1. TXModuleEndpoint - handles all the CRSF messages for the TX Module e.g. the parameter read/write commands from the Lua script.
    2. TXOTAConnector - sends the CRSF messages OTA to the RX; has special handling for the RC commands.
    3. RXEndpoint - handles all the CRSF messages for the RX, similar to the TXEndpoint.
    4. RXOTAConnector - sends the CRSF messages OTA to the TX; has special handling for the LinkStats.
    5. SerialCRSF - connector for delivering messages to any CRSF connected device e.g. flight controller, GPS etc.
    6. SerialSmartAudio - a 'fake' connector that translates Betaflight CRSF wrapped MSP messages into SmartAudio for a directly connected SmartAudio VTX.
    7. SerialTramp - similar to the SerialSmartAudio, but for IRC Tramp VTX control.

Future Changes

  1. Extend MSPVTX/VTX to become an endpoint so it can be configured as any other CRSF device for which channel/power etc is selected.
  2. The Betaflight config system (TCPSocket) should become an endpoint for translating and forwarding MSP messages to the FC.
  3. The GPS, Tramp and SmartAudio serial devices could become endpoints so they can be configured via CRSF.

Testing

  • Analog VBAT (overridden by CRSF message)
  • Barometer (overridden by CRSF message)
  • MSPVTX
  • Serial GPS
  • HoTT Telemetry sensors
  • SmartAudio
  • Tramp
  • Betaflight config via wifi
  • Backpack wireless Pan/Tilt/Roll
  • Handset PPM/CRSF auto detect
  • MAVLink
  • VTXAdmin
  • Arm on a switch (EdgeTX 2.11)
  • RX passthrough flashing
  • Changing RX protocol from CRSF and back again via Lua

@pkendall64
Copy link
Collaborator Author

@wimalopaan Can you check if this satisfies your needs for #2901, #2941, #2975 and #3160
@KissUltra Can you check that this will work for you needs #3009

This was linked to issues May 2, 2025
Allow other than 0xc8 as extended address #2901
Open
ELRS receiver doenst respond / doesnt pass through device enumeration requests on CSRF protocol. #3009
Open
Serial2: output all CRSF frames #3160
Open
@wimalopaan
Copy link

Oh, cool, that you did spend a lot of work on it!!!

This PR is against master, would it be applicable to 3.x.x-maintenance also (for #2975) ?

Yes, I will test that, but that will take some days ...

@KissUltra
Copy link

Very cool. Will check against my osd code. Thank you.

@pkendall64
Copy link
Collaborator Author

This PR is against master, would it be applicable to 3.x.x-maintenance also (for #2975) ?

No this will not be applicable to 3.x.x

@pkendall64
Copy link
Collaborator Author

pkendall64 commented May 3, 2025 •
edited
Loading

When testing this please remember that you will need to flash both the TX and the RX as the master branch is NOT compatible with 3.x.x

@KissUltra
Copy link

KissUltra commented May 3, 2025 •
edited
Loading

Just did quick test, and my ELRS detection is no more :)
I am using:

uint8_t tmp[6] = { 0xc8, 0x04, 0x28, 0xEC, 0xC8, 0 }; //request device info

NO TX powered. Works fine with latest release.

Getting no response back. Something changed in this area?

@pkendall64
Copy link
Collaborator Author

Yes, I've broken it. I'll get back to you when it's fixed... again

@pkendall64
Copy link
Collaborator Author

Getting no response back. Something changed in this area?

No, but yes. No data is output on the serial port of there is a model mismatch or team-race is on and not on the selected model. The issue is that model matched is false by default, so until there is a valid connection from a TX then nothing wull be output.
This will need to change, but in the meantime you should it should work if you have a TX connected.

@KissUltra
Copy link

Should work without ANY radio. I will wait for your fix for next test. You should be able to configure just RX.

@pkendall64
Copy link
Collaborator Author

Should work without ANY radio. I will wait for your fix for next test. You should be able to configure just RX.

Ok, I've done some more work on this and it should be all good now.
Please let me know if you have any issues.

@KissUltra
Copy link

Just did some test. Device info indeed works now. Devices enumeration from osd - still doesnt.

@KissUltra
Copy link

Enumeration works using sending to broadcast address:

uint8_t tmp[6] = {0xc8, 0x04, 0x28, 0x00, 0x80, 0}; //  osd id is 0x80

@pkendall64
Copy link
Collaborator Author

Just did some test. Device info indeed works now. Devices enumeration from osd - still doesnt.

What command are you sending that doesn't work? i.e. the full command.

If I send a broadcast message in the the serial port from 0x80 then the 0x80 is added as a known device on the serial connector.
Then if I query for a parameter from the CRSF_RECEIVER (0xEC) e.g. parameter 1 from the 0x80 device then the response is send out the serial port.

@KissUltra
Copy link

as u see, i send from 80 to serial receiver BROADCAST message. All devices must respond back VIA receiver. That doesnt happen. Keep in mind, FC has 2 addresses (and potentially 10 if 8 esc are registered). All of it behind fc endpoint. So, if 80 sends a broadcast, 80 should be registered on receiver endpoint towards FC. then reveiver should respond back.

@KissUltra
Copy link

Where are u located? I can send you ultra if u like.

@pkendall64
Copy link
Collaborator Author

Where are u located? I can send you ultra if u like.

Can we connect on discord. Might make things easier

@KissUltra
Copy link

Yes of course.

FedorCommander

@KissUltra
Copy link

Screenshot 2025-05-04 at 11 30 12 When it will start from 0xC8 aka sync byte, should be fine. :)))

@KissUltra
Copy link

aha!
Screenshot 2025-05-04 at 21 41 47
Screenshot 2025-05-04 at 21 41 19
Screenshot 2025-05-04 at 21 41 40

@wimalopaan
Copy link

wimalopaan commented May 8, 2025 •
edited
Loading

Tracing also the packets that come out of the TX-module shows, that not all device-info packages that the receiver gets come thru to the TX module.

On the attached LA trace you see on the RX:RX line the four device-info packages going to the receiver. But on the TX:TX line you see only two of them coming out of the TX-module.

la_2_elrs4

This may look like some type of congestion on the over-the-air protocol.

@wimalopaan
Copy link

If only one external device responds to a device-ping package, its responding package only occasionally comes thru to the TX-module.

The next image show the receiver receiving a device-info package on line RX:RX (length: 40) which does not come out of the TX-module:
la_3_elrs4

This image shows the same where with success:

la_4_elrs4

Out of 5 device-ping packages, of the 5 devive-info answers only one of them comes out of the TX-module.

Really looke like some type of congestion over the air.

The settings are all the same for the experiments: 333Hz and 1:2 telemetry ratio.

@wimalopaan
Copy link

Changing to 50Hz and 1:2 telemetry ratio does not help.

@wimalopaan
Copy link

With ELRS V3.5.4. this situation is much better:

la_1_elrs3 png

Here all packges come thru.

@pkendall64
Fix MSP over wifi (bf config)
72c0062 
This should be revisited as a connector, and simplified!
@pkendall64
Introduce a CRSFRouter abstraction
a094a19 
This way we can have many endpoints and connectors
@wimalopaan
Copy link

I made the above tests also with a TBS Trace tx-module and receiver. With this setup, there are no problems with 4 external devices: all 6 devices (including tx-module and rx) are showing up in the TBS Agent list.

So, I think, in the above tested ELRS case, there is some congestion sending all the device-info packages from the rx-side to the tx.

Looks like there are substantial changes in 3.x to 4.x regarding this part.
Is this a known limitation now in 4.x ?

@pkendall64
Copy link
Collaborator Author

Is this a known limitation now in 4.x ?

The slot-based telemetry sending code needs to be re-evaluated to make it work better with the new CRSF system.
I'll be starting work on that part soon.

@pkendall64 pkendall64 added enhancement 🪄 New feature or request V4.0 🍔 labels May 12, 2025
@JimB40 JimB40 mentioned this pull request May 13, 2025
Closed
@pkendall64 pkendall64 marked this pull request as ready for review May 14, 2025 04:31
pkendall64 added 14 commits June 6, 2025 17:20
@pkendall64
Linkstats should not be processed and should have the CRSF_SYNC_BYTE
0fbdd95
@pkendall64
Merge branch 'master' into crsf-rewrite
dc7419b 
# Conflicts:
#	src/lib/CrsfProtocol/crsf_protocol.h
#	src/lib/Handset/CRSFHandset.cpp
#	src/lib/LUA/lua.cpp
#	src/lib/Telemetry/telemetry.cpp
#	src/lib/Telemetry/telemetry.h
#	src/src/rx-serial/SerialCRSF.cpp
#	src/src/rx-serial/SerialMavlink.h
#	src/src/rx_main.cpp
#	src/targets/unified.ini
@pkendall64
Lua refactoring/cleanup
c2b0fea 
# Conflicts:
#	src/lib/rx-crsf/devRXLUA.cpp
#	src/lib/tx-crsf/devTXLUA.cpp
@pkendall64
TX stuff out of the common Lua code
fcfb7f7 
# Conflicts:
#	src/lib/LUA/lua.cpp
#	src/lib/tx-crsf/devTXLUA.cpp
@pkendall64
Remove last target specific code from the lua helper
f474202 
# Conflicts:
#	src/lib/CrsfProtocol/CRSFEndpoint.h
@pkendall64
Migrating devLUA functions to xxParameters.cpp which is part of the e…
a7c3573 
…ndpoint
@pkendall64
Move the lua.h/cpp into CRSFParameters
26bd6cd 
with a bit of cleanup
@pkendall64
Remove unnecessary callbacks
fb3343b
@pkendall64
Bit more cleanup
8cef56c
@pkendall64
Renaming and docs
c97db19
@pkendall64
Remove some old crusty defines
662a655
@pkendall64
Finally remove LUA library
dc07dc0
@pkendall64
More renaming
a1df34b
@pkendall64
Move the telemetry slot system into the RXOTAConnector
402178f 
Handle and do NOT forward heartbeat messages
Slight adjustments and fix locking/unlocking
Use a mutex to only allow a single thread to be in the OTA telemetry functions
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
enhancement 🪄 New feature or request V4.0 🍔
Projects
None yet
Milestone
No milestone
3 participants
@pkendall64 @wimalopaan @KissUltra