V3 Firmware (Type 80, 81, 82?)

Hi guys,

I found a couple of references to the firmware

But the github most recent commit only has the readme.
I can pull the most recent file (that was deleted on the last commit)
‘PR55-61E_Ver4_Firmware.rar’
and try flashing that, but I wanted to make sure that was OK before I tried that.

I seem to have gotten my type 81 (Two Channel Vibration Sensor) into a non-working state.
I removed the Xbee, plugged it into my PC and saw it was set for PAN ID 7BCD, I flipped it back to 7FFF, but even then plugging it back into the sensor, the sensor doesnt transmit and wont enter config.

I have the adapter to flash the sensor firmware, and the instruction set above, just want to make sure the bin I am using would be safe to use.

Kyle,
did you try factory reset ?
I just loaded the new firmware on git.

Thank you Bhaskar,

Yes I tried the following combo to get it into factory reset.
Press Reset, then within 1 second, press and hold CFG for 15-20 seconds, then release.

The Red LED illuminates when I press and hold CFG, but after release, I still dont see any transmissions from that sensor from an Xbee listening (via XCTU) on 7BCD network, or in Node-Red listening on the 7FFF network.

I’ve also tried holding both R and CFG down for 20 seconds.
I’ve tried removing the batteries and powering it with an adapter (flipepd the switch back to inside for powered mode).
The LED always lights up when I press CFG, but just cant get any transmissions from it anymore, not even the standard or RUN or ACK or anything.

One other note. It WAS working yesterday time frame. It was sending transmissions about every 5-10 minutes. We had configured it into Mode 2, but also with a high nodeId.

I had re-configured the sensor down to a nodeId of 0, to remove any variability for the interval of the transmissions.

It was working.

I then was trying to request FFT from it following a standard transmission and that was not working. The sensor WOULD seemingly reply with an ACK, but not the full time domain data.

In troubleshooting this I was again reconfiguring the sensor and had set its mode back to 0, Processed only.

That took and it was sending me processed data for an hour or so.

I then went to config it again, and tried changing to
Processed+Raw,
OnRequestTimeout = 30,
Interval = 1 minute.

I believe that was the last time I had a transmission from the sensor, was the Config Acknowledgement for that, and since then nothing.

Hey Kyle,

Bhaskar and I have seen a similar issue in isolated instances where a DigiMesh module stops responding to targeted requests. They will respond to a broadcast but not if they are targeted specifically.

Unfortunately this failure is so limited we are not able to replicate it reliably enough to track it down. Our assumption is that this is a small bug in the Digi Mesh module and is related to how messages are routed.

When we ship sensors the DigiMesh module CE configuration parameter(Routing/Messaging Mode) is always just left at the standard setting of 0(Standard Router). What I would like to have you do is, in X-CTU, change this parameter in the DigiMesh module installed in the sensor to 2(Non Routing Module) and see if this alleviates the problem.

Let us know what you find.

Thank you Kyle,
Travis

Kyle,
Did you try re-flashing the firmware ?

Thanks

I tried the CE (Routing/Messagine Mode) change on the Xbee first, but that did not restore the sensor.
Re-reading Travis’s response I think that might have been the case for why it stopped responding to the FFT.

As far as it sending any sort of transmissions, I just did the Firmware update up to version 4 and the sensor started transmitting immediately. It already has accepted a reconfig to lower the interval so I can continue developing against it.

Now that it seems to be working again I will try out the FFT Request methods again with and without that CE mode change and see if one works better than the other.

Thank you guys!

1 Like

100% success rate with both CE modes (0(Standard Router), 2(Non Routing Module)).

I sent 10 requests to each head, in each mode, and ended up with 100% success rate.

Perhaps reflashing the unit removed the bug I had encountered. Seems unlikely since the bug sounds like it exists within the Xbee, not the Microcontoller on the sensor, but all I can say is that it is working perfectly fine now.

Hi Kyle,

That’s why it’s been so difficult to track this bug down. It only seems to happen on rare occasions and it’s hard to pinpoint the source.

Regardless glad to hear everything is working as expected now.

@kstokes how did you put the sensor in Bootloader Mode to upload the firmware? Like it’s described in the How To Update " Put the board in bootloader mode. to do that hold the “CFG” button and press release “RST” button and then release “CFG” button" ?

I think this is not working for me. The Run.bat waits waits waits…times out.

do this

  1. hold cfg mode
  2. press and release reset
  3. run bat script
  4. select the correct port
    ncd iot vibration sensor firmware update - YouTube
    Thanks