XRF - Timeout No Data Received Error

[EvanG]

GadgetNut,

In an attempt to get better battery life out of the XRF transmitter, I thought I'd try loading one with the beta firmware mentioned here: http://projects.privateeyepi.com/home/home-alarm-system-project/wireless-projects/download-new-firmware-to-a-wireless-module

I was able to wake the sensor and start the firmware upload (I've done this a few times now with no issues), but the upload appears to have stops a few hundred lines in, and the XRF is now non-responsive.  Any ideas about the best way to recover this from its current state (preferably using the slice of pi)?

The objective here is to get more battery life out of the XRF when combined with the normally open reed switches included in the alarm kit.  Hopefully I haven't done something irreversible.

[EvanG]

False alarm.

I was able to bring the sensor back to life using the XCM utility from Ciseco.  Not too difficult, but it has the feel of an activity that could easily make things worse rather than better.

I was able to load the new firmware using that utility.  I haven't tried again using the xrfuploader.

If you have any further pointers on the new beta firmware, I'd be interested to hear them.

Thanks!

[Gadjet Nut]

Good to hear that. By the way, what OS are you running XCM on? 

Are you planning to upload v73 of the button firmware? I have had that on my garage door for over a year with a single coin cell battery. All depends on the amount of activity though. 

[EvanG]

I had to run it on Win 7 (dual boot iMac) with a USB - UART adapter and jumpers into the slice of Pi.

I did upload v73 of the firmware, but it doesn't appear to be triggering an UpdateHost.  Below is an example when I run rfsensor.py.

I open a door and the llap message comes through: 'BTNOFF' and 'BTNON'.  Then I run over and open a door using a sensor on the older firmware, and it clearly triggers the host update.  Just to be clear... there are two tests. New version first, data comes through, no host update, then old version, data comes through and updates host.

Am I using an old version of rfsensor.py?  I started picking through code, and thought it might be better to ask.  

Thanks!

[EvanG]

In case you're worried... I immediately realized I was an idiot and changed my password.  Wasn't thinking!

[Gadjet Nut]

It should work. Check the version of your rfsensor.py. Does it have the following code:

if data.startswith('BTN'):

                                        sensordata=data[2:].strip('-')

                                        if currvalue<>sensordata or currvalue=='':

                                                currvalue=sensordata

                                                ProcessMessage(currvalue, 0, devID,1)

[EvanG]

After adding a bunch of lines to print everything, it looks like the ProcessMessage function is looking for a BUTTON ID ('A' or 'B' under the older firmware).  Unless I missed something in the configuration, I don't believe the new firmware allows for a two button config and thus does not provide a button id.  By the time it got to processing a message, I think the button ID was coming through as 'O' and the value was 'FF' which isn't able to be processed.  I think I fixed this by  changing the following line you posted above:

FROM:

sensordata=data[2:].strip('-')

TO:

sensordata=data[1:].strip('-')

Did I miss something in the config of the XRF that would add an Button ID to the llap message?

Did I potentially break something else with my change above?

[Gadjet Nut]

Looks good, I don't think you broke anything. It might be a bug. Not many people have used this firmware (you may be the first) so it could easily be a bug. I'll load up that firmware and do some tests.

[EvanG]

Thought I'd post a quick update.

The firmware appears to have completely remedied any battery life issues... I've been running 10 days now with essentially no drop in the battery voltage for a switch that is opened and closed a few dozen times daily.  Success there.

On the other hand, I attempted to apply the same firmware to two other sensors and ran into the same issue where the upload failed a couple hundred lines in and left the XRF in boot loader mode which I was able to recover using the XCM tool.  On the third switch, I attempted the upload from the XCM tool directly, and actually ended up even closer to 'bricked' status.  I was forced to pull it back to boot loader mode by typing a '~' within 150 ms of power up (not easy).

So, if there is a bug to report thus far, it is on the installation only, and it seems to happen with some consistency (3/3 at least) across two methods of upload (miniterm.py and XCM)  No further issues after that.

[Gadjet Nut]

We use a Raspberry Pi with a Slice Of Pi breakout board for uploading new firmware, and have loaded 1000`s of firmware upgrades with no problem. 

What are you using?

Good news on the button firmware.