YS1: resource busy, or operation timed out about rfcat HOT 18 OPEN

To solve Error 110 you unplug the YS1 and plug it in again! Or reboot the RPi. I overcame this by using the module uhubctl to power cycle the USB ports every time the script ended, that way I did not have to do it manually. If you program crashes at any point while using the YS1 you'll probably have to unplug and plug to solve this, or run the uhubctl command to power cycle it.

Sergio

from rfcat.

Regarding Error 16... I got it sometimes when I'd be trying to use rfcat at the same time as my research partner so perhaps you are running scripts that try to access it while someone else is using it?

I as well encountered it when running these commands as subscripts or functions.

Sergio

from rfcat.

just updated to latest firmware, and i still get this issue..

from rfcat.

@SorenAndreasen @ssbernabeu has anyone managed to find a fix for this or do we still have to cut power for raspberry pi's?

from rfcat.

from rfcat.

@ssbernabeu damn, that sucks, is this a pi issue or a YS1 issue? Debating wether I should dual boot my laptop for this

from rfcat.

from rfcat.

Have noticed the same behaviour on my raspberry pi running raspian buster and the lastest firmware (606\x00) on the YS1. This seems to be very frequent when running rfcat -s. Has anyone managed to find a fix that does not require to cycle the usb or unplug the YS1? Thanks

from rfcat.

@bking46 Nope, I'm working on it though, raspberry pi zero w, which pi are you using?

from rfcat.

from rfcat.

@bking46 Nope, I'm working on it though, raspberry pi zero w, which pi are you using?

Mine is RPi4.

from rfcat.

we've had issues on Pi's for a long time. i'm unsure of the issues. it's possible it's an RfCat issue, but since the issues only come from the Pi (not more traditional computers), it's difficult to pinpoint.

what kind of power supply are you using? RfCat asks for 500mA, although i'm unclear what the real answer should be.

another things that the Pi might not handle as well as a standard computer: the protocol is very fast and busy, constantly polling the dongle for messages inbound to the host. it's possible increasing the delay between polls might help alleviate this issue. let me know if you're up to a little code-modification and troubleshooting.

from rfcat.

@atlas0fd00m I have been trying to figure it out with no luck, where do you think I should shoot first? I have tried polling delay with no luck

from rfcat.

@atlas0fd00m :
1.power issue: The raspberry pi 4 is powered by a 65W Usb C PD power brick, also the output of the USB port on the Pi can deliver up to 1.2A so I don't think this is a power issue. Also running the HackRF with the current setup runs perfectly with no issues on all ports tested.
2. protocol issues: Is the protocol different to the HackRF for example? Also from what I could observe with the YS1, most of the time this is error is showing up during receive, during transmission I haven't noticed this issue so far. It seems to be very apparent when using rfcat -s using the pyside2 spectrum analyser.

I would be willing to test any suggestions or ideas you might have that would eliminate this issue. I think the YS1 with a raspberry pi would be the ideal setup in my opinion and it's a pitty that we are plagued with this issue. Of course we don't know if this is a rfcat/YS1 issue or a RPI issue but as I said I would be willing to test any experiments in hope that together we might find a solution or a reason why this is happening.

Thanks again for responding on all the messages and for your support!

PS: TX works seamlessly with URH, here's a pic:

we've had issues on Pi's for a long time. i'm unsure of the issues. it's possible it's an RfCat issue, but since the issues only come from the Pi (not more traditional computers), it's difficult to pinpoint.

what kind of power supply are you using? RfCat asks for 500mA, although i'm unclear what the real answer should be.

another things that the Pi might not handle as well as a standard computer: the protocol is very fast and busy, constantly polling the dongle for messages inbound to the host. it's possible increasing the delay between polls might help alleviate this issue. let me know if you're up to a little code-modification and troubleshooting.

from rfcat.

Fwiw, I have exactly the same issue with the NUC. I have to unplug the dongle whenever I restart programs. I assume the Yardstick firmware's USB stack is crashing.

from rfcat.

so, RfCat on the Python side sends a message to the dongle to "shut down" before exiting (ok, it's more like a pause), and then starts it back up when the Python client starts. if that doesn't happen, the dongle will attempt to keep sending data to the Python client and will indeed mess up the USB stack.
might that be what we're seeing here? are you talking about "custom programs", both of you?

i apologize for the long delays in responding.

from rfcat.

Yup, that sounds like what I’m seeing. Is there any way the firmware could be improved to recover from loss of the client? Perhaps an upper bound on how long it will loop or a way for the client to kick the dongle to reset it?

from rfcat.

I had this issue while using rflib directly on a non-Pi device. My issue was I didn't have anything like this atexit in my script:

A simple d.setModeIDLE() after finishing use of the device works as well.

from rfcat.