It should be - perhaps posting this issue on the Heltec forum would be good - it will be a couple more days for me to dig out my CubeCell to try it for you.
Thanks for the hint, I have already postet it there, but don’t have a answer yet received.
Aside: I very much dislike people posting the same thing in multiple places, even more so when not providing links to the duplicated posts. Just a waste of people’s time, I feel, unless the poster can guarantee to keep the multiple places synced, 24/7. Which, of course, never happens.
1 Like
Isuue is also posted at http://community.heltec.cn/t/cubecell-dev-board-htcc-ab01-from-heltec-downlink/2591
Sorry for that I was not aware of this. Thanks for the hint.
I am a newbi in LORA and thought that receive a download from TTN using a provider delivered example code must be a simple basic funcion, but nowehre I get a hint what the problem could be. So I thought it is a good idea to post it at TTN and Heltec.
Who do you consider to be the provider? Surely not TTN because TTN would never create sample code with confirmed uplinks. Please switch to unconfirmed uplinks as soon as possible.
When it comes to downlinks, there is no guarantee a downlink will be delivered to the node. There are multiple reasons it can fail. Please switch off the confirmed uplinks and try again. Try a couple of downlinks.
However keep in mind, for development you can use a bit more but regular nodes are limited to 10 downlinks (including acknowledgments for acknowledged uplinks) each day as per TTN fair access policy.
In this case, Heltec - the issue is with their example code and if I get a free moment, I’ll pull my CubeCell out the pile and take it for a spin to see if we are missing something obvious.
Ruedi has been trying for 7 days with only me “helping” so he’s still well karma plus at present.
That is your interpretation of provider, I am still wondering who @Ruedi_68 refers to in his message.
I refer to the sample code I have posted in my Topic as a link to the Gitub repository of Heltec and which I have pasted in addition in my topic as cleartext. So the sample code is from Heltec.
See Topic:
I try to do it by using “Downlink” with dummy data in TTN and run on Cubecell https://github.com/HelTecAutomation/ASR650x-Arduino/tree/master/libraries/LoRa/examples/LoRaWAN/LoRaWan_downlinkdatahandle
My settings:
Yesterdays test from Heltec shows that in general downlink from TTN with Heltec example script should work:
Sorry I haven’t got to trying mine yet but there are some useful ideas to check from Heltec, things I should of thought of earlier.
Do you have access to the gateway logs on the gateway itself?
What we are looking for is the downlink being received by the gateway from TTN and assuming it is arriving, is it in time for the RX2 window. If the network connection is too slow, the device will have stopped listening by the time it arrives to be transmitted.
Thanks for the reply. Unfortunately I donn’t have access to the gateway. But I also use another LORA Device with TTN ( https://github.com/RobPo/PaperiNode ) and whith this one download is working on same location.
18:30:29.945 -> TX on freq 868500000 Hz at DR 5
18:30:30.045 -> Event : Tx Done
18:30:31.025 -> RX on freq 868500000 Hz at DR 5
18:30:31.058 -> Event : Rx Timeout
18:30:32.070 -> RX on freq 869525000 Hz at DR 0
18:30:32.271 -> Event : Rx Timeout
18:30:45.095 -> unconfirmed uplink sending …
18:30:45.095 -> TX on freq 868100000 Hz at DR 5
18:30:45.161 -> Event : Tx Done
18:30:46.171 -> RX on freq 868100000 Hz at DR 5
18:30:46.204 -> Event : Rx Timeout
18:30:47.186 -> RX on freq 869525000 Hz at DR 0
18:30:47.386 -> Event : Rx Timeout
18:31:00.936 -> unconfirmed uplink sending …
18:31:00.936 -> TX on freq 867700000 Hz at DR 5
18:31:01.030 -> Event : Tx Done
18:31:01.996 -> RX on freq 867700000 Hz at DR 5
18:31:02.030 -> Event : Rx Timeout
18:31:03.040 -> RX on freq 869525000 Hz at DR 0
18:31:03.242 -> Event : Rx Timeout
18:31:16.392 -> unconfirmed uplink sending …
18:31:16.392 -> TX on freq 867300000 Hz at DR 5
18:31:16.459 -> Event : Tx Done
18:31:17.435 -> RX on freq 867300000 Hz at DR 5
18:31:17.468 -> Event : Rx Timeout
18:31:18.515 -> RX on freq 869525000 Hz at DR 0
18:31:18.681 -> Event : Rx Timeout
18:31:31.918 -> unconfirmed uplink sending …
18:31:31.918 -> TX on freq 867100000 Hz at DR 5
18:31:31.984 -> Event : Tx Done
18:31:32.959 -> RX on freq 867100000 Hz at DR 5
18:31:32.993 -> Event : Rx Timeout
18:31:34.001 -> RX on freq 869525000 Hz at DR 0
18:31:34.201 -> Event : Rx Timeout
18:31:47.204 -> unconfirmed uplink sending …
18:31:47.238 -> TX on freq 868300000 Hz at DR 5
18:31:47.306 -> Event : Tx Done
18:31:48.282 -> RX on freq 868300000 Hz at DR 5
18:31:48.317 -> Event : Rx Timeout
18:31:49.336 -> RX on freq 869525000 Hz at DR 0
18:31:49.540 -> Event : Rx Timeout
18:32:03.164 -> unconfirmed uplink sending …
18:32:03.164 -> TX on freq 867700000 Hz at DR 5
18:32:03.233 -> Event : Tx Done
18:32:04.213 -> RX on freq 867700000 Hz at DR 5
18:32:04.247 -> Event : Rx Timeout
18:32:05.261 -> RX on freq 869525000 Hz at DR 0
18:32:05.462 -> Event : Rx Timeout
18:32:18.572 -> unconfirmed uplink sending …
18:32:18.572 -> TX on freq 867300000 Hz at DR 5
18:32:18.640 -> Event : Tx Done
18:32:19.654 -> RX on freq 867300000 Hz at DR 5
18:32:19.654 -> Event : Rx Timeout
18:32:20.692 -> RX on freq 869525000 Hz at DR 0
18:32:20.894 -> Event : Rx Timeout
18:32:33.829 -> unconfirmed uplink sending …
18:32:33.829 -> TX on freq 867100000 Hz at DR 5
18:32:33.897 -> Event : Tx Done
18:32:34.877 -> RX on freq 867100000 Hz at DR 5
18:32:34.910 -> Event : Rx Timeout
18:32:35.927 -> RX on freq 869525000 Hz at DR 0
18:32:36.130 -> Event : Rx Timeout
18:32:48.972 -> unconfirmed uplink sending …
18:32:48.972 -> TX on freq 868300000 Hz at DR 5
18:32:49.042 -> Event : Tx Done
18:32:50.030 -> RX on freq 868300000 Hz at DR 5
18:32:50.064 -> Event : Rx Timeout
18:32:51.074 -> RX on freq 869525000 Hz at DR 0
18:32:51.277 -> Event : Rx Timeout
18:33:04.004 -> unconfirmed uplink sending …
18:33:04.004 -> TX on freq 867900000 Hz at DR 5
18:33:04.071 -> Event : Tx Done
18:33:05.047 -> RX on freq 867900000 Hz at DR 5
18:33:05.080 -> Event : Rx Timeout
18:33:06.088 -> RX on freq 869525000 Hz at DR 0
18:33:06.323 -> Event : Rx Timeout
That’s not okay; TTN uses SF9 for RX2 in EU868, and for ABP devices you’ll need to configure that manually.
That said, as the device is using DR5/SF7 for the uplink, it’s very unlikely TTN would use RX2 for the downlink, so unrelated to your problems.
Is this log for the working device, or for the troublesome one?
Thanks for your reply, this log is from the troublesome one.
If the timestamps in the log are accurate, then I think that the RX1 and RX2 receive windows do not always open at the expected time. A downlink in RX1 should be expected 1 second after Tx Done, and if nothing is received in RX1 then RX2 is expected 2 seconds after Tx Done. So, you probably want the log to show RX starting a bit earlier than the expected time, and any timeout happening a bit after the expected time, to allow the device to detect the downlink.
Above, RX1 opens 1.010 seconds after Tx Done, and RX2 2.025 seconds after Tx Done. Both are too late?
Some other occurrences in the log show RX1 opening a bit before the expected time (good), but RX2 still opening too late. If the times in the log would be accurate, then those differences between different uplinks may be weird too?
Assuming there’s not a downlink for every uplink, you’ll need to compare the device’s log to the uplink/downlink you see in TTN Console to the log in the device, to see if RX1 and RX2 could have been okay. (You may want to reduce the number of transmissions to make it a lot easier to compare the two. Also, note the daily limits though not enforced yet.)
You may want to look into adjusting (enlarging) those receive windows, but I don’t know if the device supports that. Or look into whatever code may be messing with the timing.
(Like mentioned above, for DR5/SF7, you’d be expecting RX1. And RX2 is erroneously using DR0/SF12 rather than DR3/SF9.)
This one is even worse…? A tad too late, but also: how long did it even listen for a possible downlink?
Thank you very much for all your tips. Unfortunately I was not able to get a downlink till now. If I find time I will keep on trying.
I had the same problem with the Heltec AB02S and AB02. The downlink worked after I switched from ABP to OTAA mode.
If you’re using EU868, then this difference may be explained by not configuring the ABP device to use SF9BW125 for RX2. Like for LMIC without the required LMIC.dn2Dr = DR_SF9 for ABP in EU868, downlinks in RX1 would still work. So that would also imply that apparently your uplinks were using SF9 or worse, for which TTN would likely often choose RX2. For OTAA, the device will get the proper settings automatically in the Join Accept.
Likewise, if you’re not using EU868, this difference could be explained by erroneously using LMIC.dn2Dr = DR_SF9. One should NOT use that line for non-EU868 ABP devices.
(But if OTAA works then I’d use OTAA anyway.)
1 Like