NG7M / 2 Videos on FSK RTTY timings generated with EXTFSK/64 on new and older PC's via USB FTDI Com Ports

[ng7m]

Joe, your 2010 data (which you haven't looked up and provided, but I assume
exists? from 8 years ago) isn't a good comparison to changes at the OS, CPU
/ hardware level between 2010 and 2018.  You are very good at telling
everyone the way things are, but not very good at showing folks the way
things are / work with actual experiments and data / video.

This exercise isn't productive until you actually watch all of my content
and start reproducing my results on a scope etc... If you are not willing
to do that in 2018 with your own equipment and continue to rely on
microHam's numbers from 2010... (or someone else's data) There is no point
to the discussion.  A lot has changed since 2010.  Plus I made it crystal
clear in my video that my main computer setup is much faster than most
other Ham shack computers at the moment (2018). You act like I expected
everyone to have the same setup... which clearly shows that you cherry
picked sections out of the video to confirm your preconceived conclusions
before every clicking on the video links.  You insist on leaving out all
the detail provided in the Video, because it can't be conveyed via a few
paragraphs of text in an email.

As usual, (which is well known), you will get the last word in... Until you
produce something new for 2018, a response from myself isn't productive at
all.  And will not take place.  For now I'll let my video speak to the
experiment and 2018 current state of what I recorded.  As I do other tests
and present other findings, I will be willing to change my
understanding/conjecture/opinion based on data collected and presented.

In the 2017 CQWWRTTY contest (using a 5 year old Ivy Bridge i7 Intel cpu)
with my K3S / internal FSK keyed by the same FTDI serial interface in my
video presented this last week, I'm shocked I was able to work 1285 QSO's
and 184 band countries.  My FSK generated signal on the other end of the
QSO's must have been horrible with this setup (jitter all over the place
I'm sure).

        Band     QSOs     Pts  ZN   Cty  SP   Pt/Q
         3.5      62      74    8    6   30   1.2
           7     338     599   27   58   50   1.8
          14     689    1519   31   84   50   2.2
          21     194     370   23   34   37   1.9
          28       2       4    2    2    1   2.0
       Total    1285    2566   91  184  168   2.0

            Score : 1,136,738

I look forward to your updated data and visuals / video using data gathered
from 2018.  That will be very interesting indeed.

73 de Max NG7M


>W4TV:
​Unfortunately, your first video is completely unrealistic as the vast
majority of amateurs uses computers significantly less powerful than
your lightly loaded (less than 40% CPU utilization by your own video)
six core, 3+ GHz CPU with the EXTFSK port on a dedicated motherboard
USB port with no loading from multiple (high priority) sound cards
(they are on a different USB Root Hub) and no contest level cluster
spots.

From my customer support support experience, the typical amateur station
is a 2-2.4 GHz Core2Duo (two cores, 4 execution units) with 1 GB RAM and
all USB ports (typically 4) served by a single USB Root Hub.  The system
typically runs a logging program that polls one or two transceivers for
eight parameters every 50 to 100 msec along with one or two 96 or 192
KHz sample rate USB sound cards for a software panadapter (or
equivalent USB I/Q SDR receivers) and another 16 bit, 48 KHz sample
rate USB sound card for digital operation.  In addition, those systems
are connected to a DXCluster node with CW/RTTY Skimmer providing a
net spot flow of > 100 spots per minute.

I've provided jitter data as measured by microHAM in 2010 multiple times
on the RTTY list ... and that data has been verified by JA7UDE (author
of EXTFSK an ETFSK64) who also confirms the added jitter when the USB
system (single USB Root Hub) is loaded with heavy data transfer.  Oba's
results have also been reported on the RTTY list and are available on
his EXTFSK64 page.

73,
​

--
M. George
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

[Joe Subich, W4TV-4]

On 3/25/2018 1:25 PM, M. George wrote:
> Joe, your 2010 data (which you haven't looked up and provided, but I
> assume exists? from 8 years ago) isn't a good comparison to changes
> at the OS, CPU / hardware level between 2010 and 2018. You are very
> good at telling everyone the way things are, but not very good at
> showing folks the way things are / work with actual experiments and
> data / video.
1) I don't need to "look up" that data ... it exists in the RTTY
archives for those who haven't already seen it *and* participated in
discussions of the issues with jitter when using software generated
FSK.

2) The issue of jitter is just as important today as it was eight years
ago as it causes the same loss of signal to noise ratio as Chen takes
very great care to explain to you on the RTTY list.  Even today the
number/percentage of amateurs using liquid cooled, hex core 3 GHz i7
processors like you used for your first "demonstration" is exceedingly
small.  As I have told you multiple times, based on my support work
the average amateur system is something like an 2.4 GHz Core2Duo with
1 - 4 GB of RAM and typically a single USB Root Hub to serve CAT, CW,
FSK, digital sound card, *and* software panadapter.

*NONE* of your demonstrations showed that level of system under *FULL*
load.  Your first demonstration may have been running rig control and
software panadapter but it wasn't processing a cluster feed at contest
rates (your panadapter was clearly visible with only one or two signals
on the band) and your CPU did not exceed roughly 40% utilization.  Your
second demonstration did not include rig control, panadapter or cluster
yet by, your own measurements, had more than 10% *per bit* jitter which
is enough according to Chen to reduce SNR by several dB.

> In the 2017 CQWWRTTY contest (using a 5 year old Ivy Bridge i7 Intel
> cpu) with my K3S / internal FSK keyed by the same FTDI serial
> interface in my video presented this last week, I'm shocked I was
> able to work 1285 QSO's and 184 band countries.
You're far enough out on the advanced end of the CPU curve that you can
get away with software FSK and work plenty of strong stations.  JA7UDE
made jitter measurements <http://www.qsl.net/ja7ude/extfsk/jitter.html>
with EXTFSK64 using an Ivy Bridge i7-3770 which showed 75 baud jitter
at +/-40 uSec in a lightly loaded system, increasing to -67/+340 uSec
when the USB system was loaded by data transfer.  Oba also reported
EXTFSK on that same lightly loaded system at +/- 50 uSec (similar to
your lightly loaded liquid cooled system).

Again, jitter is not a significant issue isn't with software FSK on high
spec CPUs with light CPU loading and dedicated USB Root Hubs ... it is
the +/- 4 msec jitter that is typical on slower, dual core systems, a
single USB Root hub and heavy processor/USB loading.

You do a disservice by insisting that jitter is not a problem because
*it doesn't reach a critical level* on your high end computing
platforms.

73,

    ... Joe, W4TV


On 3/25/2018 1:25 PM, M. George wrote:

> Joe, your 2010 data (which you haven't looked up and provided, but I assume
> exists? from 8 years ago) isn't a good comparison to changes at the OS, CPU
> / hardware level between 2010 and 2018.  You are very good at telling
> everyone the way things are, but not very good at showing folks the way
> things are / work with actual experiments and data / video.
>
> This exercise isn't productive until you actually watch all of my content
> and start reproducing my results on a scope etc... If you are not willing
> to do that in 2018 with your own equipment and continue to rely on
> microHam's numbers from 2010... (or someone else's data) There is no point
> to the discussion.  A lot has changed since 2010.  Plus I made it crystal
> clear in my video that my main computer setup is much faster than most
> other Ham shack computers at the moment (2018). You act like I expected
> everyone to have the same setup... which clearly shows that you cherry
> picked sections out of the video to confirm your preconceived conclusions
> before every clicking on the video links.  You insist on leaving out all
> the detail provided in the Video, because it can't be conveyed via a few
> paragraphs of text in an email.
>
> As usual, (which is well known), you will get the last word in... Until you
> produce something new for 2018, a response from myself isn't productive at
> all.  And will not take place.  For now I'll let my video speak to the
> experiment and 2018 current state of what I recorded.  As I do other tests
> and present other findings, I will be willing to change my
> understanding/conjecture/opinion based on data collected and presented.
>
> In the 2017 CQWWRTTY contest (using a 5 year old Ivy Bridge i7 Intel cpu)
> with my K3S / internal FSK keyed by the same FTDI serial interface in my
> video presented this last week, I'm shocked I was able to work 1285 QSO's
> and 184 band countries.  My FSK generated signal on the other end of the
> QSO's must have been horrible with this setup (jitter all over the place
> I'm sure).
>
>          Band     QSOs     Pts  ZN   Cty  SP   Pt/Q
>           3.5      62      74    8    6   30   1.2
>             7     338     599   27   58   50   1.8
>            14     689    1519   31   84   50   2.2
>            21     194     370   23   34   37   1.9
>            28       2       4    2    2    1   2.0
>         Total    1285    2566   91  184  168   2.0
>
>              Score : 1,136,738
>
> I look forward to your updated data and visuals / video using data gathered
> from 2018.  That will be very interesting indeed.
>
> 73 de Max NG7M
>
>
>> W4TV:
> ​Unfortunately, your first video is completely unrealistic as the vast
> majority of amateurs uses computers significantly less powerful than
> your lightly loaded (less than 40% CPU utilization by your own video)
> six core, 3+ GHz CPU with the EXTFSK port on a dedicated motherboard
> USB port with no loading from multiple (high priority) sound cards
> (they are on a different USB Root Hub) and no contest level cluster
> spots.
>
>  From my customer support support experience, the typical amateur station
> is a 2-2.4 GHz Core2Duo (two cores, 4 execution units) with 1 GB RAM and
> all USB ports (typically 4) served by a single USB Root Hub.  The system
> typically runs a logging program that polls one or two transceivers for
> eight parameters every 50 to 100 msec along with one or two 96 or 192
> KHz sample rate USB sound cards for a software panadapter (or
> equivalent USB I/Q SDR receivers) and another 16 bit, 48 KHz sample
> rate USB sound card for digital operation.  In addition, those systems
> are connected to a DXCluster node with CW/RTTY Skimmer providing a
> net spot flow of > 100 spots per minute.
>
> I've provided jitter data as measured by microHAM in 2010 multiple times
> on the RTTY list ... and that data has been verified by JA7UDE (author
> of EXTFSK an ETFSK64) who also confirms the added jitter when the USB
> system (single USB Root Hub) is loaded with heavy data transfer.  Oba's
> results have also been reported on the RTTY list and are available on
> his EXTFSK64 page.
>
> 73,
> ​
>

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

[Rick WA6NHC-2]

On 3/25/2018 12:15 PM, Joe Subich, W4TV wrote:

>
> Even today the number/percentage of amateurs using liquid cooled, hex
> core 3 GHz i7
> processors like you used for your first "demonstration" is exceedingly
> small.  As I have told you multiple times, based on my support work
> the average amateur system is something like an 2.4 GHz Core2Duo with
> 1 - 4 GB of RAM and typically a single USB Root Hub to serve CAT, CW,
> FSK, digital sound card, *and* software panadapter.
>
> *NONE* of your demonstrations showed that level of system under *FULL*
> load.  Your first demonstration may have been running rig control and
> software panadapter but it wasn't processing a cluster feed at contest
> rates (your panadapter was clearly visible with only one or two signals
> on the band) and your CPU did not exceed roughly 40% utilization. Your
> second demonstration did not include rig control, panadapter or cluster
> yet by, your own measurements, had more than 10% *per bit* jitter which
> is enough according to Chen to reduce SNR by several dB.

Joe, I suspect you're selling the ham community short.  While 'thrifty'
(ok, most hams are just plain cheap but it IS a hobby in a world of life
issues) there is a LOT of computing power available in the used market. 
One can pick up an I-5/6/7 for a pittance and memory is dirt cheap.

I guess I'm on the bleeding edge for once.  A couple years ago I
assembled a system specifically FOR the station; it's wasn't free but it
also didn't break the bank.  It's a 4 GHz (slightly overclocked to 4.3
GHz and air cooled) I-7 with 32 GB of ram and the C: drive is a 520 GB
SSD M3 chip mounted on the mboard (multiple data paths).

NOTHING slows it down (although Windows tries), as intended.  I've only
found one ham program that actually causes load levels to rise but it's
short duration and never maxed out.  It wasn't a repurposed system, it
was created to last a long time.  Not even Photoshop causes a stutter
(and that is a demanding suite of software).

It also captures weather data, produces a live wx web page, collects
images from 4 critters cams and puts that on another live video web
page, along with the usual mundane tasks like email and browsing. (What
I DO need is fast Internet but I didn't move to North Idaho for the
Internet ;-) )

I use 'real' serial ports, not USB for station control and FSK data. 
It's all in the details.  I've had poor performance from USB not from
path overload but because it's sensitive to RFI at the worst moments;
serial is more bullet proof.

So I agree Joe, as often as you're spot on, that your data may be a bit
dated on this topic.  I'm positive I'm not the only one using more than
a dual core CPU in the station as most of the software these days (if
not the OS) requires better performance.  A dual core for ham stations
these days is self-flagellation.  My only use for one is to play music
into the home theater, Skype with the family gathered or stream web
based video on the large flat screen.  Every tool has a use but the days
of dual core for stations are long over.

Jitter is a documentable problem, it exists for a variety of reasons
(not always the path used to transfer data), some of which are not
resolvable unless taken to extreme measures.  In severe cases, a move to
AFSK is an acceptable alternative and easily managed.

Let's move on and end this thread please.

Rick nhc

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

[Jim Brown-10]

On 3/25/2018 1:37 PM, Rick WA6NHC wrote:
> Joe, I suspect you're selling the ham community short.  While
> 'thrifty' (ok, most hams are just plain cheap but it IS a hobby in a
> world of life issues) there is a LOT of computing power available in
> the used market.  One can pick up an I-5/6/7 for a pittance and memory
> is dirt cheap.

Hi Rick,

Since Joe is the guy who answers customer support calls for the line of
products he distributes, I suspect that he may have a much more
realistic read on the computer power used by hams and how
"computer-savvy" we are. And I also suspect it's a fairly wide range in
both.

For years, I got away with 8-10 year old top-quality laptops (retired
from my small consulting biz) in my ham station, and to run SO2R RTTY, I
dedicated one to each radio. A few years ago, I bought a modern biz
laptop with a fast i7, and ever since I've run both radios from it. I
found that I DID need to add RAM to allow full bandwidth decodes of MSK144.

73, Jim K9YC


______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

[Joe Subich, W4TV-4]

On 3/25/2018 4:37 PM, Rick WA6NHC wrote:

> So I agree Joe, as often as you're spot on, that your data may be a
> bit dated on this topic. I'm positive I'm not the only one using more
> than a dual core CPU in the station as most of the software these
> days (if not the OS) requires better performance. A dual core for ham
> stations these days is self-flagellation.
Rick, A dual core system for amateur use may be self-flagellation but I
receive customer support e-mail on a regular basis from users with that
level of system or even Celeron and Atom based systems.  The point is
that those low end systems *are* in regular use and one can't make
blanket statements that EXTFSK is no problem based on a few scope
pictures made with a six core, 5 GHz clock CPU.

> Jitter is a documentable problem, it exists for a variety of reasons
> (not always the path used to transfer data), some of which are not
> resolvable unless taken to extreme measures. In severe cases, a move
> to AFSK is an acceptable alternative and easily managed.

Yes, proper choice of environment (minimizing the number of processes)
can make less capable CPUs usable.  However, that generally means using
AFSK instead of EXTFSK as well as being judicious with other issues
(like software panadapters and limiting spot rates).

73,

    ... Joe, W4TV


On 3/25/2018 4:37 PM, Rick WA6NHC wrote:

>
>
> On 3/25/2018 12:15 PM, Joe Subich, W4TV wrote:
>>
>> Even today the number/percentage of amateurs using liquid cooled, hex
>> core 3 GHz i7
>> processors like you used for your first "demonstration" is exceedingly
>> small.  As I have told you multiple times, based on my support work
>> the average amateur system is something like an 2.4 GHz Core2Duo with
>> 1 - 4 GB of RAM and typically a single USB Root Hub to serve CAT, CW,
>> FSK, digital sound card, *and* software panadapter.
>>
>> *NONE* of your demonstrations showed that level of system under *FULL*
>> load.  Your first demonstration may have been running rig control and
>> software panadapter but it wasn't processing a cluster feed at contest
>> rates (your panadapter was clearly visible with only one or two signals
>> on the band) and your CPU did not exceed roughly 40% utilization. Your
>> second demonstration did not include rig control, panadapter or cluster
>> yet by, your own measurements, had more than 10% *per bit* jitter which
>> is enough according to Chen to reduce SNR by several dB.
>
> Joe, I suspect you're selling the ham community short.  While 'thrifty'
> (ok, most hams are just plain cheap but it IS a hobby in a world of life
> issues) there is a LOT of computing power available in the used market.
> One can pick up an I-5/6/7 for a pittance and memory is dirt cheap.
>
> I guess I'm on the bleeding edge for once.  A couple years ago I
> assembled a system specifically FOR the station; it's wasn't free but it
> also didn't break the bank.  It's a 4 GHz (slightly overclocked to 4.3
> GHz and air cooled) I-7 with 32 GB of ram and the C: drive is a 520 GB
> SSD M3 chip mounted on the mboard (multiple data paths).
>
> NOTHING slows it down (although Windows tries), as intended.  I've only
> found one ham program that actually causes load levels to rise but it's
> short duration and never maxed out.  It wasn't a repurposed system, it
> was created to last a long time.  Not even Photoshop causes a stutter
> (and that is a demanding suite of software).
>
> It also captures weather data, produces a live wx web page, collects
> images from 4 critters cams and puts that on another live video web
> page, along with the usual mundane tasks like email and browsing. (What
> I DO need is fast Internet but I didn't move to North Idaho for the
> Internet ;-) )
>
> I use 'real' serial ports, not USB for station control and FSK data.
> It's all in the details.  I've had poor performance from USB not from
> path overload but because it's sensitive to RFI at the worst moments;
> serial is more bullet proof.
>
> So I agree Joe, as often as you're spot on, that your data may be a bit
> dated on this topic.  I'm positive I'm not the only one using more than
> a dual core CPU in the station as most of the software these days (if
> not the OS) requires better performance.  A dual core for ham stations
> these days is self-flagellation.  My only use for one is to play music
> into the home theater, Skype with the family gathered or stream web
> based video on the large flat screen.  Every tool has a use but the days
> of dual core for stations are long over.
>
> Jitter is a documentable problem, it exists for a variety of reasons
> (not always the path used to transfer data), some of which are not
> resolvable unless taken to extreme measures.  In severe cases, a move to
> AFSK is an acceptable alternative and easily managed.
>
> Let's move on and end this thread please.
>
> Rick nhc
>
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

[Eric Swartz - WA6HHQ]

Folks - let's end the thread now in the interest of reducing list email overload (and argument overload) for others. Please take the it off-list.  

73,

Eric
Mooderator
elecraft.com
_..._

> On Mar 25, 2018, at 3:35 PM, Joe Subich, W4TV <[hidden email]> wrote:
>
>
>> On 3/25/2018 4:37 PM, Rick WA6NHC wrote:
>>
>> So I agree Joe, as often as you're spot on, that your data may be a
>> bit dated on this topic. I'm positive I'm not the only one using more
>> than a dual core CPU in the station as most of the software these
>> days (if not the OS) requires better performance. A dual core for ham
>> stations these days is self-flagellation.
> Rick, A dual core system for amateur use may be self-flagellation but I
> receive customer support e-mail on a regular basis from users with that
> level of system or even Celeron and Atom based systems.  The point is
> that those low end systems *are* in regular use and one can't make
> blanket statements that EXTFSK is no problem based on a few scope
> pictures made with a six core, 5 GHz clock CPU.
>
>> Jitter is a documentable problem, it exists for a variety of reasons (not always the path used to transfer data), some of which are not resolvable unless taken to extreme measures. In severe cases, a move
>> to AFSK is an acceptable alternative and easily managed.
>
> Yes, proper choice of environment (minimizing the number of processes)
> can make less capable CPUs usable.  However, that generally means using
> AFSK instead of EXTFSK as well as being judicious with other issues
> (like software panadapters and limiting spot rates).
>
> 73,
>
>   ... Joe, W4TV
>
>
>> On 3/25/2018 4:37 PM, Rick WA6NHC wrote:
>>> On 3/25/2018 12:15 PM, Joe Subich, W4TV wrote:
>>>
>>> Even today the number/percentage of amateurs using liquid cooled, hex core 3 GHz i7
>>> processors like you used for your first "demonstration" is exceedingly
>>> small.  As I have told you multiple times, based on my support work
>>> the average amateur system is something like an 2.4 GHz Core2Duo with
>>> 1 - 4 GB of RAM and typically a single USB Root Hub to serve CAT, CW,
>>> FSK, digital sound card, *and* software panadapter.
>>>
>>> *NONE* of your demonstrations showed that level of system under *FULL*
>>> load.  Your first demonstration may have been running rig control and
>>> software panadapter but it wasn't processing a cluster feed at contest
>>> rates (your panadapter was clearly visible with only one or two signals
>>> on the band) and your CPU did not exceed roughly 40% utilization. Your
>>> second demonstration did not include rig control, panadapter or cluster
>>> yet by, your own measurements, had more than 10% *per bit* jitter which
>>> is enough according to Chen to reduce SNR by several dB.
>> Joe, I suspect you're selling the ham community short.  While 'thrifty' (ok, most hams are just plain cheap but it IS a hobby in a world of life issues) there is a LOT of computing power available in the used market. One can pick up an I-5/6/7 for a pittance and memory is dirt cheap.
>> I guess I'm on the bleeding edge for once.  A couple years ago I assembled a system specifically FOR the station; it's wasn't free but it also didn't break the bank.  It's a 4 GHz (slightly overclocked to 4.3 GHz and air cooled) I-7 with 32 GB of ram and the C: drive is a 520 GB SSD M3 chip mounted on the mboard (multiple data paths).
>> NOTHING slows it down (although Windows tries), as intended.  I've only found one ham program that actually causes load levels to rise but it's short duration and never maxed out.  It wasn't a repurposed system, it was created to last a long time.  Not even Photoshop causes a stutter (and that is a demanding suite of software).
>> It also captures weather data, produces a live wx web page, collects images from 4 critters cams and puts that on another live video web page, along with the usual mundane tasks like email and browsing. (What I DO need is fast Internet but I didn't move to North Idaho for the Internet ;-) )
>> I use 'real' serial ports, not USB for station control and FSK data. It's all in the details.  I've had poor performance from USB not from path overload but because it's sensitive to RFI at the worst moments; serial is more bullet proof.
>> So I agree Joe, as often as you're spot on, that your data may be a bit dated on this topic.  I'm positive I'm not the only one using more than a dual core CPU in the station as most of the software these days (if not the OS) requires better performance.  A dual core for ham stations these days is self-flagellation.  My only use for one is to play music into the home theater, Skype with the family gathered or stream web based video on the large flat screen.  Every tool has a use but the days of dual core for stations are long over.
>> Jitter is a documentable problem, it exists for a variety of reasons (not always the path used to transfer data), some of which are not resolvable unless taken to extreme measures.  In severe cases, a move to AFSK is an acceptable alternative and easily managed.
>> Let's move on and end this thread please.
>> Rick nhc
>> ______________________________________________________________
>> Elecraft mailing list
>> Home: http://mailman.qth.net/mailman/listinfo/elecraft
>> Help: http://mailman.qth.net/mmfaq.htm
>> Post: mailto:[hidden email]
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
>> Message delivered to [hidden email]
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]