Red Pitaya - why I ditched it

[JohnnyMalaria]

Hi,

I see comments on STEMlab's Red Pitaya scattered about the web many of which express frustrations in trying to get the RP to do what they want it to in a straightforward way. I thought I'd share my experiences.

These are not for serious applications. I wasted $800+ on two of these things based on the claims that the RP is for engineers to develop new instruments. Well, these claims have proven to be less than convincing. The 'scope and spectrum analyzer apps are terrible. In the latter case, you can't even average the spectrum or zoom in.

I needed three synchronized RF outputs. STEMlab claim RPs can be daisy-chained and synchronized. Yes, they can in principle but not out-the-box. To come even close, I would have had to use a 3rd party SDK, learn Linux, learn Vivado, learn VHDL and learn FPGA design - just to sync a clock. I tried. Requests to add this to the 'ecosystem' have gone unheeded. Apart from one very talented and knowledgeable gentlemen, STEMlab ignore the users' forum. I've wasted more than three months trying to work around this is and this isn't a hobby for me. Delays cost me money. I also need to be able to capture two analog signals (a few kHz). Well, the way capture has been implemented is inexplicable. 16K sample buffer with only about 7 selectable sampling rates ranging from 1.9kHz to 125MHz. There is no means of continuous capture. If I want to capture 60sec of signal I have to capture exact multiples of 8.5sec with gaps between. Now, I were a wizard electronics engineer, I could completely redesign the FPGA to address this but as an out-of-the-box item, it fails to meet its obvious potential. The hardware itself is great - the support and tools needed to make use of it are woefully lacking. In the end, I bought an MCC DAQ for $400 and a 4-channel RF DDS based on the AD9959 chip for $99. So, at least I learned something from my $800+ spend. And I ended up learning Python - which is awesome. BTW - do NOT buy directly from STEMlab - they still owe me for charging me for a unit I didn't buy. Use a distributor such as Mouser. And do your homework (read forums etc.) to make sure this thing will do what you want. It works for some but not for me with my modest requirements.

John.

[marshallh]

Yet another case of "it's the software, stupid". It takes many more manhours to make good well thought out software compared to the hardware that runs it.

[EEVblog]

IIRC I did a video on first use of one and I was not impressed.
Sad to see it has not improved.

[Rushenkick]

It's true that software takes more development time than hardware most of the time, but I've tried Red Pitaya as well and it's been unsatisfactory.

[ebastler]

... claims that the RP is for engineers to develop new instruments. ...

Maybe they were thinking of engineers who have a few man-months to spare to develop their own software... 

[nctnico]

What do you expect? A working data acquisition system with a software ecosystem easely costs north of $10k.

[chris_leyson]

The hardware itself is great - the support and tools needed to make use of it are woefully lacking

couldn't agree more. It's a shame it's so difficult to develop anything useful with the RP. I really liked the concept of using a web browser to connect to an instrument because you don't need to write backend software to support different operating systems. A few years ago I tried to build the first ecosystem release from source and gave up after a few weeks. If I can't even build released source I'm not to stand much of a chance at app development. The initial excitement quickly faded and the RP is going back into it's box for now.

[komet]

Are you selling your old ones? I might be interested in them as a hardware platform.

[xani]

I really liked the concept of using a web browser to connect to an instrument because you don't need to write backend software to support different operating systems.

The problem is that it focused on completely wrong thing. If instead of making shiny web apps it was just a very good DAQ (as in "you can do advanced stuff without writing VHDL/verilog)  which plugs directly to linux kernel as a driver (so you can input/output data easily) it would have much more possibilities.

Instead they seem to want to have "marketplace" (last thing I want on test equipment) and sell you "apps"... ugh

[Howardlong]

Agreed with the general consensus here. The store concept in terms of business model and semi-lockdown is completely misguided. The applications I used were crap, then they kept changing the business model. All chrome and no substance. If you want a mixed signal instrument at the same price point the Analog Discovery beats the pants off it.

If you have a shit load of time to spend learning and implementing systems around its own crap system level documentation and APIs then I can recommend it. They are changing the baseline build all the time, so the documentation is in a permanent state of staleness and confusion, I guess they get new interns in every five minutes who think they can do it better, and redesign and rewrite for no apparent reason.

The hardware is really pretty good, possibly thermals apart. If you have enough time you can make some reasonable firmware, but you need a lot of time and patience against a waterfall of guesswork, shifting sands and crap out of date documentation.

They've gone for the razor blade/printer cartridge model, selling the base hardware for bugger all, but expecting the money to come in from less than half baked applications. I can imagine there are plenty of these sitting in drawers along with assorted revisions of Raspberry Pis.

[JohnnyMalaria]

Probably not right now. I have a couple of stop-gap uses for a least one of them e.g., as a low-frequency waveform generator. That's one feature I do like about the RP (once you have learned Python and SCPI to make it easy to program instead of the web software.)

[JohnnyMalaria]

Well, the thing is that I am developing a lab instrument that in its own way is a data acquisition device with its own ecosystem  - i.e., a turnkey solution for people to just turn on and start measuring.

I only need to the RP to do the most trivial of things:

1. Generate a 40.000000MHz and a 40.001000MHz signal from the same clock in order to drive two acousto-optic modulators. It does this admirably. An off-the-shelf box to do the same thing from a modulator supplier is $2-5K. So, VERDICT FOR RP: PASS (5/5)

2. Generate two lower frequency signals locked to the same clock as above. This requires a second unit with the ability to sync. This capability is claimed by RP but not out-of-the-box or remotely close. VERDICT FOR RP: FAIL (0/5) + hours of frustration.

4. Acquire two low frequency signals locked to the same clock (no problem if done on the same RP) *continuously* at arbitrary sampling rates. VERDICT FOR RP: FAIL (2/5)

STEMlab does also pitch the RP as an educational tool and I give it 5/5 for that but for different reasons:

1. I had very little/no knowledge of FPGAs, Vivado, Linux, SSH etc etc.

2. I was aware of DDS but thought it was far too expensive an option for me. This is where the RP has taught me otherwise. Actually, it is thanks to a company called Koheron that described a means to sync RPs but that mountain was just far too high to climb.

3. I had no experience with Python. Now I am writing all my code in Python mainly because of its stupendously fast data processing using Numpy, easy graphing and rapid development. I wish I had discovered this years ago.

So, now I have an AD9959-based 4-channel DDS board that will replace my two unsync'd RPs for signal generation - $99. For acquisition, I have an MCC USB-1608FS-Plus ($420) that has full Python support and can, out-of-the-box, perform continuous and simultaneous capture of up to 8 channels in the background. I had this functioning within a day of receiving the device. And because I do like to be able to control the hardware without being there physically, I have a USB-Over-IP adapter (the DDS and DAQ are USB). The RP's socket-based SCPI server for Python is a powerful feature that I have used heavily.

[NorthGuy]

Technically, all you need a small FPGA ($50 or so), 4-channel DAC or DDS, 2-channel ADC, Ethernet PHY and few little things such as power, flash, memory etc.. If your goal is to build some quantity of the devices (e.g. 100+), you may consider putting these on a single custom board.

[Howardlong]

Technically, all you need a small FPGA ($50 or so), 4-channel DAC or DDS, 2-channel ADC, Ethernet PHY and few little things such as power, flash, memory etc.. If your goal is to build some quantity of the devices (e.g. 100+), you may consider putting these on a single custom board.

To be fair, while the hardware cost may be cheap, the learning curve for that little lot most certainly is not, even for 100 units.

[NorthGuy]

To be fair, while the hardware cost may be cheap, the learning curve for that little lot most certainly is not, even for 100 units.

This is obviously true, but learning is a good thing. People pay top dollar for learning in Universities. Here, you not only learn for free, but you also save $40K (assuming you need 100 units).

[nctnico]

To be fair, while the hardware cost may be cheap, the learning curve for that little lot most certainly is not, even for 100 units.

This is obviously true, but learning is a good thing. People pay top dollar for learning in Universities. Here, you not only learn for free, but you also save $40K (assuming you need 100 units).

Besides that there is no reason not to hire an engineer who already designed something similar. Gobbling boards together doesn't create a stable product.

[JohnnyMalaria]

I wholeheartedly agree. Right now I am at something of a proof-of-concept stage and cobbling is an important part. There are many subsystems in my instrument (optical, mechanical, electronic, software) each of which can be realized in a multitude of ways. I'm trying inexpensive options to replicate what are otherwise prohibitive ones. RP was such a case and it proved inadequate. C'est la vie. Once I lock in on the preferred ways to meet the requirements of each subsystem I will certainly use an experienced engineer. I can already see how pretty much everything on the electronics side could include an FPGA and end up with a postcard sized board compared to 2 square feet of bench space and spaghetti I currently have.