SDRplay RSP1 Price Reduced to $99.95 USD
SDRPlay have just announced that their RSP1 unit has just been reduced in price to $99.95 USD. Their press release reads:
SDRplay are pleased to announce a price reduction for their entry-level SDR receiver, the RSP1 to $99.95 USD making it the most competitive mid-range SDR to include reception down to low frequencies without the need for an upconverter. The RSP1 provides general coverage receiver and panadapter capability from 10 kHz to 2 GHz. As well as providing SDRuno SDR software, support for popular 3rd party packages like HDSDR, SDR-Console and Cubic SDR is provided. Recent availability of an SD Card image makes for easy set up on a Raspberry Pi.
Over time we’ve seen the RSP1 reduce in price originally from $299 USD, to half price at $149 USD in March 2015 and then to $129 USD in September 2016, and now finally down to $99 USD. The newer RSP2 remains at a price of $169.95 USD.
Back to Ground Zero: you can buy an RSP1 for 100 dollars. Money well spent.
An RSP2 is even better. Yepp, I use and test both for the last 8 months, side-by side.
But that’s a different story.
I want to raise your attention to the customer approach of the two companies:
– AirSpy states “please contact your distributor or use the community forum”: http://airspy.com/contact/
– SDRPlay has a different approach: http://www.sdrplay.com/contact/. Telephone number at the end means I had the pleasure of talking to Jon in no time talking antennas and receivers and software. Grapewine friends had a similar experience, support for SDRPlay products are fantastic. Hands up, anyone, like a regular customer spending 200 dollars or so at the time who has ever managed to talk to the boss. Take it further: write in if you managed to talk to Joussef in person.
Support, dedication to end-users, and accessibility (Jon replied here, and constantly in there for the community, I’ve never read a word from AirSpy boss, afraid or what? Or doesn’t care?) Makes SDRPlay the No 1 choice for me.
Let’s not go into the SDRUno voice quality versus SDR# debate, personal circumstances and hearing are debatable, care from a company you’ve given your hard-earned money is black-and-white.
Both RSP1 and RSP2 need a LOT of support and hacking to get you started, indeed. The gains settings are awkward and never work as expected and the radio overload with a piece of wire. Things get even worse if you want to use the RSP2 with Linux. The driver is so flimsy and crashes on the CubicSDR application recommended in their FB group. I discovered later that this driver is not even present in any major Linux distro! The dependencies will make you look for another hobby out of desperation.
When I contacted the SDR Play support on FB I was told to use an attenuator in order to avoid overloading the RSP2. Why the heck would any one kill the performance of the receive system by using an attenuator? When I insisted on my request and asked for refund, I was banned from their FB group!
Sure, when you have a half-assed product and software, you absolutely need to invest in spoon-feeding support to calm the unsuspecting new joiners. What makes me laugh is that SDR Play advertise videos of the RSP with severe overloading!
http://www.sdrplay.com/yaesu-demonstrating-sdrplay-panadapter-at-lamfest-barnsley-and-ham-radio-friedricshafen/
Why don’t we ever hear about Perseus, RFSPACE, Elad or even Airspy support problems? Their shit just works! Some people got the Plug And Play concept better than others.
I am 65 years old now and spent most of my life working in industrial electrical design and despite my experience in problem solving I had hard time getting anything to work from this company. All I got is bla bla. I pity our people who are not computer savvy and who get their first SDR experience on an RSP. Most of people I work in the local 2m repeater have a very bad opinion of SDR because they picked the wrong platform in the beginning and never went back again.
Tech Guy,
I firmly belive that the SDRPlay series are for the masses, who use Windows with SDRUno software. Fulfilling the requirements of everyone is simply not possible – only a small minority of users use Linux or Cubic SDR. A toddler can receive signals with any RSP and SDRuno with step-by-step installation.
Furthermore, I’m more and more in the mindset that the RSP2, and even the RSP1, is an onion: you need to dwelve into depths of your radio knowledge to discover layers of performance. RSP1, and especially the RSP2, do not tolerate user error, be it software settings, antenna, or user input. Remember, SDRPlay series are made by radio engineers, who, I think, went balls-out for receive performance. Anyone can drive a Toyota to the nearest shop, and a Ferrari will cover the same distance, then, when push comes to shove, it’s all up to the driver to shave seconds off the time.
“RSP1, and especially the RSP2, do not tolerate user error”
That’s exactly how we define a bad design in the industry, and also the reason why high grade engineers are paid good bucks to design robust systems. These products definitely suffer from childhood diseases and have a long way ahead before reaching acceptable performance for the function they were purposely built for. No amount of user support is going to compensate that.
Let’s talk shop. How do you objectively measure a good design versus a bad design? Or robustness? Or acceptable performance?
What specific requirements and standards has the RSP signed up to that are not being met? For robustness, what is the RSP predicted/actual failure rate and under what environmental conditions? What are the environmental requirements and corresponding test methodologies?
Look, it’s an inexpensive SDR that requires a bit of playing around with to optimize its performance. I’m having a ton of fun with mine and learning quite a bit. If it helps, think of the RSP, Airspy, and RTL-SDR lines as prototypes or proofs of concept.
“What specific requirements and standards has the RSP signed up to that are not being met?”
Interesting point. But there is no need to speculate and invent a new pseudo-science to induce yourself and other people reading your blog into what YOU may think is a good performing radio. Guys like SM5BSZ objectified all these notions with actual measurements under controlled and reproducible conditions with a flawless academic “modus operandi”. Set all the radios to the same noise figure and measure the 1dB compression point at different separations. This is called science.
In contrast, despite ELAD, Perseus, RFSPACE, RTL dongles, Funcube and AirSpy all ranked better than RSP in these tests, people still try to introduce their feeling or “field expertise” into the affair to skew the interpretation. Kind of modern incarnation of snake oil miracles or audiophile sorcery. If science says A > B, not taking A is suboptimal, especially if A costs less than B.
Of course we don’t know the answers to those questions apart from what we can gather from the RSP datasheets. The point of the questions was to identify which “early childhood diseases” that the RSP is suffering from and what constitutes “acceptable performance for the function they were purposely built for”.
Apart from that, these are the types of questions that real systems, development, and product engineers ask, think about, and respond to during requirements generation, development, and testing phases of a product. “New pseudo-science”? That’s too funny. I’m sure getting paid a lot to do it if that’s what it is.
Yes, SM5BSZs videos do show the expected level of engineering discipline that would lead to reproducibility of the results . Let’s take your example. I assume you meant setting up all the radios to a signal at the same power level and SNR rather than noise figure. Noise figure is a measurement of how much the radio (RF front end in traditional radios) degrades the SNR and is an inherent characteristic of the device.
For more traditional radios, you would use calibrated signal and noise generators, variable attenuators,spectrum analyzers and measure the 1 db compression at a test point within the radio.
For the SDR under test, what measurement software are you going to use to measure the 1 dB compression point? Are the correct SDR drivers being used? Is there filtering activated within the SDR drivers that could skew the results? Has the measurement software been properly validated and calibrated (if needed)? This last one is certainly one of the most If not most important question to answer. If the measurement software has not been properly validated then the results and any comparisons will be suspect. You certainly might be able to make some useful characterization statements.though.
My advice is that if you want a better SDR, define your real requirements and be prepared to spend the money.
.
“For the SDR under test, what measurement software are you going to use to measure the 1 dB compression point? Are the correct SDR drivers being used? Is there filtering activated within the SDR drivers that could skew the results?”
Thanks for proving my previous point 🙂
“people still try to introduce their feeling or “field expertise” into the affair to skew the interpretation.”
So, can someone explain what this means for those of us owning RSP1s?
RSP is useless without good software and $99 won’t turn it magically into a good radio. Shame.
I think the SDRuno app is fine for the rsp, and quite lovely at that, but sdr console v3 has even lower cpu usage than sdruno and works well too. I’ve used hdsdr and sdr# with the rsp and not had an issue. There’s plenty of great software for the rsp series.
Would you mind posting the links to the Radio Reference and QRZ threads? I couldn’t find either.
Capitalism is SOOO evil. Folks should produce things and just give them away for free.
Signed
Bernie
What exactly do you think you are contributing to this conversation? There are plenty of websites where you can entertain political head bashing. Please go find one.
The rumors is that SDR Play refused to pay SDR# devs for support and they went developing their own “unblessed” plugin for SDR#. This made the original SDR# developers so angry that they changed all the code which broke the compatibility. There was a lot of drama in Radio Reference forum about that, and even bullying by SDR Play employees who publicly threatened to contact their friends in China to sabotage the AirSpy production.
This triggered a complete change in the way SDR# is delivered to the rest of us with even more restrictions than before. But in a way, this competition pushed the development of new plugins and functionality that is primarily targeted towards AirSpy and the RTL dongles to some extent. Many RSP owners were left in the cold, including myself. Then SDR Play managed to license Studio1, which has nice graphics but still basic functionality and no plugins. The price drop some how reflects, again, that SDR is all about the software.
Other people in QRZ forums speculate that SDR Play are now positioning themselves in the mid/low-end segment in preparation for the upcoming AirSpy HF+ which is a 18bit radio that pretends to bring Perseus-like performance into the sub $200 range.
Bernie – I am interested in moving from the RTL-SDR 1.3 to an RSP2. Do you recommend not buying an RSP2 at this time until (if ever) this is worked out? SDR# is my program of choice.
It won’t work. SDR# is now owned by Airspy company and all the great features work only with their SDR.
Even SDR-Console now has minimal support for RSP2, and not quite as good as Airspy R2 support.
SDR Console provides excellent functional support for the RSP2. We appreciate Simon Brown’s work ensuring that both production Version 2.3 and Preview Version 3 work very well for both the RSP1 and the RSP2
Indeedy-do 🙂
This is Jon Hudson, co-founder and Marketing Director of SDRplay Ltd. We have tried to avoid making public statements about the decision of the authors of SDR# to restrict support for some third party hardware platforms (including our own) other than to acknowledge the rights of the owners of the SDR# IP to use it how they see fit and support whatever platforms they wish. The exception to this stance is where we feel obliged to respond to statements that are either factually incorrect or misleading. Despite the careful use of the word “rumors”, we feel that the above statements from Bernie give a completely misleading impression of the events that lead to support for the RSP1 being dropped by SDR#.
Our stance as a company has always been to support as many different software platforms as possible to give our community of users the widest possible choice. We developed a plugin that provided support for the RSP via the ExtIO interface for all software that supported this interface, including HDSDR and SDR# amongst others. After release 1361, SDR# dropped support for the ExtIO interface meaning that the only way to interface to SDR# was via the native radio API. At no point was it suggested that we were doing anything wrong by taking this approach. Indeed, when challenged about the dropping of support for the ExtIO interface, one of the SDR# authors publicly stated that if we (SDRplay) knew what we were doing, we could easily develop our own plugin that conformed the necessary interface.
We therefore developed a new plugin that worked with the native radio API and no sooner had we released it, SDR# was amended to change the API and this meant that the new plugin would no longer work. Some of our customers reached out to the authors of the software to try to persuade them to include support for the RSP. They were told that the changes were NOT designed to break support for the RSP, but were being done for other technical reasons. Things certainly became heated and ‘words were exchanged’ between some of our customers and the SDR# authors, but at no point during this process did ANY employees of SDRplay threaten Airpsy or their business in any way, nor did we encourage anyone to do so. In fact we took quite the opposite stance and tried our best to calm things down, publicly stating that the authors of the software can do as they see fit and we completely support their right to do so. One of our customers who reached out to the SDR# team has subsequently become an employee of SDRplay, but not until more than 20 months after these events had passed. At the time none of these people had any affiliation with the company whatsoever and were certainly not acting on our behalf or under our instruction in any way.
Finally after a few iterations over the space of a couple of weeks, the radio interface API settled down to a ‘two tier’ interface with some hardware having full support and others (including our own) having restricted functionality. At this point, we reached out directly to the SDR# team ourselves to see whether we could strike some kind of business arrangement to enable full support for the RSP to be re-established. I want to make it absolutely clear that at no point did we refuse “to pay SDR# devs for support”. In fact, we asked what it might take to get the support re-instated and at no point did we ever receive any kind of proposal for how we might achieve this. We were open to discuss any option, including paying the authors of SDR# to include support, but it eventually became clear that they had absolutely no intention of allowing the restoration of full functionality for the RSP1. We can’t be completely certain as to why they took this stance, but given that they sell competing hardware, normal competitive commercial reasons would seem a reasonable explanation, and we take no issue with that. At this point, we publicly stated that as we could no longer guarantee support, we would cease any future developments to provide support for SDR#. The plugin that we had released continued to provide limited functionality with SDR# until release 1500, after which another change to the interface meant that it would no longer work at all.
As far as we are aware, the matter is now closed. We would have liked to see the RSP supported by SDR#, but without the willing cooperation of the authors it is simply not possible. We fully understand and accept why this is not something that they wish to countenance and we hope that other will respect their decision also and not resort of any more inflammatory comments. I also hope this explanation corrects any misunderstandings that Bernie and anyone else may have over this matter.
Jon,
I commend your accurate recount of events. Unfortunately, one of your (now) employees subjected me, one of the SDR# devs to threats and personal harrasment while on a family vacation and simply trying to help the situation. This was ultimately the driving force behind Youssef’s apparent lack of interest to cooperate further.
I’m happy to discuss if you wish to contact me.
Regards,
Ian
Jon – as the thread comment starter @ 3:05 AM today – I appreciate your lengthy explanation. As a newbie in the SDR world, I was unaware of the background but curious as to why the SDR# support of the RSP products ended.
If you need a tester for the Airspy HF+, count me in 🙂
Why does SDR# support for the RSP stop at version 1500?
money horny assholes only wanting to sell their own shit and making it harder for “normal” people to use devices they spent their hard earned money on, what else?
My guess would be that SDRplay no longer want to provide a basic driver to the SDR# software, provided by a competitor, that needs to be downloaded from the competitor website, and prominently display the competitors logo (with a link to the competitor website). From a purely business point of view, it probably is a bad idea to provide a driver.
To be fully fair, it is no more odd than SDRuno not supporting any hardware with sample rates higher than 1mhz. Which locked out all the Airspy hardware, and cripples comparison with all other competitors hardware. It will be interesting to see if that restriction has an addition made to it (like the sample rate must be more than 800kHz), after the Airspy HF+ is available.
Would you shy away from the RSP2 because of this?
I have no idea what part of the RF spectrum rings your bells. It is a bit like asking strangers if you should buy a strawberry milkshake or a cup of coffee. You need to Write a Pros-and-Cons List for YOU, and make your own decision. Should it be RX only or TX+RX, where do you spend most of your time in the RF spectrum, now, and where would you like to spent time in the future. If you have an RTL-SDR 1.3, maybe get a better antenna, lna at the antenna, and some bandpass filters for parts of the spectrum that interest you or bandstop to attenuate parts that are overloading the 8-bits of your dynamic range. If you decide to upgrade now or later, those bits and pieces will still be useful. Maybe learn more about RF first by joining a local club and studying for an amateur radio license.
SDRuno (EXTIO) 1.04 supports up to 2.5MHz sample rate and works with the Airspy product.
Wow, Impressive.
Just read the release notes and it was added in 1.05, unless I’m reading them wrong. To be fully honest I gave up on the software once I saw that I was restricted to less than 1MHz, and never looked at it again. 3MHz would be better, but not from a commercial standpoint 🙂
Hi Jon Hudson,
I think sdrplay team should focus on their receiver application first and then SDR hardware both. At present this application is now seems some cryptic nature but output sound is good in comparisons to sdr# application. At present sdruno is not capable to save recever working environment after closing recever application. There is no way for developer to add more functiinality with already recever application. However, Sdrplay is all in one good receiver.
I think if price of hardware go down then their may be possibility that open source software coommunity around the world may create a newly receiver application which is dedicated to sdrplay on different operating system otherwise it hard to beat Sdr# and airspy family product. Software is key of success of many hardware company all the time such as android is become a defacto operating system of today smartphone. Open source community already write rtl2832u driver for sdr purposes. Many people argue that silicon switches used in sdrplay which create noise and spur in RF environment and not provide professional solution.
IMHO, SDR# has the best DSP processing of all the existing applications today, but it looks like it only works at full capacity with AirSpy – which makes sense commercially. The decimation and noise reduction are fantastic!
Sdr# is a good receiver application dedicated to airspy family product and author update their application according to their products on regular interval. It’s pity, they change a two line of code in there application and change application version time to time, why? Why they do not consolidate all their update in one update in a year. They also not keep earlier versions of their application in archive form. Never ask suggestions from other peoples in this fields to improve receiver application.
Writings software with a team and take feedback makes it more usable and versatile.
How can this be a bad thing? We have access to the latest innovations as they are available, and no one is forced to upgrade. You are complaining because someone fixes and updates the software faster than you can find bugs? C’mon!
I remember a few years back when the project started SDR# had many updates per day. It was always funny to see what bugs would be fixed or features would be added next and no one could pretend to have the latest version. This resulted in a very fast growing of SDR# as a platform, and this is probably why it is so popular today. The real side effect is that this also attracted may sharks roaming around the project and some of them ruined the learning opportunity for the rest of us when the project went closed source to protect itself – and SDR Play are not helping.
When you see it, very few companies can afford this level of productivity sustained for years without draining their entire R&D budget and go out of business. We are in face of something really exceptional here.
Software is like a bullet and hardware like a gun without bullet gun is useless.
And a bullet without a gun is even more useless. Software without hardware to run it on is nothing more than an intellectual curiosity.