I had been having some issues with SATPC32 and my iCOM IC-9700. Whenever I was running SATPC32 and RS-44 was active, for some reason if I used the rig’s VFO knob to tune around the passband, it would sometimes caused the Doppler adjustments to stop working. All the other satellites were just fine.
I went back to the recommended settings from the SATPC32 documentation and discovered I was twice their recommended baud rate. So I lowered things to 57600 baud. On my first test, that seemed to fix the problem with RS-44.
However, I also use that radio with WinLink and VARA FM. I knew that I was using CAT for PTT, so I needed to drop the baud rate down on that as well. Imagine my surprise at finding that 57600 baud didn’t exist as a valid value.
The fix was simple; change from PTT CAT control to COM control. I used the same COM port as I had used for CAT control (COM4 in my case), and selected the PTT pin as RTS. That worked just fine.
I haven’t made a satellite contact in a few years as another club member was nice enough to step up. However, he had to back out this year, and I was left flat footed when everyone else took a step back; it looked like I had stepped forward to volunteer.
I spent a few hours today updating my satellite laptop with all the latest Windoze stuff, and figuring out why my IC-9700 didn’t power up (12VDC power supply had a loose AC plug). My next shock was that, for the most part, the birds I used a few years back were no longer active (bye bye CAS-x and XW-X). AO-7 is still sort of working, as was RS-44.
I was able to adjust the transmitter calibration and hear myself on RS-44, but had no responses to a CQ. That bird seemed to have very good doppler correction throughout the last half of the pass.
I also heard a few SSB calls on AO-73, so gave that a try. As usual the transmit doppler correction was about 7000 Hz off. I did make a partial SSB contact with N2FYA, but I don’t think he had the last letter of my call correct. AO-73 has always been a challenge for me due to its unpredictable frequency offsets.
I need to setup FO-118, JO-97, HO-113 and XW-4, which are all new birds for me, then get the transmit uplink calibrated for them and AO-7.
Field Day 2024 rules are clear that multiple QSOs count now, but only one FM contact may be counted per FM bird:
7.3.7. Satellite QSO: 100 bonus points for successfully completing at least one QSO via an amateur radio satellite during the Field Day period. “General Rules for All ARRL Contests” (Rule 3.7.2.), (the no-repeater QSO stipulation) is waived for satellite QSOs. Groups are allowed one dedicated satellite transmitter station without increasing their entry category. Satellite QSOs also count for regular QSO credit. Show them listed separately on the summary sheet as a separate “band.” You do not receive an additional bonus for contacting different satellites, though the additional QSOs may be counted for QSO credit unless prohibited under Rule 7.3.7.1. The QSO must be between two Earth stations through a satellite. Available to Classes A, B, and F.
7.3.7.1 Stations are limited to one (1) completed QSO on any single channel FM satellite.
I’ve just added an IC-9700 to the desk alongside the IC-7300, they look very nice together and very similar. Unfortunately the Audio and Serial devices also look very similar in Linux!
Both radio sound cards appear as PCM2901 making it hard to differentiate between them, and my previous udev rule to create a symlink for the IC-7300 ttyUSB device on /dev/ic7300 picked up the 9700 instead.
My previous udev serial rule created a symlink to /dev/ttyUSBx from /dev/ic7300 when a device with the 7300’s serial adapter idVendor and idProduct was seen like so:
This worked fine until the 9700 was plugged in as it also has the same idVendor and idProduct number. We can narrow this down easily as another available attribute is “serial” which contains the radios unique serial number along with its name.
We can get the serial numbers using udevadm (or better with lsusb below) against each of the /dev/ttyUSBx devices, the 9700 has two serial devices, the first works fine with hamlib for control but not sure what the second serial device at the moment.
$ udevadm info –attribute-walk –path=/sys/bus/usb-serial/devices/ttyUSB1 | grep IC-
ATTRS{serial}==”IC-7300 03000000″
An easier way to get the serial numbers is by running lsusb as root as follows, thanks to PA3MET for the pointer!
# lsusb -vvvvv | egrep "9700|7300"
iSerial 3 IC-9700 13000000 B
iSerial 3 IC-9700 13000000 A
iSerial 3 IC-7300 03000000
We can take these and create appropriate udev rules for adding symlinks for the radios serial devices including the unique serial numbers. Here is an extract from my /etc/udev/rules.d/99-hamlib.rules file:
Take care if copying the above text as the quotation marks are displaying incorrectly in WordPress. If you copy it as is you will need to replace them all with proper quotation marks.
A reload of udev rules with “udevadm trigger” and we have our serial devices available from convenient symlinks so no chasing about ttyUSB device names:
Next up is the sound cards. I use quite a lot of different programs and need to easily switch and adjust my audio inputs/outputs using pavucontrol. The problem here is both audio devices have the same name, PCM2901, meaning I can’t easily tell what sound card belongs to what radio.
There’s no way to differentiate the sound cards like with the serial above as they return the exact same information and attributes. The only way to differentiate them from what I can see is with the physical USB port they are plugged in to. This is fine here as it’s a desktop and they will remain plugged in to the same ports. If you plug the radios in to a different USB socket you will need to update the paths again.
We can list the devices with the following command, this shows both the IC-7300 and IC-9700 sound cards. I’ve removed some other sound cards from the output, as we’re just looking for the “Burr-Brown_from_TI_USB_Audio_CODEC” entries here
We are looking to extract the unique portion from device paths above, here we can see the paths differ at 3-3/3-3.4/3-3.4 and 3-2/3-2.4/3-2.4. We will want to identify which entry belongs to which radio so run it with the USB disconnected then connected to identify which device matches which radio.
We can then run the following to apply a device description of IC9700 to the IC-9700 sound card source and sink which will show against the audio device in pulse applications instead of PCM2901.
The 3-3.4 below is referencing the end of the USB port discovered above.
pacmd update-sink-proplist $(pacmd list-sinks | egrep “name:.*Burr-Brown*|3-2.4” | grep -B 1 sysfs.path | grep name | sed “s/.*<\(.*\)>/\1/”) device.description=IC7300
The audio devices should now be available using the name we set above in pavucontrol and other applications. This can be put in a script to run manually or at system startup.
Don’t want to build your own? I now sell these and an alternative design with a better, fixed external unit on my shop! The Icom IC-9700 has a GPS data input available but no oficial accessory from Icom. It’s a 2.5mm TRS connection that allows users to connect a GPS unit with an RS232 output …
Login
