But the github most recent commit only has the readme.
I can pull the most recent file (that was deleted on the last commit)
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.
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.
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.
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.
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.
@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.