Advanced Search

Did you notice the dedicated ExpressLRS on DeviationTX thread? www.deviationtx.com/forum/protocol-devel...expresslrs?start=140

Hey!

I've followed this: and it works like a charm.

(I've got the V3 Carbon looking one..)

Hope that helps!

chiedo scusa , ma avevo sbagliato l'aggiornamento , con lultima versione funziona

ho istallato l'ultimo aggiornameto v5.0.0-c84450e

I don't get a GPS lock inside and the weather is crap. In the weekend the weather will be better and I will test the GPS telemetry in the field.

Thanks. Sounds like maybe a race condition to chase down. I went ahead and merged the current PR as it's much better than it was.

Test build 3663db7 is available. Fixes the GPS latitude and longitude display.

New devices now show in the menu. Just very rarely it does not.

There might be an error in the conversion of the CRSF gps telemetry. I'll look at it in the coming days.

The data rate setting is on a Crossfire receiver.

Today was my first flight with ELRS on a wing with GPS. I only have ELRS for a week. I never used a module before just the internal 4 in 1. GPS telemetry from an frsky type receiver worked well.

I don't know how to set dynamic packet rate. I only see an option for dynamic power in the menu.

Could someone please post the corrected files for the SD card and for the radio...... I've tried to upload the files and correct them as noted ...but there's something I'm doing wrong and I cannot figure it out.... if anyone has the files already corrected please make me a copy and post them for me ...so I can just load them and have voice working

I'll need to set up some GPS telemetry to look into that, unless maybe you can make a data capture? Is this a new behavior or GPS telemetry was always like that?

Test build 051dab03 is available. This has a fix for the issue where a newly discovered device did not appear on the CRSF config page until an up/down press. Now the name will show up when the device info message is received. My nano rx responds a lot faster after changing the packet rate from Dynamic to 150Hz.

The GPS telemetry shows some numbers but they are not close to the same as what I see in iNav and goggle OSD and are not the location.

I haven't seen anything else disturbing. I'm going to fly tomorrow.

Ah yes. Often the device names don't show until the cursor hits the menu element.

That's good news. Yes 458a87e is fine for testing.

How is the CRSF menu with other devices? My crossfire nano rx sometimes doesn't show on the CRSF config page until I scroll down. Looking at the serial data it just seems slow to respond.

Long name issue is fixed, at 500Hz the device page comes up quickly and accurately.

Seems that the CRSF menu is a lot faster to load now as well!

EDIT - testing was done on the latest 458a87e build

I've got testing time today. The 458a87e is still the one to test?

The long name bug seems to be fixed. I have a menu with HappyModel ES24TX Pro on 500Hz.
Thnx

Anything special you'd like me to test?

Found the serial data problem which has been there since I put in the DMA code a few years back. Was changing from tx to rx before the last byte finished sending.

I don't know if this will fix the long name issue, but please try test build 458a87e . The serial bug is fixed and telemetry is back to normal.

I've ordered an ELRS module

That's quick turnaround. Deviation is the slow one.

Please try test build 504c1fd . This is mainly to gather some data. I found another issue on my tx and want to check if it's on others as well.

This build does add a extra delay after sending a command to give time to get a response. This is just a test but may change the behavior of the long name problem.

This build also replaces some telemetry value with debugging information. What I see on my tx is a large amount of "bad" data being received. When I put a logic analyzer on the data pin I don't see any collisions or frame errors in the captured data. That sent me looking elsewhere. Turns out the uart in the T8 is producing received data with frame errors and sometimes noise errors. The signal looks clean on an oscilloscope so I'm not sure what's going on. I've tried several i/o pin configurations, including opendrain with an external pull-up resistor. The data again looks good on o'scope and logic analyzer, but the Crossfire module doesn't recognize the data unless the pushpull output is used. Strange.

Here's what the debug telemetry data means. Please let me know what you see, and if there's any change in the long name problem.

Voltage (upper right on telemetry monitor) is a bit field that accumulates statuses from received data and a few flags indicating reasons a packet was dropped. It can be reset to zero by going to the CRSF config page. 128 is the desired value, I mostly see 192.
bit 7 - rx data ready
bit 6 - frame error
bit 5 - noise error
bit 4 - overrun error
bit 3 - invalid packet size
bit 1 - too much received data
bit 0 - CRC error

Current (below voltage) is a counter that increments on frame, noise, or overrun error
Capacity (below current) is a counter that increments when an invalid packet start byte is found (valid byte that is not ADDR_RADIO)

The counters are 8 bit and just wrap on overflow.

Thanks for the help!

It's multi-threaded in the sense that menus, mixer/packet send, and serial receive all have their own execution contexts. Menu updates are in the main loop, while the others are interrupt driven.