search

Lora-net / LoRaMac-node

Reference implementation and documentation of a LoRa network node.
Other
1.88k stars 1.09k forks source link

I-CUBE-LRWAN with stm32 (Need Help!!!) #217

Closed thrinasco closed 6 years ago

thrinasco commented 7 years ago

The example program given in I-CUBE-LRWAN 1.1.0 is for STM32L053,but i have STM32L082 and sx1276.I am using India Lorawan public network which is under 868MHz.I changed the frequencies to INDIA lora frequencies provided.ALL pins are set properly and all keys are given in commisioning.h file by selecting ABP method.I am not able to send or recieve the messages to Gateway.Can anyone help exactly what are the files i need to modify in order to communicate.Selected frequency REGION_IN865.

djaeckle commented 7 years ago

Hi thrinasco,

are you using the code on the feature/4.4.0 branch?

fletort commented 7 years ago

Why the code of the I-CUBE-LRWAN is not inside this repo ? I should be very easier to contribute to fix different bug on it.... i have some strange behaviour with it....

acourt commented 7 years ago

Unfortunately, it seems like the folks at STMicro decided that they wanted to release their own fork of this repo for their development kit instead of sticking to Semtech's official stack. Someone should complain to them directly.

spasoye commented 7 years ago

Hey guys, I am also having some issues with their example. I'm using Multitech Conduit gateway and Nucleo with SX1272 mbed shield. ST I-CUBE-LRWAN _endnode example works well with older lora-network-server 0.0.9, but when i upgrade it to version 1.0.13 my node successfully joins the network, but then it never gets to open rx window. Did anyone experienced similar behaviour ?

jmunt commented 7 years ago

I got I-CUBE-LRWAN working on B-L072Z-LRWAN1 about a month ago, had to fix a handful of bugs in both the AU915 stack and ST's implementation, the ST induced bugs being the more critical ones. My code is too far modified to share sorry. As painful as it sounds I think it's probably better to just pull the loramac-node stack directly from here and learn to implement it yourself, I am very unimpressed with ST's example code and I think learning how the stack works is unavoidable in the longer run anyway because the current state of the stack seems to have a lot of minor bugs and region specific issues.

jamesl-dm commented 7 years ago

My experience as well - skipping the ST version.

fletort commented 7 years ago

yes... i am not alone :-( (I-CUBE-LRWAN working on B-L072Z-LRWAN1 as @jmunt , and a lot of problemm too) I work on it since end of february. they are now 3 weeks that i ask myself : come back to this repo (that i already used on another target) or try to fix the st fork...... I have already fix some point on st stack too (some come directly from this repo, as the st version is not updated quickly). Another point was the tcxo timer off.

But my last point that i did not succes to resolve is this one:

did you also see this bug @jmunt ?

fletort commented 7 years ago

Ok don't use the v1.1.0 of the st library... it is based on a fork of the local dev branch (date end of february) !!!! THe previous version 1.0.3 of the st library seems more stable (as based on the local master branch, v 4.3.0)...... Very strange to make a fork of the dev branch of the middle of a development !

acourt commented 7 years ago

Has anyone been able to contact the ST developers and figure out what they are doing? Someone should tell them that they should be branching their code from a stable branch, or even better, contribute to this repo.

jmunt commented 7 years ago

I expect ST decided to work off the 4.4 dev branch to support more regions (on paper) and aren't keen to step back from that. They may not want to do much about the issues until the release version hits 4.4.x.

Regarding fail to send after first receive, I experienced something like that yes. In my case further transmit attempts (after join + 1st user packet transmission) failed 100% of the time.

Here's some notes I have on what I changed, you will see it is very region specific, and it is likely from an older version of ST's code and lorawan stack than what is available through ST now. Also since I do not have great knowledge of the stack, don't expect these changes and fixes to be ideal.

lora_fsm() - fixed region definition check (AU915 init was incorrectly checking for AS923 definition) loraMac.c - shifted #IF EU region check near top of file down a line so it no longer included LoRaMacTest.h inclusion, can't remember why GetBandwidth() - fixed logic test for setting datarate, it was off by 1 LimitTxPower() - fixed channel requirement to ACMA req (ACMA ch req has since been totally removed) RegionAU915InitDefaults() - changed default channels according to local gateway RegionAU915AdrNext() - changed default channels according to local gateway RegionAU915AlternateDr() - removed re-enable of 500khz channels since not supported by local gateway RegionAU915AlternateDr() - changed DR_4 to AU915_TX_MAX_DATARATE Changed AU915_TX_MAX_DATARATE from DR_4 to DR_3 RegionAU915NextChannel() - changed code, nextTxDelay was not being updated appropriately (In my case I believe this issue was the culprit for failure to send more than 1 packet after join) Various changes to switch VCOM and sleep implementation to support USART1 instead of LEUART (my ST dev board was faulty - short circuited LEUART under the module and I don't have bga style rework tools/skills, how this passes QA when it's a critical function of the demo code is beyond me - my bet is they didn't even test these boards)

That is all I have in my personal notes, it won't be conclusive because I got lazy with documenting my tests and modifications as my attitude towards the quality of the code plummeted. Also hard for me to recall now, since I moved on to app specific code and then eventually shifted from STM32 to EFM32 largely just because of how disgusted I am with the way ST has responded to my messages regarding my faulty ST dev board, I don't want to risk investing so heavily in companies with such bad support.

x893 commented 7 years ago

Hi, i also use EFM32 and support much better than ST. For my project i use SL720 from Neoway (EFM32ZG + SX1278) for 433 MHz and simple gateway based on 2 RFM95 modules. Also EFM32 has less consumption in deep sleep mode.

EFM32 not a bad choice !

fletort commented 7 years ago

thanks @jmunt... i came back to version 1.0.3 from st that is more stable. (no this bug after 1st paquet transmission). Now that i have something working, i have time to see, as @jamesl-dm , to use the local stack here on my B-L072Z-LRWAN1. Maybe we should make a branch dedicated to this porting layer and try a merge request when this porting layer will be ok.

YoannBo commented 7 years ago

Hi,

I-CUBE-LRWAN 1.1.1 is now available. It is based on the May 30, 2017 commit of the develop branch

mikkleini commented 7 years ago

Since many people complain about I-CUBE-LRWAN i do the same because i am not sure if the issue is in Semtech or ST code. There was no help from writing to ST forum (https://community.st.com/thread/40592-i-cubelrwan-end-node-does-not-work-stably). Problem is that after power up my class A node transmits only one frame. Then it goes to RX mode, which timeouts in 3 seconds and OnRadioRxTimeout() in LoRaMac.c is called. But the LORAMAC_TX_RUNNING flag in LoRaMacState variable is kept high so when there's time to transmit next frame with LoRaMacMcpsRequest() function then LORAMAC_STATUS_BUSY is returned. These functions are the same in both code bases, but they call lot of other functions, I have done diff but it's quite messy.

mirzafahad commented 7 years ago

The data you are sending, is it confirmed data or unconfirmed?

mikkleini commented 7 years ago

Unconfirmed. Also tried confirmed. no difference.

YoannBo commented 7 years ago

Hi,

Is the Timeout coming from DIO1 or from the timer RxTimeoutTimer?

mikkleini commented 7 years ago

Hi, Rough execution flow:

No DIOx ISR occurs during this flow.

Two problems:

  1. There's RX state while using unconfirmed messages.
  2. It doesn't recover from timed out RX.
jmunt commented 7 years ago

mikkleini,

I have already noted a problem above that caused failure to transmit more than 1 packet (I believe it was stuck in LORAMAC_STATUS_BUSY state also). The problem in my case was that the band time off or aggregated time off functionality of loramac-node was bugged, the variable used to decide band time out was not getting updated and thus causing infinite band time off. Since band duty cycle requirements are different based on region this issue was in the region specific MAC source.

My fix (in AU915 case) was to add an update to nextTxDelay in RegionAU915NextChannel() within the aggrTimeOff <= LastAggrT case, beside the line which is commented as "search how many channels are enabled". Here is the line I added:

nextTxDelay = RegionCommonUpdateBandTimeOff( nextChanParams->DutyCycleEnabled, Bands, AU915_MAX_NB_BANDS );

After adding this line I was able to transmit multiple times. Just keep in mind that this edit might not be an appropriate fix, I only spent a few days messing with the stack and it was a few months ago, so I was no expert at the time and now I can barely remember.

YoannBo commented 7 years ago

Hi,

In your post you say you " I ported this example to iM880B (stm32L151CB-A + sx1272). " 1/did you map the iM880B hw into the stm32l1xx_hw_conf.h?

define RADIO_RESET_PORT GPIOA

define RADIO_RESET_PIN GPIO_PIN_2 //GPIO_PIN_0

define RADIO_MOSI_PORT GPIOA

define RADIO_MOSI_PIN GPIO_PIN_7

define RADIO_MISO_PORT GPIOA

define RADIO_MISO_PIN GPIO_PIN_6

define RADIO_SCLK_PORT GPIOA

define RADIO_SCLK_PIN GPIO_PIN_5

define RADIO_NSS_PORT GPIOB

define RADIO_NSS_PIN GPIO_PIN_0 /GPIO_PIN_6

define RADIO_DIO_0_PORT GPIOB //GPIOA

define RADIO_DIO_0_PIN GPIO_PIN_1 //GPIO_PIN_10

define RADIO_DIO_1_PORT GPIOB

define RADIO_DIO_1_PIN GPIO_PIN_10//GPIO_PIN_3

define RADIO_DIO_2_PORT GPIOB

define RADIO_DIO_2_PIN GPIO_PIN_11 // GPIO_PIN_5

define RADIO_DIO_3_PORT GPIOB

define RADIO_DIO_3_PIN GPIO_PIN_7 // GPIO_PIN_4

define RADIO_DIO_4

ifdef RADIO_DIO_4

define RADIO_DIO_4_PORT GPIOB // GPIOA

define RADIO_DIO_4_PIN GPIO_PIN_5// GPIO_PIN_9

endif

2/also, you need to change the code sligly in sx1272mb2das (or create another one ) to control the switch properly. On sx1272mb2das, the switch control is one pin while the wimod module 2 control pins are needed: one pin is set for Rx and the other pin is set for tx. (None set in idle)

mikkleini commented 7 years ago

@jmunt: Thanks, will try out

@YoannBo: I didn't create that ST post, i just commented below it. I use STM32F4 and SX1276 module (Dorji DRF1276G). There's no ANT selection pin so i turned off the antenna selection code. IO's are othewise configured and double checked. The TX/RX work physically - i know it because the gateway gets the join message and first data message and node gets the join confirmation.

YoannBo commented 7 years ago

@mikkleini : I'm just saying that, if DIO1 pin from the radio is not triggering SX1276OnDio1Irq in case of Rx timeOut, I see the problem you report.

mikkleini commented 7 years ago

@jmunt: That line which you added was already part of EU868 region source code.

@YoannBo: You pointed directly at the issue! 👍 DIO1 was not connected. I have a self-built prototype with bunch of wires and it was loose. After connecting it there came DIO1 IRQ shortly after RX begin. Great thanks! However the operation is still quite sporadic, only few TX messages go through, most of the times LoRaMacMcpsRequest() is still returning busy. Will look into that. Maybe it has something to do with region duty cycle limit...
PS. Yes it is duty limit of ~110 seconds.

mikkleini commented 7 years ago

One thing still bothers me. Even though i got the issue fixed by having DIO1 signal connected to the MCU i still feel that there's room for improvement in LoRaMac stack. Generally, in reliable embedded system, the SW shall always consider with possible failures outside the MCU (or even with failures in MCU peripherals). It seems that the RxTimeoutTimer is implemented to consider with the possibility of no external event and the OnRadioRxTimeout() function is executing on time out, but it doesn't recover correctly. Or what other purpose is there for this timer? It's hard to believe that the timeout purpose is to put the SW into busy/stuck state.

mirzafahad commented 7 years ago

OnRadioRxTimeout() - as the name suggested, this function is supposed to handle radio timeout. Let's just say, you are sending a JOIN request. After sending the request you would go to sleep. Now after JOINDELAY1 (5s) the radio should wake up and look for the predefined preamble for 'certain period of time'. If radio doesn't get that preamble in that 'certain period of time' it will generate that DIO1 RxTimeout signal.

It doesn't put your SW in a busy or stuck state. It should go back to the normal operation (at least that's how mine is working).

griphi commented 7 years ago

Hi, I have a question regarding to the class system of the LoRaWAN. Is it possible to program the MCU to switch from class A to class B after an specific interrupt?

Example: 80% of the time the MCU is in class A mode (sleep mode) and after an hardware interrupt the MCU switches into the Class B mode (send Beacon).

Hardware: STM32 P-Nucleo-LRWAN1 with SX1272 Gateway Conduit from Multitech with LoRaWAN Card extension

Thanks

mluis1 commented 7 years ago

@griphi The question you are asking is out of topic. In the future it would be nice if you could open a specific issue. I have created a new issue for this topic. Issue #266

griphi commented 7 years ago

@mluis1 Ah, thanks for that.

mluis1 commented 7 years ago

@fahad80 Yes, you are right the OnRadioRxTimeout is supposed to handle the radio reception timeout. The issue is that we forgot to handle the case where the timeout happens on the first reception window.

We are currently validating a fix for this situation. We should be able to push a fix shortly.

KarimelQ commented 7 years ago

Hello @thrinasco , i have exactly the same problem as you, i'm working with stml082 & SX1276, i have no idea which files to modify in order to make things work, and i want to know if you found a solution to that issue. Thank you

sharmiladevadas commented 6 years ago

Hi, Following procedure i used for testing STM32L072 Discovery Kit 1.Downloaded I-CUBE-LRWAN software

  1. Build AT_SLAVE
  2. Flashed binary to STM32L072 Discovery Kit using STM32 ST-link utility software Once the device is powered on below prints appeared on the console

ATtention command interface If OTAA enabled DevEui= 36-34-37-31-68-37-65-19 AppEui= 01-01-01-01-01-01-01-01 AppKey= 2B 7E 15 16 28 AE D2 A6 AB F7 15 88 09 CF 4F 3C

If ABP enabled DevEui= 36-34-37-31-68-37-65-19 DevAdd= 01C875A0 NwkSKey= 2B 7E 15 16 28 AE D2 A6 AB F7 15 88 09 CF 4F 3C AppSKey= 2B 7E 15 16 28 AE D2 A6 AB F7 15 88 09 CF 4F 3C OK

OK

When entered any of the AT commands, not able to see anything on the console and Gateway is not recieving anything.

Please provide any inputs/suggestions to solve the above issue.

NicoHell1 commented 6 years ago

I think I have the solutions to your problem here, I managed to run the AT_Slave, if you use a terminal like PuTTy or Kitty, to see what you are entering in the console, you have to go to the terminal tab and chose "Force on" for "Local echo", you should be able to see what you write, then if you enter the right AT commands you should receive an answer from the board (for example, a simple "AT" should be answered by "AT_OK"), you can find the list of AT commands here: http://www.st.com/content/ccc/resource/technical/document/application_note/group0/db/8c/4f/5a/95/9e/40/69/DM00346311/files/DM00346311.pdf/jcr:content/translations/en.DM00346311.pdf

mluis1 commented 6 years ago

Can we close this issue?