search

gotthardp / lorawan-server

Compact server for private LoRaWAN networks
https://gotthardp.github.io/lorawan-server
MIT License
956 stars 329 forks source link

Can't make multicast work #136

Closed julien78910 closed 7 years ago

julien78910 commented 7 years ago

Hello,

I wanted to try multicast but I didn't succeed to make it work. I tried to send this: {"data":"4546","port":2,"time":"immediately"} through mqtt topic, the lorawan-server detect it and send the data to the Gateway but the Gateway can't send the message because of missing field. Indeed, When I checked the log, I saw that the coding rate is set to 0 in the data sent to the Gateway when I set 4/5 in the server. Moreover, I don't know if it is a bug or done on purpose but I can't use the 869.525 MHz frequency with the channel field. Currently, the frequencies we can use with the lorawan server for europe are: Channel / frequency 0 -> 868.1 1 -> 868.3 2 -> 868.5 3 -> 867.7 4 -> 867.9 5 -> 868.1 6 -> 868.3 7 -> 868.5 8 -> 868.8

Thanks, Julien.

gotthardp commented 7 years ago

Hello. I am confused now.

julien78910 commented 7 years ago
  1. It is the coding rate field that is missing in the packet forwarder. I set the coding rate value to 4/5 in the lorawan-server multicast setting but the packet forwarder receive 0.
  2. Today i can't because I left work but I could tomorrow if you need.
  3. In the multicast settings, there is a channel field that is mandatory. The valid value for EU are between 0 and 8 and allow to choose a frequency. https://github.com/gotthardp/lorawan-server/blob/master/doc/Infrastructure.md
gotthardp commented 7 years ago
  1. Oh, there was a stupid typo, which I fixed. (Sorry for that. As you can see, it was never tested.) The latest master shall include correct coding.
  2. This is no longer needed as the bug was found.
  3. Well, the EU channels are based on a table I got from Semtech that shows what you listed and doesn't include 869.525 MHz. Since the channel numbers are not really fixed they should be probably made configurable.
julien78910 commented 7 years ago

Thank you for the fix and your time. I am happy to be helpful :)

I didn't see the table from Semtech but it is weird that the channels 0, 1, 2 are the same as the 5, 6 and 7. Moreover, it is also weird that the Rx2 default frequency (869.525) is not availbale. Without this frequency, how my devices are supposed to receive the messages ? I would have to change the Rx2 frequency of my devices to one from those I listed but then, I should be able to choose the frequency for unicast message on class C on the server to match the new Rx2 frequency. From what I know, there is indeed 3 mandatory channels that must be implemented on the end device (868.1, 868.3 and 868.5) and the 5 others can be freely attributed (section 2.1.2 of the LoRaWan Regional specification) but surely, you have more informations than me.

gotthardp commented 7 years ago

I wonder why I made all this configuration, because you are right. Multicast should be delivered on Rx2 so we probably dont need any channel setting, right? Rx2 is fixed.

julien78910 commented 7 years ago

Yes I also think that multicast should be on Rx2. However, your channel settings can be useful if someone want to change the Rx2 frequency which seems to be allowed by the LoRaWan specifications (3.3.2) but for now, it is not a big deal if it is fixed.

gotthardp commented 7 years ago

I made another update to make the RF parameters fixed. Please try if you want.

julien78910 commented 7 years ago

I tested the update and it seems to work fine, the mutlicast message is succesfully received and sent by the Gateway (I still have a problem but it is on my LoRa module and not related to this project). Thank you for the quick fix