FiPy/Pytrack losing its firmware each day

[Dylan]

Hello,
I have been having a problem with one particular FiPy/Pytrack device where after about 1 day of sending messages over LoRa it will just stop. It is out in the field with a solar panel, LiPo battery and solar regulator (https://www.dfrobot.com/product-1139.html) inside a weather proof box. I also have two other devices that have survived for over a month now with no problems in the exact same conditions with the exact same code (different dev_addr etc though).

I fix the failed device each time by re-installing the Pytrack firmware, does anyone know why the Pytrack firmware would be getting wiped or damaged in any way every time after approximately 24 hours?

Other things worth noting:

• Before Pytrack firmware re-install the blue light doesn't turn on at all
• When the Pytrack/FiPy is plugged into the computer it does not show up in any form, COM ports, libusk or anything, I've watched device manager while unplugging/plugging in and nothing changes. its just not there.
• The battery does not go flat at any stage, even after I pick it up a few days after its stopped sending it still measures around 3.7V (deployed at ~4.1V)

[catalin]

hi @Dylan,

I've never saw a Pytrack loosing its firmware, in theory, it could happen.

Just to clearly understand your problem:

• executing dfu-util-static.exe -D pytrack.dfu, solves your problem? No other Fipy update or micropython scripts being uploaded, right?
• you're saying no libusbk was detected (by Win10 machine), but still dfu update process would not work without finding a usb device capable of dfu protocol
• how do you know the pytrack firmware was deleted, go_to_sleep() doesn't' work? Pytrack firmware is in charge mainly of just USB-to-Fipy-serial conversion.

[Dylan]

Hey Thanks for the reply.

1 - executing dfu-util-static.exe -D pytrack.dfu solves my problem each time without doing anything else before hand

2 - I only checked this in Device Manager, but nothing at all changed in any window, I'll check through command line or any other method you recommend when I get back to work on Monday.

3 - This is actually an assumption based on the fact that executing dfu-util-static.exe -D pytrack.dfu fixes the problem. I'm not sure how I could check this, maybe I'll try a different FiPy on top of the Pytrack although I don't see how that would change anything, I'll try whatever you think can verify this.

I'm planning on putting out 20 + units for static tests in the coming weeks so I'll get a better idea of whats happening but it seems to only effect this particular board so I haven't been too worried.