YS1: resource busy, or operation timed out

[SorenAndreasen]

When calling "sudo rfcat -r" it sometimes works fine, but usually it gives me either "Error claimning usb interface:USBError(16, u'Resource busy')

or (more common) Error in resetup():USBError(110, u'Operation timed out')

I'm on a Raspberry Pi running rasbian this is my firmware:

print d.reprRadioConfig() == Hardware == Dongle: YARDSTICKONE Firmware rev: 0348 Bootloader: CC-Bootloader

== Software == rflib rev: 323

this issue renders the YS1 useless to me as I can't make anything automated. Hoping that someone has an idea what could be wrong.

[SorenAndreasen]

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

[ssbernabeu]

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

[ssbernabeu]

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

[hichiaty]

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

[ssbernabeu]

not to my knowledge; last time I tried fix it was months ago and I got nowhere.

El 5 oct 2020 20:43 +0200, hichiaty notifications@github.com, escribió:

@SorenAndreasenhttps://urldefense.com/v3/__https://github.com/SorenAndreasen__;!!K543PA!cs2BqgBbtfiqEtrhZMx56YIbUdFWPtnZcZgJ8B4e2AhxCtmTAS_Ym5APvYprXvz9EgvSJayDtw$ @ssbernabeuhttps://urldefense.com/v3/__https://github.com/ssbernabeu__;!!K543PA!cs2BqgBbtfiqEtrhZMx56YIbUdFWPtnZcZgJ8B4e2AhxCtmTAS_Ym5APvYprXvz9EguutxiXEQ$ has anyone managed to find a fix for this or do we still have to cut power for raspberry pi's?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/atlas0fd00m/rfcat/issues/52*issuecomment-703817298__;Iw!!K543PA!cs2BqgBbtfiqEtrhZMx56YIbUdFWPtnZcZgJ8B4e2AhxCtmTAS_Ym5APvYprXvz9EgthekutsQ$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AMO73ZPAMYAQZVRD3W5X5BDSJIHVLANCNFSM4H5DF2PA__;!!K543PA!cs2BqgBbtfiqEtrhZMx56YIbUdFWPtnZcZgJ8B4e2AhxCtmTAS_Ym5APvYprXvz9EgvKMmw0MQ$.

[hichiaty]

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

[ssbernabeu]

I think it’s a problem in the YS1; the reboot was a method i used because the port access to the YS1 kept failing after i used it once.

Best, Sergio Bernabeu Peñalba Saint Louis University BS Aerospace Engineering, Class of 2020 El 5 oct 2020 23:57 +0200, hichiaty notifications@github.com, escribió:

@ssbernabeuhttps://urldefense.com/v3/__https://github.com/ssbernabeu__;!!K543PA!aA6A5SOAKaorTGpdSivnffsKwjXa32vh56PJACslNB2-fhHWImwVmmTLtrQ9oJ_SCOO0Mj8Jug$ damn, that sucks, is this a pi issue or a YS1 issue? Debating wether I should dual boot my laptop for this

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/atlas0fd00m/rfcat/issues/52*issuecomment-703911312__;Iw!!K543PA!aA6A5SOAKaorTGpdSivnffsKwjXa32vh56PJACslNB2-fhHWImwVmmTLtrQ9oJ_SCON3gerERw$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AMO73ZIMY2HD5D72HYWUBYTSJI6N5ANCNFSM4H5DF2PA__;!!K543PA!aA6A5SOAKaorTGpdSivnffsKwjXa32vh56PJACslNB2-fhHWImwVmmTLtrQ9oJ_SCOMZlTwcTg$.

[bking46]

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

[hichiaty]

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

[ssbernabeu]

RPi 3b

[bking46]

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

Mine is RPi4.

[atlas0fd00m]

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.

[hichiaty]

@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

[bking46]

@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.

[j9brown]

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.

[atlas0fd00m]

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.

[j9brown]

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?

[AlbinoDrought]

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: https://github.com/atlas0fd00m/rfcat/blob/382f96871234f44b1f4849f8415422525e2d5116/rflib/__init__.py#L212

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