Hello again,
?
So following:
?
"rigctld -m 3068 -v -r /dev/ttyUSB0 -s 19200 -c 0x7c
in one shell window, and
rigctl -m 2"
?
and then trying a f command, yields the same sad communication timed out message.
I first tried the above commands with sudo, which yielded the same results as non sudo.
?
Then I tried the:
"rigctld -m 3068 -v -r /dev/ttyUSB0 -s 19200 -t 4534 -c 0x7c
rigctl -m 2 -r localhost:4534"
?
which also had the same results
?
I then did the:
?
"sudo netstat -tulpn | grep 4532"
and
"sudo netstat -n |grep 4532"
both of the above commands I did in a separate window while the rigctld and rigctl were still running- but then I also redid them after shutting all of the windows down with ctrl C and then opening a fresh terminal.
?
both commands didn't seem to do anything- they executed with no error, but no output. they just went to a new line for a new prompt.
?
" ps -axww | grep USB and ?ps -axww | grep serial"
both showed no processes, other than the grep search itself.
?
I did do a wiggle test on the cable that we have, and didn't notice anything weird, but we have a million of these cables in the lab so I switched it out for a different one with no difference in dmesg or in the rig command response.
?
So. I think I'm at the point where I need to do a rig reset, we don't have anything saved on there that can't be plugged back in. I am making a list before I reset it though to make sure I get all of the settings on there that I need to in order to run rigctld as well as direwolf...
?
What I have is:
FM/D
55. off
56. 50%
59. USB
60. 19200
61. 7ch
62. off
63. --/GPS
64. --/GPS
?
I am really starting to understand why the previous coms team thought the rigblaster was a magic wand. I am happy that you all are here though, I feel like doing this the right way will limit our headaches in the future.
?
-Cass
?
|
|
|
Hi Cassie
A swag of notes/ideas.
Yes I agree something has gone wrong. Note there is a difference
between rigctld and rigctl. For testing you would start;
rigctld -m 3068 -v -r /dev/icom9100a -s 19200 -c 0x7c
in one shell window, and
rigctl -m 2
in another
If the audio is getting to/from the PC it is unlikely to be a
cable issue. If not then a temporary swap out may be in order.
Also worth doing a few "sudo dmesg" commands whilst wriggling the
cable ends to look for any intermittent connection or dirt.
Oh also check the installed version of hamlib. From memory the ID
number for the IC9100 changed a few years ago. rigctl -l | grep
9100 should show something like;
3068 Icom IC-9100 20240726.5 Stable RIG_MODEL_IC9100
So going through the rig menus;
60. CI-V Baud Rate - 19200
61. CI-V Address - 7Ch
62. CI-V Transceive - Off
I don't know if below are important but as they affect port usage
set to defaults.
63. USB2/DATA1 Func - [-----]/GPS)
64. USB2/DATA1 Func - [-----/[GPS ]) (I assume there is no GPS
unit attached to the rig)
I guess it was possible that during the project evolution the
CI-V address has been changed on one rig to allow them to talk to?
each other. Hence the check.
Apart from ensuring the user is a member of dialout, the only
other possibility is something else on the PC has grabbed either
the USB or hamlib interface port for their own use. Most distros
IME don't install the tools to check serial ports "in use" so
difficult to suggest an action here. To check if the hamlib port
has been seized try a different one or check using netstat;
rigctld -m 3068 -v -r /dev/icom9100a -s 19200 -t 4534 -c 0x7c
rigctl -m 2 -r localhost:4534
To check that 4532 may be in use;
sudo netstat -tulpn | grep 4532
and
sudo netstat -n |grep 4532
When the rigctld and rigctl commands are not active
Quite often a command will include a port specification, so using
ps -axww | grep USB and? ps -axww | grep serial may show something
Also possible to check if rigctl/rigctld is a permissions issue
by running as root with a preceding sudo. eg
sudo rigctld -m 3068 -v -r /dev/icom9100a -s 19200 -c 0x7c
sudo rigctl -m 2
Also look into a whole rig reset, if nothing important has been
saved on them.
Cheers Bob
On 27/8/24 01:00, cdres wrote:
toggle quoted message
Show quoted text
It's good to know I'm getting closer. again, you all are much
appreciated.
?
So new window with rigctld -m2? and then f to get the freq
yeilds:
thinking I may have been connected to the wrong USB, I tried
with both, and both get the same message.
?
So, I'm not sure where it is going wrong. I saw a few people
mention adding 5 v's for debug, but I wouldn't have any idea
what to do with that information.
I keep thinking I have some kind of setting wrong on the rig,
so I'm going to go through with a fine tooth comb and see if I
can find an outlier.
?
_._,
|
Hi Rob/David
Actually for the 9100 it always presents them in the right
sequence. ie the first is always the C-IV port. Other USB devices
may of course get in the way of numbering if they are enumerated
first, for which the link/udev approach works. I would assume that
Icom configured the UARTs to always respond in the same order.
I don't think serial-by-id would solve the problem if the 9100
UART response sequence changed.
Cheers Bob VK2YQA
On 27/8/24 00:56, Rob Giuliano via
groups.io wrote:
toggle quoted message
Show quoted text
Since it appears the radio provides 2 USB devices (USB0 and
USB1), the operating system may not "ALWAYS" present them in the
same order.
This will cause no end to interfacing headaches.
?
If you are running this on a Linux distribution, you may look
into udev rules.
Depending on the USB device, you should be able to find a way
to separate the 2 and provide more descript '/dev/{device-name}
sim-links to make things easier to keep track of.
They may be using the same ProductID and VendorID, so you may
need to dig a bit deeper to find the identifying USB
characteristic to separate them.
-------
Robert Giuliano
KB8RCO
|
Of course Rob is right here.. though there is a
simpler way if the cabling on the host never changes:?
/dev/serial/by-id .? For example, I can see the various serial
ports on my host:
??? ls -la /dev/serial/by-id/
??? total 0
??? drwxr-xr-x 2 root root 80 Jul 15 08:27 .
??? drwxr-xr-x 4 root root 80 Jul 15 08:27 ..
??? lrwxrwxrwx 1 root root 13 Jul 15 08:27
usb-FTDI_usb_serial_converter_FTCAWZIA-if00-port0 ->
../../ttyUSB0
??? lrwxrwxrwx 1 root root 13 Jul 15 08:27
usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0
-> ../../ttyUSB1
With this, instead of using the command:
?? rigctld -m 3068 -v -r /dev/ttyUSB0 -s 19200 -c 0x7c
you would use say:
?? rigctld -m 3068 -v -r
/dev/serial/by-id/usb-FTDI_usb_serial_converter_FTCAWZIA-if00-port0
-s 19200 -c 0x7c
--David
KI6ZHD
??
On 08/26/2024 07:56 AM, Rob Giuliano
via groups.io wrote:
toggle quoted message
Show quoted text
Since it appears the radio provides 2 USB devices (USB0 and
USB1), the operating system may not "ALWAYS" present them in the
same order.
This will cause no end to interfacing headaches.
?
If you are running this on a Linux distribution, you may look
into udev rules.
Depending on the USB device, you should be able to find a way
to separate the 2 and provide more descript '/dev/{device-name}
sim-links to make things easier to keep track of.
They may be using the same ProductID and VendorID, so you may
need to dig a bit deeper to find the identifying USB
characteristic to separate them.
-------
Robert Giuliano
KB8RCO
|
It's good to know I'm getting closer. again, you all are much appreciated.
?
So new window with rigctld -m2? and then f to get the freq yeilds:
thinking I may have been connected to the wrong USB, I tried with both, and both get the same message.
?
So, I'm not sure where it is going wrong. I saw a few people mention adding 5 v's for debug, but I wouldn't have any idea what to do with that information.
I keep thinking I have some kind of setting wrong on the rig, so I'm going to go through with a fine tooth comb and see if I can find an outlier.
?
|
Since it appears the radio provides 2 USB devices (USB0 and USB1), the operating system may not "ALWAYS" present them in the same order.
This will cause no end to interfacing headaches.
?
If you are running this on a Linux distribution, you may look into udev rules.
Depending on the USB device, you should be able to find a way to separate the 2 and provide more descript '/dev/{device-name} sim-links to make things easier to keep track of.
They may be using the same ProductID and VendorID, so you may need to dig a bit deeper to find the identifying USB characteristic to separate them.
-------
Robert Giuliano
KB8RCO
|
So I went ahead and removed gpsd, renamed the modem
manager, and double checked all of the perms for dialout and tty.
I removed the ampersand, and the extra v's and rebooted- checking
the USB's again, the radio was now on USB0 and 1, so I tried both:
?
yields no errors- but doesn't do anything else. just opens an
empty line with a blinking cursor.
Perfect.. that's what you should see from an idle daemon "running".?
Just make sure you're running it on the right USB serial port be it
USB0 or USB1.? At that point, you need to open up a new window and
try out various rigctl commands connecting to "localhost" to change
things on the radio.? Read the man page on rigctl and Google around
and find some example commands to say move the VFO around, change
modes, and ultimately one command to key up the radio and a
different command to unkey the radio (could be a toggle command).?
Once that's all working, Direwolf should work too!
--David
KI6ZHD
|
hi Bob,
?
So I went ahead and removed gpsd, renamed the modem manager, and double checked all of the perms for dialout and tty. I removed the ampersand, and the extra v's and rebooted- checking the USB's again, the radio was now on USB0 and 1, so I tried both:
?
yields no errors- but doesn't do anything else. just opens an empty line with a blinking cursor.
ctrl c and then:
yields the same effect. No scripts, no errors, no anything.
?
I'm hoping this is a better outcome than the errors? or just because of the lack of extra v's.
I did confirm that I have 60. as 19200 on the rig as well.? I am pretty sure the only way that I am starting rigctld is manually through these commands- I haven't to my knowledge, set anything else up.
I am planning to go through David's document, hoping to find something trivial that I just overlooked.
?
|
It must be that the D710 is internal to the ISS hull which is
radiation/rf-protective, and no external GPS antenna was interfaced
to the radio. Thank you.
On 8/25/24 08:47, I wrote:
toggle quoted message
Show quoted text
One would not expect instrumentation on the ISS to be limited to
the 60,000 ft. max GPS elevation restriction of many civilian
units. Even a TinyTrak-3 has provided high-altitude balloon
elevations > 92,000 ft., and certainly rocket scientists could
modify the D710. There must be a reason why they did not?
On 8/25/24 08:38, Thomas Leibold via
groups.io wrote:
Hi,
If this is the internal GPS receiver inside the
Kenwood D710 keep in mind that most such terrestrial GPS
receivers are intentionally limited at which altitude and
velocity they are operating (to prevent repurposing them for
military use).
GPS receivers for aviation use have a wider
range but still won't work in LEO.
Just my guess,
Thomas
KK6FPP
Get
Greetings, I'm wondering why the ISS PBEACON always
indicates ~0.0 lat/lon. Is GPS disabled due to rf electrical
or security concerns? From direwolf 1.8D:
...
0,1724595363,2024-08-25T14:16:03Z,RS0ISS,RS0ISS,16(2/2),0,',RS0ISS,IS,0.005500,0.166667,0.0,,,,,,Kenwood
TM-D710,Special,,ARISS-International Space Station
...
RS0ISS audio level = 16(2/2)??? ___||____
[0.3 07:16:03 25Aug2024]
RS0ISS>0P0PS3,APRSAT:'v&<0x1c>l
<0x1c>SI]ARISS-International Space Station=<0x0d>
MIC-E, Satellite/Pacsat w/overlay I, Kenwood TM-D710, Special
N 00 00.3300, E 000 10.0000, 0 km/h (0 MPH)
ARISS-International Space Station
...
Thank you.
|
But that would void the warranty.? If damaged during the mod, shipping cost back to Kenwood would be enormous <grin>
On Sunday, August 25, 2024 at 11:47:14 AM EDT, Rusty Travis <rusytravis19@...> wrote:
One would not expect instrumentation on the ISS to be limited to the
60,000 ft. max GPS elevation restriction of many civilian units.
Even a TinyTrak-3 has provided high-altitude balloon elevations >
92,000 ft., and certainly rocket scientists could modify the D710.
There must be a reason why they did not?
On 8/25/24 08:38, Thomas Leibold via
groups.io wrote:
Hi,
If this is the internal GPS receiver inside the
Kenwood D710 keep in mind that most such terrestrial GPS
receivers are intentionally limited at which altitude and
velocity they are operating (to prevent repurposing them for
military use).
GPS receivers for aviation use have a wider range
but still won't work in LEO.
Just my guess,
Thomas
KK6FPP
Get
Greetings, I'm wondering why the ISS PBEACON always indicates
~0.0 lat/lon. Is GPS disabled due to rf electrical or security
concerns? From direwolf 1.8D:
...
0,1724595363,2024-08-25T14:16:03Z,RS0ISS,RS0ISS,16(2/2),0,',RS0ISS,IS,0.005500,0.166667,0.0,,,,,,Kenwood
TM-D710,Special,,ARISS-International Space Station
...
RS0ISS audio level = 16(2/2)??? ___||____
[0.3 07:16:03 25Aug2024]
RS0ISS>0P0PS3,APRSAT:'v&<0x1c>l
<0x1c>SI]ARISS-International Space Station=<0x0d>
MIC-E, Satellite/Pacsat w/overlay I, Kenwood TM-D710, Special
N 00 00.3300, E 000 10.0000, 0 km/h (0 MPH)
ARISS-International Space Station
...
Thank you.
|
One would not expect instrumentation on the ISS to be limited to the
60,000 ft. max GPS elevation restriction of many civilian units.
Even a TinyTrak-3 has provided high-altitude balloon elevations >
92,000 ft., and certainly rocket scientists could modify the D710.
There must be a reason why they did not?
On 8/25/24 08:38, Thomas Leibold via
groups.io wrote:
toggle quoted message
Show quoted text
Hi,
If this is the internal GPS receiver inside the
Kenwood D710 keep in mind that most such terrestrial GPS
receivers are intentionally limited at which altitude and
velocity they are operating (to prevent repurposing them for
military use).
GPS receivers for aviation use have a wider range
but still won't work in LEO.
Just my guess,
Thomas
KK6FPP
Get
Greetings, I'm wondering why the ISS PBEACON always indicates
~0.0 lat/lon. Is GPS disabled due to rf electrical or security
concerns? From direwolf 1.8D:
...
0,1724595363,2024-08-25T14:16:03Z,RS0ISS,RS0ISS,16(2/2),0,',RS0ISS,IS,0.005500,0.166667,0.0,,,,,,Kenwood
TM-D710,Special,,ARISS-International Space Station
...
RS0ISS audio level = 16(2/2)??? ___||____
[0.3 07:16:03 25Aug2024]
RS0ISS>0P0PS3,APRSAT:'v&<0x1c>l
<0x1c>SI]ARISS-International Space Station=<0x0d>
MIC-E, Satellite/Pacsat w/overlay I, Kenwood TM-D710, Special
N 00 00.3300, E 000 10.0000, 0 km/h (0 MPH)
ARISS-International Space Station
...
Thank you.
|
Hi,
If this is the internal GPS receiver inside the Kenwood D710 keep in mind that most such terrestrial GPS receivers are intentionally limited at which altitude and velocity they are operating (to prevent repurposing them for military use).
GPS receivers for aviation use have a wider range but still won't work in LEO.
Just my guess,
Thomas
KK6FPP
Get
toggle quoted message
Show quoted text
Greetings, I'm wondering why the ISS PBEACON always indicates ~0.0 lat/lon. Is GPS disabled due to rf electrical or security concerns? From direwolf 1.8D:
...
0,1724595363,2024-08-25T14:16:03Z,RS0ISS,RS0ISS,16(2/2),0,',RS0ISS,IS,0.005500,0.166667,0.0,,,,,,Kenwood TM-D710,Special,,ARISS-International Space Station
...
RS0ISS audio level = 16(2/2)??? ___||____
[0.3 07:16:03 25Aug2024] RS0ISS>0P0PS3,APRSAT:'v&<0x1c>l <0x1c>SI]ARISS-International Space Station=<0x0d>
MIC-E, Satellite/Pacsat w/overlay I, Kenwood TM-D710, Special
N 00 00.3300, E 000 10.0000, 0 km/h (0 MPH)
ARISS-International Space Station
...
Thank you.
|
Greetings, I'm wondering why the ISS PBEACON always indicates ~0.0
lat/lon. Is GPS disabled due to rf electrical or security concerns?
From direwolf 1.8D:
...
0,1724595363,2024-08-25T14:16:03Z,RS0ISS,RS0ISS,16(2/2),0,',RS0ISS,IS,0.005500,0.166667,0.0,,,,,,Kenwood
TM-D710,Special,,ARISS-International Space Station
...
RS0ISS audio level = 16(2/2)??? ___||____
[0.3 07:16:03 25Aug2024]
RS0ISS>0P0PS3,APRSAT:'v&<0x1c>l
<0x1c>SI]ARISS-International Space Station=<0x0d>
MIC-E, Satellite/Pacsat w/overlay I, Kenwood TM-D710, Special
N 00 00.3300, E 000 10.0000, 0 km/h (0 MPH)
ARISS-International Space Station
...
Thank you.
|
Oh and forgot to mention. Be wary using the 9100 monitor, as the
TX audio then comes back into the DW RX. I have no idea if that
can cause a problem beyond just displaying on the terminal and
log, but just to keep in mind.
Bob
|
Hi David
Well my setup is Pulseaudio so very different;
(DONT USE THESE CASSIE)
#ADEVICE
ACHANNELS 2
RATE 48000
CHANNEL 0
MODEM 300 B+
PTT RIG 2 localhost:4532
CHANNEL 1
MODEM 1200
#No PTT so complains at start about using VOX
I assume that the ADEVICE settings default to the one stereo
soundcard. The left channel is main, right is sub. I used
pavucontrol for the initial device choice, but I also have some
pactl commands in the direwolf start script that sets device and
application volumes as they always revert to 100%, which is
probably now well beyond the OP topic. It's also possible to
define the audio device with an environment variable. eg
PULSE_PROP_APPLICATION_NAME=DIREWOLF
PULSE_SINK=alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo
PULSE_SOURCE=alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo
direwolf
Onto your initial setup Cassie I suggest you just use;
ADEVICE plughw:2,0
ACHANNELS2
ACHANNEL 2
CHANNEL 0
MODEM 1200 (or whatever it is)
PTT RIG 2 localhost:4532
......... etc
ACHANNEL 2
CHANNEL 1
MODEM 1200 (same as Ch0)
........... etc
Which is exactly what David suggested and the simplest way.
And assuming the sat uses 2m, run the rig 2m main and 70cm sub
both in FM-D mode, but NOT in satellite mode. The 70cm side will
not initially be tuned/used. If you really wanted to use rig
satmode the left/right channels toggle with the main/sub change so
no direwolf changes are needed. The main use of the 9100 sat mode
though is to track the main/sub VFOs when using the dial/knob and
run full duplex, so not really relevant to DW use. Further, if you
were to use gpredict to Doppler track the sat freq actually set it
to half duplex & VFO Up/Down not applicable, so as not to
touch the sub operating frequency at all.
Cheers Bob VK2YQA
On 24/8/24 07:07, David Ranch via
groups.io wrote:
toggle quoted message
Show quoted text
Hey Cassie,
It's great to see Bob's real world experience with the IC-9100
and what you need to consider when working with that radio.? One
thing that wasn't clear to me from Bob's message is which "audio
channel" the main band vs. sub-band audio is heard on.? If you
read:
?? #PDF page 59
??
You can see how Direwolf maps it's MONO channels to different
audio channels.? Ultimately, you need to find out if you need to
use:
?? #the left audio channel from the IC9100
?? ADEVICE plughw:2,0
?? ACHANNEL 2
?? CHANNEL 0
vs.
?? #the right audio channel from
the IC9100
?? ADEVICE plughw:2,0
?? ACHANNEL 2
?? CHANNEL 1
The other points that Bob brings up are super critical but are
technically not Direwolf's issue.? Since you're new to Linux and
maybe a bunch of these pitfalls, my Direwolf on Raspberry Pi document (aka.. anything
debian based) might be helpful in some of these areas (gpsd,
modem-manager, etc)
??
There are other guides out there on the Internet as well
though I can't speak to their accuracy, being up to date, etc.
--David
KI6ZHD
|
Hey Cassie,
It's great to see Bob's real world experience with the IC-9100 and
what you need to consider when working with that radio.? One thing
that wasn't clear to me from Bob's message is which "audio
channel" the main band vs. sub-band audio is heard on.? If you
read:
?? #PDF page 59
??
You can see how Direwolf maps it's MONO channels to different
audio channels.? Ultimately, you need to find out if you need to
use:
?? #the left audio channel from the IC9100
?? ADEVICE plughw:2,0
?? ACHANNEL 2
?? CHANNEL 0
vs.
?? #the right audio channel from the
IC9100
?? ADEVICE plughw:2,0
?? ACHANNEL 2
?? CHANNEL 1
The other points that Bob brings up are super critical but are
technically not Direwolf's issue.? Since you're new to Linux and
maybe a bunch of these pitfalls, my Direwolf on Raspberry Pi document (aka.. anything debian
based) might be helpful in some of these areas (gpsd,
modem-manager, etc)
??
There are other guides out there on the Internet as well
though I can't speak to their accuracy, being up to date, etc.
--David
KI6ZHD
On 08/23/2024 01:52 PM, Bob Cameron
wrote:
toggle quoted message
Show quoted text
Hi Cassie
It looks like David has answered all. I am on the other side of
the world so some sleeping delay involved. Some notes;
One trap you might fall into later and should just keep in mind
is that the audio device in the 9100 is split left/right (ie
stereo) between the main and sub bands. In general terms that
means the top frequency display on the rig is main and the lower
one is sub. The sub band in normal "non satellite" mode is RX
only. I for example TX/RX on 30m whilst concurrenty RX only on
2mFM.?
In rig satellite mode however the sub band is the one that
TX/RX's and the main is RX only. For satellite half duplex it is
unlikely you'd use satellite mode, but one day you might want to
run both 70cm and 2m for sats or even concurrently listen on HF
for something. This will also tend to get confusing if you use a
satellite tracking, operating frequency program to compensate
for Doppler.
As mentioned, just keep in mind for later.
Regarding the non Icom response and bind/in use error. I have
found (in Debian) that the GPS daemon (gpsd) often grabs the
first USB port regardless. It actually happens before the daemon
even starts and is to do with a socket allocation on finding an
external USB device. Sorry I don't remember all the details. I
assume you will eventually want to connect a GPS device. If not
I suggest you remove gpsd from the installation as a quick way
out. If you eventually need to (eventually) connect a GPS unit
get back to me for assist. The other bind/conflict problem is
the dialup modem manager. If you don't use a dialup modem, the
easy workaround is to rename /sbin/ModemManager to
/sbin/ModemManager.disabled. Yes there are nicer ways but that
works.
I assume you changed the rigs serial speed from Auto to 19200?
That along with setting dialout perms might also be the reason
for no response.
When testing with rigctld in a separate shell/window there is
no need to background the process. ie omit the ampersand (&)
from the command end. (Backgrounding is what the [1] response
line indicates) It's only really needed if you have inserted it
early in the direwolf startup script. I cant really comment
where that is on your system. The -vvv command option is a log
verbosity thing so reducing that to (say) -v or even omitting
might eventually be in order.
Cheers Bob VK2YQA
On 24/8/24 01:08, cdres wrote:
You both are just wealths of knowledge here. I will be
apologizing at multiple points for what I see as very 'noob'
questions. I am just so grateful to have someone know what I'm
talking about. The? only person who had a strong sense of any
of this project graduated last semester, so I have a lot to
catch up on. For reference, the end goal of this project is to
have this 9100 and computer set as a ground station for a cube
satellite that will be flying with a TRX-VU radio board. Just
to put things in perspective for you all. Now on to the
updates...
?
Referencing the section you posted below, a few questions.
?
"When using the USB only connection the PTT goes in on
the first serial port as an Icom CI-V command. The 9100 does
not support RTS etc PTT signalling. The easiest way to
handle that IMO is to install hamlib and run the rigctld
daemon before starting direwolf. In my case I have the
following in the dw startup;
/usr/local/bin/rigctld -m 3068 -vvv -r /dev/icom9100a -s
19200 -c 0x7c &?? "
?
Forgive me if this is a really embarrassing question, but
where would I add that line with the correct dev into the
direwolf startup? I will install hamlib, too. once I figure
out which version to download... I'll work on that this
afternoon.?
?
I did the dmesg and confirmed the radio is USB0 and USB1-
so, would I use /dev/USB0 in the rigctld line?
?
Going into the instructions on the 9.1.3, when I use
arecord/aplay -l commands, it only shows two cards-
arecord -l
?
Since I haven't actually finalized the direwolf config
file, I won't try to run it quite yet. I'd like to make sure
I get the PTT line correct and make sure I get hamlib
installed in order to have that run appropriately.
?
That's all I have at the moment... but I will be back in
the lab this afternoon to try to hammer out something
beneficial. Again, I appreciate your help, and you patience
as I try to get caught up on what this all means.
?
Thanks again,
Cassie
KJ5HMK
aplay -l:
?
Then going into
|
Hi Cassie
It looks like David has answered all. I am on the other side of
the world so some sleeping delay involved. Some notes;
One trap you might fall into later and should just keep in mind
is that the audio device in the 9100 is split left/right (ie
stereo) between the main and sub bands. In general terms that
means the top frequency display on the rig is main and the lower
one is sub. The sub band in normal "non satellite" mode is RX
only. I for example TX/RX on 30m whilst concurrenty RX only on
2mFM.?
In rig satellite mode however the sub band is the one that
TX/RX's and the main is RX only. For satellite half duplex it is
unlikely you'd use satellite mode, but one day you might want to
run both 70cm and 2m for sats or even concurrently listen on HF
for something. This will also tend to get confusing if you use a
satellite tracking, operating frequency program to compensate for
Doppler.
As mentioned, just keep in mind for later.
Regarding the non Icom response and bind/in use error. I have
found (in Debian) that the GPS daemon (gpsd) often grabs the first
USB port regardless. It actually happens before the daemon even
starts and is to do with a socket allocation on finding an
external USB device. Sorry I don't remember all the details. I
assume you will eventually want to connect a GPS device. If not I
suggest you remove gpsd from the installation as a quick way out.
If you eventually need to (eventually) connect a GPS unit get back
to me for assist. The other bind/conflict problem is the dialup
modem manager. If you don't use a dialup modem, the easy
workaround is to rename /sbin/ModemManager to
/sbin/ModemManager.disabled. Yes there are nicer ways but that
works.
I assume you changed the rigs serial speed from Auto to 19200?
That along with setting dialout perms might also be the reason for
no response.
When testing with rigctld in a separate shell/window there is no
need to background the process. ie omit the ampersand (&) from
the command end. (Backgrounding is what the [1] response line
indicates) It's only really needed if you have inserted it early
in the direwolf startup script. I cant really comment where that
is on your system. The -vvv command option is a log verbosity
thing so reducing that to (say) -v or even omitting might
eventually be in order.
Cheers Bob VK2YQA
On 24/8/24 01:08, cdres wrote:
toggle quoted message
Show quoted text
You both are just wealths of knowledge here. I will be
apologizing at multiple points for what I see as very 'noob'
questions. I am just so grateful to have someone know what I'm
talking about. The? only person who had a strong sense of any of
this project graduated last semester, so I have a lot to catch
up on. For reference, the end goal of this project is to have
this 9100 and computer set as a ground station for a cube
satellite that will be flying with a TRX-VU radio board. Just to
put things in perspective for you all. Now on to the updates...
?
Referencing the section you posted below, a few questions.
?
"When using the USB only connection the PTT goes in on the
first serial port as an Icom CI-V command. The 9100 does not
support RTS etc PTT signalling. The easiest way to handle that
IMO is to install hamlib and run the rigctld daemon before
starting direwolf. In my case I have the following in the dw
startup;
/usr/local/bin/rigctld -m 3068 -vvv -r /dev/icom9100a -s
19200 -c 0x7c &?? "
?
Forgive me if this is a really embarrassing question, but
where would I add that line with the correct dev into the
direwolf startup? I will install hamlib, too. once I figure
out which version to download... I'll work on that this
afternoon.?
?
I did the dmesg and confirmed the radio is USB0 and USB1-
so, would I use /dev/USB0 in the rigctld line?
?
Going into the instructions on the 9.1.3, when I use
arecord/aplay -l commands, it only shows two cards-
arecord -l
?
Since I haven't actually finalized the direwolf config
file, I won't try to run it quite yet. I'd like to make sure I
get the PTT line correct and make sure I get hamlib installed
in order to have that run appropriately.
?
That's all I have at the moment... but I will be back in
the lab this afternoon to try to hammer out something
beneficial. Again, I appreciate your help, and you patience as
I try to get caught up on what this all means.
?
Thanks again,
Cassie
KJ5HMK
aplay -l:
?
Then going into
|
I restarted the system, disconnected all the rig, turned it
off, rebooted ubuntu, plugged it all back in, and turned on the
radio, still same message. I've got something not set up right,
now to find it.
How are you starting rigctld?? Manually?? Via some script?? I would
recommend to do this manually until you prove things are working at
the basic levels.
I did make sure the user is on the dialout list, immediately
after the command, it first shows:
and then followed by a continuous time out list, and after
several minutes, It did update with this at the bottom:
Opened rig model 3068, 'IC-9100'
binding failed (trying next interface): Network error 98:
Address already in use
binding failed (trying next interface): Network error 98:
Address already in use
main: bind error - no available interface
?
This seems to me that you have multiple rigctld daemons running.?
You should only have one.? However it might start.. the radio should
be ON and connected via USB first.
--David
KI6ZHD
|
I did make sure the user is on the dialout list, immediately after the command, it first shows:
and then followed by a continuous time out list, and after several minutes, It did update with this at the bottom:
Opened rig model 3068, 'IC-9100'
binding failed (trying next interface): Network error 98: Address already in use
binding failed (trying next interface): Network error 98: Address already in use
main: bind error - no available interface
?
I restarted the system, disconnected all the rig, turned it off, rebooted ubuntu, plugged it all back in, and turned on the radio, still same message. I've got something not set up right, now to find it.
?
running ps ax|grep rigctld:
1083837 pts/0 ? ?S ? ? ?0:00 rigctld -m 3068 -vvv -r /dev/ttyUSB0 -s 19200 -c 0x7c
1087081 pts/0 ? ?S+ ? ? 0:00 grep --color=auto rigctld
?
?
|
