Closed atektelic closed 8 months ago
Hello atektelic,
In your trace log it appears that traces have been added:
"UPLINK #401: Port: 2, DR3 (903.10 MHz, SF7, BW125), Payload[1]: 02"
Before this trace, do you check the modulation type with smtc_real_get_modulation_type_from_datarate()
to use the right conversion of datarate ? smtc_real_lora_dr_to_sf_bw()
for LoRa or smtc_real_lr_fhss_dr_to_cr_bw()
for LRFHSS
There is an example of use here: https://github.com/Lora-net/SWL2001/blob/ffca22633d111ef2874fa7c2f35498a57d87f3f0/lbm_lib/smtc_modem_core/lr1mac/src/lr1mac_core.c#L234C10-L234C10
Best
Thanks for your input, closing this ticket now as it is a problem on our end.
Hello,
During LCTT test case 12B, a LinkADRReq is sent (to the end device) to set data rate to DR5 (which is used for LR-FHSS in US915). We expect the end device to NACK the LinkADRReq on the LinkADRAns, however, the end device resets and eventually fails LCTT test case 12B.
From this log file, the reset is caused from calling
region_us_915_lora_dr_to_sf_bw
function (see below), wherein DR5 falls under theelse
clause which runssmtc_modem_hal_lr1mac_panic
causing the system to reset:It seems, by default, LoRa Basics Modem compiles with
RP2_103
– this sets DR5 (along with other DRs) as supported DR for US915 during compile time (i.e. enables bitfield for DR5 as supported DR). With DR5 enabled, LinkADRReq command requesting DR=5 passes the valid DR check. But once the sensor tries to transmit,region_us_915_lora_dr_to_sf_bw
function is called and causes a reset (as explained above).Our current work around to pass LCTT test case 12B is to compile LoRa Basics Modem with
RP2_101
flag enabled to use RP002-v1.0.1 specs.Have we missed anything to prevent this behaviour? Or maybe this is expected? Any input is much appreciated.
Thanks!