We recently received a Red Pitaya, a successfully funded kickstarter campaign for open source instrumentation. The Red Pitaya has a Dual core ARM Cortex A9+ FPGA with 4GB of ram, with the circuitry to handle fast analog inputs, analog outputs, and digital GPIO. It is similar to the Parallella in that it shares the same Zynq processor, but includes a nice analog front-end for signal capture and measurements. The concept of the Red Pitaya project is to build a software platform on top of a powerful hardware platform capable of measuring precise voltages, taking advantage of the hardware in various ways. Similar to an app store, except for measurement devices.
Since the Red Pitaya has an FPGA and a fully functioning Linux environment, we can take full advantage of the hardware by writing custom VHDL code for very fast response times. The Red Pitaya has a 16 pin port dedicated for GPIO for the FPGA, which can be used to easily integrate the Red Pitaya with test fixtures for example.
We envision leveraging the Red Pitaya in a variety of applications where a simple ARM, FPGA, or PC wouldn’t be sufficient independently. In the example of an automated PCB test fixture, this platform provides 16 pin GPIO manipulation with 6 channels of oscilloscope measurements with 6 channels of analog outputs. By utilizing a bit of custom VHDL code for the FPGA, we could quickly exercise a variety of subsystems to determine if a circuit is performing as expected. Since the Red Pitaya can also be connected to the network, we can perform full signal capture over TCP/IP, which would allow for the heavy signal processing to be offloaded to a more powerful computer along with data collection and logging. This provides a very powerful and reusable platform for test. For example, since all of the measurements are taking place on the Zynq processor, the 6 analog measurements can be used as parameters in a PID control loop, which can then trigger additional VHDL logic in response to a voltage reading which is higher than expected.
With the Red Pitaya’s fairly unique architecture, the barrier to high speed analog, digital, and logic manipulation and analysis just became a lot lower. Speed and efficiency is highly valued for the projects we run at Sparx.
One of the first hurdles to overcome was connecting the Red Pitaya to the network. To do this, I connected to its serial port and looked to see what binaries were available in /bin and /sbin.
I discovered that ifconfig was present, but not dhclient. I also discovered a strange flag in /opt/etc/network/interfaces:
[bash wraplines=”true”]iface eth0 inet dhcp
udhcpc_opts -t7 -T3[/bash]
That’s how I discovered that /sbin/udhcpc could also be used for getting a dynamic IP. So after bringing up the interface, I can now get an IP address.
[bash wraplines=”true”]ifconfig eth0 up
udhcpc -i eth0[/bash]
The message on device startup indicated that /opt/etc/init.d/rcS can be modified to run user commands on startup. So if I run /opt/sbin/rw to switch the filesystem to read-write, I could add any necessary commands to configure the network interface to automatically connect. After initially editing /opt/etc/init.d/rcS to include bringing up the interface and getting a DHCP IP, I found that I no longer need to have those lines. I suspect that acquiring DHCP while the filesystem was in read/write mode, allowed resolv.conf to be updated with our nameserver (thus, it can get an IP address every time).
We configured the oscilloscope probes to the HV, +/- 20 V setting.
After connecting to it through the Red Pitaya Discovery Portal, I was finally able to connect to the oscilloscope:
As you can see in the Measure Panel, the measurements are averaging 3.073V for the 3.3V signal, and 13.0V for the 12V signal. I found that reducing the probe attenuation to 1x seemed to help the error a bit, but there was still a significant offset.
Improving the accuracy is possible through calibration, but for general ballpark measurements, the current accuracy may be good enough.
We are just starting to work with this hardware, so I’m sure we’ll gain a lot more insight soon on how best to utilize this new hardware. So far, the Red Pitaya is turning out to be a great networked tool that offers a lot of capabilities that a traditional oscilloscope, signal generator, or logic analyzer traditionally don’t have, so its exciting to see where we can take this tool. As is usual here, we’ll push this hardware to its limits.
Hey Dustin, I find this one excellent review.
One remark: The connection itself would be a lot smoother (no need for Serial port) – but it was not instructed in the first release of the Quick Start Guide. All you had to do was to follow the instructions from the discovery page.
Sorry for that.
“we’ll push this hardware to its limits.” – go ahead! Pls let us know about it. Tx
The Red Pitaya was a Kickstarter project, so its natural for it to be a bit rough around the edges.
Ales informed me that since the software that shipped on it didn’t have hotplug ethernet support, that that was likely my source of error. But by running into that problem, I learned a lot about the structure of the Red Pitaya Linux environment, and ultimately succeeded in getting it to work.
Nice to see your plans for your future power-use of Red Pitaya! 🙂
A few technical comments regarding the network configuration, to get a better insight of the problems you have had:
Indeed, the dhclient is not present, since the equivalent and smaller udhcpc DHCP client is used.
The “udhcpc_opts -t7 -T3” flag in /opt/etc/network/interfaces file are the udhcpc command line options and they increase its timeout to 7×3 = ~20 seconds.
Instead of using “ifconfig eth0 up” & “udhcpc -i eth0” I recommend using “ifup eth0” (or “ifdown eth0”), which will bring up (or down) the specific network interface according to the settings in /opt/etc/network/interfaces file- static or dynamic/DHCP, with specific timeout… whatever is set there.
There is actually no need to bring the network up manually using “ifup eth0” or your method neither from the console nor by editing the user’s startup script in /opt/etc/init.d/rcS, since this is done at boot time automatically in /etc/init.d/rcS. However, this can and will fail if there is no network cable plugged into Red Pitaya at boot time or your DHCP server is not responsive when Red Pitaya is booting. I believe this was the source of your problems.
This is the limitation of the current ecosystem release version 0.90.
The “devel” branch on GitHub on the other hand adds support for “hot-plug”, which allows for Ethernet cable insertions at any time, and is to be included in one of the next ecosystem releases.
The resolv.conf does not need the SD card filesystem to be in read-write mode. It resides in /tmp/resolv.conf (RAM/tmpfs) and /tmp is read-write by default. This file is of course generated by the “udhcpc” only if your DHCP server serves the DNS resolver option.
It does seem now that the problems I ran into were due to the network cable or DHCP server being slightly unresponsive, but once I was able to connect to the network, it has had no problems since then (I have also updated the software since this post so that I’m using the latest versions from your development branch). I bet if I updated to the latest development branch right away, I wouldn’t have had any network connection problems.
So after almost a year has the red pitaya been used for any serious work?
I have a few coworkers with pc-based oscilloscopes but they honestly seem so clunky compared to turning on a low-cost ($300) real scope , adjusting with knobs, and measuring..
But the red pitaya seems different in that it could be used for much more.. specifically I thought it would be great tool to develop simulink models targeted to the fpga. One application I had in mind was a low performance analog chart recorder that can play back the recorded data. But at $600 for the Red Pitaya, there’s cheaper solutions.
What are your thoughts? What sort of things have you used it for?
The Red Pitaya has a lot of potential for unique applications as you have described. If you have the time to develop simulink models for the fpga, then you may be in a good position to take advantage of the uniqueness of the Red Pitaya platform. The user interface for the Red Pitaya oscilloscope doesn’t provide the configuration that a real physical oscilloscope has (or even a PC based one), so for quickly viewing a troublesome signal, I use a stand alone scope.
Be sure to factor your time into your consideration for the Red Pitaya. If it takes you a significant amount of time to develop the tools your talking about, then it may not be worth it. If you can buy the cheaper off the shelf solutions that already do what you want, then that sounds like the route to go.