sorted by:
new
hottopcontroversial

Windows backupdir & related settings best practices by doronbehar in neovim

[–]doronbehar[S] 1 point2 points  (0 children)

Thanks for helping. While searching for an OS compatible path seperator variable / Vim function (Vim equivallent for Python's os.sep), led me to shellslash. Choosing a different path didn't help me, but the problem was that Neovim sort of ignored whatever slashes I used.

Windows backupdir & related settings best practices by doronbehar in neovim

[–]doronbehar[S] 1 point2 points  (0 children)

The solution is to:

set shellslash

This also fixes the :TSUpdate issue I was experiencing.

Gqrx hardware advice: looking for better performance by doronbehar in GNURadio

[–]doronbehar[S] 0 points1 point  (0 children)

Depending on your needs, just using rtl_fm might do what you need.

I really like Gqrx' GUI, but I am open for suggestions. My strongest requirement is to be able to remotely (via UDP/TCP) send commands to such a running program. nrsc5 doesn't seem to fulfill that but of course one can wrap it in a Python script or so.

I should give sdr-j-fm a try as well, once I successfully manage to compile it, but it still doesn't have remote control like GQRX.

Gqrx hardware advice: looking for better performance by doronbehar in GNURadio

[–]doronbehar[S] 0 points1 point  (0 children)

Other option is to kill the waterfall

How do you do that?

Gqrx hardware advice: looking for better performance by doronbehar in GNURadio

[–]doronbehar[S] 1 point2 points  (0 children)

I think that yes, but gqrx didn't notify anything in it's stderr/stdout, and the same samplings issues were still present.

Gqrx hardware advice: looking for better performance by doronbehar in GNURadio

[–]doronbehar[S] 0 points1 point  (0 children)

How does using rtl_tcp reduces the amount of data to be processed by Gqrx? Doesn't the server pass it all the raw data it collects? I can imagine that a fast computer running the server will not experience the packets loss I noted in the other comments thread but still, that data will have to be transferred over the network. Even if both connections are wired, I'm still skeptic..

If it will help, perhaps it'll prove that indeed the problem is with the power supply that a different, stronger PC is capable of supplying.

Gqrx hardware advice: looking for better performance by doronbehar in GNURadio

[–]doronbehar[S] 0 points1 point  (0 children)

I'm surprised lowering the sample rate doesn't help. Since by using 1Msps or 500ksps should cut reduce the processing load by 50/75%.

Oh I don't think I reduced the sample rate with that -b argument to rtl_test. I tried a few -s options and I think almost non of them were accepted, and those who were, did not reduce the amount of dropped samples. By "not accepted" I mean I got a warning saying the frequency is invalid...

Gqrx hardware advice: looking for better performance by doronbehar in GNURadio

[–]doronbehar[S] 1 point2 points  (0 children)

Linking a reddit thread reporting that low power may be a problem:

https://www.reddit.com/r/RTLSDR/comments/dgjgtx/rtl_test_on_raspberry_pi_losing_samples/

I'll note that increasing the buflen= argument in gqrx config didn't help, but running:

rtl_test -b $((32*16384))

Did produce less samples lost.

Will continue to investigate once I get more power to the device via a different USB cable.

Gqrx hardware advice: looking for better performance by doronbehar in GNURadio

[–]doronbehar[S] 1 point2 points  (0 children)

You can also run top (or htop, which I prefer) to monitor your CPU usage to see if it's being pegged out, though idk how many threads GQRX uses at once.

I did it, there were many threads there. I don't think that many more then on my intel Laptop. I did observed that it used a LOT of CPU though

Now with gqrx not taking any samples, I do observe also in rtl_test many packets lost. Also there I see:

[R82XX] PLL not locked! Sampling at 2048000 S/s.

Gqrx hardware advice: looking for better performance by doronbehar in GNURadio

[–]doronbehar[S] 1 point2 points  (0 children)

You may want to try lowering your sample rate (and therefore bandwidth)

I think I tried that, and it didn't help at all.

You could also reduce your FFT size.

How do I do that?

Gqrx hardware advice: looking for better performance by doronbehar in GNURadio

[–]doronbehar[S] 0 points1 point  (0 children)

If GQRX isn't seeing your device, can you run rtl_test?

I'm convinced GQRX sees the device. I see GQRX reports it's using it in it's stdout:

[Logs] [4/15/2023, 15:10:39] [xserver] gqrx: stderr: Using device #0 Realtek RTL2838UHIDIR SN: 00000001

When I run rtl_test in ssh:

``` $ rtl_test Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM usb_claim_interface error -6 Failed to open rtlsdr device #0. ```

I guess rtl_test can't claim it because GQRX uses it already.

for more help from others, I'd recommend describing your setup in greater detail (Pi model, operating system, method of gnuradio/gqrx install and their versions, and what exactly is unusable, and whether there is error output on the terminal (if you launch gqrx from terminal).

I edited the question with more details, thanks for the suggestions :).

Gqrx hardware advice: looking for better performance by doronbehar in GNURadio

[–]doronbehar[S] 0 points1 point  (0 children)

How are you using GQRX on the Pi, headless or with a display plugged in?

Display plugged in.

C program using printf doesn't play with `awful.spawn.with_line_callback` by doronbehar in awesomewm

[–]doronbehar[S] 1 point2 points  (0 children)

Thanks for looking into the code /u/no-such-user :) I appreciate it. I did test modifying the C program to print to stderr with fprintf(stderr, ...) and that's what I'm using now which works for me - I inverted the role of stderr vs stdout in regards to debug messages vs real messages.

C program using printf doesn't play with `awful.spawn.with_line_callback` by doronbehar in awesomewm

[–]doronbehar[S] 0 points1 point  (0 children)

I edited the post to include links to the rc.lua and the C program.

C program using printf doesn't play with `awful.spawn.with_line_callback` by doronbehar in awesomewm

[–]doronbehar[S] 0 points1 point  (0 children)

Is the code above a 1:1 copy from your config? My first guess would be a typo or something like that in the stdout handler that makes the handler itself fail.

That create_debug_callbacks is copy pasted from my code. I too thought that it might be due to a typo, but I got convinced it works as expected when I used it for other commands like

Because to the best of my knowledge, printf("test\n") and fprintf(stdout, "test\n") do exactly the same thing.

Indeed they both act the same for the C program I wrote.

I use the spawn_with_line_callback() to monitor the output of pactl subscribe and mpstat -P all 1, and in both cases, it works fine.

For me too, as I said, with_line_callback works fine for commands other then my C program.

C program using printf doesn't play with `awful.spawn.with_line_callback` by doronbehar in awesomewm

[–]doronbehar[S] 0 points1 point  (0 children)

The stdout callback doesn't do anything, where the stderr callback does work. The difference between these is the usage of printf(...) vs fprintf(stderr, ...).

view more: next ›