Configuring gpredict for use with YAESU FT-847


#1

This topic should give an overview to gpredict users, running a YAESU FT-847 radio, on how to setup things: the radio, rigctld and gpredict as well.

What do we need:

  • first of all, of course: the radio
  • a PC running gpredict (at the moment: only the master branch of gpredict’s git will work)
  • a connection between the PC running gpredict and the radio (here: RS232-USB interface)

As an USB to RS232 interface I bought the converter from “TechnoFix UK”, which can be obtained from e.g. ebay et al. There might be a problem with your braille kernel driver, so you have to disable this from loading at system start (to get /dev/ttyUSB?).
Remember to add the user running rigtcl[d] to the dialout group.
My PC is running an actual debian with KDE as desktop environment and hamlib is the version delivered as distri package (currently Hamlib 1.2.15.3), because I have been too lazy to compile it by myself.
Another issue I found while testing the threaded version of my gpredict build: transponder modes, such as FM, LSB, USB etc. have to be set manual on the radio (this is a known issue).

Setting up the radio:
FT-847 Menu 37 “CAT RATE” -> 57600

Starting rigctld:
/usr/bin/rigctld -m 101 -r /dev/ttyUSB0 -t 4532 -s 57600 --set-conf=stop_bits=2,serial_handshake=None

Setting up gpredict:
Edit -> Preferences -> Interfaces -> Add New
Name: YAESUFT-847
Host: 127.0.0.1
Port: 4532
Radio Type: Duplex TRX
PTT status: Read PTT
VFO Up/Down: SUB /\ / MAIN /
LO Down:
LO Up:
Signalling: [ ] AOS [ ] LOS

in Radiocontrol widget:
Settings:

  1. Device: YAESUFT-847
  2. Device: None
    Cycle: 2500

Note on Cycle:
You have to chose a value bigger than the communication via RS232 to the radio takes! This is approximately 300 ms per command, existing of the command itself and the answer, containing the result. With a full-duplex radio there are 7 (!) commands executed:

  1. [t] get PTT status
  2. [f] get current VFOA frq
  3. [F {…}] set new VFOA frq
  4. [f] check if new VFOA frq is set
  5. [i] get current SUB frq
  6. [I {…}] set new SUB frq
  7. [i] check if new SUB frq is set.

This results in a cycle-time of approx 2100 ms - add some time to ensure all commands are transmitted. The idea to enclose the whole communication into separate threads came up, because socket communication is always blocking. This also comes up with rotctld! Blocking calls within these widget will block the whole GUI, so the idea came up to separate these blocking calls into threads - one per control widget each. I am currently working on this, but if you would like to beta-test, please feel free to take a look at:

https://github.com/DL4PD/gpredict/tree/multithread-ctrl

TODO: add some screenshots


Error configuring source code of gpredict
#2

Hi Patrick,

Thanks for putting your notes here. I’m glad that interfacing with this radio will finally be resolved in the next version, whenever that will be. I will take a look at your updated branch as soon as I can, I’ve just been very busy lately.


#3

No problem at all, Alex!
I’ve been hunting some bugs (most caused by side effects of thread synchronisation - really hard to find) the last days. I think I will do a pull request when I’m back from work on friday morning (if my debugging session looks good ;).

While debugging, I’ve been thinking about a “display” for the linear transponders. Maybe I can get a little piece of code to show what I think will be good. Or maybe some simple drawings. But that is off-topic in here :slight_smile:


pinned #4