picotronix – Open Architecture and Modular
The picotronix platform can be the basis of many Test and Measurement solutions
Classic Instrument Design
A typical piece of test instrumentation is configured as a stand alone box with a well defined set of features. A great example would be a scope – like a Tektronix or a Rigol. Standard features – Timebase, Vertical Scale, Pan and Zoom on two or more channels.
The internal design of these instruments are usually proprietary. It is not at all clear what processor, operating system, or development language they use inside. You can’t reprogram them. Often, the manufacturer will enable a control interface allowing automation to some extent, however this can be quite difficult to navigate.
Suppose you want to automate a test procedure in a factory – buying a lot of Tektronix scopes and writing control scripts for them is probably an expensive and clumsy solution. The Test Engineer needs to have a flexible platform that provides the capture features of a scope, but also an easy to use programming environment to develop their code.
Pico Based Instrument Design
The Raspberry Pi Pico microcontroller is an example of Open Architecture systems. Raspberry Pi makes the RP2350 micro, and they also make the Pico module which turns that chip into a standard module anyone can use to build systems with.
The RP2350 is a proprietary chip, but it is supported by extensive documentation and open source libraries of application software. That means if you use a Pico, you know for sure what it can do. An important feature is that the Pico is fully integrated with a micropython development environment, which greatly extends the accessibility of the device. The engineer does not need to read 800 pages of data sheets to get the Pico doing something useful.
So, unlike instruments like the Tektronix and Rigols, if you build a test platform based on the Open Architecture Pico, designing a custom measurement platform is much more convenient.
Picotronix – a Modular Instrument Platform
The picotronix MainBoard is built around two Pico microcontrollers and provides a flexible set of interfaces to external signals.
The block diagram shows the basic architecture of picotronix.
External signals are applied via “POD” connectors – two analog PODs and a general purpose digital POD.
The analog pods (10 pin) accept a 3Vpp signal which is used internally to generate Trigger levels and drive ADC chips.
The digital POD (26 pin) provides access to the Pico GPIO pins allowing Raspberry Pi PIO State Machines to interface with external circuits. This POD also has access to the internal 3V Analog Buses, so external ADC circuits may be connected.
Networks and Datagrams
A modular Test Platform can be stand-alone, or it may be part of a system. The Pico 2W has a fully integrated wifi module, so it can form part of a networked system. In the block diagram this function would be provided by the “Pico Control”. The Pico Control interfaces to the Pico Data block which has access to the external connections.
picotronix uses a datagram which is Picogram – a custom format which allows for data and control to be passed between system components. This datagram fits very well with the modular design of picotronix – the picogram will specify how the data should be acquired, and what format to present it in. The Pico can be programmed in micropython which is a great language to interface across a network.
Hardware – Open Source or Open Architecture?
Open Source Software (OSS) is now very well established, particularly in the Linux world. Many developers contribute and the software design is highly visible. Bugs are easily fixed in the field by a software update.
Open Source Hardware is not the same. Hardware cannot be fixed by a download. Making hardware designs open invites anyone to make their own copy. The hardware design process involves a lot of experience, testing and iteration. Even small changes can have unexpected consequences. A copy of a hardware design may not work exactly the same as the original.
The other problem with open hardware is that it makes it easy to modify the design slightly. This may seem like an advantage, but it actually makes the design less useful. Any modification will require software changes to support the new feature, and this then must be integrated into the software stack. Complex revisions and special cases invite bugs and issues.
Open Architecture means that the platform is a “known quantity”. Engineers can build systems based on the known and documented features and be confident that they will get consistent results.
