FiPy LoRaWAN OTAA join freezing after subband selection

[nemik]

Hello everyone,

So first off here is my example code: https://gist.github.com/nemik/c8be84ef2fa8c3f89c4a2a49f2643d8d

When I run my firmware and don't use a sub-band selection, I can eventually join my MultiTech Conduit gateway but it takes a long time and doesn't always work. Then when it does, I only get maybe 1 in 20 packets.

So I figured the problem is that the LoRa part of PyCom is transmitting on all channels and not a sub-band like the Conduit is listening on. So I added that selection function that's found in many forum posts but after I do it, the firmware freezes up when doing an activation join.

I never get to line 47 after the join.

Is anyone else running into this or am I doing something wrong? With how many gateways and systems use sub-bands, I'm surprised it's not part of the PyCom LoRa library.

Thank you for any suggestions.

[bed]

I have raised a ticket for the issue of allowing dr_min > 0 for channels 64-71, tested the fix and added a pull request.
Hope that it helps (it is working for me!).

Regards,
Brian

[bed]

Hi @jmarcelino

Thanks for this fix -- I've just been looking at the code in this area because of a problem that I've had with the new 'region-aware' firmware not working when I've removed the channels and added them back for AU915. Basically the code will 'freeze' after the send. The changes in the commit you mentioned showed me the reason why!

But, from the code in the commit that you mentioned, I don't think that the last channel that you added - 63+subband, will be added. The code in the commit will rule out any channel where the dr_min is not 0.

I'm thinking that the freezing that I have been seeing is from LoRaMac.c::ScheduleTx() which has a while loop looking for a valid channel supporting the requested data rate. With no valid channels because of the bug fixed in your commit, ScheduleTx() will never terminate. With your commit, the channels should be added correctly again. Though I will have to make sure that channel 65 for me, has dr_min=0, instead of dr_min=4, because of the requirement for dr_min=0.

Looking forward to the next release!

Thanks,
Brian

[jmarcelino]

@robert-hh
Thanks, should have been subband to match the rest of the code

[robert-hh]

@jmarcelino In your example, last line, sb seems not to be defined.

[jmarcelino]

Hi @nemik

We found the problem, it was a bug in adding channels which is fixed in this patch, this will come included on the next firmware release: https://github.com/pycom/pycom-micropython-sigfox/commit/ae3a294c40026433dbdac3e08da788b2b4c4dfdb

I also recommend that you add the missing DR4 channel so your subchannel selection code should be (extra line of code at the end):

Thank you for your report and sorry for the inconvenience caused.

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)

  lora.add_channel(63+subband, frequency=903000000+((subband-1)*1600000), dr_min=4, dr_max=4)

[jmarcelino]

@robert-hh
Thanks Robert didn't know what I was thinking :) It wasn't a viable solution.
I'll check in this properly later today.

[robert-hh]

@jmarcelino said in FiPy LoRaWAN OTAA join freezing after subband selection:

for channel in range(0, 64):
lora.remove_channel(channel)

Please? (just changing 72 to 64)

What?

[jmarcelino]

This post is deleted!