868 Band OTAA TTN not working

[BoelD]

When I use the example sketch for OTAA, in combination with a Murata module, I can't get it working. In my gateway I do see an activation package coming in from the node. But then the activation never happens and the device just keeps sending activation packages, instead of uplink packages containing the payload.

I did check OTAA in the combination with my gateway and an RN2483 module and that worked well.

I suspect the Murata module is somehow not receiving the activation package sent by the gateway. I am not sure whether this is an actual bug, or that I am overlooking something to correctly configure LMIC 2.1.5 to work with a Murata module and TTN.

Thanks in advance for your help!

[BoelD]

This is what I mean:

(The payload at the bottom of the list was when I used ABP)

[terrillmoore]

There are at least three possibilities here.

1. the gateway is not working for downlink
2. the module's receive configuration is not working.
3. your timing (delayMicroseconds(), etc) is not working.

If you have two modules, and you test with the "raw" example (perhaps the raw_feather is a better starting point, as that's what I usually use), you can check (2). Unfortunately, I have repeatedly seen gateways work fine for uplink, but not work for downlink; so it might be (1).

If you are using any of the stock STM32 board support packages, you are likely to run into (3) -- I don't know why, but for some reason the implementation of the microsecond delays is not very good. If using a Murata module, I suggest using the MCCI STM32L0 board support package, which has a fix. [It's not just the Arduino LMIC package; the OneWire package also doesn't work, for the same reason.]

[BoelD]

Thanks for your answer... Let's run through the possibilities you mention:

1. I tested the gateway with another (type of) Lora module (RN2483) and OTAA was working fine, so I think we can exclude the gateway.

2. I do not have another murata at hand at the moment, so unfortunately I cannot test this right now. I should get more in a week or so.

3. I am using the B-L072Z-LRWAN1 board, in combination with the MCCI Catena 4551 board files, installed from the Arduino board manager. Since they both use the same module, and both rely on ST Link for programming, I assumed this should be possible. Could it be that the Catena 4551 is using an external oscillator that changes the timing?

Also, in lmic_project_config it is possible to use define US_PER_OSTICK_EXPONENT. In the standard config, this is value not set. Maybe the default value is not correct for the Murata module?

[BoelD]

I see now, that the version of the board support package installed through the boards manager is 1.06, although the repository is already at 1.08.

But I couldn't update from 1.06 right away. So I uninstalled the package and then version 1.07 appeared, but still no 1.08. I see that the micros() update is in 1.08, to that might be the problem. When I have more time, I will do a manual update.

For your convienience I added this issue to the MCCI STM32L0 board support package repository as well.

Many thanks for all your work!

[terrillmoore]

1.0.7 should work, as the only difference between 1.0.7 and 1.0.8 is in the STM tool packaging. We'll investigate today.

We clearly need a "timing diagnostic" to help narrow things down. You might try increasing the oscillator timing tolerance (which is documented).

[terrillmoore]

One other thing... we are using the 082 version of the module. It is possible that there are other differences that are blocking receive. You might want to look at the Semtech/STM code for your module and compare to the code for the 082, to see if there are any relevant differences.

[BoelD]

I am indeed using the 091 version of the Murata Module, which is indeed based on a 072. But according to Murata, that should be no problem

Unless you are using the hardware AES of course.

[BoelD]

It could be that the way a digital pin is written is different between The Catena 4551 and the B-L072Z-LRWAN1. I tried a simple digitalWrite to a port, and I made sure to match the corresponding pin by comparing the pinmappings in the variant files for both boards. But I wasn't able to drive a pin high when I use the Catana board files in combination with the B-L072Z-LRWAN1 board.

I checked the pinmappings against each other, and matched corresponding pins. For example: D12 in the B-L072Z-LRWAN1 corresponds with PB14, which in the Catena board files corresponds with D22. But when I create a simple blink, with digitalWrite (D22, HIGH) and connect the led to the corresponding pin on the B-L072Z-LRWAN1 (D12) and upload it using the Catena 4551 board files, nothing blinks at all. I tried this with several pins and double checked all connections.

So in short: I can't make a pin HIGH within the Arduino IDE, on my B-L072Z-LRWAN1 board, when I use the Catena board files while uploading a sketch. Even though they both use the same module and a nearly identical MCU.

But: For receiving, rxtx must be high.

[terrillmoore]

Can you post or email documentation (or links thereto) for the board? And also, send your variant file or give us a way to review your changes (e.g., fork the repo and push your changes to your fork)? It seems like this should be easy to fix. But as you say, if we can't drive D22 high, we really can't do anything. Blink is the first step.

[BoelD]

I am using STM32 from ST (v1.2.0) and the board variant I am using is DISCO_L072CZ_LRWAN1.

To sum up the problem: when I use my DISCO_L072CZ_LRWAN1 board, in combination with the Catana board files, I can upload a sketch and even create an LMIC node working with ABP. But OTAA and a simple blink sketch is not working, even if I carefully check in the variant files to make sure I choose a corresponding pin on the board.

I can let the pins blink as they should when I use DISCO_L072CZ_LRWAN1. I haven't tried yet to add extra pin mapings to make the Murata module available here, so I can't use LMIC here yet.

[BoelD]

Ok, blink is working now. This was actually very easy. Pressing the reset button after uploading makes the sketch run. I am so used to a sketch running right after uploading, that it didn't even occur to me to push the reset button this afternoon.

So now I can go back to the point why I started this excersise: measuring the accuracy of millis() micros().

Will do that tomorrow and post more when I know more.

[terrillmoore]

pressing the reset button after uploading makes the sketch run.

Yeah, that's one of the things I would like to fix (along with making the boot button unnecessary, so it's more like the Adafruit designs). Even crazier, if you download with an STLINK, no need for the reset button. Not great UX.

Good luck with next steps.

[BoelD]

I might have found the problem:

In your variant.h file I see:

PA1, //D29 RADIO_ANT_SWITCH_RX CRF1 Murata internal
PC1, //D30 RADIO_ANT_SWITCH_TX_BOOST CRF3 Murata internal
PC2, //D31 RADIO_ANT_SWITCH_TX_RFO CRF2 Murata internal

I don't see these internal Murata pins back in de variant.h for the other board (and Murata module). But alle the other Murata pins are mentioned.

All the pins that in the module that Catena is using are used for Antenna purposes, are in the other file simply used as normal digital pins:

PA1, //D21
PC2, //D22
PC1, //D23

So at this point, I am not sure that the Murata module that is used on the DISCO_L072CZ_LRWAN1 is fully exchangable with the module that you are using.

Unfortunately, I am still waiting for access to the Murata site, so I don't have access to detailed specs of the modules now. Let's wait for that.

Thank for your help so far!

[BoelD]

Ok, it's working now. The 072 and 082 can be exchanged. This was my first assumption and it was confirmed by the datasheets and last experiments.

When I let the sketch run for a while, the join did succeed at some point. But it took 14 attempts and over half an hour. It appeared that only after sending out the join message with SF11 the join succeeds.

Node and gateway are in close proximity. The gateway is not the problem: I do receive all the join requests sent out, regardless the SF. And with an RN2483 module, I can join with OTAA on SF7.

I tried enlarging the RX window, as suggested here, but that didn't help.

I tried a different type (and bigger) antenna, but that didn't change a thing either: still OTAA join only possible at SF11.

So that leaves me with the conclusion that either the reception of the DISCO_L072CZ_LRWAN1 board is very poor, or that there are still some timing problems within LMIC running on the Murata module. Or some parameters in the 868 bandplan files need adjustment.

A quick fix I found to make the join quicker, is to make sure the initial join is done with SF11. Hereto, in lmic_bandplan_eu868.h change

#define LMICbandplan_getInitialDrJoin() (EU868_DR_SF7)

to

#define LMICbandplan_getInitialDrJoin() (EU868_DR_SF11)

This will make the node join at SF11 instantly. Not ideal, since one would like to use a lower SF whenever possible, but for now it works.

[terrillmoore]

@DavidBoelee : that's great!

Nice hack on the dr join; I didn't realize it would be that easy.

We've tested the EU868 bandplan with other hardware and it works well.

It is possible that the timing is wrong; we had to fix the BSP, and you're not using our BSP so possibly that's an issue. Try adjusting the clock accuracy to something ridiculous like 50%. (That just makes the device open the receive window earlier and close it later.) With broken timing, the SF shouldn't have an effect, as the gateway always starts at the same moment. But... the preamble at SF11 lasts 2^4 times longer than at SF7;

If you're using The Things Network, you can easily tell from the device logs whether it is getting the uplink through and missing the downlink. (You'll see it join again on each retry in the console, but the device won't get the response.) If there's a TX problem, you won't see any successful joins at SF7 on the console; if it's an RX problem, you'll see joins, but the device will never see the JoinAccepts.

It is not impossible that the layout on your board has RF problems -- our first attempt had problems, and we had to get help from Murata to improve sensitivity and antenna coupling.

Let us know what you find

[terrillmoore]

@DavidBoelee : no update in two months so I assume that we can close this. Reopen it if needed.