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.
Serial1.write(“mac set rx2 3 869525000\r\n”);
Note: this works for iot.semtech.com, it be might different for the upcoming TTN implementation of this feature.
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.
Yes! This works.
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.
Thanks for the feedback.
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
Did I mention follow the 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.
Hope it helps.
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.
Yea I just didn’t have an FTDI cable on hand to do direct connection.
Once I had it upload in bootloader mode worked right away.
So the chip has been updated.
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.
Tried everything I could find so far but no luck. E.g.https://github.com/gonzalocasas/thethings-uno gives output, looks like a connection is made and data is sent but isn’t showing up in the api. Anyone got an idea how to get a working connection? (location Utrecht, I’m using a SODAQ Mbili+RN2483)
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
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.