@fedesilvi Just to give you an impression how bad the esp32 ADC is, I collected 10000 samples with the ESP32 ADC and an ADS7818 ADC taking values the same LM385 voltage reference. The absolute values differ, because of the different ranges (5V vs. 3.3V). The histograms are below: [image: 1538763982782-data_a7818.jpg] [image: 1538764779096-data_esp32.jpg] Edit: Adding a 10 nF capacitor close to the ESP32 ADC input and switching off WiFi improved the picture. The one above was WITH the capacitor. Without, the capacitor, it was worse (avg +/-100 readings)

@vflorio94 this error can happen frequently, it happens when the url is available, but the board doesn't accept connections. Or when the board is starting, it might take a few seconds to be able to connect to it. You don't have another connection to the board, right? (And I assume you have tried hard resetting, disconnecting power then trying again)

@dan I finally made it work! But only because of your advice! Thank you so much!!!

@inverseeffect Did you ever get any resolution on the keepalive timer? I'm running into the same issue. For now I've switched to simple.py, but I would much rather use the AWS library.

@dr_aloui In that case it's strange. You you have an oscilloscope to look at the signal timing? The expansion board should not add any significant load to the wires, at least not to P9 and P10. The Pyboard has built-in pullup-resistors on the pins dedicated for I2C (X9/X10 and Y9/Y10). That could makes a difference.

Hi! You can use this command line tool: https://hackmd.io/s/HJhUcamxQ#

Ah ha. I was using the wrong interrupt script. This is the correct working code for an accelerometer interrupt (P13) of machine.deepsleep(): import machine machine.pin_deepsleep_wakeup(['P13'], machine.WAKEUP_ANY_HIGH, False) machine.deepsleep(10*1000) So for pin interrupts there is a callback() function to create interrupts of active and sleep modes but the pin_deepsleep_wakeup() is needed to interrupt deep sleep (is that what you meant by "wake-on-pin" @jcaron?). There is no interrupt handler for pin_deepsleep_wakeup() because the working memory is cleared after deep sleep (as mentioned by @jcaron below). @jcaron I had tested my interrupt handler without sleep and it did work. In my main.py I had the following script to test that it woke from deep sleep and ran main.py. import pycom import utime pycom.heartbeat(False) #turn off LED pycom.rgbled(0xFF0000) #red LED utime.sleep(2) pycom.heartbeat(False) #turn off LED

Any news about this wifi possibility ( WifiBeacon ) Cisco Meraki is using this technology for large deployment of iot sensors https://lnkd.in/gPCrjbN and http://beaconsgalaxy.com/beacon-et-wifi-ou-lavenir-des-espaces-connectes/ Jiemde

@dan Updating the firmware fixed the problem! Both main.py and boot.py run on restart. Thank you :)

@alexpul if you want low power it’s going to be one of the last two. On a WiPy 3 the recommended option is machine.deepsleep, though I haven’t checked whether it can be used with wake-on-accelerometer. You probably won’t be able to capture the acceleration at the actual time it is over 3g, though, it takes a little while for the WiPy to wake up...

@martinnn lib_imu is a library that I wrote and in this function give only data from IMU and there aren't any delay. if I wrote data immediately on a file.txt in SD card it employ 0,2 s so the sample became 0,4. but if I collect data and insert them in a list to save data at the end of acquisition it gives me the error 'Memory allocation'.

@gda45-78 Hi, don't you have loaded a back WLAN process on the board that consume too much ? (see your post 3 months ago in your profile). regards.

got similar error, my expansion board doesnt show as recognized

@robert-hh said in Wipy 2.0 and save data on my pc, not in flash memory: Which BN055 module I was asking about the vendor and make of the BNO055 board.

@ma If the data is is fixed, you can preallocate the bytes string like: data = b"\x01\x02\x03\x05" # and later spi.write(data) But that only saves some time before the writing starts. The writing speed itself will not be affected and is most likely slower than 40 MHz. The baud rate you specify is just an upper limit.