Is there any plan to update sdr# native plugin v2.2 ?
(if I remember well 2.2 do not include the enhancements -- some or all -- around mirics api 1.8.1).
Reason: No reason
We did look at a release 2.3 a few weeks ago that would have brought the latest API functionality to the native SDR# plugin. However, because of the way SDR# has evolved over the last few months, we conclude that the native plugin code in its current form is unmaintainable and really needs to be re-written from scratch. This is a major undertaking, which will be undertaken at some point, but because of the limitations of what we can do with SDR# and because demand for SDR# amongst our customer base seems to be quite low now, we feel compelled to dedicate our limited development resource to areas that will bring our users the most benefit overall. At some point, it is likely that we will revisit the native plugin for SDR#, but we cannot give you a schedule for when this might happen.
Reason: No reason
I find this statement rather unsettling. Whether or not the demand seems low and why is subject to interpretation and guesswork. Maybe the SDR# users among your customers are just patiently (and silently) waiting, having purchased the RSP in full confidence that this situation will be resolved soon. Or maybe you are seeing a declining demand because an increasing number of SDR# users is not even considering the RSP anymore due to the (seemingly endangered) SDR#1400+ support.Tech_Support wrote: demand for SDR# amongst our customer base seems to be quite low now, we feel compelled to dedicate our limited development resource to areas that will bring our users the most benefit overall
Given that this would be not the first time I see some product never getting some promised support of XYZ, and my impression that SDRplay is much advertising other softwares lately, I"m a bit concerned now and I think you shouldn't underestimate the popularity of SDR#. Please consider that much of your customers come (just like me) from the RTL-SDR crowd, looking for a step-up from their dongles and possibly half of them is appreciating the crowd-sourced additional development of SDR# and the versatility it gives them a lot. After all many, if not most of them are not looking for yet another SDR system for the ham bands with limited software support. They want to scan utility channels, interface with their trunked radio decoders, spot MILSAT communication, or enjoy experiments in the radioastronomy domain, and SDR# is lending itself much to support that all in one software much better than anything else there is. Some just like how GUI and layout are not overwhelming and messy, while not at all lacking any functionality.
I understand that you guys currently got the short end of the stick regarding SDR# and I think I'd be not very inclined to deal with that either if I were in your place, not being responsible for the situation and all, however the cruel reality is that SDR# has gained huge popularity for a good reason, and there's no appropriate replacement on the horizon as far I can see from the hole I live in. It would be a dealbreaker issue for many, without SDR# the RSP is not much more than all the other cute PCBs that have evolved from the traditional ham radio "kits for the kids" scene.
Even if all this not true, wrooooong and rubbish, fact is I bought the RSP1 to use it with SDR#. I do with v1361 and maybe I can manage to reinstate the full functionality I got used to with that and be happy, but this is not really a good option given the fact that one has to source the parts via emails and links to fishy file hosters. On the long term I rely on your efforts to get that going just like any other customer.
BTW, the worst part of the whole situation is not the incompatibility of the ExtIO.dll with SDR#1400+, but the incompatibility with the plug-ins 1400+ supports - plug-ins that were running fine in v1361 have been updated to support 1400+ and the old versions can't be downloaded anymore. Coincidentally, before I saw his thread I posted a comment with a plea on rtl-sdr.com (the SDR# plug-in list) this evening, for making the old plug-in versions available again. Maybe that would also be a way to give you guys and everyone else more time to rectify the situation, now if there would be an agreement with Youssef about an official download site for 1361... umm yeah, I guess I know...
Reason: No reason
I think there may be a little misunderstanding here. The original post related to an update to the plugin to unlock the full feature-set of current SDRplay API, namely I/Q compensation and DC offset correction. Unfortunately, there is NOTHING that we can do to restore the lost functionality associated with various features of SDR# (such as support for some popular plugins) that was lost after release 1400. The reason for this is that SDR# was re-coded to exclude various pieces of hardware, the SDRplay RSP1 being one of them. This was a commercial decision taken by the authors of the software and it is entirely their right to do so and we fully respect that. Please understand that no changes that we can make, either to our API or plugins (ExtIO or otherwise) can restore this functionality as the filters used to lock these features out are embedded within the main body of the code for SDR# and therefore unavailable to us as the program is closed source.
We have tried to make it very clear that there is limited functionality with the RSP and SDR# for release 1400 onwards and indeed if the authors chose to do so, future releases may even prevent the RSP from working with SDR# at all. If that is what happens, I am afraid, with the best will in the world, there is absolutely nothing that we can do about it. At no point have we ever promised that we will be able to fix these restrictions with a future release of our API or plugins. Quite the opposite is true. if you search this or our Facebook forum, you will find that we have made it very clear that there is nothing more that we can do in regard to this matter.
We are very conscious of the fact that this is a significant disappointment to many users who favour SDR# and if there were something that we could do about it, we would. We did reach out to the authors of SDR# to see whether there was some agreement that we could come to with them that would restore these functions for users of the RSP, but they did not respond favourably, presumably because of the commercial conflict of interest that this would present to them. What I would say is that there are a number of alternative SDR packages that are evolving very rapidly and that as time progresses the software choices for the SDR community will get wider and better.
Reason: No reason
Thank you 13dka for expressing what I (and a lot of other radio enthusiast) I'm "patiently and silently" thinking.
Thank you sdrplay team. It is perfectly clear the role of sdr# team and sdrplay team in the "SDR#1361+" affair.
After sdr# turned his back to sdrplay, you never give us any illusion, you behave in a clear and honest way as you use to do.
Nevertheless... a couple of simple things:
1. SDR = SOFTWARE defined radio --> software is IMPORTANT.
2. Today there is no replacement for sdr# (I speak in term of a mix of: usability, functionality, plugin contribution, dsp efficency, ... maturity...)
(btw sdr-console has reached a very good level as dsp processing but is still to complicated, full of unrequired functions, missing required plugins...)
Reason: No reason
Dear Tech_Support, I think I did understand that part but this...Tech_Support wrote:Dear 13dka,
I think there may be a little misunderstanding here. The original post related to an update to the plugin to unlock the full feature-set of current SDRplay API, namely I/Q compensation and DC offset correction.
... is shocking news to me. I obviously misinterpreted what I saw in the various discussions about that elsewhere and thought SDR# just broke compatibility with the old ExtIO plug-in and you providing an interim version that kind of works with SDR# made me think that you are working on restoring full compatibility with SDR#. I'm afraid I'm not the only or the last guy who got that wrong.Tech_Support wrote:Unfortunately, there is NOTHING that we can do to restore the lost functionality associated with various features of SDR# (such as support for some popular plugins) that was lost after release 1400.
That's what I heard and the very reason why I never considered buying an Airspy. But later it looked to me (maybe I just dreamed that) like Youssef changed his mind, your work on a (somewhat) compatible plug-in reinforced that impression.Tech_Support wrote:The reason for this is that SDR# was re-coded to exclude various pieces of hardware, the SDRplay RSP1 being one of them.
Well, I even respect the right of anyone to make a complete <expletive> out of himself. You certainly don't need my assessment on how smart or dumb that move may have been, just so much: Like I mentioned above, it made me not even consider an Airspy for a while, for example because it created distrust, not only because "is their radio so bad that they need to do that?" and so on went through my brain but also because that's a question of conduct and mindset. Then it looked to me as if they just restructured their software to give themselves some head start, with an option for others to catch up later. The latest review on rtl-sdr.com and my experience with the RSP even indicate that the Airspy might be the better choice for my usage profile after all. But...Tech_Support wrote:This was a commercial decision taken by the authors of the software and it is entirely their right to do so and we fully respect that.
... if that's the truth I will not return my RSP1, make due with what I got and hope for the SDR#-plug-in authors to have mercy with us RSP users and start offering old versions of their plug-ins. But then IMHO any attempt on creating some merely basic functionality with SDR# is - more or less - a waste of resources if you can't get the things going that set SDR# apart from the other programs anyway.Tech_Support wrote:Please understand that no changes that we can make, either to our API or plugins (ExtIO or otherwise) can restore this functionality as the filters used to lock these features out are embedded within the main body of the code for SDR# and therefore unavailable to us as the program is closed source.
Tech_Support wrote:We have tried to make it very clear
...forever might the missing bit of information. I understand that this is hard to put in words elegantly and there's always a chance that this could become a "for the time being", but people may read the wrong things between the lines, like I obviously did.Tech_Support wrote:that there is limited functionality with the RSP and SDR# for release 1400 onwards...
I'm so fond of FB that my boss has to do the social networking for me.Tech_Support wrote:if you search this or our Facebook forum
I'm aware of only 2 (as I can't see HDSDR evolving):Tech_Support wrote:What I would say is that there are a number of alternative SDR packages that are evolving very rapidly and that as time progresses the software choices for the SDR community will get wider and better.
CubicSDR - A fetus. Not sure if I'm young enough to witness its maturity. Way too soon to see where it's going, or if it's a boy or a girl.
SDR Console - promising and feature-rich but also big and clunky, just try to get from 80m to 1.5GHz, integration with the RSP is not good yet (I can even make it crash easily), spectrum limited to 2MHz, not customizable for the user, no scripting/API/whatnot to extend its functionality and an overall quite different concept, mostly catering for BC-SWLs and hams. Very different from SDR#, which is customizable and most important, fast and not very cluttered. Sigh.
Anyway, thank you for the clarification.
Reason: No reason