TTN UNO - BETA release - Documentation

devlaam · October 22, 2015, 2:48pm

Btw, my device also arrived in a heavily damage package, but it did not suffer from that. It works just fine, at least in the first tests. Still i advise a hard casing for the next round. Other tips:

Probably you guys already know that the getting started manual needs some heavy rework. Not that there are errors or so, but for the beginner the learning curve maybe too steep.
I would deliver the devices working out of the box, so no flashing of software needed.
Add an extra push button on the PCB so testing is possible without connecting wires. In my view the time from unboxing to activation of its primary function should be as short as possible, preferable not more then a few minutes.
That’s it for now, keep up the good work, and congrats with the amazing kickstarter start!

Tweetonig · October 22, 2015, 2:53pm

Thanks. Good feedback and certain point of attention.

The points you mention are definitely on our list as well, If you like you can add your input on the quick start guide!

We are planning to ship it with a TTN default setup + demo application. That way it would indeed work out of the box.

Thanks for the compliments, let us know how you like it after a few test setups!

turiphro · October 22, 2015, 3:25pm

I’m also fan of out-of-the-box demo app, like a network unit test:

Add a button to the PCB; when pushed, a ping message is sent to the demo server; if the network replies, turn on the LED (pin 13?); otherwise keep blinking incidentally.

I’m sure we’ll be able to spend some time figuring out a great getting started experience.

Michael · October 23, 2015, 10:39am

I’m in Portland /Rhoon , just to the south of Rotterdam, so marconiplein will be to far away i’m afraid.
But i got the MTAC LoRa card + antenna in today, so i hope to have a working gateway this weekend.

Tweetonig · October 23, 2015, 10:39am

@Michael awesome! Let’s cover Rotterdam asap

Michael · October 24, 2015, 12:41pm

Ok, i think the gateway is working.

The node showed up here: http://thethingsnetwork.org/api/v0/nodes/
the gateway EUI is: 0080000000009D69

Not sure if everything is set up correctly though, as i can’t find it on the /gateway page.

Also, the Uno is sending the first packet ok, but the next buttonpress results in a “busy” message from the serial monitor window.

mrme · October 25, 2015, 2:55pm

Got the TTU uploaded the sketch and ran it. On serial monitor;
Reset: RN2483 0.9.5 Mar 24 2015 14:15:33
Device: RN2483 0.9.5 Mar 24 2015 14:15:33
Battery: 3223
EUI: 0004A30B001A8135
addr: ok
nwkskey: ok
appskey: ok
adr: ok
Pwr: ok
Join: ok
accepted

Does that mean it runs? Cant seem to TX through serial monitor (no response on any command). Is there test code for that?

Anyone know how and where can i check if my node is connected to a gateway?

greets,

Ewoud

telkamp · October 26, 2015, 6:40pm

The current implementation of The Things Network does not support ADR (adaptive data rate ) nor downstream messages. Of course this will be supported in the new architecture.

For now, I would suggest to switch ADR off (“mac set adr off”) and send unconfirmed messages (“mac tx uncnf 1 AABBCC”). Both can be changed in the included library (LoRa.cpp).

This will prevent retransmissions and automatic decrease of the data rate.

You can change the data rate manually by using "mac set dr " (0=SF12, … ,5 = SF7).

ruben_vleuten · October 27, 2015, 10:39am

I also managed to upload and run the sketch. I get the following:

Reset: RN2483 0.9.5 Mar 24 2015 14:15:33
Device: RN2483 0.9.5 Mar 24 2015 14:15:33
Battery: 3294
EUI: 0004A30B001A9FE8
addr: ok
nwkskey: ok
appskey: ok
adr: ok
Pwr: ok
Join: ok
accepted

In the library I changed the: (“mac set adr off”) and (“mac tx uncnf 1 AABBCC”), like Thomas mentioned.

as well as I changed the DevAddress to (“mac set devaddr 02012400\r\n”), (I “claimed” 02:01:24:xx here: http://thethingsnetwork.org/wiki/AddressSpace)

When I do LoRa_Lib.LoRaSendAndReceive(); I get:

Sending: ok

m
a
c
_
t
x
_
o
k

So I assume everything works well. My only problem is that I can’t find my message back on the REST API. I’m trying to find it using: http://thethingsnetwork.org/api/v0/nodes/{node_eui}/

But whatever I fill in for the node_eui, I can’t find my messages. I noticed that all the messages displayed in thethingsnetwork.org/api/v0/nodes/ only contain 8 digits, while the EUI I got returned from the RN2483 has 16, but even only using the last or first 8 doesn’t work.

Can someone tell me how to find my messages based on the above info?

telkamp · October 27, 2015, 2:15pm

I assume you have a gateway nearby?

You should look for 02012400 in the API.

node_eui is a mislabeling in the database, it should be changed toi devaddr.

Hope it works!

e.sajo · October 27, 2015, 2:54pm

I have the same issue, I can’t see anything from the node. I have an active gateway few meters away, I get:

Reset: RN2483 0.9.5 Mar 24 2015 14:15:33
Device: RN2483 0.9.5 Mar 24 2015 14:15:33
Battery: 3294
EUI: 0004A30B001A5BAE
addr: ok
nwkskey: ok
appskey: ok
adr: ok
Pwr: ok
Join: ok
accepted

When button is pressed:

Sending: ok

m
a
c
_
t
x
_
o
k

but I see nothing in the API

I have registered a block and set the devaddrr to: 02012200

I set adr to off and type to unconfirmed, which were not the default in the sketch (a bit silly to provide it with non-compliant settings).

BTW, our gateway is: 1DEE0B765AB9BE4D

Michael · October 27, 2015, 3:00pm

Are you connected to a gateway?

The “join: ok accepted” message unfortunately does -not- tell you, if you have connected to a gateway.

for testing purposes you can also use iot.semtech.com port 1680/1680 and then see if it shows up here:
http://iot.semtech.com/gateways/

I’m also experimenting with www.loriot.io .For now it looks to be the only one who supports confirmed messages.
Problem with them is that every transmission includes a frame counter, and after modifying the sketch or reconnecting power, the frame counter is set to zero, and messages do not show up anymore.

e.sajo · October 27, 2015, 3:15pm

When I run the poly pkt forwarder manually and press the button, I immediately see PUSH_ACK at least, so that would suggest I have a connection.

I do see some CRC errors there though:

[UPSTREAM]
RF packets received by concentrator: 3
CRC_OK: 33.33%, CRC_FAIL: 66.67%, NO_CRC: 0.00%
RF packets forwarded: 1 (16 bytes)
PUSH_DATA datagrams sent: 6 (1161 bytes)
PUSH_DATA acknowledged: 66.67%

But at least one messages seems to have gone through, but still nothing showing on the API side.

Michael · October 27, 2015, 3:33pm

Another important thing:

Set both the nwkskey and appskey to 2B7E151628AED2A6ABF7158809CF4F3C

ruben_vleuten · October 27, 2015, 3:38pm

I’m not sure if I’m connected. I assumed that Join: ok, meant that it was able to make a connection. I’m located in Amsterdam West, so think there should be coverage of at least one of the gateways. Is there a way to check if i’m connected? I can’t see anything popping up in the API

e.sajo · October 27, 2015, 3:47pm

Ok this I didn’t know either, is this documented somewhere? I didn’t see it in the quick start guide at least. I have changed it now.

Interestingly I see now something in the API but the gateway eui is the not the one that I have here, so I’m not sure if someone has used the same devaddr even though I reserved the block in the wiki.

The payload there is not decipherable by me, base64 decode gives just some garbage and not AABBCC.

e.sajo · October 27, 2015, 3:49pm

ARGH! The gateway euid is not the same as is stated in the webinterface…

EDIT

To recap

What needs to be changed in the sketch:

Set adr to off and message type to unconfirmed
Set both the nwkskey and appskey to 2B7E151628AED2A6ABF7158809CF4F3C

If you have Lorank 8 as gw:
Make sure the eui is set in the local_conf.json to be the same as is shown in the web interface, otherwise the eui might be different than expected. The webinterface reads the eui from the file gatewayID, which is not used by the poly_pkt_fwd itself.

ruben_vleuten · October 28, 2015, 10:56pm

I’ve been trying quite some stuff this evening, but no luck so far.

Is there something I can do with the TTN UNO if I don’t have a gateway myself yet?

How do I know if I’m in range of existing gateways and how can I then access the data I send?

Michael · October 29, 2015, 1:34pm

What a huge learning curve…
I’ve spend so much time on this already, but i’ll not give up…

Another discovery of the RN2483 Module:

“mac join abp” (with preconfigured keys) will not transmit anything to the gateway/server (a bug?)
“mac join otaa” (over the air activation) immediately transmits a packet to the gateway, if not replied on by the server, it will timeout with “denied”, if a response is received (on the same frequency) it will display “accepted”

Tests done on iot.semtech.com , not sure if the TTN server handles OTAA yet.

Data reception in this mode also works. If i prepare a packet to be sent to the semtech server, it is received by the module, but only when it has just sent a packet itself.
I read that is the way it’s supposed to work, as the receiver in the module is only listening to data at specific intervals after transmission of data.

Ah, finally!! Confirmed messages in this mode also work…
“mac tx cnf 1 010203” will send a packet, and will be ACKed by the gateway/server.

Btw, i’m using a simple usb SDR receiver to “see” if the module and gateway are doing something.

e.sajo · October 29, 2015, 1:52pm

Indeed if you send a message, after the transmission there are 2 receive intervals and only during those times a handshake can be done and a message received from the gateway.