Close
0%
0%

RP2350 868 MHz LoRa board

A standalone board based on the RP2350 and SX1261 that can also act as an M5Stack module

Public Chat
Similar projects worth following

What is this?

This board is a LoRa transceiver operating at 868 MHz, which is one of the the frequency bands allowed for operation in Europe. It is mainly driven by an RP2350 controlling a Semtech SX1261 via SPI, whose output is further amplified by a TI CC1190. The form factor allows its usage as an M5Stack module by means of both the mechanical interface (4 M3 holes at the corner) and the M-Bus electrical interface.

Why did you build this?

The reasons are actually multiple ones. I wanted to experiment with the design of RP2350 based boards, and I had some ideas for microcontroller projects already floating; then, at the time I was lacking a Meshtastic radio for the proper band, so after duly purchasing one I started thinking about how difficult would it be to just go make one myself and adapt the firmware to use it. Since that typically makes use of a Bluetooth enabled micro like the ESP32, I thought to make this adaptable to a M5Stack Core I had lying around, with which I already used a LoRa module in the past. That specific module wasn't particularly user friendly (also I hate AT-based transceivers), so I settled on this present plan.

Specifications

Whilst I haven’t exactly followed a plan to a T, I did write down some initial specifications.

Functional

     
  • Must be used as a standalone module.
    I didn’t want to constrain the board to only work as an M5Stack module, so this implied the following interface requirements:  
       
    • status LEDs
    •  
    • USB interface
    •  
    • power interface
    •  
    • serial port
    •  
    • user buttons
    •  
     
  •  
  • Must be able to act as an RF module seen from the ESP32

Interface

  • Must work with the M5 bus.
    This both constraints the available serial interfaces, voltages (signals and power) and currents
  • Must be in a suitable form factor for the M5Stack
  • Must expose a debugging interface

Power

  • Should consume a low amount of power

RF

  • Must operate around the 868 MHz
  • If possible, use the newer chipset from semtech
  • Must be able to operate in close vicinity with the ESP32 without causing interference

Design choices

Components

MCU

The RP2354A will be used in order to save space, as it sports a large enough internal flash and is contained in a QFN-60 package, which is fine considering there is not much to be used

Modem and frontend

In order to reach a higher power output for Lora, the modem from Semtech will be accompanied by a frontend with a PA. The CC1190 from TI was a good candidate both from price and availability standpoint at supplier’s premise. It is able to reach 27dBm max at 3.6V supply and 13dBm input, however given the M-Bus supply it will most likely cap at 25.8dBm with the same input power. For this reason, after fixing the choice to the CC1190, the transceiver has been chosen to be the Semtech SX1261, which is limited in power to max 15 dBm, as opposed as its more powerful counterpart the SX1262. Other modems could be used as well but I’ve often seen low availability of the LR series and also it would be cool to keep the options open for lower bandwith, which the 1261/2 support, as well as lower sensitivity. Another pet peeve regarding the LR series is that the documentation is not as open as the SX series and thus it’s difficult to gauge whether it’s as flexible in using the “raw” LoRa mode as opposed as LoraWAN only (which i’m not presently interested about). Note: It’s most likely possible, given that the reference manual explicitly makes reference to such commands, but it’s presently very intertwined with the github repos, which I think would be a time consuming endavour to self-document and/or reverse engineer.

On board regulators

RP235x LDO from USB

This is going to be an optional component (or optionally enabled) in case of interest in using the module as standalone

External interfaces (non M-BUS)

RP235x debug port

  • SWD
  • UART

User interaction

LEDs
  • Status-error LEDs
  • Power LED
Switches
  • Reset button
  • Boot...
Read more »

  • Finally some progress on rev. A

    bru3s01/04/2026 at 20:58 0 comments

    Hi,

    happy new year!

    I'm finally managing to share some (very) long overdue progress on the state of the board, after a months-long hiatus due to work and unrelated issues.

    After finishing the design of the initial revision, I ordered two board prototypes from NextPCB, who did a very good job on the resulting hardware and in supporting engineering questions, as well as handling PCBA. I was very satisfied with their service.

    Below you can see a board with all the components on, as shared by the engineering team at NextPCB:

    The bringup procedure

    Bringup is fairly straightforward, especially in standalone mode (i.e. powered by USB):

    • Connect USB cable to a PC port with a proper USB-C cable
    • Measure voltage on pin 3 of JP1 -> should be around 3.3V
    • Disconnect USB, close 2-3 of JP1
    • Reconnect USB while keeping SW2 (BOOTSEL) pressed (button in the middle)
    • RP2354 should mount as expected
    • Load test firmware into memory
    • Check if LEDs blink and messages are sent via the USB virtual serial port
    • Disconnect USB, close JP3
    • Reconnect USB and, using the test firmware, check that the connection with SX1261 is working as expected
    • Disconnect USB, close JP4, connect a proper antenna via J1
    • Reconnect USB and, using the test firmware, check frequency synthesis and infinite preamble mode with an SDR

    With these steps, all major functional blocks - except the M-BUS connection - can be tested.

    So, since this is the first revision of the board, I inevitably ran into issues almost immediately when performing the procedure :)

    RP2354 woes

    As mentioned previously, I wanted to tinker with the RP2354 (thanks to production samples offered via NextPCB) instead of other microcontrollers in order to save board space that would have been taken by the QSPI flash. It somehow would have fit on the board if I wanted to, but again, I just thought it would have been more interesting to use the new version with internal flash. 

    Unfortunately, when routing the board, I missed an important section of the RP235x datasheet, i.e. 14.3, which states that 

    "The six dedicated QSPI pads on the RP2350 die (CSn, SCK and SD0 through SD3) connect to both the internal flash die and the external package pins. [...]",

    which in turn means that if you're using the version with internal flash, you should leave those pins unconnected, otherwise you're possibly directly affecting the signal levels of the QSPI bus.

    Having missed that, I proceeded to route the SX1261 DIO, RST and BSY signal to those QSPI pins, since they were pretty convenient due to their position and facing direction. Oops.

    You can read more information about this whole "investigation" on the relevant thread on Raspberry official forums. Suffices to say, the RP2354 would show up as a mass memory, ready to accept UF2 files, but would not run the executable correctly. To mitigate this, the offending traces had to be cut away.

    With this (pretty ugly) hack I was able to finally boot functioning software via the UF2 loader, confirming that at least the rest of the circuit for the MCU was working as expected.

    Another issue I encountered though, was when I tried to connect a J-Link debugger to the SWD port (J4) to make sure the debug functionality was operating correctly. That also led to all matter of weird issues when trying to upload the firmware via the debugger. This was confirmed a debugger side issue by Segger support themselves, stating that the capability to interface with the RP2354 is currently planned, but still not implemented.

    Despite this, if the flash step is skipped and the debugger is only used to analyze execution of the existing firmware (i.e. via UF2), everything works as expected (except maybe flash breakpoints - still haven't checked those).

    Mechanical issues

    The overall height of the board with its largest (tallest) elements does not quite fit beneath the M5Stack Core, at least not with the headers that M5Stack provides. I...

    Read more »

  • Interface with M5Stack "Faces" and ports

    bru3s05/07/2025 at 18:38 0 comments

    As mentioned in the project description, one of the driving forces behind the form factor of the PCB was that I had some products from M5Stack lying around unused, among which the original Core Grey and an expansion module called Faces (specifically the 2nd version), which adds some LEDs and a keyboard.

    I specifically wanted to make a T-Deck-like device, so I set forth constraining the PCB dimensions and positioning of components to that.

    A note on standalone mode

    The project specifications included a "standalone" mode and a "module" mode; these are two ways the device can be used, depending on whether it's mounted as an M5Stack compliant device or not.

    • In module mode, the RP2350 is treated as an SPI slave, receiving commands from the ESP32 core such as "set the power" and "transmit". In this mode
      • The USB port is not used for power supply
      • VBUS from M-Bus is used instead
      • The RP2350 either interprets commands or acts as a passthrough to the SX1261
        • it has no agency of its own (e.g. spontaneous transmission)
        • LEDs are treated as simple device indicators
        • user button events are relayed to the ESP32
        • serial debug is still used (possibly even USB, but unlikely)
    • In standalone mode, the RP2350 is instead used as either transceiver connected to the USB and receiving similar commands as if it was in module mode, or it reacts to time events or user button clicks to decide when to transmit. In this mode:
      • The USB port is used for power supply
      • VBUS from M-Bus is not used
      • SPI port to ESP32 is unused and can be configured as free GPIOs
      • user button events trigger actions fully within the MCU firmware
      • serial debug and USB interfaces are both used for logging and communication

    Ports

    The ports I wanted to have with the outside world were as follows:

    • USB-C for communication, programming and power supply
    • separate VBUS header to measure power consumption
    • M-Bus header for module mode and generic GPIO interface
    • serial port for logging and debugging
    • SWD port for serious debugging

    Additionally, I added 2 RP-controlled LEDs to indicate status, errors and whatnot to the user; three switches for RP boot, reset and custom action; and a power LEDs to quickly check 3v3 status.

    M-Bus

    The M-Bus interface follows the orientation used in the Faces II module; so that the bottom of this board will have to mount the female socket, and the male one to propagate that of the faces base.

    The following signals have been routed through it:

    • Power
      • 3V3
      • GND
    • RST signal to RP2350
      • Independently controlled with default asserted for RP (with pulldown)
        • RP reset line towards SX default asserted (with pulldown)
      • Note that per Core Grey schematic, the reset line from the ESP32 is low pass filtered
    • SPI

      • default pins + additional SS
    • Interrupt line

      • used by RP to signal TX done/RX done
    • BSY line

      • used by RP to signal operation in progress

    The RST line was a bit of a pickle since I wanted the OR'ing of all possible sources, but didn't want to do that via diodes. So I decided to put a dedicated IC, i.e. the SN74AHC1G08 (SN74AHC1G08DCKR for smaller SC70-5 footprint) with an additional line from the SWD via a simple resistor.

    Also, the M-Bus has also to control the Faces device, which takes up the following pins of the ESP32:

    • G15 (leds)
    • G16-G17 (GROVE port A)
    • G26-G36 (GROVE port B)

    Ports placement

    From the attached figure, you can see that there are already two limitations regarding the position of ports and headers:

    • on the right side, the M-Bus (can't see that from the picture actually, but you can check M5Stack docs) takes up most of the available board outline
    • on the bottom side you have the keyboard

    You can see the general outline of the board from the picture below.

    So I ended up placing the ports I was most interested in to the left and top side of the PCB.

    In particular, 

    • I've placed the USB port to the left to be consistent with the charging port of the M5Stack and to not have awkward pulling forces on the same side as the antenna...
    Read more »

View all 2 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates