Open javafrog opened 3 years ago
Hi, what band are you using? I think this might be related with this bug. Whenever I use AU_915_TTN the join is done correctly but then the uplink packets have some error in the packet format.
Thanks for your reply! I'm using the EU868 band.
I can confirm the same.
modem.write(buffer, 2)
return 2 as it stores the two bytes in its internal buffer.
modem.endPacket(false)
produces the following debug output while returning 2 (success, 2 bytes were sent)
22:11:48.873 -> ### AT: +CFM= 0
22:11:48.906 -> ### AT: +SENDB= 0 : 2d01
On the application server side the payload is empty. It was working fine with MKRWAN_v1. I'm using EU868 band.
Hi, any news or workaround about this?
I think I found the issue.
When you call endPacket()
, modemSend()
is called in turn. This one actually composes the binary frame sent to the STM32 inside the lora module. At some point sendAT()
is called with:
sendAT(GF("+SENDB="),"0",":",msg_buf);
By debugging the module firmware I've discovered that 0 stands for "fPort" in LORA terminology and 0 is reserved for LoRa mac messages. Anything data related should not use 0 (https://lora-developers.semtech.com/library/tech-papers-and-guides/the-book/the-port-field/).
Changing the line to does it for me:
sendAT(GF("+SENDB="),"1",":",msg_buf);
EDIT: This has apparently already fixed in the master branch. By using the setPort()
class function.
Hope that helps.
Thanks @javafrog and @fe64970103. If I understand correctly, we can consider this partially fixed by:
LoRaModem::setPort
(https://github.com/arduino-libraries/MKRWAN_v2/commit/68e55095ca91589a5e09235d109587a9e7bbc52e).Is the problem fixed by adding a call like modem.setPort(3);
to your sketch @javafrog?
It seems there may be some remaining work to be done though:
LoRaModem::setPort
to the "LoraSendAndReceive" exampleLoRaModem::setPort
in the library reference (it seems the current approach is to reuse the "MKRWAN" library's reference, the source of which is here)LoRaModem::portToJoin
member variable?Do you agree?
Thanks for the follow-up. Using modem.setPort(3)
does indeed do the trick and I get data on the receiving end again.
Still, I couldn't find any information on why exactly this is necessary and what it actually does?
Check my post above and the link to the description of the port field.
After updating the library and the FW accordingly, the receiving side (TTN) only gets empty messages. This is true for confirmed and for unconfirmed messages. OTAA join works, though.
I was using the old FW and MKRWAN1 before and the same code did work. I even have a serial debug output which clearly shows that the message is not actually empty:
Sending: d=8190,v=1.31,w=B - 64 3D 38 31 39 30 2C 76 3D 31 2E 33 31 2C 77 3D 42
This is the relevant code: