@w0run said in Setting up picture: I read somewhere that because the device does not have a built-in USB peripheral, like the original Pyboard does, that updating via USB was not possible. The ESP32 chip has a built-in ROM bootloader that allows (among other things) to write to the external SPI flash via UART/serial. You could flash it using a serial cable/RS232 <-> uart converter instead of USB. You could also flash the ESP32 using another micro-controller, though you'd have to program the protocol yourself first. This ROM bootloader is automatically trigger at reset if GPIO0 / P2 / G23 is pulled low (connected to GND) during hardware reset. You mention a bug- does that mean I have flashed a bad bootloader into my devices? The bootloader that was shipped has a bug, the latest update via serial port fixes this bug. This bootloader can only be updated via serial connection. It would also be nice to be able to trigger the device into its various update modes by a command over the wifi or the serial port. I don't think the ROM bootloader can be triggered during normal operation.

That's where you find release notes :) Thank you - then I can focus on the parts that work until next update!

@abilio Succes!! Adding machine.reset_cause() != machine.SOFT_RESET: did the trick. Pymakr is now able to connect to the LoPy on its STA address. Thanks for the great support!

@jrk Thanks for your prompt reply. Based on how you fixed it, I suspect #2 is the cause. Most probably a PATH order issue. For now, installing PyQt (and pyserial) on the "system's" Python as you did will make it run. I already filled the bug report, and will be included for a future release. Thanks a lot for your detailed post on how you solved it. Regards, Abilio

@kersing The RPM version is built using a translator tool from the DEB file. Thanks for your detailed feedback, it will be taken into account for the next release.

@peter Thanks for your detailed report, we had heard about it before, but there was no description on how to reproduce the issue. We'll add this to our list of bugfixes for the next release.

@peter Thanks a lot for your detailed bug report. We will try to reproduce it, and fix it for the next release.

That works fine with DSN address set to '0.0.0.0' thank you @daniel

Looks like an LFSR clocked by the calls themselves, something like n=n>>1 ^ (0xe10000 if n&1 else 0). It might have been seeded with 1. These things are half decent for unimportant things if you extract a single bit (not the entire state) and they're scrambled, but we'd like to have a true hardware RNG too (the ESP32 should have it).

At this moment you cannot change default directory. Thanks for the great idea we add this feature to the wishlist for future releases.

Hi @jonirons, Thanks for the question. The power figures for the WiPy2 and SiPy are similar, but the exact figures for it still have to be tested. The start and stop time of WiFi is also not exactly known, but it will be measured in milliseconds. Once they are available, we'll update the documentation.

We've found umqtt.simple to work fine without SSL, but if you want to use MQTTS on the WiPy, then a small modification is needed, as you can find here: https://github.com/Enabling/WiPy-LoPy/tree/master/SensorLib/mqtt

@abilio That has done the trick - Thanks! Now I await the delivery of my wipy2 - Are there any best practice guidelines for cross development - e.g. shared code runs on laptop and wipy using pymakr?

Hello, Yes, it is possible to add a GPS receiver. Simply connect to any 2 pins (the ESP32 on the LoPy allows remapping any GPIO to any peripheral) and configure the UART to have the correct baud rate. Cheers, Daniel