TenTec
[Top] [All Lists]

Re: [TenTec] Re: A test of Orion's external CW keying

To: tentec@contesting.com
Subject: Re: [TenTec] Re: A test of Orion's external CW keying
From: "Grant Youngman" <nq5t@comcast.net>
Reply-to: tentec@contesting.com
Date: Fri, 27 Feb 2004 17:02:55 -0600
List-post: <mailto:tentec@contesting.com>
Then again, there may be nothing to "fix" exactly.  At last part of the 
issue is whether and to what extent these measured variations can 
actually be observed by a listener.  I've listened to several Orions on 
CW (including my own) and don't hear what I would call "slop", or 
what might be more precisely described as random variations in 
character element lengths.  And I don't generally "listen" to code 
with a digital storage scope :-)

But then my aging fist can't manage 60 wpm either, and even if I 
could send that fast, I couldn't copy that fast ...

So while the test results are informative and interesting, and I 
applaud the work and hope we see more like it as others dig in, it 
still at least partly boils down to the importance of perfection  beyond 
making one feel better (or not)  ....:-)

Grant/NQ5T



> Greetings All,
> 
> The really cool thing about the ORION is that this is no big deal for
> Orion owners, because when TenTec figures out an innovative 
cure for
> this situation( AND THEY WILL!!!), all we have to do is to 
download
> the new firmware into our radios and the problem is solved!! Try 
doing
> that on your ......IC756, IC756PRO, IC756PROII, IC775DSP, 
TS440,
> FT1000D, FT1000MPmark V, and the list goes on and on. I'll just 
update
> my Orion and SMILE, SMILE, SMILE!!! ;-)
> 
> 73 es GUD DX,
> 
> Kirby, W7SV
> 
> ----- Original Message ----- 
> From: "Martin Ewing" <martin@aa6e.net>
> To: <tentec@contesting.com>; <orion@contesting.com>
> Sent: Friday, February 27, 2004 10:20 AM
> Subject: [TenTec] Re: A test of Orion's external CW keying
> 
> 
> > Sinisa's result is not too surprising to me, since it seems that
> > just
> about
> > every control function in the Orion is handled through the
> > "Dragonball" processor.  This is cost effective, but it leads to
> > strange artifacts,
> such as
> > he investigated.
> >
> > Here's an experiment you can try.  With transmitter disabled (or
> > with
> dummy
> > load), send some CW with the internal keyer and spin the tuning 
dial
> > at
> the same
> > time.  You will see the sending slow down as the CPU is busy
> > tracking the frequency.  This shows that CW keying is handled 
as a
> > "process" in the
> CPU,
> > subject to all the timing jitter and pre-emption you might expect
> > from a
> 2.7
> > MIPS processor that's also managing the VFOs, the LCD, the 
DSP
> > processors,
> the
> > serial port, etc.
> >
> > It is not "wrong" to implement keying through a CPU, but you 
need to
> > use real-time OS design principles - guaranteeing proper 
maximum
> > latency for
> each
> > task, etc.
> >
> > All to save a couple of dollars on an analog keyer chip...
> >
> > 73 - Martin
> >
> > _______________________________________________
> > TenTec mailing list
> > TenTec@contesting.com
> > http://lists.contesting.com/mailman/listinfo/tentec
> >
> 
> 
> _______________________________________________
> TenTec mailing list
> TenTec@contesting.com
> http://lists.contesting.com/mailman/listinfo/tentec



-------------------------------
Grant Youngman /NQ5T
http://www.globeking.com
nq5t@comcast.net < == NEW

_______________________________________________
TenTec mailing list
TenTec@contesting.com
http://lists.contesting.com/mailman/listinfo/tentec

<Prev in Thread] Current Thread [Next in Thread>