12 May
2013
12 May
'13
5:12 p.m.
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...
12 May
12 May
5:28 p.m.
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
5:41 p.m.
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???????).
8:03 p.m.
I can do a lot of testing...just tell me what can i do to help.
Sorry but i'm not a programmer :°(
8:39 p.m.
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(a)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...
13 May
13 May
7:07 p.m.
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...
16 May
16 May
4:07 a.m.
On Wed, May 15, 2013 at 08:44:15PM +0200, Favati wrote:
Il 13/05/2013 19:07, Favati ha scritto:
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
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 :(
17 May
17 May
5:59 p.m.
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.... :)
6:02 p.m.
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
25 Feb
25 Feb
6:14 a.m.
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?
3714
days inactive
4003
days old
13 comments
6 participants
participants (6)
-
David Basden -
Favati -
Peter Stuge -
Robert Nickels -
Shaun Hey -
Tim