SiPy Doesnt power up on LiPo battery

  • Hi
    I have just upgraded a number of my SiPys to the latest firmware. Since I have done this I am not able to power up the devices from a LiPo battery charged to 4.1V. I have them connected via a deepsleep sheild, and have the batterys connected to GND and Vin pin of the DeepSleep. I am getting 4.1V on these pins on the SiPy. Previous versions of the FW will allow it to power up without any issues. I am using version 1.0.5 of the Deepsleep API. I have also powered the device from a DC power supply to these same pins, but it wont power up until after about 5V when doing this!

    Im really confused and need to get this sorted asap so if anyone can help it would be appreciated. I need the latest firmware as earlier firmwares will not allow me to send the Sigfox signal.


  • @bradnz I had your same problem. With the new release I solved

  • @daniel This is great news. Thanks. I thought I was going crazy :)

  • @bradnz this Sigfox issue appeared after bringing dual core support. We have identified the problem and we’ll fix it on the next release in a few days.

  • Ok, now I have a real problem. This is stalling moving forward with my project. Hopefully someone can help.

    I have upgraded my Sipys to 1.14...the latest release. I have to do so in order to get the devices PAC etc as part of the build process. I tried to send data - the device hangs during the delivery of the data. The data gets sent, but the device doesnt "continue" with its functions. Only a restart will get it working again - I should note that this is not an issue with my software as this has worked on previous versionsof the firmware in the past - I have a few in the field as pilots that are working on release 1.9.2 perfectly fine. However with the latest release it will freeze during delivery to Sigfox (or at least after the delivery) every second or third time it sends data. So when this does successfully send data, and comes out of deepsleep to do it again, it will hang the next time it sends it, or the time after. Its random. It is sending it, as the data arrives at Sigfox, its like it never quite finishes the process (like its waiting for an ACK or something from Sigfox). I cant put my product in the field with it like this. I have tried to downgrade to 1.9.2 (which has worked in the past), but the signal is not even sent with this release now for some reason, and the same goes for release 1.10.

    Its not SiPy specific as I have tried to do exactly the same thing on about 3 of the devices, and its the exact same result. I believe this firmware release has a bug for the SiPy.

    If there is anything you need me to do in order to help resolve / troubleshoot, Im happy to. I just need to know what.


  • @daniel I dont appear to have experienced the power problem as described again. This did happen for a long time, then all of a sudden it stopped (this was with the deepsleep attached as well). The issues Im having now are:

    1. Update the firmware using the new tool.
    2. Try to send a signal using Sigfox.
    3. The data does get sent, however at the end of the delivery its almost like the SiPy hangs. There is no further action. This is intermittent on the device, however with a power cycle, this clears the issue. It hangs on the first delivery on about every second or third restart!

    Any earlier firmware now doesnt even allow the SiPy to deliver the data - i.e. it doesnt arrive at Sigfox backend.

  • @daniel Thanks for your reply. Im having a lot of issues with these devices that I just simply cant get on top of. This is just one of them. I'll collate them altogether once I have got to the bottom of this and send them through.

    Is there avaliable a schematic of the expansion boards (2.0) available anywhere out of interest?

  • @bradnz there's nothing in the firmware that I can think of that could make the SiPy not boot-up. When you measure 4.1V on the SiPy VIN pin, is that with the deepsleep shield connected as well?

    Is the SiPy powering up if you remove the deepsleep shield?

    What was the previous firmware that worked for you?


Log in to reply

Pycom on Twitter