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.
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).
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.
Please keep us updated with your research on the RN2483! I also got a few of these, I will try to make time during the weekend to hook them up and play with them.
I can say I managed to receive a confirmation using ABP with an RN2483 (in a Microchip Mote).
I can’t tell how the RN2483 tells the confirmation thru its serial port. When we got the confirmation, the mote was running in stand-alone mode, i.e. a microcontroller was controlling the RN2483.
It happened during the 3rd LoRa Alliance conference, held at Rotterdam on 10 November. The motes were connected to the KPN network.
So I attended the Breda Lora Workshop today 18 Nov and asked about this. Indeed there was a new firmware update available for the RN2483 and the workshop involved doing the actual update which didn’t really go very smoothly but most people got there in the end. So Microchip will no doubt make these update files available soon at the RN2483 product page as they were missing when I last checked.
However this is not the problem with the apb. The microchip rep said the place to look was in the return window parameters which may vary from the defaults depending on the server. So this is why setting the rx2 parameter fixes. There are other parameters also which include the window timeslot. So probably we should find out what these parameters are for each different service and publish them somewhere.
I look forward to the TTN implementation of the confirmation. For my application I am interested in bi-directional communications so I would really like the TTN implementation to be able to invoke my 3rd part server to get the payload to return in the confirmation. I could help create a reference implementation of that plumbing.
This is useful experience and good input for our own implementation. Thanks for the feedback.
It would be of great value to the community if you could share how to update the RN2483 firmware, with pointers to the software etc.! Once it’s available.
What kind of range have people been getting with the UNO? We tested yesterday with the external antenna (same part and and connector as proposed in the quick start) and got like max 800m to a lorank 8 gateway in almost LOS. Behind some buildings the range dropped to about 250m.
So not even close to what is expected or what would be usable.
Here is the download with the 1.0 firmware and update tool.It is the same as microchip distributed at the workshop and will no doubt upload to their support site soon. I added the .hex binary firmware file and made a .pdf of the word document and included them both in the one update.
Follow the LoRa_FirmwareUpdate_viaGUI Word/PDF document closely because the workshop slides said to click the bootmode button in the gui and this misleading even though it is intuitive. As per the word document you only use the bootmode button if the device has been erased ie it is a recovery mode. Assumedly because if the device firmware is erased either by command or a failed update then it no longer has an soft reset mode and needs to use a different sequence to initialise into bootmode. Anyhow ALOT of the trouble people had at the workshop was they had clicked the bootmode button so don’t…
The other thing is I have only tested this on a microchip RN2483 PICTail and microchip Mote. These both have the microchip USB:Serial converters. I am assuming the GUI Update tool works with the generic USB port and so will work with any USB : UART connected to a RN2483 but I haven’t tested that.
If you are using an TTN UNO I imagine you will need to create serial pass-through program which pipes between Serial and Serial 1. Hopefully this doesn’t mess with the bootloader timing so you might need to write a tight bit-bang pass-through if it does. I haven’t tested this either.
FInally the FirmwareUpdate program is written in java and requires java 8 to run. It is the executeable jar ( Lora.jar ) in the root folder of the download. You should be able to double click it to run it you may have to launch it from a command line session using java. eg > java lora.jar
The RN2483_Parser.X.production.Bootloader.hex in the download is the firmware you should use. This is the 1.0 firmware for the RN2483 You need to select it as the firmware file. Also you should use 19200 as the baud. - see the word/pdf guide
Well I can’t recommend trying this as it bricked our RN2483…
Initial connection is fine with serial forwarding, all commands go well and get a response.
I then tried to update the firmware, the DFU console showed sys erase fw and then uploading firmware, at which point I wanted to resize that part of the window, and it closed everything to the startup state…
If I set to bootloader mode, I can select the file and start update but it just closes everything again after a while.
BTW I saw in the end of your text you say 19200 as the rate but in the documentation it is 57600 in all sections.
Quoting from Microchip documentation (found in the demo software section on the RN2483 page):
1] Because of a bug which was present in the RN2483 (v 0.9.5) boot loader. The attempt to update the RN Module code may not succeed on every attempt. RN2483 (V 1.0.0) or RN2903 (V 0.9.5) factory programmed, do not have this issue and will have no issues in the process.
2] If the 1st boot load did not work, the original RN2483 v 0.9.5 code would have been erased,; leaving only the boot loader on the device. Again in the LoRa Development Utility, above the device list, select the checkbox for ?Bootloader Mode?
3] This will allow all available COM ports to be populated on the device list. Select the COM port which was enumerated for the LoRa Mote.
4] Only the DFU tab will be available. Follow steps 5-7 from Update the LoRa RN Module Code until the RN Module is successfully updated.
So you might want to try a couple of times to try revive the device.
I tried indeed but no success, the program does the same every time, which looks like it’s closing the com port and then just stops there. I see no activity in the serial line after that.
I agree it’s a bit of a mess but I don’t think you have or can damage the actual RN2483 module during to firmware update process. In addition to deleting and reprogramming the firmware probably 20 times yesterday to try to make sense of the sequence of events I fussed around with least 10 retries in the following tutorial video but cut most of the attempts in the editing so I think its safe to say you will be to restore your firmware safely… eventually.
Thanks @JamesC,
I’ve just successfully updated the firmware, device shows RN2483 1.0.0 Oct 23 2015 14:46:12 created. Set speed to 19200, first attempt (‘normal mode’) failed, reconnected the device (disconnect first, restart LoRa.jar and connect USB after the GUI started), scan in ‘Bootloader Mode’ showed the device, again set to 19200 and upload firmware.
Im using a generic (cheap) Chinese USB to serial dongle with Silicon Labs CP210x. Just RX, TX and ground connected.
Did anyone manage to upgrade the RN2483 using OS X? Everything works for me, except that Bootloader input file dialog doesn’t work, so I can’t select a file.
Did you have any luck in connecting and sending packets that show up in the api? I get a mac status of 0001 and mac_tx_ok but my node is not showing up when using the api.
Nope. the mac status and mac_tx_ok doesn’t work on TTN yet.
You can’t see if you are connected to a TTN gateway this way. Where i live theres no gateway so thats the next priority.