Through Kconfig the keys are set up correctly. Got some packages with null keys on the gateway so I can confirm that the Makefile keys are not affecting the implementation.
Did you set them like this?
DEVEUI=aaaaaaaaaaaaaaaa APPEUI=bbbbbbbbbbbbbbbb APPKEY=cccccccccccccccccccccccccccccccc make
With that, I can see the keys in riotbuild.h:
/* Generated file do not edit */
...
#define LORAMAC_ACTIVE_REGION LORAMAC_REGION_EU868
#define CONFIG_LORAMAC_APP_KEY_DEFAULT "cccccccccccccccccccccccccccccccc"
#define CONFIG_LORAMAC_APP_EUI_DEFAULT "bbbbbbbbbbbbbbbb"
#define CONFIG_LORAMAC_DEV_EUI_DEFAULT "aaaaaaaaaaaaaaaa"
...
@jia200x after setting up PHY values manualy at semteck_loramac_radio.c I’m getting consistent join requests in the gateway, but no join accept (apparently the downlink is missed by the end-node).
This is expected with the patch, because the downlink configuration is usually different. This patch was just to test whether the TX path was ok or not.
From what I see, it seems that the region configuration is either wrong or not loaded properly. This would explain why you get a successful join request every now and then consistent joins when you use a fixed frequency.
It could be that for whatever reason the parameters PHY parameters are not loaded properly in the radio, but this is unlikely.
I remember we had to use the US915 Hybrid region in Chile . Could you try that region? You can select US902-928(hybrid) in Kconfig
Inside my riotbuild.h there is no CONFIG_LORAMAC_XXX... for neither of the keys. The file looks like this:
/* Generated file do not edit */
#define DEVEUI "aaaaaaaaaaaaaaaaa"
#define APPEUI "bbbbbbbbbbbbbbbbb"
#define APPKEY "cccccccccccccccccccccccccccccccc"
#define CPU_FAM_STM32F1 1
#define STM32F103xB 1
#define CPU_LINE_STM32F103xB 1
#define STM32_FLASHSIZE 65536U
#define __SYSTEM_STM32F1XX_H 1
#define CPU_MODEL_STM32F103C8 1
#define CPU_CORE_CORTEX_M3 1
#define RIOT_APPLICATION "lorawan"
#define BOARD_BLUEPILL "bluepill"
#define RIOT_BOARD BOARD_BLUEPILL
#define CPU_STM32 "stm32"
#define RIOT_CPU CPU_STM32
#define MCU_STM32 "stm32"
#define RIOT_MCU MCU_STM32
#define NDEBUG 1
#define REGION_US915_HYBRID 1
#define LORAMAC_ACTIVE_REGION LORAMAC_REGION_US915_HYBRID
#define RIOT_VERSION "2021.04"
The us915-hybrid didn’t work either.
@jia200x I’ve kept working with the tests/pkg_semtech_loramac and noticed that the selected frequencies for uplinks are usually incorrect (if I’m getting the driver right).
Since TTN proposes AU915 for chilean network, I’ve setup all the devices in the network to do so. The arduino-lmic node works as usual. For the debugging process join abp is done to get into transmission quest asap.
The output of tests/pkg_semtech_loramac and ENABLE_DEBUG 1 on drivers/sx127x_getset.c:
> loramac tx RIOT
loramac tx RIOT
[semtech-loramac] loramac cmd msg
[semtech-loramac] send frame riot
[semtech-loramac] MCPS request: confirmed TX
[sx127x] Set channel: 926800000
[sx127x] set modem: 1
[sx127x] already using modem: 1
[sx127x] Set bandwidth: 0
[sx127x] Set coding rate: 1
[sx127x] Set spreading factor: 12
[sx127x] Set CRC: 1
[sx127x] Set freq hop: 0
[sx127x] Set Hop period: 0
[sx127x] Set fixed header length: 0
[sx127x] Set IQ invert: 0
[sx127x] Set power: 27
[sx127x] Set preamble length: 8
[sx127x] Set TX timeout: 3000
[sx127x] Set max payload len: 17
[sx127x] Set payload len: 17
[sx127x] Change state: TX
[sx127x] Set op mode: TRANSMITTER
[semtech-loramac] MCPS request: OK
[semtech-loramac] MAC timer timeout
[sx127x] Change state: IDLE
[sx127x] Set sleep
[sx127x] Set op mode: SLEEP
[sx127x] Change state: IDLE
[sx127x] Set channel: 923300000
[sx127x] set modem: 1
[sx127x] already using modem: 1
[sx127x] Set bandwidth: 2
[sx127x] Set coding rate: 1
[sx127x] Set spreading factor: 12
[sx127x] Set preamble length: 8
[sx127x] Set fixed header length: 0
[sx127x] Set payload len: 0
[sx127x] Set CRC: 0
[sx127x] Set freq hop: 0
[sx127x] Set Hop period: 0
[sx127x] Set IQ invert: 1
[sx127x] Set symbol timeout: 29
[sx127x] Set RX single: 0
[sx127x] Set max payload len: 66
[sx127x] Set RX timeout: 0
[sx127x] Set RX
[sx127x] Change state: RX
[sx127x] Set op mode: RECEIVER
[semtech-loramac] Transmission completed
[semtech-loramac] MAC timer timeout
[semtech-loramac] MAC timer timeout
As we can see, the selected frequency for the first uplink is 926.8 MHz, and not part of the AU915-928 as stated on the following img:
Is this a bug? or this behaviour is correct?
Hi,
I suspect there’s something wrong with the frequency configuration.
This behavior is definitely not correct.
I will manually check the AU915 region and check what the Semtech
LoRaMAC pkg is doing. I’ll report back as soon as I find something.
I’ve been playing with the ChannelsDefaultMask array in RegionAU915.c and now it seems to choose a couple of the correct frequencies, got Join procedure succeeded! after few tries.
Hi,
I actually wanted to check this on Friday but unfortunately got consumed
by some other work topics.
I’m already looking into it.
I have the impression RIOT might be selecting the wrong frequency plan.
Let’s see
Hi,
I confirm from the LoRaWAN Regional Parameters specification (v1.0.3)
that the region has 64 125KHz-uplink channels going from 915.2 to 927.8.
The picture in TTN is just a subset of the channels of AU915-928.
This means, this channels have to be disabled in order to work with TTN.
The ChannelsDefaultMask is probably the answer. In fact, I found this
answer that solves
a similar problem.
This is also the reason why you rarely saw a join request in TTN.
If this works for you, we should probably add a wrapper or compile time
config parameters to deal with this.
Please let me know how it goes.
Guessing I have implemented the fix right because it’s seems to be working just fine.
Moving forward with examples/lorawan to build a proto firmware for the device, using BOARD=bluepill-128kib it seems to be some kind of problem with the RTC callback. I would totally asume because of this:
The following features may conflict: periph_rtc periph_rtt
Rationale: On the STM32F1, the RTC and RTT map to the same hardware peripheral. Only one standard C library can be used.
Right? Anyways I may have found a problem with tests/periph_rtc, the output is:
socat - open:/dev/ttyUSB0,b115200,echo=0,raw
Help: Press s to start test, r to print it is ready
s
START
main(): This is RIOT! (Version: 2021.07-devel-247-gd2fa7-periph_rtc_l5)
RIOT RTC low-level driver test
This test will display 'Alarm!' every 2 seconds for 4 times
Setting clock to 2020-02-28 23:59:57
Clock value is now 2020-02-28 23:59:57
Setting alarm to 2020-02-28 23:59:59
Alarm is set to 2020-02-28 23:59:59
Alarm cleared at 2020-02-28 23:59:57
No alarm at 2020-02-28 23:59:59
Setting alarm to 2020-02-28 23:59:61
Alarm!
Alarm!
Alarm!
Alarm!
As shown, when the program sets the last alarm, the clock hasn’t overflowed to 24:00:00.
offtopic:
Been working on CPU_FAM_STM32L5 but periph_rtc still resists to pass tests/periph_rtc, so I-m kinda stuck again.
Thanks for the support!
Great to hear!
I’m definitely not an expert in RTC/RTT. Maybe @fjmolinas or @aabadie might provide some insights
