I received a TTN Uno and set it aside for a couple of weeks. I have now fired it up and was expecting the RN2903 module to be running the latest firmware but find it is only running 0.9.5. Support for AU915 and AS923 were only added in later releases (AU915 in 0.9.8).
I would like to upgrade the RN2903 on the TTN Uno to V 1.0.3.
Has anybody tried this?
2 Likes
I have the same problem, I just received mine and I can not use it for AU915, there is some update of the library for this. please TTN help us with this.
Hi,
Sodaq made a bootloader sketch to do this: https://github.com/SodaqMoja/RN2483FirmwareUpdater
That project doesn’t yet include 1.0.3, but you could add it. Available here:
http://www.microchip.com/wwwproducts/en/RN2903
Hi JDP
I thought that the Sodaq updater was written for their own PCB - I don’t think it can be used with an RN2903 mounted on a TTN Uno board.
Arduino is Arduino, right? and the bootloader in the RN2903 doesn’t depend on the board.
The only limitation I can think of is if the sketch relies on the larger memory of the SAMD21 cortex used on Sodaq’s board, and if the small AVR may not have enough to buffer it.
I don’t have an Uno to try it … yet. Hoping my Kickstarter delivery will arrive some day soon.
Hi, have you had any progress with this ?, Is it a problem of the firmware or also in the ttn library?, What can we do to use the device in these other bands ?, Until now lost investment.
Please refer to the other post on the firmware updates: https://www.thethingsnetwork.org/forum/t/au-915-firmware/11612. The upgrade is pretty simple once you load the Pass-through sketch from the examples and then install and run the Microchip Java updater - no need for any specific hardware as the RN2903 supports update via the UART
Thanks @petertoome
I already update the firmware, but the ttn library in the arduino IDE does not allow me to work with AU915, can you give me an example of how are you using TTN Uno with the firmware update for AU915?
Your problem is happening because the TTN library does not recognise the AU915 channel plan. I presume that the TTN will release an update soon, but until then you get to play a bit deeper with the TTN Aruino Library. I am assuming also that you have made the changes to the local_config.xml and global_config.xml in your Gateway to select the correct channeling (see other posts on this topic)
Before editing any of the library files, make a backup so you can revert if anything goes awry.
What you have to do now is to make another channel plan in the library which you can designate TTN_FP_AU915 (I am repeating this after quickly reviewing my library rather than from paper notes so please someone pick me up if I miss anything).
First backup and then edit “theThingsNetwork.cpp”. Locate the US915 declaration (void TheThingsNetwork::configureUS915(uint8_t fsb)). Copy and paste this again and change the references to US915 to AU915.
Now locate the declaration for the channel configuration (void TheThingsNetwork::configureChannels(uint8_t fsb)). Add a new case statement entry for AU915:
case TTN_FP_AU915:
configureAU915(fsb);
break;
Add an entry in the Scaling Factor case statement (bool TheThingsNetwork::setSF(uint8_t sf)) : which is a copy of the US915 case but renamed AU915
Now edit the file “TheThingsNetwork.h”.
Add a new define for AU915: #define TTN_PWRIDX_AU915 "5"
In “enum ttn_fp_t” add an entry at the bottom "TTN_FP_AU915"
After “void configureUS915(uint8_t fsb);” add "void configureAU915(uint8_t fsb);"
In your sketch select the new channel plan "#define freqPlan TTN_FP_AU915"
Compile your sketch and check for any errors.
Thanks for your help, I have done what you tell me, but I think it is necessary to configure the frequency on each channel enabled (I added this in the void TheThingsNetwork::configureAU915(uint8_t fsb) function), but this command is not recognized when I run the sketch:
Sending: mac set ch status 8 on
Sending: mac set ch freq 8 916800000
Response is not OK: invalid_param
Sending: mac set ch drrange 8 0 3
Sending: mac set ch status 9 on
Sending: mac set ch freq 9 917000000
Response is not OK: invalid_param
Sending: mac set ch drrange 9 0 3
Sending: mac set ch status 10 on
Sending: mac set ch freq 10 917200000
Response is not OK: invalid_param
Sending: mac set ch drrange 10 0 3
Sending: mac set ch status 11 on
Sending: mac set ch freq 11 917400000
Response is not OK: invalid_param
Sending: mac set ch drrange 11 0 3
Sending: mac set ch status 12 on
Sending: mac set ch freq 12 917600000
Response is not OK: invalid_param
Sending: mac set ch drrange 12 0 3
Sending: mac set ch status 13 on
Sending: mac set ch freq 13 917800000
Response is not OK: invalid_param
Sending: mac set ch drrange 13 0 3
Sending: mac set ch status 14 on
Sending: mac set ch freq 14 918000000
Response is not OK: invalid_param
Sending: mac set ch drrange 14 0 3
Sending: mac set ch status 15 on
Sending: mac set ch freq 15 918200000
Response is not OK: invalid_param
Sending: mac set ch drrange 15 0 3
any suggestions?
Yes, you are correct. I had set the frequencies manually but then had neglected to go back and add the code to the library. I will see if I can find time to experiment further. But my personal view is that if you are setting up boards for use in a specific country, it would be safer to consider the frequency selection as a first up task and to create a specific Config sketch which would set the frequencies and write the updated settings to the board’s EEPROM. It also helps reduce the risk of the units operating outside of the ACMA compliance. The application sketch then only needs to worry about which of the sub-bands to enable.
Hi John,
I’m wanting to add the same AU915 capability to my TTN Node and UNO nodes via the Arduino Library and I’ve followed the steps outlined above, but there doesn’t appear to be any actual frequency changes described between US915 to AU915 that I would expect to see, but it kinda reads like they are required or you’d done them another way.
Do did you make subsequent changes to the TheThingsNetwork::configureAU915(uint8_t fsb) function that does the channel frequency changes and if yes can you share those code changes?
I’m also working on getting the RN2903 1.0.3 firmware with AU915 support. I think it must be beta or pre-release.
Regards
Alex Shepherd
Hello Alex
There seems to be a big push to shift to AS923 (the Asian channeling) in Aust & NZ so it is good to see someone sticking with AU915. I have uploaded the amended library file
TheThingsNetwork_cpp.txt (27.9 KB)
Download this amended file and rename it to TheThingsNetwork.cpp
1 Like
Dear Alex, Johan has provided us with the firmware for AU915, and it works with the original library, in the github repository there is the download link:
Hi, also confirming - I successfully updated a sodaq one to SA915 1.03 firmware using the instructions. It’s taken over 3 hours, using 2 sodaqs. I killed my first one because I read this: RN2483 / RN2903 Firmware upgrade guide – PocketMagic
It said “We need to extract out the combined HEX file (not the smaller offset)”
I did that, but the file looked different when I was using Notepad++ macro recorder to put the " ", around each line. I burned it anyway using the Arduino v1.4 tool called RN2483FirmwareUpdater by SodaqMoja, and it said success, but now the microchip RN2903 isn’t responding.
I’ll need to reprogram it directly, suppose this means soldering to the microchip, because I’m not desoldering it!
What you need to do if you use RN2483FirmwareUpdater is the opposite.
Use the smaller offset, not the larger combined hex file!!!
Here’s what I did, the general version:
RE: Updating Microchip module on Sodaq One Rev.4
Get updater sketch GitHub - SodaqMoja/RN2483FirmwareUpdater
expand to c:\users\username\Documents\ardunio
rename updater sketch folder (remove the -master bit at the end)
load sketch (double click on the sketch INO)
double check it opens & shows all files including hex files etc (should be about 15 tabs across the top!)
uncomment the file HEXFILE_RN2903AU_097rc7 in the HexFileImage.h file (It’s the second tab in Arduino software)
compile the sketch, confirm it’s good
plug in the sodaq, select the sodaq one, then select the com port
compile and send to arduino
Wait for confirmation
select the com port again (might have changed)
click tools, serial monitor
send the y command to the arduino
-update success!
close, reset & reopen the serial monitor
confirm in the serial monitor that it’s running v097
Repeat on all sodaqs, confirming they update to the ‘old’ version OK.
Now comes the hard bit. You need to incorporate the new version into the sketch. It’s slow to do so if you’re a noob like me, but I cracked it. Only problem was, I incorporated the wrong hex file… as I mentioned at the start. Here are correct instructions (well, they worked for me)
First is converting the .hex to a .h file, by sort of making it look like json or js.
Find the .hex file in RN2903.SA1.0.3.Hex.zip named RN2903_Parser.production.hex
If you don’t have RN2903.SA1.0.3.Hex.zip from a source, none of these instructions help you!
Open this hex file in notepad plus plus, save it straight away as HexFileImage2903AU_103.h
Also in notepad ++,
Open file HexFileImage2903_103.h from SodaqMoja/RN2483FirmwareUpdater GitHub zip
compare the two files
Your goal is to make the new HexFileImage2903AU_103.h look much like the old HexFileImage2903_103.h
Then use the macro recorder to make the changes to all lines.
Adding
" at the start of each line
", at the end of each line.
I found it worked well if I started macro recording at the top left hand side, and used END to the end of the line, then pressed right arrow to go to the next line, then stopped macro recording. Then you multi-run the macro (I think it’s a double play) and repeat to the end of the file. This way it only takes a few minutes to fix the whole .h file up.
Also, show all characters (reveal codes) to see the LF and LFCR at end of each line. Use the LF converter to ensure it’s only LF at the end of each line. Click edit, EOL conversion, Unix.
Copy and paste and rename the bits at the top and bottom of the file. I’ve included them here, as I’ve customized the names, and this ties in with another .ino file in the RN2483FirmwareUpdater folder.
Header of new .h file (after it’s had the " ", added and LF checked)
#ifndef HEXFILEIMAGE2903AU_103_H__
#define HEXFILEIMAGE2903AU_103_H__
#define HexFileImage RN2903AU_103
const char* const RN2903AU_103 = {
Footer of that same new .h file
};
#endif /* HEXFILEIMAGE2903AU_103_H__ */
Once this is done, compare again your two files, and they should be pretty much identical, apart from the actual hex code inside, and the names (The one we are working on is 103, but has AU in the name…)
SAVE the file 
Ok, now, one more file to edit. in hexfile.h (second tab across the top in the Arduino IDE), replace lines as per this. It’s essentially just adding support for our new AU_103 version of the .h hexfile
/*
- HexFileImage.h
*/
#ifndef HEXFILEIMAGE_H_
#define HEXFILEIMAGE_H_
// Uncomment one of the following, and one only, not more, not less.
//#define HEXFILE_RN2483_101
//#define HEXFILE_RN2483_103
//#define HEXFILE_RN2483_104
//#define HEXFILE_RN2903AU_097rc7
#define HEXFILE_RN2903AU_103
//#define HEXFILE_RN2903_098
//#define HEXFILE_RN2903_103
#if defined(HEXFILE_RN2483_101)
#include “HexFileImage2483_101.h”
#elif defined(HEXFILE_RN2483_103)
#include “HexFileImage2483_103.h”
#elif defined(HEXFILE_RN2483_104)
#include “HexFileImage2483_104.h”
#elif defined(HEXFILE_RN2903AU_097rc7)
#include “HexFileImage2903AU_097rc7.h”
#elif defined(HEXFILE_RN2903AU_103)
#include “HexFileImage2903AU_103.h”
#elif defined(HEXFILE_RN2903_098)
#include “HexFileImage2903_098.h”
#elif defined(HEXFILE_RN2903_103)
#include “HexFileImage2903_103.h”
#else
#error “Please define one the the following: HEXFILE_RN2483_101, HEXFILE_RN2483_103, HEXFILE_RN2903AU_097rc7, HEXFILE_RN2903_098, HEXFILE_RN2903AU_103”
#endif
#endif /* HEXFILEIMAGE_H_ */
Logs from bad update - using wrong hex file: (just for interest)
…
-
Starting HEX File Image Verification…
0% |||||||||||| 25% |||||||||||| 50% |||||||||||| 75% |||||||||||| 100%
HEX File Image Verification Successful! -
The module is in Application mode:
RN2903AU 0.9.7rc7 Aug 11 2016 15:07:56
Ready to start firmware update…
Firmware Image: RN2903AU_103
Please press ‘c’ to continue…
…
-
Starting HEX File Image Verification…
0% |||||||||||| 25% |||||||||||| 50% |||||||||||| 75% |||||||||||| 100%
HEX File Image Verification Successful! -
The module is in Application mode:
RN2903AU 0.9.7rc7 Aug 11 2016 15:07:56
Ready to start firmware update…
Firmware Image: RN2903AU_103
Please press ‘c’ to continue…
Erasing firmware and attempting to start bootloader…
-
The module is in Bootloader mode.
Bootloader Version: 101
Device ID: 5424 -
Starting firmware update…
0% Failed to upload the firmware. Please unplug and restart.
** SODAQ Firmware Updater **
Version 1.4
Press:
- ‘b’ to enable bootloader mode
- ‘d’ to enable debug
…
- Starting HEX File Image Verification…
0% |||||||||||| 25% |||||||||||| 50% |||||||||||| 75% |||||||||||| 100%
HEX File Image Verification Successful!
The module did not respond in application mode. Please unplug and retry in bootloader mode.
The module did not respond in application mode. Please unplug and retry in bootloader mode.
The module did not respond in application mode. Please unplug and retry in bootloader mode.
The module did not respond in application mode. Please unplug and retry in bootloader mode.
completePage()
startNewPage(0x300000): starting at 0x300000
100%
completePage()
HEX File Image Verification Successful!
[initBootloader]
[applicationReset]
[expectApplicationString] expecting RN.The module did not respond in application mode. Please unplug and retry in bootloader mode.
[applicationReset]
[expectApplicationString] expecting RN.The module did not respond in application mode. Please unplug and retry in bootloader mode.
[applicationReset]
[expectApplicationString]
Logs from good update:
Before…
…
-
Starting HEX File Image Verification…
0% |||||||||||| 25% |||||||||||| 50% |||||||||||| 75% |||||||||||| 100%
HEX File Image Verification Successful! -
The module is in Application mode:
RN2903AU 0.9.7rc7 Aug 11 2016 15:07:56
Ready to start firmware update…
Firmware Image: RN2903AU_103
Please press ‘c’ to continue…
Erasing firmware and attempting to start bootloader…
-
The module is in Bootloader mode.
Bootloader Version: 101
Device ID: 5424 -
Starting firmware update…
0% |||||||||||| 25% ||||||||
After…
-
Starting HEX File Image Verification…
0% |||||||||||| 25% |||||||||||| 50% |||||||||||| 75% |||||||||||| 100%
HEX File Image Verification Successful! -
The module is in Application mode:
RN2903 SA1.0.3 Jan 23 2018 14:56:26
Ready to start firmware update…
Firmware Image: RN2903AU_103
Please press ‘c’ to continue…
And there you have it.
An updated RN2903 now at SA1.0.3
This issue is all also touched on here
I am sure it’s much easier to use the LoRaSuite-windows-1.0.exe from https://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=dv164140-2 (assume this is latest version?!) and a passthrough sketch. I’m going to try that now to fix the dead Sodaq One that I have…
If you try this,
Get the Lora development suit for windows
Install, but untick docker (only works on 32bit) & java (it’s an old version), read the readme, close.
Then install latest java
https://www.java.com/en/download/windows-64bit.jsp
Lastly, Using windows explorer go and run C:\Users\username\Microchip\LoRaSuite\Applications\LoRaDevUtility\LoRaDevUtility.jar
Put on some passthrough sketch, and maybe give the loradevutility a go. No idea if it’s going to work 
x
Hi guys
I have adapted the RN2483 sketch and included inside the Firmware V1.0.5 for RN2903 AU915.
It´s support class C.
You can download here:
Hope this can help. I have updated all my Sodaq Explorer Boards with this sketch.
Regards
Hugo