LoPy To MultiTech Conduit
-
Has anyone had luck establishing a consistent flow of data between LoPy and MultiTech Conduit?
I can do an OTAA join with no problem. I have set up a simple routine to send a string every xxx seconds. However, there is usually a gap between payloads received of 1 to 6 attempts. Example output:

The "pressure" value should be continuous from 1 to 100.
I have experimented with time between sends (up to 5 minutes), socket data rates, etc. Nothing seems to change the situation. Like many others, I find the black box nature of the LoPy unit frustrating. The only other data that may be relevant is that I am accumulating CRC errors in the Conduit's LoRa history page:

Any suggestions out there from someone who might have found a way to get this to work consistently?
For what it's worth, here are the settings available to me on the Multitech side of the Lora connection:

Thanks in advance for any light the community may be able to shed on this.
-
If you could post your code, that would help, but I usually find that this kind of problem is because the lopy hasn't been narrowed to use the subband channels that your gateway is listening on, so basically, random distribution will get you about 1 in 8 messages going through. Based on your screenshots, you're using subband 1, so if you use this function:
def select_subband(lora, subband): if (type(subband) is int): if ((subband<1) or (subband>8)): raise ValueError("subband out of range (1-8)") else: raise TypeError("subband must be 1-8") for channel in range(0, 72): lora.remove_channel(channel) for channel in range((subband-1)*8, ((subband-1)*8)+8): lora.add_channel(channel, frequency=902300000+channel*200000, dr_min=0, dr_max=3, duty_cycle=0)and do a:
select_subband(lora,1)in your code (right after you create the lora object), it should be 100% reliable.
-Chris
-
Added your recommendation (which makes total sense!), but now getting this when I run:
Traceback (most recent call last): File "<stdin>", line 23, in <module> File "<stdin>", line 18, in select_subband TypeError: extra keyword arguments givenProbably something simple but it's been a long day...Here's my code:
from network import LoRa import socket import time import binascii import utime def select_subband(lora, subband): if (type(subband) is int): if ((subband<1) or (subband>8)): raise ValueError("subband out of range (1-8)") else: raise TypeError("subband must be 1-8") for channel in range(0, 72): lora.remove_channel(channel) for channel in range((subband-1)*8, ((subband-1)*8)+8): lora.add_channel(channel, frequency=902300000+channel*200000, dr_min=0, dr_max=3, duty_cycle=0) lora = LoRa(mode=LoRa.LORAWAN, adr=False, public=True, tx_retries=0) select_subband(lora,1) app_eui = binascii.unhexlify('00 00 00 00 00 00 00 00'.replace(' ','')) app_key = binascii.unhexlify('00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'.replace(' ','')) lora.join(activation=LoRa.OTAA, auth=(app_eui, app_key), timeout=0) while not lora.has_joined(): time.sleep(5) print('Not yet joined...') if(lora.has_joined()):print("Hell Yeah!") s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) s.setblocking(False) pressure = 1 while lora.has_joined(): #payload = str(pressure) payload = '{"pressure":'+str(pressure)+',"tst":"'+str(utime.time())+'"}' print(payload) time.sleep(5) s.send(payload) print('Joined...') pressure +=1 if pressure > 100: pressure = 1 -
@dchappel Sorry--apparently, duty_cycle isn't supported now. Try this version of the function--I just tried your code with this change and it seems to work..
def select_subband(lora, subband): if (type(subband) is int): if ((subband<1) or (subband>8)): raise ValueError("subband out of range (1-8)") else: raise TypeError("subband must be 1-8") for channel in range(0, 72): lora.remove_channel(channel) for channel in range((subband-1)*8, ((subband-1)*8)+8): lora.add_channel(channel, frequency=902300000+channel*200000, dr_min=0, dr_max=3) -
@cmsedore That got it...Thanks!
(EDIT) Or so I thought. Now LoPY hanging after a short while. Done with this for now...will pick up again when fresh. Appreciate the help.
-
@dchappel I found the same thing (hanging after a short while). I'm going to pull down the current firmware source and see if I can figure out what is happening. This was pretty stable in prior releases, so it may be a minor bug with the updated LoRa stack.
-
@cmsedore Even after yesterday's firmware update LoPy still hanging after 7-8 successful sends. Have you had any luck ferreting out a bug?
-
Update
I have come up with a workaround. The code as suggested is removing all channels and then adding back just the 8 in the sub-band. However, the LoPy locks after 7 or 8 sends. Got me thinking that it may be trying to use one of the removed channels.
I updated the code via brute force to put the the desired sub-band frequencies in each of the individual groups of 8 (ex. 0-7, 9-15, etc).
Works just fine now.
May just need to update so that system ignores removed channels?
-
Sorry for being slow to get back to this--other work intervened.
I figured out where it is hanging up, but not why just yet. Hope to run it down in the next few days.
-
Ok, I know the problem and the fix. I'll try to polish it up and do a pull request.
-
Thanks for finding this -- I just ran into the same bug with my new LoPys and my Multitech Conduit. Looking forward to your fix.
-
@iannucci I just created the pull request.
-
@cmsedore can you share your final code?, the last one has worked for me but it happens the same as everyone, it blocks after some successful submissions to TTN. Thanks in advance. I am using a AU915 Multitech gateway config
-
Hi @johncaipa, The pull request should be visible from the main repository if you'd like to patch the firmware source directly. (This can't be fixed via python code.)
-
Hi @cmsedore You give me to understand that it is a problem with the firmware? Hopefully the Pycom team will take it into account.
Sorry but I do not know where the repository is, you can share the link as soon as you can, sorry for the inconvenience. -
-
Until the firmware is updated, here is the workaround I came up with. Since the current firmware insists on using all the channels, this distributes the the desired sub-band frequencies among them all.
It's not pretty, but it works!
from network import LoRa import socket import time import binascii import utime def select_subband(lora, subband): if (type(subband) is int): if ((subband<1) or (subband>8)): raise ValueError("subband out of range (1-8)") else: raise TypeError("subband must be 1-8") for channel in range(0, 72): lora.remove_channel(channel) index = (subband-1)*8 for channel in range(0, 7): lora.add_channel(channel, frequency=902300000+index*200000, dr_min=0, dr_max=3) index+=1 index = (subband-1)*8 for channel in range(8, 15): lora.add_channel(channel, frequency=902300000+index*200000, dr_min=0, dr_max=3) index+=1 index = (subband-1)*8 for channel in range(16, 23): lora.add_channel(channel, frequency=902300000+index*200000, dr_min=0, dr_max=3) index+=1 index = (subband-1)*8 for channel in range(24, 31): lora.add_channel(channel, frequency=902300000+index*200000, dr_min=0, dr_max=3) index+=1 index = (subband-1)*8 for channel in range(32, 39): lora.add_channel(channel, frequency=902300000+index*200000, dr_min=0, dr_max=3) index+=1 index = (subband-1)*8 for channel in range(40, 47): lora.add_channel(channel, frequency=902300000+index*200000, dr_min=0, dr_max=3) index+=1 index = (subband-1)*8 for channel in range(48, 55): lora.add_channel(channel, frequency=902300000+index*200000, dr_min=0, dr_max=3) index+=1 index = (subband-1)*8 for channel in range(56, 63): lora.add_channel(channel, frequency=902300000+index*200000, dr_min=0, dr_max=3) index+=1 index = (subband-1)*8 for channel in range(64, 71): lora.add_channel(channel, frequency=902300000+index*200000, dr_min=0, dr_max=3) index+=1 lora = LoRa(mode=LoRa.LORAWAN, adr=False, public=True, tx_retries=0) sb = 2 #Change to desired conduit frequency sub-band select_subband(lora,sb) app_eui = binascii.unhexlify('00 00 00 00 00 00 00 00'.replace(' ','')) app_key = binascii.unhexlify('00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'.replace(' ','')) lora.join(activation=LoRa.OTAA, auth=(app_eui, app_key), timeout=0) while not lora.has_joined(): time.sleep(5) print('Not yet joined on frequency sub-band '+str(sb)+'...') if(lora.has_joined()):print("Successful join on frequency sub-band "+str(sb)+"!") s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) s.setblocking(False) s.setsockopt(socket.SOL_LORA, socket.SO_DR, 3) pressure = 1 while lora.has_joined(): payload = '{"pressure":'+str(pressure)+',"tst":'+str(utime.time())+'}' print(payload) s.send(payload) time.sleep(6) pressure +=1 if pressure > 100: pressure = 1 -
@dchappel do you know if the error was already corrected in the new firmware (1.5.0.b2)?
-
I don't know if this got fixed. Haven't gone back and checked.
-
@dchappel I built my own version of the firmware with this fix in it. But as this is the first time I've built ESP32 / LoPy firmware, I am having a small problem. The make process seems to work properly, and the flashing process seems to work. But when I remove the jumper wire and reboot the LoPy, it runs a different version of firmware, not the one I just flashed.
I've tried the safe boot tricks to no avail.
Any ideas how to get the LoPy to come up running the version of firmware just uploaded via make?
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login