Okay, I figured out the double response in the log, but wow, this is driving me nuts. Bottom line: even at 921600 baud the/my logging is just too often incomplete.
Like this should create 9 entries in the log:
SYS_DEBUG(SYS_ERROR_DEBUG, "\r\nLORA: configureRXChain(1, ...)\r\n");
status *= configureRXChain(1, appGWActivationData.configuration_sx1301.rfchain[1].enable,
appGWActivationData.configuration_sx1301.rfchain[1].freq);
for(i = 0; i <= 7; i++)
{
SYS_DEBUG(SYS_ERROR_DEBUG, "\r\nLORA: configureIFChainX(%d, ...)\r\n", i);
status *= configureIFChainX(i, appGWActivationData.configuration_sx1301.ifchain[i].enable,
appGWActivationData.configuration_sx1301.ifchain[i].radio,
appGWActivationData.configuration_sx1301.ifchain[i].freqOffset);
}
But I get 1 with some weird double response, and 7 for the loop where the first of for(i = 0; i <= 7; i++), is not (properly) shown:
LORA: configureRXChain(1, ...)
RF: 1,1,868500000
LORA: send_cmd: 23 34 06 00 01 01 20 42 c4 33 b8 0d
LORA: recv_rpl: 23 34 07 00 00 01 01 80 e5 f9 ff be 0d
LORA: recv_rpl: 23 35 01 00 00 59 0d
LORA: sendCommand OK
// The following is missing!
// LORA: configureIFChainX(0, ...)
// IF: 0,1,1,-400000
LORA: configureIFChainX(1, ...)
IF: 1,1,1,-200000
LORA: send_cmd: 23 35 07 00 01 01 01 c0 f2 fc ff 0f 0d
LORA: recv_rpl: 23 35 01 00 00 59 0d
LORA: sendCommand OK
// Likewise proper output for i = 2, 3, 4, 5, 6
LORA: configureIFChainX(7, ...)
IF: 7,1,0,400000
LORA: send_cmd: 23 35 07 00 07 01 00 80 1a 06 00 07 0d
LORA: recv_rpl: 23 35 01 00 00 59 0d
LORA: sendCommand OK
So, I am quite sure that the weird second response (the line LORA: recv_rpl: 23 35 01 00 00 59 0d and the next LORA: sendCommand OK) is actually the response for i = 0, and even more: the payload shown for the RX in the line LORA: recv_rpl: 23 34 07 00 00 01 01 80 e5 f9 ff be 0d is actually the payload for the TX in LORA: send_cmd for i = 0!
Compared to when logging happens to be okay, after:
LORA: send_cmd: 23 34 06 00 01 01 20 42 c4 33 b8 0d
ā¦apparently the first and last lines of:
LORA: recv_rpl: 23 34 01 00 00 58 0d
LORA: sendCommand OK
LORA: configureIFChainX(0, ...)
IF: 0,1,1,-400000
LORA: send_cmd: 23 35 07 00 00 01 01 80 e5 f9 ff be 0d
ā¦have somehow been combined into this single bogus line, discarding anything in between:
LORA: recv_rpl: 23 34 07 00 00 01 01 80 e5 f9 ff be 0d
Changing the output format for TX and RX a bit also makes clear itās indeed just a matter of weird printing. (Itās not like the RX and TX data are mixed up in memory.)
TL;DR: for me the fix to flush the buffer is still working, and I guess I can submit the PR, but one needs to be careful trying to read the log.
The only reference to logging I see is:
But that looks okay, as itās about to reboot and then logging would be lost without such delay.
doesnāt look very stabil.