config save failed

[lafrech]

Hi.

My setup stopped a few hours ago. Here's what my logfiles show:

2013-03-24 07:36:52,413 INFO Serial RX: > 0i
2013-03-24 07:36:52,419 INFO Serial RX: config save failed
2013-03-24 07:36:52,421 WARNING Misformed RX frame: ['config', 'save', 'failed']

The gateway script (the python one) is still running, but I don't get any data from COM port.

Is this the "config failed" line ? (Maybe the string differs between source and hex.)

https://github.com/mharizanov/RFM2Pi/blob/master/firmware/RFM2Pi_RF12_Demo/TinySensor_RF12_Demo/TinySensor_RF12_Demo.ino#L85

Is this a know issue ?

I rebooted the pi and it's working again. Should I investigate something next time before rebooting ?

[mharizanov]

I see that there was an instruction to set the node id to 0, that's why it failed. Typically this could happen on serial gibberish being picked up; I'd suggest to lock the settings (using 123 x) to prevent this from happening

[lafrech]

Hi. Thanks for answering.

Where does serial gibberish come from ?

• Is this electronic interference ?
• Is it when RX and TX happen at the same time (I don't know if RX and TX at the same time should work or if it is forbidden).

Do you mean I should modify _set_rfm2pi_setting function:
https://github.com/Jerome-github/emoncms_raspberrypi/blob/rfm2pigateway_dev/rfm2pigateway.py#L359

to toggle config.lock each time I change a setting ?

Could a "modify setting" TX message be lost because of "serial gibberish" ? Should we use a ACK, then ? Or resend settings from time to time ?

[mharizanov]

I have never really reached to the bottom of it, there was a discussion here: http://openenergymonitor.org/emon/node/1506
It may have to do with using software serial and a RFM12b transmission coming in at that time, but these are just guesses.
The "settings lock" function is a toggle one, that means that each call will toggle the setting from the default unlocked to locked state; The current lock state is displayed in the help message when issung 'h' command. This makes it a bit harder for the scripts to unlock, modify and then lock back settings. The intention was that you'd set the configuration using minicom, the lock it for changes.

[lafrech]

OK I think I get the logic. We seem to have reliability issues with the serial link. Then I suppose it could also affect any command or reply, right ? So you can never be sure a message was actually received.

We could do (by decreasing niceness) :

1/ Solve hardware problem if it is hardware. Hard to do if we don't know where this comes from.

2/ Add some CRC and ACK to secure the link.

3/ Add some software workaround using the toggle you created (and hoping the toggle command will be received, otherwise we don't know which state we're in unless we use the h command and parse the result). This can be hidden in the code (toggle before and after each command. this would be a sort of 0-level CRC: "yes I'm sure" - command - "ok I'm done") or appear in the GUI with a switch to manually do the toggle. But should the user be bothered with this ?

Do you see anything else ?

I could work on 3/ but I'd favour previous solutions. Do you think ACK/CRC is something that we could reasonably do ?

Do you know if latest (SMT) version of your board show these problems as well ? If they don't, it's less of an issue to use the toggle workaround in the meantime.

[lafrech]

Hi Martin.

Do you have a link to a piece of information about suspected ATTiny serial lib bug ? (Forum thread, bug report,...).

Thanks.

[mharizanov]

Check this thread on the Attiny 84 + SoftwareSerial issues:
http://arduino.cc/forum/index.php/topic,123388.msg1133148.html#msg1133148

So locking the settings seems the only reasonable solution for the v1
board.

On Wed, Apr 17, 2013 at 6:10 PM, Jérôme Lafréchoux <[email protected]

wrote:

Hi Martin.

Do you have a link to a piece of information about suspected ATTiny serial
lib bug ? (Forum thread, bug report,...).

Thanks.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-16511574
.