hmm.but yesterday i took the device with me to the middle of Berlin, Kreuzberg near Checkpoint Charlie. And connection did not work either.
And here at my home i am at maybe 15m heigh upstairs. At the screenshot of the map below where the label “Köpenick” is displayed, near the bridge
Really not sure what to suggest at this point then as I dont know your device…perhaps others will step in.
One thought is it may depend on just where you were around Kreuzberg as I believe there are several Single or (and at least one) Dual channel PF’s that operate around there…you may have been unlucky in being ‘serviced’ by one of them depending on the RF path and strongest signals etc, though if you were moving around the density of full GW’s in Berlin would suggest you should have been able to connect…start looking at the documentation and firmware for the device at this point… good luck! 
1 Like
That’s right. In order to sort out different reasons for the problem, I’d also suggest to try the device again in a zone where several gateways should be reachable. If there is still no connection, I would suspect a hardware problem with your node.
For further investigation into the problem it’d probably be best to contact TTN community people nearby who can help with gateway logs, SDR debugging, different nodes for testing at your place, general advice, and more.
Hi tomber52,
did You have had any progress on this topic? I have purchased same Dragino LHT65 device and i have the same issues. It does not joint TTN.
I installed my own TTN gateway and so i could see on the gateway logs the join messages. But TTN does not reply.
This is one of the messages i see on the gateway:
DEV EUI: A84041000181C7BF
APP EUI: A000000000000100
Phys. Payload: 0000010000000000A0BFC78101004140A889AE16D1DC03{
“gw_id”: “eui-58a0cbfffe801728”,
“payload”: “AAABAAAAAACgv8eBAQBBQKiJrhbR3AM=”,
“dev_eui”: “A84041000181C7BF”,
“lora”: {
“spreading_factor”: 7,
“bandwidth”: 125,
“air_time”: 61696000
},
“coding_rate”: “4/5”,
“timestamp”: “2019-12-02T13:53:18.446Z”,
“rssi”: -48,
“snr”: 7.25,
“app_eui”: “A000000000000100”,
“frequency”: 868500000
}
It looks good for me so far. I have no further ideas.
Regards, Stefan
Where did you get these details, and did you overwrite the details in TTN Console?
A TTN-generated AppEUI starts with 0x70B3D57ED. Of course, in the Application in TTN Console, you can add the AppEUI that comes with a pre-configured device, and then select that for the device. But you did not mention that, and the value you’re using is not registered to Dragino either.
Also: is the Join Request show in the gateway’s Traffic page in TTN Console, and when clicking it, do you see any errors?
Hi arjanvanb,
This funny APP EUI ist built into the LHT65.
With Your hint i managed to get the LHT65 working. It has a serial console which responses to AT-commands. And there is an AT-command to set the proper APP EUI (AT+APPEUI=).
Now it works.
Many thanks!
The supplier sends me an other device with proper frequency band…but it doesnt work either. As i see i have same APP EU A000000000000100 on the sticker on the device and i set this as Application EUI in TTN. This is wrong? Which APP EUI should i set with the AT command you mention?
Should the device connect to LORA network even if i do not register it in TTN?
1 Like
You did right, but: Dragino did wrong. From the LoRaWAN specifications:
6.1.2 Application identifier (AppEUI)
The AppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies the entity able to process the JoinReq frame.
By definition, an EUI-64 address should be unique. In this case: unique per application, but Dragino should not expect customers to share an application, so each off-the-shelf device should have its own unique AppEUI (and DevEUI). As apparently Dragino uses A000000000000100 for all their LHT65 devices (which was not even assigned to them, unlike their DevEUI which is okay), in theory TTN would not be able to tell the applications of different LHT65 users apart.
I’m a bit surprised that multiple users can apparently add the same non-unique AppEUI to TTN Console, but it seems TTN only uses the combination of AppEUI and DevEUI:
Just to be sure: is the DevEUI indeed unique for each device?
But as it’s still not working for you, and as I assume you don’t want to be surprised in the future: apparently making it unique and using the AT-commands to set that unique value helps. One could simply use the value that TTN generates when one does not explicitly set a value in TTN Console.
No. Devices do not really “connect”. The gateway(s) will forward any valid LoRa packet to TTN, and one can see those in the gateway’s Traffic page in TTN Console. But TTN would not be able to find the AppEUI and DevEUI, so would not know the secret AppKey it needs for a Join Accept, and will ignore the Join Request. Also, even if somehow magically joined (or when using ABP rather than OTAA): where would you expect the data to go when the device has not been registered in TTN?
1 Like
…and given my previous answer, and as that error is not mentioned in the posts above: what if the AppEUI on the sticker is bogus? Maybe there’s an AT-command to read the AppEUI that is currently configured in the device?
I also use the LHT-65 and it is working like a charm. However I did not try to move it around.
It’s connected to my own internal TTN gateway.
But I can confirm that my LHT-65 also has the same APP EUI as the others.
1 Like
What does “internal” mean? Is that TTN Gateway just registered in TTN Console? If yes, then you’re part of the public network. 
Devices don’t really “connect” to a gateway, but I understand that your device’s transmissions are received by your gateway, and maybe some other nearby gateway(s) too.
How long ago did you register that in TTN Console? And @tomber42, did you manage to register the very same AppEUI without seeing any errors, and if yes: when?
And @VictorMarinus I assume you don’t have the same DevEUI as well? (Above, A84041000181BD42 and A84041000181C7BF are mentioned.) Also, I wonder if things keep working for you if at some point others manage to register the very same AppEUI…
That’s no longer relevant now that it’s clear that at least one device was registered with that weird AppEUI, so the weird AppEUI on that device’s sticker matches the true AppEUI as configured in the device.
I mean it is the indoor model of the TTN gateway. Registered in my console since one week.
As I can see all the traffic of my LHT-65 on the gateway, I suppose my device is only using my gateway. Am I correct?
The LHT-65 has been registered 5 days ago.
And indeed the DEV EUI is different. ending with C7B7
1 Like
Any gateway in its neighbourhood will receive it. If those are TTN gateways, then you can see the list if you go into the application’s or device’s Data page, and then click an uplink to see its metadata. Its gateways attribute is a list of one or more gateways.
Hi tomber42,
You can find the AppEUI of Your App in the TTN Application Console. When You try to register a new device to the App the EUI ist shown as last field at the bottom of the Form.
To connect to the serial console of the device I used an USB-Serial adptor with an open UART-Connector (just four open black/white/green/red jumper-pin-connectors instead of the usual RJ45 or DB9 plug). Using the serial connector shipped with the device You must patch red to red, black to black, white to green and green to white (null modem connection). The default passwort is 123456 and Enter (You find it in the Dragino documentation)
Apply the AppEUI of Your device via the AT+APPEUI=… an then Your AppEUI including a Blank between each byte. With AT+APPEUI=? You can verify if the device has “swallowed” it.
I copied and pasted the DevEUI and the AppKEY (AT+DEVEUI=?, AT+APPKEY=?) into the registration form and changed the AppEUI on the device to the TTN-AppEUI and the device registered.
With AT+CFG You can retrieve the whole device configuration.
I recommend to download the AT-commands- and the operating-manual in its latest version from the Dragino support website. They are both really useful.
1 Like
I´m using LHT65 connected to my TTN indoorgateway, it worked from the first day.
the APPEUI is the same (A000000000000100)
Do you think it´s necessary to generate a new EUI?
1 Like
Recently I have got one Dragino LPS8 gatway and two LHT65 Sensors. I started them up at home near to the gateway and could finally connect both to the TTN. One mistake I made was to miss to put in the “APP KEY” beside the “APP EUI” and “DEV EUI” on the TTN Console. “APP KEY” and “APP EUI” are printed on the sticker inside the small carton box. So there is no need to reprogram the “APP KEY” to the one generated by TTN. You simply can overwrite it in the TTN console by the one from the sticker.
Regarding coverage: One of the sensors I moved arround 1km. I was disapointed about that it does not connect to TTN anymore. Today I think I found the reason for this in the specification lorawan1_0_2-20161012_1398_1.pdf. There is written “Adaptive Data Rate control may not be possible when the radio channel attenuation changes fast and constantly”. This likely happend to the sensor due to the move by car 1km far away from the gateway without any transmission (was set to 10min period).
With the second sensor I checked out the scenario by moving it to the cellar of my house. Same situation. In the logread of the gateway, I saw that the LHT65 was sending with spread factor SF7 and 14dBm (EU variant) before. This seems to be to less. After I restarted the sensor in the cellar by pressing the button > 5sec it got connected with SF12. Sensor back in the first place, the SF went back to SF8. So adaption works fine in this direction.
In case there was already a connection to TTN and the attenuation is changed rapidly, activate the device again.
1 Like
Very true. But just curious: did you get the same non-unique AppEUI A000000000000100 like the others in this topic? Also, I’m starting to wonder if people get different values for the AppKey…
1 Like
I have got the same AppEUI A000000000000100. This looks to be ok. See: Addressing and Activation. I do think that the application is the LHT65 itself.
Unfortunately my coverage issue could not be solved by activation of LHT65 (placed outdoor in a wooden beehive) once again, 1km far away from my indoor Dragino LPS8 gateway (placed in 2. floor under the roof top made from concrete roof tiles). This is not that far away, isn’t it? The area is a standard settlement with houses in the same height as my one.
I am at a loss. Does anyone know, how to improve the range (beside outdoor gateway or antenna)? Is it that Over-the-Air Activation (OTAA) is not possible on that range and I should try Activation by Personalization (ABP)? Any experience with simliar setup would be helpful as well 
No, it’s not okay: an application is not defined by a device type. Even a single customer should be able to define multiple applications using the very same device types. Also, this is not even a valid AppEUI, and who knows if Dragino or another manufacturer isn’t using the very same AppEUI for another device type. See my earlier answer above.
That said, it’s nice, and weird, that this works for some of you (at least with the current version of the TTN stack) while others needed to change the AppEUI to get things to work. I’d not risk having to fix this later though, and I’d give the devices a proper AppEUI before deploying them.
As for coverage: the activation method does not matter. if ABP works but OTAA does not, then such only implies that uplinks work but downlinks don’t, or not that well. In that case ADR would not work either (and you’d need to explicitly program basic network settings as well). Also, just to be sure you know: you should not do an OTAA join very often, and once joined there’s no difference between OTAA and ABP.
Maybe Gateway queries & ranges helps, but it’s a long read.
1 Like