Devo10 DSMX and Oranage/Lemon Rx issues

mwm wrote: Let me add a data point. I noticed that the Rx on my 200SRX was blinking instead of it's usual solid light. While this Rx is telemetry-capable, it doesn't report transmission issues, but provides vibration and setting reports from the flight control board.

When I bind this Rx with telemetry ON, I get a blinking light on the receiver. Turning telemetry off doesn't change that.

When I bind it with telemetry OFF, I get a solid light on the receiver. Turning telemetry back on doesn't change that.

Using 6 channels at all times.

This is on a Devo10 running the team nightlies (well, sorta - I've got some beta display code; no changes in the protocols directory, though).

Just tried this too.. re-binding with telemetry off. I get less flickering that way (only once or twice as opposed to regulary).. but still doesn't fix the inability to center yaw on a KK board and the constant left yawing.

Have you checked this thread: www.deviationtx.com/forum/3-feedback-que...y-questions?start=40 ?

issues seem similar

Arakon wrote: Just tried this too.. re-binding with telemetry off. I get less flickering that way (only once or twice as opposed to regulary).. but still doesn't fix the inability to center yaw on a KK board and the constant left yawing.

Hi,
don't mix up DSM2/DSMX issues with CPPM issue.
CPPM is an analog protocol, and there may be compatibility issues between RX and the flight-controller. I don't think CPPM issues are related to the (digital) DSM protocol.
See also this discussion on rcgroups

There are loads of frame drops and synch issues with these receivers that seemingly only occur using a deviation transmitter. Therefore this may very well be related.

I ran a test with an Orange R615X hooked to a Saleae.
The CPPM signal is exact the same at start as after five minutes.
Even while the led is flickering because I put the tx in 100uW mode at some distance.

This signal is the one and only that counts for your FC.
What about gyro drift?

A gyro drift that exclusively happens with these receivers? Nope.. There is zero drift with sat receivers or pwm receivers.

I have no experiences with these KK boards, is there not some RC reconfiguration
necessary after changing the rx?
What signal reaches the FC if the tx is switched off?

The only change needed is to set it to cppm instead of sat. No other change needed. When turned off, the board complains about loss of signal.

aMax wrote: I ran a test with an Orange R615X hooked to a Saleae.
The CPPM signal is exact the same at start as after five minutes.
Even while the led is flickering because I put the tx in 100uW mode at some distance.

This signal is the one and only that counts for your FC.
What about gyro drift?

I have had experience with flying my hex, and hearing the throttle control lost while high in the air, within 50 yds. it is using analog output from RX to FC (r800x, no sat)

on this same hex, I have hovered in my house, the light has gone out while in low hover, and was unable to recover link before it went into furniture. this was within 5 feet away. I have also experienced wrecks on R615x and a quad due to link loss.

the flicker might not mess with YOUR control, but I believe it indicates a serious issue that could cause a loss of control.

How can the board determine that there is a link loss?
If I disable failsafe on my FC, it never would recognize this, only a throttle down.
My rx delivers a constant ppm signal if the tx is off, CH3 is min and the rest in middle position.

I'm not sure if this is related or even a bug, but I'm getting odd consistency results from my Devo 10 w/4.0.1
My failsafe doesn't always trigger. I'm trying to use this with an ORange R910 receiver. What I really need is a failsafe that reliably drops the throttle below 975 while the regular throttle range is ~1000-2000. When I turn off the transmitter, sometimes it drops to 968 and sometimes it stays where it was previously. The R910 reciever claims all channels will failsafe to bind position but so far I cannot get them to set to any specific value. The only one I seem to have any control over is the throttle and it's not consistent.

Reading this thread and seeing no development on the firmware I'm seriously considering moving all my Devo's (3) back to Walkera firmware and moving to Frsky Taranis as I can't have my multicopters failing if it's avoidable. At home I have a Devo that I fly regularly with a Blade Nano QX FPV (great practice!) and it works throughout the house reasonably well. The closest thing to this I have experienced is once in awhile the quad twitches on me - but that could be the quad. Actually, sometimes the binding of the quad to the devo takes quite a few tries. Other times it works instantly. No idea if either of these is related or relevant.

A big thanks to you all for posting and trying to view/verify these problems. Deviation is so amazing and powerful - I hope it doesn't die out.

I don't get it how it's the radio's fault if you turn it off? It looks to me that the receiver or the FC is misbehaving, if at all.

I've been using Deviation for a long time with all sorts of orange, lemon pwm, sat, ppm and devo receivers, plus multiwii micro, nano, naze, flip32, kk and never experienced anything like this.

There is some development going on on the firmware. However, with PBR taking a sabbatical, there's not really any central point of collection, and the updates aren't showing up in places only he can update.

I've tried to get everyone who's working on things too coordinate, with a bit of success. If you search the forum for "team" , you'll find references to it. The most important thread is the announcement of the nightly builds .

Changes since the last PBR nightlies include more protocols, module support fixes, GUI improvements, fixes for various GIT issues on PBR's repository, and a new "multirotor" model mode (needs better icons, though). There is some discussion about some DSM telemetry fixes as well, though I haven't checked on that discussion in a while.

sbstnp wrote: I don't get it how it's the radio's fault if you turn it off? It looks to me that the receiver or the FC is misbehaving, if at all.

Personally, I think the failsafe issues are an Rx issue, not a Tx issue. However, since the OrangeRx sets failseafes at bind time, it could be a binding problem. Given that I see different behaviors based on my Tx configuration at bind time, I'm wiling to believe this could be a problem. Be interesting to know if the Rx does the same thing with a licensed Tx.

I don't have the knowledge to fix this. Some of the people participating in this thread do, and are also contributing to the team nightlies, so it could get fixed in a team build. While PBR won't take money for deviationTx work (and I understand why), possibly others aren't so reluctant to turn a hobby into a job. You might try offering a bounty on this bug.

mwm wrote:

sbstnp wrote: I don't get it how it's the radio's fault if you turn it off? It looks to me that the receiver or the FC is misbehaving, if at all.

Personally, I think the failsafe issues are an Rx issue, not a Tx issue. However, since the OrangeRx sets failseafes at bind time, it could be a binding problem. Given that I see different behaviors based on my Tx configuration at bind time, I'm wiling to believe this could be a problem. Be interesting to know if the Rx does the same thing with a licensed Tx.

The original TX are working worse than a Devo with these. In this case a
X9303.....
www.hobbyking.com/hobbyking/store/HK_mov...4deb8597e1fcedd9f484

Already replied to this and can prove it. With Deviation the Orange binds and
reacts synchronously with the beep at boot....lol.

I have a friend bring over a Spektrum DX6I transmitter and we will test the receivers with his TX. Hopefully this will resolve any speculation about Devo vs spectrum.

aMax wrote:

mwm wrote:

sbstnp wrote: I don't get it how it's the radio's fault if you turn it off? It looks to me that the receiver or the FC is misbehaving, if at all.

Personally, I think the failsafe issues are an Rx issue, not a Tx issue. However, since the OrangeRx sets failseafes at bind time, it could be a binding problem. Given that I see different behaviors based on my Tx configuration at bind time, I'm wiling to believe this could be a problem. Be interesting to know if the Rx does the same thing with a licensed Tx.

The original TX are working worse than a Devo with these. In this case a
X9303.....
www.hobbyking.com/hobbyking/store/HK_mov...4deb8597e1fcedd9f484

Already replied to this and can prove it. With Deviation the Orange binds and
reacts synchronously with the beep at boot....lol.

That link is about the reboot times on the R615X. The problem described by burninmedia with the R615X and a LemonRx Rx could all be explained by slow reboot issues. The replies I saw from you on this thread were also about the R615X reboot times.

The post I replied to from rexless was about fiailsafe issues with a an R910 Rx. While I wouldn't be surprised if the R910 showed the same reboot issues as the R1615X, the failsafe issues he mentioned should be unrelated to that. Unless I've badly misunderstood his post, anyway. Nothing on this thread seems to show anyone other than him having done any Rx failsafe testing.

Just to enumerate things:

1. According to the 4.0.1 docs on the DSM protocols, some licensed Rx's go wonky when bound to deviationTx with more than 8 channels. I've seen this with the 350QX1.
2. Based on my experiments, at least one licensed Rx with telemetry behaves differently with deviaitonTx depending on whether or not the Tx has telemetry enabled when you bind.
3. According to the thread at HK the R615X has reboot issues when used with licensed Tx's.
4. On this thread, hexfet reports needing 7 or 8 channels to bind properly to licensed DSM Rx with satellites
5. deviationTx had an issue with >7 channels triggering 11ms mode on AR7200. Other non-licensed DSM implementations may still have this, or our workaround might not work with them.

To me, these look like the kind of compatibility issues you get across multiple independent implementations of a software protocol. Especially when some of the implementations are based on reverse engineering things as opposed to having a spec to work from.

Given that, the only tests that are really relevant for devaiationTx problems are those between deviationTx and a suspect Rx, and those between a licensed Tx and a suspect Rx. Where "suspect Rx" is one known to be running the same firmware version as the one having the problems. If deviaionTx behaves differently than a licensed Tx, than it's a deviaionTx problem. If it's not a deviationTx problem and it can be fixed without breaking licensed Rx's, it'd be nice to do so.

burninmedia wrote: I have a friend bring over a Spektrum DX6I transmitter and we will test the receivers with his TX. Hopefully this will resolve any speculation about Devo vs spectrum.

Did not test the DX6i because it was DSM2 only.

Hello,

I don't have a solution for the problems being discussed here but I can say that I'm using the Devo10 with FW 4.0.1 with WK-2801, Devo and DSMX protocols (DSMX with 100mW, others used are 10mW for the MiniCP and 30mW for the V120) and both of my ORX R800X work flawlessly in a range way further than I can see the model. If the R800X loses signal by switching off the TX it will come back to work as soon as I switch on the TX again. I would say it takes 1/3 of a second max.

EDIT: I use the R800X set up without telemetry and on 8 channels, only 5 used though.

Cheers,
Stefan

First, thanks for all the replies. I will check out those alternate nightlies on the google drive site. That's exciting news!

Unfortunately I don't have a license TX here to compare results with. So what I just did now is I took an orange R615 off of another device and plugged it into a Naze. I copied the model.ini file, set the scalar limits to +/-150, set the ELE failsafe to +50 and set a new bind code and went through the binding procedure. On this set up the throttle failsafe has worked exactly as required on about 15 TX on/off tests. The ELE failsafe has not done anything at all. I'm guessing this means that the failsafe setting in the model.ini isn't actually doing anything and it's purely a case of stick positions at bind. This also seems to suggests the R910 does not have a reliable failsafe setting (at least when used with this Devo) as it sometimes works and sometimes doesn't.

The good news is that this suggests the Devo/Deviation is probably not the issue. The bad news for me, is that I need a receiver optimized for full-range use with at least 8ch for this build. So now I'm going to have to decide on another receiver to buy.

Thanks again guys!