-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added support for SAMR34-based boards #286
base: master
Are you sure you want to change the base?
Conversation
… firmware from Microchip (repo: https://github.com/MicrochipTech/atsamr34_lorawan_rn_parser). Tested with MLS 1_0_P_6 (Parser_ECC608) and WLR089 Xplained Pro. Should be backwards-compatible with standard RN2xx3 modules.
…4 and autobaud for RN boards)
This sounds great. @johanstokking what do you think about this? Do we want to include support in our library? I should have an SAMR34 devkit somewhere on which I can test this to confirm before merging. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is pretty cool indeed, thanks @danalvarez
It would be great if you can test this @jpmeijers !
Default baud rate of RN2xx3 (and this library): 57600 I can't get this to work yet. The SAMR34 keeps on replying with Test setup:
SendOTAA output:
|
The problems I'm seeing is related to the required @danalvarez I would recommend that you add an example sketch to this library that shows how to initialise and use the SAMR34 running RN parser. It seems that this module is just enough different from the RN2xx3 that the existing example sketches won't work out of the box. |
…both with RN2xx3 or SAMR34. Removed CheckModule.ino example, this procedure has been moved to DeviceInfo.ino, where it makes more sense. Changes to TheThingsNetwork.cpp: 1. Added the mac_joineui command to mac_options, which is used to obtain the appeui in SAMR34 RN parser firmware 2. Added the mac_edclass command to mac_options, which is used to set the LoRaWAN class in SAMR34 parser firmware 3. Added getModemType and setModemType functions 4. Modified personalize: only perform soft reset on RN2xx3 boards 5. Modified provision: only perform soft reset on RN2xx3 boards 6. Modified provision: send mac set appeui or mac set joineui for RN2xx3 or SAMR34 boards, respectively 7. Modified provision: only send mac save on RN2xx3 boards 8. Modified setClass: send mac set class or mac set edclass for RN2xx3 or SAMR34 boards, respectively 9. Modified showStatus: optain appeui via mac get appeui or mac get joineui for RN2xx3 or SAMR34 boards, respectively
@jpmeijers Thank you for testing this. Indeed, the library's default It is also important not to soft reset the module when performing a call I also noted that some commands (namely: I have added steps in the I have also updated the documentation to reflect these changes. Let me know if you have any questions or suggestions. PSNote that you can chage the default baud rate of the RN parser firmware by editing the |
…s to automatically check modemType
Hello @jpmeijers , do you think you might have a chance to test this? I've addressed your change requests. :) |
Bump |
Yes, will hopefully get to this in the coming week(end). Was in Europe for 3 weeks for the conference. |
I'm still facing some issues. At startup the DeviceInfo sketch hangs for 30 seconds trying to read the EUI from the SAMR34. Another thing that I do not like is all the extra custom code that is added to the examples. The API needs to be simple to use, but with all these changes it is becoming quite complicated and unclear what is needed. The only way to solve this is to move all init code into a single init function that can play the role of single entry point, which is called in setup(). Depending on which module is detected the init function can run the required reset/init code. To be honest I'm starting to think adding SAMR34 support to this repo is not worth it. Maybe we should rather keep this support in a separate repo, like under @danalvarez's account. DeviceInfo.ino output
Sniffing SAMR34 output:
|
Based on my TTN forum post
I have recently been tinkering with a WLR089 Xplained Pro board, which is based on the SAMR34. This new LoRa modem is intented to be used as a standalone microcontroller + radio solution from Microchip, but I found Microchip also released a firmware for the modem in which the standard ASCII commands used for the RN2xx3 chips can be used to control it. It’s called the RN parser.
Since the RN parser firmware largely emulates the behaviour of the RN2xx3 modules, this PR adds support for the SAMR34 to this library.
Changes
The main changes to this library to add SAMR34 support are listed below. These have also been updated in the documentation in
docs/TheThingsNetwork.md
.TTN_HEX_CHAR_DETECT_CASE
macro, because downlinks in the SAMR34 firmware are sent with lower-case ASCII, while the RN2xx3 uses upper case.compare_table
, to be used when checking a valid module is connectedsys_sleep_standby
tosys_table
, because SAMR34 is sent to sleep by issuingsys sleep stansby <ms>
, instead of justsys sleep <ms>
as in RN2xx3.macReset
command, which was not implemented before and is necessary with SAMR34 because a mac reset must be issued to start the LoRaWAN stack on power on.mac_reset_table
showStatus()
to not show the battery voltage and APPEUI when working with a SAMR34, because these commands are not implemented in the RN parser firmwarecheckValidModuleConnected()
sleep()
to sendsys sleep standby <ms>
for SAMR34 boards, still backwards compatible with RN2xx3wake()
to take a pin as argument when working with SAMR34, because this module is not woken up viaautoBaud()
but rather via an external pin interrupt (more info here). Still backwards compatible with RN2xx3.Tested commands
Here is a list of the commands I have personally tested with the WLR089 module:
Some Final Notes