SatDump Auto start. about satdump HOT 14 CLOSED

Not perfect, but the last few days of work have brought something that mostly covers this issue, so I think closing is appropriate. If there's more requests may as well open a new one.

(from CO2ESP's station)

from satdump.

For windows using Orbitron DDE and the plugin Scheduler like what's used in SDR#/ SDR Sharp should work. The Scheduler allows you to control what you need. I think it's best using a scheduler to do all the work. If you can have it all work on all platforms Windows, linux, etc. That would be great. I am hopping I can start compiling and building a Raspberry Pi disk image soon. So other users can try out or use.

Wait, looking at it now it seems like custom commands are an option? Definitely need to look into what Orbitron / SDR# uses. Never used those much.

@Aang23 Take a look at rigctl: https://www.mankier.com/1/rigctl

there are already some server examples setup which can then be connected to gpredict https://www.mankier.com/1/rigctl#Examples

usually, the rigctl server will have localhost: port 5632 as connection then options such as tuning control, recording control, VFO control & a start/stop button.

If I remember, I use rotctl with hamlib to control my rotator. Hamlib is a library collection containing lots of things including rigctl & rotctl, you add this library to your build, then define variables and functions in menu.cpp hamlib: https://sourceforge.net/projects/hamlib/ https://github.com/Hamlib/Hamlib

Here is an example of rigctl (cpp code) used with SDR++ app: https://github.com/AlexandreRouma/SDRPlusPlus/blob/master/misc_modules/rigctl_server/src/main.cpp

Once you have rigctl setup and small menu in satdump, you connect with gpredict and it will control and adjust: Doppler shift TIme start/stop Frequency/satellite

example command line string to control rotctl: rotctld -m 202 -r COM7 -s 9600 -T 127.0.0.1 -t 4533 -C timeout=500 -C retry=0 -vvvvvvvv > pause example of rigctl string: rigctl -m 2 -r localhost:4532 F 7253500 M LSB 0

Thanks for the details, I have already used both rotctld and rigctld... And honestly, the issue really is more about how to make it work with SatDump's way of things than purely interfacing with rigctld or other solutions.

SatDump, in live processing does not work like a classic SDR software doing only recording or tuning a VFO, SatDump has to know what pipeline to start and similar (there is no need for doppler adjustement and that would actually mess things up more than anything else, the PLL in the demod does it well by itself).
Now, how do I differentiate each pipeline? I could do it by frequency, but some different satellites share the same, such as FY-3C / MetOp-A/B/C and Aqua / Aura, so that won't work, I need some way to get at least get a NORAD ID or a custom parameter set on Gpredict's side.

I know rigctld is really designed for handling radios and not really this kind of usecases, so I'll have to see if using another parameter for this will work, otherwise... Maybe I'll be better off making a custom solution. (After all supporting this feature will probably mean introducing another UI and some other parameters so adding in the entire scheduling part wouldn't be that bad, I already have everything SGP4).

(I was also asked about interfacing with UltraTrack, which may required something else too)

Honestly, I'll say that I'm open to any input on this, I haven't started looking that deeply into the issue.

from satdump.

I have actually had a few requests about that recently, so that's definitely a considered / upcoming feature.

The main issue would be selecting the correct pipeline each time purely from the tracking SW. It also means it will need a way to record baseband for later processing, but that's not too bad.

I need to do more research on what DDE will allow doing without more internal stuff in SatDump (such as it's own scheduling / tracking aspect if required). Simply using the frequency will not work as some satellite are using the exact same.

from satdump.

For windows using Orbitron DDE and the plugin Scheduler like what's used in SDR#/ SDR Sharp should work. The Scheduler allows you to control what you need. I think it's best using a scheduler to do all the work. If you can have it all work on all platforms Windows, linux, etc. That would be great. I am hopping I can start compiling and building a Raspberry Pi disk image soon. So other users can try out or use.

Vince.

from satdump.

gpredict integration would be so good :)

from satdump.

@Aang23
Take a look at rigctl:
https://www.mankier.com/1/rigctl

there are already some server examples setup which can then be connected to gpredict
https://www.mankier.com/1/rigctl#Examples

usually, the rigctl server will have localhost: port 5632 as connection
then options such as tuning control, recording control, VFO control & a start/stop button.

If I remember, I use rotctl with hamlib to control my rotator. Hamlib is a library collection containing lots of things including rigctl & rotctl, you add this library to your build, then define variables and functions in menu.cpp
hamlib:
https://sourceforge.net/projects/hamlib/
https://github.com/Hamlib/Hamlib

Here is an example of rigctl (cpp code) used with SDR++ app:
https://github.com/AlexandreRouma/SDRPlusPlus/blob/master/misc_modules/rigctl_server/src/main.cpp

Once you have rigctl setup and small menu in satdump, you connect with gpredict and it will control and adjust:
Doppler shift
TIme start/stop
Frequency/satellite

example command line string to control rotctl:
rotctld -m 202 -r COM7 -s 9600 -T 127.0.0.1 -t 4533 -C timeout=500 -C retry=0 -vvvvvvvv > pause
example of rigctl string:
rigctl -m 2 -r localhost:4532 F 7253500 M LSB 0

from satdump.

Shouldn't this should be pretty easy to implement for geostationary wx? Because it gets transmitted at specific times of the day the program just needs a schedule.

from satdump.

For GEOs, usually I would guess the Ingestor would be used, it's pretty much what it was for.

Another update though : I have started work on some very WIP tracking features... Which will handle this kind of automation as well at some point.

from satdump.

@Aang23 I would also like to see this feature. Is it currently in the works? If not, I could give a shot at developing it.

from satdump.

Well, with the new system this would be a lot easier to implement.
Again, the main issue if that if you wish for "standard" DDE control as seen in SDR#, I will need some kind of specification to implement it. (Unless going custom - but then may not make sense)

Otherwise, I'd guess some ""basic"" scheduling could also do the job for some usecases (or perhaps some basically satellite tracking & autostart feature in the recorder).

from satdump.

Since satdump can already handle recording and processing by itself, wouldn't it be better and simpler to keep everything contained? The user would select a satellite and a pipeline, and that pipeline gets processed during the pass. Would there be a benefit of using DDE with another software?

from satdump.

I'd 100% agree. Such self-contained automated recording / processing (as well as rotator control and more) is something I want to implement at some point - likely when I get a rotator back up.

DDE only makes sense for users that really prefer interaction through another SW / need some sort of remote control.

from satdump.

I've come up with a base for predicting transits in my fork of the repo. I imagine you'll want to implement it yourself because I don't really know what I'm doing in c++, but hopefully you can use it as a reference or something.

from satdump.

Wow Just updated my install to v1.1.0 and the tracking with rotctl. I'm simply lost for words. Nice Job! Looking forward to configuring it with my rotator and sitting back in a chair for a change lol. Thanks.

from satdump.