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:
- 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.
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
1 Like
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.
Hi Micheal,
Yep. Wilt test with otaa this weekend, but does this also work on ttn or do i need different keys for that?
grt
@Ewoud, TTN does not currently implement OTAA yet.
Thanks @matthijs. Will bring my uno to work (utrecht) and try it there.
We’re testing the UNO and having more or less similar experience as the others report regarding the inconsistency of packet reception on the API end.
So today we tested running the entire TTN stack locally (super easy to setup with docker-compose), and it works like a charm! This is especially important if you are planning a hands on meetup as we are; we want to be able to demo and play the whole process from node to API.
We also put together a quick Getting started repo for the UNO based on the code from @alarmatwork (thanks guys!): https://github.com/gonzalocasas/thethings-uno
1 Like
You can always set up netcat UDP port listening for debugging in any linux server:
nc -u -l -p 3333
and try to configure your gateway to send packages to this server in addition to TTN endpoint…
it works very well with Lorank 8 gateway, because you can set up this UDP listener locally inside the gateway.
You will be able to get fast feedback - see if the packages are received, but only downside is that you can not decrypt the data.
If you run the “server” tool from https://github.com/TheThingsNetwork/lora_simulator, you will see the decrypted data (when using the default semtech key, which can be changed in the source code of that tool).
1 Like
I am also exploring the RN2483 module and wanted to clarify your results.
I backed the kickstarter and look forward to the gateway. Until then I have built the RaspberryPi+Ecard gateway as posted by nestorayuso - great job!
Using the iot.semtech.com test server I am able to
- Use otaa to send (and view the data online ) and get confirmed packet and returned data
- Use abp to send (and view the data online ) but not receive a confirmation or returned data
I think you are saying the same thing in your post but I wanted to confirm.
The thingsnetwork server is not supporting confirmation or downlink at this stage from what I understand so it’s probably not been a priority but Has anyone had any success receiving a confirmed packet in adp mode using the RN2483
On Wednesday I am going to a microchip sponsored lora workshop in Breda and will ask about the current firmware version of the RN2483 because there is a new R3 source bundle on the microchip RN2483 portal which has instructions on how to update the firmware of both the mote and RN module but is missing key files.
Anyhow, I am very keen on using the adp mode and downlink so if anyone has achieve this would like to compare notes.
1 Like