Devo8s loses active model info when batteries ran

I log a ticket for this problem - Bitbucket Issue #452

Devo8s with Devo8-V3.0.0.0-b64e40c - seems the low voltage protection does not work under all conditions.

I left the Devo8s on and the Devo8s batteries (NiMH) ran flat. When I got back the LCD was dimmed and very faint. Not realizing what the problem was, I switched it OFF and ON a few times before realizing it got to be the batteries.

I then put it on the Charger and on switch-on it came up with the same model number (Model4.in) but the name was back to Model4 and it is an empty default (template).

Since this is something that could (and would) happen in normal operations, we need to see if we can further improve the low voltage protection.

PhracturedBlue wrote: What is your battery critical level set at? This will be found in the tx.ini (it isn't settable in the GUI. It should be properly defined automatically when you 1st setup your Tx.

Hi PB,

I have never changed it or anything in the tx.ini except enabling the two other modules I installed, so it should be default. I since posted the model4.ini file it created to bitbucket and listed the changes it made to the tx.ini file - at least it disabled all modules.

I have reloaded the modules and have been flying this afternoon, with no problems If needed I can let it run flat again an monitor it. (I have now made a full backup of the full file system).

This is what the TX.ini settings were at the time:

current_model=4
language=0
music_shutdown=1
mode=2
brightness=5
contrast=5
volume=10
vibration=0
power_alarm=5
batt_alarm=3300
batt_critical=3800
batt_warning_interval=30
splash_delay=35

EDIT: I see in my new tx.ini file from the latest file system that values are now different:

batt_alarm=4000
batt_critical=3800

Although the critical level is the same, may be I should push it to 4.0 for my NiMH batteries

Hi PB, (or anyone else)

Some advise please - why would Deviation write None in my tx.ini file after switching the Devo8 off and on? This happened a few times (not every time) while I was testing the DMS2/DSMx binding issues, and then suddenly I have all protocols marked with a *(not available) even for the CRYF chip.

The template have these all correctly configured but commented out, so it not no reloading the template, but is writing "None" to these lines. The rest of the file looks as it was before,no changes.

The Devo8 was on the charger, so it could not be a low battery/voltage issue.

enable-cyrf6936=None
has_pa-cyrf6936=1
enable-a7105=None
has_pa-a7105=1
enable-cc2500=None
has_pa-cc2500=1
enable-nrf24l01=None
has_pa-nrf24l01=0

Hi PB

I was testing the DSM2/DSMx binding proces with a Spektrum DSMX satelite plugged into a 3GX FBL unit on the bench, trying to undestand why some Bind codes seems to work better than others. Devo8 was on the charger, so low voltage is not an issue and there is nothing in the crash file.

The steps leading to this happening 6-7 times over a 30 minute period.

1) Use Heli model with DMS2 or DSMx protocol, 6,7 or 8 channels.
2) Go through the bind process, remove bind plug, switch-off RX and ON again see if it binds again. 60% of the time it won't bind again.

3) If it binds again switch-off the RX and then Devo8, wait 10 Seconds Devo on RX on, see if it binds.

4) Try different bind codes, on DSM2 and then DSMx, see if that makes a difference in the rebinding. I also changed the number of channels to 6,7 and 8, as changing the protocol to DMSx or DSM2, it defaults 7.

Unfortunately I could find no pattern or trend on the Binding side except not to trust DSM2/DSMx at all to rebind. The only real result of these tests is that I got the "None" in the tx.ini file quite a few times.

RandMental wrote: ....switch-off the RX and then Devo8, wait 10 Seconds Devo on RX on, see if it binds.

Important is that after it happened the first two times, I made sure that I wait 10 seconds or more after switching the Devo on or off before I do anything to make sure the write and read processes after-and during power cycling completes.

RandMental wrote: ...
The Devo8 was on the charger, so it could not be a low battery/voltage issue.

enable-cyrf6936=None
has_pa-cyrf6936=1
enable-a7105=None
has_pa-a7105=1
enable-cc2500=None
has_pa-cc2500=1
enable-nrf24l01=None
has_pa-nrf24l01=0

RM I had the same thing last night. Was playing with my HiSky FBL-80 when I realized it wouldn't bind. I went into the modelxx.ini and every protocol had an * in front of it. So I entered USB mode and used Notepadd++ to edit tx.ini and I found the same thing you have above. I cannot recreate the steps so I can't file a bug report.

Mine is a Devo10+nrf24L01 installed.

Hi PB, Would this bug have affected the DSM2/X binding and rebinding and an existing, live connection?

I guess what I am asking is when do this code that you changed run (the RBE optimisation)? Can it affect an existing live connection to a model by killing the SPI link with the RX module?

I need to understand what I should retest to restore confidence in the DSMX/DSM2 protocol and binding process

Wish I was home so I could test this. If RM doesn't get to it I will be home about 7:30 pm GMT-5.

Thanks, will do these tests tomorrow, It's almost 9pm this side.

I have now tested for over an hour on the bench, using a Devo8s and the latest source build from bibucket.

Using DSMx and DSM2, 6ch's into a AR600 Spektrum receiver, I get very positive results and did not have one failure. (I have not yet gone back to the official V3.0.0 release due to the positive results with this latest build)

After binding, I can cycle the receiver power as many times as I want, I get immediate re-connection - that is obviously good news and is what is required for potential brownouts and loss of connections during flight.

Interestingly, I can also power cycle the TX (with and without power cycling the RX) and the TX and RX still reconnects almost immediately. It thus seems that our DSM2/DSMx implementation (tends to) selects the same channels/sequence after switch-on, rather that searching for the best/clean channels as I believe the DSM2/X Spektrum tx's do.

After an hour I cannot believe that is coincidence, as we have a few fixed and portable hotspot Wifi networks around so there is some 2,4G noise around.