we updated our Cubes to the new 3.6.10 stable FW today, and found the following issue across 2 different units, after updating the RCIN through SBUS is not recognised when SBUS is being fed through an IP based Digitial Datalink, in our case we tried two different type of radios, one is the Microhard PMDDL2450 and the other is the MainlinkAero M51, both of these units displayed the same issue across different cubes running 3.6.10, upon downgrading to 3.6.9 it resolved the issue. However, when feeding SBUS directly via a Frsky R9M this issue is not seen.
We have been using these radios since 3.6.5 and never had this issue.
I had a chat with @tridge about this and he says that he suspects this is caused by corrupted SBUS packets that are being caught by the ChibiOS I/O firmware that is more strict in order to better catch SBUS corruption like we saw with the Pixhawk4.
If you could provide more details of your setup that might help. Tridge also suggests that we will likely either need to get the same hardware to diagnose the issue or we need the output from a logic analyser (like one from saleae.com) attached to the SBUS input/output.
I use a ground station that outputs commands in Serial which is fed to the Base unit Microhard PMDDL2450 directly as serial and on the air we have PMDDDL2450 Picroradio the serial commands are then converted to Sbus using Serial to Sbus which is a teensy board running a code to convert it.
The second unit is from MainlinkAero which accepts Direct Sbus input and Outputs Sbus, i would assume internally it is doing the same job of converting it to serial or vice versa due to the fact that the whole thing communicates in single frequency. both of them are 3 in1 units, the product is very new and there is not much info in their website about it. But i would assume this issue can be replicated with any 3 in 1 digital data links. MainlinkAero
I have a Digital oscilloscope i guess with storage the DS212 from MINI, which i had used to confirm whether or not i was receiving signal, would that be of any help? also i can procure one of the logic analyzer and send you the data provided if i know a brief of what i must givee as a sample signal as I have never used that before.
Hi @Mohamed, I’m the maintainer of the SBUS decoder in ArduPilot, so it is likely that I will be the one to look at these traces.
What we need is a trace which shows what is different about the SBUS signal coming out of a receiver which works and the signal which doesn’t work. A scope trace could be used, but very often it is difficult to see a complete SBUS packet with a scope. SBUS is 25 bytes (at 12 bits per byte).
The easiest sort of trace for me to work with would be a capture from a Saleae logic analyser. That will give me data that I can directly compare to what we expect, plus give me the timing in the detail needed to work out what is wrong. The Saleae Logic software can also check the serial config for us.
Make sure you capture at a high enough rate (2MHz or above would be fine).
My guess is we will find it is something like the number of stop bits being wrong, or the packet spacing not being sufficient.
Cheers, Tridge
Hi @tridge thank you for reaching out, I have just placed an order of Saleae Logic Pro 8, for troubleshooting this issue, i will update you with the capture once the unit arrives.
Using a Radiolink minipix. It was once solved that Telemetry 1 and Telemetry 2 was swapped. Now with 3.6.10 it is swapped again. That means Telemetry 1 is on Serial 2 and Telemetry 2 is on Serial 1
@rmackay9@tridge Is there a rough ETA for a release for 3.7.0? Is the 3.7.0 dev (which is the Master branch? Or another branch?) in its current state safe to use on a stock 3DR Solo?
I have two Iris+ at the moment and am planning to expand the fleet, I imagine the Solo would be an upgrade (would it ?) but since I plan on buying several more drones, having to spend the extra money for upgraded cubes on each is a bummer.
A development version is subject to frequent change, includes newly developed and yet untested features and therefore is not to be considered as “safe”.
3.7 isn’t even in beta testing yet.
Unless you know what you are doing I would wait at least until the formal beta testing starts.
Thanks for the reply! Fair enough and sound advice. I do understand that the not yet released version is not safe in the general sense, I should have been more precise. I meant specifically as it relates to stock Solo support and the 3v vs 5v signaling flaw, which, as I understand, will be natively supported in 3.7 without the need for an upgraded cube. And by safe, I meant in terms of the maturity of the features that will allow such support, aka no sudden motor issues.
And if I’m misunderstanding any of these points, please feel free to correct me
I hope we will start beta testing Copter-3.7 in 3 to 4 weeks. There are three features we need to complete:
Integration of object avoidance into Copter
Addition of stay-out zones
High vibration failsafe
3.7 does include two new parameters MOT_SLEW_UP_TIME and MOT_SLEW_DN_TIME which I’m pretty sure are intended to resolve the Solo’s 3v vs 5v issue (at the cost of some reduction in vehicle’s performance).
@rmackay9 Great, thanks for the update!
I’m actually also looking forward to the collision avoidance feature, since that will be an important topic when flying multiple vehicles in the same air space.
As for the Solo, that makes sense. I’m not worried about the performance cost as my application is more concerned with autonomy and robustness than “flight fun”.
I’m still new at the world of ArduPilot so for now I can only say thank you to all the developers for the amazing work, hopefully, I’ll be able to contribute back in the future.
On a more subjective note, (and off topic, happy to move that to a private message or different thread) I really like the Iris (but it’s likely a bit outdated in terms of hardware) – and I think I’ll like the Solo too (but for the software fix to the hardware flaw, and still aging) – but as I look to expand our fleet, are there other vehicles that are as RTF and capable as these, or close to, with ArduPilot compatible hardware in a somewhat budget-friendly range? From the ArduPilot ready to use doc, I also have several SkyVipers and they are great to experiment and test with, but limited obviously because of the form factor. Others seem either in the “toy” range or “commercial” range (i.e. $$$) The build from scratch route downside is scalability, as I would like to end up with a half dozen or dozen of vehicles, initially
It’s definitely off-topic for this thread but in any case, we have a list of known RTF vehicles here. There are undoubtedly more but we don’t really know all the companies that are using ArduPilot.
At the SZUVIA conference in Shenzhen Hex had two RTF vehicles at their booth which I heard were to be sold as RTF vehicles. I don’t have any other details yet but I suspect in the future these might be another good choice but we shall see.
Hey.
Some time ago I built a 3-inch quad on omnibus 4 pro v2. I was great at Betaflight and Inav. Since I was not happy with the althold fashion in Inav, I decided to install the Arducopter. By using the DFU betaflight mode, I got software for arducopter 3.6.10 from the latest issue. Unfortunately, after this operation Omnibus is dead. When I try to call DFU mode with the switch Windows 7 does not recognize the bootloader and displays the USB device is not recognized. I will not blink blue diode on the board, it only lights up constantly green. Nothing changes using ZADIG. I have stm32 drivers installed on my computer and another 4prov2 omnibus boards are reported in both betaflight and Inav. Since this is the second omnibus that behaves this way (in the previous after identical operation I thought that the motherboard was lost). I have a question. Did the uploaded firmware change / damage the bootloader on the disc? Are the board save?
I am sorry for the confusion. I was able to recover the plate. After disconnecting the signal wire of the sbus receiver, the boardloader is reported and I can go back to Inav and Betaflight. I tried again flash 3.6.10 with the receiver, gps, magnetometer disconnected and the plate again does not give a sign of life although I am not afraid and I can return the software. Is the arducopter 3.6.10 confirmed with the 4pro V 2 omnibus board working?
Half a year earlier, I managed to successfully upload an older version of the arducopter. I welcome
Since 3.6.0, Oneshot 125 is of no use: PWM out is still between 1000 and 2000 when Oneshot125 is selected, instead of 125-250 range.
While using 3.6.9, normal PWM out, I experienced motor desynchronising with bad Yaw control when manually tuning parameters. Same parameters are fine with 3.5.7 and Oneshot125 (no desynchronising). So I reverted to 3.5.7 for my day use.
Can you check with dev team if Oneshot125 is working as intended on other cards like PixHawk, Cube and 3.6.x. No need to fly, just change type to 2 (Oneshot125) and check if PWM out status is in the expected range.
I had a short try with 3.6.10 but compiled arducopter from repository doesn’t launch (reported to Emlid team). 3.6.10 rc1 doesn’t work either.
