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.
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.
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.
Hey guys, hope its ok to resurrect this a bit, as the above text might still apply.
We have some of our guys updating firmware on type 80 (Single Channel Vib Plus) and type 81 (Two Channel Vib Plus) sensors, and on about 5 or 6 now, after the firmware flash the unit no longer seems to transmit.
When I say it wont transmit, meaning I dont hear it on 7FFF, and it wont appear as accepting configuration when a gateway is in configuration mode, and the sensor gets put into Config mode.
I even hooked up the sensor to the UBSToSerial adapter, opened CommOperator/Putty and tried to view its logging, and I don’t see any messages coming across from the sensor after pressing reset
If I remove my USBToSerial adapter and put it back to a known good sensor, I DO get the logging messages when I press reset on a sensor.
The onboard LEDs DO lightup when CONFIG is pressed on the sensor, just the compute part of the unit seems to be dead.
Is there anything else we can try if after a firmware flash, the sensor seems to no longer be working?
does the board say PR55-61 on the board?
If yes then that’s the issue. The firmware on the git is for hardware PR55-72.
If you are trying to use the git firmware one PR55-61 it will brick it.
I will send you a new firmware once you confirm your board number.
