TTN v3 and Dragino LG308


Did anybody succesfully added an Dragino LG308 to TTN v3?
I added the gateway but the status stays disconnected.
On v2 I need to check the legacy packet forwarder.
But it looks this isn’t an option in V3?
Is there a workaround for this?


What do the logs on the gateway say is going on?

Have you searched the forum?

Thnx Descartes!
The logs helped
The gateway still was on the server address of v2 :frowning:
Changed the server address to and now it works!

1 Like

Hi oberon, which firmware did you use for your device?


A post was split to a new topic: Connecting Dragino LSE01 to ThingsSpeak or MyDevices

Hi Tomsch,

I’m still using the firmware which came with the device:
Firmware Version:


Thanks for the info,
i managed also to connect to V3 on FW LG02_LG08-5.4.1594972541.
Has a nicer UI :slight_smile:


Hi all
Does someone see why the connection not work?
i did a update of the firmware, but it does not help.



The uplink port seems to be empty. It should be set to 1700.

Did you reset to defaults? That seems to be required for some firmware upgrades.

I have a similar problem.
On the old firmare LG02_LG08-5.4.1594972541 the gateway connects when I change the server name.
But if I upgrade to any newer firmware the device won’t connect.
It seems even that it does not find its radio interface because all the entries under LoRa Log are empty.
I have reset the device to factory defaults and reconfigured everything without any effect.
Any idea what could be wrong?


I think I’ve been stuck on this interface problem. There is many new FW releases so I’ll try if this is still not working.

Hi @GatuRatz ,
Hi @slorba ,

I don 't think you’re doing anything wrong. I am (/was) having the same problem. I’ve got an “old” LG(3)08P with SX1301 and SX1276. The newer LG308 doesn’t have the SX127x anymore and the (even more recent) LG308N is using the SX1302 instead I think.

I was able to track down the error to the file

root@dragino:/# ls -l /mnt/etc/init.d/board_detect 
-rwxr-xr-x 1 root root 4438 29. Jun 2018  /mnt/etc/init.d/board_detect

looking into this file it says:

more code before just for context
        SN=`hexdump -v -e '11/1 "%_p"' -s $((0x908)) -n 11 /dev/mtd6`
        case $SN in
                logger "[Model Detected]: LIG16"
            logger "[Model Detected]: LG308-N"
                rmmod spi-gpio-custom
                insmod spi-gpio-custom bus0=1,14,16,26,0,8000000,15 bus1=2,18,21,19,0,8000000,24
                sleep 1

                /usr/bin/spirw 8 0
                if [[ "$?" == "0" ]]; then
                        logger "[Model Detected]: LG02"
                        /usr/bin/spirw 23 1
                        if [[ "$?" == "0" ]]; then
                                logger "[Model Detected]: LG01"
                                /usr/bin/spirw 12 1
                                if [[ "$?" == "1" ]]; then
                                        logger "[Model Detected]: LG308"
                                        logger "[Model Detected]: LG308P"

        echo $chip > /var/iot/chip
        echo $model > /var/iot/model.txt
        echo $pic   > /var/iot/pic.txt

(I’ve reformatted the code a bit to be less confusing)

In other words: if spirw fails to communicate with the SX127x, then we’ve got the newer model of the LG308 with only the SX1301 and all variables are set to the correct values to be written into the files located in /var/iot/. Those files are used by all the other scripts to decide what they actually do.

If the communication with the SX127x succeeds, then we’re running on an LG(3)08P, but not all required variables are set correctly. This results in empty files in /var/iot and scripts and web-ui don’t work correctly.

After patching the script like this:

                                        logger "[Model Detected]: LG308P"

…the device is running nicely without (me noticing) any (uncommon) problems so far, yet RX and TX are both done through the SX1301 and the SX1276 isn’t used anymore (which really doesn’t bother me at all).

I was contacting Dragino support assuming that it is only a firmware bug, but they wrote back to me within no time, that the hardware is simply too old and can’t run the current firmware and I should buy a new one.

Honestly now I think it was done in purpose to render the old devices unusable with the latest firmware to boost sales.

Right now I didn’t fully check, whether downlink messages sent through the SX1301 are working properly, but would be great if anyone could confirm this.