Hi,
Totally new to this, hope someone can give me some pointers.
I have a dragino LPS8 gateway and LT-22222 i/o controller.
Following the manuals, I get the LPS8 connected. When I try to get the LT-2222 connected, I don’t see any payload data coming through, just messages that look like this.
Any suggestion on what might be the problem?
Those are join requests, Ie the device logging on to the network.
Can you see the gateway logs to check it is transmitting the join response?
HI Nick, thank you very much for your reply. Here is a snapshot of the gateway logs.
These all seem to be join requests. I can’t see anything that looks like a join response - hang on a sec, there is one that says join accept.
PS - I see the TX light flash on the LT22222, but never the RX light.
DIY devices failling to receive OTAA accept (ie, “activation”) messages is a common problem traceable to subtle timing or configuration issues in the custom code or port.
With a more “factory” device it’s a bit puzzling - unclear if the best approach is a support request, or to try to get the code (Dragino is relatively good about that by their site seems to be momentarily offline) and build a version with debug output to a serial port and try to figure out what exactly is going wrong.
Of course these things are best investigated in the context of a gateway you control, where you can get debug output to verify that it actually transmitted. In complex cases it’s useful to put one scope probe on the gateway transmit LED and another on a GPIO the node blips when it starts a receive window, and make sure the two properly line up…
Just one minor note: the fact that TTN sees the Join Request (yellow/orange icon in the gateway’s Traffic page), accepts it and shows you an Activation (yellow/orange icon in the application/device’s Data page), and a Join Accept (green icon in the gateway’s Traffic page), implies that the configuration in TTN matches the configuration of the device. 
I assume descartes was referring to the logs on the LPS8 gateway hardware (not the gateway Traffic in TTN Console, which indeed looks good).
Yup, try to see what the gateway says it is actually doing rather than what the TTN servers have requested.
thanks for your comment. I was hoping that using factory kit and components from same supplier I’d avoid having to debug or get a multimeter out 
Thanks for your helpful comments, appreciate that.
Here are the logs from the gateway - unfortunately they mean nothing to me 
.
I did find some info on dragino’s wiki page " OTAA Join Process Debug" but I haven’t been able to get to grips with it either!
Please don’t post logs as images, but post them as text.
You’d be looking for lines like the following; this looks fine but others may not:
Also, it makes little sense to look at random parts in the log. Instead, look at the parts at the time of an uplink for which you know TTN told the gateway to transmit a downlink (in your case: the OTAA Join Request and its Accept). You should see the gateway sending the uplink (the Join Request) to TTN in a PUSH_DATA, and then receive details about the downlink (the Join Accept) from TTN in some PULL_RESP.
Thanks again - I see what you mean.
This is from the gateway:
Logread RxTxJson:
Fri Oct 2 19:10:08 2020 daemon.info lora_pkt_fwd[1673]: RXTX~ {"rxpk":[{"tmst":191817379,"time":"2020-10-02T11:10:08.978056Z","chan":8,"rfch":0,"freq":917.500000,"stat":1,"modu":"LORA","datr":"SF8BW500","codr":"4/5","lsnr":10.5,"rssi":-25,"size":23,"data":"ALsagpF6QUCouxqCMf9BQKifyfh1maA="}]}
Fri Oct 2 19:10:14 2020 daemon.info lora_pkt_fwd[1673]: RXTX~ {"txpk":{"imme":false,"tmst":197817379,"freq":923.2,"rfch":0,"powe":14,"modu":"LORA","datr":"SF10BW125","codr":"4/5","ipol":true,"size":33,"ncrc":true,"data":"IHgbBFAU/SqXS4WuNbIqr5CyH20TEuIRwcd89ye979vi"}}
Fri Oct 2 19:10:17 2020 daemon.info lora_pkt_fwd[1673]: RXTX~ {"rxpk":[{"tmst":200308820,"time":"2020-10-02T11:10:17.497451Z","chan":3,"rfch":0,"freq":917.400000,"stat":1,"modu":"LORA","datr":"SF12BW125","codr":"4/5","lsnr":10.8,"rssi":-22,"size":23,"data":"ALsagpF6QUCouxqCMf9BQKimfW9u9a0="}]}
Fri Oct 2 19:10:21 2020 daemon.info lora_pkt_fwd[1673]: RXTX~ {"txpk":{"imme":false,"tmst":205308820,"freq":917.4,"rfch":0,"powe":14,"modu":"LORA","datr":"SF10BW125","codr":"4/5","ipol":true,"size":33,"ncrc":true,"data":"IA3NP3bsPon/HQckwtPmbguwyrPIfjZT8Di3RndSZ6pN"}}
This is from TTN traffic, Join Request, Event Data
{
“gw_id”: “eui-a840411eb93c4150”,
“payload”: “ALsagpF6QUCouxqCMf9BQKifyfh1maA=”,
“dev_eui”: “A84041FF31821ABB”,
“lora”: {
“spreading_factor”: 8,
“bandwidth”: 500,
“air_time”: 28288000
},
“coding_rate”: “4/5”,
“timestamp”: “2020-10-02T11:10:09.125Z”,
“rssi”: -25,
“snr”: 10.5,
“app_eui”: “A840417A91821ABB”,
“frequency”: 917500000
}
You’re only showing the communication between gateway and TTN now. And you’re showing two pairs for Join Request/Accept for the gateway log, and a single one from TTN Console.
This is your Join Accept:
So, the Join Accept arrived at your gateway. But was it in time?
A Join Accept for RX1 should be sent 5 seconds after the Join Request was received, which happened at 19:10:08. For RX2 that is 6 seconds. The value for tmst at which the downlink should be transmitted, 197,817,379, is 6,000,000 microseconds after 191,817,379 at which the uplink was sent to TTN. So: TTN wants the gateway to use RX2. Receiving the downlink at the gateway at 19:10:14 may be just in time, or a bit too late, when comparing to 19:10:08.
The other pair is set to transmit after 5 seconds, hence RX1.
So: what does the other log view that you showed earlier give you around that time?
If the gateway transmitted the Join Accept then you’ll need to investigate why the LT-22222 did not receive it. That will be a bit harder to debug; I don’t know the device.
Hi @Sgrobler, the gateway appears to RX the join request with an RSSI of -25dBm. This is very strong. Are the device and the gateway very close? I suggest that you move the device to be at least 15 feet (this is in the USA, 5m in new money) away from the gateway and preferably on the other side of a wall to reduce the power levels.
They’re about 6ft apart at the moment. Is there a downside to having too much power?
Edit: its down to -59 now…
There certainly is, with too much power data may be received by the gateway on a neighboring channel due to crosstalk. When the response is being sent on that channel the node probably won’t receive it as it listens on the original channel.
What regional settings are these systems supposed to be operating in ?
What country are you located in?
For TTN, 917.5 SF8BW500 seems to suggest it’s AU-915? If yes: are you using Meshed?
For RX2 in AU-915, regardless the uplink, a downlink should use 923.3 MHz SF12BW500 (DR8), but you’re seeing 923.2 SF10BW125 (DR2) in the first example above.
For RX1 the downlink depends on the uplink, but an uplink on 917.4 SF12BW125 (DR0) should also yield a downlink on SF12BW500 (DR8), but you’re again seeing SF10BW125 in the second example.
So either you’re indeed running into the crosstalk that @kersing mentioned, or it seems the gateway’s configuration has a mismatch somewhere? (Probably in TTN as it’s using the wrong settings for the dowlinks.)
And what other details did that give you?
Yes its in Australia: AU-915. I am using Meshed. “TTN-meshed-router” in my gateway settings and "and “meshed-router” in TTN gateway settings. Sub-band 2(916.8-918.2MHz) in my gateway settings, and same in the LT22222.
Where would I look to see fix a setting in TTN? Couldn’t see anything there for uplinks or downlinks?
The console on the LT22222 gives this output. lots of RX timeouts…
DRAGINO LT-22222-L Device
Image Version: v1.4.2
LoRaWan Stack: DR-LWS-003
Frequency Band: AU915
DevEui= A8 40 41 FF 31 82 1A BB
Enter Password to Active AT Commands
[1114]***** UpLinkCounter= 0 *****
[1115]TX on freq 917500000 Hz at DR 6
[1148]txDone
[6135]RX on freq 923900000 Hz at DR 13
[6160]rxTimeOut
[7151]RX on freq 923300000 Hz at DR 8
[7210]rxTimeOut
[8150]***** UpLinkCounter= 0 *****
[8151]TX on freq 917800000 Hz at DR 0
[9638]txDone
[14641]RX on freq 926300000 Hz at DR 8
[14702]rxTimeOut
[15641]RX on freq 923300000 Hz at DR 8
[15701]rxTimeOut
Here are some of the settings in the device - do any of these look like they need adjusting?
AT+ADR=1
AT+TXP=0
AT+DR=6
AT+DCS=0
AT+PNM=1
AT+RX2FQ=923300000
AT+RX2DR=8
AT+RX1DL=1000
AT+RX2DL=2000
AT+JN1DL=5000
AT+JN2DL=6000
AT+NJM=1
AT+NWKID=00 00 00 00
AT+FCU=0
AT+FCD=0
AT+CLASS=A
AT+NJS=0
AT+RECVB=0:
AT+RECV=0:
AT+VER=v1.4.2 AU915
AT+CFM=0
AT+CFS=0
AT+SNR=0
AT+RSSI=0
AT+TDC=6000
AT+PORT=2
AT+RX1WTO=7
AT+RX2WTO=7
AT+CHS=0
AT+CHE=2
916.8 917.0 917.2 917.4 917.6 917.8 918.0 918.2
I’d not look at the device settings. Instead, check the frequency plan (and router) in the gateway settings, and the handler in the application settings.
Given that specific downlink channel: any chance you ever configured the gateway to use AS923? What’s your gateway’s ID? (Or what do the CLI ttnctl gateway status your-gateway-id and ttnctl gateway info your-gateway-id and https://www.thethingsnetwork.org/gateway-data/gateway/your-gateway-id give you?)
Ah, it’s https://www.thethingsnetwork.org/gateway-data/gateway/eui-a840411eb93c4150 There you have it:
{
"eui-a840411eb93c4150": {
"id": "eui-a840411eb93c4150",
"description": "LPS8",
"owner": "sgrobler",
"owners": [
"sgrobler"
],
"location": {
"latitude": redacted,
"longitude": redacted,
"altitude": 0
},
"country_code": "au",
"attributes": {
"brand": "Dragino",
"frequency_plan": "AS_920_923",
"placement": "indoor"
},
"last_seen": "2020-10-04T08:05:34Z"
}
}
More fun:
ttnctl gateways status eui-a840411eb93c4150
INFO Discovering Router...
INFO Connecting with Router...
INFO Connected to Router
INFO Received status GatewayID=eui-a840411eb93c4150
Last seen: 2020-09-29 14:14:39.801302027 +0200 CEST
Timestamp: 0
Reported time: 2020-09-29 14:14:39 +0200 CEST
Frequency Plan: EU_863_870
Bridge: gs.v3.
IP Address: 58.7.170.44
Location: not available
Rtt: not available
Rx: (in: 0; ok: 0)
Tx: (in: 0; ok: 0)
and:
ttnctl gateways info eui-a840411eb93c4150
INFO Found gateway
Gateway ID: eui-a840411eb93c4150
Frequency Plan: AU_915_928
Router: meshed-router
Auto Update: off
Owner: Sgrobler
Owner Public: yes
Location: (redacted, redacted, 0)
Location Public: yes
Status Public: yes
Brand: Dragino
Placement: indoor
Description: LPS8
Something has been messed up big time? (Maybe using ttnctl gateway status does not work well with Meshed, or maybe you once registered it using EU868, given the older “Last seen”? Its output may be coming from the EU router?)