I was happily setting up a Traditional Heli, using an mRo R15 PicRACER, ArduCopter v.3.6.12 and QGC. Everything acted as expected.
After updating to ArduCopter V. 4.0.0 stable - found that neither QGC nor MP software recognized my DX8 radio signals coming thru a Spektrum SPM4648 receiver. I received an error message that 0 Channels were coming through and 5 were needed “with PX4”. Note - I am using the current ArduCopter-ChiBios flight stack - NOT the PX4 stack. For giggles…tried the PX4 flight stack and even tried Nuttx. Everything loaded normally, but radio signals are not acknowledged by the MP/QGC software. Screenshots attached.
I down-graded back to 3.6.12 and the signals were recognized again using QGC Radio Calibrate as the signal indicator. I did this upgrade a second time…and the results were the same…so now I’m back to 3.6.12 until a fix for v. 4.0 can be had.
To rule out an issue with MP loading the incorrect firmware could you try directly downloading the firmware from the link below? I think the “arducopter.apj” file should be the one to download and it can then be uploaded using the “Load custom firmware” link on the Install Firmware screen.
Randy, do you think there’s a chance that the 22ms protocol of spektrum was broken recently? I’ve only been testing the 4.0-level releases recently when I found https://github.com/ArduPilot/ardupilot/issues/13117.
I wouldn’t necessarily pin this on Spektrum (nor mRobotics R15). After all, everything functions completely normally on firmware v.3.6.12 in both MP & QGC.
Radio and receiver binding was never an issue at 11ms no matter whether v.3.6.12 or v.4 is loaded.
Thinking changes inside firmware v.4. is the culprit…
Tried all sorts of variations of the order of hooking up power to the flight controller, the radio, starting QQC before/after powering up the fight controller nothing seems to resolve.
I think we have a solution for this issue in Copter-4.0.1-rc1 which is on it’s way out for beta testing (release announcement). There’s a slight delay between when I release it and when it actually appears in the ground station but hopefully it’s available within the next couple of hours using the GCS’s “Beta Firmwares” link.
I probably hardly need to ask but looking forward to feedback on whether this has resolved the issues or not.
Issue with my original post continues…neither QGC nor MP software recognize DX8 radio signals coming thru a Spektrum SPM4648 DMSX serial receiver. Radio & receiver bind normally, without issue at both 11 and 22ms no matter the Arducopter firmware.
No signal capture by QGC nor MP situation continues even with Arducopter v. 4.0.1 stable (but continues to capture signals & work normally with v. 3.6.12).
Developer told me to post the tlogs for both ArduCopter versions in this Forum. Have attached the tlog for v. 3.6.12…but oddly…there are no tlogs generated with v.4.
Appreciate anyone’s help remedying this regression in the newer firmware.
So I assumed this was user error, but it is not! @rmackay9, @tridge I can completely reproduce this. I have an SPM4648, DX8 and mRo Pixracer R14 bound at 11ms. I just flashed 4.0.1 copter and low and behold no signal recognized in MP radio calibration page! RX binds ok. If you need any help debugging this I am happy to oblige, but seems like a serious issue.
Matt,
Thanks for making the language in the title more precise. I further tweaked the title to minimize the 11/22 ms focus…as the radio & receiver bind properly with BOTH 11/22 ms under v. 3.6.12 & under v.4.
Wondering if this issue is affecting only Spektrum users…or others too. As mentioned earlier - wouldn’t necessarily pin this on Spektrum nor mRobotics R15. After all, everything functions completely normally on firmware v.3.6.12 in both MP & QGC. Radio and receiver binding was never an issue at 11ms or 22ms no matter whether v.3.6.12 or v.4 is loaded.
Thinking changes inside firmware v.4. is the culprit…
Thanks to all! I know these are tough bugs to snuff out.
Thanks for the report, I’ve added it to our Copter-4.0 issues list so it won’t be forgotten. Hopefully we can get to the bottom of it quickly. @andyp1per being able to reproduce it should help us speed along the solution.
can you capture some of the traffic on the uart? Do you have a logic analyser you could use to do that? I need to get the bytes so I can run it standalone
You mean the UART that MP is connected to (I’m connected via USB)? I don’t have a logic analyzer - any other mechanism I could use? I was wondering whether I could cherry pick out some suspicious commits are retry?
@tridge , @rmackay9 I bisected all the way to the culprit which is this:
commit 748cf39116acac0f5395c699a6718db4cdbc6b4b
Author: Andrew Tridgell <andrew@tridgell.net>
Date: Fri Sep 13 14:48:04 2019 +1000
HAL_ChibiOS: disable DMA for RCIN on Pixracer
this frees up DMA for USART1_RX, which gives DMA for input over the
SERIAL5 WiFi port, which is important for applications where a
pixracer is being fed vision data over WiFi
interesting! have you tried with master but with that single common reverted?
If this is the commit that matters then the cause must be small changes in timing.
In AP_RCProtocol_DSM.cpp you will see two uses of the constant 5 milliseconds in dsm_parse_byte(). Can you try adjusting those and see if it fixes the issue?
@tridge, @rmackay9 the only reliable way for me to make this work again is re-enable DMA on the RCIN channel for the pixracer. I played with the timing settings and nothing is reliable.
UPDATE: I’ve raised an issue with some logging between good/bad. Happy to try different timings - but I don’t really understand the logic of the code so need some guidance. https://github.com/ArduPilot/ardupilot/issues/13458
