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

It is indeed mentioned in this post. So I'll be able to get rid of the expansion board but not the deep sleep shield for it to be fully efficient That's exactly what I was thinking but I wanted to be sure about especially about the current since it worked but I was sure there will still be current consumption problems without the shield. Thank you for your fast reply, this will reduce the size of my project.

I just made a mistake with the pins, the one I needed to not change were G12, G13 and G14 and not like mentionned above. I'm still interested if I could use those Pins for input and then somehow deinit so that the communication still works.

@marto Hi thanks for pointing that you, you are correct the updater tool only shows instructions for the expansion board at the moment. I have passed this on and it should hopefully be changed soon. I will now remove the text about carefully reading the updater instructions because that clearly caused confusion. I will also pass on your OS details so make sure it gets investigated at the same time as the Mac OS issues.

@jerryhjones The latest version for MacOS is 1.1.2.b1... can you please check that you have the latest version? Also can you please provide more details as to how you apply power to the board? What kind of TTL adapter are you using?

@bradnz Exactly which version of deepsleep.py did you use? There are many commits which mention version 1.0.0 for this file. I am trying your solution, but it's not working for me on LoPy.

@aptusmarvin I have upvoted your messages, then you can now post without delay and i suppose also include images directly to the forum

@misterlisty Micropython uses the prefix u for its modules to indicate, that it may be a subset of what you have in CPython. For compatibility, the names without u are also provided. So, the genric name in MicroiPyhton is uos.uname, while os.uname is also possible. Likewise, you can write import uos or import os There are some deviations from that simple rule. Like in CPython, you can use _io, whereas in Micropython it's called uio (not u_io), and _io is not known. Also, why some modules have a non-u alias and others not is unclear. You could change that easily in mpconfigport.h of the respective port.

Further to this, I have found even more weird. I simply cannot get this Pycom SiPy device with a deepsleep module attached to wake every 30mins. Its so random. @crumble if I needed to fix the floating pins issue, what resistor size would you suggest, and would this be pull up or pulldown? Also what commands in the SW would I need to ensure that P17/P18 doesnt wake the module from deepsleep if I do this? (Assuming of course that these are the only two pins I need to control - P10 is used to communicate with the deepsleep module, but I dont think this needs a pullup / pulldown on my board?) Any help would be appreciated. Cheers.

@meirssv I've managed to construct a GPS tracker with a SiPy module. But I've use this gps lib ( https://forum.pycom.io/post/16183 ) from neuromistyx. Works great. because L76 is slow I've added a timeout of 3 minutes.

Hi @seb Thanks that clears things up a lot! I didn't know I could list the methods in each module either, useful to know... That would be fantastic if you could add this sort of extra detail in the documentation, I'm sure that will save me a lot of time! Thanks again.

@aptusmarvin this was 7 months ago - did you tried it now with current firmware? to check firmware on you board run os.uname()

Hi @livius, yes mailbox! here is the text in the documentation of the CCS811 chip: Programming Model: For flexibility and software driver maintenance simplification the CCS811 does not support direct addressing of registers over the I2C bus. Instead it supports single byte mailboxes identifiers that behave as proxies for registers with specific functionality and data sizes. To access a register an I2C transaction must be issued with the target address on the CCS811 being equal to the intended mailbox, this by way of proxy opens access to the register's functionality. In this manner the programming model is rigidy fixed while allowing the underlying firmware to be inherently flexible, extensible and configurable. That's chinese for me! Jiemde

Hi Miguel, The Spot'it service is available for all Sigfox development kits including the SiPy

giving up for now and hoping for the FiPy

Hello, Thank you for pointing that out. I changed the pins to G30 (sleep) and G13 (wakeup) and now the system works fine. So, the new code is: from machine import Pin, Timer from deepsleep import DeepSleep import deepsleep def handler(button): ds.enable_pullups('G31') # can also do ds.enable_pullups(['P17', 'P18']) ds.enable_wake_on_fall('G31') # can also do ds.enable_wake_on_fall(['P17', 'P18']) print("Button pushed") ds.go_to_sleep(20) ds = DeepSleep() # get the wake reason and the value of the pins during wake up wake_s = ds.get_wake_status() print(wake_s) if wake_s['wake'] == deepsleep.PIN_WAKE: print("Pin wake up") elif wake_s['wake'] == deepsleep.TIMER_WAKE: print("Timer wake up") else: # deepsleep.POWER_ON_WAKE: print("Power ON reset") button=Pin("G30",Pin.IN, pull=Pin.PULL_UP) irq=button.callback(trigger=button.IRQ_FALLING, handler=handler) print('booted---')

Ok, thanks for this - didnt see that one. And what are your thoughts on making sure i can resume the deepsleep. For thi, I really need to be able to send the data every 30mins. If its getting restarted because of a deepsleep wake, how do I know how far into the deepsleep the device was so that I dont get a wake 29mins into the deepsleep, and then go to sleep again for another 30mins once the wake is processed? I hope this makes sense. Its almost like I need to write the remaining time to a variable, save the variable in NVRAM, and then call that once the device has been reset. What do you think?

Thanks for the reminder @iotmaker, with the new Sigfox signal analyser this should be much easier to debug.

This issue is now resolved. Thanks! https://github.com/pycom/pycom-micropython-sigfox/issues/77#issuecomment-334796725