Compatibility: Compatible with Arduino/Micropython
Issue Encountered
I am working on a geofencing project. I am struggling to receive downlinks on the nodes (they appear in the gateway logs).
Tests Conducted
Verification of AT Commands:
Commands AT, AT+CDEVEUI, AT+CAPPKEY, and AT+CAPPEUI work correctly and receive an OK response.
Other commands such as AT+CFM=1, AT+RXWIN2=869525000,9, AT+LINK=1, AT+CSQ, AT+RECV, and AT+RESET all return a +CME ERROR:1.
Sending Downlinks:
I modified the global_conf.json file to set implicit_payload_length to 20 bytes.
The downlinks reach the gateway successfully, but they are not received by the nodes.
Attempts to activate downlinks and configure RX windows were unsuccessful.
I am seeking solutions to resolve the downlink reception issues and AT command errors on my RA-08H node. Any help or suggestions would be greatly appreciated. Thank you!
Is the issue encountered really about goats & polygons or is it of a technical nature regarding the firmware & radio issues around downlinks to the RA-08H?
If you click on the … you can access the pencil to edit out the irrelevant information - if people start answering about goats on here we end up with the same problem on the other thread.
In the meanwhile, can you explain what you had in mind changing global_conf.json - what resources inspired this? What is “activate downlinks”?
Given the number of modules on the market and the non-standardisation of AT commands, what are CFM, LINK & CSQ for? It helps the volunteers if they have easy access to hardware resources so any links to docs will speed things up.
I managed to solve some problems with the AT commands for the RA-8h chip (https://docs.ai-thinker.com/_media/lora/docs/ra-08_at_instruction.pdf) for those in need; I no longer have issues with that. However, I am sending POST requests with Postman in this form for example (with the necessary headers):
{ “downlinks”: [ { “frm_payload”: “AQAEASltQ0JyihZAkW1DQvCnFkA=”, // Payload encoded in Base64 with correct padding “f_port”: 1, // Application port “confirmed”: false, // Unconfirmed message “priority”: “NORMAL” // Message priority } ] }
My downlinks are correctly received on TTN and, since they are already encoded in Base64, my downlink encode function does not alter the values of my frm_payload. However, I cannot reconstitute it on the node, and the gateway logs show something like this:
Between this and your implicit payload length and not answering the other questions, it’s hard to tell.
Why Postman? It’s an extra layer of complexity in debugging - just enter them in the device console.
Why Class C? Why not just simply have the device on a push-to-send and it will pickup the downlink with you watching. Does your gateway setup support Class C?
It is essential that all tests are done at the simplest possible level to establish a basic working setup, then add in the extras.
I tried to simplify my issues. First i’m attempting to receive the join-accept downlink (wich is already an issue). It is well send to my gateway with the same instructions : tx fred = rx1 freq and dr tx = dr rx1, with an delay of 5 seconds, so no problem with the connections between my gateway and ttn. Same for the connection between my node and my gateway, the rssi and snr are good. logs from the gateway
INFO: Received pkt from mote: F1145FBO (fcnt=5824)
JSON up: {“rxpk”:[{“jver”:1,“tmst”:20767708,“chan”:1,“rfch”:1,“freq”:868.300000,“mid”:8,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“rssis”:-34,“lsnr”:13.8,“foff”:3941,“rssi”:-33,“size”:23,“data”:“ALpvBfEMwBYAbXwG0F7Vs3Diy3EG0Rc=”}]}
JSON down: {“txpk”:{“imme”:false,“tmst”:25767708,“freq”:868.3,“rfch”:0,“powe”:14,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“ipol”:true,“size”:33,“ncrc”:true,“data”:“IJc7cAUsVeDNEAxL78Fcz+lBCQGgB53XsZZeShvNbHzc”}}
I see no logs for RX2 json down, is TTN supposed to send a second order to the gateway or the gateway does it by itself?
logs from my end-device
[16:38:10.000] Command: AT+CJOIN=1,0,8,1
[16:38:13.000] Response:
OK
ASR6601:~# TX on freq 868300000 Hz at DR 5
Start to Join, nb_trials:1
[16:38:14.000] Command: AT+DRX?
[16:38:17.000] Response:
+DRX:0
OK
ASR6601:~#
ASR6601:~# RX on freq 868300000 Hz at DR 5
+CJOIN:OK
Joined
[16:38:18.000] Command: AT+DRX?
[16:38:21.000] Response:
+DRX:0
OK
No Join Accept received. Anyway, i tried to open rx1 with the good delay (+5s, i cannot do +4980ms on my device, +4s doesn’t work either) but i cannot get data during my window from the gateway. I couldn’t find any information about the RX1 window opening duration for the RA-8H module.
Thank you in advance for any help!
Edit: I focused to much on your text and neglected to read the output of the module.
.
Your module joins fine. You are not getting any application data and that is to be expected when joining. Application data can only be returned on a normal uplink, not a join.
So after the join you need to issue a DTRX command to send an uplink and at that point you will get downlink data if that is available.
You must have read about Rx1 being 5 seconds after transmission - so asking 4 seconds later, well,
The Join procedure is dictated by a specification - a device transmits the JR and then listens 5s later for a response - this is universal. Afterwards the LNS may change the Rx1 duration, a function in the specification, but almost all of this stuff needs leaving alone as you build up your toolkit.
The TTN console for the gateway & your device will show you what is going on - you should see the JA being heard and the JR being sent, assuming your gateway is the closest to hand (there’s a bit more to this, but mostly that’s the case) and the device console show similar info.
No and No. If it is determined that the Rx1 window will be missed then Rx2 is used. The gateway won’t do two sends ‘just to be sure’.
Strongly recommend reading the Learn section (link at the top of every page) as that has a whole section on the join procedure and normal uplinks and perhaps a lighter roast too ??
roast too 
??