Add 224 port certification mode

[terrillmoore]

Hi @terrillmoore , would be very nice if the lib will have the 224 port test included, I know for a fact there are others also asking on another forum if this is possible. I was at the LoRaWan conference 1,5 week ago and quality is one of the main items that has focus, would be very nice if boards like RFM95 together with the LMIC lib are compliant.

I am in contact with IMST (a german certification test house), they mentioned you can do a pre certification yourself without having to send your device to them, I have asked how this can be done, will keep you informed and would be happy to test it.

Regards,
Jeroen

edit: Just checked out MCCI, nice company :-). All open source, vey nice! You are probably way ahead of me, but still if I can help would be great.

Originally posted by @I-Connect in #196 (comment)

[terrillmoore]

Hi, was going to look at this last weekend but ran out of time. But now that we have #196 merged, I think it's time to do it. I think I am going to do it actually in the ardunio-lorawan code, because then I can use C++ and move more quickly. But I may change my mind and do it all in the lmic, or at least put the port-224 code here as a library function.

Note to self: the referenced code from IMST is LoRaMac-node.

[terrillmoore]

I've started working on this, using a RedwoodComm RWC 5020A as the tester. I'm using test-driven development, and I'll push my code to branch issue215 occasionally.

First step was to get an internal fix for #229, so I can code the message receive logic sanely.

I then created an application (rwccert-otaa-halconfig-us915.ino) as an example sketch for doing the certification pretesting. I'll probably rename it, because there's no reason not to use the configured region.

I'm now to the point where I can click start on the test, and the device will join with the tester, print a message (Received message on port 224: 4 bytes), and then ignore it. This means I can now implement and start to test the switch to certification mode.

[terrillmoore]

Changed subject to be more helpful.

[terrillmoore]

@I-Connect I'm now working on this; I'm not sure you were notified by github when I created the issue. Anyway, you'll get noise on this from here on.

[terrillmoore]

Further note; I'm just referring to the LoRaWAN certification docs, which I have, as my starting poin.

The plan is to add an engine that can be called from the user's message processor. The engine has the following parts.

lmic_cert_engine_t LMIC_CertState; -- an (opaque to clients) object that tracks the certification state. (This probably won't be declared in lmic.h, as I don't think it needs to be visible.)

lmic_cert_rx_action_t
LMIC_certRxMessage(
    uint8_t port, const uint8_t *pMessage, size_t nMessage
    );

A function to be called from the user's message RX handler, before doing any work. It will check for port 224, and take appropriate actions based on the body of the message. The caller must check the return in order to determine how to proceed.

lmic_cert_rx_action_t -- a value returned from the certification state engine, with the following values:

LMIC_CERT_RX_ACTION_START -- indicates that the message was for the certification engine, and started certification mode. The client must disable normal uplink generation, and should disable normal processing.

LMIC_CERT_RX_ACTION_END -- the certification engine has exited uplink mode based on this message. The caller should not process the message further, but should restart normal processing.

LMIC_CERT_RX_ACTION_DISCARD -- the message did not cause a state change, but should not be processed by the caller.

LMIC_CERT_RX_ACTION_PROCESS -- the message did not cause a state change, and must be processed by the caller.

[terrillmoore]

Status as of fa68184:

The LMIC now processes the activate and deactivate test mode messages correctly. It fails the mandatory directed join requests -- it prints EV_REJOIN_FAILED. Since this is the first time I've used LMIC_tryRejoin(), I suspect it's just broken. Also, it doesn't seem to be using the 500 kHz channels at all. And the random channel selection really slows down test; a shuffle would be much better. Oh well, that's what happens when you test. I can trivially test on EU868 as well, maybe I'll try that when I get a chance.

[terrillmoore]

Current status: we now pass the RWC rejoin test (receive window 2). Added fixes for #247, #244, #235, #245, #4.

The echo ("crypto") request seems to break things; we don't echo, and we stop responding to inbound messages. So... that's for tomorrow. Simple FSM problem, I think.

[terrillmoore]

Current status: everything in the port 224 code, except for CW generation in the FSM, is verified. The biggest problem is that the onEvent upcall (and friends) happens inside the LMIC, rather than at the edge. The code really should use an osjob to report events up, to avoid massive confusion with recursive calls into the LMIC. Event function and tx/rx complete functions have to be coded very carefully to avoid problems. From a usability point of view, this is bad. It would be better to just move event processing to a separate osjob, which would possibly require a queue (as multiple events might be reported in one schedule of the LMIC). For now, we just advise extreme caution. There are (of course) a number of LMIC errors that need to be corrected, but we probably can pull this branch onto HEAD once we have clean builds on all targets.

[terrillmoore]

I'm starting to prepare a pull request to bring this onto head. I'm doing a code review. I decided that LMIC_Cert is too confusion; reminds me of "certificate". So I'm now using LMIC_Compliance -- and everything got renamed to follow. Things are passing CI tests. Since this also introduces the callback scheme, I still need to dither about whether to push the callbacks to an OS job. I also realized that it's a major usability problem to have Tx immediately start the LMIC rather than using an osjob. The key is, you can't call engineupdate() from within engineupdate().... maybe that suggests how to make it more robust, which is to explicitly detect and defer recursive calls (as I do in the compliance fsm).

[terrillmoore]

Regression testing was indicated. In order to find my bugs, I had to straighten out a number of things.

• Fix Allow messages up to the maximum length #77 to allow longer echo messages.
• Fix os_setCallback re-triggering is not robust #251, reportEvent() unconditionally calls engineUpdate() #253, Add API for checking if time-critical jobs are pending #254 were required for stability.
• I had to address Compliance test needs clock tolerance of 5% #259 (clock tolerance) in the test script.
• I found radio.c uses SX1272_MC1_IMPLICIT_HEADER for the 1276 #252, Cancel pending transmit when doing LMIC_reset() for frame count overflow. #247 while doing code review.
• I needed Add LMIC.saveIrqFlags for tracking down RX problems #257 and Add EV_RXSTART and EV_JOIN_TXCOMPLETE #255 for tracking down LMIC stops receiving downlinks during compliance testing #258 and isolating it.

I think this is already enough better than master that it's time to do a pull request.

[terrillmoore]

I've created pull request #260 -- I'll wait a day or two to merge. Interested parties are welcome to review and/or test. I'm sure there are things that need to be documented in README.md that I've missed.

[terrillmoore]

I reviewed the changes in #260 this morning, and it looks good to me. I'll hold off a little while longer before committing, but as I want to continue chasing #258, and I want to post corrections for #261, #262, #263, and think that should be on a separate branch building on this, I'm anxious to get this on the main development branch.

[frazar]

I'm interested in looking into the changes, but I'm going to be quite busy in the next few days.

[terrillmoore]

Things are much better now, so I've merged this onto HEAD. We pass RWC US cert tests 1, 2, and 3.1 through 3.6. Now running into #266 and #267, but no point in keeping this branch off HEAD.