I am hoping to use this pull request for a project, and would like to help out. What unreliable behavior have you observed? And do you have a sense of where the problem might be coming from?

From my end, I see OTAA joins failing before a reply can be received (sometimes, but not always), and data transmissions aren't being sent - plus the test code hangs indefinitely with no confirmation or failure message when trying to send data.

Thanks.

Thanks for proposing some help here @ecarthi.

What unreliable behavior have you observed? And do you have a sense of where the problem might be coming from?

I didn't rework this PR recently, just rebased it now, but the problems I initially observed are the same as the ones you describe regarding reply not received: the RX windows are closed too early so messages sent from the backend are missed. The problems were happening mostly with DR0/DR1.

Regarding the code that is hanging, this was fixed in master, so now that the branch is rebased, this shouldn't happen anymore (not yet tested though).

Otherwise, the good point with this loramac version is the possibility to select the datarate used during the join procedure. With the old version, this is not possible.

@aabadie do you think you can rebase this PR ? I have some new hardware I'd like to test, I would like to try your PR and I need the I2C rework ;)

do you think you can rebase this PR ?

I already rebased it after I2C rework was merged.

I ran some tests with this PR and my new board
What I can say right now :
otaa join works excepts with DR0 and DR1
I can exchange data between my node and my gateway

Hi

We did it separately — https://github.com/unwireddevices/RIOT/tree/loralan-public-2018.07/pkg/semtech-loramac, also backported RU864 band from 1.0.3a

Application logic is here — https://github.com/unwireddevices/RIOT/blob/loralan-public-2018.07/examples/loralan-wan/main-node.c (not a pure example, but a part of a bigger project, and some logic is not here yet, e.g. uplink queue)

Works quite good with Thingpark and Gotthard's LoRaWAN server, including DR0 OTAA joins.

I'm trying to figure out what's wrong with this madness but I didn't make any progress.
Looks like the node doesn't see the join request's response from the gateway. I've hacked all the timings and yet I never received the RX done interrupt. It seems to me all parameters are all set correctly by the LoRaMAC stack...
I also tried to compated with @olegart's branch but still no clue.

Network server issue maybe? E.g. Actility ThingPark has SF settings for each registered device, and it replies on RX2 with the specified SF, not SF that device used to send JoinReq.

Our branch works on STM32L151 Cat. 3/4/5 (CBU6A, CCU6, RET6...) or STM32L07x CPUs, if you have any of those, you may want to try it by compiling examples/loralan-wan (change the board accordingly). Other CPUs are not supported due to rtctimers_millis implementation. At least you'll see if it's a device related issue or not.

After flashing, you'll need serial console to set DevEUI, AppKey and AppEUI, and then you may change LoRaWAN settings (join type, default DR, ADR) with the "set" command followed by "save" and "reboot". To send some payload data enable something like "mod lmt01 enable" or "mod adc enable", then "save" and "reboot" — after that you'll have "lmt01" or "adc" modules enabled, they send some data automatically (period can be changed with "adc period N" or "lmt01 period N" command) or by command ("adc send", "lmt01 send").

As for now, we've tested our code with Actility, brocaar and gotthard's servers, OTAA works with DR0.

@olegart I am not a ST user so I won't be able to test your branch directly. I'm using TTN with a multitech GW for now. I don't think (yet ?) this is related to the server. I'll try to put more time on it later.

I have some news about DR0 and DR1. TTN seems to use the RX2 window to send the join request's response(using DR0 and DR1 only). But a timeout occurs even before the device setup the RX2 window leading to failure.

@aabadie I was able to locate the DR0/DR1 join request issue. I'll provide a fix once cleanup done so we can finally move forward. Should I push your branch directly or you prefer handle it ?

Thanks for your help @dylad ! That's really a good news.

Should I push your branch directly or you prefer handle it ?

You can push to my branch, no problem.

To explain more in details what was going on there :
For DR0/DR1 join requests, TTN send the response on the RX2 Window at the dedicated frequency (869525000 Hz). The issue was the behaviour of the TimerGetElapsedTime function implements in semtech_loramac_timer.c

    uint64_t CurrentTime = xtimer_now_usec64();
    return (TimerTime_t)(CurrentTime - savedTime) / US_PER_MS;

This function was substracting us with ms leading in incorrect results.

This wrong result was then used here
Because of that, the condition was true and LoRaMac was aborting the RX2 setup when the timeout of RX1 was received. Since the RX2 was not setup, we didn't received the TTN response because the device was not even listening.

Note : I also fixed TimerGetCurrentTime which was also incorrectly set

@aabadie I'll let you check if it solves issues on your side.
Since I commit to this PR, I'll let @jia200x or someone else ACK :)

Interesting fix @dylad, so it was just a conversion issue ? I'll try to test today on IoT-LAB if time permits.

Yup, I confirm it again, I was able to fix all my JR DR0/DR1 with this fix. I put 1 billion printf in LoRaMAC stack to find it out ;-)

I tested this PR on IoT-LAB and could join/send/receive packets using DR{0,1,2,3,4,5}. Thanks a lot @dylad !
Auto-ACK :)

I tested this PR on IoT-LAB and could join/send/receive packets using DR{0,1,2,3,4,5}.

Great ! One approves and we can finally merge this one !

One approves and we can finally merge this one !

To me it's perfectly fine if there's only yours :)

Me too but I'm afraid some maintainers don't have the same opinion.

@jia200x, @dylad I just pushed a couple of commits that improve things significantly in the interaction of RIOT adaption code and the MAC: no more freeze and better return statuses. It works very well now.
I hope this PR will be merged soon.

just tested and works as expected!

there's a bug but it's also present in upstream:

2018-09-25 13:46:36,207 - INFO #  loramac set dr 6
> loramac get dr
2018-09-25 13:46:39,839 - INFO #  loramac get dr
2018-09-25 13:46:39,840 - INFO # DATARATE: 0
> loramac set dr 5
2018-09-25 13:46:43,576 - INFO #  loramac set dr 5
> loramac get dr
2018-09-25 13:46:46,168 - INFO #  loramac get dr
2018-09-25 13:46:46,169 - INFO # DATARATE: 5

I'm OK to merge this one and add the fix in another PR

(we should fix the DR issue, which is not related to this PR)

re-trigger Murdock for LLVM. We can push the green button right after !

rebased, let's wait for the CI

The CI passed, there's an ACK => all green, so let's go.
And special thanks to @dylad for finding the timers bug, that helped a lot.