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
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).
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?
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!
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
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.
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.
Another important thing:
Set both the nwkskey and appskey to 2B7E151628AED2A6ABF7158809CF4F3C
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
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.
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:
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.
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?
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.
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.
Indeed a very steep learning curve! Got some more response from the ttu but can’t see if the device had connected to the gateway;
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
Sending: ok
m
a
c
_
t
x
_
o
k
Changed settings as advised, reserved a block of nodes and set devaddr.
Hi all,
Found the RN2483 command reference. Included a test to see if im connected to a gateway;
Serial.print("Getting status: ");
Serial1.write(“mac get status\r\n”); //status
delay(2000);
while(Serial1.available()) Serial.write(Serial1.read());
LoRaBlink();
And added this to start after reset (gives 0000) and after join (gives 0001) so should be connected to a gateway.
Still no sign on the nodelist though (what am i doing wrong;)
rn2483.pdf (362.3 KB)
I think currently the TTN api side is broken, nothing was updated since 02:40 today. Check in iot.semtech.com in this format: http://iot.semtech.com/applications/00-00-00-00-00-00-00-00/data/mote.00-00-00-00-02-01-xx-xx/ where xx should be adjusted according to what you set as the device address.
Out team https://www.facebook.com/thingkitee-1159573787404363/ have been playing with The Things Uno in TehnoHack hackathon in Estonia.
After some efforts we managed to get Things Uno to work successfully with Loran 8 gateway and got it sending the messages from highly populated are up to 400m with the external antenna.
It looks like TTN api is not very reliable receiving and passing the messages currently, but with own data endpoint we managed to get the system working in pretty reliable matter.
Our debug code can be found: https://github.com/thingkit-ee/things_uno
Hi Ewoud,
I’ll bet if you place the TTN UNO in a metal bin/enclosure so that no wireless communication can take place, You will see the same status.
“mac join abp” doesn’t seem to work properly (or i don’t know how to set it up)
I used “mac join otaa” with my gateway, and it worked fine.
In this mode the appkey needs to be set up first.
Thanks! Nice code base for some further testing.