rfm95 support

[sillevl]

Trying to get these drivers working with the rfm95 module from hoperf (http://www.hoperf.com/upload/rf/RFM95_96_97_98W.pdf), I noticed that the driver is compatible with the SX1276MB1LAS configuration. This means, setting the _ant_switch to high (with a pullup resistor), it will get the module working perfectly.

The means that we need to sacrifice an IO pin just to get the module working. I tried to solve this by inheriting from the SX1276_LoRaRadio class. This should be a clean solution, as it does not alter the source in any way.

A problem arises when trying to override the set_sx1276_variant_type() where I want to skip the _ant_switch code, and set the radio_variant manually to SX1276MB1LAS. radio_variant is declared as static, and outside the scope of the class. This means that I don't have access to the variable to set it manually.

At the moment the implementation does not allow for a configuration where the antswitch is hard wired with a pullup or pulldown resistor. The functionality would allow support for the rfm95 board, and its variants.

I would like to propose a means to make it configurable to skip the antswitch detection depending on an IO pin, and make it possible to set it in code. Would it be possible to add this feature? I see many options to add this feature.

• changing the scope of the radio_variant so that it accessible in derived classes
• adding setter/getter methods for the radio_variant variable (additionally, add behaviour that skips antswitch code when the pin is set to NC)
• adding conditional pre-processor directives that can enable or disable manual antswitch at compile time
• adding a is_rfm95 property just like the is_murata property, that can enable/disable antswitch at runtime

Many possibilities to make the driver more generic. I would like to start a discussion on how this could be tackled, and maybe provide an possible solution.

[kivaisan]

Our LoRa radio drivers are just a reference implementation and therefore application / hardware specific changes are very likely needed.

If you have some good ideas and want to contribute them back to our driver, feel free to make a pull request and we can evaluate it.

[kivaisan]

@sillevl could you check if PR #15 is suitable also for your use?

[sillevl]

@kivaisan I did a test of PR #15 with the RFM95 board, and can confirm that this implementation is working correctly. Thank you for the effort.

[kivaisan]

Closing this issue as resolved.