Canique Pico Gateway

An 868MHz to MQTT message gateway using a Raspberry Pico

Similar projects worth following
Canique Pico Gateway receives encrypted radio messages from Canique environmental sensors, decrypts them, and forwards them to a custom configurable MQTT server (using a TLSv1.2 connection or plain TCP).
In a later stage it will be able to receive radio messages from other devices and just forward them to an MQTT server.
You can access the most recent sensor data via HTTP request in JSON format because Canique Pico Gateway has an embedded HTTP server onboard.

The HTTP server also serves a settings webpage to change settings.
You can switch between DHCP or static network configuration.
You can set MQTT host, port, keepalive time and user credentials.

Canique Pico Gateway uses an RP2040 chip as its core, and a Wiznet W5500 chip for its ethernet connection.

Embedded HTTP server

The embedded HTTP server comes along with the following JSON formatted status pages (cnq-pico-ip is a placeholder for the real IP address):

http://cnq-pico-ip/getStatus.cnq - provides you with information about network/MQTT status, uptime, current time, firmware version

http://cnq-pico-ip/getSensors.cnq - outputs current sensor data (like temperature, rel. humidity, barometric pressure) along with a timestamp, RSSI, and battery status (in millivolts) for each sensor that sent radio messages to this gateway

The HTTP server runs on its own core on the RP2040 chip so it should work no matter what the other core is doing.


The Rasperry Pico LED shows the MQTT connection status. It will turn green when an MQTT connection has been successfully established and turn off when the connection seems broken or when you unplug the network cable.

The TX LED will blink whenever a radio message is sent (e.g. to acknowledge a message).

The RX LED will blink whenever a signal is detected that is above the noise floor. If the RX LED is blinking all the time or if it seems to be constantly turned on, then this indicates that there is an interference in the proximity of the device. This can be a television, loudspeaker, a computer, a monitor or some network device, etc. interfering with the 868 MHz radio. To resolve this, you need more distance between the Canique Pico Gateway and the interfering device.


If you enter wrong network settings on the HTTP settings page, you won't be able to access the HTTP page again, because the network won't be connected, right?

There's a simple solution to prevent you from locking yourself out: Keep the black button pressed for a minimum of 3 seconds, and the Canique Pico Gateway will restore factory network settings (DHCP).

Power efficient!

The RP2040 chip is sleeping whenever possible to save power. It will wake up on radio messages, MQTT keepalive pings or messages, DHCP or DNS timers, network link changes, HTTP requests or button presses.


The complete startup of Canique Pico Gateway after connecting it to a USB power supply took less than 5 seconds during a test! This included: DHCP IP address retrieval, time synchronization via SNTP, DNS lookups, establishing a secure TLSv1.2 connection using the TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256 cipher and an MQTT connection.

The TLS connection alone has been established in roughly 1.2 seconds during that test.


The supported TLS ciphers are restricted to only a few good ones to keep the connection secure. In a future firmware version TLSv1.3 support will be added. Note, though, that the ciphers currently used are also part of TLSv1.3.

If you specify an IP address as MQTT server, no TLS will be used. A plain TCP connection will be established. This is e.g. useful if your MQTT server is in the same local network.

TLS Compatibility

The TLS connection has been tested successfully with Canique Cloud and HiveMQ Cloud (free version).

The Pico Gateway firmware contains these root certificates by default:

Let's Encrypt ISRG Root X1 (Root Certificate, RSA 4096 bits, valid until 2035)

Let's Encrypt ISRG Root X2 (ECDSA P-384, valid until 2040)


Power consumption: 0.7W

RJ45: used for DNS, DHCP, SNTP and TLSv1.2 connection to the MQTT server and for serving HTTP requests
USB for power supply and firmware updates
u.FL for 868 MHz antenna

Supported TLS versions: TLSv1.2
Supported TLS Ciphers:

Root certificates:
 Let's Encrypt ISRG Root X1 (Root Certificate, RSA 4096 bits, valid until 2035)
 Let's Encrypt ISRG Root X2 (ECDSA P-384, valid until 2040)

Supported MQTT version: 3.1.1


First draft of 3D case - top

step - 83.61 kB - 09/22/2022 at 13:24



First draft of 3D case - bottom

step - 78.84 kB - 09/22/2022 at 13:24


  • Revision 0.8.2

    canique02/25/2023 at 12:33 0 comments

    Revision 0.8.2 comes with an SMA connector directly soldered on the board.

    First tests have shown a noise floor of about -110 dBm (during operation at 25kbps).

  • 3D printed case

    canique10/05/2022 at 17:18 0 comments

    This is the pico gateway in a 3D printed case.

    4 self tapping screws are used to keep the enclosure parts together: M2.6 x 8mm

    4 self tapping screws are used to mount the PCB to the enclosure: M2 x 4mm

  • 3D printable enclosure

    canique09/22/2022 at 13:27 0 comments

    I've uploaded the files for a 3D printable enclosure (v0.0.2).

    In 1-2 weeks I will post a picture of a Canique Pico Gateway installed in such an enclosure.

    Some small adjustments are still to be made to the drawing yet.

  • Availability

    canique09/04/2022 at 22:05 0 comments

    The Pico Gateway will be available for sale by March 2023.

  • Current resource consumption

    canique08/27/2022 at 19:21 0 comments

    After embedding

    • some HTTP server content
    • some root certificates
    • code to output JSON formatted data (also the HTTP settings page just parses JSON data fetched via Javascript)
    • a DNS library
    • an SNTP library
    • Mbed-TLS
    • the Paho MQTT library

    the flash consumption is 251KB and static memory consumption is around 78K currently.

    Remember that we have 2048KB flash and 256KB memory at our disposal.

  • Wiznet or Ethernet PHY?

    canique08/27/2022 at 18:57 0 comments

    To get fast results I went the Wiznet way. There was already some software support, even sample projects were available for Raspberry Pico.

    To me it was important to have a working software layer in C that would just work reliably. I tested everything was working by first connecting a Raspberry Pico to a Wiznet board with a W5500 chip. When I knew there were no issues, I designed the PCB.

    I opted for the Wiznet W5500 because it would support 8 simultaneous connections (whereas the other variants didn't or were more expensive, e.g. W5100 only has 4 sockets). Additionally it would offload the RP2040 and its RAM having its own 32K buffer.

    If you think about the different protocols involved: DHCP, DNS, SNTP, MQTT, HTTP ... and you don't want to reconfigure sockets all the time, then more sockets is  definitely better.

  • How to connect to a network?

    canique08/27/2022 at 18:42 0 comments

    I could have gone the WiFi way or the ethernet way.

    I wanted to take the "secure" route first. WiFi might interfere with 868MHz radio, since there are big current spikes in WiFi chips which translate to voltage fluctuations and hence to radio emissions.

    The other thing about WiFi is that it can be jammed more easily. A network cable is more robust and still can be 100 meters long. WiFi is much more limited in range.

    And then there's user experience. With WiFi you might be more flexible in positioning the device but it can stop working from one day to the other and you'll never know why if you aren't an experienced user. This happened to me with a Raspberry Pi type computer. It was working for years and suddenly it would just lose the WiFi connection most of the time. It turned out that some new neighbour was transmitting on that very channel. A channel change on my side quickly fixed the problem. But you see: WiFi is not always "fire and forget".

    Canique devices are meant to be fire-and-forget, though. This is why an old-fashioned RJ45 connection seemed wiser.

  • Why use an RP2040?

    canique08/27/2022 at 18:24 0 comments

    When deciding which MCU to use as the core of this Gateway, there were a couple of things to consider...

    • Lots of RAM/Flash for TLS: TLS libraries need lots of RAM and Flash to establish a connection. This narrows down your possibilities to some expensive MCUs because generally speaking the MCUs with lots of RAM and Flash are also the ones with lots of (maybe unneeded) peripherals.
      The Raspberry Pico comes with 2MB of Flash and 256KB of RAM which is more than enough to use any modern TLS cipher. It even has 2 Cortex M0+ cores which give it a good price/performance ratio.
      The overall price could further be reduced by using a smaller Flash chip (it is external to the RP2040) and by replacing the Buck regulator (RT6150B-33GQW) by a cheaper version.
    • Fast TLS: When you look for benchmarks in the internet to see common connection speeds (1-30 seconds), you could stumble upon this e.g. - 1.2 seconds on an STM32F4 @ 144 MHz for a TLS connection using ECDHE/ECDSA. So even using a high performance Cortex-M4 MCU does not get you below 1.2 seconds.
      Canique Pico Gateway does get below that number (screenshot in the gallery) using an RP2040. Clock speed is crucial here.

    Initial Requirements:

    The minimum required Flash should be 200KB (100KB was expected solely for the TLS library). Currently the image has a size of 251KB.

    The minimum required RAM should be 40K. Currently the TLS layer alone uses a static 50K of RAM.

    Hardware encryption and/or a hardware RNG would be a plus (unfortunately RP2040 does not have either).

    Still the price/performance of the Raspberry Pico was so good and the availability much better than the rivals (like STM32G0B0CE or STM32G0C1KC), that I opted for the Pico.

View all 8 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

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