Date   

Re: Narrow Band Emergency Messages

Sarah
 

Yes!  I'm still relatively new to NBEMS and haven't used it in an emergency yet.  But it seems tailor made for the circumstances you describe.  For example, you could be of great service to your community by being able to send NBEMS messages to provincial** authorities in charge of emergency or first responders or something like the Red Cross.  If nothing else being able to communicate the need for critical medications or provide a detailed status report could really make a difference. 

** being in the US I'm not sure how or if Canadian provinces are broken down into smaller governmental units like a US State breaks down into county governments. 


On 7/16/2018 7:44 AM, John Corby wrote:
Thanks for all the responses. It's good to know that folks are actually using NBEMS. I believe that it has a lot of potential that isn't been utilized. Most people probably think of NBEMS in terms of supporting emergency services during major disasters. But, there is another dimension to it in prepping for personal emergencies. I live in a rural area in southern Ontario that experiences frequent power outages. Often, phone (and internet) lines are down too.  After 24 hours, or thereabouts, cell service deteriorates as backup power drops. That leaves residents isolated. NBEMS has the potential to provide independent messaging, or email, capability until services are restored. This is my principal interest in the technology.


Re: Narrow Band Emergency Messages

Steve Hansen
 

I'm a bit late to this thread but we use NBEMS quite extensively in Maine. In my county all of the town stations, the county EOC and home stations are equipped to use NBEMS. We also have a local packet network and Winlink but for real time comms, especially VHF/UHF, NBEMS is fast and efficient.

We also have a NH/ME hospital net that uses NBEMS for data transmission.

73, Steve KB1TCE


On 07/16/2018 10:44 AM, John Corby wrote:
Thanks for all the responses. It's good to know that folks are actually using NBEMS. I believe that it has a lot of potential that isn't been utilized. Most people probably think of NBEMS in terms of supporting emergency services during major disasters. But, there is another dimension to it in prepping for personal emergencies. I live in a rural area in southern Ontario that experiences frequent power outages. Often, phone (and internet) lines are down too.  After 24 hours, or thereabouts, cell service deteriorates as backup power drops. That leaves residents isolated. NBEMS has the potential to provide independent messaging, or email, capability until services are restored. This is my principal interest in the technology.


Re: Narrow Band Emergency Messages

John Corby <va3kot@...>
 

Thanks for all the responses. It's good to know that folks are actually using NBEMS. I believe that it has a lot of potential that isn't been utilized. Most people probably think of NBEMS in terms of supporting emergency services during major disasters. But, there is another dimension to it in prepping for personal emergencies. I live in a rural area in southern Ontario that experiences frequent power outages. Often, phone (and internet) lines are down too.  After 24 hours, or thereabouts, cell service deteriorates as backup power drops. That leaves residents isolated. NBEMS has the potential to provide independent messaging, or email, capability until services are restored. This is my principal interest in the technology.


Re: Unable to deliver your message

Larry Levesque
 

On Sun, Jul 15, 2018 at 06:00:14AM -0400, Gilbert Kauffmann wrote:



-----Original Message-----
From: Yahoo Groups <notify@...>
To: k3cc <k3cc@...>
Sent: Sat, Jul 14, 2018 12:23 pm
Subject: Unable to deliver your message


We are unable to deliver the message from <k3cc@...>
to <nbemsham@...>.

Your message was sent to a group that does not exist. Please check
to make sure you spelled the group name correctly.

For further assistance, please visit http://help.yahoo.com/l/us/yahoo/groups/original/members/forms/general.html
Attached Message
From Gilbert Kauffmann <k3cc@...>
To NBEMSham@...
Subject re: site for custom FLdigi forms
Date Sat, 14 Jul 2018 12:23:13 -0400
would it help if we had a site were folks could save their forms for all to see ?
This would allow everyone to see FLmsg, FLAMP and other forms made and used by others.....

Just a question to help the group.....Each form could be downloaded and changed for their use

de Skip  K3CC 


--
Larry Levesque
KA1VGM


Unable to deliver your message

Gilbert Kauffmann
 




-----Original Message-----
From: Yahoo Groups <notify@...>
To: k3cc <k3cc@...>
Sent: Sat, Jul 14, 2018 12:23 pm
Subject: Unable to deliver your message


We are unable to deliver the message from <k3cc@...>
to <nbemsham@...>.

Your message was sent to a group that does not exist. Please check
to make sure you spelled the group name correctly.

For further assistance, please visit http://help.yahoo.com/l/us/yahoo/groups/original/members/forms/general.html
Attached Message
From Gilbert Kauffmann <k3cc@...>
To NBEMSham@...
Subject re: site for custom FLdigi forms
Date Sat, 14 Jul 2018 12:23:13 -0400
would it help if we had a site were folks could save their forms for all to see ?
This would allow everyone to see FLmsg, FLAMP and other forms made and used by others.....

Just a question to help the group.....Each form could be downloaded and changed for their use

de Skip  K3CC 


Re: Narrow Band Emergency Messages

Sarah
 

Ooops, forgot to mention John:  I started a Groups.io group about 6 months ago for the specific purpose of creating a place where NBEMS users could share tips, information, and experiences.  Open to all:  https://groups.io/g/22nbems

73, N6OPE


On 7/14/2018 6:55 AM, John Corby wrote:
Is anybody actually using the FL-suite to send and receive messages? I see a lot a discussion here about the software but no references to it's use for sending narrowband emergency messages. I have been quite enthusiastic about the use of NBEMS for exchanging messages - especially during power and phone line outages - but I haven't actually found anybody to exchange messages with. Is anybody else in the same situation, or is this group really a software dscussion group?

John, va3kot, EN93


Re: Narrow Band Emergency Messages

Sarah
 

Hi John:

I live in Los Angeles Co., CA and the volunteer Disaster Communication Service that's allied with the Sheriff's department does weekly net with NBEMS.  (And a second, smaller emergency comms group I belong to in my immediate, local area is resuming a second net this week.)

73, N6OPE.

On 7/14/2018 6:55 AM, John Corby wrote:
Is anybody actually using the FL-suite to send and receive messages? I see a lot a discussion here about the software but no references to it's use for sending narrowband emergency messages. I have been quite enthusiastic about the use of NBEMS for exchanging messages - especially during power and phone line outages - but I haven't actually found anybody to exchange messages with. Is anybody else in the same situation, or is this group really a software dscussion group?

John, va3kot, EN93


Re: Narrow Band Emergency Messages

Randy McGill
 

Yes, we use it all the time.  We have custom forms that we use for message traffic as well as the standard ICS, WX message forms.  We have integrated our FLmsg / FLamp files into a linked folder with ARIM/ARDOP.  Incoming / stored messages are shared between ARIM and FLmsg / FLamp.  This allows for sharing of traffic outside of the standard net times and acts as a backbone network between select stations.  Those shared NBEMS files can then be extracted from ARIM and seamlessly resent on another net using FLmsg / FLamp. 
N7WWA


Re: Narrow Band Emergency Messages

501_Andy_VE4PER <ve4per@...>
 

Are you on a linked VHF network that is tied to the Thunder Bay/Dryden/Kenora/Falcon Lake system that links into MB MRS system by any chance?


On 2018-07-14 10:49 AM, Jeff Ronner wrote:
We have a weekly NBEMS net on a VHF repeater where we originate and receive practice messages.

On Jul 14, 2018 09:55, "John Corby" <va3kot@...> wrote:
Is anybody actually using the FL-suite to send and receive messages? I see a lot a discussion here about the software but no references to it's use for sending narrowband emergency messages. I have been quite enthusiastic about the use of NBEMS for exchanging messages - especially during power and phone line outages - but I haven't actually found anybody to exchange messages with. Is anybody else in the same situation, or is this group really a software dscussion group?

John, va3kot, EN93



Re: Narrow Band Emergency Messages

501_Andy_VE4PER <ve4per@...>
 

Hello John,

I have been able to set up and use the suite here and with help of some cooperative emcomm hams in USA managed to create a few useful forms to use locally here for practice. I have a home network and use separate machines to send msgs back and forth to prove they work properly.

I ,like yourself,  have found local hams here reluctant to try both Linux and Windows and/or  the FL suite. The few that are not generally apathetic are more involved in MARS/CFARS  ALE products which include encryption and use ACP MIL Spec type messaging that is not built into the FL suite generally.

I was a RAC EC locally for about a year here in EN09 and on a number of occasions designed and sent practice forms to other EC's to see if they could generate enough participation in their areas to maybe set up local practice exchanges on say 80M nets but got no response back to those efforts either.

I offered to install and clone Linux systems onto thumb drives for them also but was never asked to do so by anyone. I find linux far more challenging than a crossword or sudoko to keep the aging old grey matter elastic. And being senior $$$ savings are immense when it comes to finding software free of the cloud and crazy subscription fees or seat licenses for programs.

There is a bit of a learning curve associated with Linux so many are overwhelmed and just close their ears and put on blinders to prevent having to learn a new OS like linux. In so doing the advantages of having a system that can fully function using just a 64 or 128 GB thumb drive on almost any hardware easily anywhere is lost.

It also has the advantage when developers set up installs of custom ham programs as an example using ppe's that all components and programs are deemed part of the OS install system are updated at the same time and quickly usually.

On updates it usually lists all the components with file sizes and allows you an option to exclude something that might compromise an emcomm program you need to be reliable.

You don't spend endless hours installing and re-installing updates piecemeal only to have an auto windows update delete some needed library file on you. YOU control the timing of installing updates and don't have to worry about $600 extra data overage charges because an auto update was corrupt and kept trying to re-download and reinstall every day on you.

In the ALE world hopes were up to use the TI ez USB sound card because it was expandable, however that idea has been quashed because TI just out of the blue jacked the price up from $99 to well over $250 a cost average hams find objectionable even though they may be civic minded enough to offer their resources in EMER situations.

In short John if we had a net locally here under present propagation condx I would be into it here easily.

73

Andy, ve4per, EN09


On 2018-07-14 08:55 AM, John Corby wrote:
Is anybody actually using the FL-suite to send and receive messages? I see a lot a discussion here about the software but no references to it's use for sending narrowband emergency messages. I have been quite enthusiastic about the use of NBEMS for exchanging messages - especially during power and phone line outages - but I haven't actually found anybody to exchange messages with. Is anybody else in the same situation, or is this group really a software dscussion group?

John, va3kot, EN93


Re: Narrow Band Emergency Messages

Jeff Ronner
 

We have a weekly NBEMS net on a VHF repeater where we originate and receive practice messages.

On Jul 14, 2018 09:55, "John Corby" <va3kot@...> wrote:
Is anybody actually using the FL-suite to send and receive messages? I see a lot a discussion here about the software but no references to it's use for sending narrowband emergency messages. I have been quite enthusiastic about the use of NBEMS for exchanging messages - especially during power and phone line outages - but I haven't actually found anybody to exchange messages with. Is anybody else in the same situation, or is this group really a software dscussion group?

John, va3kot, EN93



Re: Narrow Band Emergency Messages

Marty Hartwell
 

Hi John

At time I see discussion of problems related to testing of the systems
and discussion of areas of the country where they are used. Like here
in Middle Tennessee our served agencies don't or aren't at the moment
using tools like Flmesg and it's associated tools to send filled out
forms. However I think if more of the operators were to demo them and
show what can be done there might be more demand. I think if more ops'
were to get some training tools to become more proficient with them to
show what could be done, which means that we as ARES ops' need to learn
on our own and show the heads of county EMA what power there is there
we may be able to get some head way.

I am starting to get my FEMA requirements out of the way first then start on this next agenda item.

Marty kd8bj

On 07/14/2018 08:55 AM, John Corby wrote:
Is anybody actually using the FL-suite to send and receive messages? I see a lot a discussion here about the software but no references to it's use for sending narrowband emergency messages. I have been quite enthusiastic about the use of NBEMS for exchanging messages - especially during power and phone line outages - but I haven't actually found anybody to exchange messages with. Is anybody else in the same situation, or is this group really a software dscussion group?
John, va3kot, EN93


Re: Narrow Band Emergency Messages

John Higgins
 

Colorado ARES meets at 0830 MT on 2nd and 4th Sundays on 3590 Center.  Start on PSK31 then other modes as needed to exercise FLAMP and FLMSG.  We periodically move on to WinLink Express to further exercise Soundcard ops.  On our FSK Digital nets, we often use the FLMSG application to move formatted messages.

73,

John Higgins, N6VTS
719-330-0916

On Jul 14, 2018, at 08:25, W2TLJ <tjoneson@...> wrote:

The NYS RACES routinely use NBEMS FL suite to send messages as does the NYS DOH. Great product at the right price.
Tom Joneson W2TLJ

On Sat, Jul 14, 2018, 09:55 John Corby <va3kot@...> wrote:
Is anybody actually using the FL-suite to send and receive messages? I see a lot a discussion here about the software but no references to it's use for sending narrowband emergency messages. I have been quite enthusiastic about the use of NBEMS for exchanging messages - especially during power and phone line outages - but I haven't actually found anybody to exchange messages with. Is anybody else in the same situation, or is this group really a software dscussion group?

John, va3kot, EN93


Re: Narrow Band Emergency Messages

W2TLJ
 

The NYS RACES routinely use NBEMS FL suite to send messages as does the NYS DOH. Great product at the right price.
Tom Joneson W2TLJ

On Sat, Jul 14, 2018, 09:55 John Corby <va3kot@...> wrote:
Is anybody actually using the FL-suite to send and receive messages? I see a lot a discussion here about the software but no references to it's use for sending narrowband emergency messages. I have been quite enthusiastic about the use of NBEMS for exchanging messages - especially during power and phone line outages - but I haven't actually found anybody to exchange messages with. Is anybody else in the same situation, or is this group really a software dscussion group?

John, va3kot, EN93


Re: Narrow Band Emergency Messages

George Blakeslee
 

John

The New Hampshire ARES digital net meets Saturday mornings at 1130 UTC on 3582 KHz with 1500 offset.
We start out with BPSK125.
Practice FLmsg and FLamp Messages are generally exchanged with THOR50x1 or MFSK32.
You are welcome to check in.

73  GB

On Sat, Jul 14, 2018 at 9:55 AM, John Corby <va3kot@...> wrote:
Is anybody actually using the FL-suite to send and receive messages? I see a lot a discussion here about the software but no references to it's use for sending narrowband emergency messages. I have been quite enthusiastic about the use of NBEMS for exchanging messages - especially during power and phone line outages - but I haven't actually found anybody to exchange messages with. Is anybody else in the same situation, or is this group really a software dscussion group?

John, va3kot, EN93




--
George Blakeslee


Narrow Band Emergency Messages

John Corby <va3kot@...>
 

Is anybody actually using the FL-suite to send and receive messages? I see a lot a discussion here about the software but no references to it's use for sending narrowband emergency messages. I have been quite enthusiastic about the use of NBEMS for exchanging messages - especially during power and phone line outages - but I haven't actually found anybody to exchange messages with. Is anybody else in the same situation, or is this group really a software dscussion group?

John, va3kot, EN93


flrig 1.3.41.01 alpha

Dave
 

Fixes failure to connect to Icom-735 transceiver

No other changes from 1.3.40.

73, David, W1HKJ



flrig-1.3.40 posted

Dave
 

At www.w1hkj.com
and Source Forge.

Version 1.3.40 is the result of 5 months of intense coding and testing by an international team of amateurs.  Great attention was given to making the xmlrpc server compatible with programs other that fldigi and flwkey, especially WSJT-X.  WSJT-X developers were a part of the flrig development team during the entire 1.3.40 develop/test cycle.  flrig 1.3.40 has been tested on several Linux distributions, OS X i386 and G4 processors, MacOS (latest version), and Windows 7 and 10. 

73, David, W1HKJ

Version 1.3.40

  * Maintenance release

  FT950 comp
    * removed speech equalizer switching
      - compression level always sent when changed
      - compression on/off state always sent when
        changes in state or comp level

  COMport NONE testing
    * allow testing all functions when NONE selected

  slider drag
    * change coding to improve responsiveness
      - separate UI from serial send
      - push UI slider changes to slider queue
      - process slider queue in serial thread

  KENWOOD vfoA/B split
    * Change VFO A/B, SPLIT operation to be identical to transceiver front panel operation

  IC PBT controls
    * Add read Passband Tuning controls

  Send Command
    * add waitResponse

  Yaesu mods
    * corrected FT5000 mode table entries
    * modified FT5000 SWR table conversion
    * change waitN to wait_char
      added trace statements
      added bandwidth by vfo/mode
      - FT450
      - FT450D
      - FT950
      - FT2000
      - FTdx1200
      - FTdx3000
      - FT5000
      - FTdx9000
    * modified FT5000 Pwr table conversion

  tt550
    * add trace statements to 550 backend
    * add missing tt550_enable_keyer boolean to prefs file.  default to false.

  Test Xcvr
    * Separate all xcvr set/get from UI initialization
    * Add check() to all xcvr back ends
      - test for get_vfoA, fail if no response

  modeA modeB
    * Correct xmlrpc methods for set_modeA, set_modeB
      when transceiver can modify alternate vfo parameters - IC7300

  Documentation
    * revise documentation to current version

  FT1000 update
    * AM mode filter code changes

  UI init
    * fix drop down resizing on Windows
    * add more points to progress during init
    * change "Tune" button label to "Tuner"
      - change hint to "Enable Auto Tune"

  ICOM transceivers
    * Additional code to support main/sub transceiver paradigm for swapping main / sub vfos
    * Add controls for Icom Inner/Outer PBT
      - allow locking controls for IF shift
    * Add Filter select to bandwidth selector
      - e.g. Wide/Medium/Narrow for IC7200
    * Add between execution memory for bandwidth and filter selection by vfo by mode
    * Add read/restore of filters in use for vfoA / vfoB
    * enabled vfo adjust for IC7300
    * calibrated IC7300 power and swr tables
    * add xmlrpc methods to get / set modeA modeB
    * corrected IC73000 mode_bw tables
    * correct default start up freq, mode, bw for various models

  xml_server
    * add get vfo A/B mode
    * add get vfo A/B bw
    * add send command type of string processing to xmlrpc server
    * Change widget used to display xml-help

  trace update
    * Add separate status item for trace on/off
    * Add configuration tab for debugging
    * change all occurrences to use the trace output file
    * add all debug statements to trace log
    * add trace statements to xmlrpcpp lib

  guard lock
    * Change trace number to trace string

  KENWOOD base
    * Add base rig class for KENWOOD transceivers

  Trace
    * separate trace file generation by
      - RIG_DEBUG 0 - no trace; default
      - RIG_DEBUG 1 - trace level 1 xcvr methods
      - RIG_DEBUG 2 - trace all xcvr methods
      - XML_DEBUG 0 - no trace of xmlrpc methods; default
      - XML_DEBUG 1 - trace xmlrpc methods

  ts2000 get split
    * Change to read P12 in IF; response

  TOD thread
    * Remove TOD thread and all support code

  PTT on split

  TS2000 split
    * remove Fl::awake(...) call from TS480HX/SAT, TS590S/SG, TS2000

  TS series A2B
    * execute active to inactive for all xcvrs whose
      command set does not include a native copy vfo

  Send command
    * Change guard_lock mutex for send command

  ICOM A/B vfo handling
    * IC7300
      get set for freq/mode/filter changed to use x25 x26 CAT sequences.
      A/B FIL # will always be same as set at xcvr
    * IC7200
      copy active to inactive did not change the displayed vfoB frequency.
    * removed all special handling for swapping vfos in Icom transceivers
      - use Icom generic swapAB
      - exception IC7300, add read FIL A/B after swap
    * Add specific B0/B1 commands for 756PRO series

  xmlrpc split/swap/a2b
    * change split/swap/a2b processing to service queue management

  fix tod clock
    * Thanks Mike, W9MDB
      - change ztimer to use tv.usec for sub second timing

  TS480
    * Add front panel beep disable to 480HX and 480SAT

  PTT queue
    * combine vfoque and ptt queue into single fifo processor
    * replace multiple mutex with single

  sizeof errors
    * correct use of sizeof array in various source files

  XMLRPC Select Vfo
    * Add processing delay after every call to select vfo
      - fixed 200 msec

  xmlrpc server
    * add rig.set_bandwidth method to xmlrpc server
      - valid if xcvr can set bandwidth, bandwidth / shift
      - not valid if xcvr set to use high / low pass values
    * change paradigm for servicing vfo A/B change requests
      - single queue for both A and B requests
      - all service requests handled by single queue processor
        with the exceptionof PTT.
      - queue handles interlaced A/B, UI, and xmlrpc requests
    * force get and set to wait for vfoque servicing to complete
    * fix cbA2B (copy active to inactive vfo)

  TS480HX/SAT
    * Copy working methods from 480SAT
    * Update power scale and conversion

  Conditional trace
    * trace output conditional upon command line parameter RIG_DEBUG
    * remove specific RIG_DEBUG = true statements from transceiver class methods

  Warnings fixes
    * Fix various reported compile warnings

  FT950 debug
    * Added trace calls to class methods

  FT891 mods
    * Added trace statements to FT891 class methods
    * Modify code to comply with latest pdf CAT reference manual.

  Icom updates
    * Add trace statements to Icom class methods
      - removed civ debug log
    * IC7300
      - Bug fix in set bandwidth methods
      - add compile directive for alternate vfo methods
    * corrected bwtable method in various icom xcvr class
    * extended tod clock to 10 usec precision

  Load prefs file
    * Load existing prefs file when changing xcvrs
    * Provide button to refresh the combo listing of serial ports

  Exit processing
    * correct debug seg fault during exit processing
    * move all exit processing to main thread
    * add Fl::check() to force UI update during
      transceiver restore

  Vfo-B mode
    * Correct method get_modeB in TT588.cxx
    * Correct method get_modeB in IC7300.cxx
    * Always set useB flag with selectA / selectB

  appbundle
    * fix app version string

  Init no split
    * Disable split on transceiver intitialization

  xmlrpc method swap
    * correct calling method
      - was rig.set_swap
      - add rig.swap

  FT series vfo
    * Change FT series class methods for set/get vfo

  altvfo
    * add code to set and read alternate vfo freq IC7300
      - command code 0x25
    * use rig data vfo initialize failed to
      correctly read start up values
    * Modify code to copy freq, mode and bandwidth A->B
    * Change all Icom class vfo set/get methods
    * Change A=B behavior; active vfo --> inactive vfo
      independent of whether A or B is active.  This
      behavior emulates the Icom series of transceivers.

  ptt race / debug trace
    * make trace(...) conditional
    * fix ptt race condition

  Service queues
    * change queue servicing to execute all pending
      service requests rather than just the final

  replystr mutex
    * change replystr to rigbase element
    * add mutex to guard replystr contents

  xmlrpc a/b vfo
    * expose new xmlrpc methods
      - rig.set_vfoA
      - rig.set_vfoB
      - rig.get_vfoA
      - rig.get_vfoB
    * changed A/B state change queue processing
    * Add ability to QSY during Tx for transceivers
      - allow user to disable for transceivers which do not support that capability

  ICbase
    * Condition wait for FB dependent on echo_comm on/off

  Split operation
    * Implement a fake split operation for all transceivers not
      supporting split natively
     * TS2000 change get_split to return boolean

  TT588
    * Correct CAT string for split

  xmlrpc help
    * add --xmlrpc-help
      - prints xmlrpc interface to cout
    * add rig.set_frequency
      identical to main.set_frequency
    * Create a substitute read-only text dialog for Windows
      users to access command line output

  xmlrpc swap/split
    * expose vfo set swap to xmlrpc interface
    * expose set/get split to xmlrpc interface

  Yaesu ID
    * Change back ends for Yaesu transceivers
      - add ID; query before every change request
        to insure that transceiver is receptive

  Mode change
    * Fix seg fault in xml_server
      - occurred for specific mode changes when bandwidth selection is maximum value


flmsg 4.0.7 posted

Dave
 

At www.w1hkj.com

and at Source Forge

Source Forge git repository MASTER branch also updated to 4.0.7.

Version 4.0.7

  * maintenance release

custom fields

  * added HTML-5 telephone field to custom.cxx
  * added HTML-t email field to custom.cxx
  * limit upper case field conversions to within the bounds of <body ... </body

RRI radiogram

  * Add templates for Radio Relay International templates
  * Add user configuration item to select RRI

CSV view seg fault

  * fix bug caused by missing \n on last line of csv text

Autosend seg fault

  * Fix seg fault if user presses Autosend with no form selected

Thumb drive

  * Change FL_APPS recognition to work correctly from within a Windows batch file

73, David, W1HKJ



Re: Configure TS-450S for Fldigi

Dave
 

You're welcome Lawrence, and glad that you discovered the needed fix.  You are 4 years more advanced in age than I.  I hope to still be developing software when, Lord willing, I reach 84.

Dave

On 06/30/2018 11:01 AM, Lawrence Moore wrote:
Thanks, Dave, for reminding me a smart operator reads the help files. I had missed the check box Enable flrig xcvr control with fldigi as client.

I have been claiming 83 years old and a little senile but sometimes I think I am just stupid. HI HI

Lawrence, AD5O