DSMX connection drops

[GoogleCodeExporter]

Which board (stock / gruvin9x / sky9x) are you using?
stock

What is your open9x FW version?
open9x-stock-DSM2-en.hex
2013-01-16 06:41:50
open9x-r1855
212-0

What is your open9x EEPROM version?
? pristine setup

What steps will reproduce the problem?
1. setup a model to use dsmx
2. do some fine tuning
3. watch the receiver loose connection for a second or so

What is the expected output? What do you see instead?
I expect this to NEVER EVER happen

Please provide any additional information below.
I think this is because of timing errors in the serial data stream.
This is a show stopper! Open9X cannot be used with DSM at all in this state!

Original issue reported on code.google.com by lilv...@nscit.com on 10 Feb 2013 at 4:22

[GoogleCodeExporter]

For you when you have time ... I am not able to do anything, I don't have any 
DSMX module / receiver

Original comment by bson...@gmail.com on 10 Feb 2013 at 5:01

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I need to know module type and eeprom settings about the modulation.
If it's possible post eeprom here..

Original comment by romolo.m...@gmail.com on 10 Feb 2013 at 5:27

[GoogleCodeExporter]

I remember that Andre worked on this same problem some months ago. Are you able 
to compile and test old open9x releases? I can try to find the version on which 
he worked and we could start some dichotomia to find which release introduced a 
regression.

Original comment by bson...@gmail.com on 10 Feb 2013 at 5:37

[GoogleCodeExporter]

I just blew up (still trying to find out how) my 9x so i can't help until i got 
a new one.
I am using a DX5e 21dbm module which i ripped out of a DX4e TX.

Original comment by lilv...@nscit.com on 10 Feb 2013 at 5:50

[GoogleCodeExporter]

Which version were you running when you noticed the problem?

Original comment by bson...@gmail.com on 10 Feb 2013 at 5:53

• Changed state: Accepted

[GoogleCodeExporter]

open9x-stock-DSM2-en.hex
2013-01-16 06:41:50
open9x-r1855
212-0

Original comment by lilv...@nscit.com on 10 Feb 2013 at 6:07

[GoogleCodeExporter]

For reference, I run open9x r1734 (quite old now) with DSM2 on the PPM output 
port. I fly Trex-500 helicopter and a Helios 10e electric plane with no trouble 
at all.

I have a DSMX module somewhere, but not yet installed. I'm using a DSM2 module. 
However, it's highly unlikely that using the different module would cause the 
problem - -unless the module itself is faulty.

How is the DSMX module installed? Does it have its own, larger 5V regulator 
before a 3.3V reg? You can't use the smaller 78L05 regulator ahead of a 3.3V 
one for a DSMX module. It will over-heat regularly and cut out -- usually 
within seconds of power-up, then on and off every now and then -- mostly off. 
You need to use a 1+ Amp linear regulator ahead of the 3.3V reg for the DSMX 
module.

Original comment by gru...@gmail.com on 10 Feb 2013 at 10:48

[GoogleCodeExporter]

Im using a switching regulator directly connected to the lipo and
with an older version of er9x i dont see these problems.

Original comment by lilv...@nscit.com on 10 Feb 2013 at 10:50

[GoogleCodeExporter]

OK. Thanks. 

Alas, I've already spent hours fixing DSM2 protocol timing issues. If it's 
broken again I'm afraid someone else is gonna have to fix it. I'm sticking with 
r1734. 

Original comment by gru...@gmail.com on 10 Feb 2013 at 10:57

[GoogleCodeExporter]

Same for me, thats why i stick with some older known to be good version of 
er9x. But its too sad not to be able to use Open9x. But i could give r1734 a 
try when i got the new TX.

Original comment by lilv...@nscit.com on 10 Feb 2013 at 11:00

[GoogleCodeExporter]

I would certainly be interested to know if r1743 fixes the problem for you. 

I'd be equally interested to know if anyone using DSMx successfully on a later 
versions could report in here. If anyone knows of others using DSMx, please 
give them a prod (as I was. :-) Thanks.

Meanwhile, perhaps when this hot weather cools down a bit, I can take a look on 
the logic analyser and scope to see what's up.

Original comment by gru...@gmail.com on 10 Feb 2013 at 11:23

[GoogleCodeExporter]

What receiver were you using? Is it a real DSMX one?

Original comment by bernet.a...@gmail.com on 10 Feb 2013 at 11:59

[GoogleCodeExporter]

My answer to that, if only for comparative purposes, should it turn out that it 
even makes a difference, is; "Real" Spektrum branded DSM2 receivers. (Good 
point, though.)

Original comment by gru...@gmail.com on 11 Feb 2013 at 12:34

[GoogleCodeExporter]

My question was directed at the issue's poster for 2 reasons, the first indeed 
to know if it's a genuine receiver, and the second because I'd like to know the 
exact receiver model to know if it's really a DSMX receiver. The poster said he 
had a "DSMX" problem, but we don't know if he's really using a DSMX RX, or just 
has a DSM2 receiver with the radio set on DSMX.

Original comment by bernet.a...@gmail.com on 11 Feb 2013 at 12:52

[GoogleCodeExporter]

Understood. However, it has been reported, "... with an older version of er9x i 
dont see these problems."

Ultimately, I do not think these questions (or indeed my own lazy bantering) 
are going to prove very useful. What is needed is for the firmware version 
reported faulty to be put on a stock board and connected to a scope to have its 
performance verified, at the PPM out pin. No TX modules need be involved.

I had assumed there would be several others able to do this. If not, then I 
suppose I'd best make a greater effort?

Original comment by gru...@gmail.com on 11 Feb 2013 at 1:18

[GoogleCodeExporter]

I found a Turnigy transmitter, with a stock board and programmer cable 
attached. So I hooked it up on the logic analyser, with the current trunk-1947 
(compiled here, using avr-gcc v4.7.1). [This is not the code revision under 
which the problem was reported, but a later one.] 

Thus far, after several sessions of 80+ seconds of sampling, whilst moving 
sticks and changing settings in the MIXER screen, I have been unable to find 
any fault in the DSMX data stream at the PPM output pin in the TX module bay.

Also, I almost am afraid to say that the comment, "I just blew up (still trying 
to find out how) my 9x so i can't help until i got a new one" -- has me 
concerned. 

Perhaps we should wait until the replacement transmitter arrives? The cause, 
"blow up" *might* be related???

Original comment by gru...@gmail.com on 11 Feb 2013 at 2:27

[GoogleCodeExporter]

> I had assumed there would be several others able to do this.

I'll be able to get back into it again once I come home from my vacation at the 
end of the week - I'm actually close to you at the moment, in Wanaka now and 
flying to Auckland again tomorrow ;)

Original comment by bernet.a...@gmail.com on 11 Feb 2013 at 4:08

[GoogleCodeExporter]

Gosh. OK. Trust you had fun. ;-)

Original comment by gru...@gmail.com on 11 Feb 2013 at 7:13

[GoogleCodeExporter]

I am using AR6210 with satellite so its "real" DSMX on the air as well.
But i doubt that really matters. In the past those problems were always caused 
by timing issues on the output data stream.
My blowing up is definitely not related to the problem. I will get a new TX
by mid of the week, then i can do tests using a scope myself.
Its good to see that you folks in here care about the problem.
Note: i was usually able to trigger the problem by pushing the tuning keys.

Original comment by lilv...@nscit.com on 11 Feb 2013 at 8:15

[GoogleCodeExporter]

Can you explain what you mean by "tuning keys"? That's not a term I am familiar 
with, related to this system, anyway. Thanks.

Original comment by gru...@gmail.com on 12 Feb 2013 at 12:02

[GoogleCodeExporter]

I got the new TX, rebuilt everything and tested using the current version r1947.
With this version i have not yet been able to reproduce the problem, also 
hooked up a scope and the timing looks very solid to me.

Original comment by lilv...@nscit.com on 13 Feb 2013 at 9:46

[GoogleCodeExporter]

Ah regarding "tuning keys", what i mean is "trimming keys". Sorry for my bad 
english.

Original comment by lilv...@nscit.com on 13 Feb 2013 at 9:48

[GoogleCodeExporter]

I think that nothing changed between r1855 and r1947, especially on the DSM2 
front. Are you able to reproduce the problem in r1855?

I am ok to close the issue of course, but really think that you should try to 
understand what happened first!

Original comment by bson...@gmail.com on 13 Feb 2013 at 9:50

[GoogleCodeExporter]

hey i've actually had this problem with the home made dsmx module i made (out 
of a dx5e or something, never remember the model beyond dx5) and found it to be 
the module browning out because (the first time) the voltage reg was a dud (and 
no was not a chinese bought one was from my local us distributor of parts) so 
put another in and it proceeded to work fine through a few flights, the second 
time it happened it was because the reg REALLY needs a good solid connection to 
the positive power pin on the radio, so if its "just" making contact it can 
lose power for a tiny bit of time enough to lose the link to the receiver or at 
least enough to foul up the rf packet so the receiver drops the link

Original comment by Mechcond...@gmail.com on 14 Feb 2013 at 10:50

[GoogleCodeExporter]

Thanks for the info. I don't see anything wrong on the open9x side then, I 
close the issue, please reopen it if needed!

Original comment by bson...@gmail.com on 15 Feb 2013 at 6:21

• Changed state: Invalid

[GoogleCodeExporter]

In relation the the "tuning" (trimming) keys, ... I am aware as of just today 
that aileron-up trim usage on a G9X board is causing a system reset or crash 
for another user. I did not relate that and this issue together at the time, 
but now that I know "tuning" = "trimming", I will keep the (remote) possibility 
in mind. So far, I certainly cannot produce any problems, flicking all the trim 
switches rapidly, for a long time, myself -- and no one else has reported this 
to date. (See below as to probable cause, though.)

For the DSMX issue, the original poster has stated that he's using a 
switch-mode regulator (they are much more efficient) and that it doesn't fault 
under an older er9x version. I am regarding that as fair indication that this 
is not a power related issue -- probably. However, I too have discovered in 
practice that the DSM2/X module are very sensitive to power supply glitching. 
At the very least, a decoupling capacitor is required right at the module, 
across its power input pins.

Alas, I am unable to reproduce the fault and, despite the OP's assertions, we 
are talking about a radio that "blew up" soon after the report, for reasons 
unknown. Could have been power related. Just don't know. We have to wait until 
the radio is replaced or repaired and let him test again.

The trim switch thing; I suspect that the decoupling capacitor for the switch 
has a bad solder joint, thus allowing the MCU to be "spiked" when the switch is 
pressed, sometimes. We've only just started the long-distance diagnosis task, 
however.

@bertrand: "Invalid" status for this issue is OK for now, as I believe the 
original poster and others who have posted on this issue will still get email 
notifications when new messages are posted.

Original comment by gru...@gmail.com on 16 Feb 2013 at 9:18

[GoogleCodeExporter]

Right, I close the issues which are not directly related to the open9x FW, as I 
already have a lot in my plate ;)

Original comment by bson...@gmail.com on 16 Feb 2013 at 9:40

[GoogleCodeExporter]

Of course. There's quite a few others using DSM2 and no other reports so far, 
plus the above. So more than fair. I'll still be responding to further messages 
as they arrive here. I am getting notifications even after marking invalid, so 
I'm sure the OP will too.

Original comment by gru...@gmail.com on 16 Feb 2013 at 10:10