Testing issues with compliance-otaa-halconfig with AU915

[paulalting]

With a gateway setup for AU915 sub band 3 and using the compliance-otaa-halconfig.ino I am still running into problems it appears.

With a Rocket Scream Mini Ultra Pro V2 board, (similar to Feather M0) I have configured an additional pin map for it and using the basic compliance-otaa-halconfig example with lmic project config set for AU921, using sub band 3, by LMIC_selectSubBand(2).

What I notice is that it connects right way with joinRequest and getting joinAccept, but what I think is not correct is that it appears to use other channels outside of Sub Band 3 as well as the channels in the band. If the Gateway is setup for using only sub band 3, then many data packets are ignored.

As a test, I re-configured everything to use US915, the gateway and the Rocket Scream board, again, using the compliance-otaa-halconfig example set for sub band 1. It works without any fault at all, absolutely perfect data coming into the LoRaServer.

I re-configure back to AU921, with same code, but for AU921 and sub band 3 and the problem presents itself.

The only real way I seem to be able to makes sure only selected channels are used is to set LMIC_setAdrMode(false). I will need ADR enabled as part of the projects underway.

I guess my question is, has the library been fully tested with AU921, (sometimes as AU915) ?
What other data or information can I provide ?

Below is a sample of the serial data output:
Channels for sub band 3 are 16 to 23, so why are there transmissions on channels such as 5 and 9, where you can see the txrxflags is 0x20 rather than when the correct channel is used and txrxflags is 0x21.

Starting
Packet queued
349102: EV_JOINING
349198: EV_TXSTART: ch 22 rps=0x4 (SF10 BW125 CR 4/5 Crc IH=0), datarate 2, opmode 88C
669366: EV_RXSTART: freq=926.9 rps=0x94 (SF10 BW500 CR 4/5 NoCrc IH=0), datarate 2, opmode 88C, txend 372415, delta ms 4751
690200: EV_JOINED: ch 22
netid: 0
devaddr: 15243C7
artKey: 7-E7-84-91-65-83-7C-13-11-77-A3-D1-6D-FF-32-58
nwkKey: C4-A5-E7-96-A-77-79-F4-86-FB-F4-52-92-69-B2-29
690351: EV_TXSTART: ch 18 rps=0x4 (SF10 BW125 CR 4/5 Crc IH=0), datarate 2, opmode 888
775625: EV_RXSTART: freq=924.5 rps=0x94 (SF10 BW500 CR 4/5 NoCrc IH=0), datarate 2, opmode 888, txend 716129, delta ms 951
783940: EV_TXCOMPLETE: ch 18 rps=0x94 (SF10 BW500 CR 4/5 NoCrc IH=0) txrxflags 0x21
Packet queued
1721585: EV_TXSTART: ch 5 rps=0x1 (SF7 BW125 CR 4/5 Crc IH=0), datarate 5, opmode 888
1786211: EV_RXSTART: freq=926.3 rps=0x91 (SF7 BW500 CR 4/5 NoCrc IH=0), datarate 5, opmode 888, txend 1725811, delta ms 966
1845311: EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate 5, opmode 888, txend 1725811, delta ms 1912
1923349: EV_TXCOMPLETE: ch 5 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0) txrxflags 0x20
Packet queued
2860995: EV_TXSTART: ch 21 rps=0x1 (SF7 BW125 CR 4/5 Crc IH=0), datarate 5, opmode 888
2925300: EV_RXSTART: freq=926.3 rps=0x91 (SF7 BW500 CR 4/5 NoCrc IH=0), datarate 5, opmode 888, txend 2864900, delta ms 966
2928221: EV_TXCOMPLETE: ch 21 rps=0x91 (SF7 BW500 CR 4/5 NoCrc IH=0) txrxflags 0x21
Packet queued
3865866: EV_TXSTART: ch 19 rps=0x1 (SF7 BW125 CR 4/5 Crc IH=0), datarate 5, opmode 888
3930491: EV_RXSTART: freq=925.1 rps=0x91 (SF7 BW500 CR 4/5 NoCrc IH=0), datarate 5, opmode 888, txend 3870092, delta ms 966
3933419: EV_TXCOMPLETE: ch 19 rps=0x91 (SF7 BW500 CR 4/5 NoCrc IH=0) txrxflags 0x21
Packet queued
4871064: EV_TXSTART: ch 9 rps=0x1 (SF7 BW125 CR 4/5 Crc IH=0), datarate 5, opmode 888
4935688: EV_RXSTART: freq=923.9 rps=0x91 (SF7 BW500 CR 4/5 NoCrc IH=0), datarate 5, opmode 888, txend 4875289, delta ms 966
4994788: EV_RXSTART: freq=923.3 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0), datarate 5, opmode 888, txend 4875289, delta ms 1911
5123226: EV_TXCOMPLETE: ch 9 rps=0x96 (SF12 BW500 CR 4/5 NoCrc IH=0) txrxflags 0x20

[paulalting]

With further investigation I find that if I place in the sendComplete() function, just before the schedule for next transmission a call to LMIC_selectSubBand(2), then it appears to function how I would expect.
I wonder if settings coming down from the gateway are being misinterpreted with respect to channel mask or something similar ?

By including the above function at that spot or just before payload transmission, I get reliable and consistent exchanges from sensor node to gateway and into LoRaServer.

Even if this is more of a hack at this point in time, I will like to try this out on some installed sensor nodes based on Feather M0 that are installed but have been very silent.

[terrillmoore]

Hi @paulalting sorry for the slow response.

For sure, the network is sending you things right after join that update the channel mask.

I have, in several of my sketches, some code that prints out downlink MAC messages. I register a receiveMessage callback, and in that code I have:

        if (port == 0)
                {
                gCatena.SafePrintf("MAC message:");
                for (unsigned i = 0; i < LMIC.dataBeg; ++i)
                        {
                        gCatena.SafePrintf(" %02x", LMIC.frame[i]);
                        }
                gCatena.SafePrintf("\n");
                return;
                }

This prints out any MAC downlink messages. These are sent after the JoinAccept and typically update teh channel masks.

You can also print out the channel masks by printing LMIC.channelMap[0..4] as 4-digit hex numbers. 0..3 are for the 125 kHz channels, and 4 is for the 512 kHz channnels. (You can do this right after join, and again after any successful downlink).

The code for managing the channels works fine in the US, but it's possible there's a bug in AU due to typos or cut/paste issues.

[paulalting]

@terrillmoore I have confirmed that the case for including a LMIC_selectSubBand(2) as detailed in my earlier posts is indeed required for correct functionality on a deployed LoRaWAN infrastructure in the local city here. They use AU915 sub band 3.

Note: We all here in Australia call our band AU915, not AU921.

Without the additional and continual issue of selecting the required sub band before each transmission, it simply does not function beyond the initial join connection.

It may function if sub band 1 is used, but I did not test that, though I guess for all users here in Australia, where a selected sub band may be used, then the library will likely fail unless they also include the above statement before each transmission.

I have tested under a number of operating conditions as well as using the compliance test, and the result is consistent with inclusion as well for test when no inclusion of this statement.

Printing the channel mask at join time give the following data live from site from device reset:

Rose Lane North
Battery Volts: 4.13 V Well Level: 7.72 m Temperature: 12.0 C Pressure: 1009.5 hPa
TX Packet Queued Ch: 21 freq: 0 DR: 0
EV_JOINING
EV_TX_START
EV_JOINED
Network ID: 12582xxx
Device address: FC002xxx
App EUI Key: 16A46xxxB6E5959E5BFC16875D0xxx
Network Key: BFA28xxx23C83F995FDC5233DBE0Fxxx
--
Channel Map 0: 0
Channel Map 1: FF
Channel Map 2: 0
Channel Map 3: 0
Channel Map 4: 4
EV_TX_START
EV_TX_COMPLETE
Battery Volts: 4.19 V Well Level: 8.91 m Temperature: 12.0 C Pressure: 1009.5 hPa
EV_TX_START
TX Packet Queued Ch: 22 freq: 919600000 DR: 5
EV_TX_COMPLETE
Battery Volts: 4.19 V Well Level: 9.04 m Temperature: 12.0 C Pressure: 1009.6 hPa
EV_TX_START
TX Packet Queued Ch: 19 freq: 919000000 DR: 5
EV_TX_COMPLETE
Battery Volts: 4.20 V Well Level: 9.05 m Temperature: 12.0 C Pressure: 1009.6 hPa
EV_TX_START
TX Packet Queued Ch: 16 freq: 918400000 DR: 5
EV_TX_COMPLETE
Battery Volts: 4.20 V Well Level: 11.39 m Temperature: 12.0 C Pressure: 1009.5 hPa
EV_TX_START
TX Packet Queued Ch: 17 freq: 918600000 DR: 5
EV_TX_COMPLETE
Battery Volts: 4.20 V Well Level: 11.78 m Temperature: 12.0 C Pressure: 1009.5 hPa

[terrillmoore]

There is no certification test for AU915, and that's the only way I can test apart from setting up a TTN gateway.

I can tell from the displayed frequencies that you are not using The Things Network. Per https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html#au915-928, they use channels 8..15 and 65; this is (0-origin) subband 1.

The printed channel map and the frequencies indicate that subband 2 (counting from 0) was selected.

1. what network are you using? It appears that you're using you own network (since you measure Loraserver)
2. Please post the exact sketch(es) you're using.
3. What libraries are you using?
4. Bear in mind that many of the sample sketches (including the compliance sketch) do explicit setup of the subband for US. (The compliance sketch currently uses subband 0 in the US, because of a bug in supporting equipment.)

Because of point 4, I know that the basic library works with various subbands, and doesn't usually require aggressive reset of the subbands.

It's a good idea to check how the compliance sketch prints out data. The LMIC is very fragile w/r/t timing in the event outcall. You can't do much, and in particular it's a bad idea to print very much out. To get compliance to work, I had to minimize the work in the event processor, and defer all time consuming work until after the LMIC becomes idle.

[terrillmoore]

On reflection, it seems likely that your network is sending LinkADRRequests to your device, and that these requests don't match the bandplan of your gateway. (Your statement that "disabling ADR" makes the problem better makes me think this; the device will definitely request ADR.)

Also, I've found many problems with MAC message processing. What version of the LMIC are you using? If you're using a release version, please try updating to latest HEAD on master, as there have been many bug fixes. I haven't made interim releases because most of the work has been done in the last few weeks.

[terrillmoore]

You might want to retest now with master (more or less v3.0.99.3).