Advice please - DSM2 Binding with AR600

Guys

Advice from the Spektrum/DSM2 users please.

This is the first time I am using the DSM2/DSMX protocol in Deviation.
I bind with an AR600 in DSM2 mode and and it worked as expected.

I did two flights with no problem , except I have to rebind with the Bind plug every time after I switched the TX Off.

I do the binding as in the AR600 Manual: Bind plug in the port, power on, fast flicker, Bind with a 6 Digit code, Led goes solid and I have full control after which I remove the Bind plug and fly.

If I recycle power on the TX, I have to go through the Bind process again, as if the Deviation generates a new binding code after power on.

What am I doing wrong?
Using Devo8s with latest Deviation build from Bitbucket)

Thanks Vlad

The AR600 is a DSM2 only receiver, 6 channels. I can get it to bind the first time without a problem, every time.

The receiver "remember" the bind code as it should. If I switch the receiver off and on, it comes up with a slow flicker (brownout Detected) and reconnect to the TX. This I can do many times, with a short off-time and long RX off-time, without losing the bind and reconnection.

BUT - when I switch the TX OFF and ON, and then power the RX, the RX LED stays off and no re-connection occurs.

The Bind code is the same and any changes to the model are saved - TX is on the charger to ensure sufficient voltage for the Models to be saved and reloaded.

To me it seems the Deviation does not "remember" the bind code and/or the two 2.4g channels that were used.

Changing to DSMX has only one change - the AR600 don show the brown-out connection but gives a solid LED when re-powered.

However when the TX is powered on and off, same as with DSM2, NO connection and all LEDs off on the RX.

I have no idea what is could be the reason for this behaviour, it does the same with an Align 3GX with a Spektrum DSMX sat receiver.

Please let me know what bind code you use and how many channels - lets see if I duplicate your setup. Or even better, please post me one of your DSM2/X models

For now I have replaced the AR600 with a Devo10 and are flying with the original Devention 8s firmware (which works 100% and rebinds immediately so there is no HW issue.) I cannot risk a Deviation problem causing a crash.

I am not sure that might be a stupid question: Do you powered off the Tx also?
I do have Spektrum bricks without bind plug and orangeRx receivers only. But in any case I always do a shutdown after binding. The German manual of the AR600 do have a different translation to the English version: They write to remove the bind plug before power off the Tx (without to mention that the Rx should be powered off also). I use the fixed ID with all Rx without any problems while repowering.

I have tried all combinations of power off before and after the Bind plug is removed etc, with no luck.

I have also reloaded the file system to make sure my model.ini files are the latest and had not been corrupted by new firmware releases. I started a new 6 channel Plane model with DSM2 and 6 channels, unfortunately it gives me the same results on both the AR600 DSM2 6ch receiver and a 3GX heli FBL Gyro with a Spektrum sat receiver.

I am out of ideas, will do some more tests tomorrow

On some of my models, I also use DSM2, without a problem. After reading your post, I tried this:

AR6100e:

Using default binding code 123456 doesn't work and shows what you described. After I changed it to something else, it did work fine.

AR9000:

Haven tried using the default binding code, but I am using it with another binding code for a while, no problems as you described.

So maybe you are using the default binding code?

Hi Pat
It is already a concern if certain bind codes don't work without an explanation.

It took the receiver to the LHS this morning where we tested it with a DX4e, it worked perfectly, so I am sure there is no problem with the receiver.

Thus back to Deviation. I have found a bind code that seems to work - will test it over the next day or two.

Fully agree with you. I was also surprised. I will file a bugreport for this.

As far as I can see, I only noticed it with the default binding code 123456. Could it be that the ASCII code of this string is different? I mean, like characters and not numbers?

I once noticed that on a WiFi access point, using Caps Lock or using the shift key for creating capital letters was not the same. Only when using the shift key, I got connected, using caps lock gave me "wrong access code".

OK, I ran out of clues. Shall I delete the bug I posted or leave it as it is? I can live with this issue as I never use the default binding code anyway. Maybe a solution would be to make the change of the binding code mandatory.

Problem fixed with commit 81effe3 (Prevent resetting tx.ini ports).
Since this update (27/12/2013) I cannot simulate the problem(s) anymore.

Ticket closed on BitBucket