TTN UNO - BETA release - Documentation

Commands I’m using for successful data transfer after the module has been reset to factory settings (sys factoryRESET):
sys get hweui
Wait for 16 byte number
sys reset
Wait for ‘RN2483 …’ (… depends on firmware level)
mac set devaddr <your 8 hex char address, something like 0201FF01>
Wait for ok
mac set appskey 2B7E151628AED2A6ABF7158809CF4F3C
Wait for ok
mac set nwkskey 2B7E151628AED2A6ABF7158809CF4F3C
Wait for ok
mac set adr off
Wait for ok
mac set rx2 3 869525000
Wait for ok
mac join abp
Wait for accepted
mac tx uncnf 1 3132333435
Wait for mac_tx_ok

All lines being send should be terminated by (\r\n)
If you want to know for sure a gateway received the data, replace the last line by
mac tx cnf 1 2132333435
This will perform a confirmed transmit, so if no gateway acknowledges an error will be shown and mac_tx_ok has ‘real’ meaning.

BTW have you tried using the Sodaq code for the RN2483?

I don’t have the ‘mac set rx2 3 869525000’ line, will add it and test it tomorrow when I’m in Utrecht again. Unfortunately no TTN (yet) in my hometown. Also tried the Sodaq code but node doesn’t show up in the api.

I’ve added that line to get the confirmation working with a MultiTech gateway connected to Semtech as well as TTN. Found a reference to it in message 45 of this thread.

Tried it but node is not showing up, can’t figure out what I’m doing wrong. I’m using the following code:


void setup()
{
Serial.begin(57600);
Serial1.begin(57600);
Serial1.write(“sys factoryRESET\r\n”); delay(10000);Serial.write("factoryreset: ");while(Serial1.available()) Serial.write(Serial1.read());
Serial1.write(“sys get hweui\r\n”); delay(1000);Serial.write("MAC: ");while(Serial1.available()) Serial.write(Serial1.read());
Serial1.write(“sys reset\r\n”); delay(1000); Serial.write("versie: ");while(Serial1.available()) Serial.write(Serial1.read());
Serial1.write(“mac set devaddr 02013B01\r\n”);Serial.write("set devaddr: "); delay(1000); while(Serial1.available()) Serial.write(Serial1.read());
Serial1.write(“mac set appskey 2B7E151628AED2A6ABF7158809CF4F3C\r\n”);Serial.write("set appskey: "); delay(1000); while(Serial1.available()) Serial.write(Serial1.read());
Serial1.write(“mac set nwkskey 2B7E151628AED2A6ABF7158809CF4F3C\r\n”);Serial.write("set nwskey: "); delay(1000); while(Serial1.available()) Serial.write(Serial1.read());
Serial1.write(“mac set adr off\r\n”);Serial.write("set adr off: "); delay(1000); while(Serial1.available()) Serial.write(Serial1.read());
Serial1.write(“mac get status\r\n”); Serial.write("status: ");delay(1000); while(Serial1.available()) Serial.write(Serial1.read());
Serial1.write(“mac set rx2 3 868100000\r\n”); delay(1000); while(Serial1.available()) Serial.write(Serial1.read());
Serial1.write(“mac join abp\r\n”); Serial.write("join: ");delay(1000); while(Serial1.available()) Serial.write(Serial1.read());
Serial1.write(“mac get status\r\n”); Serial.write("status: ");delay(1000); while(Serial1.available()) Serial.write(Serial1.read());
Serial1.write(“mac tx uncnf 1 68656c6c6f\r\n”); delay(5000); while(Serial1.available()) Serial.write(Serial1.read());
}

I don’t see anything obvious. Can’t test your code as the RN2483 is not connected to an Arduino. What is the output of your code?
Also, are you sure you are within reach of a gateway connected to TTN while testing?

Hi Thomas,

It doesn’t work either on Linux because of

this.fileOpenDialog.setInitialDirectory(new File(Preferences.userNodeForPackage(getClass()).get("FilePath", "C:\\")));

in FEDFXMLController.java:3969

I spent 1h trying to recompile the decompiled .java and re-package the .jar without success.
At the end, I used a VirtualBox VM with Win10 and it worked out of the box, without using the bootloader mode.

00:57:17.989 > Device: COM3 Bootloading started
00:58:25.543 > Device: COM3 Bootloading Successful

The module is a bare RN2483 chip connected to a FTDI USB/Serial adapter.

Pierre

I should be in range of a gateway. It would be nice if there was a way to determine if you are indeed in range and connected to a TTN gateway or not.

Output:
factoryreset: RN2483 0.9.5 Mar 24 2015 14:15:33
MAC: 0004A30B001BA639
versie: RN2483 0.9.5 Mar 24 2015 14:15:33
set devaddr: ok
set appskey: ok
set nwskey: ok
set adr off: ok
status: 0000
ok
join: ok
accepted
status: 0001
ok
mac_tx_ok
ok

@kersing tried again this morning on a different location in Utrecht. My packets apparently are ending up on iot.semtech.com (Gateway 00-00-B8-27-EB-FD-3F-68) Although I only see three packets that have arrived. SNR an RSSI are bad so that could suggest to much interference. So now I’m in doubt if it was really me or someone who copy-pasted code from this forum. Will try again with another devaddr to see if I get any results later today.

The gateway in Utrecht (located at Catharijnesingel 51) is indeed forwarding both to TTN and Semtech.

To increase your reach, you can lower the data rate to SF12:

"mac set dr 0"

You’re now using SF7.

Thanks for checking! I admitted my defeat and used Windows too…

I’ll raise this with Microchip.

Thanks, changed it. I see my packets coming through, I’m on the other side of the tracks at the moment ( Croeselaan).

@kersing

Nice, that’s not bad at all, considering the gateway is behind a window with huge attenuation on one side, and massive reinforced concrete on the other!

On SF12 the gateway can demodulate up to -20 dBm, every decrease in spreading factor, increases the minimum SNR by about 2.5 dBm.

Not sure if this was already shared, but I found this document useful:

1 Like

Following the clear video and instructions, we successfully upgraded three RN2483’s (which were running a 0.95 version) to 1.0, using Windows 10.
With two others we needed to walk the bootloader path but that did not work out.
We tried about 5 times (unplug/plug etc) but got the errormessage mentioned below in the java console.
Any suggestions, should we keep retrying, or consider these two to have gone to meet their ancestors ?


5503FD0055AA00030000WRITE
WRITE
5503FD0055AA00030000WRITE_DONE
FFFFFFFF5503FD0055AA00READ
5503FD0055AA40420000WRITE
WRITE
5503FD0055AA40420000WRITE_DONE
030000015503FD0055AA40READ
5503FD0055AA80810000WRITE
WRITE
5503FD0055AA80810000WRITE_DONE
420000015503FD0055AA80READ
5503FD0055AAC0C00000WRITE
WRITE
5503FD0055AAC0C00000WRITE_DONE
810000015503FD0055AAC0READ
5502400055AA00030000F5EF01F0FFFFFFFFE1CF28F0E2CF29F0D9CF2AF0DACF2BF0F3CF2CF0F4CF2DF0F6CF2EF0F7CF2FF0F8CF30F0F5CF31F09DB09EA003D0DDEC6AF042D09DBA9EAAWRITE
WRITE
5502400055AA00030000F5EF01F0FFFFFFFFE1CF28F0E2CF29F0D9CF2AF0DACF2BF0F3CF2CF0F4CF2DF0F6CF2EF0F7CF2FF0F8CF30F0F5CF31F09DB09EA003D0DDEC6AF042D09DBA9EAAWRITE_DONE
0000000000000000000000READ
Trying to Disconnect: COM12
Disconnection Successful
No FED Selected by the user
In Bootloader Failure

@waltert The RN2483 modules seem to have some pins that can be used to flash the firmware using PICkit3. Do you happen to have one of those available? (Or any other PIC programmer able to program a 18F46K22 device?)

I was wondering about that. Probably should check with microchip first that the firmware update hex is a ‘full hex’ and not missing the bootloader block which may also contain some ‘secret’ information. Otherwise flashing the device with a PIC Programmer would definitely send it to heaven unless you were very careful to exclude programming to the bootblock and any other potentially protected code segments.

The device itself is probably not fatally damaged but maybe worth waiting for the updated programming software microchip have been promising.

@JamesC If it is missing some code the hex file should not contain data for those addresses and as a result not clear that part of flash… Of course the loader software might contain some magic to skip part of the data in the hex file.

Why upgrade at all? Is there an urgent reason?

Yep ! worked fine for me.
Both motes are now v1.0.0.

Thnx

Now continuing to get them connected to a gateway (hopefully around somewhere in my neighborhood …)

Hi Rene,

Exactly my problem right now !
Did you manage to find a solution for this ?
My RN2483 “says” to be joined (accepted) and a max_tx_ok is returned. So my conclusion was (hopefully) that the actual message was send. But unfortunately did not show in the api …

Hopefully you mae some progress on thes matter ?