Testing issues with compliance-otaa-halconfig with AU915 #340
Comments
|
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. 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. |
|
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 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 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. |
|
@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:
|
|
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.
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. |
|
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. |
|
You might want to retest now with master (more or less v3.0.99.3). |
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.
The text was updated successfully, but these errors were encountered: