Elecrow CrowPanel PICO HMI 4.3″ Display – Review

MakerIot2020.com is usually about my creations, or at least my attempts to create something. Today we shall change that, and publish a Review of the Elecrow Crowpanel PICO HMI 4.3″ Display.

While I usually do not do any sponsored reviews of products, I decided to make an exception in this case. Why? Well, when I received the product documentation for this module from Elecrow, I was immediately interested, since the module fit in perfectly with a project that I was working on, and while it was quite obvious that there would be a huge learning curve involved, with many hours spent chasing documentation and other resources, I believed that the potential functionality and thus gain for my project would make all of this worth-while.

What is this module exactly?

CrowPanel Pico Display is an HMI module series that utilizes the powerful Raspberry Pi RP2040 (ARM Cortex-M0+) as its main controller. It is equipped with a 32-bit dual-core chip running at a clock frequency of up to 133 MHz. With 264kb of built-in SRAM and a 2MB flash memory chip, it integrates power supply, voltage regulation, and counter functions into a single microcontroller. This series of touch screens incorporate high performance, low cost, and user-friendly features.

The Pico 4.3” Display has a 320*240 resolution and capacitive touch for more sensitive control. It has flexible I/O peripherals and a unique programmable input/output (PIO) subsystem, including practical communication interfaces such as I2C, UART, common IO ports, and USB. It also has a built-in BW16 wireless network module, dual-band Wi-Fi (2.4GHz or 5GHz) + low-power Bluetooth 5.0, supports remote monitoring and network management functions, and easily accesses IoT devices and systems. It is also equipped with functions such as a lithium battery interface and a buzzer alarm and can communicate with almost any external device, providing professional users with excellent flexibility and scalability, and achieving seamless connection with the physical world and smart home control.

The module comes with abundant resources, including development SDK, and documentation. It has a very low entry barrier, making it suitable for beginners and hobbyist users. It not only can use Arduino IDE and CircuitPython to program, but also supports the LVGL graphics library and Squareline Studio to customize the desired UI interface. It serves as an excellent platform for machine learning applications and is the preferred solution for Pico-like HMI interaction terminals.

  • 4.3 inch Pico Display: 320*240 resolution, IPS Panel, capacitive touch and support multi-touch
  • RP2040 Microcontroller: Equipped with a 32-bit dual-core chip, it achieves a maximum clock frequency of 133 MHz.
  • Wireless connection: Support 4GHz IEEE 802.11b/g/n and 5GHz spectrum range, support Bluetooth 5.0 and BLE
  • Energy Efficiency: Supports low-power sleep and hibernation modes, promoting energy conservation and environmental consciousness.
  • Exceptional Extensibility: A wealth of interfaces, including I2C, UART, IO ports, USB, a lithium battery interface, and a buzzer alarm, ensures remarkable extensibility.
  • Ease of Use: A user-friendly experience is guaranteed with the provision of a detailed development SDK, and comprehensive documentation, ensuring a smooth learning curve.

Specification


  • Main Chip: RP2040
  • Processor: Dual-core 32-bit ARM Cortex-M0+ @ 133MHz
  • Memory: 264kB on-chip SRAM (supports up to 16MB of off-chip flash memory)
  • Screen Size: 4.3 inch
  • Resolution: 320*240
  • Signal Interface: SPI
  • Touch Type: Capacitive Touch
  • Panel Type: IPS
  • Power Input: 5V-2A
  • Active Area: 95.04*53.856mm(W * H)
  • Dimensions: 124.7 * 76 * 14.2mm(W * H * D)

Unboxing and initial thoughts

The display module came very well packaged.

and includes the display module, a USB-C programming cable and a single 4 way io cable

All the GPIO breakout headers, as well as the Reset and Boot buttons are located on the back of the module. This may be a double edged sword though, as I am still unable to find a way to gain access to these pins without the buttons, while soldering wires directly to them is definitely possible, I really don’t want to do that. Access to these buttons are quite essential, as they are needed to program the device, and once mounted into an enclosure, access to them will be quite difficult, without completely disassembling the enclosure. Time will however tell if this is really a problem or not.

Dissasembly – Looking at the stuff inside

I disassembled the unit because we must look at what is inside – otherwise, we would not be makers, would we? The quality of the PCB seems to be very high, with detailed silkscreen legends everywhere.

Let us take a closer look at a closeup

From what I can see, everything seems well organised, with all relevant circuitry in blocks. The Wifi and Bluetooth module is correctly placed on the right-hand edge of the board, ensuring that we shall have no issues with signal strength, also note that the antenna area is free of tracks and copper pours.

My initial thoughts – about the hardware

The PCB seems to be of very high quality, and the layout of the board clearly required a lot of thought. The unit has a very solid “feel” to it.

However, I do not like the choice of gpio connectors on the board. Screw-type terminals may have been better, at least in my opinion. The Reset and Boot buttons, as previously mentioned are at the back of the board, this may present issues if the panel is mounted into an enclosure. Additional header pins, to enable the installation of external buttons would maybe have been a good idea – time shall however tell if this is really a problem or not.

Supplying power to the board is another issue. Using a USB-C connector is in my view appropriate for bench use. Installing and using this module in a “real-life environment” would require a different type of connector, like a screw-terminal type, that would make it easy to connect power to the unit from more types of power supply units – I am specifically thinking of using it in an Automotive environment, where USB ports are not necessarily always available

Gui Generation – the LVGL graphics library and Squareline Studio

Squareline Studio seems quite sufficient to generate basic GUIs for the display module. The interface is relatively easy to use, and the widgets available is sufficient for a functional, although fairly basic GUI interface. It is possible to code directly in LVGL and add any advanced or customised widgets that way – although this should be done directly in your programming IDE of choice.

It is possible to export your generated GUI directly to Arduino code, and from there make changes to get things working – but with a few very important caveats.
1) It seems that SquareLine Studio suffers from version creep, with new versions popping up in incredibly short timeframes. This means that the latest version does not generate all the required Arduino files anymore – the main .ino file seems to always be missing, with only .c and .h files being generated.

This makes it necessary to perform a few extra steps to get things going ie.
– Copy the example project from Elecrow into a folder – this includes a .ino file
– Remove example Gui related files
– Rename the .Ino to <xxxxxx>.ino (as required by your project )
– export the GUI code into this folder
– edit the .ino file to include you custom code etc…

This results in a successful upload to the board, with a fully functioning Gui… but is a bit of a roundabout way to get things done. Let us see what happens in the future, maybe this will be repaired in future?

Documentation and other Resources

Elecrow has made a lot of written documentation available on their website, here. There are links to all the different RP2040-based Crowpanel modules.
It is however VERY VERY important to note that some of the documentation presented here seems to be incomplete, especially the 4.3″ display module, which uses a completely different display driver than the other members of the RP2040 Crowpanel devices…

I would thus recommend that potential users take a VERY close and detailed look at Elecrow’s YouTube tutorial on these boards, available here. These videos
highlight all the differences, and gets you up and running in a few minutes – with the unfortunate issue of using video to teach technical things – you will have to pause and continue quite a few times… It is however completely worth it in the end, as the information presented is perfect, and invaluable to get started with this module…

Pinout

Pin NameDescriptionConnect Type
PWRPower LED.
RSTReset button. Press it to reset the system.
BOOTHold the BOOT button and press RST button to make the RP2040 enter flash mode.
TF
Provide offline save and extra storage space.
UART0Build the communication among Logic modules, including serial communication module and print module.
GPIO_DConnect with external hardware devices to realize communication, control, or data acquisition with external devices.HY2.0-4P
I2CConnecting microcontrollers and other peripheral devices.HY2.0-4P
BATConnect with the lithium battery. Connect USB-C port to charge the battery.PH2.0-2P
ADCBy analyzing and processing the input signal, the control system can realize the precise control of the controlled object.HY2.0-4P
PICO 4.3-inch HMI PortPin Number
I2CGP2(SDA), GP3(SCL)
UART0RX(GP1); TX(GP0)
UART1RX(GP5); TX(GP4)
GPIO PinsGP0~GP3, GP6,GP7, GP16,GP17,GP22,GP26~28
ADCGP26(SDA),GP27(SCL)

Conclusion – and next steps – for me at least

I am pleasantly surprised with this module. yes, the learning curve is steep, and there are a few very uncomfortable runarounds that has to be performed to use Squareline Studio together with the Arduino IDE to generate GUIs for the module.

We do however have to remember that Squareline Studio and Elecrow are two different companies. The GUI generator has to cater for many different hardware devices. It would thus be unfair to say that the Elecrow Crowpanel module has a problem, just because Squareline Studio requires you to jump through a few hoops to get things working with the Arduino IDE.

I am thus giving the module a thumbs-up and saying all is good. However, I would like to see some improvements in connectors, especially for powering the device, as well as connecting a battery to it, screw-terminals would be much more convenient.

Externally accessible headers for at least the Reset button would also be a very good idea.

Performance-wise, I received a 16mb flash version from Elecrow, and it is snappy, to say the least… the graphics are well-defined and clear, and the touch interface is very responsive.

As mentioned before, the learning curve is steep. This is not a device that you can pick up and start running within a few minutes – You will have to invest some time to get familiar with it – believe me, it will be worth all of that effort!

As for my future projects, I am currently busy interfacing the 4.3″ Crowpanel HIM module with one of my custom PCB projects and will report back more on that once the project is completed.

XIAO RP2040 Mouse Ver 3.0

Over the last few months, We have been steadily improving the design of our XIAO RP2040-based mouse device. With this, ver 3.0 all the hardware bugs were finally eliminated, and we also placed the device into its first-ever enclosure.

Let us take a look at the design

The PCB and Schematic


The PCB is a very strange shape, with lots of cut-outs. This is to accommodate the big push buttons that will be mounted in the enclosure, as well as to fit nicely into the mounting area of the enclosure… This design took quite some time with a pair of callipers and CAD, but all went well, and the shape is perfectly accurate.


The schematic is also straight forward, with the only real changes begin to the rotary encoder. In ver 2.0, We connected the encoder to the MCP23008, but for some reason CircuitPython does not seem to like an encoder connected to an IO extender… That forced us to do some software hack to use the encoder… I have thus decided to change things around in ver 3.0 and move the encoder back to the native GPIO on the XIAO RP2040

It is also interesting to note that the circuit was initially designed for the XIAO ESP32S3, but due to issues with stock, as well as crazy prices on local parts, we made a quick turn-around and went back to the RP2040. The ESP32S3 was going to allow us to implement a wireless device, through using ESPNow protocol… That may still be done in future, but for now, I think we have done enough work on the mouse device for the time being…

Manufacturing the PCB and Assembly

I choose PCBWay for my PCB manufacturing. Why? What makes them different from the rest?

PCBWay‘s business goal is to be the most professional PCB manufacturer for prototyping and low-volume production work in the world. With more than a decade in the business, they are committed to meeting the needs of their customers from different industries in terms of quality, delivery, cost-effectiveness and any other demanding requests. As one of the most experienced PCB manufacturers and SMT Assemblers in China, they pride themselves to be our (the Makers) best business partners, as well as good friends in every aspect of our PCB manufacturing needs. They strive to make our R&D work easy and hassle-free.

How do they do that?

PCBWay is NOT a broker. That means that they do all manufacturing and assembly themselves, cutting out all the middlemen, and saving us money.

PCBWay’s online quoting system gives a very detailed and accurate picture of all costs upfront, including components and assembly costs. This saves a lot of time and hassle.

PCBWay gives you one-on-one customer support, that answers you in 5 minutes ( from the Website chat ), or by email within a few hours ( from your personal account manager). Issues are really resolved very quickly, not that there are many anyway, but, as we are all human, it is nice to know that when a gremlin rears its head, you have someone to talk to who will do his/her best to resolve your issue as soon as possible.

Find out more here


Assembly was quite easy, I chose to use a stencil, because the IO Expander chip has a very tiny footprint, as well as a leadless package… The stencil definitely helps prevent excessive solder paste, as well as saves a lot of time on reworking later…


In the picture above, we can clearly see why I had to design the PCB with such an irregular shape.

Firmware and Coding

We are still using CircuitPython for the firmware on this device. It is not perfect, but it works, well sort of anyway. What does that mean? Well… As far as the mouse functions are concerned, clicking, scrolling, moving the pointer – all of that is works perfectly, and thus allows me to use the device for basic operations every day. Drag and Drop, as well as selecting and or highlighting text DOES NOT work. This seem to be an issue with the HID code in Circuitpython, meaning it doesn’t seem to be implemented. It is also way beyond my abilities to implement it myself…

Below is the code.py file, with the boot.py below that


import time
import board
import busio
from rainbowio import colorwheel
import neopixel
import rotaryio
import microcontroller
from digitalio import Direction
from adafruit_mcp230xx.mcp23008 import MCP23008
import digitalio
i2c = busio.I2C(board.SCL, board.SDA)
mcp = MCP23008(i2c)


from analogio import AnalogIn
import usb_hid
from adafruit_hid.mouse import Mouse
joyX = board.A0
joyY = board.A1
JoyBtn = board.D2

LeftBtn = 0
CenterBtn = 1
RightBtn = 2
UpBtn = 3
DownBtn = 4
EncoderBtn = 5


mouse = Mouse(usb_hid.devices)
xAxis = AnalogIn(joyX)
yAxis = AnalogIn(joyY)

# NEOPIXEL
pixel_pin = board.NEOPIXEL
num_pixels = 1
pixels = neopixel.NeoPixel(pixel_pin, num_pixels, brightness=0.1, auto_write=False)

leftbutton = mcp.get_pin(LeftBtn)
leftbutton.direction = digitalio.Direction.INPUT
leftbutton.pull = digitalio.Pull.UP

centerbutton = mcp.get_pin(CenterBtn)
centerbutton.direction = digitalio.Direction.INPUT
centerbutton.pull = digitalio.Pull.UP

maint_btn = digitalio.DigitalInOut(JoyBtn)
maint_btn.switch_to_input(pull=digitalio.Pull.UP)

rightbutton = mcp.get_pin(RightBtn)
rightbutton.direction = digitalio.Direction.INPUT
rightbutton.pull = digitalio.Pull.UP

enc_btn = mcp.get_pin(EncoderBtn)
enc_btn.direction = digitalio.Direction.INPUT
enc_btn.pull = digitalio.Pull.UP

scroll_up = mcp.get_pin(UpBtn)
scroll_up.direction = digitalio.Direction.INPUT
scroll_up.pull = digitalio.Pull.UP

scroll_down = mcp.get_pin(DownBtn)
scroll_down.direction = digitalio.Direction.INPUT
scroll_down.pull = digitalio.Pull.UP



mousewheel = rotaryio.IncrementalEncoder(board.D6, board.D7, 4)
last_position = mousewheel.position
print(mousewheel.position)

move_speed = 3
enc_down = 0

RED = (255, 0, 0)
YELLOW = (255, 150, 0)
GREEN = (0, 255, 0)
CYAN = (0, 255, 255)
BLUE = (0, 0, 255)
PURPLE = (180, 0, 255)
BLACK = (0, 0, 0)


if move_speed == 0:
    in_min, in_max, out_min, out_max = (0, 65000, -20, 20)
    filter_joystick_deadzone = (
        lambda x: int((x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min)
        if abs(x - 32768) > 500
        else 0
    )
if move_speed == 1:
    pixels.fill(GREEN)
    pixels.show()
    in_min, in_max, out_min, out_max = (0, 65000, -15, 15)
    filter_joystick_deadzone = (
        lambda x: int((x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min)
        if abs(x - 32768) > 500
        else 0
    )
if move_speed == 2:
    pixels.fill(BLUE)
    pixels.show()
    in_min, in_max, out_min, out_max = (0, 65000, -10, 10)


filter_joystick_deadzone = (
        lambda x: int((x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min)
        if abs(x - 32768) > 500
        else 0
    )
if move_speed == 3:
    pixels.fill(PURPLE)
    pixels.show()
    in_min, in_max, out_min, out_max = (0, 65000, -8, 8)
    filter_joystick_deadzone = (
        lambda x: int((x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min)
        if abs(x - 32768) > 500
        else 0
    )
if move_speed == 4:
    pixels.fill(CYAN)
    pixels.show()
    in_min, in_max, out_min, out_max = (0, 65000, -5, 5)
    filter_joystick_deadzone = (
        lambda x: int((x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min)
        if abs(x - 32768) > 500
        else 0
    )


pixels.fill(BLACK)
pixels.show()
while True:
    # Set mouse accelleration ( speed)
    #print(mousewheel.position)
    if move_speed == 0:
        pixels.fill(BLACK)
        pixels.show()
        in_min, in_max, out_min, out_max = (0, 65000, -20, 20)
        filter_joystick_deadzone = (
            lambda x: int(
                (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min
            )
            if abs(x - 32768) > 500
            else 0
        )
    if move_speed == 1:
        pixels.fill(GREEN)
        pixels.show()
        in_min, in_max, out_min, out_max = (0, 65000, -15, 15)
        filter_joystick_deadzone = (
            lambda x: int(
                (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min
            )
            if abs(x - 32768) > 500
            else 0
        )
    if move_speed == 2:
        pixels.fill(BLUE)
        pixels.show()
        in_min, in_max, out_min, out_max = (0, 65000, -10, 10)
        filter_joystick_deadzone = (
            lambda x: int(
                (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min
            )
            if abs(x - 32768) > 500
            else 0
        )
    if move_speed == 3:
        pixels.fill(PURPLE)
        pixels.show()
        in_min, in_max, out_min, out_max = (0, 65000, -8, 8)
        filter_joystick_deadzone = (
            lambda x: int(
                (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min
            )
            if abs(x - 32768) > 500
            else 0
        )
    if move_speed == 4:
        pixels.fill(CYAN)
        pixels.show()
        in_min, in_max, out_min, out_max = (0, 65000, -5, 5)
        filter_joystick_deadzone = (
            lambda x: int(
                (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min
            )
            if abs(x - 32768) > 500
            else 0
        )

    current_position = mousewheel.position
    position_change = current_position - last_position

    x_offset = filter_joystick_deadzone(xAxis.value) * -1  # Invert axis
    y_offset = filter_joystick_deadzone(yAxis.value)
    mouse.move(x_offset, y_offset, 0)

    if enc_btn.value and enc_down == 1:
        move_speed = move_speed + 1
        if move_speed > 4:
            move_speed = 0

        # print (move_speed)
        enc_down = 0

    if not enc_btn.value:
        enc_down = 1

    if leftbutton.value:
        mouse.release(Mouse.LEFT_BUTTON)
        # pixels.fill(BLACK)
        # pixels.show()
    else:
        mouse.press(Mouse.LEFT_BUTTON)
        pixels.fill(GREEN)
        pixels.show()

    if centerbutton.value:
        mouse.release(Mouse.MIDDLE_BUTTON)
    else:
        mouse.press(Mouse.MIDDLE_BUTTON)
        pixels.fill(YELLOW)
        pixels.show()

    # Center button on joystick
    if maint_btn.value:
        mouse.release(Mouse.LEFT_BUTTON)
    else:
        mouse.press(Mouse.LEFT_BUTTON)
        pixels.fill(GREEN)
        pixels.show()

    if rightbutton.value:
        mouse.release(Mouse.RIGHT_BUTTON)
        # pixels.fill(BLACK)
        # pixels.show()
    else:
        mouse.press(Mouse.RIGHT_BUTTON)
        pixels.fill(PURPLE)
        pixels.show()

    if not scroll_up.value:
        mouse.move(wheel=1)
        time.sleep(0.25)
        pixels.fill(BLUE)
        pixels.show()

    if not scroll_down.value:
        mouse.move(wheel=-1)
        time.sleep(0.25)
        pixels.fill(CYAN)
        pixels.show()

    if not scroll_up.value and not scroll_down.value:
        for x in range(4):
            pixels.fill(RED)
            pixels.show()
            time.sleep(0.5)
            pixels.fill(BLACK)
            pixels.show()
            time.sleep(0.5)
        microcontroller.reset()



    if position_change > 0:
        mouse.move(wheel=position_change)
        #print(current_position)
        #pixels.fill(BLUE)
        #pixels.show()
    elif position_change < 0:
        mouse.move(wheel=position_change)
        #print(current_position)
        #pixels.fill(CYAN)
        #pixels.show()
    last_position = current_position
    pixels.fill(BLACK)
    pixels.show()

boot.py

import storage
import board, digitalio
import time
from rainbowio import colorwheel
import neopixel
import busio
from digitalio import Direction
from adafruit_mcp230xx.mcp23008 import MCP23008
import digitalio
i2c = busio.I2C(board.SCL, board.SDA)
mcp = MCP23008(i2c)



#button = digitalio.DigitalInOut(board.D8)
#button.pull = digitalio.Pull.UP

button = mcp.get_pin(6)
button.direction = digitalio.Direction.INPUT
button.pull = digitalio.Pull.UP

Rstbutton = mcp.get_pin(7)
Rstbutton.direction = digitalio.Direction.INPUT
Rstbutton.pull = digitalio.Pull.UP

# NEOPIXEL
pixel_pin = board.NEOPIXEL
num_pixels = 1
pixels = neopixel.NeoPixel(pixel_pin,num_pixels,brightness=0.2,auto_write=False)

RED = (255, 0, 0)
YELLOW = (255,150, 0)
GREEN = (0, 255, 0)
CYAN = (0, 255, 255)
BLUE = (0, 0, 255)
PURPLE = (180, 0, 255)
BLACK = (0, 0, 0)

# Disable devices only if button is not pressed.
#usb_hid.enable((), boot_device=2)
if button.value:
   pixels.fill(GREEN)
   pixels.show()
   storage.disable_usb_drive()
   usb_cdc.disable()
else:
    pixels.fill(RED)
    pixels.show()
    usb_cdc.enable(console=True, data=False)
    storage.enable_usb_drive()


time.sleep(5)
# Write your code here :-)

Xiao RP2040 Joystick Mouse – revision 2.00

Revision 1.0 of the Project


Over the last few months, I have been using the initial revision of this project on almost a daily basis. It has come a long way since the initial concept was implemented on the breadboard.

Initial Concept on a Breadboard

While completely functional, and relatively easy to use, quite a few things started adding up – making me believe that it could be better…

That prompted me to start thinking about a hardware revision, adding some missing features, like a middle button, and “maybe” a display to the device, making it easier to visualise settings, etc…

Current Revision 2.0 ” Proof of concept ” prototype

My main limitations came from the Seeed Studio Xiao RP2040 Module. While super tiny and compact, the module only has access to 11 GPIO pins on the RP2040 chip. Most of these were already in use, connected to buttons etc.

I would thus have to find an I2C IO expander that will be supported by CircuitPython and have a suitably small footprint. That way, I could free up many of the valuable GPIO pins on the Xiao RP2040 for other purposes.

What did I use?

My initial goto chip was the MCP23017, with 16 GPIO pins. But after some more thinking, I settled on the MCP23008, which has only 8 GPIO lines. I2C bus breakout headers to allow for expansion, as well as access to all the unused GPIO pins on the XIAO RP2040, were also added.

The Rotary encoder was once again included, as it could later be used for selecting Menu options etc.

What is the current status of the project?

The revision 2.00 hardware works as expected, with a few issues.
CircuitPython has an issue with rotary encoders connected to IO expanders. I don’t understand why that would be the case, but wrote my basic routine to handle the encoder, which at this time, is only used for scrolling. ( I have still got to decide if a display would be needed)

As far as settings are concerned, I have only implemented a sort of “mouse speed” feature that determines how fast or slow ( for better accuracy ) the pointer moves. This is currently controlled by the encoder button, on a cycling loop, with different colours on the NeoPixel as visual feedback on the current speed selected.

USB connectivity at computer startup and/or resuming from a suspend operation is still a major problem. This means that you have to physically reset the device after every resume from suspend, or after starting your computer.
From what I can see in the CircuitPython documentation, it is possible to detect USB connectivity. That part works. From there, It seems that once USB connectivity is lost, CircuitPython goes into some sort of unknown state, and no further code is executed, thus making a software reset not executing…

I have an idea that it has got something to do with the HID Mouse mode or something ???? For now, I am happy to just hit a reset button to continue…

Another big issue is a suitable enclosure. Revision 2.00 PCB was not designed to be placed into an enclosure, mainly because I have so far been quite unsuccessful in finding a suitable one. My 3D design skills are also quite lacking, so designing something from scratch won’t do either. I have decided to sort out all the hardware and firmware issues first, find an enclosure and then modify the PCB layout to fit that.

Manufacturing the PCB

I choose PCBWay for my PCB manufacturing. Why? What makes them different from the rest?

PCBWay‘s business goal is to be the most professional PCB manufacturer for prototyping and low-volume production work in the world. With more than a decade in the business, they are committed to meeting the needs of their customers from different industries in terms of quality, delivery, cost-effectiveness and any other demanding requests. As one of the most experienced PCB manufacturers and SMT Assemblers in China, they pride themselves to be our (the Makers) best business partners, as well as good friends in every aspect of our PCB manufacturing needs. They strive to make our R&D work easy and hassle-free.

How do they do that?

PCBWay is NOT a broker. That means that they do all manufacturing and assembly themselves, cutting out all the middlemen, and saving us money.

PCBWay’s online quoting system gives a very detailed and accurate picture of all costs upfront, including components and assembly costs. This saves a lot of time and hassle.

PCBWay gives you one-on-one customer support, that answers you in 5 minutes ( from the Website chat ), or by email within a few hours ( from your personal account manager). Issues are really resolved very quickly, not that there are many anyway, but, as we are all human, it is nice to know that when a gremlin rears its head, you have someone to talk to who will do his/her best to resolve your issue as soon as possible.

Find out more here

Assembly and Testing

Assembly is easy but does require a stencil due to the small size of some of the SMD components.

CircuitPython Coding – A work in progress

This is the current code, and it is a work in progress. It works, and could definitely be optimised quite a lot. I am not very familiar with Python but I believe I can help myself around it.

import time
import board
import busio
from rainbowio import colorwheel
import neopixel
import digitalio
import rotaryio
import microcontroller
from digitalio import Direction
from adafruit_mcp230xx.mcp23008 import MCP23008
import digitalio
i2c = busio.I2C(board.SCL, board.SDA)
mcp = MCP23008(i2c)

from analogio import AnalogIn
import usb_hid
from adafruit_hid.mouse import Mouse

mouse = Mouse(usb_hid.devices)
xAxis = AnalogIn(board.A2)
yAxis = AnalogIn(board.A1)

# NEOPIXEL
pixel_pin = board.NEOPIXEL
num_pixels = 1
pixels = neopixel.NeoPixel(pixel_pin, num_pixels, brightness=0.1, auto_write=False)

leftbutton = mcp.get_pin(3)
leftbutton.direction = digitalio.Direction.INPUT
leftbutton.pull = digitalio.Pull.UP

centerbutton = mcp.get_pin(4)
centerbutton.direction = digitalio.Direction.INPUT
centerbutton.pull = digitalio.Pull.UP

maint_btn = digitalio.DigitalInOut(board.D0)
maint_btn.switch_to_input(pull=digitalio.Pull.UP)

rightbutton = mcp.get_pin(5)
rightbutton.direction = digitalio.Direction.INPUT
rightbutton.pull = digitalio.Pull.UP

enc_btn = mcp.get_pin(2)
enc_btn.direction = digitalio.Direction.INPUT
enc_btn.pull = digitalio.Pull.UP

scroll_up = mcp.get_pin(6)
scroll_up.direction = digitalio.Direction.INPUT
scroll_up.pull = digitalio.Pull.UP

scroll_down = mcp.get_pin(7)
scroll_down.direction = digitalio.Direction.INPUT
scroll_down.pull = digitalio.Pull.UP

enc_a = mcp.get_pin(0)
enc_a.direction = digitalio.Direction.INPUT
enc_a.pull = digitalio.Pull.UP

enc_b = mcp.get_pin(1)
enc_b.direction = digitalio.Direction.INPUT
enc_b.pull = digitalio.Pull.UP

enc_a_pressed = False
enc_b_pressed = False

#mousewheel = rotaryio.IncrementalEncoder(enc_a, mcp.get_pin(1))
#last_position = mousewheel.position

move_speed = 3
enc_down = 0

RED = (255, 0, 0)
YELLOW = (255, 150, 0)
GREEN = (0, 255, 0)
CYAN = (0, 255, 255)
BLUE = (0, 0, 255)
PURPLE = (180, 0, 255)
BLACK = (0, 0, 0)


if move_speed == 0:
    in_min, in_max, out_min, out_max = (0, 65000, -20, 20)
    filter_joystick_deadzone = (
        lambda x: int((x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min)
        if abs(x - 32768) > 500
        else 0
    )
if move_speed == 1:
    pixels.fill(GREEN)
    pixels.show()
    in_min, in_max, out_min, out_max = (0, 65000, -15, 15)
    filter_joystick_deadzone = (
        lambda x: int((x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min)
        if abs(x - 32768) > 500
        else 0
    )
if move_speed == 2:
    pixels.fill(BLUE)
    pixels.show()
    in_min, in_max, out_min, out_max = (0, 65000, -10, 10)


filter_joystick_deadzone = (
        lambda x: int((x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min)
        if abs(x - 32768) > 500
        else 0
    )
if move_speed == 3:
    pixels.fill(PURPLE)
    pixels.show()
    in_min, in_max, out_min, out_max = (0, 65000, -8, 8)
    filter_joystick_deadzone = (
        lambda x: int((x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min)
        if abs(x - 32768) > 500
        else 0
    )
if move_speed == 4:
    pixels.fill(CYAN)
    pixels.show()
    in_min, in_max, out_min, out_max = (0, 65000, -5, 5)
    filter_joystick_deadzone = (
        lambda x: int((x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min)
        if abs(x - 32768) > 500
        else 0
    )


pixels.fill(BLACK)
pixels.show()
while True:
    # Set mouse accelleration ( speed)
    if move_speed == 0:
        pixels.fill(BLACK)
        pixels.show()
        in_min, in_max, out_min, out_max = (0, 65000, -20, 20)
        filter_joystick_deadzone = (
            lambda x: int(
                (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min
            )
            if abs(x - 32768) > 500
            else 0
        )
    if move_speed == 1:
        pixels.fill(GREEN)
        pixels.show()
        in_min, in_max, out_min, out_max = (0, 65000, -15, 15)
        filter_joystick_deadzone = (
            lambda x: int(
                (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min
            )
            if abs(x - 32768) > 500
            else 0
        )
    if move_speed == 2:
        pixels.fill(BLUE)
        pixels.show()
        in_min, in_max, out_min, out_max = (0, 65000, -10, 10)
        filter_joystick_deadzone = (
            lambda x: int(
                (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min
            )
            if abs(x - 32768) > 500
            else 0
        )
    if move_speed == 3:
        pixels.fill(PURPLE)
        pixels.show()
        in_min, in_max, out_min, out_max = (0, 65000, -8, 8)
        filter_joystick_deadzone = (
            lambda x: int(
                (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min
            )
            if abs(x - 32768) > 500
            else 0
        )
    if move_speed == 4:
        pixels.fill(CYAN)
        pixels.show()
        in_min, in_max, out_min, out_max = (0, 65000, -5, 5)
        filter_joystick_deadzone = (
            lambda x: int(
                (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min
            )
            if abs(x - 32768) > 500
            else 0
        )

    #current_position = mousewheel.position
    #position_change = current_position - last_position

    x_offset = filter_joystick_deadzone(xAxis.value) * -1  # Invert axis
    y_offset = filter_joystick_deadzone(yAxis.value) * -1
    mouse.move(x_offset, y_offset, 0)

    if enc_btn.value and enc_down == 1:
        move_speed = move_speed + 1
        if move_speed > 4:
            move_speed = 0

        # print (move_speed)
        enc_down = 0

    if not enc_btn.value:
        enc_down = 1

    if leftbutton.value:
        mouse.release(Mouse.LEFT_BUTTON)
        # pixels.fill(BLACK)
        # pixels.show()
    else:
        mouse.press(Mouse.LEFT_BUTTON)
        pixels.fill(GREEN)
        pixels.show()

    if centerbutton.value:
        mouse.release(Mouse.MIDDLE_BUTTON)
    else:
        mouse.press(Mouse.MIDDLE_BUTTON)
        pixels.fill(YELLOW)
        pixels.show()

    # Center button on joystick
    if maint_btn.value:
        mouse.release(Mouse.LEFT_BUTTON)
    else:
        mouse.press(Mouse.LEFT_BUTTON)
        pixels.fill(GREEN)
        pixels.show()

    if rightbutton.value:
        mouse.release(Mouse.RIGHT_BUTTON)
        # pixels.fill(BLACK)
        # pixels.show()
    else:
        mouse.press(Mouse.RIGHT_BUTTON)
        pixels.fill(PURPLE)
        pixels.show()

    if not scroll_up.value:
        mouse.move(wheel=1)
        time.sleep(0.25)
        pixels.fill(BLUE)
        pixels.show()

    if not scroll_down.value:
        mouse.move(wheel=-1)
        time.sleep(0.25)
        pixels.fill(CYAN)
        pixels.show()

    if not scroll_up.value and not scroll_down.value:
        for x in range(4):
            pixels.fill(RED)
            pixels.show()
            time.sleep(0.5)
            pixels.fill(BLACK)
            pixels.show()
            time.sleep(0.5)
        microcontroller.reset()

    if enc_a.value:
        enc_a_pressed = False
    else:
        if enc_b_pressed:
            enc_a_pressed = False
        else:
            enc_a_pressed = True

    if enc_b.value:
        enc_b_pressed = False
    else:
        if enc_a_pressed:
            enc_b_pressed = False
        else:
            enc_b_pressed = True

    if enc_a_pressed:
        mouse.move(wheel=1)
        time.sleep(0.25)
        enc_a_pressed = False
    if enc_b_pressed:
        mouse.move(wheel=-1)
        time.sleep(0.25)
        enc_b_pressed = False

    #if position_change > 0:
    #    mouse.move(wheel=position_change)
    #    # print(current_position)
    #    pixels.fill(BLUE)
    #    pixels.show()
    #elif position_change < 0:
    #    mouse.move(wheel=position_change)
    #    # print(current_position)
    #    pixels.fill(CYAN)
    #    pixels.show()
    #last_position = current_position
    pixels.fill(BLACK)
    pixels.show()

Conclusion

Okay, so this is where it is at at the moment. The code is not perfect, and the hardware is not perfect, but it works. I am using this device every day, and also making changes as needed. At the moment, there are some issues, but they do not prevent the actual use of the device.

If you are interested or would like to make modifications, feel free to do so.

“The Emergency Mouse” – A project born out of necessity

Imagine You are working on a project late on a Friday evening and suddenly your mouse stops working… You can not scroll, and the right-side button won’t respond to your clicks… At the same time, you have a project design that has got to get finished… and the shops are all closed already…

These were the circumstances that led to the birth of “The Emergency Mouse” – A project born out of necessity. How did I solve my problem?

Having access to a lot of electronic modules saved the day. As a maker, I always have various modules and gadgets lying around, and on this unfortunate evening, I remember that the RP2040 has USB HID support. Combine that with a simple Analog Joystick module, a rotary encoder and some push buttons, add about 30 minutes worth of browsing the internet, struggling along with a broken mouse – we have to give the old one credit, it had a very long and hard life, and I finally found some example code that did not just jiggle the mouse pointer or do something equally silly…

The only problem with all of that was that the code was for CircuitPython… I generally dislike using Python on a Microcontroller, as I believe it is better suited for the computer, but, I am warming up to the idea… slowly…

The initial fix – a mess of wires on a breadboard

I quickly grabbed a RaspBerry Pi Pico out of a box, plugged it into a breadboard, loaded Circuitpyth and fired up the example code I got on the internet… While promising, It did not exactly do what I wanted… so a few minutes later, after some coding, I had a moving pointer, controlled by the small thumb joystick module, and with the center button as a “right button”…

So far so good… I can work more easily, but still did not have scrolling… so lets hit the datasheets and documentation on the Adafruit Website (not sponsored) and add a rotary encoder… works well, add more buttons, etc etc…

Eventually it was all done, and about 1 hour has passed, but we were left with a huge ugly mess on a breadboard, and a lot of unused GPIO pins.. So this Pico must go… it can be used for something more useful later…

Then my eye fell on a SEEED Studio XIAO RP2040 module, almost begging to be used… This is smaller, more compact… lets try that …

Initial breadboard version, here shown with the SEEED Studio XIAO RP2040

What functions did this “mouse” have

After changing to the XIAO RP2040, things went very quick…

I added two buttons for scrolling up and down, simulating a mouse wheel,
but kept the encoder… which, while VERY awkward to use at this stage, definitely had potential in the long run…

I also added another button to take over the function of a right button, while the center button on the joystick became left…

Disaster averted, with only about 2 hours wasted, I returned to my project and managed to get it finished using the “improvised-mouse-on-the-breadboard” contraption…

That night, while lying in bed, trying to get to fall asleep, the possibilities of this “contraption-on-the-breadboard” would not let me go… I am fairly old-school, and during the late 80’s and early 90’s owned quite a few “roller-ball” mouse devices… these later became trackballs, and being excessively overpriced, was promptly removed from my environment – the old ones did not last very long, and the new ones were, as I said, overly expensive…

I did however never forget the ease of use that first “rollerball mouse” gave me all that years ago, using only my thumb to move it around etc etc…

This idea would have to be investigated, and turned into a PCB… with that, I finally drifted off to sleep…

The PCB design

The next morning came, and due to reasons unknown, as well as being lazy, I decided not to leave the house, and go buy a new mouse. lets try online… No, they are crazy – I am not paying that for a mouse!

All the time using the “contraption-on-the-breadboard”. So this thing started growing on me… lets design a PCB

The Initial PCB design

After a few hours spent on deciding on optimal layout, I came up with this…
It was still a bit unrefined, but definitely had potential… It lacked a dedicated center button, and those momentary push-buttons requires a lot of force to use… but as a prototype, why not…

Let’s get this manufactured.

For this build, since I used a SEEED Studio module, I decided to send it to SEEED for manufacturing… no need to get components from various places, as they should have all in stock…

Seeed Studio’s Fusion service seamlessly marries convenience with full-feature capabilities in one simple platform. Whether you are prototyping or looking for a mass production partner or based on open source product customization requirements and other design manufacturing services, Seeed Studio Fusion service is catered to your needs starting with a simple online platform. https://www.seeedstudio.com/fusion.html

The PCB arrives from the factory

During the entire time that it took for the PCB to be manufactured and assembled, I was still using this “homemade mouse” – I started calling it a mouse now… and it was still on the breadboard… I never did bother to buy a new mouse, yet..


The PCB Arrived today, and apart from a few small soldering issues, looked great… I still had to do a bit of assembly on my own, as there was an issue with the components I wanted being out of stock.. I have plenty in stock of my own, so opted to do manual assembly…


The completed PCB now only needed a joystick, and some firmware…


After adding a few button caps, and mounting everything to a piece of acrylic plate, I had a working prototype…

The Firmware

As mentioned above, the device runs on CircuitPyton. As Such, there are quite a lot of “examples” on the internet, showing you how to do many USB HID “mouse” like things, but generally being completely useless…

I have thus spent quite a lot of time up to now, writing and refining my own version of the firmware, that is actually useful and does actually work.

It has the following features:
X-Y axis control of the mouse pointer via a thumb joystick, with a left click function on the center joystick button, as well as a dedicated “left” button.

A dedicated “right” button
A “virtual center” button made up of simultaneously pressing left and right

Up and down scrolling either using the rotary encoder as a “mouse wheel” or via dedicated up and down pushbuttons.

A dedicated Reset button – this is necessary, as I can not seem to get the device to initialise correctly at computer bootup.

Various software functions, like changing the pointer acceleration by pressing the center button on the rotary encoder

and most importantly, hiding the Circuitpyton drive, only showing it when I actually need access to the code in this device…

Various statuses are indicated using the NeoPixel on the XIAO, making it easy to see in what state the device is operating.

As such, I shall NOT be releasing the firmware at this moment, as it is still far from being perfect. It works, but it can be way better…

Summary and next steps

Since its “birth” late on a Friday night, about 3 weeks ago, I have been using this device, in its various forms as my primary pointer device. It is growing on me more every day, and it is quite comfortable to use – If we ignore the fact that it is not in a suitable enclosure and that I am still making small changes to the firmware from time to time.

I am already planning the next revision, in which I shall replace the momentary push-buttons with proper microswitches, as well as try my hand at designing a proper enclosure.

If you are a 3D printing expert and want to collaborate with me on this, let’s talk…

An I2C Matrix Keypad

The completed I2C Matrix Keypad

In a previous post this month I introduced my 4×4 matrix keypad. That keypad was designed to be directly interfaced to a microcontroller’s GPIO pins or alternatively to an IO expander chip like the PCF8574. That design, while working very well had the problem of requiring 8 GPIO pins to function correctly.

GPIO pins on a microcontroller can be considered very precious resources, and it should then be logical to assume that we should find a way to use these GPIO pins in a more conservative way, to allow us to interface more peripherals.

I solved this problem by integrating the keypad with an IO Expander on the same PCB. That will allow us to get away with using only 2 GPIO pins, and also open up the option of adding more keypads to the I2C bus, in the event that we need that many keys for a particular project.

The Schematic

I2C 4×4 Matrix Keypad Schematic

Looking closely at the schematic, we can see that it is exactly the same basic keypad circuit that I used in the initial design. The only difference is that in this design, I have integrated a PCF8574 directly onto the PCB.

Some additional features include selectable I2C Pullup resistors ( usually my microcontroller development boards already include those) that can be activated with a jumper when needed. There are also a set of address selection jumpers, making it possible to stack keypads together into a bigger keyboard if you require something like that. Note that, in this version of the hardware, I did not include headers for stacking.

The keypad can be powered by a DC power source of 3.3v to 5v.

The PCB

I2C Keypad PCB
3D Render of the I2C Keypad

The PCB is a double-layer board of 68.8mm x 50.8mm. Male header pins provide access to the connections as well as address and pullup resistor jumpers. In my build, I have mounted these male headers on the back of the PCB. That makes it possible to mount the Keypad in an enclosure without having the jumpers “stick out” and get in the way.

The top layer of the I2C Keypad PCB
Bottom Layer

Manufacturing

I choose PCBWay for my PCB manufacturing.
This month, PCBWay is also celebrating its 9th anniversary, and that means that there are quite a lot of very special offers available.

Why?
What makes them different from the rest?

PCBWay‘s business goal is to be the most professional PCB manufacturer for prototyping and low-volume production work in the world. With more than a decade in the business, they are committed to meeting the needs of their customers from different industries in terms of quality, delivery, cost-effectiveness and any other demanding requests. As one of the most experienced PCB manufacturers and SMT Assemblers in China, they pride themselves to be our (the Makers) best business partners, as well as good friends in every aspect of our PCB manufacturing needs. They strive to make our R&D work easy and hassle-free.

How do they do that?

PCBWay is NOT a broker. That means that they do all manufacturing and assembly themselves, cutting out all the middlemen, and saving us money.

PCBWay’s online quoting system gives a very detailed and accurate picture of all costs upfront, including components and assembly costs. This saves a lot of time and hassle.

PCBWay gives you one-on-one customer support, that answers you in 5 minutes ( from the Website chat ), or by email within a few hours ( from your personal account manager). Issues are really resolved very quickly, not that there are many anyway, but, as we are all human, it is nice to know that when a gremlin rears its head, you have someone to talk to that will do his/her best to resolve your issue as soon as possible.

Find out more here

Assembly

The assembly of this PCB was quite easy and quick. A stencil is not required. All SMD components are 0805 or bigger. It would thus be quite easy to solder them all by hand with a fine-tipped soldering iron.

I have however used soldering paste and hot air to reflow the components, as it is the fastest, in my opinion, and definitely looks neater than hand soldering.

After placing SMD components onto solder paste – ready for reflow soldering
After Reflow soldering with Hot Air

The board is now ready to solder the switches and header pins in place. As already mentioned above, I chose to assemble the headers on the back of the PCB to prevent them from interfering with any enclosure that I may later use with the keypad.

Final Assembly
Note that I assembled the headers onto the back of the PCB.

Testing and Coding

Testing the keypad consisted of a few steps, the first of which was ensuring that there were no short circuits, as well as that all the momentary switches worked.
This was done with a multimeter in continuity as well as diode mode, with probes alternatively on each column and row in turn, while pressing the buttons.

The next stage was testing the I2C IO Expander. This was done with a simple I2C Scanning sketch on an Arduino Uno. It did not do a lot, but, I could see that the PCF8574 is responding to its address and that the pullup resistors work when enabled. This test was repeated with my own ESP8266 and ESP32 boards, this time with pullup resistors disabled, as these boards already have them onboard.

Coding came next, and it was another case of perspectives. It seems like all commercial keypads do not have diodes. This affects the way that they work with a given library. It seems that software developers and hardware developers have different understandings of what a row and a column is.

This meant that, due to the fact that I have diodes on each switch, and the way that the library work – which pins are pulled high and which are set as inputs -, I had to swap around my rows and columns in the software to get everything to work. On a keypad with the diodes replaced with 0-ohm links, that was not needed.

A short test sketch follows below:

Note that with was run on an ESP8266-12E, therefore the Wire.begin() function was changed to Wire.begin(4,5); in order to use GPIO 4 and GPIO 5 for I2C

Another point to note is that the keypad Layout will seem strange. Remember that this is due to the diodes in series on each switch. That forces us to swap around the Rows and the Columns in the software, resulting in a mirrored and rotated left representation of the keypad. It looks funny, but believe me, it actually still works perfectly.

#include <Wire.h>
#include "Keypad.h"
#include <Keypad_I2C.h>

const byte n_rows = 4;
const byte n_cols = 4;

char keys[n_rows][n_cols] = {
    {'1', '4', '7', '*'},
    {'2', '5', '8', '0'},
    {'3', '6', '9', '#'},
    {'A', 'B', 'C', 'D'}};

byte rowPins[n_rows] = {4, 5, 6, 7};
byte colPins[n_cols] = {0, 1, 2, 3};

Keypad_I2C myKeypad = Keypad_I2C(makeKeymap(keys), rowPins, colPins, n_rows, n_cols, 0x20);

String swOnState(KeyState kpadState)
{
    switch (kpadState)
    {
    case IDLE:
        return "IDLE";
        break;
    case PRESSED:
        return "PRESSED";
        break;
    case HOLD:
        return "HOLD";
        break;
    case RELEASED:
        return "RELEASED";
        break;
    } // end switch-case
    return "";
} // end switch on state function

void setup()
{
    // This will be called by App.setup()
    Serial.begin(115200);
    while (!Serial)
    { /*wait*/
    }
    Serial.println("Press any key...");
    Wire.begin(4,5);
    myKeypad.begin(makeKeymap(keys));
}

char myKeyp = NO_KEY;
KeyState myKSp = IDLE;
auto myHold = false;

void loop()
{

    char myKey = myKeypad.getKey();
    KeyState myKS = myKeypad.getState();

    if (myKSp != myKS && myKS != IDLE)
    {
        Serial.print("myKS: ");
        Serial.println(swOnState(myKS));
        myKSp = myKS;
        if (myKey != NULL)
            myKeyp = myKey;
        String r;
        r = myKeyp;
        Serial.println("myKey: " + String(r));
        if (myKS == HOLD)
            myHold = true;
        if (myKS == RELEASED)
        {
            if (myHold)
                r = r + "+";
            Serial.println(r.c_str());
            myHold = false;
        }
        Serial.println(swOnState(myKS));
        myKey == NULL;
        myKS = IDLE;
    }
}

Conclusion

This project once again delivered what I set out to achieve. It has some quirks, but nothing serious. Everything works as expected, both in the Arduino IDE/platform IO realm, as well as in ESPHome. It is worth noting that in ESPHome, we do not need to swap the rows and columns to use the Keypad component. Do remember to leave the has_diodes flag to false though…

AI-WB2 and XIAO RP2040 Combo

`Ai-Thinker (#notsponsored) should be quite well known to many makers as a company that manufactured and designs many of the modules that we use in our projects. We, MakerIoT2020, definitely make use of quite a few of their products, like the RA-02, as well as their ESP32-S module.



A few months ago, I got the opportunity to play with one of their newest projects, the AI-WB2, which is based on the BL602 Risc-V Chip. After a very very bumpy ride, mainly due to the chip being quite new, and documentation being virtually nonexistent in the English language, I decided to take a step back, and stop trying to reinvent the wheel 🙂 Afterall, I don’t want to use Apache NuttX or a similar RTOS for every project, as the thought of having to write almost all of the different required components from scratch, does not really appeal to me. especially as the SDK is in Chinese, and the English version of it is a bit patchy, to say the least…

This made me quite a bit frustrated, at least until I decided to change my thinking, and take a look at the stock AT command set that comes shipped on the modules from the factory… While excellent for use as a WiFi modem, it did not seem to allow any access to any of the GPIO on the WB-AI2 module… But wait… is that really a problem? No… Let me tell you why…

I also have a few XIAO Modules ( the RP2040 and SAMD21 ) lying around, and those do not have any connectivity options onboard…

A few very quick tests later, It was clear that the AI-WB2 will be a very compact
WiFi as well as BTLE connectivity solution for these XIAO modules, and, If I design with the future in mind, the GPIO pins of the AI-WB2 module can also become useable to me as well… once the firmware and SDK gets more accessible..

What followed from this is a very basic prototype PCB, with the XIAO RP2040 as the main processor, and the AI-WB2-12F as a “connectivity co-processor”, meaning that all communications functions will be offloaded to the AI-WB2 and the results of those, sent back to the XIAO for processing…

This in itself presents quite a few challenges, especially on the communications handling, and using the second UART port, which is currently not possible with the official Arduino Core for the RP2040… Luckily, the XIAO RP2040 uses an alternative core, that supports the second UART port quite well …

What is on the PCB?

AI-WB2-12F XIAO Combo

The Top Section of the PCB is dedicated to the AI-WB2-12F and its supporting components, including a flash and reset button. The GPIO for the WB2-12F is broken out onto H1.

At the right, below H1, is a series of jumpers, connecting the Xiao RP2040 and WB2-12-F Uart ports, or, alternatively, connecting the XIAO Rp2040 to the pin headers at the side of the PCB.

The rest of the PCB is dedicated to the Xiao RP2040 or Xiao SAMD21 module, with its supporting circuitry, and a dedicated Reset button for the SAMD21 module ( also works for the RP2040)

The board is powered with 5v DC through a dedicated header at the left bottom. This directly powers the Xiao and indirectly powers the WB2-12-F through a 3.3v LDO Regulator. Please note that although the Xiao is powered via 5v, the GPIO pins are all 3.3v logic!

The Schematic and PCB

Schematic

PCB Layout

Software

MQTT Connection on the AI-WB2-12F

AI-Thinker Example

The full AT command set example is available here

For the Xiao RP2040, like I used, it is possible to use the second UART to connect to the AI-WB2 chip.

As I am still not completely done with my development, I will not release the full code at this moment.

I have also been informed by AI-Thinker that a new version of the AT-command firmware is available that will allow using the GPIO on the AI-WB2 via AT Commands. I am currently investigating that new version, and that is also a big reason for not releasing any code at this stage.

Manufacturing

The PCB for this project has been manufactured at PCBWay.
Please consider supporting them if you would like your own copy of this PCB, or if you have any PCB of your own that you need to have manufactured.

PCBWay

More Pictures

RP2040 Scoppy Oscilloscope Analog Front End Shield

This post will look at my prototype Analog front-end for the Scoppy RP2040 Oscilloscope. It is important to state right from the beginning that this circuit is one of the 5 recommended designs from the Scoppy Website. I have only moved it from the breadboard design as published, onto a PCB.

The entire circuit, with all of the original designer’s writeups, is available here

So, why use someone else’s circuit? Well, the reason for this is two-fold.
1) The circuit designer also designed the firmware, so it stands to reason that his circuit will be optimised for use with the firmware.
2) Using his circuit provides a solid reference, making it possible to test the firmware for correct operation, and later on, providing a base for my own design – if and when I do decide it is worthwhile to actually design my own.

As I already have a proper oscilloscope as well as a logic analyser, this entire exercise is purely academic, I find the Scoppy project interesting, and as such, I would like to see how it compares with my commercial products ( while also knowing that it won’t be a very fair comparison ).

With all the limitations, I am however still quite impressed at the level of use that you can get out of this very simple device. It is definitely quite useful for a beginner.

What is on the PCB, and what did I change?

The PCB is a dual-layer shield that is designed to be used with the MakerIOT2020 Raspberry Pi Pico Carrier board. The shield is directly powered by the carrier board.

The original Analog Front-End #3 circuit featured a single channel input, capable of accepting a -18.0v to 18.0v signal input.

My changes were limited to doubling up on that circuit, to provide two channels.

The Schematic


I have redrawn the original schematic, partly to make it easier to understand for myself, as well as to help me with the design of the PCB.

Lets take a look at the schematic ( by using text from the original designer)

The author makes no warranty, representation or guarantees regarding the suitability of this design for any particular purpose. Nor does the author assume any liability arising out its use and specifically disclaims any and all liability, including without limitation special, consequential or incidental damages.


All text below is quoted from here

This design builds on Design 2 and adds over and under voltage protection to the analog front end. After all, we won’t have a cheap oscilloscope if we keep frying our components!

I’m assuming here that the minimum and maximum voltages that will be applied to the input of the scope will be -18V and +18V respectively. It has been tested from -18.5V to 18.5V (two of my 9V batteries in series) but of course If you decide to use this design you are doing so at your own risk. I personally wouldn’t use Scoppy with an expensive phone/tablet just in case something unexpected goes wrong (better to use an old, obsolete phone that is no longer used for anything else) – especially when dealing with higher voltages – but of course you can do what you like.

Protecting the Op-Amp input(s)

First of all we need to protect the op-amp. In this design we’ll be using an LM324 op-amp, which is very similar to the LM358 but contains four individual op-amps rather than two. We’ll be using three of these op-amps. The reason for this will be explained later.

According to the datasheet for the LM324 the allowed input voltage range goes from -0.3V to 32V. Of course 32V is above the maximum expected voltage (18V) and so we don’t need to worry about over-voltage protection. However we do need to ensure that the voltage at the input pins don’t go below -0.3V. A schottky diode can be used to clamp the voltage to something above -0.3V (D1 in the schematic).

One thing that needs to be considered when selecting the diode is its reverse current. The 1N5817 has a very low forward voltage but high reverse current and this results in a voltage drop at the input of the op-amp (in the order of 100mV). Presumably this is because it draws current through the high value input resistor (Rg1). The 1N5711 has a much lower reverse current specification and I couldn’t discern any voltage drop when this was inserted into the circuit. However, its forward voltage (at the current expected in this part of the circuit) is very close to the minimum allowed voltage of -0.3V. To be safer I prefer to use something like a BAT46. It does result in a voltage drop of a few millivolts but the clamped voltage is more like -0.23V.

Protecting the Pico/RP2040

The Pico datasheet states that:

the ADC capable GPIO26-29 have an internal reverse diode to the VDDIO (3V3) rail and so the input voltage must not exceed VDDIO plus about 300mV

The obvious way to protect the ADC inputs (GPIO26-29) then is to simply insert a schottky diode between the ADC input and VDDIO. However, the RP2040 datasheet says that:

the voltage on the ADC analogue inputs must not exceed IOVDD ...<snip>... Voltages greater than IOVDD will result in leakage currents through the ESD protection diodes

That suggests to me that we shouldn’t be allowing current to pass (leak) through our clamping diode and into IOVDD. I could be completely wrong here – if you think so then please share your thoughts in the forum (Discussions).

Anyway, to be safe we’re going to avoid that situation by sending the current to the output of one of our op-amps (LM324-sink on the schematic). The LM324 is able to sink up to ~10mA so this should work fine if we limit the current from the main op-amp (LM324-amp in the schematic). Given that the maximum voltage expected at the output of LM324-amp is around 4.5V (Vcc – 1V) then we need a resistor of at least 120R to limit the current to 10mA (4.5-3.3 / 0.010 = 120). A 220R resistor should do fine (Rout).

And of course the reason we are using an LM324 rather than the LM358 of the previous designs is that three op-amps are required.

A 1N5817 diode (D2) is used here (rather than a BAT46 – used on the input of LM354-amp) because at the expected maximum current of 10mA the forward voltage drop of the BAT46 is higher than 300mV. The high reverse current of the 1N5817 is not such an issue here because Rout has a low value and so there will only be a small voltage drop across Rout when D2 is reverse biased.

Construction

Schematic
Breadboard

Here are some instructions for assembling this front end on a breadboard. The pin numbers refer to the LM324 PDIP package. Refer to the schematic and breadboard image above. NB. The rail labelled 5V on the schematic is actually VSYS which of course is not necessarily 5V because it depends on how charged the battery is on your Android device.

Connect 3V3 of the Pico to the top red power rail of the breadboard. Connect VSYS to the bottom red power rail. Connect both ground rails of the breadboard to one of the GND pins of the Pico. The fuse as shown in the breadboard image is optional.

Connect the Vcc pin of the LM324 to the VSYS rail. Connect the GND pin of the LM324 to the GND rail. Don’t connect anything to the ADC pin(s) of the Pico yet.

Now we’ll configure each of the 4 op-amps of the LM324 in turn.

Op-amp 2 – Unused
Op-amp 2 (pins 5, 6 and 7 of the PDIP package) is not used so we’ll wire it up as recommended in the TI tech note – How to Properly Configure Unused Operational Amplifiers.

The voltage at the non-inverting input should be approximately VSYS/2 and the output should be the same.

Op-amp 4 – Vref
Wire up this op-amp as shown in the schematic. The voltage at the output should be approximately 1.65V.

Op-amp 3 – sink
Wire up this op-amp as shown in the schematic. The voltage at the output should be 3.3V.

Op-amp 1 – amp
Wire up this op-amp as shown in the schematic, including the under-voltage protection diode on the input (D1) and the current limiting resistor (Rout) and over-voltage protection diode (D2) on the output. Don’t connect the output to the Pico yet.

Testing and initial operation

You should now be able to safely apply any voltage at Vin1/Vin2 of between -18V and +18V. Test that the voltage at the input of the LM324 (Vampin) doesn’t go below -.3V and the voltage at the output of op-amp 2 after Rout (Vadc) doesn’t go above 3.6V.

Once you’ve confirmed that all of the op-amps have been wired correctly you can connect the output of Rout to the ADC pin of the Pico.


The author makes no warranty, representation or guarantees regarding the suitability of this design for any particular purpose. Nor does the author assume any liability arising out its use and specifically disclaims any and all liability, including without limitation special, consequential or incidental damages.

Designing the PCB

PCB Design and Layout

Manufacturing the PCB

The PCB for this project has been manufactured at PCBWay.
Please consider supporting them if you would like your own copy of this PCB, or if you have any PCB of your own that you need to have manufactured.

PCBWay

Assembly

The PCB was assembled with help of a stencil to ease and speed up the solder paste application. The components were then hot-air soldered.
As this is only a prototype, I chose to only place 2.54mm header pins on pins that are required for operation, as well as all the ground pins, to ensure a proper ground plane.

SMD Stencil to speed up assembly

Conclusion

This was quite an interesting project. While everything works as expected, resolution and frequency are limited. ( of course, it is…) The project is however still useful, and will definitely give you some useful results in a pinch.

The logic analyser is by far more useful, but once again, a commercial device will be way more accurate and useful for professional use. Hopefully, the designer will add some protocol filters etc in future.

This device will not replace a proper oscilloscope or logic analyser, but it will definitely give enough accuracy and resolution on low-frequency applications to satisfy some of the basic needs of a beginner or student just starting out with electronics.

It is also important to note that you should be safe, and not try to connect this to high voltages etc. Also, don’t connect this to your expensive phone or tablet, use an old one instead, as accidents may happen, and we don’t want to damage our valuable handheld devices…

An Easy RP2040 Logic Analyzer Shield – Scoppy Scope Part 2

Scoppy Scope Logic analyser Shield with Logic Probes

As part two out of a series of three articles (part 1), This is the Scoppy RP2040 Logic analyzer shield, for use with our Raspberry Pi Pico Carrier board and the Scoppy Oscilloscope firmware for the RP2040.

In Part one, we took a very quick look at the installation of the firmware, as well as the basic limitations for use of this very useful project.

In this part, I want to take a quick look at my Logic Analyser shield, for use with this project, as well as the Raspberry Pi Pico Carrier Board. In part one, we saw that the logic analyzer inputs are limited to 3.3v by the RP2040 GPIO pins. This shield is a prototype attempt to overcome those limitations by using logic-level conversion.

What is on the PCB ?

The PCB is designed to be an add-on shield for the Makeriot2020 Raspberry Pi Pico Carrier Board. (Get your own here) It is in the same form factor as the Arduino Uno shields, but with pinputs specific to the RP2040 and Raspberry Pi Pico.

8 Ch Logic analyser Shield for use with Scoppy and MakerIOT2020 Pico Carrier Board

All Raspberry Pi Pico pins are broken out and labelled, as well as all of the pins specific to the Scoppy App have been clearly labelled. The board are stackable onto the Pico Carrier board, via standard 2.54mm Male Headers, or extra long, stackable female 2.45mm headers, similar to those found on common Arduino shields.

The use of stackable headers will allow simultaneous use of the logic analyser shield and the Analog frontend shield, introduced in part 3 of this series.

In addition to that, a 2×8-way 2.54mm Male header provides access to the 8 logic converted logic analyser inputs.

Logic conversion is done with a simple circuit, comprising a Bss138 N-Channel Mosfet and two 10K resistors per channel.

The shield is powered directly from the Pico Carrier board, which is in turn powered from the OTG cable to the Android Phone or tablet used to display the captured data. ( see Part 1 for installation instructions and other details regarding the Scoppy Project)

The logic level converters allow the use of a 5v logic signal, which is an improvement over the original design, which allowed only 3.3v inputs.

The Schematic and PCB Layout

Logic analyser shield schematic


PCB Layout

Manufacturing

The PCB for this project has been manufactured at PCBWay.
Please consider supporting them if you would like your own copy of this PCB, or if you have any PCB of your own that you need to have manufactured.

PCBWay

Some more pictures of the device

Installation instructions (repeated from Part 1)

Scoppy Scope Installation

All credits for the development of the Scoppy firmware goes to fhdm-dev. This shield is a modification made by MakerIOT2020, and thus belongs to me. In the spirit of the original project, It will however be released to the public as a free open-source project ( free as in free download, free schematic, free design ). The PCB manufacturing files will be made available for free at a later stage, or can be ordered from PCBWay from this link

RP2040 Oscilloscope and Logic Analyser

Oscilloscopes and Logic analysers are essential instruments for every serious electronics hobbyist. They are however quite expensive, and thus beyond the reach of many people starting out with electronics. Today, I will show you a cheap solution, an RP2040 Oscilloscope and Logic analyser…

Before we get started, we need to clear up a few things first:
1). This is not my own project. It was designed and built by someone else.
2). This is not a professional grade Oscilloscope or Logic analyser
3). The range of input voltages, as well as the frequencies that you can measure, are limited.

What is this, and why do I bother with it?

This post is about the Scoppy Occiloscope Firmware, designed by fhdm-dev. I have no affiliation with him/her, I came across this recently and found it useful in the sense that it may help others gain access to instrumentation to greatly help them with electronics.

I did design some derived pcb components that works with this project, in order to take care of some limitations that I saw in the original project. More on that in two follow-up posts, in which I will show you two PCB’s that I designed to use with this project, and analog Frontend ( based on a public design by fhdm-dev, as well as a Logic analyser shield, of my own design

before we do this, we need to look at the basic Scoppy design and its firmware.

Getting Started

You will need a few things to make use of this project, the most important will be the Scoppy App ( available from the Google Playstore ), and an Android Phone.
You will also need a USB OTG Cable/hub for the phone, as well as a Raspberry Pi Pico or Pico W

The Installation and Getting Started Guide is very well documented, and as such, I will not spend a lot of time on that.

My own Setup

I have decided to use my own Raspberry Pi Pico Carrier board for this project, as it will allow me to get away from the breadboard, as well as serve as a platform for easily expanding on the project via expansion shields, as you will see in later articles.

Makeriot2020 Raspberry Pi Pico Carrier Board

This PCB, in Arduino Uno form Factor, will make putting the entire project into a case quite easy, as well as hopefully keep the number of floating hookup wires to a minimum. ( hopefully reducing some notice and other stray signals from interfering too much with our signals)

After installing the application, which is quite easy, we need to load the firmware onto the RP2040. This is also extremely easy is you follow the guide at the top.

Please note that the Android app has two modes, a freeware mode, limited to one channel, and a paid version, with no limitations. I recommend that you consider buying the paid version, as it only costs a few dollars ( I paid $USD2), and will motivate the developer to keep working on the project, and improving it.

Scoppy Application, Main Interface – Oscilloscope
Scoppy Menu
Scoppy Logic Analyser Screen

As we can see, the interface is quite clean, and easy to use.

What are the limitations?

There are quite a few limitations, namely frequency and voltage input.
From what I can understand, the frequency limit seems to be around 25Khz, with the voltage level limit being 0.0v to 3.3v ( as per the limit of the RP2040 ADC

Please make sure that you follow all instructions on the original page, as you can very easily damage your Android device as well as the Pico if you apply a voltage outside of the allowed range.

On the logic analyser side, It is also important to note that you should stay in the 0.0v to 3.3v range of the Pico GPIO’s.

While these limited ranges will definitely limit what you can do and measure, It will still be a very useful project. In the next part of this article, I will show you how I have solved the logic analyser voltage range issue… Allowing you to analyse 5v signals as well.

A versatile easy to use XIAO RP2040 LoRa Fusion

In this post, we will look at a versatile easy-to-use XIAO RP2040 LoRa Fusion. The SEEED Studio Xiao RP2040 should, by now, no longer be a stranger to any of us makers and electronics enthusiasts. At its heart, it contains the same RP2040 processor that is used on the Raspberry Pi Pico.



What makes, the Xiao RP2040, special is its size, only 20.00mm x 17.5mm, as well as the carefully curated combination of GPIO pins, single-sided board construction and castellated pads to make incorporating it directly into a design an absolute pleasure.

Features

  • Powerful MCU: Dual-core ARM Cortex M0+ processor, flexible clock running up to 133 MHz
  • Rich on-chip resources: 264KB of SRAM, and 2MB of onboard Flash memory
  • Flexible compatibility: Support Micropython/Arduino/CircuitPython
  • Easy project operation: Breadboard-friendly & SMD design, no components on the back
  • Small size: As small as a thumb(20×17.5mm) for wearable devices and small projects.
  • Multiple interfaces: 11 digital pins, 4 analog pins, 11 PWM Pins,1 I2C interface, 1 UART interface, 1 SPI interface and 1 SWD Bonding pad interface.

Specifications

ItemValue
CPUDual-core ARM Cortex M0+ processor up to 133MHz
Flash Memory2MB
SRAM264KB
Digital I/O Pins11
Analog I/O Pins4
PWM Pins11
I2C interface1
SPI interface1
UART interface1
Power supply and downloading interfaceType-C
Power3.3V/5V DC
Dimensions20×17.5×3.5mm

The AI-Thinker RA-02 also need no introduction from me, as I have used it extensively in quite a few projects before.

With the worldwide chip shortage, building solutions around the easily available RP2040, and RA-02 makes perfect sense, as these two modules are also super cheap.

For this project, I have also decided to try out a fully factory-assembled PCB to compare quality, as well as the convenience of being able to focus on software without doing assembly first, not that I mind assembling my own boards though… More on that experience later…

What were my intentions with this project?

I had the following goals/needs:
1. A modern, easily obtainable processor, that is not only cheap but also energy efficient. The RP2040, in the form of the Xiao RP2040, fits that goal perfectly.
2. An as-small-as-possible footprint for the main processor, without having to resort to manually designing a Pi Pico derivative – The RP2040 chip is a bit tiny for my eyes
3. The minimum of external supporting components to make the design function
4. Flexible power options ( 3v or 5v )

As to my use intentions, I use quite a few LoRa devices for various different purposes, so adding another option seemed like a good idea.

In the current design, providing that the Arduino libraries stay compatible, the new design will support not only LoRa but also FSK and OOK, with all the advantages of those.

By changing the position of only 3 jumpers, I can also use the PCB for a general-use RP2040 development platform, or another RP2040 project.

Taking all of this into consideration, the device will thus be ideal for any remote sensor application, as well as using it on the bench-top for prototyping

What features are on the PCB?

  1. All of the Xiao RP2040’s pins and pads are broken out onto the PCB, including the SWD port.
  2. The Xiao also has a user LED, and a NeoPixel on-board, which can easily be used for signal indication.
  3. Level shifted 5v I2C port, in addition to the standard 3.3v I2C, because all of our sensors are not always 3.3v compatible, and using external level shifters is not always so convenient.
  4. Access to the RA-02’s GPIOs (DIO1-DIO5) is provided, but most people won’t need to worry about these.
  5. Jumpers to connect some of the Xiao RP2040 GPIO to the special use GPIO on the RA-02, for example, GPIO1 and GPIO2, sometimes used with some of the more specialised LoRa libraries.
  6. Provision or powering the device via a dc barrel connector, or screw-terminal, as well as via the 3v input pins (make sure your supply has a capability of more than 300mA)
  7. A power management chip to reset the Xiao RP2040 when the supply voltage falls below 3.0v – To prevent unstable operation and possible lock-up.

The Schematic

PCB Design and Rendered Images

PCB Design, 2 Layer board
PCB 3D-Render

Manufacturing and Assembly of the PCB

For this project, I have decided to try out SEEED STUDIO’s Fusion Service.
They are after all the manufacturers of the Xiao RP2040 Module that I used, so, when they contacted me a few weeks ago with an invite to try out their Fusion service, I decided to give it a go.

Se​eed Fusion offers one-stop prototyping for PCB manufacture and PCB assembly services, and as a result, they produce superior quality PCBs and Fast Turnkey PCBA in as little as 7 working days. When you prototype with Seeed Fusion, they can definitely provide Free DFA and Free functional tests for you!

So, what was my experience like?

From a design point-of-view, nothing much changed, except that I had to spend a bit more time focusing on the BOM, as my usual go-to for components is LCSC. I, therefore, had to make a few small substitutions on some passive components to ensure that everything was in stock and available.

I also chose to only have the SMD components on the PCB factory assembled. Soldering a few header pins is no trouble anyway.

Manufacturing and shipping lead times were not too long, and I received the assembled boards in about 7 working days from the time of order.

Using the PCB

The Xiao RP2040 has great support for Micropython, CircuitPython as well as the Arduino IDE. There is an excellent article on getting started with the XIAO RP2040 available here , with sections on all three supported development languages and environments.

You can also try out some machine-learning projects with TinyML

As mentioned above, most of the 11 GPIO pins on the XIAO RP2040 were broken out to headers on the PCB, with the exception of those needed for dedicated control of the RA-02 LoRa Module ( D1, D2, D8, D9, D10). In addition to this, some other GPIO, like the I2C pins (D4 and D5) may be accessed on H1 (labelled as SCL/SDA) [3.3v logic] or alternatively on H2 (as SCL/SDA) [ note that this header is level converted to 5.0v ]

To accommodate some other special use features of the RA-02 LoRa Module, J1 and J2 can be jumpered in two positions to connect D3 to DIO1 on the RA-02, and D6 to DIO2 alternatively. Most people will however not need to do this.

When using the Hardware UART on the Xiao RP2040, the jumper at H4 needs to be set to D7/Rx->D7 in order to receive Data, and J2 should be in the default D6/Tx->D6 position

PCB Layout – Showing Jumpers and Headers

Testing the PCB with LoRa

In order to test the functionality, I have written a very simple sketch to test the communication between the PCB and another LoRa device, running a similar sketch…

#include <SPI.h>       // include libraries

#include <LoRa.h> // I used Sandeep Mistry’s LoRa Library, as it is easy to //use and understand


const int csPin = D7;     // LoRa radio chip select

const int resetPin = D1;    // LoRa radio reset

const int irqPin = D2;     // change for your board; must be a hardware //interrupt pin

byte msgCount = 0;      // count of outgoing messages

int interval = 2000;     // interval between sends

long lastSendTime = 0;    // time of last packet send

void setup() {
Serial.begin(115200); // initialize serial
while (!Serial);
Serial.println("LoRa Duplex - Set spreading factor");
// override the default CS, reset, and IRQ pins (optional)
LoRa.setPins(csPin, resetPin, irqPin); // set CS, reset, IRQ pin
if (!LoRa.begin(433E6)) { // initialize ratio at 433 MHz
Serial.println("LoRa init failed. Check your connections.");
while (true); // if failed, do nothing
}
LoRa.setSpreadingFactor(8); // ranges from 6-12,default 7 see API docs
Serial.println("LoRa init succeeded.");
}
void loop() {
if (millis() - lastSendTime > interval) {
String message = "Testing Xiao RP2040 - LoRa "; // send a message
message += msgCount;
sendMessage(message);
Serial.println("Sending " + message);
lastSendTime = millis(); // timestamp the message
interval = random(2000) + 1000; // 2-3 seconds
//msgCount++;
}
// parse for a packet, and call onReceive with the result:
onReceive(LoRa.parsePacket());
}
void sendMessage(String outgoing) {
LoRa.beginPacket(); // start packet
LoRa.print(outgoing); // add payload
LoRa.endPacket(); // finish packet and send it
msgCount++; // increment message ID
}
void onReceive(int packetSize) {
if (packetSize == 0) return; // if there's no packet, return
// read packet header bytes:
String incoming = "";
while (LoRa.available()) {
incoming += (char)LoRa.read();
}
Serial.println("Message: " + incoming);
Serial.println("RSSI: " + String(LoRa.packetRssi()));
Serial.println("Snr: " + String(LoRa.packetSnr()));
Serial.println();
}

Please note that the sketch uses callbacks on receiving messages.

In conclusion

This project was quite interesting, and I am very much impressed with the quality of the assembly done by SEEED Studio’s Fusion Service. The Xiao RP2040 is also a pleasure to work with, and I hope that with future iterations of this prototype, I may be able to produce an even more compact PCB, that will still pack some serious performance punches while being power efficient as well