Taranis and DSM2 mods

[EjectSteve]

I have two Linux builds.
On Mint 64 bit this works: PCB=TARANIS (with no options). DSM2=PPM and DSM2=SERIAL does not work
On Suse 32 bit: DSM2=PPM works but DSM2=SERIAL does not work. Bertrand is saying DMS2=PPM, so I think I'm good, I'll give that firmware a try.

Perhaps I have incomplete 32bit libraries on my 64bit install. John, what are you using for Linux?

[EjectSteve]

This is what I have found in testing with a dx4e hack module:
This hapened with all tests after binding, during testing: If I enter the setup menu of the plane, when I get to the "SERVOS" menu, the servos positions change. This may be affecting only rx channels 1 and 2. Can someone test this (no props please!)

• DSM2 OrangeRX, binds and operates on the bench fine except for the SERVOS screen issue
  Nano CPX helicopter, binds fine in DMS2, works fine except for the SERVOS screen issue above
  Nano CPX helicopter, binds find in DMSx, but servos 'go crazy"
  NanoQX quad. It bound once ok in dsm2 mode. It seemed to lose binding when I changed the battery. The binding light would flash and then go off completely when I entered binding mode on the TX. It should have stayed flashing for no bind, or went solid when it was bound.

I was able to bind the NanoQX back to a dx6i, no problem.

[Mechcondrid]

well that actually sounds like a ppm issue of some kind i did have that problem with the module i made then i realized i had the diode (i think this was quite a while ago) in the opposite way it needs to be on order for the module to function correctly
(you want to use the reverse of how you would normaly put in a diode so forward is towards the tx line not from)
other than that i can only think of one other thing; that something is not compiling correctly on your setup. afaik it is possible to compile correctly (at least in terms of linker or compiler errors) and not get a completely viable firmware

[yay]

Can you guys put online a binary with dsm2 enabled (preferably all the other options default)... I'd would give it a try and setting the build environment would take me the weekend that I could use for testing instead

[Kilrah]

I guess I'm over my head here. I was able to compile a version - they system said it was version opentx-r2859 216

It flashed ok, but the Taranis boot warned that it had to 'update the eeprom'.

Note that if you just want to test DSM2 without messing things up you might want to use r2856.

r2857 is a major rework of the firmware, many things don't work the same way anymore (models need thorough checking to see operation hasn't been broken, and may benefit from reprogramming to take advantage of the new features), EEPROM format is changed, and there is no companion9x support yet.

So use r2857 and later strictly for testing only, and backup your EEPROM before flashing so that you can go back to release version for flying.

[JohnAustin]

Hi
I have successfully compiled and loaded revision 2860
Fedora 18, gcc-arm-none-eabi-4_7-2013q3-20130916-linux.tar.bz2, DSM2 = PPM
So farI have bound successfully to the following Rxs
Spektrum AR9310 in both DSM2 and DSMX (This Rx is only just cheaper than a Taranis !!!!)
Spectrum AR6255 in both DSM2 and DSMX (two of this type)
and servos are moving in the right directions - brilliant !
The Model Match is also working fine

I have not carried out a range test - hard rain in England today

Aside
Only problem I have found is that Aileron differential does not work correctly with revision 2860
I am driving the diff with GV1 derived from S1

I attach the circuit and parts I used for the module hack

Many thanks to everyone for the upgrade to 6 channel DSMX and model match in my case

[EjectSteve]

Thanks Kilrah. I checked out out build 2856 and compiled it with the DSM2=PPM option. All tests so far are good. No issue switching back and forth between dsm2 and dsmx models either. Like you thought, my issues were from using the bleeding edge release instead of a stable version.

[JohnAustin]

Repeated compile with r2856 and all is well !

Thanks again
John

[yay]

I've just made few flights with EjectSteve's build (r2856). Everything works flawlessly!

[Kilrah]

I think there is still something wrong with binding.
Can you tell me the procedure you did for binding so that I can check if it's really how it was intended?

[EjectSteve]

I am just binding micros right now, so there is no binding plug. I turn the TX off and turn on the micro heli/quad etc. The micro goes into binding mode automatically, then I turn on the TX and go into dsmx or dsm2 binding mode. After a few seconds the controller on the micro goes 'solid'. I stop the binding procedure. and reboot everything.

One thing with all my micro's (after they are bound the first time) is that sometimes you have to turn them on and off a few times before they bind again. But this happens with my dx6i and is a known issue with all TX's I think.

Sometimes when binding the first time, the RX doesn't seem to bind until after I stop the binding procedure on the TX (maybe after 5 seconds). As soon as I stop the binding on the TX, the RX light 'goes solid'. But Spektrum binding is always a pita, even with 100% spectrum equipment so I never thought to blame the Taranis.

The most amazing thing is the native FrSky binding. It's so fast that you think you did something wrong!

[Kilrah]

One thing with all my micro's (after they are bound the first time) is that sometimes you have to turn them on and off a few times before they bind again. But this happens with my dx6i and is a known issue with all TX's I think.

Yeah that's an issue with the receiver on the micros I think. On all of mine I've sometimes had to cycle power a couple of times until they would actually get into the flashing binding mode. Go figure.

Anyway on one model I power it up, wait for flashing LED, power up the radio, enter binding mode, nothing happens. Exit binding mode, still flashing. Cycle power to the radio, and it finishes binding and works (but that makes no sense).
On the other, no way to get it to bind at all.

Will have to investigate.

[EjectSteve]

From a troubleshooting point of view, is this experience something that some of us could try to duplicate as well? I wonder if the same problem would follow your module and RX if you tried to do the same thing on a 9x with er9x? (if you have them available)

I wanted to fly today, but had the dreaded "button push through" issue with the enter button. I glued the button strip back on the post and I think I'll be ready to do more testing soon.

[Kilrah]

Update, I put my module on my 9X again and can't bind to the first model I refer to anymore either. This exact combo has many flight hours of perfect operation, so maybe something's gone wrong on my module. Will have to check the signals and power.

[JohnAustin]

I have now successfully flown two models with r2856 and DX4e module !
AR6255 Rx in DSMX mode (DSMX mode was selected on Tx, I assume that was what was used)
AR6100 Rx in DSM2 mode (DSM2 only Rx)
The only thing I noticed was that on one occasion the AR6255 did not connect cleanly.
Power cycling the Tx gave a clean connection - so not really a problem
I have not been able to repeat the event in about 30 attempts
This was a connection glitch not a binding problem
The symptoms were that the servos appeared to have only 2 or 3 bits of resolution
ie the surfaces moved in response to the sticks but in large jumps
Foolishly I did not check if the correct surfaces were moving !
Maybe just an isolated glitch
Aside
The DSM2 only receiver appears to work correctly even if DSMX is requested in the Tx
ie it falls back to DSM2
Is this as expected ?
Is it unhealthy to always request DSMX in the Tx and let the Rx and Tx sort it out for themselves ?

[Kilrah]

Yes DSMX is actually "Auto DSMX/DSM2". The module chooses DSMX if the receiver supports it, DSM2 if not.

[heliphil]

I wondered about that as I tried binding with DSMX on my MCPX and it worked although I thought my module was only DSM2

[ShowMaster]

My DSM in a Taranis story.

I built up a dx4e rf deck into a module shell per the how to's. It works with the new patched opentx FW and I can bind to my Taranis. The range check with a new never used orange rec with satellite is maybe 30 ft.

I had the rec antennas mounted at 90 deg to each other 6 in apart.

I flew this in a SkySurfer. All was good until about 200ft out and up in an area the Spektrum flyers call the "link loss triangle" I did indeed lose link and regained it many times in this location but managed to recover and land ok.

Next I tried a a new updated orange tx DSM module in the 22ms ppm mode.

I didn't check it in the range check mod but did walk it out 60-80 ft.

When I flew it I got out and up in the same area as the other test flight and time I lost the link and it never recovered and when I went to the crash site the receiver and 2 servos were still working normally. They and the battery connection survived.

Funny thing was that the motor never went into a power down failsafe? That was checked before the flights and worked. With the dx4 hack it did but not with the orange tx module in the air.

Yes it could have been a module connector pin issue but no module power or ppm in should have triggered the receiver or esc failsafe.

What bothers me more since I'm only playing around here, is that the Spektrum owners actually have a "plane kill zone" they all point to.

So what happened? The plane had flown earlier and has for months using the Frsky mode and
D receivers without ever losing link lock, even in the "kill zone".

The untested dx4 hack and orange module were only used for close range indoor BNF flying in the past. The orange rec was new and also worked at checkout close range.

The fact that many Spektrum owners seem to lose their planes in a certain area makes me think it's a Spektrum dsm2 vs local interference issue?

On the other hand, it could be the new orange receiver since it also was untested.

Since the modules and receiver survived and still work I'm probably going to setup a range test of them all to sort this out.

I can try the dx4 hack in my sky tx and the original orange DSM and another new unused orange module. ( yes, both are the latest HK ones)

I also have my dx7 and many used and new dsm2 real receivers to compare it all to.

Funny thing is, two years ago my last Spektrum dx7/6200 crash was in this same area at the field with the same symptoms! That's what got me thinking Frsky and why that's all I fly today, until the DSM test.
I almost forgot what a link loss was like.

I tnink I'm the only one in the large club trying all this so I don't have anyone that I can compare this R&D with.

I've ordered some new test planes so I'll retest and hopefully sort this out on the bench.

I'm open to technical ideas on module testing. A real Spekturm 6200 or 7000 dsm2 or several is a must now.
I'm considering this a dsm2 issue and not a Taranis issue. However this is the first time I've used the module bay. To be totally fair I'll plug in a new tested DJT module and test fly using the ppm mode again and the rear module port as I did with the orange HK module.

I'm not faulting Spektrum itself because everything that went wrong was a Spekturm hacked or clone device including the FW and tx hardware.
Many fly Spektrum everyday at this field and are very happy. But there is that famous crash zone that only seems to eat Spekturm planes and no other brand?
This is a fact finding mission so I need all the facts.

[EjectSteve]

I have been having some weird binding issues. I hesitate to bring it up because I am talking about “micros” and those are always a bit challenging to bind.

I tried over and over to bind a Nano CPX to “receiver number 11” both on dms2 and dsmx mode. As soon as I change the receiver number to 9, it binded immediately on the dsmx setting. I have had similar issues with other micro’s, but it is difficult to have it consistently fail consistently work. That’s not a great setup for troubleshooting and eliminating criteria etc.

Regarding ShowMaster’s difficulty, is link/range something that has could have anything to do with a Taranis implementation of dms2? That might seem like a dumb question, but that seems completely between the module and the RX so long as they are bound properly?

[Kilrah]

Hah interesting, might be on something!

I did my tests with a dummy model, no 21. One of my micros (with a newer AS3X DSMX receiver) would not bind at all (many tries, left in bind mode for 1min+ etc) and the other (older DSM2 receiver) did the strange thing I mentioned (had to reboot the TX). With that DSM2 one, if I leave the plane and radio on but restart the binding procedure multiple times (which cycles power to the TX module) it never binds. Change receiver no to 20, and it happily binds perfectly normally, and the other plane does too.

I guess these modules simply don't like some model numbers, after all they're only used up to the DX6i which has 10 model memories. Might be that feeding it a model number >10 leads to unpredictable results.

[JohnAustin]

Following up the above I have tested the binding to an AR9310 Rx and its associated remote
This is quite a modern up market Rx from Spektrum
It would appear that both DSM2 and DSMX binding behave the same but I have NOT tested all DSM2 possibilities

1-20 OK
21 Fails
22 OK
23 - 28 Fail
29 - 58 OK
59 Fails
60 - 62 OK
63 Fails
I will double check these again if required
I can check an AR6200 (DSM2 only) if required

[Kilrah]

1-20 OK
21 Fails
22 OK

Talk about bad luck with my random #21 test model

I'll try to confirm tomorrow, but we might need to limit receiver no to 20 for DSM...

Would be interesting to see if there's a wraparound (i.e bind with e.g. 22, and see if another code results in the model responding).

[EjectSteve]

Just to make things complicated, I tesed JohnAustin's list of fail numbers with a dsm2 orangeRX and they all bind fine. I don't own any stand-alone dsmx receivers so I can't test the other options.
21 Works
23 -28 Works
59 Works
63 Works

OrangeRX is probably not a perfect implementation, so not a great test. I was able to bind a micro heli with 'stock' dsmx(2?) controller, and it bound on 21 but the binding was lost when I power cycled the heli and radio. I did the same on 23 and had no problem binding and power cycling - binding was not lost. I wonder if the pass/fail pattern has something to do with each RX?

[JohnAustin]

Hmmm
More tests - not every possibility has been tested !
DSMX mode selected on the Tx
AR9310 Rx
Checked through my results and can summarise them as follows
0 - 20 Bind OK, survive Rx off/on, survive Tx on/off
Very occasional need for second attempt at binding required
Channels above 20 may or may not bind - as per the previos list - those that do bind will survive a Rx on/off
No channels above 20 that do bind survive a Tx on/off

I will try another Rx - AR6200
I also have one of these I can try
OrangeRx R710 Spektrum DSM2 Compatible 7Ch Receiver w/Failsafe

[EjectSteve]

No channels above 20 that do bind survive a Tx on/off

Did I read th at righ? Witih your AR9310, no Receiver number above 20 stays bound when you power cycle the TX or RX? How about with your r710? Can you try 21 and 59 as an example?

[JohnAustin]

For the AR9310 for all channels above 20, even if the channel binds, a power off/on of the Tx will prevent a successful re-connection (loss of binding I assume)
I didn't test every possibility though
I have done some prelim tests on the 710 (DSM2)
It would seem that the 710 behaves differently - if it binds then it survives both Rx and Tx power cycles
I have not yet found a channel that is OK for the AR9310 and fails on the 710
There are big gaps in the list though
Orange 710 DSM2
63 Bind OK Rx off/on OK Tx off/on OK
62 B OK Rx OK Tx OK
...
59 B OK Rx OK Tx OK
...
29 B OK Rx OK Tx OK
28 B Fail
27 B Fail
26 B OK Rx OK Tx OK
25 B OK Rx OK Tx OK
24 B Fail
23 B Fail
22 B OK Rx OK Tx OK
21 B Fail
20 B OK Rx OK Tx OK
19 B OK Rx OK Tx OK
...
Next tests
AR9310 in DSM2 mode
AR6200 (DSM2)

[JohnAustin]

Summary so far
Note:
Only the following channels have been tested in detail: 00, 19 - 30, 58 - 63
---------------
DSM2 Mode - four receivers + remotes (AR9310 + SPM9646, Orange 710, AR6200, AR6210 + SPM9645)
All Rx behave in the same way when in DSM2 mode
If the channel binds it appears to work correctly and will survive a Rx and/or Tx power off/on

Channels 58 - 63 OK
Channels 21, 23, 24, 27, 28 Fail to bind
Channels 00, 19, 20, 29, 30 OK
---------------
DSMX Mode - two receivers + remotes (AR9310 + SM9646, AR6210 + SPM9645)

Some channels above 20 will bind
If they bind they will survive a Rx power off/on
Even if they bind none will survive a Tx power off/on

The AR9310 and the AR6210 both fail to bind for these channel numbers
Namely 21, 23 - 28, ..., 59 and 63
(Compare with the DSM2 failure list above)
---------------
Conclusion
In DSM2 mode some channels above 20 are unusable as they will not bind
In DSMX mode channels above 20 cannot be used as binding appears to be lost when the Tx is powered off/on
It is still does not appear to be possible to determine whether the problems are associated with
DSM2/DSMX Tx module limitations or the Tx software

Question that appears relevant
Do the same limitations occur when a DIY DSM2/DSMX module is installed in other OpenTx transmitters or is it just a Taranis problem?

[EjectSteve]

Question that appears relevant
Do the same limitations occur when a DIY DSM2/DSMX module is installed in other OpenTx transmitters or is it just a Taranis problem?

Looking at companion9x, I think er9x only holds 16 models and the "RX number" must be hard coded to the model slot since it doesn't appear to be a way to change it. Perhaps the model slot number is appended differently in er9x than the opentx version?
Nano CPX
1-10 Bind
11 No
12 Yes
13-14 No
15-16 Yes
17-18 No
19-20 Yes {19-20 did not survive tx reboot}

[Kilrah]

openTx handles receiver no the same way on the 9x, but as there are only 16 model slots you won't end up with a number >20 unless you really set it there yourself (and there's no reason to).
So the problem is likely the same, but nobody ever noticed.

The only solution seems to be to limit the RxNum to 20 if DSM is selected.

[JohnAustin]

Certainly not a problem to me
I do have about 12 Spektrum Rx hence being able to use DSM2/DSMX/MM is a real bonus at the moment,
however, the future is FrSky !