I have got satnogsclient up and running on my RPi. It is recognized by the software on network-dev.
My radio is an Icom 821H and I know the arguments to use in an invocation of rigctld:
rigctld -m334 -r /dev/ttyUSB0 -s 19200 -c 0x60
My question is simply this: Where do I put these arguments so that satnogsclient will use them when it starts rigctld. (rigctld is started but only with the (default) argument -t 4532).
HI @oz6bl – three of those arguments have equivalent settings in the satnogs-client code:
- RIG_MODEL for the “-m” argument
- RIG_FILE for the “-r” argument
- RIG_SERIAL_SPEED for the “-s” argument
However, if I’m understanding things right, these settings don’t work the same as the other
settings – that is, they’re not settable in the same way other settings are (tech detail: they’re not taken from environment variables the way, say, RIG_IP is). And of course, there isn’t support for the “-c” argument.
It would be good to get someone from the SatNOGS team to confirm all that. Assuming I’ve understood it all correctly, this should be a simple bug to fix: add support for setting the variables, add in the “-c” argument, and allow them all to be set by the satnogs-client-ansible script (which, if you’re using the [Raspbian image (https://wiki.satnogs.org/Raspberry_Pi_3#Raspbian), is how they’ll get set on your Raspberry Pi). I’ll file a bug and see if I can get a PR in to fix this.
Hi @saintaardvark. I tried to insert one of the arguments (the RIG_MODEL) directly into settings.py, but all I got out of it was this very informative message:
rig_open: error = IO error
(irony may occur) and rigctld was not started.
I subsequently tried to insert some log messages into tasks.py to see what arguments were actually used in the rigctld call, but they appear to have vanished into thin air. The same happened when I brutally changed the logger call to a print statement.
I have tried to understand the way satnogsclient uses the logging module but so far with meager results. Hopefully somebody (you?) could give me some pointers to better understanding.
Oh, it’s been a while since I dug into logging…but checking through my notes:
this issue suggests setting loglevel to “satnogsclient” – which I think is what’s being done here and here
- Not sure how you’re checking logs, but you may want to check /var/log/syslog* and also the web interface (port 5000 on the IP of your Raspberry Pi)
- A while back I was working on another part of the client that launched a program, and I think I remember seeing I/O error; IIRC, the sequence was:
- client starts up the outside program
- outside program runs long enough to check its args, say “That’s wrong!” and promptly exits
- client doesn’t notice
- then when the client tries to write to the filehandle for the outside program’s STDIN, the write fails and the I/O error is logged
You may want to check for the same thing.
You should be able to go to Advanced options in the satnogs menu and scroll down to HAMLIB_UTILS_RIG_OPTS
If you run:
rigctld -m334 -r /dev/ttyUSB0 -s 19200 -c 0x60 -vvvv
in your commandline you should get verbose logging which may tell you whats going wrong.
@m6lzt – thanks, I hadn’t noticed that! I was looking through the satnogs-client code to see how it built up the arguments for rigctl – not rigctld. HAMLIB_UTILS_RIG_OPTS is used to build the file
/etc/default/hamlib-utils, which in turn is used as settings for rigctld…so I got that wrong (doh). @oz6bl, apologies for the mixup!
@saintaardvark @m6lzt Thanks to both of you for the help. I have learned a lot! I now have rigctld running with the correct arguments.
The next step is to see my radio track a pass of some satellite.
One hour later: It does indeed track, so everything is good,
Brilliant, glad to hear its working!