Lora-net/packet_forwarder

AU915 beacon format

Closed this issue · 7 comments

I think the logic in lora_pkt_fwd.c:1980 for determining the beacon RFU field sizes may not work for the AU915 region. Regional params specs RFU1 = 3 bytes and RFU2 = 1 byte, but this logic will configure 5 and 3?

The datarate of beacon for AU915 is SF10, so the logic is correct.

Looks like the LoRaWAN spec has changed a bit for AU915. In the v1.0.2 regional parameters doc, it specs SF10 as you say. However in v1.0.3a it specs SF12, then in v1.1a back to SF10, and in latest v1.1b spec it is SF12 again.

ah ok. :)
Anyway, the RFU size is directly linked to the datarate, so it should be consistent

Unfortunately the specification did not change the RFU sizes for AU915 through any of the referenced versions.

Ah, so I need to check if it is a mistake in the specifications or in the code. :)

@hosse005 you are a genius!

You are right. I modifed lora_pkt_fwd.c:1980 with RFU1 = 3 bytes and RFU2 = 1 byte. And then the gateway send beacon (size 19 byte) as in the specification for AU915.

Thank you so much!!! :D

In an effort to improve our customer support experience and in recognition that our support backlog on GitHub has historically exceeded the capacity of our engineering team, we have taken the difficult decision to focus on the most contemporary issues reported and to close all others without confirmation of resolution.

Our belief is that issues which have remained unresolved and unaltered for extended periods of time are less likely to continue to pose a significant problem to the user than when they were originally filed. More contemporary issues however may still be relevant and hence are more appropriate to prioritize.

For those users who remain interested in resolution of a reported issue that was closed, we are encouraging usage of our developer portal forums [https://forum.lora-developers.semtech.com/] and commercial support portal [https://semtech.force.com/ldp/ldp_support] as the preferred avenues to receive support. We will continue to monitor the GitHub issue trackers as well, but want to encourage all users to take advantage of the increased community presence on the developer portal. For commercial customers, we highly recommend using the commercial support portal which is uniquely tailored to service such support requests.