@hm97 said in Deep Sleep and Battery Consumption.: @rcolistete said in Deep Sleep and Battery Consumption.: ''There is a cycle delay in the sensor data sent, so 2nd LoRaWan package uses data sent in #1 cycle.'' can this explain why I am having a relatively high airtime? The first reading I sent to TTN gives me an airtime of about 103ms while all the following readings give me an airtime of ~413.7ms. So when you said the LoRaWAN package uses data sent in #1 cycle is that to say that it is sending more data in the subsequent readings and thus takes more airtime? What @rcolistete means is that if you use the method they gave, then there's always an offset of one sleep cycle between data collection and sending it: each time you send the data you collected during the previous cycle. This allows you to run data collection in parallel to the RX windows delays: when you send data over LoRaWAN, the device always waits at least 1 second, then listens for a downlink in RX1, then waits another second, then listens for a downlink in RX2. So that always takes at least 2 seconds (unless you receive a downlink in RX1). With the traditional get data-then-send method, your total awake time is time to boot + time to get data + time to send-and-wait-for-RX. With the parallel method, the total awake time is time to boot + max(time to get data, time to send-and-wait-for-RX). If time to get data is significant, as is the case for some sensors, this can save quite a bit of awake time on each cycle. The drawback is that you get the data one cycle later.

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

@Kcsss Read the documentation here more carefully. The case is important! from network import LoRa import socket import ubinascii import struct # Initialise LoRa in LORAWAN mode. # Please pick the region that matches where you are using the device: # Asia = LoRa.AS923 # Australia = LoRa.AU915 # Europe = LoRa.EU868 # United States = LoRa.US915 lora = LoRa(mode=LoRa.LORAWAN, region=LoRa.EU868)

@Eric73 Thanks for the info

@catalin Ok, I will try the licensing then. Thank you very much.

@Colateral said in Lopy4 433Mhz example: Does anybody have 433Mz lora initialization? I don't actually know any details about this, but just stumbled over [1] the other day. So, @robert-hh might be the right one to ask about this. Please also see [2], where you might find more appropriate details to go ahead on this. [1] https://packages.hiveeyes.org/hiveeyes/foss/pycom/robert-hh/LoPy4-1.20.0.rc13-eu433.tar.gz [2] https://github.com/pycom/pycom-micropython-sigfox/issues/345

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

@Bettina This topic has been silent for a month. It is 6 days to Sep 22nd now, and no activity. May I assume that the attempt is silently canceled?

@Eric73 Great, thanks for your help !

@melkoutch hope you still read this as this thread is quite old. I stumbled upon it having the exact same problem (LoPy4 <-> Feather M0 in raw LoRa). Adjusting the spreading factor doesn't seem to solve it for me. Would you be able to post the code fragment that you used to successfully connect the two? Thanks a lot!

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.

@robert-hh Thanks for that will take a look

Okay this has answered my question! Looking forward to test the border router functionality.

@asb said in Firmware Over The Air (LPWAN): Hi, Im curious about the following: Reading in the things networks forums, there is some interesting material about work regarding firmware updates using LoRa. Let's say for example the things network implements over the air updates via lora in their console. Could existing LoPy's (4) use this feature, or could a manual firmware update from pycom enable this feature or not possible? Thanks Best regards We have user's who have implemented there own firmware OTA using lora in the past. I dont think anything got released for public use however. Ill try and find out what our plans are Re: Lora OTA.

@snehasg96 main.py is executed automatically when the device boots. If ouy wnat to run a script, like recv.py, manually, just enter at the REPL prompt (the one with >>>): import recv

@iplooky Hi, I think I am looking for the same concept to. My case is to implement a Lora Nano-GTW and use a SIM808 to backhaul the data via GPRS. Is it the same case you have? I am actually a the planning stage. If you have advanced something, please share your ideas. I am thinking to do it with an arduino module. I am going to try to create a serial connection with it and also connect other arduino's pins with the SIM808 and create another serial Then I guess hard code programming should be necessary in order to create the flux of information between the pycom to an arduino's logical buffer and then to the SIM808 to be transmitted to some internet server through GPRS cell network. Please, destroy my idea with anything. Thanks to all.