Hi there! I'm using a dongle on a raspberry + rtl_tcp and sdrsharp on another machine (quad core.... 3gb ram...good machine!) The problem occour at 00:57 http://www.youtube.com/watch?v=4E2MPfEzEi8 and at 1:34 in this video: http://www.youtube.com/watch?v=8snz1wQSRpw If i stop and start sdrsharp, it works ok for some minutes...then the problem is up again! No errors appear on the console of raspberry/rtl_tcp I'm not able to understand if it's a problem of rtl_tcp,raspberry or whatelse... Things i've tryed: 1) Changed the samplerate 2) Changed the raspberry (tested tp1/tp2 too...getting 4.98v!!!) 3) Changed the dongle 4) Updated sdrsharp The dongles tryed work ok on a pc I've no more idea.... Anyone can help me? PS: If someone know a program that works in linux and is similar to sdrsharp AND CAN INTERFACE TO A REMOTE RTL_TCP...
On 5/12/2013 10:12 AM, Favati wrote:
No errors appear on the console of raspberry/rtl_tcp
I'm not able to understand if it's a problem of rtl_tcp,raspberry or whatelse...
Hi Favati, I knew what your videos would should before even watching them, because I have the exact same problem here when using SDR# to connect via rtl_tcp to a Raspberry Pi. Recent improvements to rtl_tcp have helped a lot with re-starting but this a new problem, as I'm accustomed to running the tcp connection for hours without such failures. I'm fairly certain the problem is on the sending (i.e. R-Pi) end, but haven't got data to prove this theory. However, since you can see in the video that SDR# continues to run, producing both audio and spectrum and waterfall displays, I think this shows that it is processing the IQ data which it is receiving (which is no longer correct). Hopefully a fix will be forthcoming, as this is a pretty big problem for remote users. I'll certainly be happy to provide any data or help with evaluation. 73, Bob W9RAN
Hi Favati,
I knew what your videos would should before even watching them, because I have the exact same problem here when using SDR# to connect via rtl_tcp to a Raspberry Pi.
Recent improvements to rtl_tcp have helped a lot with re-starting but this a new problem, as I'm accustomed to running the tcp connection for hours without such failures. I'm fairly certain the problem is on the sending (i.e. R-Pi) end, but haven't got data to prove this theory. However, since you can see in the video that SDR# continues to run, producing both audio and spectrum and waterfall displays, I think this shows that it is processing the IQ data which it is receiving (which is no longer correct).
Hopefully a fix will be forthcoming, as this is a pretty big problem for remote users. I'll certainly be happy to provide any data or help with evaluation.
73, Bob W9RAN
So...there are 2 possible problem (my english is not good at all!) -the raspberry (maybe something relating to the tcp/ip) or -rtl_tcp bug Or i've not understood you? I'm investigating a lot... I don't think it's a raspberry problem... when the problem occour (only in that moment!!), i can stress the raspberry with file transfer...the files are transfered ok. I think it's a problem of rtl_tcp... What kind of tests do you suggest now? I've never seen that problem elsewhere (can you point me to other having this issue???????).
I can do a lot of testing...just tell me what can i do to help. Sorry but i'm not a programmer :°(
Hi Favati, Are you by chance using a wifi dongle on the Raspberry Pi? I also have this problem, but it seemed to be a lot worse when I was trying to use wifi instead of ethernet. Just a thought... Shaun On May 12, 2013, at 11:12 AM, Favati <smile_k@libero.it> wrote:
Hi there! I'm using a dongle on a raspberry + rtl_tcp and sdrsharp on another machine (quad core.... 3gb ram...good machine!)
The problem occour at 00:57
http://www.youtube.com/watch?v=4E2MPfEzEi8
and at 1:34 in this video:
http://www.youtube.com/watch?v=8snz1wQSRpw
If i stop and start sdrsharp, it works ok for some minutes...then the problem is up again!
No errors appear on the console of raspberry/rtl_tcp
I'm not able to understand if it's a problem of rtl_tcp,raspberry or whatelse...
Things i've tryed:
1) Changed the samplerate 2) Changed the raspberry (tested tp1/tp2 too...getting 4.98v!!!) 3) Changed the dongle 4) Updated sdrsharp
The dongles tryed work ok on a pc
I've no more idea....
Anyone can help me?
PS: If someone know a program that works in linux and is similar to sdrsharp AND CAN INTERFACE TO A REMOTE RTL_TCP...
It SEEMS that lowering the buffer to 16 (option -b 16) solved the problem...(it's up since 30mins atm). I'll let you know...
On Wed, May 15, 2013 at 08:44:15PM +0200, Favati wrote:
Il 13/05/2013 19:07, Favati ha scritto:
It SEEMS that lowering the buffer to 16 (option -b 16) solved the problem...(it's up since 30mins atm).
I'll let you know...
no way...re-happened today...
I've no more ideas :(
Run 'vmstat 1' in a different terminal on the RPi while running stuff, and paste the first dozen lines? (You can just CTRL-C vmstat after this) I ran rtl-tcp a while ago on the RPi and it was really pushing the limits of the IO bandwidth and CPU, but there has been a lot of optimisation in the RPi stack kernels etc since. Using a USB network interface would just push the RPi's limited USB IO even harder. Reducing the samplerate for rtl-tcp might help a bit if you aren't looking at a wideband signal. David
Run 'vmstat 1' in a different terminal on the RPi while running stuff, and paste the first dozen lines? (You can just CTRL-C vmstat after this)
I ran rtl-tcp a while ago on the RPi and it was really pushing the limits of the IO bandwidth and CPU, but there has been a lot of optimisation in the RPi stack kernels etc since. Using a USB network interface would just push the RPi's limited USB IO even harder.
Reducing the samplerate for rtl-tcp might help a bit if you aren't looking at a wideband signal.
David
I've run vmstat 1, but nothing special change when the problem occour. The cpu NEVER goes more than 50%. Lowering the samplerate didn't change anything (except a very little cpu load lowered). Still investigating...if someone have some ideas to let me try.... :)
Run 'vmstat 1' in a different terminal on the RPi while running stuff, and paste the first dozen lines? (You can just CTRL-C vmstat after this)
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 0 124928 16680 61392 0 0 0 0 4120 552 3 40 57 0 0 0 0 124896 16680 61392 0 0 0 0 4315 542 4 41 55 0 1 0 0 124864 16680 61392 0 0 0 0 4220 549 3 40 57 0 0 0 0 124748 16680 61392 0 0 0 0 4079 544 3 39 58 0 The problem occoured at the second line
Favati <smile_k <at> libero.it> writes:
Run 'vmstat 1' in a different terminal on the RPi while running stuff, and paste the first dozen lines? (You can just CTRL-C vmstat after this)
i'm having this same problem. when connected directly to the PC, seems to be fine. when i'm running it on the pi, after a while has the exact same issue. did you find a solution?
participants (6)
-
David Basden -
Favati -
Peter Stuge -
Robert Nickels -
Shaun Hey -
Tim