@hjoe I stopped. There is no reason to carry on until Pycom issues a major rework of the firmware and the PyLife app.

@Chandan-Verma can you clarify which example you are using, which region you are in, and where exactly the error happens (the full log/trace would be useful)?

@robert-hh Thank you

@d-alvrzx I strongly support this request. I see, that restoring some of the data may cause trouble, if restore is executed multiple time w/o a save in between. Like the packet counters. But that is less cumbersome than loosing all data. See also my notes here to retrieve individual elements: https://forum.pycom.io/topic/5922/an-alternative-to-nvram_save-restore-using-the-sd-card/6?

@Eric73 Oh wow, that makes sense... So it actually is transmitting at max power, as expected. That's good to know. Thanks so much for your insight! @catalin @Xykon would you be able to confirm this? If so I think it's important to change the documentation in https://docs.pycom.io/firmwareapi/pycom/network/lora/. Thanks!

@Widget Contrary to cellular networks, LoRaWAN networks usually don’t transmit much, if at all. Other than the odd join accept, confirmed frame ack, or downlink, all of which should be very rare, they don’t transmit anything, and definitely no beacons, advertisements or broadcasts. So it’s not possible to check if there’s a network around, just by listening, unless you plan to wait a very long time or get very lucky. But have you checked TTN’s coverage map? Also remember that radio waves don’t like obstacles. Find the closest active gateway(s) and check the path between them and you, taking into account terrain/elevation, buildings, vegetation, etc. There are tools that allow you to simulate all that. TTN being an open initiative, coverage varies widely. Some areas have lots of outdoor gateways in very good (high) locations, others may be the proverbial desert...

@berryskies My bad! Stupid error (as usual?). I misread the socket.SO_CONFIRMED option. I thought this was a constant boolean and didn't set the trailing 0 to 1 (slap to forehead). All working as expected.

@Eric73 Thanks for the info

@mfalkvidd Hi, tks for the reply. Ok, that explains the problems that I have.

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

Hi, I know this is not a gateway. I have been using other devices where I am able to send MAC layer commands. Your response fails to answer any of this. 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)

@River are you sure you’re not missing something in your code? When you wake up, you should restore LoRa settings, then check if the node thinks it has joined, and it not, try to join. If some any reason you don’t get to the LoRa save, the next restore will result in the device having lost the join state, and being unable to send anything...

@mk IIRC a reset will have the same effect as deep sleep, resetting LoRaWAN counters and other state. Unless you join every time you reset, you need to save and restore state.

Nevermind, I solved it. I'm new to real time programming and apparently had to find out the hard way not to put code that's too time consuming into an ISR. I changed it so that the ISR just changes a flag and that the actual work is being done in the main loop.

@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.