What values are you seeing? Are the GW logs showing Tx receives during these drop out periods (but then dropping packets) or is node simply not txing?
Thanks for helping!
@Wolfgang
These were my concerns as well, but actually I don’t think it’s that important because my other three LHT65 nodes (with the exact same configuration) work fine. The gateway I use is a Heltec HT-M01S which works flawlessly with all my other nodes. I prefer not to adjust the ADR to save the battery and because that was not necessary for other LHT65 nodes. Below you see the LHT65 configuration.
@Jeff UK
Below is a sent message from the LHT65 as a text file. As you can see an RSSI of about -70, with an SNR of 7.5 (which both barely differ from my other LHT65 nodes). Also the serial output of the LHT65 over a longer period of time.
Configuration:
AT+CFG
Stop Tx events,Please wait for all configurations to print
Printf all config...
AT+DEUI=a8 40 41.....
AT+DADDR=018.....
AT+APPKEY=44 4f 13 68.....
AT+NWKSKEY=52 d3 f9 a2.....
AT+APPSKEY=a5 a7 ba 3a.....
AT+APPEUI=a0 00 00.....
AT+ADR=1
AT+TXP=1
AT+DR=5
AT+DCS=0
AT+PNM=1
AT+RX2FQ=869525000
AT+RX2DR=3
AT+RX1DL=5000
AT+RX2DL=6000
AT+JN1DL=5000
AT+JN2DL=6000
AT+NJM=1
AT+NWKID=00 00 00 13
AT+FCU=512
AT+FCD=87
AT+CLASS=A
AT+NJS=1
AT+RECVB=0:
AT+RECV=0:
AT+VE©OWrÂrŠ[02]*Uá68
AT+CFM=0
AT+CFS=0
AT+SNR=0
AT+RSSI=0
AT+TDC=300000
AT+PORT=2
AT+PWORD=123456
AT+CHS=0
AT+SLEEP=0
AT+EXT=1
AT+BAT=3071
AT+WMOD=0
AT+ARTEMP=-40,125
AT+CITEMP=1
AT+RJTDC=20
AT+RPL=0
AT+TIMESTAMP=systime= 1630760107 2021 9 4 12 55 7
Payload:
{"end_device_ids":{"device_id":"84432","application_ids":{"application_id":"37724"},"dev_eui":"A8404.....","join_eui":"A000000000000100","dev_addr":"260....."},"correlation_ids":["as:up:01FEJY3FQFTK7W6QNE03N8VS3J","gs:conn:01FEB3G4EWMHMHSF3BVCAZ4CHB","gs:up:host:01FEB3G4Q5JQEBT2SYV1CQRFPV","gs:uplink:01FEJY3FGWPCD8GKTJWDF8H8ZP","ns:uplink:01FEJY3FH0AQVDK093ESP225Y2","rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01FEJY3FH0S348T4DP668KSG8N","rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01FEJY3FQFC9SYAVRDVKJP9B0H"],"received_at":"2021-09-02T09:40:40.304377150Z","uplink_message":{"session_key_id":"AXuMRo0dR0vFsqdfT1cjDA==","f_port":2,"f_cnt":358,"frm_payload":"y/gIyQJxAX//f/8=","decoded_payload":{"BatV":3.064,"Bat_status":3,"Ext_sensor":"Temperature Sensor","Hum_SHT":62.5,"TempC_DS":327.67,"TempC_SHT":22.49},"rx_metadata":[{"gateway_ids":{"gateway_id":"echtsing","eui":"7C9EBDFFFFFB83C0"},"timestamp":1535757968,"rssi":-70,"channel_rssi":-70,"snr":7.5,"location":{"latitude":51.923755976429256,"longitude":5.490650171600395,"altitude":8,"source":"SOURCE_REGISTRY"},"uplink_token":"ChYKFAoIZWNodHNpbmcSCHyevf//+4PAEJCdp9wFGgsImLjCiQYQyLf2KyCAxbuS2fU7","channel_index":4}],"settings":{"data_rate":{"lora":{"bandwidth":125000,"spreading_factor":7}},"data_rate_index":5,"coding_rate":"4/5","frequency":"867300000","timestamp":1535757968},"received_at":"2021-09-02T09:40:40.096620933Z","consumed_airtime":"0.061696s","version_ids":{"brand_id":"dragino","model_id":"lht65","hardware_version":"_unknown_hw_version_","firmware_version":"1.8","band_id":"EU_863_870"},"network_ids":{"net_id":"000013","tenant_id":"ttn","cluster_id":"ttn-eu1"}}}
Serial output over time
serial.txt (17.1 KB)
PS: Strange that, as you can see in the Grafana graph, the dropouts start every time in the night and everything works again later in the morning.
Ideally the thing to do would be to collect raw traffic logs from the gateway, and collect serial logs from the node, for a period starting before a dropout, running through it and back to the resumption.
First make sure the node thinks it transmitted, and look for any differences in those transmissions.
Then see if there are matching messages in the gateway log at those times.
Your node appears to be using confirmed uplink, which is generally a bad idea, and often having to retry which is worse, so it’s perhaps possible that you’re burning through an airtime allowance and the node is stopping its own transmissions until it’s “earned” more transmit allowance, nevermind that you’re probably drastically exceeding the TTN fair use allowance.
It turns out that the Dragino LHT65 is responsible for this problem, the node simply doesn’t send messages every now and then. This mainly happens at night, but certainly also at other times.
As you wrote the confirmed uplink is generally a bad idea but that’s Dragino’s factory default. I didn’t want to change that so as not to frustrate discussions with them about warranty. Also because my other LHT65 nodes work with exactly (!) the same settings.
Because I don’t have this problem with other LHT65 nodes, I assume that my new LHT65 is defective. Unfortunately I haven’t heard anything from Dragino support after more than a week, maybe they don’t want to give guarantee.
I throw the node away, after hours of experimenting I’m tired of spending any more time, not even a minute, on a $45 thing and look for another brand. I also don’t want to bore forum users with this. If Dragino still offers service or warranty, I will let you know here.
Anyway thanks for your help!
1 Like
So it’s you that’s adding all those downlink stats.
Not sure how configuring a device as per the supplied documentation would void the warranty.
And you may just want to try flashing the device with the current firmware - it just may be an older or rogue device that needs a brain make over - you never mentioned which firmware it has so it might be worth the 5 seconds to check.
Hi Nick! The firmware version is latest as shown in the payload above (“firmware_version”:“1.8”). A firmware refresh/update is quite simple and might help, but I didn’t do it to prevent Dragino support from pointing that out as the cause. For now, the node is ready for the trash. I’ll wait a little longer for a response from Dragino.
Where’s that then?
I can only think you must have had some really bad experiences with warranty returns in the past!
Firmware updates are expected, that’s why they are made public on the vendor website. If anything, the first response is likely to be “are you using the latest version” - which is what we say on the RAK forum ad nauseam and then … … nothing, because only 1.53% of people report back to say that it’s now working. When polling respondents, 23.878% replied agreed with the statement “I was too embarrassed to report back, it being something so simple to try, I so should have done with it sooner”. The remainder just blushed and ran.
Also, firmware updates are not immutable - ie you can roll back.
The firmware version as in the post above 
Thanks for pointing it out, I think you mean “the firmware version is well hidden in the post above”.
The easier you make it for people to help you, the more help you’ll get.
Hey Hans, I can PM you my ship to…just mark as defective item for recycling & £0/$0/€0 for customs 
sure likely recoverable with updates/configuring as h/w issues not a common cause of problems like this.
Grafana is the end of the chain, what do the intermediate stages show at these times…gw logs (local @ gw and in gw console), application/device logs (again in console), do you have data storage integration enabled? Is data missing in there at those times also? As asked earlier. Are the confirms all sent to node or does node miss and keep tx’ing… potentially exhausting on air time duty cycle forcing a Tx stop for a period? (Let alone busting TTN FUP)
The serial output shows lots of double taps suggesting conf failed and device resends? Any logs from time aroudnwhennode appears to drop out or restart delivering?
Lol, yep. Most of my computers are windows boxes where the software ate itself, acquired free and installed with Linux.
Software misbheaviour != hardware problem
(though in a few cases I had to replace the drive)
Analysing your serial.txt I recognized, that first your node transmitts every message three times with the same counter-value on different frequencies.
At 15:13:48.383 it receives an ADR-command. After that it transmitts every message twice.
At 15:48:34.296 it receives the next ADR-command. After that it transmitts every message once.
Maybe this behaviour is the reason why a decreasing number of values are shown.
Thanks for analyzing Wolfang and the others for your comments. I emailed Mr. Edwin Chen, director of Dragino, the day before yesterday and asked to read these messages. Usually he always responded kindly and adequate so I am now waiting for his response.
Have you actually updated the firmware yet?
Yes, latest is 1.8.3 and I have flashed 1.8.2 over 1.8.1. The only difference 1.8.3 as shown in changelog is:
The band sequence of AU915 and US915 bands (CHE=0) is changed from 12345678 to 21345678
So no need to flash 1.8.3. over 1.8.2. Besides my old STM-32 programmer is broken, maybe I’ll flash 1.8.3 when the new one is delivered.
No one puts their subtle bugs in to the change list so anything could have been fixed that no one wants to admit to.
But if your programmer is broke, not much can be done.
For defective hardware you need to contact your vendor. Did you order from Dragino directly or from a european reseller?
In terms of self help and soliciting community assistance to help you resolve, 13 days ago I asked as above. What did you discover? What results? Dont write off just yet!..
Thanks for your help but I have stopped using this LHT65. The $40 is not worth it to me to spend so much time on it, I just bought a new one and it worked right away. The old one is in a box with unused stuff that I’ll throw away when I clean up my attic if I ever move