Hello @braulio. I think the extra milliseconds are from Lopy info processing, you can try with a different number (10 seconds, 20, 30 etc) and the "extra" time is the same then you have a solution. Also you hsould try to make a new post, the topic is quite different from this one.

@jmarcelino Hi I was trying the code on Leo Gaggl's blog page . Cheers Sean

Dear @robert-hh , Thank you so much for your continue help! All your advice have been very useful for me. I hope this thread helps somebody else to save time. With best regards Sebastian Barillaro

@colateral It's in the development branch.

@kebson Thinking about your message, I assume that you connected the collector of the transistor to GND and control the relay though through the Vcc & GND pins of that relay board. Two topics are to be discussed: Current draw. According to the data sheet, the coil resistance is 70 Ohm, resulting in an current of 47 mA at 3.3V. At that load, the output voltage should be lower than 3.3 V, so it might "just" fit. At about 3V, the force at the relay contacts may be lower than at 5V, causing higher relay contact wear. Flyback voltage peaks. If you did not remove the flyback diode from the board, that might work, at least for a while. But still I would not consider to connect an inductive load directly to the ESP32 output pins. It may work for a while, but then break. B.T.W.: What is the mains voltage/power of the Pump?

@sealyons I made a test with the calibrated temperature mesurement device: Calibrated device: 21.7 21.8 DS18B20: 21.9 21.9 DHT22: 21.8 21.9 SI7021: 21.7 21.8 BMP085: 22.4 22.5 BME280: 21.8 21.9 Besides the BMP085, all devices were on the spot = within 1 digit variance. That status was stable for 5 hours testing. Only the BMP085 was always ~0.6 °C above, but still that at the limits of it's spec.

Thank you for the instantaneous reply. You are welcome :-) We will check on your issue ASAP. Cheers, Daniel

@kots As @jmarcelino said, just call lora.nvram_save() before going to deep sleep, and lora.nvram_restore() after initialising LoRa but before sending your message.

@jmarcelino It's possible to send peer-to-peer with two LoPy's. Pycom have supplied a tutorial on that in the documentation. The range I get between two LoPy's is about 400-500 meters in urban area, which is not particullary good though

@jmarcelino It works for me now! I had to enable NTP client using the command line in Windows. Before that, "rtc.synced()" was returning False. Thanks.

@mohpor There was no open issue on Github for this problem and to me changing a 2 to 3 didn't seem to warrant opening a PR so I simply brought it up on the forum, seemed to be most practical way of addressing this.

@Erica-Galindo Hi there, I can confirm we are fixing many of the issues and have been working with the web design company to make this a priority. We should have many fixes this week. Best wishes Fred

@bucknall said in Camera image over MQTT: Hi @robmarkcole This is definitely possible over WiFi as there are working examples written in C for the ESP32, however I'm yet to see this ported to MicroPython so it might be a while before you're able to do it specifically in MicroPython. Here's a link to the example I'm referencing written in C; https://github.com/igrr/esp32-cam-demo I see that project converts color pictures into ASCII art. Can anyone enumerate some other options for capturing color pictures and sending via network, LoRa or otherwise? I know of the Arducam, what else? Anything native to the ESP32 that can just connect one of the Onvif cameras (OV7670, OV2640) and send?

@jmarcelino that fixed it. I can now upload my own firmware. Your fix of increasing the stack and putting listining mode in PASSIVE doesn't help though :-(. I'll see if I can go deeper into the scanning part. thanks for all the help Rolf

@livius Hi livius, That's work!, now I need to understand how work the "format" of the "pack" function and specialy "little and big-endian. Best regards Jiemde

@alvaroav Dear all, Some advances by the end of the week. I have tried from a clean code, just building a new program. I come back to the option to open the socket, send all data in a loop, and at the end of the loop, close the socket. I am not so sure why, BUT now the ENOMEM error just appears from time to time. Moreover, I don't need any server (blocking or non-blocking) running. Moreover, I place this exception into the loop, and allow me to "reconnect" and continue the program even if an error appers. flag = 1 Nerrors = 0; socketUDP = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) while (flag<200): time.sleep(0.05) data=bytes() data = data + b'counter = ' + bytes(str(flag),'utf-8') try: sent = socketUDP.sendto(data, addr) print(data) led.toggle() flag=flag+1 except OSError: Nerrors+=1 print('error ', Nerrors) continue socketUDP.close() I am thinking that the problem might come from the wifi connection to the router... I will check this next week. BR

@borbonjuggler take also a look at this: https://forum.pycom.io/topic/3549/important-update-regarding-lte-modem-updates

@pkilcoyne Hello, my two cents about reading your topics, Basically if two lora module have same center Freq, same SF, same SYNCWORD (0x34 for lorawan and 0x12 for private lora), same coding rate, same IQ (IQ is inverted for lorawan and not inverted for private lora usally) and same HeaderSetup (implicit or explicit) the RX/TX work. I dont see where with lopy how we can set header mode, so i suppose it's always explicit ? In ERA-LORA it seem to be the same think (cannot set header mode so may be alway set a explicit?). They use "group ID" term instead of SYNCWORD, and they don't speak about IQ (so it's be supposed to be alway inverted ?) I suggest you to try inverting IQ in Lopy for RX and TX, set group ID to 12xx in era lora , be careful on how you select frequency on both module and try...may be it's change something. *I dont speak about header CRC mode setup it's a little bit fuzzy how it work.