It is unclear whether the server component will be separate from the main software program, but regardless, I welcome the upcoming changes. Using a wholly rewritten server platform can only be a positive step. The existing software has a steep learning curve for those who aren’t technologically minded and can feel clunky to set up. The upcoming server platform is an excellent addition that will hopefully break through the barriers users have been experiencing while attempting to set up the problematic RSP TCP Server. The ideology behind RSP server software is that one can access their device’s data stream anywhere globally. SDRplay has also done extensive work on the server component of their software, which is compatible across multiple operating systems. For many, SDRconnect will surely be a welcomed change, bringing many benefits. The company has listened to customer feedback since its initial SDRuno software release, proving its excellent reputation for arguably the best value software-defined radio receivers on the market. SDRconnect’s user interface has been built from the ground up to be intuitive and easy to follow, retaining the tactile style of SDRuno while offering a similar feature set. The final release will be compatible with Windows, macOS, Linux, and Android. A software prototype has undergone a demonstration using an Apple M1 Mac at Hamvention in Dayton, Ohio (One can view the demo here). Reply to this email directly, view it on GitHub, or unsubscribe.SDRconnect has been designed from the ground up, starting with the powerful Core DSP engine for Spectrum and Waterfall displays. You are receiving this because you are subscribed to this thread. And the software stoping to receive signals shoult just not happen. Even having a workaround for this would be fine. However, I highly dislike having to restart my system to fix things. I can live with having to kill the sdrplay_apiService process once in a while. I discovered this while trying to record some POCSAC messages over night. SDR++ disengages and there is no error explaining why. Listening to the radio waves for an extended time, things just stops. There is no sdrplay_apiService process running and disconnecting and reconnecting the SDRPlay hardware does also not change anything. The only way to recover from this, is to reboot the system. In that case the log shows Could not init RSP device: sdrplay_api_Fail. Sometimes that does not work and SDRPlay does not even show up as a source. This usually can be fixed by sending SIG TERM to the sdrplay_apiService process. When that happens, I can select the SDRPlay as a source but the device shows as unavailable (red text in SDR++). When starting SDR++, its console output shows Could not intiatialized the SDRplay API. I have several observations that might or might not be related. Using SDR++ on macOS 11.5.2 with an SDRPlay 1A.
0 kommentar(er)
