How do you feel about this article? Help us to provide better content for you.
Thank you! Your feedback has been received.
There was a problem submitting your feedback, please try again later.
What do you think of this article?
The Red Pitaya has matured and is now out in the hands of users. I too have a device that I have been playing with for the last few weeks. It really is a great device. The fact that it has a very accessible IO for post processing to the size and cost make this a device that is attractive to hobbiest and professionals alike.
The device fills a gap that is in the test equipment market, and while the Red Pitaya has not yet filled its full potential (this will be realized as users begin to develop their own applications for the device) it has opened the doors to many to having great test equipment in their own personal lab.
A few months back I was able to interview the crew of the Red Pitaya. I share with you their answers. So sit back with your favorite exotic fruit and enjoy.
1. What were the major design constraints for the project and how did they shape the end product? (Some examples might include cost, size, and features)
- All three mentioned, plus appeal to a broader audience.
- Delivering set of high end measurement and control tools on a single platform at a convenient price.
- Plus an open platform dimension, stimulating and supporting user's creativity.
2. Were there any features that you would have liked to have include, but could not due to a specific design constraint, if so what was the feature that was left out, or reduced, and what was the deciding factor to remove/reduce the feature?
It may be misleading to consider the hardware side to be carved in stone. Hardware can actually be reconfigured through FPGA and additional module can bring extended functionality. As far as the Red Pitaya module, the key criteria was: strip the unit down to the most essential common denominator of features, form a solid foundation and sharpen the performance at an acceptable price. That is why we wanted to be as generic as possible. In addition, giving the users access to FPGA and software while building an ecosystem around the device, is in our opinion the strongest element of Red Pitaya.
To be concrete: There were several suggestions what to add and how to extend the unit once it was revealed (say SFP connector, battery pack, housing, better/stronger FPGA), yet for this first edition we had to keep the “price/performance/broadness of use” criteria in our sight. Not that these would be constrained by the form factor itself. And to be frank – the form factor even changed once during the development cycle by a few millimeters.
3. It seems that when I get to the end of any one of my designs, there are things that I wish that I could have done differently, are there any items like this in the Red Pitaya? If so what were the factors that lead to these issues? An example scenario would be that due to an early configuration decision, adding a specific feature became difficult because it would require a complete rethink of the architecture.
Actually, this is a good question but we think it is too early to give a definitive answer. So far we do not regret our design decisions; it will be feedback from users that may trigger such thoughts in the future and we will be listening. We are actually putting in place a systematic way of collecting user's feedback and then prioritizing design decisions. Economic impact had to be taken into account as well in this case – losing broad range of users susceptible to price boosted up by not-so-frequently required functionalities makes a poor outcome for all the stakeholders. That said, two tradeoffs seem to be resurfacing occasionally: the first one is related to our choice to choose finer granularity of the ADC (14 bit) at the cost of lower sampling rate; the second is simplicity and robustness of the RF front-end instead of choosing a more sophisticated, larger and therefore more expensive design, which at the end would result in a bigger and more expensive device. Time will tell if we were right.
4. How did you decide on the Xilinx Zynq7000 series SoC over other brands? Were there specific things about the product, or was it driven by familiarity with similar products from this vendor. This is something that is an interesting topic as there seems to be a lot more mobility in choosing a vendor for uC’s, I am wondering if this is similar in the FPGA world.
We have been following trends and component development over many years now. So we think we can spot the sudden acceleration or even disruption of the technology relatively quickly. We found that the proposed SoC concept was really very attractive, mainly because "... the processor is not presented as an “FGPA helper”; it’s the main attraction." as it is nicely described in this article (http://edn.com/electronics-blogs/other/4311279/Xilinx-Zynq-EPPs-Leibsons-Law-in-action-) We have experience with FPGAs used for signal processing for more than a decade now, and we spotted that this kind of SoC has the potential for a breakthrough. We actually used Zynq before designing Red Pitaya in one of the devices produced for a particle accelerator. Of course, we did some analysis and comparison of similar devices on the market. At the end, it is not only about the performance – there is also economic impact, switching effort, learning curve, ease of development, support required with a particular device. So yes, not as much as with microcontrollers, but there are many options nowadays also in the FPGA market. At the end, we were very familiar with Xilinx products, though at the same time we consider Xilinx Zynq to be top in the class among SoC including FPGA technology.
5. How does the Red Pitaya benefit from the ARM A9 cores on the Zynq? There has been some previous mention that with the A9 cores this allowed for prototyping of the device, but that this signal processing would move to the FPGA in the final release. With this in mind, how does the final production model benefit from the two A9 cores?
Having both the FPGA and the CPU available on the signal-processing system enables the developer to freely decide which parts of DSP processing to implement on the FPGA and which parts on the CPU. There are slight differences between them in terms of processing suitability, but both can perform digital signal processing. In general, the FPGA handles ultrafast and hard real-time, yet simple DSP operations, but is a bit less suitable for complex procedural operations. The CPU, on the other hand, excels at slower, but arbitrarily complex procedural operations; CPUs are also good at running standard interactive interfaces, such as web servers, for example. Despite the large improvements in FPGA development tools in recent years, it is still generally easier to write procedural software to run on the CPU, compared with RTL coding and synthesis of digital structures in the FPGA.
6. During the Kickstarter campaign, there were two upgrades made as a function of stretch goals, the addition of the RAM from 1-4Gb and the 1Gb Ethernet. How do these functionally make the Red Pitaya a better device, and what if any problems were created by these updates late in the design process? Looking back on it, do you think that this was wise to offer these as stretch goals without having a pushed out timeline, or was the effort worth it despite a push back in the schedule?
With RAM we simply wanted to provide users with more resources and support more complex developments by not constraining future developments. We realized based on feedback after disclosing the initial idea that this is something what they wanted.
On the other hand the 1Gb Ethernet was a more complex decision. First, we wanted to be prompt and follow recent technological trends and standards. To be very direct here, in fact the second upgrade was a threat (a project risk) by itself – not being foreseen and included in the assessment of the work required initially. Still, we recognized that widening the bottleneck of data transfer makes streaming applications, fast data transfer between external system and Red Pitaya possible. If we had not do so, an early obsolescence of the device would be a threat for Red Pitaya. Any design change carries risk. We are sorry for the delay in delivering our device to our Kickstarter backer and we apologize for that, but we believe that those performance improvements of the Red Pitaya justified our decision, but in the end our users will have the final say in this.
7. Based upon the last question, I am familiar with some of the issues with the switch to 1Gb Ethernet, can you elaborate on some of the specifics, and how you found the solution?
In spite of the experience and years of component tracking, and in spite of careful selection of the component set, we simply managed to overlook the non-compatibilities of particular hardware. The problem was isolated to communication between Xlinix Zynq integrated circuit, gigabit PHY integrated circuit and gigabit Ethernet connector. When tracking the solution of the problem we encountered a few hiccups, but managed to first isolate the problem, then brainstorm and list a few alternatives how to solve it, assess the best one, mock-up the solution (did it wrong the first time), test and evaluate the mock-up, and implement it finally in the design. Final testing of the solution was then automated as a routine. We would like to point out that this problem was not the kind of problem when device is not working at all. The problem was related to occasional loss of packets and consequently very occasional problem to the user.
8. What special considerations were given to the ADC and DAC design, and what factors lead to the selection of the parts used?
We knew these parts and we are constantly following developments in this field. The knowledge originated from previous experience, developing instruments for particle accelerators. We estimated that higher resolution and moderate sampling rate would provide solid foundation for variety of applications. With higher solutions also instruments like oscilloscope provide new and different experience to the user. At the same time these ADC are well suited for RF applications. At the end this is a tradeoff.
9. From a general overview, how is the FPGA being used to process the digital data (filtering, decimation, etc)?
Red Pitaya basic applications use FPGA to implement functions that require deterministic processing such as signal acquisition, digital signal processing and signal generation. In order to simplify the development process the FPGA algorithms are implemented as generic building blocks and reused by different applications. For example, the acquisition building block can be programmed from ARM processor in order to acquire a sequence of samples. This building block implements programmable signal filtering and decimation in order to acquire signals at the data rate required by the specific application. The ARM processors can therefore select a suitable FPGA filtering in order to extract the relevant signal information from a noisy signal.
10. What is the value of 14bit sample depth vs the 8 in standard scopes?
Seeing the complete signal without losing view on details – or vice versa – seeing leaves on trees without losing view on the forest. In classical oscilloscope signal analysis, the user selects the voltage range and offset in order to inspect in detail predefined regions of interest. It’s therefore required that the user knows in advance the regions to inspect because the whole picture expressed in terms of 256 voltage levels does not show these details. On the other hand, an instrument with improved dynamic range describes in a single shot all the tiny details of the signal, highlighting to the user all the anomalies.
The Red Pitaya 14 bit dynamic range shows immediately the spikes induced by transmitter switch-mode power supply (SMPS) on a signal. The example is reported on the Red Pitaya Kickstarter page, where a serial communication link signal analysis is presented. The power supply spikes are not visible in the Rigol scope global picture, while Red Pitaya presents such spikes immediately to the user.
The same serial link acquisition example can be also the input of an automated test procedure that verifies at the same time the power supply spikes are within some acceptance levels and the correctness of the serial link information content. This automated testing setup, implemented by Red Pitaya, can check multiple signal parameters in times in the order of milliseconds.
Another application example is the measurement of similar spikes caused by SMPS on mains when analyzing the short range influence to the mains network. This is more or less a similar scenario from the signal analysis point of view, but the purpose of these measurement is different. Here we would also like to point out the possibility for a further dynamic range improvement by means of oversampling. When slower signals are acquired, additional digital filtering can be applied in order to remove the noise outside the signal bandwidth. Therefore the Red Pitaya Signal to Noise Ratio (SNR) in the audio frequency band (approx. 110 dB) is comparable to the commercial 24 bit audio systems.
11. A lot of other scopes with similar claimed bandwidth are running 1Gs/s ADC front ends (Rigol DS1000 series comes to mind), how does the Red Pitaya offer similar bandwidth of these devices with lower sample rate? How would you explain this to a perspective customer that comes up to you with that concern?
Red Pitaya is a creative measurement and control platform. As such we choose to fix the 3 dB bandwidth with respect to the ADC's sampling rate to facilitate variety of potential applications. In theory, The Nyquist criterion states that the sampling rate must be at least twice the maximum frequency that you want to measure. If one is designing a spectrum analyzer a general tendency is to push the 3 dB point closer to the first Nyquist frequency, to extract as much information out of that frequency range. In case of oscilloscope the situation is different. Here designers are concerned with good time domain reproduction of the signal measured, which requires more samples to accurately reconstruct a waveform and the ratio between the sampling rate and the 3 dB bandwidth is 5 or even higher. A third situation is if one wants, for example, to implement the so called equivalent–time sampling (ETS) – often called repetitive sampling. ETS only works if the signal you are measuring is stable and repetitive; it works by building up the waveform from successive acquisitions. In this case, again, it is desirable to have higher bandwidth.
12. Why did you choose to go with SMA connectors?
They are great RF connectors. Yet throughout the development of the unit we were playing with the idea whether we should replace them with bigger, more robust BNCs. We wanted to keep the board small, so size was one of the key design criteria. On the other hand robustness was appealing. Simply to get a figure of merit about the loads that can be withstand here, we mocked-up a test. A picture is worth a thousand words, they say. So, it is 10 kilos on the first picture, 5 kilos on the second and 3 kilos on the last one (note the distance!). No plastic deformation was observed until we increased the load on the last figure to 3.75 kg. Surprised? We were. To be clear – a damaged Red Pitaya board and a damaged probe were used for these tests – so no boards or probes were injured during these tests.