Vraag

Downlink test message or ACK not received by node

  • 19 June 2017
  • 18 reacties
  • 2316 keer bekeken

At this moment I have my Seeeduino node operational with ABP and am able to successfully sent from my current location GPS data with SF9 to my application.

My next step is to receive messages (and confirmations) over the air.
Unfortunately I am not able te recive one of these.
I get no ACk when I sent a confirmed message or receive a datapacket sent by the developers portal.
As with I can not get a connection with SF8 my question is if I need to find a better spot for reception?

18 reacties

Reputatie 3
Badge +1
I don't know how good the acknowledgement communication is working right now. Most of the times I don't receive an acknowledgement for my ABP messages.

First you have to send a (downlink) message from the developer portal or your application server to your LoRa device. After that, to receive the message on your LoRa device, you first have to send a (uplink) message. Right after you send a message from your LoRa device it will listen for a short period if there are messages for the device. When you are able to send messages, I guess you should also be able to receive messages.

If you got this right and still need help, then you have to give more details of what you did/ tried.
Hi Jeroen, this is exactly what I did.
The RX1 delay is set to 1000ms and the time-out is set to 10secs.
I also diregarded the libraries as I found out dureing my struggle with this board that they are incomplete.

So for so far I can see I did everything correct.
To my knowledge the ACK is transmitted at SF9, with this SF I can reach a Gateway.
Reputatie 7
Badge +6
Hi @jawove,

I am wondering if you have made any progress yet?

Off course I would like to help you with this issue. To make sure that I give you the right instructions I will discuss this with the specialists. Meanwhile, perhaps @Jeroen10 has also so more tips for you?

When I have discussed this with the specialists, I will inform you right away 😉
Hi Rick,

unfortunately not.
It seems that the documentation on the Seeed LoRaWAN module is killing me again (so much for Chinese products) making it almost impossible to find the root cause of the problem of not being able to receive either confitmed message or a downlink message I will try to do succeed with an other device like the HopeRF (yes I know Chinese) or a Raduino a reltively new device also using the Semtech chip.

I'll keep you informed on my progress.

As it seems not
Reputatie 7
Badge +6
Hi @jawove

It's been a while that we spoke, but here I am again.
Since our last contact I discussed the issue with our specialists. This week I provided additional information about your registered device and now the specialists are trying to find the solution.

Furthermore, I am very curious whether the the test with the HopeRF device has been successful?
@jawove could you please provide details from the sketch or the sketch itself related to GPS data retrieval and sending? Seeedstudio wiki doesn't indicate how to perform it so I'm struggling at doing it for my seeeduino lorawan node.

Thanks!
Hi kalon33, sorry for the delay.
TinyGPS is the solution to go for (at least for me)
Reputatie 1
Badge +1
A question for KPN along the same line, @Rick S.: is a downlink message always sent in RX1 and RX2, or does the network choose one of these two?
I seem to always get a timeout in RX1 and always a succesful reception in RX2, but I am wondering if this is a network feature, or an error in my software! 😉
Reputatie 7
Badge +6
Hi @rharte,

It is correct that you can't send a downlink message in RX1. The RX2 channel on 869.525 MHz is specifically used for downlinks. So in a way the network chooses which channel is used ☺️
Reputatie 1
Badge +1
@Rick S. thanks for your answer, but I don't quite get it...... @michieljol writes in this thread > https://zakelijkforum.kpn.com/lora-forum-16/downlink-berichten-verstuurd-op-channel-lc127-8441

"Overigens hebben we ook bij andere klanten gezien dat er problemen kunnen ontstaan wanneer downlink via RX2/LC127 wordt verstuurd. Beste is natuurlijk hier niet in terecht te komen en gewoon het eerste receive window te gebruiken. "

This suggests that a mobile device should always listen for (and expect to receive) a downlink message in RX1. This seems to be in contradiction with your answer!?
Reputatie 7
Badge +6
Hi @rharte,

I can understand your confusion. I'm now starting to doubt which is the correct answer too.
In addition, when I read my answer I want to adjust it a little bit. The fact that RX2 is specifically used for downlinks doesn't have to mean that you can't send downlinks in RX1.

Just to be sure I will discuss this with the specialists, so there can't be any doubts about this 😉
Reputatie 1
Badge +1
Yes @Rick S. that would be great! My software first listens in RX1 for a downlink reply, then in RX2, and I find that there is never anything received in RX1, and always a succesful reception in RX2. So I am in doubt if the network does not send anything in RX1, or my software is just faulty.... 😅
I am observing the following parameters:
RX1: delay 1 sec, frequency same as TX-frequency, sending and receiving on SF12
RX2: delay 2 sec, frequency 869.525 MHz, sending and receiving on SF12
(I am sending and receiving on SF12 to prevent any misinterpretation/effect of the parameter RX1DROffset).
Reputatie 7
Badge +6
In the meantime i spoke the specialists about the channels RX1 and RX2. The network decides in what channel the downlink is sent. Normally, this is RX1. But when a gateway has a heavy load for example, the network can decide to sent the message through another path.

Now it may also be, in your case, of your module settings. For some devices, for example, RX2 receives default on SF9.
Reputatie 7
Badge +6
Following my last reply, when you are sending and receiving on SF12 the network will never sent the downlink message in RX1. In this situation, you can also decide to use ADR 😉
Reputatie 1
Badge +1
Hi @Rick S., thank you for your quick reply! So do I understand correct that the network chooses to send in RX1 OR RX2, but not in both?

The other thing you are saying about receiving default on SF9 in RX2 must be incorrect: this is in contradiction with the LoraWan standard, that says that the RX2 datarate is always SF12. And the datarate in RX1 is governed by the parameter RX1DROffset that gives the relation between the uplink SF and the downlink SF. So a fixed SF will never work neither in RX1 nor in RX2.

We are using a radio module that is fully transparent and is controlled by our own LoraWan stack implementation, therefore we can see all that is going on on the radio layer and we control what this module is doing.
Reputatie 7
Badge +6
That's correct! The network chooses to send in RX1 or RX2.
Reputatie 1
Badge +1
@Rick S., I wrote my reply before reading your second message! 😀

Now it is all clear to me! Thanks, I am going to do some more testing on other datarates!
Reputatie 7
Badge +6
@rharte That's great! I wish you a lot of fun with testing 😁
If you have any other questions or issues, please let me know!

Reageer