RAK 811 firmware problem



  • I have 2 problems with the functionality of the RAK811 module.

    1. When activated in the OTAA mode, it occurs at the maximum speed -
       SF7. This does not meet the specification. it`s a minor bug
    2. When the ADR is enabled, the module stops receiving data from the gateway.
      If you look at the details of the data exchange, you see that after sending from server MAC_LINKADR_REQ, the module correctly notifies about the change (MAC_LINKADR_ANS), and the next sending does at this speed, but stops receiving data. Perhaps the problem is that it continues to receive data at the old speed, which does not give receive server data, and continue to change the speed as the module does not receive MAC_LINKADR_ANS


  • Here is a listing ( bottom to top,
    Date Type Data DR Fcnt Freq gatewayId macData Packet Status Port RSSI SNR)

    06.03.2018 15:32:50 UNCONF_UP fe740023 SF11 BW125 4/5 22 868100000 b827ebffff7f93d3 1 -67 10.8
    06.03.2018 15:32:21 UNCONF_DOWN 2420696e7420323535203330 SF11 BW125 4/5 5 867900000 B827EBFFFF7F93D3 SUCCESS 221
    06.03.2018 15:32:20 UNCONF_UP fe740023 SF11 BW125 4/5 21 867900000 b827ebffff7f93d3 1 -68 11.5
    06.03.2018 15:31:51 UNCONF_DOWN 2420696e7420323535203330 SF11 BW125 4/5 4 868500000 B827EBFFFF7F93D3 SUCCESS 221
    06.03.2018 15:31:50 UNCONF_UP fe740023 SF11 BW125 4/5 20 868500000 b827ebffff7f93d3 1 -71 8.5
    06.03.2018 15:31:27 UNCONF_UP 000001 SF11 BW125 4/5 19 868300000 b827ebffff7f93d3 1 -63 10.5
    06.03.2018 15:31:17 UNCONF_UP fe740023 SF11 BW125 4/5 18 867100000 b827ebffff7f93d3 1 -69 11
    06.03.2018 15:30:47 UNCONF_UP fe740023 SF11 BW125 4/5 17 868500000 b827ebffff7f93d3 1 -68 9
    06.03.2018 15:30:17 UNCONF_UP fe740023 SF11 BW125 4/5 16 867500000 b827ebffff7f93d3 1 -75 10
    06.03.2018 15:29:47 UNCONF_UP fe740023 SF11 BW125 4/5 15 867500000 b827ebffff7f93d3 1 -68 9.5
    06.03.2018 15:29:17 UNCONF_DOWN+MAC_LINKADR_REQ SF11 BW125 4/5 3 867900000 B827EBFFFF7F93D3 0321ff0001 SUCCESS 0
    06.03.2018 15:29:17 UNCONF_UP fe740023 SF11 BW125 4/5 14 867900000 b827ebffff7f93d3 1 -77 10
    06.03.2018 15:28:47 UNCONF_UP fe740023 SF11 BW125 4/5 13 867900000 b827ebffff7f93d3 1 -68 11.8
    06.03.2018 15:28:17 UNCONF_UP fe740023 SF11 BW125 4/5 12 868300000 b827ebffff7f93d3 1 -75 10.8
    06.03.2018 15:27:47 UNCONF_UP fe740023 SF11 BW125 4/5 11 868300000 b827ebffff7f93d3 1 -67 11.2
    06.03.2018 15:27:17 UNCONF_UP fe740023 SF11 BW125 4/5 10 867300000 b827ebffff7f93d3 1 -73 10.8
    06.03.2018 15:26:47 UNCONF_DOWN+MAC_LINKADR_REQ SF11 BW125 4/5 2 867100000 B827EBFFFF7F93D3 0321ff0001 SUCCESS 0
    06.03.2018 15:26:47 UNCONF_UP fe740023 SF11 BW125 4/5 9 867100000 b827ebffff7f93d3 1 -74 10
    06.03.2018 15:26:17 UNCONF_UP fe740023 SF11 BW125 4/5 8 867500000 b827ebffff7f93d3 1 -67 8.8
    06.03.2018 15:25:47 UNCONF_UP fe740023 SF11 BW125 4/5 7 867500000 b827ebffff7f93d3 1 -66 9.2
    06.03.2018 15:25:17 UNCONF_UP fe740023 SF11 BW125 4/5 6 867900000 b827ebffff7f93d3 1 -79 11.8
    06.03.2018 15:24:47 UNCONF_UP+MAC_LINKADR_ANS fe740023 SF11 BW125 4/5 5 867700000 b827ebffff7f93d3 0307 1 -66 10.2
    06.03.2018 15:24:18 UNCONF_DOWN+MAC_LINKADR_REQ SF12 BW125 4/5 1 868300000 B827EBFFFF7F93D3 0311ff0001 SUCCESS 0
    06.03.2018 15:24:18 UNCONF_UP fe740023 SF12 BW125 4/5 4 868300000 b827ebffff7f93d3 1 -75 6.5
    06.03.2018 15:23:48 UNCONF_UP fe740023 SF12 BW125 4/5 3 868300000 b827ebffff7f93d3 1 -74 8
    06.03.2018 15:23:18 UNCONF_UP fe740023 SF12 BW125 4/5 2 867100000 b827ebffff7f93d3 1 -75 9
    06.03.2018 15:22:48 UNCONF_UP fe740023 SF12 BW125 4/5 1 867100000 b827ebffff7f93d3 1 -68 8.8
    06.03.2018 15:22:36 UNCONF_UP fe740023 SF12 BW125 4/5 0 867700000 b827ebffff7f93d3 1 -79 8.5
    06.03.2018 15:22:28 JOIN_ACC 287556d156120cb74bb4f8dcc072e8521fb3dbb5eb179076cde0a0a65f24e23538 SF7 BW125 4/5 0 868500000 B827EBFFFF7F93D3 SUCCESS 0
    06.03.2018 15:22:28 JOIN_REQ SF7 BW125 4/5 0 868500000 b827ebffff7f93d3 0 -77 7



  • What is your gateway using?



  • @xc.c Paket forwarder consisting of IMST iC880A +Raspberry. I got another node with RN2483 - and there is no problem with it, it working properly.



  • @Digidenis What's band you used ?
    " it occurs at the maximum speed -SF7. This does not meet the specification"
    Would you like send the spec ?

    Thanks



  • @junhua i use EU band ( you can see it in the listing).
    i have try any possible setup for module and server but ADR still not work.
    Can anyone share their experience in this issue with latest firmware?

    For SF issue- i am read specs 1.1 again and find only this (/The join-request message can be transmitted
    using any data rate and following a random frequency hopping sequence across the
    specified join channels. It is RECOMMENDED to use a plurality of data rates. /).
    My mistake, module can use SF7, its not forbidden, but use SF12 is make more sense, because i got more chance to join and then adjust SF and power step by step.



  • One more question... ( am i need create another topic for that?)
    How can i customize frequency plan?
    I need to setup those plan:
    base freq 868.9, 869.1 Mhz + additional freqs 864.1-864.9 Mhz ( its actually russian frequency plan)
    I set manually channels 0-6 (at+set_config=ch_list: num,on,freq,0,5), so after command "at+get_config=ch_list" i got responce from module "OK0,on,868900000,0,5;1,on,869100000,0,5;2,on,864100000,0,5;3,on,864300000,0,5;4,on,864500000,0,5;5,on,864700000,0,5;6,on,864900000,0,5;7,off;8,off;9,off;10,off;11,off;12,off;13,off;14,off;15,off" - and this is what i expect to see.

    But when i send "at+join=otaa" module connect to gateway with EU frequency plan, not RU ( i got 2 gateway with different setups).
    So, despite configured channels, module try to join using default EU channels, and dont using precofigured value.



  • Yep, you are right, there is a serious firmware bug. I only tested this is AU_915 mode but I don't think by reading the above that this is limited to the Australian frequency range.

    1. You can set the channel list to restrict your used channels, if you don't the end-mode will pick any of the (in Australia) 64 channel. I don't consider this a bug however it would have been beneficial to have this mentioned in the documentation.
    2. Even if you set a channel list the node will still send the OTAA packet on a channel outside of the set list! This is the first BUG
    3. The negotiation or evaluation of the end-node to choose the most appropriate data rate for the distance to the gateway or better evaluation of RSSI and SNR is not working and has random results, in 95% of the packets I transmitted they arrive at SF 12 or very seldom on SF8 never on any other spreading factor. however if you managed to get an OTAA and you use at+dr = 0 to 5 you will see that the packets are received on other spreading factors 7,8,9,...
      This is a real issue if you have an 811 tracker board as it moves around you will need to shift the data rate all the time.

    I hope that RAK will soon release a new firmware to counter act this serious shortfall. In my opinion it renders the boards pretty much useless unless you have a stationary unit which you nail to one frequency and even than the use is limited as the OTAA is unreliable.



  • I found solution for ADR issue. Just need 500 ms delay after wake ing up module, dont ask me why


Log in to reply
 

Looks like your connection to RAK Support Center was lost, please wait while we try to reconnect.