@tve The original mesh announcement https://pycom.io/launching-mesh-networks/ said it was based on OpenThread https://openthread.io/ and includes links to the source on github. I'm in the process of setting up my own demo using a bunch of LoPy nodes. Andrew

My apologies for the late response and any confusion I might have caused by switching to integers within the post. The big/little-endian format was indeed the issue. Adding a '>' sign in both the micropython and the php script solved the problem. This is what I ended up doing. Micropython encoding # Pack data data = struct.pack('>5i', 25, 36, 81, 11) # Send data print('Sending data') lora.join(activation=LoRa.ABP, auth=(dev_addr, nwk_swkey, app_swkey)) s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) s.setsockopt(socket.SOL_LORA, socket.SO_DR, 5) s.setblocking(True) s.send(bytes(data)) s.setblocking(False) PHP decoding $struct = new Struct(); $decoded_payload = $struct->unpack('>5i', hex2bin($decrypted_payload)); $data = [ 'var1' => $decoded_payload[0]/10, 'var2' => $decoded_payload[1]/10, 'var3' => $decoded_payload[2]/10, 'var4' => $decoded_payload[3]/10, 'var5' => $decoded_payload[4]/10 ]; The PHP struct class I used in the PHP decoding script can be found here. Thanks a lot for your help!

@graham said in lora.join does not attempt every 15 seconds in background: while not lora.has_joined(): pass I would add something like sleep(1) into the loop, giving the background tasks more time.

@oligauc Can you tell what is wrong with this code then: from network import LoRa import socket import binascii import settings import sys import time import pycom LORA_FREQUENCY = 923000000 LORA_FREQ_ADD = 20000 LORA_GW_DR = "SF10BW125" LORA_NODE_DR = 2 # initialize 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.AS923, device_class=LoRa.CLASS_C) # create an OTA authentication params dev_eui = binascii.unhexlify('70b3d5499da97f9c') app_eui = binascii.unhexlify('ADA4DAE3AC12676B') app_key = binascii.unhexlify('11B0282A189B75B0B4D2D8C7FA38548B') # set the 3 default channels to the same frequency (must be before sending the OTAA join request) print('Adding channels') lora.add_channel(0, frequency=923200000, dr_min=0, dr_max=5) #join a network using OTAA print('Joining...') lora.join(activation=LoRa.OTAA, auth=(dev_eui, app_eui, app_key), timeout=0, dr=LORA_NODE_DR) #lora.join(activation=LoRa.OTAA, auth=(dev_eui, app_eui, app_key), timeout=0) # wait until the module has joined the network while not lora.has_joined(): time.sleep(2.5) print('Not joined yet...') print('Joined') # remove all the non-default channels print('Removing other channels') for i in range(1, 16): lora.remove_channel(i) # create a LoRa socket s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) # set the LoRaWAN data rate s.setsockopt(socket.SOL_LORA, socket.SO_DR, LORA_NODE_DR) #test set unconfirmed. s.setsockopt(socket.SOL_LORA, socket.SO_CONFIRMED, 0) # make the socket blocking s.setblocking(False) time.sleep(5.0) pkt = b'PKT #' + bytes([i]) print('Sending:', pkt) s.send(pkt) time.sleep(4) print('Listening...') while True: rx, port = s.recvfrom(256) if rx: print('Received: {}, on port: {}'.format(rx, port)) time.sleep(1)

hi @catalin, thank you very much! This answers my question. I would like to evaluate the mesh networking functions for a project at our university. The devices are energy constrained and expected to consume as little energy as possible. For this usecase I would like to use a Sleepy End Device or at least a Minimal End Device. I will use the CLI in combination with disabling the router role for a first evaluation.

hi @chadtfraser Thanks for you interest into Lora Mesh. Honestly, lately we were quite busy with the Pygo development, and I did not have time to prepare a release with updated Lora Mesh. As usual, all work will become open-source for our community, at some point. For now, you could simulate a Border Router by having an UDP port open on the designated BR (like a server), and send all Mesh traffic to this BR. Next, the BR would repack data for Wifi/Cellular/BLE. Sorry, for not respecting the targeted release date.

@shp96 That does not seem correct. Your gateway is only listening on channels 48 to 55 and 70... Can you show logs of packets received with the associated channel?

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