Not receiving uplinks on V3 but working on V2

If there is no option to cut-and-paste the text most forum users use a (or more) screen shot of the relevant information. Would that be possible for you? (I don’t know which OS you use so I won’t assume you have the option.)

Two different but alike end devices. It all looks good to me. Maybe I just need to be patient. I am learning that about this stuff. Instant isn’t the way it works. :slightly_smiling_face:
Screen Shot 2021-04-14 at 18.38.42

How far from the gateway is the device?

Can you confirm that your v3 gateway, the DLOS8 has not shown ANYTHING at all in the v3 console?

The DLOS8 is outside. The LHT65s are about 4 m and 10 m away from the physical gateway device. I just triggered the LHT65 to try to join and I see the traffic in the TTN v3 gateway console and in the application console. I also see the “join_accept” JSON blobs pass through the TTNc3 webhook to my server. Screen Shot 2021-04-15 at 10.21.53 Screen Shot 2021-04-15 at 10.19.51 I’ll try moving the end-devices farther away from the LSO8.

Did you ever resolve this? I have the same problem with 2 LHT65’s. My device log looks exactly like yours. Thanks for any info.

No, this is not resolved yet. I am going through some support steps with someone from Dragino but I have to wait for an adapter (ordered yesterday) for the serial cabling. At this point they’ve asked me to dump the config from the LHT65 and send it to them. It all worked well on TTNv2. :^(

Thanks, I had 1 working on TTN V2 but it stopped on 04/13 (after the TTN V2 upgrade??) but I thought it maybe bricked so I bought another and installed on V3 with the results that are the same as yours. I ordered a programmer because I’m pretty sure my LHT65’s will need firmware upgrades but lots unknown at this point.

I will post here if and when I find a solution for TTNv3. I am assuming at this point that there is some detail in the internal config of the LHT65 that isn’t meshing well with the new system.

Updating to Firmware 1.8 (Dragino Download Server ./downloads/LHT65/Firmware/v1.8/) mine joins the v3 Network and reports again.
Before it sent traffic to my Gateway, that could be seen on the GW but never made it to the v3 Network. A manual rejoin (holding the button for a long time) caused a join-loop. What a luck that I got my programmer working so that I could update the FW. My smt v2 has a Problem with the reset Pin so I needed to connect it to ground and remove it after the light on the programmer blinks, see Dragino’s FAQ.

One of the advantages of having problems is that I’ve learned a lot. I updated the LHT65 firmware to v1.8. I was checking settings using the LHT65 serial console when I noticed that it was set to sub-band 1 so I changed that to sub-band 2 for uplink which to my understanding is what the TTIG uses. Unfortunately, I still get the same result as the one you posted on 5/15. My test LHT65 is on TTN v3 and my TTIG is on v2. I rarely see traffic on my v2 TTIG but I do get Application live data on v3 but never a data packet. The last message I ever see in the Application live data is “Forward join-accept to Application Server”.

@gstammw @thosmick I will try to update one of my LHT65 to v1.8 but it won’t work on my iMac due to security obstacles and the unsigned java update tool. Sigh. I have a Windblows machine at the office. Next week!

LHT65’s magically working this morning. This may be due to TTN changes but I also did a AT+CHE=0 command through the LHT65 serial console. This allows the LHT65 to use all sub-channels during a join and that takes a long time. I recorded the JOIN REQUEST frequencies and RX results and all sub-channels were used except for 3 of them and 7 not on the list were used too. In all cases the serial console said that all RX’s timed out but somehow I still got a join. Mystery to me.

After setting this aside for a while I can report that using the ST-LINK device to upgrade the Dragino LHT65 end devices to firmware version 1.8, and adding them again to TTNv3 has worked. TTN is reasonably straightforward to use but the rest was somewhat annoying and fiddly.

1 Like

I agree. I have multiples up and running now and it’s clear that when you buy one not only is the firmware version unknown but some of the config. parameters appear to be set differently like CHE=0 for one and CHE=2 for another. So my standard practice now is to download the config. using PuTTY then update the firmware then reconfigure to my liking then save that configuration. A config file for each device has already saved me some time and problems.

1 Like

Good day!
I meet the same problem. I have two device that work on the V2 stack but when using the V3 stack, I just saw one data from end device of application, After got data when I create end device , there is any data:
image
But in gateway of V3 stack, Both devices are working. please refer as below ( Devaddr: 0x2604170C; 0x260B1E72)
image.

Based on the above discussion, I still can’t confirm where the problem in this case.

Please show the activation information of both devices as well.

Hi Kersing

Thank you for your reply.
Please refer as following:
image

That is one node only. Is that the working one? What about data from the other node?