LoPy To MultiTech Conduit

[dchappel]

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.

[daniel]

@cmsedore Sorry for the delay in merging your code. I'm testing it now and everything looks solid. This will be on the next release. Thanks for your contribution!

Cheers,
Daniel

[iannucci]

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

[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]

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

[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]

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

[dchappel]

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

[johncaipa]

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

[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

[livius]

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

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

[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]

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

@iannucci I just created the 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]

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

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

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

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