search

jketterl / openwebrx

Open source, multi-user SDR receiver software with a web interface
https://www.openwebrx.de
GNU Affero General Public License v3.0
1.02k stars 146 forks source link

Solution to unreliable SDRPlay startup #316

Closed luarvique closed 2 years ago

luarvique commented 2 years ago

I have seen some discussion of unreliable RSP startup in the Wiki notes on SDRPlay devices. Here is a much simpler explanation of why it sometimes fails to startup, and a fix:

Unlike RTL-SDR devices, which are usually accessed directly, RSP devices rely on the sdrplay.service running and providing device access via SDRPlay API. If this service is not running at the moment of openwebrx.service startup, the RSP device will not open and will appear as "failed" in the OpenWebRX UI. The solution to this problem is to edit openwebrx.service file at

/etc/systemd/system/multi-user.target.wants/openwebrx.service

and add the following line:

[Unit]
...
Requires=sdrplay.service
...

Now things should always startup properly. Please, update the SDRPlay Wiki page with this information.

jketterl commented 2 years ago

The unreliable startup of SDRPlay devices does not only occur during system boot. OpenWebRX shuts down devices when they are not needed, and SDRPlay devices fail quite regularly to start back up, and I'd go as far as asserting that the sdrplay service should be available at this point. For this whole reason, the "keep device running at all times" has been introduced.

Also, introducing a dependency to an optional component is not a solution. This would break the startup to any system that doesn't have SDRPlay software installed. It's therefor not possible to solve this on OpenWebRX' end at this time.

The way I see it, this could either be solved in the SDRPlay API itself by introducing a wait condition for the service to be started up, or maybe by introducing a different systemd construct. I'm thinking of a target dedicated to such services that OpenWebRX would depend on. The difference would be that if the target is empty, the dependency would be automatically immediately fulfilled. This would however require changes on the SDRPlay end as well.

As of right now, the best we can do at this point is to mention this in the wiki.

luarvique commented 2 years ago

Not suggesting any changes to the software at this point, just an update to the Wiki notes.

As to the RSP hardware repeatedly failing to startup, I think it has been tracked down to unreliable power supply elsewhere on the Internet. Essentially, 2A power supply is not enough for Raspberry, Rockchip, and the like. They may take a bit more, causing slight voltage fluctuations, and RSP hates that. 2.4A supply does the job, at least for me.

jketterl commented 2 years ago

There's a lot of issues with reliability of SDR devices on Raspberry Pi, not only with SDRPlay devices. I believe that the power supply on the USB port is pretty unreliable in general, even if you're supplying enough power to the Pi itself. This may be down to the fact that the micro USB input on the Pi probably causes a significant voltage drop at these currents, but I've heard of people who supply power over GPIO and still have the same issues. A powered USB hub can help, but there's no guarantees either.

There's not a lot that can be done about these things on here, though.

The wiki is generally open for edits, so feel free to put this on the SDRPlay page.

luarvique commented 2 years ago

I have been experimenting with powering a Rockchip SBC from different sources lately and the conclusions so far are as follows:

1) Always use 2.4A+ supply. 2) USB chargers generally add 20-30dB of noise to HF bands, making them unusable. At least with RSP and discone antenna that is close to the receiver. All USB chargers. 3) Laptop USBC power supplies work much better, with Lenovo being the best, at 10-15dB of HF noise. 4) A power bank is the best of all, at least some brands (Energizer). 5) No, power filters and ferrite beads do not help against any of the above, but grounding helps. 6) There is USB traffic noise, spaced at 8kHz, especially visible at VHF. Ferrite beads do lower it.

A magnetic loop antenna removed at least 2-3m from the receiver solves a lot of these issues, but I guess everybody knows that already.

jketterl commented 2 years ago

Alright... I think this has digressed far enough from any actionable items, for further conversation we have the mailing list. I'll close this.