Reacties geplaatst door Heinz

6 Reacties

M
MartijnGStarter
gevraagd in LoRa Forum

MAC Commands implementatie.

Dear Lennart, That's right, LoRaWAN 1.1 clarifies this (therefore my comment above). But currently KPN LRC is LoRaWAN 1.0 and our radio module has implemented 1.0.2 If LRC needs LinkAdrReq to set the ChMask it should be documented somewhere by KPN how end devices which have implemented LoRaWAN 1.0 or 1.0.2 should behave, because as you wrote "[u]LRC[/u] still needs to send LinkADRReq..." Best Regards, Heinz

21
Lennart Nordin
Oud KPN Medewerker
6 jaar geleden
M
MartijnGStarter
gevraagd in LoRa Forum

MAC Commands implementatie.

Dear Rick, Thanks for your reply. We discussed the issue of ADR OFF and LinkADRReq and the need of the KPN server to use LinkADRReq to set the ChMask internally, with the customer and also with Semtech. We could implement the solution from LoRaWAN V1.1 with 0xF for DataRate and TX Power. So the module is allowed to send back a LinkADRAns with ChannelmaskACK set to 1. This is a workaround that could help you.

21
Lennart Nordin
Oud KPN Medewerker
6 jaar geleden
M
MartijnGStarter
gevraagd in LoRa Forum

MAC Commands implementatie.

Dear Rick, Thanks for the reply and good to know that this issue is fixed now. What is about the other issue with ADR OFF and LinkADRReq? Martijn has generated some log files on the end device side. 1) ADR ON: we see in 75 minutes log file only one MAC CMD from the server LinkADRReq Everthing works fine! 2) ADR OFF: We see several the following MAC CMDs in a loop - LinkADRReq + DevStatusReq - LinkADRReq + 3 times NewChannelReq - 2 times NewChannelReq .... - LinkADRReq + DevStatusReq - LinkADRReq + 3 times NewChannelReq - 2 times NewChannelReq .... Now, there are two options: 2a) end device responses on the MAC CMDs directly via port zero-> this leads to an non ending loop of MAC CMDs and MAC RSPs consuming the duty cycle of the end device 2b) end device tries to answer with the packet header of the next payload uplink. Then this loop is discontinued because is not resopnding directly on MAC CMDs. It waits for the next payload uplink packet. This is not satisf

21
Lennart Nordin
Oud KPN Medewerker
6 jaar geleden
M
MartijnGStarter
gevraagd in LoRa Forum

MAC Commands implementatie.

Hi Rick, Thanks for your fast reply. Maybe I have to explain in more detailed what was meant. Sorry! Concering 1) ADR (Adaptive Data Rate) is OFF on EndDevice. Server asked with LinkADRReq to Adapt the Data Rate (ADR) ? I now that this command also includes the ChMask. End Device Aative Data Rate is OFF Server sends Command to Adapt Data Rate? 2) From the LoraWAN specification V1.0 page 25 below table 6. "If any of those three bits (Channel mask ACK/Datarate ACK/Power ACK) equals 0, the command did not succeed and the node has kept the previos state." Some (as far as I know IBM LMic implementation, Semtech GitHub implementation) interpret this, that when ADR is OFF this CMD is rejected (all bits =0 within the LinkAdrAns). Note has to kept previos state means: nothing should be accepted from this LinkADRReq ? 3) Although one can certainly discuss point 2) (intepretation of the LoraWAN specification) my question was: When the Severer always asks e.g. DevStatusReq and the

21
Lennart Nordin
Oud KPN Medewerker
6 jaar geleden
M
MartijnGStarter
gevraagd in LoRa Forum

MAC Commands implementatie.

We have same situation with the MAC CMD DevStatus Req. EndDevice has set ADR ON but send MAC responses immediately via port 0. You can see device received a MAC CMD 03 01 DF 00 01 06 which is a LinkADRReq (03 01 DF 00 01) and a DevStatusReq (06). Due to the fact that ADR is switched ON at the end device this answer the LinkADRAns is responded (I assume with an answer that the srever accepts). But after this the DevStatusReq (06) is repeated several times. The module alsways answers with 06 FF 12 06: CID FF: end device was not able to measure the battery level yy: signal to noise ratio, a variable value e.g. 12 or 11, or 0D Wha does the server repeats this DevStatusReq. alsways? What must the end device answer to stop this?

21
Lennart Nordin
Oud KPN Medewerker
6 jaar geleden
M
MartijnGStarter
gevraagd in LoRa Forum

MAC Commands implementatie.

IMST: We see this situation (loop between network server sending the same MAC CMDs and end device answering the same MAC RSPs) also with other MAC CMDs (CID 0x06). 1) LinkADrReq: ADR is switched off on the enddevice (recommandatoiion for mobile devices from KPN ?). This (ADR Off) is signalled to the server after Joining the end device. Does a LinkADRReq CMD from the server still makes sense? 2) LoRaWAN spec. is not very accurate in this spoint (V1.0.2 page 25). But it says "if one of those three bits (ChMask, DataRate,TXPower) equals 0, the command did not succeed and the node has to kept the previos state. Some interpret this, that when ADR is OFF this CMD is rekected (all bits =0 iwithin the LinkAdrAns). 3) Generally: how useful is it, to ask always the same question when always getting the same answer? This consumes unnecessarly Duty Cycle.

21
Lennart Nordin
Oud KPN Medewerker
6 jaar geleden

Badges

Toon alle badges
Forumvoorwaarden