Issues w/ Uplink Using SAM R34 and ABP

[dnakazawa-aps]

Hi cslorabox, thanks for your reply.

@cslorabox

Can you log the actual transmissions frequencies from the end device side? As a side effect that indicates that one has actually happened - which is unclear from your screenshot - it gives no hint of either the application payload or overall packet length, nor spreading factor, nor frame count - it might be showing the settings that would be used, rather than that a packet has actually been sent.

I’m not sure how I would go about doing this. I think I would have to take some time to do a deep dive into Microchip’s stack and change the example code around a bit to show this information in the terminal when the program runs. Unless you are referring to the end device Console, in which case one of my problems is that I cannot see anything in the end device Console.

@cslorabox

One concern is that it’s should be the second sub-band, so its #2 if counting from one but it’s #1 if counting from 0 as more typical in programming.

I suppose this could be an issue, but the example code starts out with the sub-band being defined as 1 rather than 2. If the sub-bands were 0-indexed, then I would imagine I wouldn’t have had to change this value to 2, though this didn’t do anything immediately noticeable either. Furthermore, another forum post on this topic corroborates this (Microchip SAMR34 Joining Denied - #32 by Afremont).

@cslorabox

In the LoRaWAN spec, OTAA nodes are supposed to randomly try to join across all legal sub-bands, so that’s a configuration issue that formally exists only with ABP and not with OTAA, though practically speaking a lot of people cheat the spec and rig their OTAA firmwares to only try the assumed sub-band.

It seems that OTAA should be the way to go whether for development or production. Is there a benefit to rigging firmware to only try that one sub-band?