lorabasics / basicmac Goto Github PK

Low-power modes, are they implemented or in what way? If there is an example for configuring low-power modes in the application, please provide it.

When the SX1272 is selected, LORA_RXSTART_FIXUP is not defined breaking the compilation. Adding it with a value of zero makes compilation work again. The value is probably not correct, but the surrounding constants seem to be dummy values as well.

Hi,
I am working on the basic mac project on stm32l072 board and I am using the x-nucleo-iks01a2 sensor board, I want to add the I2C protocol implementation, what is the best way to add it.
Knowing that I added the The I-CUBE-LRWAN Expansion Package , I took that for the stm32l072 board, and I got this error:
/home/mourad/opt/xPacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/8.2.1-1.4.1/.content/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld: /home/mourad/opt/xPacks/@gnu-mcu-eclipse/arm-none-eabi-gcc/8.2.1-1.4.1/.content/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp/libnosys.a(sbrk.o): in function `_sbrk':
../projects.gmk:118: recipe for target 'build-eu868/ex-join.out' failed

please do you have a proposal to fix this error or another way to offer me to implement the I2S protocol?

Hi,

There might be an issue with payload sizes defined in lwmux. The code writes 242 bytes for EU868 DR>3, but it is 222 in LoRaWAN regional parameters V1.0.3 & v1.1

Olivier

In programming model page it is written: Jobs must not be long-running in order to ensure seamless operation!.
Could you please be more specific about maximum job time ? When no LoRaWAN operations are running (after event EV_TXCOMPLETE), could users have long processing time, or they should split any computer intensive jobs in smaller tasks ?

Olivier

Hi,
We are test this on nRF2840+sx1262. The ABP is ok. But OTAA fail. We find we can't recieve the join accept packet from gateway(like EU868). Is there any suggestion? Is it about the RTC? or other timer issues? Thanks.

Great to see work is done to bring an LMIC-based stack back into development. I'm curious how you are planning to structure the development of this stack?

IBM used a fairly closed model, where development happened on an internal repository and only releases were published as zip files, without much interaction with or opportunity for contributions from the user community. Here, I see you're using github and have a public forum, which is great. However, I do see that the commit history is completely squashed, with just one commit per release (implying that there is an internal working repository, or that only one or two people are working on the code).

What are the plans for this codebase? Are you expecting to work with the community, accepting pullrequests, publishing development code in separate commits when they are done (rather than only releases), maybe even share the maintainance with community members?

For some background on my question, I created an Arduino port of LMIC years ago, which has become the defacto standard stack to use on (small) Arduino-based platforms. After the initial port, I have been hesitant to do a lot of further development on it, since I did not want the arduino port to deviate too much from the original ARM-based port. I had plans to unify both again (by doing development in the main version and allow automatically creating the Arduino version from that using a script), but never really gotten around to it (and I also held off on it recently when the lorawan minimouse stack and this basicmac stack were expected to be released).

Now that basicmac is available, it looks like a great base to port to Arduino and I'd gladly see it become the new center of development for small LoRaWAN stacks, replacing LMIC at some point. However, I do not want to do a one-off port to Arduino (forking the repo and fragmenting development). But if this repository is not intended to facilitate community supported development, then it might not be so suitable to serve as such a center of development. Or if you're not planning to support (or even accept pullrequests to support) smaller (8-bit) platforms and project structures (e.g. Arduino does not use Makefiles but requires a specific library format).

In downlink hook, what are the flags ?

Olivier

In programming model page it is written: It is recommended that applications make use of the Application Startup (appstart) service to provide the correct initialization for the run-time environment..

Is it recommended or mandatory ?

Olivier

Hi,

In order to avoid too many issues I will list here typos in the documentation; fell free to check the boxes when corrected.

Page https://doc.sm.tc/mac/programming.html

• Run-time API Functions: menitioned => mentioned

The source of the documentation is missing. Having the documentation locally can be quite useful and it's also not possible to create pull requests.

Hi,
As I understand basicmac nad basicloader will have support for remote upgrade.
My question is will remote upgrade will be suported for ABP and OTAA?

Hi,

First page of the documentation mentions the onEvent() function. It used to be in LMiC 1.6, is it still there in LMiC 1.9 ?
A search on the code does not return any result.

Olivier

https://github.com/lorabasics/basicmac/blob/master/lmic/lce.c#L73

Does LoRaWAN pre-1.1 have a notion of NwkKey? Perhaps that code should be:

void lce_addMicJoinReq (u1_t* pdu, int len) {
#if defined(CFG_lorawan11)
    os_getNwkKey(AESkey);
#else
    os_getAppKey(AESkey);
#endif    
    os_wmsbf4(pdu+len, os_aes(AES_MIC|AES_MICNOAUX, pdu, len));  // MSB because of internal structure of AES
}

https://doc.sm.tc/mac/programming.html#c.os_runloop

It might be great to add something like "It should be called only one time" so users now they do not have to call in again in the callbacks, and maybe rename it to os_runInifiniteLoop() ?

HI

Unable to build bootloader

arm-none-eabi-gcc -std=gnu11 -DSTM32L0 -DSTM32L073xx -DUP_PAGEBUFFER_SZ=64 -DBOOT_LED_GPIO="GPIO('A',5,0)" -MMD -MP -g -mcpu=cortex-m0plus -I../../../src/common -fno-common -fno-builtin -fno-exceptions -ffunction-sections -fdata-sections -fomit-frame-pointer -I../../../src/arm/CMSIS/Include -Wall -Os -I../../../src/arm/CMSIS/Device/ST/STM32L0xx/Include -c -o bootloader.o ../../../src/arm/stm32lx/bootloader.c ../../../src/arm/stm32lx/bootloader.c:1:0: error: target CPU does not support ARM mode // Copyright (C) 2016-2019 Semtech (International) AG. All rights reserved. ^ <builtin>: recipe for target 'bootloader.o' failed make: *** [bootloader.o] Error 1

In the documentation it is said to use LMIC_startJoining, but the code example is using lwm_setmode(LWM_MODE_NORMAL);

Which is the recommended way to join ?

Olivier

It would be nice to add it to the documentation

Olivier G.