Greetings All:
This is an old subject, a curse mainly of older compilers and interpreters
that had marginal capabilities in looking after a serial port - COM port in
the modern parlance.
First, you have to find out if your compiler or interpreter is working with
COM ports - some of them dont work properly, never did work properly -
despite what the claims of the suppliers were. If your using some of the
old Basic interpreters or early Compilers you can reduce your frustration
level with the erase and delete functions! I have been using the Borland
Basic Compiler, now over 13 years old, but it is a piece of junk in todays
terms, never did work right and is only useable by a bag of tricks that are
very marginal (unreliable) above 4800....
Second, write a sending routine out of one PC. Cross connect, called a Null
MODEM cable and a sex changer between two PC's. Write a receive routine on
a second PC. If you can not get 100% performance over a link like this, you
will never get a radio to work properly when it is hooked to a COM port.
It is normal that even the oldest PC software can send a string competently
out of a COM port. The problem, in my experience, is 99% in the receiving
routine. The general problem is to write a polling routine to catch the
incoming characters. You loop around the incoming port and catch every
character as it arrives. The alternative is to figure out how the interrupt
system really works as against what the documentation says it works. In
some cases it is necessary to obscurely find a way to catch a change in the
length of the incoming cue created by the incoming data, then to get the
data out of the cue into a string fast before the cue over runs.
One last nasty with the old stuff, if you try to send a nul character, 8
bits all zero, most Basic's will NOT do it, some will suggest it is done and
have done nothing. Avoid this pain at all costs is my advice.
You can avoid all this nonsence by using the MSCommn (where n is the number
of the port) in Visual BAsic. It really works, works properly and is
consistent. VB is a bit of a hard ticket to get started with but I have
come to love it for the speed you can put a concept or notion into a
workable demonstration. One thing, with VB using MSCommn you can have 8
ports in a PC, all ports looped to the next one and the last back to the
beginning and feed it a string and let the software sort out the excitement.
I have left it running over a weekend and still had the same string going
past on the screen on Monday. All ports running at 57K, nuf said?
Last but not least, watch out for the IRQ zoo. COM1 is normally IRQ3, COM2
is normally IRQ4 and then you put in an internal modem on COM3 and it
doesn't work. Well find out on your system the equivalent of WINMSD.EXE and
you will quickly notice that COM1 and COM3 are sharing IRQ4- a solid
gurantee not to work. Put COM3 on IRQ7 which I notice in NT-4 is not
normally assigned any regular duties.
Now lets say a few words about how radios receive serial data. They all do
not work the same! When sending a command to a radio, and if your having
nasty problems try a small delay period between every character that your
sending to the radio. Some years back while building an automatic station
for managing some of the AMSAT microsats one of the radios control ports
just refused to work. I had to insert a 10 millisecond pause between every
character sent to the radio on the serial port! This is not an uncommon
problem - there is a commercial CW keyer, top of the line for the
manufacturer that has an RS-232 serial port. If you send the keyer two
ASCII characters at full machine rate, no pause between the characters at
all, the keyer will NOT receive the second one.
When I proposed the requirement to get your COM ports working between two
PC's first, I did this for good reason as you can see. So the process is to
minimize the number of new things in the loop during each step in the
process and make your software works with as many things that are known to
work and work properly along the way.
Unless your prepared to put in a steep learning curve and a heavy stress on
your cranium avoid the Microsoft Hyperterminal in favour of an old copy of
Procomm or something similar.
None of this is rocket science but if your being driven nuts some of the
above might point you in the right direction. Just remember, minimize the
number of unknown variables to get control of the problems. One problem you
can see and fix is a lot better than 4 problems you can not isolate or find
or fix......
Good Luck
Larry
VA3LK
--
FAQ on WWW: http://www.contesting.com/tentecfaq.htm
Submissions: tentec@contesting.com
Administrative requests: tentec-REQUEST@contesting.com
Problems: owner-tentec@contesting.com
Search: http://www.contesting.com/km9p/search.htm
|