Raspberry Pi problem?
Re: Raspberry Pi problem?
Have you tried a different USB cable? Or different USB port? Are you using a port sharing hub? If so, connect directly to see if that's the problem.
Best regards,
SDRplay Support
Best regards,
SDRplay Support
Reason: No reason
Re: Raspberry Pi problem?
I noticed that you never terminate correctly. You need to capture ctrl-C for example and perform a StreamUninit();
Failure to do that will give you problems for any subsequent use - you will need to disconnect and reconnect the device if you don't StreamUninit
Best regards,
SDRplay Support
Failure to do that will give you problems for any subsequent use - you will need to disconnect and reconnect the device if you don't StreamUninit
Best regards,
SDRplay Support
Reason: No reason
Re: Raspberry Pi problem?
Anywhere from a few minutes to several hours. The longest I've had to wait was about 10 hours, the average is probably about 3 hours. Sometimes I think it takes longer to go wrong if there's no antenna connected, but I'm not sure about that.How long is a while? Your simple test code has been running on my RPi3 for about 10 minutes without a problem.
g++ -o PiBug PiBug.cpp -lmirsdrapi-rspHow are you building your app? I'm using this simple Makefile...
It's consistently using about 32% on my Pi3. Usually on one core, but occasionally split across two.Press '1' when running top to see the individual core load. On my system your test app takes 50% on one core.
I'm connected directly to a port on the RPi, and not using a hub. I will try using a different cable and port. I /am/ writing data to a USB thumb drive -- I'll stop doing that too and see whether it makes any difference.Have you tried a different USB cable? Or different USB port? Are you using a port sharing hub? If so, connect directly to see if that's the problem.
Thank you... yes, I do need to do that. I was trying to keep the example code as simple as possible, though.I noticed that you never terminate correctly. You need to capture ctrl-C for example and perform a StreamUninit();
Thanks for your help!
Reason: No reason
Re: Raspberry Pi problem?
Try adding -O3 to your build command - the API is build with that level of optimisation. I use that by default in my apps.
Best regards,
SDRplay Support
Best regards,
SDRplay Support
Reason: No reason
Re: Raspberry Pi problem?
I'll try -O3 too...
Progress report: the problem still occurs with no USB stick in use (or plugged in), and with the RSP1 connected to a different USB port. I'm currently testing with a different USB cable.
Other things I can try are using a different physical RPi3, and using an RSP2 instead (I've got one of those too).
Just a quick thought: given that your RPi seems to be busier than mine (you report 50% rather than the 32% I see), are you possibly running a debug/unoptimised version of the API? Might this make a difference?
Cheers,
John
Progress report: the problem still occurs with no USB stick in use (or plugged in), and with the RSP1 connected to a different USB port. I'm currently testing with a different USB cable.
Other things I can try are using a different physical RPi3, and using an RSP2 instead (I've got one of those too).
Just a quick thought: given that your RPi seems to be busier than mine (you report 50% rather than the 32% I see), are you possibly running a debug/unoptimised version of the API? Might this make a difference?
Cheers,
John
Reason: No reason
Re: Raspberry Pi problem?
Nope, I'm using the released API - I'm also using RSP2 as you mentioned RSP2 in an earlier post I thought? I'll try RSP1 but it should be the same.
Best regards,
SDRplay Support
Best regards,
SDRplay Support
Reason: No reason
Re: Raspberry Pi problem?
More experiments...
My RSP2 seems to work just fine with the test program on the RPi3. I ran it for 32 hours without seeing a single problem.
Reverting to the RSP1 (but keeping everything else -- RPi, USB cable, Antenna, test executable -- identical), the problem is still there: after running for a while the API starts writing many tens of thousands of 'Gap=' debug messages (I truncated the log at 100,000 lines to avoid filling the SD card, so I don't know whether it would eventually have stopped).
Just in case, I swapped the RPi3 itself for a spare, and for good measure did a software update (apt-get update; apt-get dist-upgrade). No difference: the problem is still present on the RSP1.
I'm happy to send you the full log files if you like, but this bulletin board won't let me attach them because it says the zip file is too large (it's 1.3 MB).
I'm starting to wonder whether my RSP1 is faulty? I'm struggling to think of other reasons why this problem would reproduce so readily for me, and not for you.
Cheers,
John
My RSP2 seems to work just fine with the test program on the RPi3. I ran it for 32 hours without seeing a single problem.
Reverting to the RSP1 (but keeping everything else -- RPi, USB cable, Antenna, test executable -- identical), the problem is still there: after running for a while the API starts writing many tens of thousands of 'Gap=' debug messages (I truncated the log at 100,000 lines to avoid filling the SD card, so I don't know whether it would eventually have stopped).
Just in case, I swapped the RPi3 itself for a spare, and for good measure did a software update (apt-get update; apt-get dist-upgrade). No difference: the problem is still present on the RSP1.
I'm happy to send you the full log files if you like, but this bulletin board won't let me attach them because it says the zip file is too large (it's 1.3 MB).
I'm starting to wonder whether my RSP1 is faulty? I'm struggling to think of other reasons why this problem would reproduce so readily for me, and not for you.
Cheers,
John
Reason: No reason
Re: Raspberry Pi problem?
John, I'm curious.
Did you solve your problems, or was it really a faulty RSP1?
Greetz Ton
Did you solve your problems, or was it really a faulty RSP1?
Greetz Ton
Last edited by TipTip on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason
Reason: No reason
Greetz
Ton
Ton
Re: Raspberry Pi problem?
I don't know: I eventually found a formula which worked reliably enough.
Rather than using one of the non-zero-IF modes, I use zero-IF with 4xdecimation and tune so the signal I want is off centre to avoid the DC spike. That didn't completely eliminate the problem, but it did then take several days rather than several hours to happen. So I also perform a mir_sdr_StreamUninit()/mir_sdr_StreamInit() sequence every midnight too, and I haven't seen the problem since.
Cheers,
John
Rather than using one of the non-zero-IF modes, I use zero-IF with 4xdecimation and tune so the signal I want is off centre to avoid the DC spike. That didn't completely eliminate the problem, but it did then take several days rather than several hours to happen. So I also perform a mir_sdr_StreamUninit()/mir_sdr_StreamInit() sequence every midnight too, and I haven't seen the problem since.
Cheers,
John
Reason: No reason