[hpsdr] Penny PTT unkeying spike - T/R sequencing?

Thomas Cathey K1JJ at comcast.net
Wed Feb 2 11:23:08 PST 2011


Thanks for your input, Roger and Tim.  That's kind of what I expected. This
issue I'm having would have surfaced with other rigs by now.

Yes, after more testing today it appears that maybe I have something amiss
still centering on Penny. Today I keyed up the rig a few times into the
dummy load on ssb and  Penny took off with a series of images up and down
the band. (down -30db from main carrier)    I heard it on the outside RX and
if I pull the coax off Penny, it drops down, but still there. Shutting off
the computer does not affect the images. The only way to kill it is by the
power switch. When in this runaway node,  Penny stays on even with the PTT
switch off.

I reloaded PSDR from stretch and reset all the toggles, but had the same
result.  These transients on unkey are still there and I think they are
shocking Penny into the oscillations. I see "ADC Overload" on the screen,
but maybe that is just Mercury complaining.   Other than this the rig runs
flawlessly as it should.

I'm talking with Gerd, who off-hand doesn't think it is Penny's hardware
itself - I will try a few tests he suggested first. Otherwise I might have
to send it out to him for evaluation.

I will certainly post the fix, whatever it turns out to be, for the
archives.

Thanks for the time and suggestions, guys!

Tom, K1JJ
 

I would like to second Tim's comment.

I have been regularly using five Mercury/Penelope combinations [some Pene's
are TAPR, some are Gerd's] for weak signal VHF work for a nearly two years
or so, and I have seen NO S meter or TR transition issues such as have been
described.  I have never had the software lock up on TR transition or seen
any of the Pene 'lock up' that Tom is seeing.  Nor have I experienced the
'headphone pop' he reports.

This would suggest to me that he is seeing one of those system-eccentric
anomalies that can drive the affected individual crazy [I know because I
have been there with other pieces of gear], but which can be very hard to
track down.  My note is just to indicate that I don't think it is a problem
that all of us are having.

The solution of these problems does sometimes, however, lead to
identification of programming or other general 'issues' that were otherwise
unrecognized, so it will be interesting for us all to hear the denouement,
once the problem is solved.


73,

Roger Rehr
W3SZ



 1296674588.0


More information about the Hpsdr mailing list