LoPy To MultiTech Conduit

[dchappel]

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

[cmsedore]

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

[dchappel]

@cmsedore Even after yesterday's firmware update LoPy still hanging after 7-8 successful sends. Have you had any luck ferreting out a bug?

[dchappel]

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?

[cmsedore]

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.

[cmsedore]

Ok, I know the problem and the fix. I'll try to polish it up and do a pull request.

[iannucci]

Thanks for finding this -- I just ran into the same bug with my new LoPys and my Multitech Conduit. Looking forward to your fix.

[cmsedore]

@iannucci I just created the pull request.

[johncaipa]

@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

[cmsedore]

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

[johncaipa]

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.

[livius]

https://github.com/pycom/pycom-micropython/pulls

[dchappel]

@johncaipa

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

[johncaipa]

@dchappel do you know if the error was already corrected in the new firmware (1.5.0.b2)?

[dchappel]

I don't know if this got fixed. Haven't gone back and checked.

[iannucci]

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

[iannucci]

@iannucci Just re-tried this and was able to compile, flash and boot. Initial test indicates the issue is resolved, but I will do some additional testing.

[iannucci]

@iannucci Sadly, the fix does not work for me. Benefit: does not seem to hang. Downside: the first seven packets get through (according to the Loriot dashboard). After that, nothing.

[cmsedore]

@iannucci I just was back in the office today and ran some tests--I couldn't create a scenario where it did not work as expected (all packets went through). Do you have source you could share? Does it behave better if you reconfigure all the channels as @dchappel suggested? (the code is in the post below)

[iannucci]

@cmsedore I just ran a test with @dchappel's code -- 4000+ messages and counting, no drops. Good news!