> the 781 on the 40 meter position. It happened off and on for a
> short time and then went away. Allowing the error to run off the
A wonderful observation. The intermittence is what makes this problem
difficult to track.
I can make the problem occur with regularity under Win 95 but under DOS it
occurs much less frequently. In fact, I thought I had the problem solved
under DOS by changing the TIMEOUT, PAUSE, etc parms but the day of the ARRL
10m contest it reappeared and occurred regularly under DOS. What I ended up
doing was switching to another DOS machine. The problem only occurred a
couple of times during the contest and I had one NONCW entry in the log that
I had to edit. I have switched back to the original machine and now it seems
stable under DOS. Strange.
Below are bits of a trapped TR-Icom message using TR's RADIODEBUG command.
TR was running under Win 95 and the Icom was set to 21021.0 in the CW mode.
The Icom was not keyed or tuned at any time. I can watch it cycle between CW
and NONCW as the frequency display cycles between 21021.0 and 210.2. Every
once in a while it will cycle between SSB and NONSSB. You can see from the
DEBUG trace that I parsed using a PERL script the either a bit is change or
a byte is lost. I am now doing some long term data collection under DOS to
see if I can capture some of the these NONCW events. I suspect that the
problem is a marginal problem that is exacerbated under Win 95 compared to
DOS. Also it is likely that the problem will not occur under DOS unless TR
is engaged in some other activities such as keying or logging etc. I wonder
if has something to do with not using the serial port interrupt.
It might be helpful if we could turn our attention to "collecting" data to
solve the problem instead of "speculating" about the existence and source
of the problem. After all it is an hardware/software problem not a political
problem :-)
bye .... Sylvan
PS - it is rather simple to write a little program to capture and send
messages to the Icom. I have written several of them and they are stable
under either DOS, Win 9x, NT and Linux. The annoying thing is doing writing
the BCD conversion routines.
----------------
Sylvan Katz
Saskatoon, Sask
VE5ZX & G0TZX
Note all messages to and from Icom begin with FE FE and end with FD see the
CI-V data sheet for the message content definition. I am not sure that the
first Hex value (e.g. 12, 13, etc is for) and I am not sure exactly what
RADIODEBUG is trapping. Only the changed messages are listed below.
RADIO.DBG (Win 95, 21021.0 MHz, CW)
13 FE FE E0 40 03 00 10 02 21 00 FD FE FE E0 40 04 03 01 FD
12 FE FE E0 40 03 00 10 02 21 00 FD FE FE E0 40 04 01 FD 00
13 FE FE E0 40 03 00 10 02 21 00 FD FE FE E0 40 04 03 01 FD
11 FE FE E0 40 03 00 10 02 21 FD FE FE E0 40 04 03 FD 00 00
13 FE FE E0 40 03 00 10 02 21 00 FD FE FE E0 40 04 03 01 FD
12 FE E0 40 03 00 10 02 21 00 FD FE FE E0 40 04 03 01 FD 00
0F FE E0 40 03 00 10 02 21 00 FD FE FE E0 40 FD 00 00 00 00
12 FE E0 40 03 00 10 02 21 00 FD FE FE E0 40 04 03 01 FD 00
13 FE FE E0 40 03 00 10 02 21 00 FD FE FE E0 40 04 03 01 FD
12 FE FE E0 03 00 10 02 21 00 FD FE FE E0 40 04 03 01 FD 00
11 FE FE E0 40 03 00 21 00 FD FE FE E0 40 04 03 01 FD 00 00
12 FE FE E0 40 03 00 10 21 00 FD FE FE E0 40 04 03 01 FD 00
11 FE FE E0 40 03 00 21 00 FD FE FE E0 40 04 03 01 FD 00 00
13 FE FE E0 40 03 00 10 02 21 00 FD FE FE E0 40 04 03 01 FD
11 FE FE E0 40 03 00 10 02 21 FD FE E0 40 04 03 01 FD 00 00
--
FAQ on WWW: http://www.contesting.com/FAQ/trlog
Submissions: trlog@contesting.com
Administrative requests: trlog-REQUEST@contesting.com
Problems: owner-trlog@contesting.com
Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
|