@lukesaber To compute your power requirements, if you are running a "wake up, send data, go back to sleep" pattern: define T as the duration in seconds of reference period of your choice (1 hour = 3600, 1 day = 86400...) define N as the number of times your device will wake up in that period define D as how long your device will we awake each time it wakes up (in seconds) define IA as the power consumption when awake (in mA, but you can use any unit as long as it's the same for IS and the result) define IS as the power consumption when sleeping (ditto) Then the average power consumption is: (N * D * IA + (T - N * D) * IS) / T Example: T = 3600 (1 hour) N = 3 (wakes up 3 times an hour) D = 10 (stays awake for 10 seconds) IA = 100 mA (average power consumption while awake) IS = 0.010 mA (10 µA, average power consumption while sleeping) Then the average power consumption is: (3 * 10 * 100 + (3600 - 3 * 10) * 0.010) / 3600 = 0.84325 mA If you want to have enough power for 2 days, then you need a battery with a 40 mAh capacity (0.84325 * 24 * 2). I think nearly any battery will do. Now, the exact figures for D, IA and IS can vary a lot, based on: what sensors/peripherals you may have that you need to power, and whether you power them all the time or only when you are awake what you need to do while awake how you send (LoRa, SigFox, LTE, Wi-Fi, BLE...), at what power level, at what data rate how long it takes for handshakes, ACKs, receive windows, etc. and probably a lot more things. Ignoring any sensors or other peripherals, while awake, the power consumption is usually somewhere between 50 mA (module active, not sending or receiving) and 200 mA (when sending). How long you stay awake will usually range between 3 and 10 seconds. Power consumption during deep sleep should be somewhere between 10 and 20 µA depending on the exact setup. So with 3 wake-ups per hour, for 2 days of battery life, your worst case scenario, not counting any sensors or peripherals, (200 mA when active, 10 seconds active, 20 µA in deep sleep) is about 80 mAh. You need to add the requirements for your sensors/peripherals on top of that. If you don't go to deep sleep for whatever reason, then the figures are drastically different, but you can keep the same logic. Just replace IS with the power consumption while idling.

@bmarkus If you exceed duty cycle limitations in your region, it's mainly illegal...

hi @jdcrunchman, we open-sourced the openthread (small) port to Lora (still not 100% features suported). More interesting, you can already use all mesh commands from https://github.com/openthread/openthread/blob/master/src/cli/README.md So, you can start already with UDP sockets. I take this opportunity, to invite Mesh enthusiastics (firmware and networking engineers) to even join Pycom (some formal JD will follow), as we have good plans to open Mesh to masses. <later edit>: If interested, just drop me an email on support@pycom.io

@iotgeek Some time ago Pycom team said that is FCC rated as 2.2 dB. Also that is unclear that this same level is consistent in all antennas.

@burgeh It depends a lot, but generally (and specifically in your case), no. Listening for LoRa packets consumes power. The LoRa chip on the LoPy 4 (SX1276) uses 10 mA when listening, and the rest of the LoPy uses about 50 mA average. You could probably reduce the ESP32 power draw with some more or less advanced uses of sleep (i.e. not out of the box), but we're still talking tens of mA, compared to about 10-20 µA in deep sleep. This means that if you are listening all the time, even a relatively large 2500 mAh battery will only last a few days. This may or may not be a problem for you depending on the use case (mains powered, enormous battery, solar powered, ability to recharge/change battery often...), but this is usually not the kind of use case for LoRa, and from your question "more efficient power wise", it's clearly not what you are looking for. So it usually remains more power efficient to deep sleep, wake up on whatever event (time, pin change...), send the frame, check for an ACK, retry if no ACK was received, and go back to deep sleep. Note also that there are many other reasons than just another one of your nodes sending data that could trigger a frame being lost. The frequency bands are shared, so there will be other devices using them, and you will end up with collisions and other forms of noise even if you control when all of your devices send.

Hi @grideagle, Thank you for reporting that, I've reported it to GitBook. The current workaround is to use the "copy" button it the top right corner of the code section.

@robert-hh said in TTN EU inconsistent to LoRAWan Spec: I just stumbled over an inconsistency between TTN EU and the LoRa WAN specification. For Downlink messages with DR < 4 TTN uses the RX2 window with DR=3 (SF9BW125) at 869,525 MHz and a power level of 27. This does deviate from the LoRa Spec in two aspects: a) I would expect that for a downlink message at first the RX1 window ist used, with the data rate and frequency matching the Uplink message. b) If the RX2 windows is used, DR0 = SF12BW125 should be used. That is what the PyCom devices expect for the RX2 window. The Pycom devices seem to implement the LoRAWAN spec. As a consequence, downlink messages for low data rates are lost. @bmarkus : How is the behavior in the loriot network? @robert-hh LORIOT EU868 settings are compliant to the LoRaWAN Regional Specification, see channel plan:

@sympatron Probably, we'll release a stable version at the end of this week, not completely sure. Also, as these Mesh features (Border Router) are in progress, not sure when to commit that I'll finish. Anyway, I will look into a micropython solution first, maybe some minor C code changes (released as development).

@robert-hh So a remote raw lora receiver with a lot of nodes sending it is just inevitable that collisions happen? My current "solution" is to send and wait for it to send back an acknowledge, if not just wait a random period of time.

Hello everyone, a question regarding this issue, I would like to know if someone has tried to connect a Lopy with raw Lora to a Multitech Conduit gateway as it comes from the factory or would they not be compatible?

Hi @james-matthews, Maybe a LoRa mesh network? (Note: it's still in development) What type of devices do you have?

@burgeh It is definitely possible, if you use raw LoRa mode. The simple expamples from the docs would serve for LoPy. I do not know how you want to drive the RN2903.