search

ARMmbed / mbed-os-example-lorawan

Simple LoRaWAN example application for mbed OS
Apache License 2.0
78 stars 92 forks source link

Can't join, AU915 #132

Closed evandavey closed 4 years ago

evandavey commented 5 years ago

I am trying to run a minimal example as suggested in #122. I can see a join accept in the TTN console but the device does not receive any events. Here is the full log:

[DBG ][LSTK]: Initializing MAC layer

 Mbed LoRaWANStack initialized

 CONFIRMED message retries : 3

 Adaptive data  rate (ADR) - Enabled
[DBG ][LSTK]: Initiating OTAA
[DBG ][LSTK]: Sending Join Request ...
[DBG ][LMAC]: Frame prepared to send at port 0
[DBG ][LMAC]: TX: Channel=65, TX DR=6, RX1 DR=13

 Connection - In Progress ...
[DBG ][LSTK]: Transmission completed
[DBG ][LMAC]: RX1 slot open, Freq = 915200000
[DBG ][LMAC]: RX2 slot open, Freq = 923300000
[DBG ][LMAC]: Frame prepared to send at port 0
[DBG ][LMAC]: TX: Channel=11, TX DR=0, RX1 DR=8
[DBG ][LSTK]: Transmission completed
[DBG ][LMAC]: RX1 slot open, Freq = 917500000
[DBG ][LMAC]: RX2 slot open, Freq = 923300000
[DBG ][LMAC]: Frame prepared to send at port 0
[DBG ][LMAC]: DC enforced: Transmitting in 141284 ms
evandavey commented 5 years ago

Additionally, looks like TTN is getting multiple join requests image

ciarmcom commented 5 years ago

ARM Internal Ref: IOTCELL-1909

hasnainvirk commented 5 years ago

@evandavey Looks like a timing issue with your board. https://github.com/ARMmbed/mbed-os-example-lorawan/issues/122#issuecomment-477935631 Your comment here tells me that you are using some custom board with Murata ABZ radio. I assume your MCU is STM. STM L072CZ in Discovery-LRWAN1 series contain a crystal which is not precise. Check the timing for your board using an oscilloscope. That may clear some air here.

evandavey commented 5 years ago

@hasnainvirk yes, a custom board with a CMWX1ZZABZ-078 (so STM32L082). I will see if I can hook up a scope but I now have the stock example, compiled online, working fine (whereas the locally compiled version reports a connection error, and I have the issue above for the no RTOS version). I am thinking maybe a compiler difference but I don't think I can compile the no RTOS version online. Are there any settings I can tweak for timing tolerance? I will probably do a board revision, what's the recommendation - an external 8Mhz crystal?

hasnainvirk commented 5 years ago

@evandavey 32 MHz crystal. It's interesting that you are having issues with non-RTOS build only. You could tweak the timing tolerance at the cost of longer radio operation modes than necessary. No matter how much I detest this, sometimes we have to do it :). https://github.com/ARMmbed/mbed-os/blob/master/features/lorawan/mbed_lib.json#L72 Check wake-up time too. May be add 5ms to each . When you find out something, do let me know.

evandavey commented 5 years ago

Hi Hasnain - I have just been revisiting my design notes and I am using a precise 32Mhz. The module has an internal 32Mhz oscillator for the Semtech radio which I've connected to the OSC_IN of the module as per the module's Application note. It does suggest in this mode that the registers HSEBYP should be 0 and HSEON should be 1 so maybe that's what's missing? How would I check these?

hasnainvirk commented 5 years ago

I'm afraid, it's not obvious to me. Have to read the specs and MCU datasheet to comment on it. I will try to dig it out at a convenient time. At the moment I'm a bit stretched.

evandavey commented 5 years ago

OK sure, I am playing around with the target system_clock.c function to try and set this up. I copied the DISCO boards HSE setup function (which is for 8Mhz) and I have had some success but everything I think is running at twice the speed. Is there an example setting the clock for 32Mhz HSE?

hasnainvirk commented 5 years ago

There is something relevant. Check tragets.json file (its in targets folder in the tree). You can check STM family targets and you will find with some of them you can select clock source. Look for the field "clock_source". Hope it helps.

evandavey commented 5 years ago

Yes but I don't think the target MURATA_TYPE_ABZ uses these macros(inside system_clock.c) and for the DISCO board, it is set to use a 8MHz external crystal (whereas I want 32Mhz).

So I add the 'SetSysClock_PLL_HSE' function to system_clock.c for the MURATA_TYPE_ABZ target, use this function instead of 'SetSysClock_PLL_HSI' and set RCC_OscInitStruct.PLL.PLLMUL=RCC_PLLMUL_4 and RCC_OscInitStruct.PLL.PLLDIV = RCC_PLLDIV_4. This works in that I get a response from the board but LED flashes appear twice as fast as they should and UART baud looks upset too.

hasnainvirk commented 5 years ago

Hmmm. This is going beyond my expertise. Let's get some help. @kjbracey-arm What do you think ? What is your diagnosis here ?

evandavey commented 5 years ago

Was trying to use STM32 Cube MX to configure the clocks and looks like HSE is expected to be less than 25Mhz for the STM32L082CZ. Not sure how that works on the module as the datasheet suggests it's 32Mhz - seeking clarification on this from Murata as the application note is light on detail.

hasnainvirk commented 5 years ago

Kevin gave me some pointers for your issue. The clock source needs to be 16 MHz which is provided to the PLL. PLL then multiplies it with 4 and divides it with 2 to generate 32 MHz clock. Plus, it will be better to get help from STM as they provide the HAL layer in Mbed OS for all STM targets.

evandavey commented 5 years ago

OK, thanks. I will check over at STM. The Murata note definitely suggests it's a 32Mhz clock and that it can be used (but agree that doesn't seem to fit with the STM32L082CZ). I can't share here due to the confidentiality they have on their datasheets. I've asked them for clarification too. I've definitely had something running using a PLL multiplier of 4 and divider of 4 and by turning off the PLL but as I said it seems to run twice as fast than expected and UART is scrambled. I tried multiplying the PLL by 4 and dividing by 2 but get nothing.

evandavey commented 5 years ago

I guess for the board revision it would be simplest to copy the DISCO board and allow for an 8Mhz external crystal that could be scaled by the PLL.

evandavey commented 5 years ago

So I've had some clarification from Murata. Firstly, is it true that using the internal HSI will not be precise enough for LoRaWAN? If it is precise enough, the issue above is probably not related to the clock.

Secondly, the 32Mhz is an oscillator used for the radio module, with a 32 Mhz output that behaves like a 32Mhz clock. So the STM32 needs to be configured in bypass mode. I have tried doing this in system_clock.c without success but I am not really sure what I am doing so some expert advice would be appreciated if not here then I will check over at STM.

evandavey commented 5 years ago

I have produced a second board revision, this one with the capabilities of using an external 32 Mhz clock, 8Mhz external crystal, or the internal 8Mhz HSI. Currently it is hardware configured with the external 8Mhz crystal connected. I have successfully used the Arduino framework to join, so I know the radio is functioning. I have configured lora.phy to AU915, lora.fsb to {0xFF00, 0x0000, 0x0000, 0x0000, 0x0002} (and have also tried without this set) and lora.duty-cycle-on to false (but have also tried with this set to true. I am using the ARM6 compiler supplied with the latest version of MBED studio. Using this stock example (not the minimal version), I still can not progress past the 'Connection in progress' message using either the MTB_MURATA_ABZ (which looking at system_clock.c doesn't look to support a HSE clock) or DISCO_L072CZ_LRWAN1 (which should support the HSE). I can see the join attempt in the thingiverse:

{
  "time": "2019-05-22T01:36:24.361388343Z",
  "frequency": 918.2,
  "modulation": "LORA",
  "data_rate": "SF12BW125",
  "coding_rate": "4/5",
  "gateways": [
    {
      "timestamp": 304660156,
      "time": "2019-05-22T01:36:24.296239592Z",
      "channel": 7,
      "rssi": -54,
      "snr": 9.75,
      "rf_chain": 1
    }
  ]
}

So it looks like the board is not getting confirmation that the join has succeeded. This is the trace (using MTB_MURATA_ABZ). Is there something wrong with the RX1 slot frequency??

 ---FEEDER SENSE---
[DBG ][LSTK]: Initializing MAC layer

 Mbed LoRaWANStack initialized

 CONFIRMED message retries : 3

 Adaptive data  rate (ADR) - Enabled
[DBG ][LSTK]: Initiating OTAA
[DBG ][LSTK]: Sending Join Request ...
[DBG ][LMAC]: Frame prepared to send at port 0
[DBG ][LMAC]: TX: Channel=64, TX DR=6, RX1 DR=13

 Connection - In Progress ...
[DBG ][LSTK]: Transmission completed
[DBG ][LMAC]: RX1 slot open, Freq = 918600000
[DBG ][LMAC]: RX2 slot open, Freq = 923300000
[DBG ][LMAC]: Frame prepared to send at port 0
[DBG ][LMAC]: TX: Channel=38, TX DR=0, RX1 DR=8
[DBG ][LSTK]: Transmission completed
[DBG ][LMAC]: RX1 slot open, Freq = 100671552
[DBG ][LMAC]: RX2 slot open, Freq = 923300000
[DBG ][LMAC]: Frame prepared to send at port 0
[DBG ][LMAC]: DC enforced: Transmitting in 141411 ms
evandavey commented 5 years ago

I have just repeated this using a DISCO-L072CZ-LRWAN1 board so it seems very unlikely to be a hardware issue. Steps I followed:

  1. import mbed-os-example-lorawan into the MBED online compiler
  2. update mbed_app.json: 
    "lora.phy": "AU915",
"lora.fsb-mask": "{0xFF00, 0x0000, 0x0000, 0x0000, 0x0002}",
"lora.device-eui": "{ 0x00, 0x7C, 0x47, 0x85, 0x0C, 0xE3, 0x32, 0x5A }",
"lora.application-eui": "{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }",
"lora.application-key": "{ 0xA9, 0xA5, 0x64, 0x4D, 0x0B, 0xD4, 0x51, 0xFB, 0xAD, 0xDD, 0x8F, 0xFA, 0xB9, 0x8F, 0x54, 0x27 }"
  3. Compile and upload (note, the first compile generated an error, 2nd compile worked fine).

I am using a RAK831/pi gateway setup using https://github.com/RAKWireless/RAK2245-RAK831-LoRaGateway-RPi-Raspbian-OS. I can connect another (ESP32/Arduino LMIC based) node without issues.

I can see the join request and join accept in the server.

AnttiKauppila commented 4 years ago

“At this time, due to our prioritisation of work on customer projects, we are unable to devote the time to fix this issue. As an open source project, we welcome fixes to Mbed OS, so if would like to contribute a fix yourself then we would very much welcome that, please see our contribution guidelines here - https://os.mbed.com/docs/mbed-os/v5.13/contributing/workflow.html#contributions”

evandavey commented 4 years ago

So, ARM, a multi-billion dollar company, is not willing to support this... Good to know when choosing hardware for our next project.

maansaari commented 4 years ago

Hi Evan,

Unfortunately also in large companies like ARM we have limitations in our engineering resourcing and we are not able to support all the requests in time which are coming in. For this reason we find it better to inform that for time being were don't have capacity to look into this issue and we hope that community would be able to look the fix for the issue. There was some other issues with this example that have been solved, I hope those solved the issues for your problem too. Best Regards, Kirsi