Challenger RP2040 LoRa (868MHz)
The Challenger RP2040 LoRa is an Arduino/Circuitpython compatible Adafruit Feather format micro controller board based on the Raspberry Pico (RP2040) chip.
This is a spin-off from our Challenger RP2040 WiFi board but we have replaced the WiFi module with a low power LoRa radio module from Hope RF. The transceiver features a LoRa long range modem that provides ultra-long range spread spectrum communication and high interference immunity whilst minimizing current consumption.
LoRa
The integrated module LoRa module, RFM95W, can achieve a sensitivity of over -148dBm utilizing a low cost crystal and bill of materials. The high sensitivity combined with the integrated +20 dBm power amplifier yields industry leading link budget making it optimal for any application requiring range or robustness. LoRa also provides significant advantages in both blocking and selectivity over conventional modulation techniques, solving the traditional design compromise between range, interference immunity and energy consumption.
The RFM95W is connected to the RP2040 via SPI channel 1 and a few GPIO’s that is required for signaling. A U.FL connector is used to attach your LoRa antenna to the board.
- 168 dB maximum link budget.
- +20 dBm – 100 mW constant RF output vs. V supply.
- +14 dBm high efficiency PA.
- Programmable bit rate up to 300 kbps.
- High sensitivity: down to -148 dBm.
- Bullet-proof front end: IIP3 = -12.5 dBm.
- Excellent blocking immunity.
- Low RX current of 10.3 mA, 200 nA register retention.
- Fully integrated synthesizer with a resolution of 61 Hz.
- FSK, GFSK, MSK, GMSK, LoRaTM and OOK modulation.
- Built-in bit synchronizer for clock recovery.
- Preamble detection.
- 127 dB Dynamic Range RSSI.
- Automatic RF Sense and CAD with ultra-fast AFC.
- Packet engine up to 256 bytes with CRC.
We support both 868MHz and 915MHz systems by using the specific LoRa module (RFM95W-868S2, RFM95W-915S2) as required for each region.
Pinout
LiPo battery / charger
The board is equipped with a standard 2.0mm JST connector for connecting a rechargeable LiPo battery. There is also an internal battery charger circuit that charges your battery as long as a USB cable is inserted or the VUSB connection is connected to 5V.
USB Type C
In the recent years we have noticed that we are seeing more and more USB Type C cable laying around the lab due to the fact that all new phones and accessories use them. As of yet we haven’t seen any shortage of micro USB cables but we are not getting any new ones any more and old ones do break occasionally. So we decided to go for a USB Type C connector for this board. A bonus of this is that they are quite bit more durable and you don’t have to fiddle with the cable before plugging it in.
brian.n.norman –
I have only tested the LoRa aspects of this board. I like the board for it’s features but haven’t used it in anger yet.
I bought it a while ago from the Pi Hut and recently got around to trying to get it to work using Sandeep Mistry’s pico-lorawan code from github. The problem I had was that the code assumed spi0 and would not use spi1. There’s a bug in the spi-board.c file which I fixed and notified Sandeep about. I have documented this here https://github.com/BNNorman/ilabs-challenger-rp2040-lora
Once the code bug was fixed the board joined TTN and worked just fine using the otaa_temperature_led example.
Why only 4 stars? – well, that’s down to the pain I had getting it to work. Code examples are non-existent. Design files assume we all have Eagle – a JPG would be useful to most people. I couldn’t find any information about how much current is drawn if the board is put to sleep
In all other respects a nice board.
Pontus –
Hi Brian,
Please try to ease yourself =), we certainly do not want our customers to have a heart attack by something so earthly as electronic devices =)
I acknowledge your problem, which is something that we have encountered ourselves while building and testing the product.
We have tried to reach out to the different maintainers of the existing LoRa and LoraWan libraries to try and sort this out. They have either not replied or acknowledged the problem but not replied on our suggestions on how to resolve to this.
This is a major problem to us and we could possibly provide (and we might still do) our own forks of their software where this is solved but for us this is not the real solution.
We consider having a hard coded SPI port basically a library bug and might eventually escalate it to this on their github pages.
It is great that that you, as a customer, have alerted us to this as this will put more weight on the library maintainers.
Best regards
Pontus Oldberg
@invectorlabs