[Lowfer] Bug found and AFRICAM 4.3 available

[Bill de Carle]

At 08:28 AM 2/14/2004 -0600, Lyle wrote:
>It's possible that LEK was not sending a properly coded signal. The computer
>that was sending the AFRICAM data didn't lock up, and the "keying" LED on my
>homebrew exciter was blinking normally. This morning the computer was
>displaying an error message which I thought applied only to receiving, but
>it's possible that something was messed up at this end. Will see if Bill de
>Carle captured anything last night. Thanks for listening.

Hi folks, sorry for the inattentive morning but I've been busy looking into
things.
First of all I did try to copy LEK last night - copy was terrible but I saw
enough
characters in there at the right places to be convinced Lyle *was* sending
correctly.

I have been using AFRICAM to test sending BPSK with the little synthesizer
box I just
built and found something particularly unnerving...  When it started
sending it would
at that point stop updating the UTC clock on the screen but would continue
sending
anyway.  I finally tracked it down.  A few days ago Lyle brought forward
what at the
time seemed an excellent idea - in order to make the 1-pps line go a little
negative
he suggested pulling it low with a resistor to a pin on the port itself.  A
couple
of days ago when I was in the shop I modified my 9-pin interface to do just
that.
Aside from the Tx output (pin 3), there are only two other outputs
available, RTS (pin 7),
and DTR (pin 4).  Now I remembered that we are using RTS output to key the
BPSK so I
knew I shouldn't use that one, so I figured pin 4 was the one to use.  I
connected a 4.7K
resistor between Ring Indicator (pin 9) and DTR (pin 4).  Then I tested the
cable
and it seemed to work fine.  It worked fine before, but I wanted some extra
margin and
so I pulled it low a bit.  The circuit I use for the 1-pps signal is an NPN
transistor,
emitter grounded, base driven by the TTL 1-pps output via a 10K series
resistor, with
a 2.2 K resistor in the collector to 12 VDC.  Another 2.2 K resistor
couples the collector
to the cable going to the RS232 input connector.  I had actually measured
pin 4 on the
connector to be sure, and it was indeed around minus 12 V.   Like I say, it
worked fine -
until I started to send!

I noticed the UTC clock stopped updating the instant I started to send
(there is usually
a delay between hitting the ENTER key and when the first bit starts going
out - that's
because AFRICAM waits to synchronize the first bit in the frame with its
appropriate
UTC time slot.  During that delay the UTC clock on screen continued to
update normally,
but once the *first* bit went out the clock stopped updating.  But sending
continued
normally, and I was able to activate the receiver and get perfect copy on
my own signal
coming from the synthesizer.  I scratched my head.  Eventually found it was
not taking
any more 1-pps interrupts at all after it started sending!  So it was
sending undisciplined
BPSK and I was copying it fine.  Once AFRICAM has a calibration run in on
the computer's
T0 timer frequency it uses that for bit-timing.  So even if the 1-pps
interrupts stop
coming in the sending will still continue from where it left off - and if
the room temp
doesn't change much and we are using a long bit time (e.g. MS1000) the
keying will stay
remarkably coherent for many hours!  So guess what the problem was?  I had
completely
forgotten that in AFRICAM we use DTR as a push-to-talk output - so as soon
as it started
sending it *asserted* DTR (to turn the Tx on) and presto, DTR went positive
instead of
negative and my 1-pps circuit was no longer able to pull the ring indicator
pin low enough
to trigger the interrupts.  Lyle had reported this phenomenon to me earlier
- where the
UTC clock stopped updating but the machine kept on sending normally, but it
never dawned
on me until today what the actual problem was.

Anyway, that's fixed now.
I just uploaded version 4.3 of AFRICAM to my bbs at:

www.magma.ca/~ve2iq

I corrected that problem and changed the way it reports time on the trace
file.
There is also an additional diagnostic value printed out at bottom of
screen whenever you do
a "home" key - npps=xxxx where xxxx is the number of 1-pps interrupts seen
so far.  It should
go up by one each second.  I also changed the code in the Undouble routine
- it's a little
cleaner now but I'm not convinced we've gotten to the bottom of that one.

Thanks for all the feedback.  I'm going to try get a Tx put together this
afternoon out at the
loop.  Can drive it OK from the shack now.  It's going to snow later they
tell me.  Oh well...

73 de Bill VE2IQ