RoadTest the Raspberry Pi 4 Model B (2GB) - Review

Name: RoadTest the Raspberry Pi 4 Model B (2GB)
Rating: 4.8137255 (17 reviews)

jwilson over 3 years ago

RoadTest: RoadTest the Raspberry Pi 4 Model B (2GB)

Author: jwilson

Creation date: 5 Oct 2019

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?:

What were the biggest problems encountered?: An owner of previous Raspberry Pi board will probably need to purchase new power and display cables.

Detailed Review:

The Raspberry Pi 4 comes with impressive connectivity in a small package: 4 USB ports (2x 2.0, 2x 3.0), gigabit Ethernet, dual 4K-capable HDMI ports, in addition to CSI and GPIO headers for interfacing with a variety of physical computing peripherals. True to its roots as a minimalist computing platform, the Raspberry Pi 4 comes with only the board itself; you'll need to supply storage, cables, and peripherals to get started.

One of the most interesting and controversial changes in the Pi 4 hardware has been the USB-C power connector. The controversy arose when it was discovered the Pi 4 was incompatible with laptop power supplies that implement the USB-PD standard. The culprit turned out to be the omission of a single resistor, and a bit of an embarrassment to the Raspberry Pi Foundation. The Raspberry Pi Foundation has said this will be addressed in a future board revision. Is this reason to reconsider buying the current Pi 4? In my opinion, no. As I will cover in my review of power consumption, the Pi 4 uses nowhere near the power available from USB-PD power supplies. Most USB-PD power supplies cost more than the Pi 4 itself, meaning using a USB-PD power supply with the Pi 4 is a bit of waste of one's resources. Similarly, there is no need for expensive PD-rated cables; in my testing I used an ordinary A-to-C data cable to power the Pi 4. On the whole, the USB-C power connector is a bit of a head-scratcher – the micro-B connector isn't disappearing anytime soon, and this board layout mistake aside, the Pi 4 doesn't have any circuitry for doing USB-PD negotiation. On the other hand, the Pi 4 still uses full-sized stacked USB-A connectors that are the tallest component on the board. Switching some or all of the USB peripheral ports to USB-C connectors would open up some board space for other use and reduce the vertical form factor.

For those upgrading from a previous Raspberry Pi, in addition to a USB-C cable, you will need a new HDMI cable. To drive two displays, the Pi 4 uses micro-HDMI connectors to save space on the board. Micro-HDMI cables are easy to find, but you'll want to have them on hand if you want to get started using your new Pi 4 right away.

Building a voice assistant for oscilloscopes

As I've been building my own switched-mode DC-DC power converters, one of things I've learned is probing them requires careful technique. Using the supplied long ground wire with your probe is a good way to get unwanted inductive coupling, which will obscure your signal when you're probing a low-level current sense line close to a power inductor. Getting good signal integrity requires using the ground wire spring, which requires carefully orienting the probe to maintain a solid mechanical and electrical connection. If you need to probe two points, all of sudden your hands are full!

For several months, I've been using the Raspberry Pi as a platform for voice control of oscilloscopes. I named the project Ollie and have made the source code, along with complete customized Raspbian images, available as free software on Github (https://github.com/jmwilson/ollie ). Ollie currently works for both Keysight and Rigol oscilloscopes and you can control most of the typical front-panel operations with your voice.

Voice control is a natural fit for human-computer interaction when the hands or eyes are occupied, but I was surprised that it's not an option with most oscilloscopes. The exception seems to be Keysight's 6000-X series, but that's a lot of oscilloscope, both in terms of desk space and price. I first learned about the Snips voice platform at a Maker Faire event two years ago, and it seemed like a strong fit for field-deployable voice assistants. It runs completely on-device, skipping the need for a network connection and avoiding the murky privacy questions of cloud-based voice processing. Snips is partially open-source and free for noncommercial use, and they officially support the Raspberry Pi! Currently, Snips has yet to ship an official release for Debian 10 ("buster") that is needed for the Pi 4, but I was able to follow workaround steps to get the platform running for testing. The Snips team has done some research on available microphone expansions for the Pi, and I went with their recommendation of SeeedStudio's ReSpeaker 2 Pi Hat - it's an inexpensive dual microphone hat that's the same dimensions as a Pi Zero. The board even has some APA102 LEDs controllable by SPI, which I found would come in handy for simple user feedback.

Pi 4 with the ReSpeaker 2 microphone hat installed

Building voice assistants with Snips is straightforward, even for those without experience with voice applications. Creating commands (referred to as intents) and training examples is done on the Snips website. You'll want to think of as many ways as possible to phrase your intents ("what's the amplitude on channel one" / "show me the amplitude of channel" / "measure amplitude for channel one" / etc.) to ensure the best recognition. Once you're done, Snips will provide you a trained assistant file to download.

Creating intents and training examples on the Snips console website (https://console.snips.ai/ )

For controlling an oscilloscope, I tried to think of the common operations I would like to do hands-free. The front panel of a scope gives a good idea of where to start: changing the horizontal and vertical scales, adding measurements, adjusting the trigger, and starting and stopping capture. The full set of commands, along with examples, is listed on the Github project page. Nearly all modern digital test instruments support some form of remote control, either through USB, GPIB, or a LAN port. The USB standard even defines a device class and protocol for controlling test instruments called USBTMC. I chose to use USB since it's fairly easy to work with; no network setup and addressing is required. On Linux, USBTMC devices are natively supported and exposed as character devices named like /dev/usbtmc0, which means you can read from and write to them by piping regular shell commands!

I wanted the device to be as small as possible since bench space is always at a premium. I built the initial version on the Pi 3A+ since it's the smallest Pi that can run Snips. I also relied on using LED sequences as visual feedback instead of a screen. The LEDs light up when the wake word is spoken, and animate in a flashing pattern while processing. The software architecture of Ollie is fairly simple. The Snips platform publishes recognized intents on a local MQTT server. Ollie runs as a Python service that listens to messages on the MQTT channel and translates the intents into USBTMC commands. Keysight and Rigol both provide programming manuals for their scopes that detail the syntax of commands, for example, to show the trace for channel two, you would send ":CHANNEL2:DISPLAY ON" over the USB connection. Ollie also manages the USB connection to the oscilloscope and the feedback sequences to display on the Respeaker's LEDs.

System block diagram and communication protocols used by Ollie

Running Ollie on the Raspberry Pi 4B and hands-free oscilloscope operation

One of the limiting factors of voice assistants is speed. Our expectations of speech as a medium is set by our interactions with other humans, thus voice interfaces with computers that are slow or halting are singularly frustrating. While Ollie runs well on the Pi 3A+, I realized it was because I had adjusted my speech to assist it, inserting a short pause after the wake word, or waiting for the LEDs to guide my response. I was excited to try out the Pi 4 to see if it could process commands faster.

To do the comparison, I set up the 3A+ and the 4B to run Ollie simultaneously and collected the profiling data from system logs on a script of 17 spoken commands. I compared the latency to recognize the end of a spoken command, the post-processing time, and total completion time. On average, the Pi 4 is 49 ms (-25.4 %) faster at endpoint detection, 10 ms (-37.9 %) faster at post-processing. What does this mean in real usage? The numbers seem small but it the improvement is usability is perceptible; the Pi 4 feels more responsive. Although I didn't have a way to measure hotword detection latency, I definitely found it possible to speak faster to Ollie running on the Pi 4.

Benchmarking Snips performance on the Raspberry Pi 3A+ and 4B. All times are in seconds (s).

Power consumption

As the Raspberry Pi platform has matured and bumped up its specs, its need for capable power supplies has come into focus. With the earliest revisions of the Pi, one simply grabbed any spare phone charger to use, but since the Pi 3 it's been recommended to use something rated for at least 10 W or buy the official power supply. As I was doing my testing, I wanted to look at how the Pi 4's power consumption compared to its predecessors.

To measure power usage, I connected the 5V and GND GPIO pins to a bench power supply and measured the current with a logging multimeter. Note that powering the Pi 4 from the GPIO pins completely bypasses all of the reverse polarity and power circuitry protection, but I trust my power supply and myself, at least to some extent after I've triple-checked the connections before flipping the switch.

Monitoring power usage of the Pi 4

The idle current draw with only a wireless keyboard/mouse dongle connected was 700 mA, or 3.5 W of power. When I played a H.264 video stream, the current draw increased to 950 mA, or 4.75 W of power. This means for playing media, the Pi 4 is just on the edge of of what a typical 5 W phone charger can deliver. To test my hunch this would probably be an unstable configuration, I tried streaming video while powering the Pi 4 from a 5 W phone charger. At this point, the Pi 4 would typically reboot after less than a minute or two. If you want to use the Pi 4 as a media center, a 10 W power supply is definitely required.

To stress the CPU, I compiled cpuburn (https://github.com/ssvb/cpuburn-arm ) designed for the Cortex A53 (no version tailored for the Pi 4's A72 cores was available) and ran this while logging the current on the 34461A and monitoring the system temperature and processor clock readout. As you can see from the figure, the power consumption jumps from 3.5 W at idle to 7 W at full CPU load. The system begins throttling at a core temperature of 80 C, and you can see the current draw then fluctuate in a band that keeps the CPU on the edge of its thermal limit. If the system only draws 7 W at full CPU load, why is the official Raspberry Pi power supply rated at 15 W? The answer, is to supply peripherals and hat boards. A 15 W power supply gives you 7 W of headroom for power-hungry peripherals even at full CPU load. This test also shows that active cooling is essential for applications that will use the full capabilities of the CPU.

Raspberry Pi 4 idle current and stress test

How does this compare to previous Raspberry Pi generations? Since the previous Pi I used for Ollie was a 3A+, I connected it in the same manner and ran cpuburn. From the chart below, you can see the idle current draw for a 3A+ is a mere 250 mA, or 1.25 W. This is to be expected since the 3A+ is missing several USB ports and the ethernet PHY, along with their power-consuming controllers. When running cpuburn, the power consumption is almost identical to the Pi 4. This suggests to me that the BCM2837 and BCM2711 have similar thermal design points.

Raspberry Pi 3A+ idle current and stress test

Conclusion

The Pi 4 is a solid improvement over its predecessors. The capabilities and interfaces available on this $35-55 device, coupled with the robust community support makes it one of the best choices for single-board computer projects. Snips makes it possible to build offline, field-deployable voice assistants that run on a credit-card sized device - something that seemed out reach of makers only a few years ago! A big thanks to element14 for choosing me as first-time road tester, and to the Raspberry Pi Foundation for making them available.