search

olliw42 / mLRS-docu

Documentation for the mLRS project
GNU General Public License v3.0
35 stars 11 forks source link

Trouble with R9 MX #111

Closed Hwurzburg closed 5 months ago

Hwurzburg commented 11 months ago

@olliw42 have been trying to a system setup...flashed R9M TX module with ELRS bootloader and then mLRS,no problem.....flashed via TX the R9MX with ELRS bootloader, no problem....but cant seem to talk via uart port to my ftdi connector using the UARTupload.py script....it runs, the RX is flashing as if in bootloader, but script tries 10 ten times and gives up...

-have tried reversing tx/rx (although its pretty easy to get that right) -have tried no delay to many different delays on powering rx after script starts -have checked connectivity of wires from RX uart pads to duponts

any other suggestions? might have to shelve this and move on...was hoping to post a AP blog post on it once I got it and the wifi link from R9M module running

olliw42 commented 10 months ago

what firmware are you using on your radio? OpenTx, EdgeTx? which version? (I had tested that firmware on my t16 radio, and it worked just fine)

ArtimisFowl888 commented 10 months ago

edgetx 2.7.1

olliw42 commented 10 months ago

ah, that's a bit old ... I don't recall anymore but I think the lua didn't work for older edgetx versions can you maybe upgrade?

jlpoltrack commented 10 months ago

Maybe the SD Card was slightly corrupted? May just try deleting the existing Lua and uploading it again before upgrading EdgeTx.

ArtimisFowl888 commented 10 months ago

ah, that's a bit old ... I don't recall anymore but I think the lua didn't work for older edgetx versions can you maybe upgrade?

Yup, that fixed I didn't even think to check my edge tx version. Thank you, guys, for all the help.

olliw42 commented 10 months ago

Yup, that fixed I didn't even think to check my edge tx version.

fantastic! So we need to update the docs to mention this, raised issue to remind us, https://github.com/olliw42/mLRS-docu/issues/113

brad112358 commented 10 months ago

The problem @Hwurzburg was has could possibly also be explained by a problem with his USB TTL serial adapter. I'm beginning to wonder if a common USB adapter chipset or windows driver has some issue at higher or unusual baud rates or something. Perhaps the clock divisor math isn't working out well. For example, 460800 would be a more common baud rate than 420000 outside of the drone world.

I did test 3 different chip sets I happen to have here and they all worked under both Linux and windows, including one with a CP210X chip.

@ArtimisFowl888, could you please test your problematic serial adapter at 9600 baud with a terminal emulator and let us know if it works at this more conservative and common speed? If that works, please also test 230400 and 460800 baud.

Thanks!

olliw42 commented 10 months ago

ah ... the cp21xx chips have an internal list of supported baudrates, which one can program, but the required 420000 might not be in there I have that "issue" with STorM32 NT bus, which runs at 2000000 baud, so here I always have to first program the cp21xx to handle it. Adapters with FTDI chip don't have that issue. Here the docs in the STorM32 wiki: https://www.olliw.eu/storm32bgc-wiki/How_to_configure_CP2102_USB_adapters_for_high_baud_rates. In the list shown there you see that 420k is not inlcuded. Not sure that still holds though, didn't do that for a long while since I have enough cp21xx adapters LOL.

brad112358 commented 10 months ago

The adapter I have used the most for flashing under Linux is an cp2102N, and it also worked when I flashed under Windows, but it seemed worth asking @ArtimisFowl888 to do this test anyway...

ArtimisFowl888 commented 10 months ago

9600, 230400 and 460800 worked.

brad112358 commented 10 months ago

@ArtimisFowl888, Thanks for checking! This indicates that your serial adapter is not defective. Unfortunately, as Olli has informed us, and @jlpoltrack also experienced, some of the CP210x chips do not support the required baud rate of 420000.

Looking at the Linux driver, it seems that the cp2101, cp2102, cp2103 and cp2108 support only a limited set of baud rates without reconfiguration while the cp2104, cp2105 and cp2102N should already support the required rate. This explains why it works for me but not for you since I have the cp2102N and you seem to have a cp2102.

@olliw42, I guess it is important to mention this in the documentation. Does anyone know of any other common USB adapters which might have similar constraints?

The workaround for anyone who does not have a more flexible adapter is to use passthrough on a flight controller. Betaflight is easier since the python script already configures passthrough there. Ardupilot will also work, but the passthrough currently needs to be configured manually.

@Hwurzburg when you get back to this project, you might want to try flashing via FC passthrough.

olliw42 commented 10 months ago

I guess it is important to mention this in the documentation.

absolutely. Pl feel free to make a suggestion.

The workaround for anyone who does not have a more flexible adapter is to use passthrough on a flight controller. Betaflight is easier since the python script already configures passthrough there. Ardupilot will also work, but the passthrough currently needs to be configured manually.

this shouldn't be a fault of ArduPilot but the py script. It could eiher (a) set the params as needed (and reset them after done) or (b) use the mavlink serial passthrough protocol which doesn't need configuration of params.

brad112358 commented 8 months ago

@Hwurzburg, When you get back to your testing, I suggest you try a different serial adapter or, just use a flight controller via serial passthrough to flash your receiver. Some serial adapters don't support the 420K baud rate required by the bootloader and it seems the windows drivers may silently choose a different baud rate.

Also, you may want to take another look at the R9M mLRS documentation. Several improvements have been made since you first raised this issue.

Hwurzburg commented 8 months ago

thanks..will do

On Sunday, February 18, 2024 at 10:57:50 AM CST, brad112358 ***@***.***> wrote:

@Hwurzburg, When you get back to your testing, I suggest you try a different serial adapter or, just use a flight controller via serial passthrough to flash your receiver. Some serial adapters don't support the 420K baud rate required by the bootloader and it seems the windows drivers may silently choose a different baud rate.

Also, you may want to take another look at the R9M mLRS documentation. Several improvements have been made since you first raised this issue.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

4O6FPV commented 7 months ago

Also found this issue when using a cheap Chinese CP210X adapter but once I switched to CH9102 adapter I had no issues and was able to flash the r9mm/mini. I have also ordered a cpl MX units to get familiar with the flashing of them.

olliw42 commented 5 months ago

I think this can be closed. The improved the situation and also docs. And it's stale for few months.

If the problem comes up again, a new issue could be raised.

@jlpoltrack closing?

jlpoltrack commented 5 months ago

@jlpoltrack closing?

Fine from my end. I do plan to redo the R9 docs (split in Tx and Rx sections) but even the other issue reminds of that (https://github.com/olliw42/mLRS-docu/issues/143)