Canique Pico Gateway

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).

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

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.

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

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.

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.

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.

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. https://forums.mbed.com/t/slow-handshake-for-mbed-tls/5648/6 - 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.