Closed dantiel closed 10 months ago
Hi Dantiel! I'm not sure you're going to have much luck getting it to work, and am actually very surprised you're getting any packets successfully at all. I think you might actually be seeing more failures of the CRSF CRC8 system letting bad packets through than actual good parses.
The problem you're experiencing I believe is due to SoftSerial not being viable to use for such high bitrate communication, on such a slow processor. It just isn't reliable for high baud rates, especially if you're going to be doing anything else with the MCU, and it will just get worse and worse the more other code you have running.
I'd recommend just using the hardware UART set to 250000 and doing your debug logging over SoftwareSerial instead to a separate FTDI.
I think the Arduino pro mini doesnt support 250000 on hardware serial either. unfortunately I dont understand yet how the code works nor the limitations. isnt there a simpler algorithm ? I would literally offer you a crate of beer if we can make it work (;
I just told you how to make it work 😄 The Arduino Pro (atmega328) will work up to 500kbit assuming it is a 16MHz one, but I've only tried it at 125000 and 250000, both of which appeared to work fine after setting the RX's baud to that as well.
You just can't use SoftwareSerial as it requires too much of the MCU's dedicated time to work reliably at this bitrate. The atmega328 is not a very powerful processor so you'd need to be extremely smart about how your code allocates processor time to have it work even at much lower baud rates. The processor certainly can be useful, but if you're starting with SoftwareSerial and then expecting to build a system on top of that, you're destined for failure unless you've got a lot of experience with the platform.
Solutions: Use the hardware UART for CRSF and do your logging using SoftSerial (at a low baud rate), OR switch platforms entirely. RP2040 boards are just as cheap, support so many of the same libraries, and are so many levels of performance peripherals and usability above the 20+ year old atmega design that it is just no contest.
Hi, sorry for hijacking this issue a bit but I'm also currently trying to get this lib to work on an Arduino Pro Mini (3.3v 8Mhz), without luck. Using the Hardware UART and so far I have tried 250000, 115200 and 57600 baud rate but it doesn't work at all. When trying the same code on a ESP32 board it works fine though (only tested at 115200) Maybe this is not supposed to work at all on the 8Mhz mini? Thanks!
There is another crsf library simple_rx that seems optimized for speed but I couldn’t get any useful value out of it, maybe it’s optimized to work only for the setup of the author >.< this lib I have tested on 16mhz 5v version of pro mini. Before I was running this on it: extensive sine caclculations, ppm decoder, gyro reading and PID controller. It’s possible, but the same gets fragmented on 8mhz. i thought decode elrs wouldn’t be more difficult than ppm but for sure it’s a lot more data and complex protocol. I haven’t got anything yet out of the hardware serial, mainly therefore used softwareserisl, logging is not necessary but its a problem that I need to desolder the receiver when uploading a new sketch because there’s only the one same serial. Actually I have two rp2040 boards lying around which I haven’t tested yet they cost the double as pro mini but offer more, gonna try those or compare both libraries and find out how it works, although probably it will be difficult to impossible running everything at once
"[another CRSF implementation] that seems optimized for speed" -- this hurts me :'(
CRSF is not complicated. If you're capable of reading serial data, you're almost done. The only issue is that you need to be able to receive the data as fast as it is coming. You can not with SoftwareSerial. It is too resource intensive for the amount of data coming. Your other solution is to use 50Hz ELRS, lower the baud rate to 38400 or maybe 19200.
I do understand that you're feeling serious MCU-selection remorse right now as you've discovered your chosen MCU does not meet the one basic requirement: has a UART. I know it really is a pain the ass to have to desolder stuff to switch it to upgrade firmware-- that's terrible and makes development incredibly painful. atmega328 are great too, I've been heavily programming with them for 14 years, and produced commercial products with them. Where they really suck is that they only have one UART, which makes interfacing them to other things that use UARTs a real problem without resorting to ICSP and you lose your ability to easily debug.
You just need to start with step 1 of your design process: Pick a piece of hardware that has an available UART to connect to, unless you're OK with 50Hz mode at low baudrates, and even then I wouldn't trust SoftwareSerial to get you all the packets the RX sends.
Maybe this is not supposed to work at all on the 8Mhz mini?
I don't see why not. The max baud I think would be 125000 but it should work. There's nothing that 8MHz versions do apart from change their timings to be half what 16M ones use.
ha sorry I didnt mean to criticize, by the way simple_rx also recommends your library ;) good idea to try lowering the rate even further, somehow I didnt suspect that its possible, lower rate is not a problem because my application are slow flyers. im gonna try these possibilities and also use other hardware, because the sketch size has already been an issue. ill report, thank you capnbry
Honestly I just tried doing what I suggested with the RX connected to the UART and a SoftwareSerial logger at 19200 on other pins and if I just print channel 1 to the log on every new packet, LOTS of packets start dropping. SoftwareSerial disables interrupts when it writes so even that seems unsuitable as an option. If I just count the number of packets per second, with SYNC and Telemetry off on the TX, I get the expected number of packets per second (250 packets at 115200), but if I try to print the message AND count the packets, incoming data from the HardwareSerial gets lost
#include <CrsfSerial.h>
#include <SoftwareSerial.h>
CrsfSerial crsf(Serial, 115200); // pass any HardwareSerial port
SoftwareSerial logging(2, 3);
static uint8_t cnt;
void packetChannels()
{
++cnt;
}
void setup()
{
logging.begin(19200);
logging.println("UP AND RUNNING");
crsf.onPacketChannels = &packetChannels;
crsf.setPassthroughMode(false);
}
void loop()
{
// Must call CrsfSerial.loop() in loop() to process data
crsf.loop();
static uint32_t last;
uint32_t now = millis();
if (now - last >= 1000)
{
static bool thisTime;
thisTime = !thisTime;
if (thisTime)
{
logging.print("Cnt="); logging.println(cnt, DEC);
}
cnt = 0;
last = now;
}
}
UP AND RUNNING // print cnt every cycle, if (thisTime) replaced with if (true)
Cnt=0
Cnt=0
Cnt=0
Cnt=232
Cnt=223
Cnt=248
Cnt=248
Cnt=248
Cnt=248
Cnt=248
Cnt=248
Cnt=248
Cnt=249
Cnt=248
Cnt=249
Cnt=248
Cnt=248
Cnt=248
Cnt=249
Cnt=24
Cnt=0
Cnt=0
UP AND RUNNING // switched to only print every other cycle
Cnt=0
Cnt=0
Cnt=222
Cnt=249
Cnt=250
Cnt=250
Cnt=250
Cnt=250
Cnt=250
There also appears to be a bug in that it requires crsf.setPassthroughMode(false);
in init, as the UART is not correctly set up if initialized as a static class only. That line might help @sandstreamer
I can confirm that crsf.setPassthroughMode(false);
combined with baud rate 57600 solved the issue for me on
Arduino Pro Mini (3.3v 8Mhz) connected to a BetaFPV Lite RX running ELRS 3.2.1.
Also tried again on 115200 but this rate seems to be too fast for the 8Mhz mini.
Thanks a bunch @CapnBry!
@dantiel Hello dear! Can you help me with uploading firmware please? Never used platformio before. When i just installed this library, it builded normal (just builded, not uploaded to the board), but i saw that it was configured to different board. I've pasted it to platformio.ini:
[env_common] platform = atmelavr board = pro16MHzatmega328 framework = arduino upload_protocol = avr-stub debug_tool = avr-stub
but now I got a lot of problems when building. Like this:
/Users/user/.platformio/packages/framework-arduino-avr/cores/arduino/HardwareSerial.h:143:25: note: previous declaration as 'HardwareSerial Serial' extern HardwareSerial Serial; ^~~~~~ *** [.pio/build/PURPLEPILL/FrameworkArduino/IPAddress.cpp.o] Error 1
Can you tell me please, what am i doing wrong?
@Pavel-trying This is not a support forum for helping you write software. You have two things defined as Serial
due to multiple platforms being built. See how it is using both PURPLEPILL (an STM32 target) and arduino-avr? You can't just dump your stuff into env_common
, and CRServoF won't build for atmega328 anyway.
Please don't randomly jump into an unrelated issue and look for development help.
@CapnBry I'm so sorry for disturbing you! Just saw that @dantiel made it for same board as mine (Arduino pro mini), but can't text him to DM :(
@CapnBry you're amazing, indeed crsf.setPassthroughMode(false);
did the trick. I was not able to get a smooth behaviour from SoftwareSerial, but now HardwareSerial works perfectly smooth and reliable with 333Hz package and 115200 baud rate.
Hi, i am trying to use this library on Arduino pro mini with EP2 ELRS receiver. The small form factor of EP2 would be very good for making a lightweight flightcontroller. to make it work, I had to change the library to SoftwareSerial, and use baud rate of 152000. However only about 70% of the channel readings are correct, and also channels are read only every 10seconds.... attached a screenshot of debug messages I added.
Is there a chance to make it work?