PTT -- w/o rig control

[dhas...@fvrl.org]

I have everything working well (Pat and WINMOR) with one exception: controlling the PPT line via a simple RS-232/one-transister switch, without full CAT/CI-V rig control. I have Icom radios, but no CI-V control converter box.

I tried to set definitions with rigctld, but just managed to mess up things up and nothing in Pat would work at all. I'm back to a clean install and config file, and I can get everything working properly with VOX ptt, but that is where success ended (no connects, VOX circuit not nearly fast enough for WINMOR).

My question: how would I set up Pat's congif file to set the serial RTS line high, thus closing the PTT circuit via my simple little interface, but not using any form of remote (CAT/CI-V) rig control? In other words, to get it to function exactly as FlDigi or packet does? :^) I think such a set-up would benefit many hams, especially those on a budget.

Any ideas would be appreciated.

Best regards and 73,
Dave Hassler
K7CCC

[Erlend Grimseid]

Hi.

If you only need to pull the rts line high you could use rigctld.

Use an dummy rig, set ptt device (-p) to the appropriate serial port,  and ptt type (-P) to rts.
I have not tried this my self but i think it might work.

If you want to build your own CI-V interface you could use an usb to ttl adapter. Its an easy build and the adapters are cheap on EBAY.

Google it, or contact me of list and I will help you.

73
LA4TTA
Erlend 

[dhas...@fvrl.org]

Hi, Everyone.

Here's an update, and (as you will see) I still need some help setting things up properly.

I tried the following:

1) open a terminal console instance and run rigctld like this: rigctld -m 1 -p=/dev/ttyS0 -P=RTS
2) leave the terminal window open and rigctld running
3) open a second terminal console instance and run this: pat configure
4) edit the "winmor" section and change the PTT variable to "true."  Save the new config. Run Pat.

Here's the terminal output:
$ pat http
2016/06/06 06:40:49 Starting HTTP service (localhost:8080)...
2016/06/06 06:41:07 WINMOR TNC v1.5.9.0 initialized
2016/06/06 06:41:07 Unable to set PTT rig 'dummy': Not defined or not loaded.

Clearly, I'm missing something in the config.json file.  Any ideas? 
I think there's some addressing missing in config.json to access the rigctld port,
but I'm kind of a linux/networking noob, and I'm totally unsure what should be added or where in the config file.
Below is the config.json file I have, auto-generated by Pat, and then with the bits I added:

{
  "mycall": "K7CCC",
  "secure_login_password": "xxxxxxxxx",
  "auxiliary_addresses": [],
  "locator": "CN85pp",
  "http_addr": "localhost:8080",
  "motd": [
    "Open source Winlink client - getpat.io"
  ],
  "connect_aliases": {
    "telnet": "telnet://{mycall}:CMST...@server.winlink.org:8772/wl2k"
  },
  "listen": [],
  "hamlib_rigs": null,
  "ax25": {
    "port": "wl2k",
    "beacon": {
      "every": 3600,
      "message": "Winlink P2P",
      "destination": "IDENT"
    },
    "rig": "dummy"                  <----------  I ADDED THIS
  },
  "serial-tnc": {
    "path": "/dev/ttyUSB0",
    "baudrate": 9600,
    "type": "Kenwood"
  },
  "winmor": {
    "addr": "localhost:8500",
    "inbound_bandwidth": 1600,
    "rig": "dummy",                <----------  I ADDED THIS
    "ptt_ctrl": true                <----------  I ADDED THIS
  },
  "ardop": {
    "addr": "localhost:8515",
    "arq_bandwidth": {
      "Forced": false,
      "Max": 500
    },
    "rig": "",
    "ptt_ctrl": false,
    "beacon_interval": 0,
    "cwid_enabled": true
  },
  "telnet": {
    "listen_addr": ":8774",
    "password": ""
  },
  "gpsd_addr": "localhost:2947",
  "schedule": null,
  "version_reporting_disabled": false
}


Any help will be appreciated.

Thanks,
Dave
K7CCC

[Martin Hebnes Pedersen]

Hi again Dave,

thank you for re-posting on this list :)

On 06/06/16 07:55, dhas...@fvrl.org wrote:

1) open a terminal console instance and run rigctld like this: rigctld -m 1 -p=/dev/ttyS0 -P=RTS
2) leave the terminal window open and rigctld running
3) open a second terminal console instance and run this: pat configure
4) edit the "winmor" section and change the PTT variable to "true."  Save the new config. Run Pat.

Here's the terminal output:
$ pat http
2016/06/06 06:40:49 Starting HTTP service (localhost:8080)...
2016/06/06 06:41:07 WINMOR TNC v1.5.9.0 initialized
2016/06/06 06:41:07 Unable to set PTT rig 'dummy': Not defined or not loaded.

Clearly, I'm missing something in the config.json file.  Any ideas? 
I think there's some addressing missing in config.json to access the rigctld port,

Yes, you are missing the actual rig definition (addressing etc.). This is the hamlib_rigs section of the configuration file.

See https://github.com/la5nta/pat/wiki/Rig-control#configuration for some explanation of this relationship.

For your setup, I would suggest the following entry (top-level in the JSON document):
"hamlib_rigs": {
  "my_ptt_rig": {"address": "localhost:4532", "network": "tcp"}
},

... and under the winmor section, make sure the "rig" attribute matches the rig's name (i.e. my_ptt_rig).

Please note, "my_ptt_rig" can be any string you want it to be, I called mine "ft897" for clarity :)

The rest of your config looks fine, I think you're all good to go as soon as you have added the hamlib_rigs entry!

--
73 de LA5NTA

[dhas...@fvrl.org]

Hi, folks.

Well, after much trial and error (even defining serial port speeds, etc) nothing seems to work in getting rigctld to close the PTT line via ttyS0 (COM1).  I've tried everything that Martin and Erlend suggested, but no luck.  As I mainly use ICOM radios, I think Erlend's suggestion of building a simple CI-V, TTL-level cable, one with the FDTI converter chip already in the housing of the USB connector, may be the low-cost way to go.  Not as low-cost as a single transistor switch on the RS-232 port, but what is?!?  :^)

Should someone come up with a solution to triggering the PTT line without full rig control cabling, I would welcome any info.

Very 73,
Dave
K7CCC

On Monday, June 6, 2016 at 9:18:48 AM UTC+1, LA5NTA wrote:

Hi again Dave,

thank you for re-posting on this list :)

[Martin Hebnes Pedersen]

On 07/06/16 21:14, dhas...@fvrl.org wrote:

Hi, folks.

Well, after much trial and error (even defining serial port speeds, etc) nothing seems to work in getting rigctld to close the PTT line via ttyS0 (COM1).  I've tried everything that Martin and Erlend suggested, but no luck.  As I mainly use ICOM radios, I think Erlend's suggestion of building a simple CI-V, TTL-level cable, one with the FDTI converter chip already in the housing of the USB connector, may be the low-cost way to go.  Not as low-cost as a single transistor switch on the RS-232 port, but what is?!?  :^)

Should someone come up with a solution to triggering the PTT line without full rig control cabling, I would welcome any info.

Hi again Dave,

my best bet is that the rigctld command line arguments need tuning. Maybe you could get something useful out of this thread: https://sourceforge.net/p/hamlib/mailman/message/30663804/ ? I notice that they use --rig-file in addition to --ptt-type="RTS".

To simplify the testing, I would use rigctl (notice the missing "d") to test various configurations. I.e. rigctl -m 1 --ptt-type RTS --rig-file /dev/ttyS0 T 1 (to send PTT ON command to the rig). This eliminates potential issues with Pat configuration and all the socket communication in between. When you get your rig to PTT with rigctl, then try the same configuration with rigctld and Pat.

--
Regards,
Martin

[dhas...@fvrl.org]

Hello, Everyone.

Another success, and another setback.

Using rigctl, I was able to trigger the PTT line with my simple one-transister switch with this: rigctl -v --model=1 --rig-file="/dev/ttyS0" --set-conf="ptt_type"="RTS" --set-conf="ptt_pathname"="/dev/ttyS0"  When prompted for a command, I entered T, then a 1 to close the PTT circuit and a 0 to open it.  Worked FB .... manually, with me entering commands from the keyboard.  I have no idea why the serial device has to be defined twice, other than once for the rig as a whole, and a second time for the PTT line, specifically.

Unfortunately, the same commands cannot be said to work with ridctld.  The same string of commands and options did nothing to trigger the PTT circuit of the radio.  WINMOR modem appears to be working fine with Pat, as there's plenty of sound going out of the soundcard.  The only problem is no PTT control.  Again, here are the relevant portions of my config.json file:

  "hamlib_rigs": {
    "dummy": {"address": "localhost:4532", "network": "tcp"}

 "winmor": {
    "addr": "localhost:8500",
    "inbound_bandwidth": 1600,
    "rig": "dummy",

    "ptt_ctrl": true
  },

All I can say at this point is that it should work.  Yet, I'm obviously still missing something here.

Best regards, Dave

[Martin Hebnes Pedersen]

Dave,

you should be seeing a log line from Pat indicating the status of the rigctld connection. Could you do a "pat connect ..." and attach the content of ~/.wl2k/pat.log?

Also, if you run rigctld with -vvvvv, rigctld will log every command received. rigctl -vvvvv --model=1 --rig-file="/dev/ttyS0" --set-conf="ptt_type"="RTS" --set-conf="ptt_pathname"="/dev/ttyS0" gave me this output:
rigctl(d): T 'currVFO' '1' '' ''
rigctl(d): T 'currVFO' '0' '' ''
rigctl(d): T 'currVFO' '1' '' ''
rigctl(d): T 'currVFO' '0' '' ''
rigctl(d): T 'currVFO' '1' '' ''
rigctl(d): T 'currVFO' '0' '' ''

As you can see, the PTT commands sent from Pat are in fact received and processed by rigctld. Unfortunately, I do not have the hardware to confirm that the RTS line toggles.

Your config looks fine, but hopefully the -vvvvv can help narrow down the problem to either Pat or rigctld.

--
Regards,
Martin.

On 11/06/16 08:00, dhas...@fvrl.org wrote:

[Erlend Grimseid]

Hi all.

This worked for me.

erlend@erlend-tough:~$ rigctld -vvvvv --model=1 --rig-file="/dev/ttyS0" --set-conf="ptt_type"="RTS" --set-conf="ptt_pathname"="/dev/ttyS0"
"

My conf file for reference

{
  "mycall": "LA4TTA",
  "secure_login_password": "SUPER SECRET PASSWORD",
  "auxiliary_addresses": [],
  "locator": "JP20RE",
  "http_addr": ":8080",

  "motd": [
    "Open source Winlink client - getpat.io"
  ],
  "connect_aliases": {
    "telnet": "telnet://{mycall}:CMST...@server.winlink.org:8772/wl2k"
  },
  "listen": [],

  "hamlib_rigs": {
    "kx3": {"address": "localhost:4532", "network": "tcp"}

  },
  "ax25": {
    "port": "wl2k",
    "beacon": {
      "every": 3600,
      "message": "Winlink P2P",
      "destination": "IDENT"
    },

    "rig": "kx3"
  },
  "serial-tnc": {
    "path": "sm0",
    "baudrate": 4800,
    "type": "sound modem"
  },

  "winmor": {
    "addr": "localhost:8500",
    "inbound_bandwidth": 1600,

    "rig": "kx3",
    "ptt_ctrl": true

  },
  "ardop": {
    "addr": "localhost:8515",
    "arq_bandwidth": {
      "Forced": false,
      "Max": 500
     },

    "rig": "kx3",

    "ptt_ctrl": false,
    "beacon_interval": 0,
    "cwid_enabled": true
  },
  "telnet": {
    "listen_addr": ":8774",
    "password": ""
  },
  "gpsd_addr": "localhost:2947",
  "schedule": null
}

I notice that rigctl also holds the DTR line high using this string. Make sure your ptt circuit wont be affected by this.

You actually could use this to build an rs323 to ttl level converter to control your icom rig from the same serial port.


73

Erlend

--
You received this message because you are subscribed to a topic in the Google Groups "pat-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pat-users/gofrbmvLP6Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pat-users+...@googlegroups.com.
To post to this group, send email to pat-...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/pat-users/575BC883.2090209%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

[dhas...@fvrl.org]

Hello Erlend, Martin, and the group.

Success, gentlemen!  And thanks for all your help.  For some strange reason, setting the -vvvvv variable in rigctld
as suggested made all the difference.  Perhaps I should have mentioned that I'm running an Ubuntu 15.10 system
(xfce desktop environ), as that might have affected things.  Anyway, there is only one difference between the rigctl
test of the PTT switch (-v) mentioned earlier in this thread and the actual working run of rigctld (-vvvvv).

Bottom line, this works for PTT-only control on the RST line with a simple one-transister switch for rigctld:

rigctld -vvvvv --model=1 --rig-file="/dev/ttyS0" --set-conf="ptt_type"="RTS" --set-conf="ptt_pathname"="/dev/ttyS0"

In the interest of maybe helping someone else facing the same problem, I offer my console outputs below for use.

A) Ran rigctld in a terminal instance, first try:

dave@Surplus:~$ rigctld -v --model=1 --rig-file="/dev/ttyS0" --set-conf="ptt_type"="RTS" --set-conf="ptt_pathname"="/dev/ttyS0"
Opened rig model 1, 'Dummy'

B) Ran pat in a second terminal instance:

dave@Surplus:~$ pat connect winmor kb6bt
2016/06/11 19:41:00 dummy ready. Dial frequency is 145.000.00 MHz.
2016/06/11 19:41:00 Connecting to WINMOR ()...
2016/06/11 19:41:00 Unable to establish connection to remote: No dialer has been registered for this scheme
dave@Surplus:~$

C) Ran rigctld in the first terminal instance with the "extra Vs":

dave@Surplus:~$ rigctld -vvvvv --model=1 --rig-file="/dev/ttyS0" --set-conf="ptt_type"="RTS" --set-conf="ptt_pathname"="/dev/ttyS0"

rigctld, Hamlib 1.2.15.3
Report bugs to <hamlib-d...@lists.sourceforge.net>

rig:rig_init called
rig: loading backend dummy
dummy: _init called
rig_register (1)
rig_register (2)
dummy_init called
rig_set_conf: ptt_type='RTS'
rig_set_conf: ptt_pathname='/dev/ttyS0'
rig:rig_open called
dummy_open called
dummy_get_vfo called: VFOA
Opened rig model 1, 'Dummy'
Backend version: 0.5, Status: Beta
Connection opened from 127.0.0.1:52720
rigctl(d): f 'currVFO' '' '' ''
dummy_get_freq called: currVFO
fscanf: Success
Connection closed from 127.0.0.1:52720    ; it didn't seem to like access from the console
Connection opened from 127.0.0.1:52724    ; but it was OK with access via HTTP
rigctl(d): f 'currVFO' '' '' ''
dummy_get_freq called: currVFO
rigctl(d): f 'currVFO' '' '' ''
dummy_get_freq called: currVFO
rigctl(d): T 'currVFO' '1' '' ''          ; PTT line closing and opening!

rigctl(d): T 'currVFO' '0' '' ''
rigctl(d): T 'currVFO' '1' '' ''
rigctl(d): T 'currVFO' '0' '' ''

   [truncated]

D) Ran Pat in the second terminal instance:

dave@Surplus:~$ pat connect winmor kb6bt
2016/06/11 19:44:25 dummy ready. Dial frequency is 145.000.00 MHz.
2016/06/11 19:44:25 Connecting to WINMOR ()...
2016/06/11 19:44:25 Unable to establish connection to remote: No dialer has been registered for this scheme

dave@Surplus:~$ pat http
2016/06/11 19:44:39 dummy ready. Dial frequency is 145.000.00 MHz.
2016/06/11 19:44:39 Starting HTTP service (localhost:8080)...
2016/06/11 19:45:19 WINMOR TNC v1.5.9.0 initialized
2016/06/11 19:45:19 Connecting to KB6BT (winmor)...
2016/06/11 19:45:57 Unable to establish connection to remote: Connect timeout

Now here's the interesting thing -- Pat, when run from the terminal, did not want to talk with the WINMOR TNC.
You can see this in the rigctld output (C) above, as well as what Pat reports.  However, when I told Pat
to run with the browser front-end, everything was fine (well, all but connecting to KB6BT on 10 meters...). 
The PTT switch operated fine and keyed the radio as expected (and I later connected on 17m just fine :^)

Thanks again, guys.  When you're next in Portland, Oregon, the beers are on me!

Dave - K7CCC

[Martin Hebnes Pedersen]

Hi Dave,

the reason you're the having trouble with connect from the command line interface is because you got the syntax wrong.
Try "pat connect winmor:///KB6BT" instead (notice the URL syntax). "pat connect --help" for more details and examples :)

Anyway, glad you got everything working! I will give you a heads up in advance when Erlend and I come to collect ;)

Don't hesitate to start a new thread if you have any feedback, comments or questions. We need more questions like this on the mailing list to make it a good source of information for Pat users.

--
73 de LA5NTA/Martin