Downlink not working?

Question

Downlink not working?

Closed this issue 7 years ago · 22 comments

I tried the code on my Nexus with my Lorank8 Gateway and connected it to TTN network.
In TTN device window i see the Test = 0x00 data in the uplink payload. Sending a downlink byte 0x01 via TTN device window does not result in Test = 0x01. So it seems the downlink does not work.

Answer 1 · 2016-07-31T17:40:32.000Z

I checked on the lorank8 gateway if the packet from TTN is forwared to the Nexus. It seems yes, see gateway log below.

2016-07-31 17:37:52 GMT

[UPSTREAM]

RF packets received by concentrator: 2

CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%

RF packets forwarded: 2 (28 bytes)

PUSH_DATA datagrams sent: 6 (1434 bytes)

PUSH_DATA acknowledged: 100.00%

[DOWNSTREAM]

PULL_DATA sent: 6 (100.00% acknowledged)

PULL_RESP(onse) datagrams received: 1 (160 bytes)

RF packets sent to concentrator: 1 (14 bytes)

TX errors: 0

Answer 2 · 2016-07-31T18:37:01.000Z

Hi Cyberman,

We'll have a look into it.

What Nexus code release did you use to test with?

Best regards,

Bart Hiddink
Ideetron b.v.

Cyberman schreef op 2016-07-31 19:40:

I check on the lorank8 Gateway if the packet from TTN is sent, it
seems yes, see gateway log below.
It seems the Nexus does not receive it, or the code has a bug?

2016-07-31 17:37:52 GMT

[UPSTREAM]

RF PACKETS RECEIVED BY CONCENTRATOR: 2

CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%

RF PACKETS FORWARDED: 2 (28 BYTES)

PUSH_DATA DATAGRAMS SENT: 6 (1434 BYTES)

PUSH_DATA ACKNOWLEDGED: 100.00%

[DOWNSTREAM]

PULL_DATA SENT: 6 (100.00% ACKNOWLEDGED)

PULL_RESP(ONSE) DATAGRAMS RECEIVED: 1 (160 BYTES)

RF PACKETS SENT TO CONCENTRATOR: 1 (14 BYTES)

TX ERRORS: 0

You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub [1], or mute the
thread [2].

Links:

[1]
#5 (comment)
[2]
https://github.com/notifications/unsubscribe-auth/ANs_Ylfn5BMwBpb9EFa2c2j8PflI03umks5qbN4QgaJpZM4JZE_5

Answer 3 · 2016-07-31T18:45:12.000Z

This one:
https://github.com/Ideetron/RFM95W_Nexus/tree/master/LoRaWAN_V31

Answer 4 · 2016-07-31T18:51:53.000Z

Ok I will have Gerben look into it tomorrow.
Br. Bart
Verzonden vanaf mijn Samsung Galaxy-smartphone.
-------- Oorspronkelijk bericht --------Van: Cyberman notifications@github.com Datum: 31-07-16 20:45 (GMT+01:00) Aan: Ideetron/RFM95W_Nexus RFM95W_Nexus@noreply.github.com Cc: Bart Hiddink bart@ideetron.nl, Comment comment@noreply.github.com Onderwerp: Re: [Ideetron/RFM95W_Nexus] Downlink not working? (#5)
This one:

https://github.com/Ideetron/RFM95W_Nexus/tree/master/LoRaWAN_V31

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Answer 5 · 2016-08-01T22:08:43.000Z

Meanwhile i tried with my Lorank8 gateway set to Loriot.io cloud, instead TTN.
Same result: i see the incoming and outgoing payload on the Loriot.io output log, but the Nexus running the code from this repository does not loop the payload back.

I am not sure what's going wrong here:

a) bug in this code, or
b) Nexus is broken (is a brand new one, this is my first test receiving data with it), or
c) some issue with the Lorank8 gateway.

Hints how to further debug this are warmly welcome.

Answer 6 · 2016-08-02T07:07:40.000Z

Hello Cyberman,

Thank you for testing with Loriot.
This rules out TTN as the problem.

Please login to your Lorank8 by typing the IP address into your browser.
Goto Logs and get the last 50 lines.

You should be able to see a passage like this one:

Aug 2 06:51:14 lorank8 lorank8v1[530]: ### [UPSTREAM] ###
Aug 2 06:51:14 lorank8 lorank8v1[530]: # RF packets received by
concentrator: 3
Aug 2 06:51:14 lorank8 lorank8v1[530]: # CRC_OK: 100.00%, CRC_FAIL:
0.00%, NO_CRC: 0.00%
Aug 2 06:51:14 lorank8 lorank8v1[530]: # RF packets forwarded: 3 (45
bytes)
Aug 2 06:51:14 lorank8 lorank8v1[530]: # PUSH_DATA datagrams sent: 12
(2673 bytes)
Aug 2 06:51:14 lorank8 lorank8v1[530]: # PUSH_DATA acknowledged: 58.33%
Aug 2 06:51:14 lorank8 lorank8v1[530]: ### [DOWNSTREAM] ###
Aug 2 06:51:14 lorank8 lorank8v1[530]: # PULL_DATA sent: 9 (33.33%
acknowledged)
Aug 2 06:51:14 lorank8 lorank8v1[530]: # PULL_RESP(onse) datagrams
received: 2 (348 bytes)
Aug 2 06:51:14 lorank8 lorank8v1[530]: # RF packets sent to
concentrator: 2 (24 bytes)
Aug 2 06:51:14 lorank8 lorank8v1[530]: # TX errors: 0

Never mind the date and time.
Focus on the the part under DOWNSTREAM.
Here it says that 2 packets are transmitted from the Lorank with no
errors.

Please have a look into your logs and tell me what you see there.

Br, Bart

Cyberman schreef op 2016-08-02 00:08:

Meanwhile i tried with my Lorank8 gateway set to Loriot.io cloud,
instead TTN.
Same result: i see the incoming and outgoing payload on the Loriot.io
output log, but the Nexus running the code from this repository does
not loop the payload back.

I am not sure what's going wrong here:

a) bug in this code, or
b) Nexus is broken (is a brand new one, this is my first test
receiving data with it), or
c) some issue with the Lorank8 gateway.

Hints how to further debug this are warmly welcome.

You are receiving this because you commented.
Reply to this email directly, view it on GitHub [1], or mute the
thread [2].

Links:

[1]
#5 (comment)
[2]
https://github.com/notifications/unsubscribe-auth/ANs_Yqnlnm2iEfxNzEOrfcp4AR0u8NDmks5qbm5sgaJpZM4JZE_5

Answer 7 · 2016-08-02T08:05:31.000Z

I will check this soon and post results hier.

Meanwhile i figured out that LoRaWAN Standard in Spec 1.0 says in Chapter 7 for the downlink settings in Europe:

"The RX2 receive window uses a fixed frequency and data rate. The default parameters are
15 869.525 MHz / DR0 (SF12, 125 kHz)"

Maybe Nexus ist listening with SF9, as coded here, and Lorank8 Gateway ist talking with SF12?

Answer 8 · 2016-08-02T08:16:36.000Z

ok.

The Donwlink is on 869.525 MHz, 125 kHz BW and SF9.

Cyberman schreef op 2016-08-02 10:05:

I will check this soon and post results hier.

Meanwhile i figured out that LoRaWAN Standard in Spec 1.0 says in
Chapter 7 for the downlink settings in Europe:

"The RX2 receive window uses a fixed frequency and data rate. The
default parameters are
15 869.525 MHz / DR0 (SF12, 125 kHz)"

Maybe Nexus ist listening with SF9, as coded here, and Lorank8 Gateway
ist talking with SF12?

You are receiving this because you commented.
Reply to this email directly, view it on GitHub [1], or mute the
thread [2].

Links:

[1]
#5 (comment)
[2]
https://github.com/notifications/unsubscribe-auth/ANs_YvIZ2sYr8o1etlMN0USrKXPmG1s1ks5qbvpMgaJpZM4JZE_5

Answer 9 · 2016-08-02T09:01:50.000Z

I checked my router logs and did a packet-log with Semtech utility packet logger.
Lorank log says downlink traffic was delivered.
But in the packet log i see only uplink traffic from my Nexus, running the code from this repository, so sending with SF11BW125.

Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [up] PUSH_ACK for server router.eu.thethings.network received in 43 ms
Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [down] for server iot.semtech.com PULL_ACK received in 55 ms
Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [down] for server router.eu.thethings.network PULL_ACK received in 40 ms
Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [down] for server iot.semtech.com PULL_ACK received in 52 ms
Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [down] for server router.eu.thethings.network PULL_ACK received in 41 ms
Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [up] PUSH_ACK for server router.eu.thethings.network received in 43 ms
Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [down] for server router.eu.thethings.network serv_addr[ic]PULL_RESP received :)
Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [down] a packet will be sent on timestamp value 369733603
Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [down] for server iot.semtech.com PULL_ACK received in 54 ms
Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [down] for server router.eu.thethings.network PULL_ACK received in 41 ms
Aug 2 10:52:30 lorank8 lorank8v1[534]: ##### 2016-08-02 08:52:00 GMT #####
Aug 2 10:52:30 lorank8 lorank8v1[534]: ### [UPSTREAM] ###
Aug 2 10:52:30 lorank8 lorank8v1[534]: # RF packets received by concentrator: 1
Aug 2 10:52:30 lorank8 lorank8v1[534]: # CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
Aug 2 10:52:30 lorank8 lorank8v1[534]: # RF packets forwarded: 1 (27 bytes)
Aug 2 10:52:30 lorank8 lorank8v1[534]: # PUSH_DATA datagrams sent: 4 (922 bytes)
Aug 2 10:52:30 lorank8 lorank8v1[534]: # PUSH_DATA acknowledged: 50.00%
Aug 2 10:52:30 lorank8 lorank8v1[534]: ### [DOWNSTREAM] ###
Aug 2 10:52:30 lorank8 lorank8v1[534]: # PULL_DATA sent: 6 (100.00% acknowledged)
Aug 2 10:52:30 lorank8 lorank8v1[534]: # PULL_RESP(onse) datagrams received: 1 (180 bytes)
Aug 2 10:52:30 lorank8 lorank8v1[534]: # RF packets sent to concentrator: 1 (30 bytes)
Aug 2 10:52:30 lorank8 lorank8v1[534]: # TX errors: 0
Aug 2 10:52:30 lorank8 lorank8v1[534]: ### [GPS] ###
Aug 2 10:52:30 lorank8 lorank8v1[534]: # GPS sync is disabled
Aug 2 10:52:30 lorank8 lorank8v1[534]: ##### END #####

"gateway ID","node MAC","UTC timestamp","us count","frequency","RF chain","RX chain","status","size","modulation","bandwidth","datarate","coderate","RSSI","SNR","payload"
"AA555A0000000101","","2016-08-02 08:56:23.844Z", 7615844, 868100000,1, 0,"CRC_OK" , 14,"LORA",125000,"SF11" ,"4/5",-55, +9.0,"402884A9-17001400-0197068E-F3B3"
"AA555A0000000101","","2016-08-02 08:56:47.378Z", 31150140, 868100000,1, 0,"CRC_OK" , 14,"LORA",125000,"SF11" ,"4/5",-53, +7.8,"402884A9-17001600-01741DD7-D0D5"
"AA555A0000000101","","2016-08-02 08:56:59.144Z", 42917292, 868100000,1, 0,"CRC_OK" , 14,"LORA",125000,"SF11" ,"4/5",-47, +8.2,"402884A9-17001700-01E5290D-F504"
"AA555A0000000101","","2016-08-02 08:57:10.903Z", 54675612, 868500000,1, 2,"CRC_BAD", 14,"LORA",125000,"SF11" ,"4/5",-98,-16.2,"4A28ED92-5F1C0666-690CFDAA-4EAD"
"AA555A0000000101","","2016-08-02 08:57:10.910Z", 54684460, 868100000,1, 0,"CRC_OK" , 14,"LORA",125000,"SF11" ,"4/5",-53, +7.5,"402884A9-17001800-018A5DE9-8FC7"
"AA555A0000000101","","2016-08-02 08:57:22.678Z", 66451604, 868100000,1, 0,"CRC_OK" , 14,"LORA",125000,"SF11" ,"4/5",-47, +8.8,"402884A9-17001900-0165F9B7-A8E5"
"AA555A0000000101","","2016-08-02 08:57:34.445Z", 78218756, 868100000,1, 0,"CRC_OK" , 14,"LORA",125000,"SF11" ,"4/5",-54, +8.5,"402884A9-17001A00-014764D1-B4B3"
"AA555A0000000101","","2016-08-02 08:57:46.212Z", 89985900, 868100000,1, 0,"CRC_OK" , 14,"LORA",125000,"SF11" ,"4/5",-50, +8.2,"402884A9-17001B00-01706571-2E06"
"AA555A0000000101","","2016-08-02 08:57:57.981Z", 101753052, 868100000,1, 0,"CRC_OK" , 14,"LORA",125000,"SF11" ,"4/5",-51, +9.2,"402884A9-17001C00-011F726F-9B63"

Answer 10 · 2016-08-02T09:32:17.000Z

Alternative try with Loriot.io, changed gateway plan to RX2_SF9, again - no reception.
It seems the Nexus misses the reception window. Or ist it a hardware or gateway problem?

000000001919BC11 2.8.2016, 11:28:40 868.100 SF7 BW125 4/5 -43 9 29 1 00
000000001919BC11 2.8.2016, 11:28:28 868.100 SF7 BW125 4/5 -42 9.8 28 1 00
000000001919BC11 2.8.2016, 11:28:16 868.100 SF7 BW125 4/5 -41 8.5 27 1 00
000000001919BC11 11:28:05 23 (enqued data sent)
000000001919BC11 2.8.2016, 11:28:05 868.100 SF7 BW125 4/5 -43 9.5 26 1 00
000000001919BC11 33(enqueued for sending)
000000001919BC11 2.8.2016, 11:27:53 868.100 SF7 BW125 4/5 -43 9.2 25 1 00

Answer 11 · 2016-08-02T09:44:30.000Z

Everything looks good from these files.
However it doesn't explain why the Nexus doesn't receive the data back.

What data do you send back to the Nexus (downstream)?
And how do you observe that it didn't receive it?

Cyberman schreef op 2016-08-02 11:01:

I checked my router logs and did a packet-log with Semtech utility
packet logger.
Lorank log says downlink traffic was delivered.
But in the packet log i see only uplink traffic from my Nexus, running
the code from this repository, so sending with SF11BW125.

Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [up] PUSH_ACK for server
router.eu.thethings.network received in 43 ms
Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [down] for server
iot.semtech.com PULL_ACK received in 55 ms
Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [down] for server
router.eu.thethings.network PULL_ACK received in 40 ms
Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [down] for server
iot.semtech.com PULL_ACK received in 52 ms
Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [down] for server
router.eu.thethings.network PULL_ACK received in 41 ms
Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [up] PUSH_ACK for server
router.eu.thethings.network received in 43 ms
Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [down] for server
router.eu.thethings.network serv_addr[ic]PULL_RESP received :)
Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [down] a packet will be
sent on timestamp value 369733603
Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [down] for server
iot.semtech.com PULL_ACK received in 54 ms
Aug 2 10:52:30 lorank8 lorank8v1[534]: INFO: [down] for server
router.eu.thethings.network PULL_ACK received in 41 ms
Aug 2 10:52:30 lorank8 lorank8v1[534]: ##### 2016-08-02 08:52:00 GMT

Aug 2 10:52:30 lorank8 lorank8v1[534]: ### [UPSTREAM] ###
Aug 2 10:52:30 lorank8 lorank8v1[534]: # RF packets received by
concentrator: 1
Aug 2 10:52:30 lorank8 lorank8v1[534]: # CRC_OK: 100.00%, CRC_FAIL:
0.00%, NO_CRC: 0.00%
Aug 2 10:52:30 lorank8 lorank8v1[534]: # RF packets forwarded: 1 (27
bytes)
Aug 2 10:52:30 lorank8 lorank8v1[534]: # PUSH_DATA datagrams sent: 4
(922 bytes)
Aug 2 10:52:30 lorank8 lorank8v1[534]: # PUSH_DATA acknowledged:
50.00%
Aug 2 10:52:30 lorank8 lorank8v1[534]: ### [DOWNSTREAM] ###
Aug 2 10:52:30 lorank8 lorank8v1[534]: # PULL_DATA sent: 6 (100.00%
acknowledged)
Aug 2 10:52:30 lorank8 lorank8v1[534]: # PULL_RESP(onse) datagrams
received: 1 (180 bytes)
Aug 2 10:52:30 lorank8 lorank8v1[534]: # RF packets sent to
concentrator: 1 (30 bytes)
Aug 2 10:52:30 lorank8 lorank8v1[534]: # TX errors: 0
Aug 2 10:52:30 lorank8 lorank8v1[534]: ### [GPS] ###
Aug 2 10:52:30 lorank8 lorank8v1[534]: # GPS sync is disabled

Aug 2 10:52:30 lorank8 lorank8v1[534]: ##### END

"gateway ID","node MAC","UTC timestamp","us count","frequency","RF
chain","RX
chain","status","size","modulation","bandwidth","datarate","coderate","RSSI","SNR","payload"
"AA555A0000000101","","2016-08-02 08:56:23.844Z", 7615844,
868100000,1, 0,"CRC_OK" , 14,"LORA",125000,"SF11" ,"4/5",-55,
+9.0,"402884A9-17001400-0197068E-F3B3"
"AA555A0000000101","","2016-08-02 08:56:47.378Z", 31150140,
868100000,1, 0,"CRC_OK" , 14,"LORA",125000,"SF11" ,"4/5",-53,
+7.8,"402884A9-17001600-01741DD7-D0D5"
"AA555A0000000101","","2016-08-02 08:56:59.144Z", 42917292,
868100000,1, 0,"CRC_OK" , 14,"LORA",125000,"SF11" ,"4/5",-47,
+8.2,"402884A9-17001700-01E5290D-F504"
"AA555A0000000101","","2016-08-02 08:57:10.903Z", 54675612,
868500000,1, 2,"CRC_BAD", 14,"LORA",125000,"SF11"
,"4/5",-98,-16.2,"4A28ED92-5F1C0666-690CFDAA-4EAD"
"AA555A0000000101","","2016-08-02 08:57:10.910Z", 54684460,
868100000,1, 0,"CRC_OK" , 14,"LORA",125000,"SF11" ,"4/5",-53,
+7.5,"402884A9-17001800-018A5DE9-8FC7"
"AA555A0000000101","","2016-08-02 08:57:22.678Z", 66451604,
868100000,1, 0,"CRC_OK" , 14,"LORA",125000,"SF11" ,"4/5",-47,
+8.8,"402884A9-17001900-0165F9B7-A8E5"
"AA555A0000000101","","2016-08-02 08:57:34.445Z", 78218756,
868100000,1, 0,"CRC_OK" , 14,"LORA",125000,"SF11" ,"4/5",-54,
+8.5,"402884A9-17001A00-014764D1-B4B3"
"AA555A0000000101","","2016-08-02 08:57:46.212Z", 89985900,
868100000,1, 0,"CRC_OK" , 14,"LORA",125000,"SF11" ,"4/5",-50,
+8.2,"402884A9-17001B00-01706571-2E06"
"AA555A0000000101","","2016-08-02 08:57:57.981Z", 101753052,
868100000,1, 0,"CRC_OK" , 14,"LORA",125000,"SF11" ,"4/5",-51,
+9.2,"402884A9-17001C00-011F726F-9B63"

You are receiving this because you commented.
Reply to this email directly, view it on GitHub [1], or mute the
thread [2].

Links:

[1]
#5 (comment)
[2]
https://github.com/notifications/unsubscribe-auth/ANs_YraUiwkcPF8-swoTMu14XU5-mywbks5qbwd_gaJpZM4JZE_5

Answer 12 · 2016-08-02T10:06:21.000Z

I think you should focus on the Nexus software.
The service and the Gateway seem fine.
If the RF chip on the Nexus is sending packets, it should also be able
to receive packets.
Do you have any means of measuring the output of the Gateway like an RF
detector?

I can't reproduce the tests here at the moment because we are all out of
Nexus boards.

Cyberman schreef op 2016-08-02 11:32:

Alternative try with Loriot.io, changed gateway plan to RX2_SF9, again

no reception.
It seems the Nexus misses the reception window. Or ist it a hardware
or gateway problem?

000000001919BC11 2.8.2016, 11:28:40 868.100 SF7 BW125 4/5 -43 9 29 1
00
000000001919BC11 2.8.2016, 11:28:28 868.100 SF7 BW125 4/5 -42 9.8 28 1
00
000000001919BC11 2.8.2016, 11:28:16 868.100 SF7 BW125 4/5 -41 8.5 27 1
00
000000001919BC11 11:28:05 23 (enqued data sent)
000000001919BC11 2.8.2016, 11:28:05 868.100 SF7 BW125 4/5 -43 9.5 26 1
00
000000001919BC11 33(enqueued for sending)
000000001919BC11 2.8.2016, 11:27:53 868.100 SF7 BW125 4/5 -43 9.2 25 1
00

You are receiving this because you commented.
Reply to this email directly, view it on GitHub [1], or mute the
thread [2].

Links:

[1]
#5 (comment)
[2]
https://github.com/notifications/unsubscribe-auth/ANs_YneKDk7Kfc-3R_yQslysUdbPIB5mks5qbw6hgaJpZM4JZE_5

Answer 13 · 2016-08-02T10:37:12.000Z

For testing the reception i just run this code on the Nexus, nothing else, no modifications.

As far as i understand the code, it sends a payload byte "0x00" from the Nexus to the gateway/cloud and then listenes for an answer. If there is an answer, it takes the payload from the answer and sends it back with the next package. So it is a simple loop test and should work with every cloud. But it doesn't, either with TTN nor with Loriot.

I assume that there is a bug in the receiver settings of this code, e.g. the timing goes wrong and the Nexus just misses the RX2 downlink reception window, or any other setting of a RFM95 register is not compliant with the LoRaWAN specs.

I have no measuring equipment to check the RF 868 MHz of the Nexus on layer1. My Rigol digiscope has only 100 MHz.

Answer 14 · 2016-08-02T11:26:31.000Z

ok.
Gerben did not test this function because of the lack of reliable
back-end in those days the program was written.
The only way for us to support you is to reproduce this setup and solve
the problem.
I have to look for a spare Nexus that works.
Please give us some time to find out what is wrong.
In the meantime please feel free to adjust the Nexus code any way you
like.

Cyberman schreef op 2016-08-02 12:37:

For testing the reception i just run this code on the Nexus, nothing
else, no modifications.

As far as i understand the code, it sends a payload byte "0x00" from
the Nexus to the gateway/cloud and then listenes for an answer. If
there is an answer, it takes the payload from the answer and sends it
back with the next package. So it is a simple loop test and should
work with every cloud. But it doesn't, either with TTN nor with
Loriot.

I assume that there is a bug in the receiver settings of this code,
e.g. the timing goes wrong and the Nexus just misses the RX2 downlink
reception window, or any other setting of a RFM95 register is not
compliant with the LoRaWAN specs.

I have no measuring equipment to check the RF 868 MHz of the Nexus on
layer1. My Rigol digiscope has only 100 MHz.

You are receiving this because you commented.
Reply to this email directly, view it on GitHub [1], or mute the
thread [2].

Links:

[1]
#5 (comment)
[2]
https://github.com/notifications/unsubscribe-auth/ANs_Yi0BITWZ1fVuMXrPcOm9-hRici9Nks5qbx3ZgaJpZM4JZE_5

Answer 15 · 2016-08-02T19:29:50.000Z

I will keep my hands on this issue, because I think it is just a little bug, maybe in one of the register settings for the HopeRFM95 or something in the receive window timing section of the code. Comments on how to debug this welcome.

Answer 16 · 2016-08-02T19:57:41.000Z

I didnt try this on a Nexus, but there is also lmic based on the code of Thomas Matthijs en Gerben over here:
https://github.com/things4u/LoRa-LMIC-1.51/blob/master/README.md

Answer 17 · 2016-08-03T07:18:17.000Z

If it is a timing problem you can debug this by setting the RxTime out window larger. Register 0x1F of the radio module. See RFM95_V21.cpp line 89. This is the time te radiomodule will search for an preamble on the channel. The start of this period can be changed by adjusting the Receive_delay_2 variable in LoRaMAC_V11.cpp line 82.

For example you can start by setting the rx time out window very large and set the delay to 0. Then you can check if you receive anything and then adjusting it and making it smaller etc...

Answer 18 · 2016-08-06T15:22:30.000Z

Meanwhile i changed my code from this LoRaWAN stack to the LMIC stack by IBM. I used the LMIC arduino port by Matthijs Kooijman for this and now the downlink is working! So, the hardware ist okay.

Because this fills nearly the whole memory of Nexus ATMega328p, i also tried to use the smaller LMIC port by M. Westenberg for ATmega238. But as seen with the Ideetron stack i could not get a downlink with this port. Since this port uses parts of the code from the Ideetron stack, i suppose that indeed there must be a bug somewhere in the Ideetron stack.

Answer 19 · 2016-12-02T14:42:22.000Z

Hi there,

Same issue here.
Had success connecting to TTN but no downlink.
I'm a bit lost here but meanwhile i found that on RFM_Receive()
the RX2 receive window is configured for SF9. Shouldn't be SF12 as it is refered on Lorawan_regional_parameters (2.1.7) ?

Any news on this?

Answer 20 · 2016-12-02T14:46:51.000Z

Oh found out now that ttn defines SF9 for RX2.

Still stuck anyway...

Answer 21 · 2016-12-07T15:02:59.000Z

Hi,

after doing some testing downlink is now working.

just need to adjust register 0x1F to 0xE0 extending rx time out window. Receive_Delay_2 was left untouched.

Thank you.

Answer 22 · 2017-06-25T21:05:38.000Z

Also got the downlink to work on my nexus - over the things network - but with a slightly different solution. I only changed the Receive_Delay_2 to 9 (which actually listens on the RX slot 1). Apparently, the gateway sending the downlink was sending the data in RX window 1 (which has a delay of 1s) instead of 2 (which has a delay of 2s).

Looking at the TTN frequency plans they seem to have specified sending the downlink in the RX1 window (with one exception): https://www.thethingsnetwork.org/wiki/LoRaWAN/Frequencies/Frequency-Plans#lorawan-frequencies_eu-863-870mhz. Apparently this has recently been changed: https://www.thethingsnetwork.org/forum/t/downlink-freq-rx2-869-525/7144

A more robust solution would be adjust the code to listen to both RX1 and RX2. I'm guessing the TTN gateways in the field are sending downlinks in both RX1 and RX2 depending on the forwarding software they are running (old vs new).