[pskmail] Re: ICOM interfacing with pskmail_server

  • From: Rein Couperus <rein@xxxxxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Mon, 01 Jun 2009 08:43:56 +0200

'answers' below...

> -----Ursprüngliche Nachricht-----
> Von: "Rick W" <mrfarm@xxxxxxxxxxxxxxx>
> Gesendet: 31.05.09 20:13:36
> An: pskmail@xxxxxxxxxxxxx
> Betreff: [pskmail] ICOM interfacing with pskmail_server

> I have had a great deal of help from David, KF4WBS, in setting up a 
> pskmail server. Lots of things to set up and thankfully, I had some 
> Linux knowledge from earlier attempts to use the OS or I would have been 
> hopelessly overwhelmed.
> Currently, I tried interfacing with an ICOM 746Pro. In order to do this, 
> I set up a SignaLink USB for the audio lines. It can also do VOX keying 
> for PTT. Then for rig control I have a homebrew CI-V interface to go 
> from COM (with the usual adapter from USB).
> It mostly works, but there are some issues:
> 1. I have the computer connected to the rear 6 pin mini DIN plug on the 
> rig which means it must be in the "D" mode to key up the PTT. Since the 
> pskmail server changes through the 5 different one minute intervals to 
> different frequencies, modes, and sideband setup, I have found that when 
> the switch occurs, the rig drops out of the D mode and of course the rig 
> can no longer be keyed from the software.
> All our HF rigs are recent vintage ICOMs so would probably all have the 
> same problem.
> Has anyone found a work around for this dropping out of D mode?
> The only software program I have been able to control the toggling of 
> the D mode is Ham Radio Deluxe, so I know that I can be done in software.

we have an icom 756 on pi4tue which is keyed by hardware ptt.
i have no info about later icom rigs.

> 2. Is there any way to key an ICOM with this program, using the PTT 
> command set under CI-V? If not, then you would either need to have a VOX 
> type interface. Otherwise it would be necessary to interface through the 
> mike connector using the rig's own VOX. This can not be done via the 
> rear ports since the VOX circuit comes before those connectors.

INTERMAR (www.pskmail.de) has a solution which generates hardware ptt from 
the audio signal, and also allows to set the audio level by software. you could 
take a look there... 
> 3. I still get an error periodically that says:
> Invalid arg for command 'set_mode'
> sh : 0 not found

do you have the mode in the freqs.txt file? this may be a hamlib issue...
the error message comes from hamlib trying to set the mode. if there isn't one 
in the freqs.txt file i expect an error message.
maybe Roberto (IS0GRB) can shed some light on this, he wrote the patch :)
Normally the argument used is USB,USB,USB,USB,USB,

> I am guessing this is an argument that I have set wrong?
> 4. I seem to have poor results with using the PSK125 and 250 speeds with 
> my "local" test set up here in the shack running between two systems: 
> the Linux computer with the ICOM 746 Pro with the pskmail_server and the 
> Vista computer with the javaPSKmail client. This is probably due to 
> inherent problems as I have had great difficulty in the past to try and 
> locally connect this way using the higher speed modes, e.g., PSK250.
> Even though the rigs are responding to each other the data may be 
> corrupted perhaps and they eventually time out.

normally this is an fldigi issue. it needs the right frequency (within 20 Hz) 
you may try with AFC off. Lck the tx frequency. Use the right amplitudes on 
the sound card.... etc...

> Can someone explain what the server means by:
> status : last = 4 good = 0 end = 2 missing =
> And then sometimes it will have groups that increase with last = 1 good 
> = 1 and then last = 2 and god = 2, etc.

this is monitor output of the status information the client sends to the server.
the numbers refer to the internal buffer in the client which is max. 64 
(0...63) blocks.

last= last block sent to the server
good = last block received consecutively correct by the client
end = last block received correct by the client
missing = nr of blocks missing from last frame

read ARQ.pdf which explains the protocol.

> Lots to understand, that is for sure.

You can never learn enough :)


Rein OH0/PA0R/P

> 73,
> Rick, KV9U


Other related posts: