I’m working with the XRP Beta board (Pico W version) and I’d like to add a SparkFun BlueSMiRF v2 so I can use Bluetooth as a wireless serial link (REPL/file transfer) instead of being tethered by USB.
From my research, the BlueSMiRF only needs 4 connections:
• VCC → 3V3 on the Pico W (pin 36)
• GND → any ground (e.g. pin 38)
• TXO (BlueSMiRF output) → Pico W GPIO1 / UART0 RX (pin 2)
• RXI (BlueSMiRF input) → Pico W GPIO0 / UART0 TX (pin 1)
• CTS/RTS left unconnected
On the Beta XRP board, the problem is that the Pico W doesn’t have the 2×20 headers soldered in by default — the controller PCB only breaks out motor, servo, encoder, and Qwiic connectors. So to make these connections, I’d either need:
• A Pico W with headers soldered so I can jumper into pins 1, 2, 36, and 38, or
• To solder directly to the Pico W pads or any breakout holes the Beta controller provides for those signals.
Could anyone confirm this wiring setup, and ideally share a wiring diagram or photo of how they connected a BlueSMiRF (or similar UART Bluetooth module) to their XRP Beta board?
This is the link to the XRP hardware specification You can select which board you are looking for. Both versions of the XRP already have ble available to them, and XRPCode can connect to them via bluetooth. If you still want to use the BlueSMiRF board, be aware that on the beta board all the GPIOs are assigned. In the specification above you can see how to cut some jumpers on the back of the board to free up a couple of GPIOs. Or you can use ones on ports like Motor 3 or 4, but be aware that they can still get used by the XRPLib API.
Thanks for clarifying. I’m developing in VSCode / Thonny with MicroPython — not using XRPCode — since XRPCode is a bit too limited for what I need. For the Science Olympiad Robot Tour event, anything Wi-Fi–based is strictly forbidden, so I really need a straight COM/UART link over Bluetooth.
Good to know about the GPIO assignment issue on the Beta board. Since I’ll never use Motor 3 / 4, repurposing those pins for the BlueSMiRF connection sounds like a workable solution. I also saw you mentioned cutting jumpers on the back of the board to free up GPIOs — that’s promising.
Follow-up request:
Has anyone in the community already wired up a BlueSMiRF (or similar UART Bluetooth module) to their XRP Beta board? If so, could you please point me to a photo or annotated diagram showing exactly which solder pads or headers that were used (especially for motor 3 / 4 or jumpers)? That would be extremely helpful for me to replicate safely.
Thank you for the information. And we hope you get things working. The internal bluetooth works off of the standard NORDIC UART. I haven’t seen a VSCode addon that works over bluetooth, but if you point us at it, we might be able to get it to work.
Also if there are features that would make XRPCode more useful for you please let us know, we are always looking to improve it.
Thank, I am trying to break the cable dependency. Being able to update code and get realtime feedback via bluetooth while the robot is running a maze makes debugging / optimization much faster.
I’m new to most of this on the hardware side, so I’m chipping away at my ignorance at this point.
Hi there! Sorry for not responding sooner, I’ve been out for a bit!
The radio on the XRP supports both WiFi and Bluetooth. If you were to only use the radio for its Bluetooth functionality without WiFi, would that be permitted by the competition rules? If so, that would simplify the hardware (though possibly complicate the software side compared to a BlueSMiRF).
To my knowledge, no one has done this before. However, I think it should be fairly straight forward. Instead of cutting jumpers, I’d suggest using the GPIO pins available from the Motor 3/4 connectors. Each one of these cables gives you access to 2 GPIO pins, GND, and 3.3V (can just cut the motor +/- wires).
In MicroPython, you’d need to set up a dupterm to duplicate the USB terminal over UART for the BlueSMiRF. Can do with the following:
from machine import UART
import os
uart = UART(id=0, tx=0, rx=1) # For Motor 3 connector
#uart = UART(id=1, tx=8, rx=9) # For Motor 4 connector
os.dupterm(uart, 0)
Note that the CTS and RTS pins are typically not needed, so you should only need 2 GPIO pins for TX and RX. Also make sure to connect the TX of the BlueSMiRF to the RX pin of the XRP (GPIO 1) and vice versa.
You should add this code to your main.py to ensure it is always set up whenever the board is rebooted.
Back again: I’m running into what I suspect is a simple configuration issue and was hoping someone could test a similar setup to confirm.
Hardware setup:
SparkFun XRP Final Board (RP2350)
BlueSMiRF v2 (with headers)
Connected using either breakout pins or the Motor 3/4 port GPIOs
I’ve also tested a few alternate pairs (breakout, motor port, and even the Qwiic line pins).
Behavior:
Windows pairs with the BlueSMiRF without issue.
Two COM ports are created (COM6 and COM7).
I can connect to either port in PuTTY (depending on TX/RX wiring), and I see a solid green light on the BlueSMiRF — so the link is definitely active.
However, I never get a MicroPython prompt or any response to input (e.g., sending $$$ to enter command mode). The terminal just sits blank.
What I’ve tried:
In Thonny (via USB), I’ve redirected the REPL to UART as follows:
from machine import UART, Pin
import os, time
uart = UART(0, baudrate=9600, tx=Pin(44), rx=Pin(45)) # or other GPIO pairs tested
time.sleep(0.2)
os.dupterm(uart)
print("UART REPL enabled on UART0 @9600")
I’ve also tried os.dupterm(uart, 0) and using raw GPIO numbers (e.g., tx=44, rx=45) directly.
I’ve tested multiple baud rates. I initially kept 9600 since that’s what Windows assigns to the COM port by default, but also tried 115200, which the BlueSMiRF typically defaults to.
I’ve verified that the BlueSMiRF is properly powered (3.3–6V on VCC, logic at 3.3V) and that GNDs are tied together. CTS/RTS are not connected.
Despite this, I can’t get any serial response or MicroPython prompt through the Bluetooth link.
If anyone has an XRP board and a BlueSMiRF, could you try enabling UART REPL on any available UART pins and see if you can get an interactive prompt over Bluetooth? I’d like to confirm whether this is a pin mapping or REPL routing issue specific to the RP2350 port of MicroPython.
Goal:
Treat the Bluetooth serial link (COM7) as transparently as the USB COM port (COM5) — full REPL access over Bluetooth.
Any insights on verified working UART pin pairs or MicroPython configuration for the RP2350 would be appreciated.
Are you using the Beta XRP with the RP2040, or the new board with the RP2350? Your previous posts stated the Beta XRP with the RP2040, in which case GPIO 44 and 45 are not valid. If you actually have a new board with the RP2350, the correct UART GPIO should be:
uart = UART(id=0, tx=2, rx=3) # For Motor 4 connector
#uart = UART(id=1, tx=22, rx=23) # For Motor 3 connector
Also FWIW if you’re using the new board, you can use the headers instead of the motor connectors. GPIO 12-19 are left available for the user to do whatever you want with them, so no need to sacrifice one of your motor connectors. machine.UART(0) defaults the TX/RX pins to 12 and 13 respectively.
@sparkfro
Update: I was able to get it working using your recommendation of GPIO 12 and 13, and shortening
uart = UART(id=0, tx=12, rx=13)
to:
uart = UART(0)
I also switched to new cables, in case one was causing problems.
I’ll play around with baud rates etc, but I’ve got the most important part working, thanks again for your help!!