SatDump/SatDump

Using satdump_sdr_server and satdump cli

burgeda opened this issue · 13 comments

burgeda commented

I'm running satdump_sdr_server on a raspberry pi out at my dish and I've been running satdump-ui inside on a Dell 7050 micro and that works fine.
I'd like to ditch the gui and run the cli version of satdump but can't find any documentation or examples of how to use a remote satdump_sdr_server at the antenna and satdump on another pc.

There is some mention of running satdump at both ends but I'm not doing that.

Any idea how I can configure the satdump server (decoder) to talk to a remote satdump_sdr_server.

I've seen that satdump (cli) is exchanging messages with satdump_sdr_server but I can't seem to pick a source that is valid.

Thanks

burgeda commented

I still haven't had any success, has NO ONE ever run a satdump_sdr_server on a PI out at the antenna and run the commandline version of satdump on a pc inside?

It's not documented but I'd sure like to get this working.

burgeda commented

@Aang23

Perhaps you can help me, no one has shed any light on my problem so far.

I'm running satdump_sdr_server on a remote pi and trying to connect from the commandline satdump server>

I've run satdump sdr_probe on satdump_sdr_server and get:

[INFO] [UHD] linux; GNU C++ version 12.2.0; Boost_107400; UHD_4.3.0.0+ds1-5
[16:38:21 - 27/04/2024] (I) Found devices (sources) :
[16:38:21 - 27/04/2024] (I) - File Source
[16:38:21 - 27/04/2024] (D) - type : file
[16:38:21 - 27/04/2024] (D) - id : 0
[16:38:21 - 27/04/2024] (I) - Network Source
[16:38:21 - 27/04/2024] (D) - type : net_source
[16:38:21 - 27/04/2024] (D) - id : 0
[16:38:21 - 27/04/2024] (I) - Generic RTL2832U OEM #0
[16:38:21 - 27/04/2024] (D) - type : rtlsdr
[16:38:21 - 27/04/2024] (D) - id : 0
[16:38:21 - 27/04/2024] (I) - RTL-TCP
[16:38:21 - 27/04/2024] (D) - type : rtltcp
[16:38:21 - 27/04/2024] (D) - id : 0
[16:38:21 - 27/04/2024] (I) - SDR++ Server
[16:38:21 - 27/04/2024] (D) - type : sdrpp_server
[16:38:21 - 27/04/2024] (D) - id : 0
[16:38:21 - 27/04/2024] (I) - SpyServer
[16:38:21 - 27/04/2024] (D) - type : spyserver
[16:38:21 - 27/04/2024] (D) - id : 0
[16:38:21 - 27/04/2024] (I) Found devices (sinks) :
[16:38:21 - 27/04/2024] (I) Done! Goodbye

I've run it on the pc running satdump server and gotten:

[16:34:40 - 27/04/2024] (I) Querying SDR Server at 192.168.200.230:5656
[16:34:41 - 27/04/2024] (I) Found devices (sources) :
[16:34:41 - 27/04/2024] (I) - File Source
[16:34:41 - 27/04/2024] (I) - Network Source
[16:34:41 - 27/04/2024] (I) - 192.168.200.230:5656 - Generic RTL2832U OEM #0
[16:34:41 - 27/04/2024] (I) - RTL-TCP
[16:34:41 - 27/04/2024] (I) - SDR++ Server
[16:34:41 - 27/04/2024] (I) - SpyServer
[16:34:41 - 27/04/2024] (I) Found devices (sinks) :
[16:34:41 - 27/04/2024] (I) Done! Goodbye

I've tried running variations of:

satdump live goes_hrit /home/burgedm/Satdump/images --source rtlsdr ip_address 192.168.200.230 port 5656 gain 24 lna_agc true --samplerate 2.4e6 --frequency 1694.1e6 --gain 40 --http_server 0.0.0.0:8080

Substituting every source I could conceive of and all I get is:

...
[16:43:42 - 27/04/2024] (I) Querying SDR Server at 192.168.200.230:5656
[16:43:43 - 27/04/2024] (E) Could not find a handler for source type : rtlsdr!

Always simply says "Could not find a handler for source type : xxxx

How can I connect from a pc running the command line version of satdump to a pi running satdump_sdr_server.

It works fine using satdump-ui so I know that its all actually working.

Thanks.

Aang23 commented

Sorry, somehow totally missed this... :-)

You can use the following, as an example :
./satdump live metop_ahrpt /tmp/test --source remote --source_id THEID --samplerate 25e6 --frequency 100e6

The ID can be obtained from satdump sdr_probe.

burgeda commented
kng commented

I'm running the satdump_sdr_server and satdump-ui, I tested the cli satdump sdr_probe just to see how it looked:

[09:30:18 - 01/05/2024] (I) Querying SDR Server at 192.168.1.126:5656
[INFO] [UHD] linux; GNU C++ version 12.2.0; Boost_107400; UHD_4.3.0.0+ds1-5
[09:30:20 - 01/05/2024] (I) Found devices (sources) :
[09:30:20 - 01/05/2024] (I) - File Source
[09:30:20 - 01/05/2024] (D)     - type : file
[09:30:20 - 01/05/2024] (D)     - id : 0
[09:30:20 - 01/05/2024] (I) - Network Source
[09:30:20 - 01/05/2024] (D)     - type : net_source
[09:30:20 - 01/05/2024] (D)     - id : 0
[09:30:20 - 01/05/2024] (I) - PlutoSDR IP
[09:30:20 - 01/05/2024] (D)     - type : plutosdr
[09:30:20 - 01/05/2024] (D)     - id : 0
[09:30:20 - 01/05/2024] (I) - 192.168.1.126:5656 - HackRF One 14d463dc2f39a6e1
[09:30:20 - 01/05/2024] (D)     - type : remote
[09:30:20 - 01/05/2024] (D)     - id : 792307425
[09:30:20 - 01/05/2024] (I) - 192.168.1.126:5656 - Generic RTL2832U OEM #0
[09:30:20 - 01/05/2024] (D)     - type : remote
[09:30:20 - 01/05/2024] (D)     - id : 0
[09:30:20 - 01/05/2024] (I) - Generic RTL2832U OEM #0
[09:30:20 - 01/05/2024] (D)     - type : rtlsdr
[09:30:20 - 01/05/2024] (D)     - id : 0
[09:30:20 - 01/05/2024] (I) - Generic RTL2832U OEM #1
[09:30:20 - 01/05/2024] (D)     - type : rtlsdr
[09:30:20 - 01/05/2024] (D)     - id : 1
[09:30:20 - 01/05/2024] (I) - RTL-TCP
[09:30:20 - 01/05/2024] (D)     - type : rtltcp
[09:30:20 - 01/05/2024] (D)     - id : 0
[09:30:20 - 01/05/2024] (I) - SDR++ Server
[09:30:20 - 01/05/2024] (D)     - type : sdrpp_server
[09:30:20 - 01/05/2024] (D)     - id : 0
[09:30:20 - 01/05/2024] (I) - SpyServer
[09:30:20 - 01/05/2024] (D)     - type : spyserver
[09:30:20 - 01/05/2024] (D)     - id : 0
[09:30:20 - 01/05/2024] (I) Found devices (sinks) :
[09:30:20 - 01/05/2024] (I) Done! Goodbye

hope it helps.
unfortunately, looks like this rtl-sdr driver uses device id and not the eeprom serial.

burgeda commented
Aang23 commented

I could look into changing the RTL-SDR ID system perhaps.

  • 👍1
burgeda commented
burgeda commented

Looks like there's an issue with git commit 885ac21 "SDR IDs are now strings " and it's causing satdump to fail to start with

terminate called after throwing an instance of 'std::logic_error'
what(): basic_string: construction from null is not valid

I notice it indicates the checks have problems during the automated build process so I'll check back in a day or so looking for a new build to clone.

Aang23 commented

@burgeda this should be working now.

burgeda commented
burgeda commented

@Aang23

Still no joy, still core dumps.

JVital2013 commented

This issue should be fixed up now too, closing with the others