measurement interval lost after sensor reboot

[impellerturn]

Hi,
i somehow have an issue with the measurement interval.
it seems that its not correctly stored in EEPRom and initialized to a very high value after power off->on.

here is what i did:

pi@raspberrypi:~/Documents/WateringSystem $ python3
Python 3.5.3 (default, Jan 19 2017, 14:11:04)
[GCC 6.3.0 20170124] on linux
Type "help", "copyright", "credits" or "license" for more information.
from chirp_modbus import SoilMoistureSensor
sensor = SoilMoistureSensor(10, "/dev/ttyUSB0")
sensor.getMeasurementInterval()
65524
sensor.setMeasurementInterval(123)
sensor.getMeasurementInterval()
123

Power off sensor, power back on

sensor.getMeasurementInterval()
65524

Reinitialize python object, turns out this was not the issue

sensor = SoilMoistureSensor(10, "/dev/ttyUSB0")
sensor.getMeasurementInterval()
65403
sensor.getMeasurementInterval()
65403
sensor.getMeasurementInterval()
65403
sensor.getMeasurementInterval()
65403
set another interval
sensor.setMeasurementInterval(123)
sensor.getMeasurementInterval()
123
sensor.getMeasurementInterval()
123
sensor.getMeasurementInterval()
123
sensor.getMeasurementInterval()
123
sensor.getMeasurementInterval()
123
sensor.getMeasurementInterval()
123
sensor.getTemperature()
26.4
sensor.getTemperature()
26.4
sensor.getTemperature()
26.4
sensor.getMoisture()
229

** here the test, if the data is updated fast, yes it is**

sensor.getMoisture()
416
sensor.getMoisture()
227
sensor.getMoisture()
227
sensor.getMeasurementInterval()
123
sensor.setMeasurementInterval(500)
sensor.getMeasurementInterval()
500
sensor.getMeasurementInterval()
500
sensor.getMeasurementInterval()
500
sensor.getMeasurementInterval()
500

** power off sensor, power back on**

sensor.getMeasurementInterval()
65524
sensor.getMeasurementInterval()
65524

[cheeeeee]

I realize this is old but you are correct. There was an error with how the measurement interval was stored to eeprom. I THINK I have this fixed but i'm still going through stuff and I'm not sure this project is even supported any more.

[Miceuz]

Hi, the project is still very much supported, thanks for your contributions. Would you mind forking it from mine and adding you changes to the forked branch so I could import them to my repository?

Thank you very much for the contribution! I am a bit busy right now, but I will come back to your questions in couple days.

[cheeeeee]

Oh yeah it's already forked and under https://github.com/cheeeeee/RS485_AtmelDebug/tree/master/src. The issue here was a mismatch between the initial array declaration being u16 and the eeprom stores being u8. On my branch everything is u16 and all values are written to eeprom as u16 and loaded as u16. Also the loadconfig() function wasn't fully finished and now is in working order. I'm still working on stuff so I don't know if I really have a stable build yet or not so you have time.

[impellerturn]

Hi,
good to hear from you.
I have 3 of these sensors and are also still interested in bugfixes.
Best regards

[cheeeeee]

Added some possibly stable .elf and .hex files at https://github.com/cheeeeee/RS485_AtmelDebug/tree/master/src/Release
If anyone is brave enough to try and flash their sensors. Hopefully I can get a programming setup to test these patches out this week.

[impellerturn]

Hi,
mine are buried and also sealed, so "quick testing" is not possible for me :(
Sorry, best regards

[Miceuz]

I think this bug might be a combination of the bug in the library as incorrect register number was specified for measurement interval AND MAYBE eeprom saving issue. @cheeeeee is correct - I should be saving 16bit values, not 8 bit. Even though I don't use them all. Will work on that

[cheeeeee]

Yeah when I was going through it you could do a mix of 8 bit and 16 bit ints but honestly it's just way easier to make everything 16 bit even if it's a little inefficient. If there's anything you want me to look at more in depth just let me know i'll be happy to do it.

[Gagi2k]

I guess my sensors have the same bug. I have 20 sealed sensors, most of them buried, but i also have some replacements at my desk. Do you think these saving issues can also affect other areas (not just the measurement interval) which could make the device stop working completely and not answer anymore ?
All my replacement sensors (which were not used once, just used for a basic check when i got them) are all not answering anymore. I extended your python library to scan all baudrate/parity combinations, but no response. Any help on what i can do to debug the problem or fix/reflash is very welcome g

[impellerturn]

I guess my sensors have the same bug. I have 20 sealed sensors, most of them buried, but i also have some replacements at my desk. Do you think these saving issues can also affect other areas (not just the measurement interval) which could make the device stop working completely and not answer anymore ?
All my replacement sensors (which were not used once, just used for a basic check when i got them) are all not answering anymore. I extended your python library to scan all baudrate/parity combinations, but no response. Any help on what i can do to debug the problem or fix/reflash is very welcome g

I had a similar issue with the sensors stopping reponding. But i did not associate it with the storing problem.
I was reading the values for temp and moisture every second and after a while (random, usually something between 2 and 24 hours) none of the sensors attached to the bus was reponding.
Only thing that helped was cutting the power supply and giving them a hard-restart.
At that point i´ve discarded the idea of measuring moisture and went back to basic time sheduling of my irrigation system.

[chris-b-tanner]

Is this issue still open? I have similar behaviour across multiple sensors; after powering down and up again the reading interval requires checking and resetting regularly to ensure correct readings. I also have the odd occurrence when the slave ID is reset to 1, which causes much more trouble as when there are multiple devices on the bus, it's not fixable by the master.

[Miceuz]

I have pinpointed that to a power sequencing issue. I don't know yet what, but something causes the sensor to corrupt eeprom when power is rising/falling too slow. I.e. this should happen while turning of/on the whole string of sensors.

Increasing BOD value seemed to help, so I did that for my current batch of sensors.

But also I have a hardware solution that powers sensors and disconnects both power and modbus lines when voltage is too low. If anyone wants, I can send that as a bandaid fix for this problem, contact me directly plz.

Also just disconnecting cable instead of allowing slow switch off of the power supply is an option if you have it on a connector.