This article is intended for those who are planning to scale their POC(proof of concept). But, you can read it even if you wish to do it one day. Or just read it for fun, which I hope it will be.

slice media player with pi compute module

Now, before jumping into the technical part, let this be clear. Our incentive for changing the hardware is maximum profit and optimum quality but not the creation of an over-killed foldable refrigerator kind of thing. You have made a working prototype. All the functionalities you need in the final product are there in your POC. Now you want to make use of economies of scaling for maximum profit. And yeah, we need to improve the quality and built of the hardware, at the same time not over-engineering it.

Since it will be a long topic, I am dividing this into 3 subparts. This article is part 1.

Part 1

Do you want to move up from raspberry pi?

Connectivity Constraints

Part 2

Computation power constraints

Form factor Constraints

Energy Constraints

Part 3

Pi Compute Module

Off the shelf modules vs OEM components

The first question you should ask yourself.

“ Do I really want to change the hardware? “

See, if you are aiming for 100s of unit production, most of the time it is better to stick to the pi itself. Why did I say most of the time? It is because there are some situations(below) which inherently prevent us from using raspberry pi in our final product.

Form factor Issue.

pi and pi zero

We need to improve the form factor of the product as we cannot afford the size and all those extra ports in the pi. Pi zero is a good option here. But yeah, after compromising computational power.

Energy Efficiency

The pi SoC and its architecture are not that good in terms of energy efficiency. There are better architectures out there and system approaches like big-little, which gives you a huge advantage in terms of energy efficiency. Think of it like this, for the given processing power, you can get 10 times more efficient systems.

It’s a wearable product

Most wearable products will already have energy efficiency constraint. But even if it’s not there, you may have to think about changing the system. Because mechanical connection likes SD connector is a big downer for wearable devices. Especially since it acts as the primary storage medium. Talking about that, make sure you have something similar to eMMC if you are using wearable tech. Its better, smoother, and you can avoid those occasional glitches which can appear while your user goes for their daily morning run.

So that’s it. I will advise you to stick to the pi if the above constraints are not applicable for you. And obviously, if you are making it in 100s. There is a misconception that raspberry pi is not good for the final product, its not true. I think it’s because it became so omnipresent in the tech community, some people prefer to think of it as just a hobbyist item.

Connectivity Constraints

A perfectly designed processing board is pure magic. For intermediate engineers like me, it’s an absolute supernatural creation, which we always dream to make. Yet, there are magicians all over the globe who does it with ease.

Now you have decided to go forward with changing/improving the hardware. You need to think of what are the parameters you have to think about while choosing the CPU, SoC, RAM etc.. Connectivity constraints are a good point to start.

Wired Connectivity

USB

Till Pi 4, we were having USB 2.0. Then suddenly, we got USB 3.0 with a speed of 5 Gbps [theoretical :( ]. Now we can use it for applications like uncompressed Video streaming and network-connected storage. But, while selecting the next platform, choose wisely. A USB 2.0 host controller chip will always be cheaper than its USB 3.0 version. So, If you don’t have any use of USB3.0, use the older one, unless you want to show off your hardware superiority just for the sake of it.

Here is a link to an article about USB devices. which can be a good starting point.

HDMI

One of the most widely used uncompressed video interface. If you are using one of them in the product, probably you won’t have the issue of energy constraint, nor it will be wearable tech. There are different versions of HDMI with various bandwidth, supporting different resolutions. Choose wisely. If an HDMI 1.3 can do the job and is cheaper than 2.0 (Not always true as USB 2.0 and 3.0), go for it.

UART Serial

I am talking about our good old RS232 protocol for low bandwidth communications. RPI has one dedicated port for this. Though we can configure other GPIOs to do the job, I won’t prefer that. Not reliable even at low baud rates. Since this being a protocol/interface existing from prehistoric times, there are hardware converters from other protocols like USB, I2C, SPI etc. Why I am telling you this is because, if you are looking for a system with multiple serial ports, there are other hardware options to widen your options.

I2C

A sleek protocol/interface, if we want to connect multiple devices in a single port. It follows the bus topology with a single master(commanding at a time) and multiple slaves. Every slave/device in the connection will have a unique address, which we use to communicate with it. There will be a problem while using multiple units of the same hardware in same network since they can have the same address. Hardware manufacturers sometimes provide a backup address which will be automatically used in-case the main one is used by another slave. But there are always address translator ICs which will shift the address of that particular slave externally.

SPI

This too is a single master - multiple slave interface. Since we don’t need the address overhead anymore, it means more bandwidth than I2C. One disadvantage of SPI over USB is that they don't use differential signalling. So, noises will eventually creep during high-speed transmission or if wiring is poorly planned. Why am I saying this? Many, if not most MCUs and CPUs contains SPI interface. It’s easy to implement as well. If you use USB in your pi POC, and your USB device is also in the prototyping stage, you can remove USB interface from your project altogether. Obviously, if the noise problem I mentioned above is not an issue. It will save you the cost of the USB host and device or hub.

Wireless Connectivity

Wifi

There are different protocols like 802.11.a, b,g,n, ac. Each of them has different bandwidth, maximum speed, covered distance. This table may be helpful for you.

While selecting the Wifi module/ modem/ SoC , choose wisely. The communicating interface of the module is also very important. If there is an 802.11 ac module with UART serial protocol, it’s basically a waste of money. As the speed of the entire module is dependent on the serial speed. The standards specify theoretical speeds. So the realistic speed varies across manufacturers. So before choosing them for your product, go through its datasheets, reviews and test it with a dev board.

Bluetooth

There are many wifi chips which come with Bluetooth as well. Like wifi, there are many versions of Bluetooth. There are some backward compatibility issues with Bluetooth. So you need to be careful here. If you already have wifi as a primary wireless interface, then getting too much excited about the improved speed of new Bluetooth versions is kind of stupid, unless of-course your application needs high bandwidth Bluetooth. Other than that, choose the Bluetooth version depending upon the maximum number of user devices you plan to communicate with (Think about the future as well), range, power consumption and cost.

Augniscient (becoming omniscient through augment reality :D) is a young startup working on visual communication based wearable devices. Check out our website. www.augniscient.com