I recently bough a Cow Tracker … for a project to track wild horse in Namibia. With a little recent experience in TTN and LoraWAN, I have got it conneted to TTN and displaying a position in Node Red.
However it is not clear to me from the instructions
Enable the cayenne low power payload by sendingcay=1in the bootmenu of your device.
Therre must be some place in the code to be compiled (as there is for the AppEUI’s) to set these parameters.
In particular, I am concern about the drop in battery voltate over three days…while in the South of England Sun… and may not have some low-power setting enabled
If you scroll down on the page you linked, refer to the section under ONE v3 titled Universal Tracker - SODAQ payload and Cayenne LPP, Configure Your Board.
You will need to connect to your board with a Serial Monitor. The three parameters you mentioned (ADR, SF and Cayenne) are set by command. Once set, save the configuration and allow the tracker to exit the config mode.
I’m surprised you were able to get your board connected at all as this is the same process used to enter the DevEUI, AppEUI and AppKey.
There might be a number a few things happening here which could result in another SF being used. Primarily, either the device is not being configured for the correct SF or ADR is not being disabled, or somehow those settings are being overridden on the MAC layer.
To start with I would recommend enabling full debug for the RN2483 library and capturing all the raw commands and response sent during the configuration. Using that it will be possible to confirm that at least the configuration is being done correctly.
In order to enable debug, you need to make sure the ‘#define DEBUG’ in the cpp file is not commented out. Additionally, the instance needs to be assigned a debug / diagnostic stream.
Additionally, the instance needs to be assigned a debug / diagnostic stream.
but there is (as one might expect) now change in the SF7
I have a particular interest in the SF as the plan is to use this to track wild horse in Namibia, and range is therefore important… and at the same time the Gateway is not likely to be overloaded.
I performed some tests by setting the sf to different numbers (7,9,12) and there is no change in the rssi number/snr… from which I conclude that - notwithstanding what the ternal says, the SODAQ ONE is not changng the sf parameter.
Thanks for sharing the version of the Universal Tracker you use.
I can see in your order you bought a EU version RN2483.
Here you can use all spreadingfactors. 7, 8, 9, 10, 11 and 12.
There is a known bug in the v1.0.3
In the systemSleep() you should remove “network.setActive(false);”
I recommend to not change anything in the LoRaHelper.
Keep the changes to the config.cpp and the .ino
You should be able to check in the menu the current/used settings.
I don’t see anything in the code what could cause an issue.
Can you turn on debug, dbg=1 in the menu.
And share the logfile. You can email it to me jan at sodaq dot com.
I fear, Jan , that this problem has returned… in an odd way
I now have two Cow trackers: The firse one I bout, which was “removed” while testing, but has now been recovered, and a second one.
The second one - refere two above - is working with the
There is a known bug in the v1.0.3 In the systemSleep() you should remove “network.setActive(false);
code in place, and give me sf=12
The initial one - recovered - for some reason had failed - would not join TNN, and I therefor purchase a new SODAQ one board and install it inthe old housing (reusing the battery and solar cell)
That has sf=12 set, has joined TTN, with the same code, but different DEVEUI etc…
I fear that the SF12 working one has been shipped to Namibia, so I now don’t have access to that one anf more…and the people who will be trying to use it are not “geeks” (I’m a part-time geek)
I downloaded the RN2483 Firmware updater.
Made a guess that I needed the RN2483_105 version,and loaded it in (I hope)
#error “Please define one the the following: HEXFILE_RN2483_101, HEXFILE_RN2483_103, HEXFILE_RN2903AU_097rc7, HEXFILE_RN2903_098”
12:56:19.356 -> …
12:56:19.856 ->
12:56:19.856 -> * Starting HEX File Image Verification…
12:56:19.856 -> 0% |||||||||||| 25% |||||||||||| 50% |||||||||||| 75% |||||||||||| 100%
12:56:23.882 -> HEX File Image Verification Successful!
12:56:25.285 ->
12:56:25.285 -> * The module is in Application mode:
12:56:25.285 -> RN2483 1.0.5 Oct 31 2018 15:06:52
12:56:25.285 ->
12:56:25.285 -> Ready to start firmware update…
12:56:25.285 -> Firmware Image: RN2483_105
12:56:25.285 ->
12:56:25.285 -> Please press ‘c’ to continue…
12:56:41.352 -> Erasing firmware and attempting to start bootloader…
12:56:43.549 ->
12:56:43.549 -> * The module is in Bootloader mode.
12:56:43.596 -> Bootloader Version: 101
12:56:43.596 -> Device ID: 5424
12:56:43.596 ->
12:56:43.596 -> * Starting firmware update…
12:56:43.596 -> 0% |||||||||||| 25% |||||||||||| 50% |||||||||||| 75% |||||||||||| 100%
12:57:18.229 -> Firmware update has finished successfully! Please unplug the module to restart.
12:57:18.229 -> Elapsed Time: 35.88s