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

[Joe Subich, W4TV]

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:Elecraft at mailman.qth.net
> 
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to lists at subich.com