You may also look at the esp32 data sheet, page 28: http://www.espressif.com/sites/default/files/documentation/esp32_datasheet_en.pdf and other documents at that site: http://www.espressif.com/en/support/download/documents

Can you create a Fritzing board out of this model? E.g: [image: 1489961779947-sample.png]

@bucknall Is the documentation up to date? see https://forum.pycom.io/topic/888/lopy-super-twin-pack-not-working

@mkharibalaji Thanks for the explanation. Currently the Bluetooth stack only supports Bluetooth LE. You'd have to change your mobile app to use this instead. Bluetooth Classic is planned but I'm not sure when, it's not even on the low-level toolchain yet.

@bmarkus Yes.

I think so. I did not find any pin that could be hold low during deepsleep mode. @daniel can you show us some light here? Thanks a lot, Pablo

I never used tools other than ftp and telnet for WiPy and Lopy. Pymakr was unreliable from the first version on and never improved. When you use FileZilla of FireFtp as ftp client, you can set it up that a double click on the will will open it for editing in our favorite editor and saving stores it back to your device. You can also configure at least FireFTP for auto-conect. Obviously that causes some flash wearing, in contrast to PyMakr's method to keep files on your PC and load them on-the-fly. If you prefer that method, you can also try Dave Hyland's rshell (https://github.com/dhylands/rshell).

Ok.. Solved: from machine import I2C import time ADDR = 0x70 CMD = 0x51 configure the I2C bus i2c = I2C(0, I2C.MASTER, baudrate=250000) i2c.writeto(ADDR, bytes([CMD])) time.sleep(0.5) dist = i2c.readfrom(ADDR, 2) total = (dist[0]*255)+dist[1] print(total)

@Shaun I can enumerate at least 5 active people from this forum that required the frozen functionality.

@timeb look here - there is topic - but not solution.. https://forum.pycom.io/topic/829/mesh-network-on-wipy-2-0

@pascal probably you are connected to board by COM port from different program. You can not be connected to board bye e.g. pymark, putty. Updater tool must have exclusive access to com port (UART). Is this the case? also look here https://forum.pycom.io/topic/763/firmware-upgrade-troubleshooting-checklist-procedure

Hi @vervoortraf, you should not need to pass any arguments to the uart.readline() function. Just run uart.readline() and it should detect the '\n' in any of the messages sent to your LoPy via UART. https://docs.pycom.io/pycom_esp32/library/machine.UART.html#machine.uart.readline Let me know if this helps! Thanks, Alex

@Jan-Burkhardt said in Power saving with new machine.deepsleep functions !: machine.deepsleep([60000]) In documentation brackets [] show optional arguments you can run machine.deepsleep() or machine.deepsleep(60000) But remember that first is currently not wake up able We must wait for pin wakeup support And about 13 mA - it is already know by @daniel and he say that it is under investiagtion.

@robert-hh Thank you for the answer! I searched around the forum but its sometimes confusing when then documentation and forums are not synced because of the ever changing updates :) I'll keep an eye out the in the patch notes.

@bucknall Thanks. Purpose would be to (re)charge the 6600mAH batteries offsite, and replace an empty battery when needed. Any idea how long approximately (is it days, months) a 450mA/6600mA battery will last when only sending every 1 hour a LoRa message?

Hi @omer I've replied to your PM, sorry about the delay!

Hi Joshua, There's no way to do it in Pymakr (which is being discontinued anyway) but you can simply telnet into the your LoPy and get your print() results that way.

@jmarcelino said in Get the Location using LoPy: @beyonlo The NetID has several implications, for example it becomes part of the assigned device addresses (devaddr, not EUIs) which gateways can then filter on amongst other details. It's a complex subject, I recommend reading the LoRaWAN specification and the NetID allocation policy: https://www.scribd.com/document/317164891/20160603-NetID-Alloc-Policy-Application-1178-1 "3rd party" means if you're running a network that will accept devices from users outside your company and/or devices made by other companies (namely LoRaWAN Certified devices) If you're running a private network just for your application using your own devices then you shouldn't need your own NetID. Again owning a NetID shouldn't have anything to do with LoRa geolocation, I mentioned it because this sort of access usually only makes sense (economically) for very large deployments but I suggest that you contact Semtech sales and enquire about it (and let us know if you can!) Follow the link at the bottom at https://www.semtech.com/wireless-rf/lora-geolocation to obtain your contact. Thank you :)