How to test/use class B

[sualko]

Hi everyone,

I know support for class B is labeled as untested, but I would like to change that 😉. Can anyone give me some advice how I can debug support of class B, because I'm currently stuck. Also helpful resources to read are appreciated. If you have no time to answer this noob question, feel free to close the issue.

My stack: Loraserver + Loragateway, Raspberry Pi 3 as Gateway with RAK831 and GPS converter board. I run Raspbian on the gateway with lora-gateway and packet-forwarder from lora.net. Everything configured to use EU868. Class A ist working fine and the packet-forwarder is showing the right GPS coordinates and the emission of a beacon. In the loraserver my device profile enables class B and sets ping frequency to 4 seconds (all other settings are untouched at 0).

From the lorawan specification I know that every device joins as class A device and levels up after it receives a beacon. Therefore I called LMIC_enableTracking after my device joined. I tested 0 and 5 (I don't understand exactly what the parameter means even after reading the documentation) as parameter, but the result was always a EV_SCAN_TIMEOUT. I also tried to call LMIC_setPingable(2) after join, but with the same result.

My issue is now that I don't know where to look at. Which components in the stack are crucial for class B support? Is my loraserver miss configured? Or is my use of the lmic library wrong? Who can help and maybe provide an example?

[terrillmoore]

HI @sualko -- thanks for your note.

Please check the pdf docs (in the doc directory) for LMIC_enableTracking(). There are two cases:

• if > 0, then then next n uplinks will request beacon info (but the device won't start searching.
• if == 0, then the device immediately starts looking for a beacon.

Second, it's very possible that the parameters in the LMIC are wrong -- check the data in lorabase.h and lorabase_eu868.h to confirm that things are rign.

Third, you really want to call LMIC_setPingable(1) after join, because that's what really accomplishes the transition to class B.

Fourth, hack up the compliance sketch, turn on event logging (so that LMICOS_logEvent etc actually are compiled in), and check how RX events are being handled.

It's very likely that the LMIC has an obsolete idea of the beacon format -- when I was originally reviewing this, I found mismatches and errors in the LoRaWAN spec, which have subsequently been corrected in 1.0.3 -- that's what you should use as a reference.

Good luck!

[sualko]

thanks for your note.

thanks for your quick and helpful response. With your clues I was able to receive a beacon and to start the frequent rx windows from class B. As you stated the frequency was wrong and only with a dirty fix I was able to get it right. Will work further on it, because it's quite unstable and I only receive beacons sporadic. Also the class B bit is not set in the uplink message, and therefore the server is still waiting for an uplink message (class A mode). If it's ok for you, I will report my progress.

Btw I think the parameter for LMIC_enableTracking is deprecated, because the BeaconTimingReq is deprecated. Or did I miss something?

[terrillmoore]

That's great that you're getting beacons at all.

There's a replacement for BeaconTimingReq, which we should be using in its place: DeviceTimeReq. But it's just an optimization; it's totally OK to start by scanning for a beacon without sending any uplinks at all.

Are you calling LMIC_setPingable(1)? That's what completes the conversion of the device into a Class B device. Then at line 1890 or so:

    LMIC.frame[OFF_DAT_FCT] = (LMIC.dnConf | LMIC.adrEnabled
                              | (sendAdrAckReq() ? FCT_ADRACKReq : 0)
                              | (end-OFF_DAT_OPTS));

Add here the setting of bit 4 (FCT_CLASSB), if OP_PINGABLE is set. Something like:

    LMIC.frame[OFF_DAT_FCT] = (LMIC.dnConf | LMIC.adrEnabled
                              | (sendAdrAckReq() ? FCT_ADRACKReq : 0)
#if !defined(DISABLE_PING)
                             | (LMIC.opmode & OP_PINGABLE) ? FCT_CLASSB : 0
#endif // ndef DISABLE_PING
                              | (end-OFF_DAT_OPTS));

[sualko]

There's a replacement for BeaconTimingReq, which we should be using in its place: DeviceTimeReq.

I tried the DeviceTimeReq, but it didn't work in a quick test. Not sure why, but it's also not that important to me. One other think I recognized was that the PingSlotChannelRes is malformed and therefore the server sends a new request if he receives a response and so on and so on. I disabled it via DISABLE_MCMD_PingSlotChannelReq for now.

Are you calling LMIC_setPingable(1)?

I call LMIC_setPingable(2), because I have my server configured to a 4 seconds interval. The receive slots are also opened, but as far as I can tell the server is not aware of that.

Add here the setting of bit 4

That worked like a charm. The uplink packet is now marked as class b. Receiving is still not working, but this could also be related to the loraserver. I have to lookup how this is normally be done, because the loraserver still waits for the next uplink message. Once again, thanks for your help.

P.S.: I think I know why the loraserver is not starting to send in the ping slots. It's in the lora specification section 14.3:

Once the NS has sent the first PingSlotChannelReq command, it SHOULD resend it until it receives a PingSlotChannelAns from the device. It MUST NOT attempt to use a class B ping slot until it receives the PingSlotChannelAns.

At least I know now where I have to look.

[terrillmoore]

Great. It should be easy to fix the PingSlotChannelAns uplink. Since I've not tested at all, and I rewrote the mac message code, it's very likely that I messed it up. But it should be easier to find and fix in the new code.

[sualko]

Short update: The beacon search is still not reliable, but that's not the biggest issue at the moment. With my/your fixes from #481, the PingSlotChannelRes is also working sometimes. I have no idea why, but sometimes the PingSlotChannelRes is send as payload to port 17 (which is the mac code of the response). Do you have an idea, why this happens? Where should I look at?

[terrillmoore]

Can't tell from your comment if you're running into this, but:

In LoRaWAN, MAC commands can travel in one of two ways.

• they can be sent explicitly to port 0.
• they can piggyback on messages sent to other ports.

Uplink MAC messages will often piggyback on messages sent to other ports. The network is free to decide whether to piggyback the downlink MAC messages. It looks like your network is using the same port 17 for PingSlotInfoAns as the PingSlotInfoReq used for piggyback on the uplink. Totally legal. The LMIC will parse it and act on it either way. You will get a zero-length message for port 17 in the app (or you'll get a valid port 17 message, depending). In either case, the answer has been processed. If you need to detect the presence of the mac message in your app, you can compare your message pointer to the base of the message buffer. If not equal, then there was a mac message, which has been removed.

[sualko]

It looks like your network is using the same port 17 for PingSlotInfoAns as the PingSlotInfoReq used for piggyback on the uplink.

My application is only using port 1. What I get from lmic is something like that:

{
  "mhdr": {
    "mType": "UnconfirmedDataUp",
    "major": "LoRaWANR1"
  },
  "macPayload": {
    "fhdr": {
      "devAddr": "0044ece9",
      "fCtrl": {
        "adr": false,
        "adrAckReq": false,
        "ack": false,
        "fPending": true,
        "classB": true
      },
      "fCnt": 4,
      "fOpts": null
    },
    "fPort": 17,
    "frmPayload": [
      {
        "bytes": "Aw=="
      }
    ]
  },
  "mic": "ee9fd4f3"
}

As you can see, 17 is the mac cmd for PingSlotInfoAns and Aw== is 0x3, which means frequency and dr are processed. I don't think that mac commands should be transferred as payload, or am I wrong?