I was in an conversation with regard to a 902MHz enthusiast list, and we were discussing issues that may be unique to the 902MHz band due to the ARRL band plan, that was adapted to reflect reality in much of the USA with regard to easily adaptable commercial equipment.
The real life ham bands where the FM next to weak signal situation might occur (in the USA) based on the ARRL band plan include:
50MHz: The SSB/CW only and “any mode” meet at 50.3MHz. Maybe most FM operators stay about 51MHz? I have the equipment for this band but regrettably don’t listen often.
144MHz: I assume most weak signal work is at least 100kHz away from the popular 144.390MHz APRS frequency
220MHz: Again a case of ~100kHz spacing between FM and whatever weak signal work may exist
440MHz: The satellite band with what are typically very directive antennas keep multi-MHz separation between FM and weak-signal
900MHz: I would expect below 902.080MHz and above 902.120MHz to be trashed for weak signal operators according to the band plan.
The situation I felt hinges on:
a) what the relevant FCC specifications demand for “off-channel, in-band” emissions — is this just specified as say -60dB so many kHz from center channel, or with an emission mask. In either case, is the specification sufficient to protect a weak signal operator within N km of a powerful FM transmitter?
b) If the specification is not sufficient for weak signal protection from nearby (in range) FM transmitters, do the practical filter implementations used by the most frequently used equipment provide enough protection any way as a corollary to meeting the FCC specification?
Stopping rigctld and rotctld:
# finds rigctl and rotctl PIDs and SIGTERMs them
# Michael Hirsch
if [[ -n $RigPID ]]; then
echo "Stopping rigctld PID $RigPID"
if [[ -n $RotPID ]]; then
echo "Stopping rotctld PID $RotPID"
Starting rigctld and rotctld: for Kenwood TS-2000 on /dev/ttyS0 and Yaesu GS-232B rotor controller on /dev/ttyS1
if [[ -z $RigPID ]]; then
echo "Started rigctld"
rigctld --model=214 --rig-file=/dev/ttyS0 --serial-speed=57600 -C serial_handshake=Hardware,post_write_delay=10 &
if [[ -z $RotPID ]]; then
echo "Starting rotctld"
rotctld --model=603 --rot-file=/dev/ttyS1 --serial-speed=9600 -C serial_handshake=Hardware,post_write_delay=10 &
Remember: if using GPredict with Hamlib, do not use -v verbose options, since the extra text output will confuse Gpredict.
To change the baud rate of the Kenwood TS-2000 over the RS-232 serial COM port, you can do this locally or remotely.
Locally, you go into menu 56, and select your baud rate. Hamlib/rigctl recommends using the highest possible baud rate i.e. 57600 baud. Then power cycle the radio.
Remotely, look at the CAT EX menu item 56. You can read the current baud rate by sending
The radio will answer back
EX05600004; which implies 57600 baud since the last digit is 4. The last digit to baud is:
To set, send the corresponding command. E.g. to set 57600 send:
and turn off the TS-2000 by sending
Now disconnect, and reconnect at the new baud rate (here, 57600) and turn the radio on by sending:
Note: You can lose communication with your TS-2000 requiring a site visit. Be prepared.
This is easy to install thanks to John Nogatch’s PPA:
sudo apt-add-repository ppa:jnogatch/wsjtx
sudo apt-get update && sudo apt-get install wsjtx
mkdir ~/.wsjtx && cd ~/.wsjtx
Then just type
to start WSJT-X program