--=====================_29883044==_.ALT
Content-Type: text/plain; charset="us-ascii"
Hello, guys. I received a lot of answers. Thank you.
N2MG wrote:
>Absolutely the first thing you need to do is to NOT start CT in a window.
>Boot directly to DOS and then proceed with running CT.
AD1C wrote:
Now that I read the message again, and saw Mike's response, I'm sure that's the
source of the problem. You can shut down Windows to a DOS prompt then try to
run CT that way. There are some "Hints and Kinks" on the www.k1ea.com web site
if you want Windows to give you a boot menu when you power up the computer.
This way you can boot to DOS without having to run the Windows startup first.
*** Not Windows is the problem. My example was not good. Let's suppose I have
two DOS computers running CTs. In fact, I used properly CT over Windows 95 and
I successfully connected two computers via a TNC link.
K1MK wrote:
You should not have to exit CT but you would have to stop logging and
enter the CT commincations SETUP screen to re-establish the TNC link.
That's only be necessary when the TNCs break connection. If one of
the computers crashed the TNCs should still remain connected UNLESS the
TNCs are responding to changes in state of the modem control lines
during the Win-98/MS-DOS re-booting.
That's a TNC issue not a CT issue. Suggestions where to check:
Consult your TNCs' manuals to see if you can set how the TNC reacts when
DTR/DSR are raised/lowered. In this application the TNCs needs to ignore
DTR/DSR. Once a connection is established, the RS-232 control lines to
the TNC should not be able to break the connection.
Try running terminal programs on both end of the TNC link and shutting down
one of the computers to investiagte what happens and to verify that the TNCs
remain connected.
You might need to wire a special connector that jumpers the modem control
lines inorder to get it to do the right thing.
*** Excelent idea. In fact, if one computer crashes, there have to be a buffer
into TNCs that is filled with information from CT. Of course, there is a limit,
but in a real contest, a crash may produce 2-3 minutes to be resored. If
connection is kept and TNC was not power-off-ed, everythink must be normal, as
nothing happened. But in fact, I did not see this behavior. May be the DTR/DSR
signals.
But what if I connect the PC to TNC using only Rx/TX and GND?
BTW, there's no database to restore; if there are network outages during the
contest then after the contest you'll need to run MERGE to create the
final log from the logs stored on each node.
*** This is not a good idea. The main intrest is to see both logs as only one
in real time, to avoid dupes or to hunt new multipliers. If logs are
independent, there is no network involved...
I tried to start a CT instance using a new file. Then (from Windows), I started
a new instance of CT using the same file. No sharing violaton error occured.
But QSOs made by one side were not reported on the other side, even the
file.bin was the same. This is because CT saves in .bin every new contact, but
does not read the file again. If file was read, networking was not a problem if
all computers involved in network had a TCP/IP layer. One file was shared in
this network and nothing more to run any number of computers.
In fact CT is a DOS application and is not updated with the new technologies.
The only reason that I think that CT is better to stay on DOS, is because it
runs on very low-end computers, as XT or 286. But these days, an old 486
computer is priced at $100 (including monitor), so anyone may have on his
desktop a good computer for Windows 95...
73s de Ciprian YO3FWC
--=====================_29883044==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
Hello, guys. I received a lot of answers. Thank you.<br>
<br>
N2MG wrote:<br>
<br>
<blockquote type=cite cite>Absolutely the first thing you need to do is
to NOT start CT in a window. Boot directly to DOS and then proceed
with running CT.</blockquote><br>
AD1C wrote:<br>
<br>
Now that I read the message again, and saw Mike's response, I'm sure
that's the <br>
source of the problem. You can shut down Windows to a DOS prompt then try
to <br>
run CT that way. There are some "Hints and Kinks" on the
<a href="http://www.k1ea.com/"; eudora="autourl"><font
color="#0000FF"><u>www.k1ea.com</a></u></font>
web site <br>
if you want Windows to give you a boot menu when you power up the computer. <br>
This way you can boot to DOS without having to run the Windows startup
first.<br>
<br>
*** Not Windows is the problem. My example was not good. Let's suppose I have
two DOS computers running CTs. In fact, I used properly CT over Windows 95 and
I successfully connected two computers via a TNC link.<br>
<br>
K1MK wrote:<br>
<br>
You should not have to exit CT but you would have to stop logging and <br>
enter the CT commincations SETUP screen to re-establish the TNC link. <br>
That's only be necessary when the TNCs break connection. If one of <br>
the computers crashed the TNCs should still remain connected UNLESS the <br>
TNCs are responding to changes in state of the modem control lines <br>
during the Win-98/MS-DOS re-booting. <br>
That's a TNC issue not a CT issue. Suggestions where to check:<br>
Consult your TNCs' manuals to see if you can set how the TNC reacts when <br>
DTR/DSR are raised/lowered. In this application the TNCs needs to ignore <br>
DTR/DSR. Once a connection is established, the RS-232 control lines to <br>
the TNC should not be able to break the connection.<br>
Try running terminal programs on both end of the TNC link and shutting down <br>
one of the computers to investiagte what happens and to verify that the TNCs
<br>
remain connected. <br>
You might need to wire a special connector that jumpers the modem control <br>
lines inorder to get it to do the right thing.<br>
<br>
*** Excelent idea. In fact, if one computer crashes, there have to be a buffer
into TNCs that is filled with information from CT. Of course, there is a limit,
but in a real contest, a crash may produce 2-3 minutes to be resored. If
connection is kept and TNC was not power-off-ed, everythink must be normal, as
nothing happened. But in fact, I did not see this behavior. May be the DTR/DSR
signals.<br>
But what if I connect the PC to TNC using only Rx/TX and GND?<br>
<br>
BTW, there's no database to restore; if there are network outages during the
<br>
contest then after the contest you'll need to run MERGE to create the <br>
final log from the logs stored on each node. <br>
<br>
*** This is not a good idea. The main intrest is to see both logs as only one
in real time, to avoid dupes or to hunt new multipliers. If logs are
independent, there is no network involved...<br>
I tried to start a CT instance using a new file. Then (from Windows), I started
a new instance of CT using the same file. No sharing violaton error occured.
But QSOs made by one side were not reported on the other side, even the
file.bin was the same. This is because CT saves in .bin every new contact, but
does not read the file again. If file was read, networking was not a problem if
all computers involved in network had a TCP/IP layer. One file was shared in
this network and nothing more to run any number of computers.<br>
In fact CT is a DOS application and is not updated with the new technologies.
The only reason that I think that CT is better to stay on DOS, is because it
runs on very low-end computers, as XT or 286. But these days, an old 486
computer is priced at $100 (including monitor), so anyone may have on his
desktop a good computer for Windows 95...<br>
<br>
<br>
<br>
73s de Ciprian YO3FWC
</html>
--=====================_29883044==_.ALT--
|