LDS01 unable to communicate

End Devices (Nodes) Dragino
#1

Hello,
I’m in the process of testing some devices connected to our office TTN gateway.
I’ve been able to setup a Dragino LGT92 device, but following the same process I can’t associate the LDS01 to our TTN gateway.

The following keys have been set in order to match the TTN application setup.
AT+CAPPKEY=XXXXXXXXXXXXXXXXXXXXX
AT+CAPPEUI=XXXXXXXXXXXXXX
AT+CDEVEUI=XXXXXXXXXXXXXX

I cannot even see Lora join packets reaching the TTN web Gateway Traffic console.

DRAGINO LDS01 Device
Frequency Band: EU868 v1.1

This is the output from the serial:

[3349]DRAGINO LDS01 Device
[3351]Frequency Band: EU868 v1.1
[3354]OTAA
[3355]DevEui= XXXXXXXXXXXXXX
[3358]class type A
[3359]freq mode intra

[3363]***** UpLinkCounter= 0 *****
[3374]TX on freq 868300000 Hz at DR 0
[3384]Start to Join, method 2, nb_trials:48
+CJOIN:FAIL
[7381]Wait 1 hour for new round of scan

Of course I am a newbie on Lora and TTN…
Thank you for you help.
Stefano

#2

Can you see activity on your gateway - need to check the RF side.

Also, if you are on top of the gateway, as in the device & gateway are in close proximity, they really need to be 5-10m apart or behind a brick wall otherwise they can overload each other, particularly the gateway as it effectively has 8 receivers.

#3

Hi Nick,

thank you for your reply. No activity seen on the gateway (related to this device, but I can see other sensors communicating).
The device is “close” to the antenna - 4 or 5 meters. I can try to move it away…
I’ll update you soon.

Stefano

#4

Unfortunately, same behavior with some distance in between…

#5

What frequency plan is your gateway aka, where are you and is it an EU gateway?

Do you have an SDR to check the radio / antenna are actually emitting a signal?

#6

EU gateway. Southern Switzerland.
Sorry no SDR…
Can the TTN gateway sniff lora packets?

#7

Not as such, it can hear any LoRa transmissions and if they vaguely match a packet then the gateway will make a stab at processing it but mostly come up as CRC errors. So the best you can do is try & synchronise an uplink whilst watching the gateway log to see if you can get a correlation.

#8

Thank you. Will try…

#9

I’m also having trouble with the LWL01 water leak sensor since December 20 and I also live in Switzerland. I connected a TTL adapter to the device to check the logs. At first the network join was also not working. After I changed the device address the network join worked again, but there is still an error when sending the messages. Here is the full output from the log:

[3380]DRAGINO LWL01 Device
[3382]Frequency Band: EU868 v1.1
[3385]OTAA
[3386]DevEui= XXXXXXXXXXXXXX
[3389]class type A
[3391]freq mode intra

[3395]***** UpLinkCounter= 0 *****
[3405]TX on freq 868300000 Hz at DR 5
[3415]Start to Join, method 0, nb_trials:48
[3479]txDone
[8466]RX on freq 868300000 Hz at DR 5
[8550]rxDone
+CJOIN:OK
[8559]Joined

[8616]***** UpLinkCounter= 0 *****
[8620]TX on freq 867700000 Hz at DR 0

ERR+SENT:01

I can also see the join message in the TTN console, but no message after that. Here is the output of the join message:

{
  "time": "2021-01-05T16:25:37.053777255Z",
  "frequency": 868.5,
  "modulation": "LORA",
  "data_rate": "SF7BW125",
  "coding_rate": "4/5",
  "gateways": [
    {
      "gtw_id": "stoeckacker",
      "timestamp": 787998267,
      "time": "2021-01-05T16:25:37Z",
      "channel": 0,
      "rssi": -91,
      "snr": 7.5
    },
    {
      "gtw_id": "eui-7276fffffe019ba8",
      "timestamp": 3585074948,
      "time": "2021-01-05T16:25:36.02497Z",
      "channel": 7,
      "rssi": -121,
      "snr": -3
    }
  ]
}

I also tried setting the network and app security key again, but the transmission still does not work. Did you find a solution for your device?

#10

It would appear you joined the network server, which would mean that things are working correctly in both uplink and downlink direction

[8616]***** UpLinkCounter= 0 *****
[8620]TX on freq 867700000 Hz at DR 0

ERR+SENT:01

Whatever this error is, it’s purely internal to the node. You’d have to check the manufacturer user information.

One possibility is that you’ve attempted to send a packet which would take an unreasonable amount of time at the extremely, extremely low data rate DR0

#11

Thanks for the quick reply. I already contacted Draguino support if they have any idea why this isn’t working. Strange is that the device worked perfectly for several months until December 20 and I did not change anything on this date.

#12

@cslorabox I just received an answer from Dragino. The problem was simply the battery. I already tried to replace the battery, but one of my new batteries was also almost dead. I did not think of trying another battery because the network join worked for some reason. I checked all the batteries with a multimeter and now used one with a voltage higher than 3 Volts and with that the device works again.

3 Likes
#13

Battery issues explains why the first data transmission fails as that uses SF12 which requires a lot of energy compared to the join at SF7. TTN will direct the node to use a better SF in reply to that first data transmission but if that never makes it…

#14

Thanks for the hint. This would explain why the join worked.

#15

A node that managed to join with SF7 traffic really shouldn’t be defaulting its ADR to SF12… I can see how first-cut software might do that but it’s the sort of thing that should be noticed and corrected as an implementation matures.

#16

@kersing I’m just now having a new problem. With the new battery everything works fine when the device is near the gateway, but just a bit farther away it is having problems transmitting again. Using the AT+CTXP command I found out that the transmission power after joining is set to 0 (-17dBm). If I manually increase the transmission power to 1 (-15dBm) the device is able to transmit, but it resets back to 0 again as soon as I reset the device.

Is there a way to force a higher transmission power for this device or is this something that I can set in the TheThingsNetwork console?

#17

You might be able to save the settings in the device, if possible I would expect the at command document to list that feature. (It is a while since I last looked at the code Dragino based their software on so I’m not sure)

It is not something TTN has any control over as after join the stack in these modules ‘resets’ to a set a defaults that are part of the device code (and may be configuration parameters).

After moving ADR should change the settings so the device gets heard, however that might take considerable time.

#18

This is very odd: minimal power with SF12 is “penny wise but pound foolish” as the increase in transmission duration would cost more than the power saved. If expecting a very weak battery a medium power setting could make some sense, but the fraction of power actually going to RF output has to be weighed against the power needed to operate the chip - there’s a floor in savings where doubling the transmission time is going to cost more in terms of that base load, than it saves in lower final amplifier draw.

#19

I’ve just received an answer from Dragino and the transmission power 0 is in fact the highest transmission power for this device. So the device works correctly, but is still not able to send a message with the highest transmission power. So I guess my new battery has been stored for too long and does not deliver enough power.

My guess is that even if I would buy brand new batteries that they also would only last for a few months at this high transmission power. So I’m currently thinking of building my own device and use an 18650 battery to power it. I already built some LoRa devices myself using the CubeCell boards and they work perfectly and for a long time without replacing the battery. Also I have a lot of 18650 batteries from old Powerbanks, so this would be the best solution for me.

#20

Keep in mind that a lithium ion battery has a higher voltage than the lithium primary batteries many of these pre-made nodes are made for. If you go with this plan, you’ll need a suitable voltage regulator or converter. You also want to make sure you don’t over-discharge the cell, as then you will not be able to charge it again.