RAK811 Lora Module Connecting to TTN

1

Hello everyone, I use RAK811 Lora Module Connecting to TTN met a problem is:

Who can tell me how to solve this problem?

2

@twy: I don’t get what’s the problem exactly. You link to a completely different issue for a totally different module. I tried the RAK811 and it works without issues to connect to TTN. I don’t remember if I tried confirmed uplinks explicitly, but I tried downlinks for sure.

4

Yes, it is different module, but both use the loraWAN stack. I just mean there is a problem when I send a uplink confirmed data , noramlly the relay server need ack the module with empty unconfirmed downlink data on port 0, but now there recieve on port 2 (application port). So module return a recieved empty unconfirm downlink data event to user . I think it is not suitable here.

5

But the issue you link to is closed and in the comments it says that a solution is already implemented. Is it still occurring?

6

Yes, it still occurring. And I see the data logger display the unconfirmed data sent on port 0 ,but RAK811 module recieved the data is sent from port 2. check the attachment please.

7

Just to be sure: data is not sent “from” a port. (It’s sent using some frequency and spreading factor, and it defines data and a port to be used by the application. Gateways don’t care about that.) As such, the device is also not listening on some specific port, but only on some frequency and spreading factor. (In RX1, it’s listening on whatever it has transmitted on; for RX 2 it should be listening on 869.525 SF9.)

That said, I don’t know which port is to be expected for an ACK. (Even more, maybe empty ACKs that don’t also include any application data at the very same time, don’t even specify a port, and is it just the GUI that’s wrong?)

If the error still occurs then you should comment in the GitHub issue. But then please provide clear details; I don’t understand why you think it’s still an issue.

For me, OTAA just works fine; for you it seems the node keep sending the OTAA Join Request, so apparently does not receive or process the Join Accept. If it’s your own gateway then looking at the gateway’s “traffic” in TTN Console might help debugging.

8

Hello arjanvanb

  1. Yes, I just mean send on application level.

  2. How do you think it should ACK on port 0 or 2(send confirmed uplink data port), I see the GUI display 0 mean it ACK empty unconfirmed downlink data on port 0, but module recieve the downlink data, there app payload feild port number is 2,
    please help to check.

  3. For me ,join otaa is also works fine.

9

My bad, I didn’t realize your node actually did an uplink after each OTAA. Still then, unrelated to your questions, please do not do an OTAA for every uplink:

That said, sorry, I don’t understand your other points.

10

Hello arjanvanb

Follows pictures log, show the RAK join OTAA and send confirmed uplink data success to Actility platform . UnconfirmedDataDown ack port 0 is OK. if the UnconfirmedDataDown not from port 0, RAK811 module will consider it is user’s application data , and notify the at+recv=0,2,0 , but data len is 0 seems not good.

11

Hi, for this do many times OTAA it is because the rx2 piont our default datarate is SF12 , after setting the SF9 , it seems fine now…

12

Correct, I think. But: your screenshots show the downlink ACK is using port 0?

That sounds good to me, as your screenshot also shows it’s only a DevStatusReq MAC command, without any application data:

4.3.2 Port field (FPort)

If the frame payload field is not empty, the port field must be present. If present, an FPort value of 0 indicates that the FRMPayload contains MAC commands only; see Chapter 4.4 for a list of valid MAC commands. FPort values 1…223 (0x01…0xDF) are application-specific.

Now, I don’t know if a DevStatusReq is to be expected… (Maybe related to ADR?)

Is your gateway registered in TTN Console? If yes: what does the gateway claim is the content of the downlink? (See the “traffic” page for the gateway, on which you can get the binary data.)

The OTAA Join Accept will tell your node that it should use SF9 for RX2, not SF12. If the module is using SF12 in RX2, then the module is doing something wrong. If it uses an RN2483: you need at least firmware version 1.0.1.

However, it seems the ACK is received in RX1? If true, then that uses the same frequency and SF that was used in the uplink. Your screenshot shows the uplink is using SF12. So: all fine, if received in RX1.

Are you developing that RAK811 module? Then maybe you need to get in touch with TTN for commercial support. They’ll also understand the specifications much better.

13

OK , I will check the binary data, but from module side , it is truely recieved the UnconfirmedDataDown ACK from port 2.

14

Then how do you explain the Port 0 in TTN Console and FPort 0 in your own tool (“actility logger”?), in both your very own screenshots…?

Argh, you’re showing screenshots from Actility. I’m out of here, success.

If you’ve got the raw packet, you can decode it online.

By the way: I hope you’re only using a single backend? (Only The Things Network, not also some other party that is trying to send downlinks for the same device?)

15

Okay, you’re right. But I really find it very hard to get that information from the posts above…

I see the following in the gateway traffic:

This has the payload YDoUASYgAwACKg+UqA== for which decoding shows:

Message Type = Data
  PHYPayload = 603A140126200300022A0F94A8

( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
        MHDR = 60
  MACPayload = 3A14012620030002
         MIC = 2A0F94A8

( MACPayload = FHDR | FPort | FRMPayload )
        FHDR = 3A140126200300
       FPort = 02
  FRMPayload = 

      ( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] )
     DevAddr = 2601143A (Big Endian)
       FCtrl = 20
        FCnt = 0003 (Big Endian)
       FOpts = 

Message Type = Unconfirmed Data Down
   Direction = down
        FCnt = 3
   FCtrl.ACK = true
   FCtrl.ADR = false

So, the above (probably erroneously) includes:

FPort = 02

However, for the device TTN Console (erroneously) shows the very same payload is using port 0:

And like mentioned before, it should probably indeed use port 0 instead, as it’s only a DevStatusReq MAC command, without any application data:

4.3.2 Port field (FPort)

If the frame payload field is not empty, the port field must be present. If present, an FPort value of 0 indicates that the FRMPayload contains MAC commands only; see Chapter 4.4 for a list of valid MAC commands. FPort values 1…223 (0x01…0xDF) are application-specific.

I’ve created an issue on GitHub.

16

OK Thanks for your great support !:slight_smile:

17

hi @gonzalo did u use the rak811 wiskey (shield) with arduino?

18

Hi @Baxter! The initial version of the shield had an issue when used as shield. There’s an extra little connector needed to fix the routing of power lines. I have a couple of those (the shield + the connector) if you need

cheers

1 Like
20

Hi,
i add RAK811 to my fork of Lora-net/LoRaMac-node.
Now only to CLASS_B branch.
Power and only USART1 (w/o any messages).
Later order PCB with GPS, sensors, solar controller etc. to implement extra small animals tracker.
Modules available on aliexpress.com
(i’m not a seller)

1 Like