Has anyone had any success with these at all? I ask because there are several compilation errors in the RadioHead Library for this
configuration
[env:wiscore_rak4631]
platform = [email protected]
board = wiscore_rak4631
framework = arduino
monitor_speed = 115200
upload_speed = 115200
lib_deps =
mikem/RadioHead
Or has anyone integrated any 433 MHz RF receiver with the RAK4631? If so, what library did you use for the RF receiver?
The RAK4631 has a LoRa transceiver inside. Even the RF path is not optimized for 433MHz, you can still use the SX126x-Arduino Library and set it to EU433 (if LoRaWAN) or set the frequency to 433MHz (if LoRa P2P).
RAK4631(L) for the 4xx MHz frequencies will come soon.
But if you want to use an external LoRa transceiver, can you post the compile errors please.
This is not for a LoRa transceiver, but rather a regular radio receiver … the compile errors are in the RadioHead Library. I’ve not used the library before, so I have no idea if it compiles for other boards, but I imagine it does, I’ve certainly heard of this library and the current version was released 11 months ago it seems
I’ve actually searched the rest of the library for TCCR1A, TCCR1B, WGM12, OCRA1A, TIMSK and OCIE1A, but cannot see their use anywhere other than in RH_ASK.cpp, so I figured I just comment out those bad boys and see if the library will then compile.
It doesn’t because of the last error:
.pio\libdeps\wiscore_rak4631\RadioHead\RH_ASK.cpp: At global scope:
.pio\libdeps\wiscore_rak4631\RadioHead\RH_ASK.cpp:714:4: error: expected constructor, destructor, or type conversion before '(' token
ISR(RH_ASK_TIMER_VECTOR)
After running with -E build_flag, I’ve had a look in RH_ASK.cpp.o and it looks okay to me, unless ISR needs defining for the platform or something.
# 714 ".pio\\libdeps\\wiscore_rak4631\\RadioHead\\RH_ASK.cpp"
ISR(TIMER1_COMPA_vect)
{
thisASKDriver->handleTimerInterrupt();
}
I’m not entirely certain that this ISR is needed (because I can find no references to it at all), so I’ve just gone ahead and commented out that too and I have a successful build (but we all know that just because it builds doesn’t mean that it works) … I’ll let you know what happens
Update: the ISR() member appears to be managing the Tx and Rx timers, so it is needed, but the code just won’t compile 
I am sorry for your problems, but I think you better ask Paul Stoffregen how to solve this problem. GitHub - PaulStoffregen/RadioHead: Version of RadioHead library for Teensy boards
I cannot solve problems of his library.
That code in your error messages is specific to the hardware timers on an ATmega chip, it’s not going to work on this platform.
Officially the RadioHead library supports the nRF52 as a platform, so if you go to the upstream originals you may be able to get that to work. Be careful to distinguish nRF52 as the platform from the driver for the nRF52’s 2.4 GHz/BLE radio, which is not what you’re looking for.
I don’t think Paul Stoffregen would have much to do with Radio Head except as modified for his Teensy brand of boards, and as far as I know those aren’t nRF52 based - the nRF52 code in his fork is presumably just that inherited from the upstream source.
Kind of says to me that the wrong path has been taken (i.e. incomplete #defines) in the preprocessor, for this platform.
I’m not really okay with what is and is not included when compiling against a framework and platform and I really don’t see where many of these preprocessor defines are expected to come from.
Looking through the RadioHead source, there is definitely an expectation of NRF52 being defined somewhere, but I cannot find anywhere that would provide such a #define
NB: I’m working on a windows machine … search is somewhat rubbish on Windows, I have to say.
@cstratton
You are right, the Github repo is a special version.
@billr
I found this page for the original version. But it seems it was not updated since 2014.
The version history on there shows the latest changes were last month. It is an active project.
Your most productive path would probably be to try to find an example of using radiohead on another nRF52 target. The catch of course is that you’re trying to use it to operate an external radio, rather than the internal 2.4 GHz one - so you really need an example using the OOK radio.
Making it work probably goes beyond headers - different actual source code would be needed to time inputs based on the nRF52’s timer hardware which is drastically different than an ATmega’s. It’s within the realm of possibility that no one has invested the time in making that particular combination of radio type and host MCU work.
Another possible course of action would be to add an ATmega to operate the OOK radio and then use something (maybe a serial UART?) top send the result into the RAK module’s nRF52. In a parts count way, that’s wasteful, in getting one setup to work, it might be efficient. Though reliably receiving serial messages in an embedded firmware can take some experience.