@papasmurph Use the socket.bind( x ) where x is your desired port before doing the send

I've had success with the Cozair sensors from Gas Sensing Solutions. At the time I started looking at CO2 sensors a couple of years ago they were pretty much one of the few and the lowest cost sensor. Now there are others available using the same technologies. The sensor I have is now connected to a Lopy and Expansion board to provide regular readings via LoRa. Andrew

OK @Asb comment got me thinking that everyone seems to be fine with the lora.has_joined() method call. So I put a slight delay following the nvram_restore call, and it seems to work ok. 2 seconds seems to be optimal. This code seems to work most of the time. lora = LoRa(mode=LoRa.LORAWAN) lora.nvram_restore(): time.sleep(2) if not lora.has_joined(): print('failed to join via nvram_restore') lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.AU915, adr=False, tx_retries=0, device_class=LoRa.CLASS_A) for i in range(16, 65): #AU915 TTN gateways need channels removed lora.remove_channel(i) for i in range(66, 72): lora.remove_channel(i) appeui = binascii.unhexlify(app_eui) appkey = binascii.unhexlify(app_key) lora.join(activation=LoRa.OTAA, auth=(appeui, appkey), timeout=0) while not lora.has_joined(): print('trying to join OTAA') time.sleep(0.5) print('connected and ready to publish') s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) s.setsockopt(socket.SOL_LORA, socket.SO_DR, 5) s.setblocking(True) s.send("some data") s.setblocking(False) rev_data = s.recv(64) print('recieved data: ', rev_data) lora.nvram_save() time.sleep(2)

@Wolli01 This is not rebuildung everything, It's just two resistors and one capacitator. Pretty simply.

@robert-hh Thank You!

@Wolli01 These batteries are only good for medium to low power consumption. They are rated at ~1500 mAh, but only at 100Ohm load = 30mA. My first impression is, that these batteries are too weak. Anyhow, Better go for batteries with a higher voltage like this one: https://www.conrad.de/de/p/saft-ls-14500-spezial-batterie-mignon-aa-lithium-3-6-v-2600-mah-1-st-651153.html, or use three AA sized cells with 1.5 V each. If you scan through the forum you'll find a lot of discussion about power consumption and power budget. The power consumption of the ESP32 is pretty high by itself, and the WiPy need comparable long to start, consuming high power during that period. Other Pycom devices need more power and longer start-up time. The baseline Arduino UNO with its 8 bit Atmel processor at 8 MHz takes ~5 mA at full speed, compared to ~30mA for the ES32 w/o WiFi and up to 250mA peak/100mAaverage with wifi, @160 MHz clock speed.

Gern geschehen. Grüße aus Dänemark

Doesn't anybody have such a sensor running and could help me get mine to run?

@Martinnn said in Please help me! Micro USB card to my Lopy and Wipy: The adafruit board you referred to is simply a breakout board for a micro USB connector. The ESP32 does not have USB hardware, so there's nothing to connect it to... If you want to connect to (the serial port of) the Wipy via USB, you need a USB to serial converter. Easiest is to buy an interface board like the expansion board. Thank you

Indeed we have the "socket.accept ()" method in the first LoPy, but the problem was in the pointing address to the other LoPy which was wrong. It's already solved, thank you!

@Wolli01 Both SX1272 and SX1276 oprate at a range of 1.8 to 3.7 V, the esp32 at a range of 2.6 to 2.6 V. So 3.33V should not be a problem. The voltage should however be taken at the 3.3 V output of the LoPy, to be sure, that the supply arrives. But there may be short supply drops during send bursts. If you have an oscilloscope available, try to trigger for voltage drop sat the 3.3V output. The current demand for WiFI is higher than that for Lora, 250mA worst case for the ESP32 vs. 120mA worst case for the SX127x, but I doubt that these high power output modes for Lora are supported. So yes, worst case can be in the range of 500mA. Given your power consumption, battery impedance, especially at low voltage, may more be an issue than total capacity.

@robert-hh Thanks for the info. Always rescued it via software. Will test it with machine Deepsleep

Depends. 2k on a LoPy is a lot of memory. If it occurs during compilation time, precompiling your code with mpy_cross is the solution. Otherwise it is not that easy. You have to reduce memory fragmentation. You can see the fragmentation with micropython.mem_info() Precompile as many files as you can. So the memory of the LoPy is not fragmented after boot time. Allocate huge buffers as early as you can. Reuse them instead of reallocate. You can try to call the garbage collector in front of your memory allocation. But this does not help in many situations. The garbage collector does not relocated objects in use, so the memory is still fragmented. If there is a background thread, it may fill your memory faster than you can free it. For example if it calculate float objects in a loop.

@HenroRitchie Thank You

@robert-hh Okay, thanks for your help.

@eric73 Thank you for your answer, I think it replies my question: It is possible however it depends on the network server allowed behavior.

I have the same opinion as @jcaron . MTU size is something that has to be configurable. We should be able to set MTU size of Pycom. Changing is not going to break anything in case of good implementation (I've already tried it with Pycom). @Emmanuel-Florent the reason I've started this topic is that I've experience with ESP32-DevKitC and BLE MTU size changing, on that size everything worked fine, so I'm just requesting the same functionality on Pycom if possible.

Thank You

@robert-hh No, I was relying solely on pybytes Web interface.

import time time.sleep(2) import pycom pycom.heartbeat(False) print('main MAC1') print('LED test') print (0xffffff) pycom.rgbled(0x0) Try this code. This should run perfectly fine.