@jcaron thanks for pointing to this informative thread! I've looked through the library code as well, very informative. In addition, I spent half a day reverse engineering the connections and looking up cryptic SMT markings for the undocumented parts on the board (TPS78233 LDO, BQ24040 Lipo charger, TT8J13 dual P channel FET). Thankfully I don't need the low power capabilities of this board (I need an active WiFi connection), I only need the sensors, so this simplifies things. Let's hope Pycom releases the secrecy around this board and published PIC source code and schematics.

Hi @stefan85e, You can find our example project for the Pysense on GitHub here. It has the main.py with the code and the libraries.

Thank you for your reply. Is there a simple example anywhere of sending data (temperature, humidity) to pybytes using the pysense shield?

hi @arthurjw, what do you mean by v1/v3? The hardware versions are 1.0 and 1.1(no difference). The latest firmware version is v0.0.8. The Pysense updating procedure did not changed: https://docs.pycom.io/chapter/pytrackpysense/installation/firmware.html On what OS are you updating, Windows/Linux/Mac?

@jazzyhawk Hey, try doing a safeboot. It should skip your boot.py and main.py code and allow you back in. https://docs.pycom.io/gettingstarted/programming/safeboot.html

@le_wildfox I'm not very familiar with NB-IoT, but from what I understand, it is quite specifically designed to not offer great throughput or latency, as the priority is low power. The peak rate is between 20 and 250 kbits/s, and latency is counted in seconds... Not sure exactly what you expect to get...

@tbuteau You should probably start by looking at the various inbound methods you can talk to carbon (the graphite daemon you will send data too). You should establish what is expected by your graphite cloud. I would imagine it is authenticated in some fashion. https://graphite.readthedocs.io/en/latest/feeding-carbon.html pickle or plain text would be the way to go, (I am not aware of AMQP libe for MicroPython)

Figured out the issue. Looks like the FiPy was consuming more current that my USB was able to deliver even though it was just running the sample PyMakr code of changing LED color. I connected a LiPo battery to it and didn't have an issue since. For those interested in figuring out how I got to this: I removed the FiPy module from the PySense Connected through USB to the computer and checked device manager for a new COM port If present, then PySense is fine. Without removing the USB to the PySense, I connected the FiPy and was able to program it. With the above basic steps you can determine if the board is actually bricked or just requires power.

@berkelium Our hardware designer has provided these step files http://software.pycom.io/downloads/PyShieldsExp3_step.zip I haven't been able to open them myself yet but maybe you have better luck? I'd appreciate any feedback before we put these into the docs.

@jcaron Thanks a lot for the explanation! That solved the question for me.

@akshayjames I think the problem is the button on the Pysense goes low when pressed, not high, so you want to wake up on low.

@jmarcelino Oh. Yes I was using machine.deepsleep(). Now it works. Thank you for your help.

Can everyone explain me how is pwr_en works? Can I wakeup the board over pwr_en and gnd from deepsleep? Can I force a reset over this pin? Pycom doc confuse me 😊

@Henning I had the same issue with the Expansionboard v3.1. The issue got solved, after using another Expansionboard v3.1 I've bought recentely..... I never used the SD-Card slot on the first one before, so I don't know, why it seems to be broken. Well, at least it works flawless with the second Expansionboard.