QBasic Serial Ports

Story:
I use a couple of different machines in my station automation and am running into a rather odd problem with accessing one of the serial ports under QB45. I know the port exists, been into the BIOS, and can even communicate with the darn thing under Win3.1 (normally the robot runs straight DOS with the program genericly called DIALER). However QB fails the OPEN routine with a Device Timeout Error. Am I overlooking something here? I know there's nothing wrong with the I/O in the QB package for there's a modem on 2 which the program does successfully open and communicate with. Though I got a small issue with that, but I'll make a separate thread when I'm fustrated with the 'bug'.:rolleyes:

FWIW, here's an example of a simple communications program:

Code:

---

100 ' ----------------------------
110 ' Simple Communication Program
120 ' ----------------------------
130 '
140 ' Note: Set "ECHO = -1" for Local ECHO
150 '      Set "ECHO -  0" for No Local ECHO
160 '
170 ECHO = 0: CLOSE
180 '
190 ' --------------------
200 ' *** Screen Setup ***
210 ' --------------------
220 KEY OFF: CLS
230 PRINT "Simple Communications Program"
240 PRINT "(Press [Esc] to Exit Program)": PRINT ""
250 '
260 ' ----------------------------------------------
270 ' *** Open Specified COM Port for Read/Write ***
280 ' ----------------------------------------------
290 ' Note: Use COM1 for Serial Port 1, COM2 for Serial Port 2
300 '
310 OPEN "COM1:9600,N,8,1,DS,CD" FOR RANDOM AS #1
320 '
330 ' --------------------------------
340 ' *** Display Local Keystrokes ***
350 ' --------------------------------
360 LocalKeystroke$ = INKEY$
370  IF LocalKeystroke$ = CHR$(27) THEN SYSTEM ' Exit on [Esc]
380  IF LocalKeystroke$ = "" THEN 450
390  IF ECHO THEN PRINT LocalKeystroke$;
400  PRINT #1, LocalKeystroke$;
410 '
420 ' -------------------------------
430 ' *** Display Remote Response ***
440 ' -------------------------------
450 IF EOF(1) THEN 360
460  RemoteCharacter$ = INPUT$(LOC(1), #1)
470  IF RemoteCharacter$ <> CHR$(13) THEN PRINT RemoteCharacter$;
480 '
490 ' ------------
500 ' *** Loop ***
510 ' ------------
520 GOTO 360

---

Reboot to DOS and run this program in GWBASIC or QBASIC. Type "ATZ" (and press [Enter]) and you should get an "OK" response from your modem.

Dude I really appreciate your taking time to do this, but that's not the problem.
[list=1][*]I am already running a PURE DOS program in this case, using QB and a program as the main driver for the system.[*]I am already successfully communicating with a Modem using this program.[/list=1]
The problem is opening a pure, (no modem attached), serial port for communicating with a non-modem appliance. And from other documentation I think I understand on the project, I cannot seem to do that without a null modem cable for QB wants to use the DTR/RTS lines. I think.

Have you tried

• wiring DTR to DSR and CD ...
  For a 9-pin Serial Port that would be pins 4, 6 and 1.
  For a 25-pin Serial Port that would be pins 20, 6 and 8.
  
  and:
  
• wiring RTS to CTS and RI?
  For a 9-pin Serial Port that would be pins 7, 8 and 9.
  For a 25-pin Serial Port that would be pins 4, 5 and 22.

Going to have to wire something, frigging Terminal does talk to the Starguide, the Starguide provides RTS, CTS, RXD, & TXD, and doesn't require a proper Null Modem, I'm talking to it with a straight through serial cable, (1-1, 2-2, etc).
Busy talking with Tech Support to see what I need to do, thanks for the suggestion, will probably try that, if I got a couple of adaptors lurking about, over the weekend. (P.S. everything 9pin)
It's either that, or resort to a mini calling program I sublaunch which sends the commands to COM1, they're only 10-16 Ascii Chr strings.
_S_a_y_, isn't it possible to use Mode to configure the port specifications, then use Echo to send the chr string to the port under DOS 6x?

Is your Starguide's COM port set for 9600 Baud, No Paridy, 8 Data-bits and 1 Stop-bit, (9600,N,8,1)? The COM port on your Computer (or Terminal) and your Starguide must be set the same.

> _S_a_y_, isn't it possible to use Mode to configure the port specifications, ...

Yes, on most, but not all PCs. The MODE command is very similar to line 310 in the above program. For example:

• mode com1:9600,N,8,1

> ... then use Echo to send the chr string to the port under DOS 6x?

Yes, but you'll be doing it blind, (i.e., you won't be able to see the remote devices response(s) to your commands).

Example DOS commands:

• echo atz>com1
  echo atdt18005551212>com1
  echo ath,+++>com1

The first command resets the modem with your saved settings, the second tells the modem to dial 1-800-555-1212 (which in the US will get you the 1-800-number operator), the third will hang up (go on-hook, disconnect) many modems.

9600,N,8,1 FYI Starguide is a Digital Satellite Reciever, the buggers cost about $4,700 a pop, without decoder cards at $780 a pop. :eek:
That's basically what I have in mind, and blind it about right, however, I should be able to double pipe the effect I'm looking for, aka:
echo (command string)>com1 >results.txt
Like I said, the commands are real short, they're for changing channels via automation, like going from program 23 to program 52, I tell the reciever:
SP C,S,52
And the reciever doesn't even bother me unless I generate an error, then it says:
ER #
Matter of fact, I'm going to try this right now!
P.S. Uplink provides for the availability of ISDN/TCP Ethernet connection with a 20Mbps download speed, requests still have to be sent via another means, like phone or DSL.

Quote:

---

Matter of fact, I'm going to try this right now!

---

:mad: Didn't work, echo'ing to the comm port runs it through INT24 which demands full handshaking with the other end, and the Starguide doesn't provide F.HS., going to have to either wire a dongle, or write a mine bit of ASM/C code to make it happen.
:bummer:

> echo (command string)>com1 >results.txt

Won't work. :(

The BASIC program can be altered to capture remote responses though.

BTW, I know absolutely nothing about a "Starguide". :(

:p Me neither, until I started working in Radio!
http://www.starguidedigital.com/
But that's besides the point right now, I've got to wait for Normal Business Hours to get some futher information about the serial port on the beast and see what I have to do to make this work.
LOL!
Still, thanks much for your help and suggestions.

Is there a wiring diagram sticker on it, or in the manual, that shows which pins are for what, (like TxD, RxD, RTS, CTS, etc.)?

Yo! Techie Stuff!
Starguide M&C Port Pins:
[list=1][*]Chassis Gnd[*]TXD Out[*]RXD In[*]N/C[*]Signal Gnd[*]N/C[*]CIS In[*]RTS Out[*]N/C[/list=1]
:o No DSR/DTR signals, which means that Hardware Flow Control Reliant programs will ALWAYS fail!

Here's what I'd probably try first:

PC pin 1 to Starguide pin 1 (Chassis grounds)
PC pin 2 (RxD) to Starguide pin 3 (TxD)
PC pin 3 (TxD) to Starguide pin 2 (RxD)
PC side only, jump 4 (DTR) to 6 (DSR)
PC pin 5 to Starguide pin 5 (Signal grounds)
PC pin 7 (RTS) to Starguide pin 8 (CTS)
PC pin 8 (CTS) to Starguide pin 7 (RTS)
(Ignore pin 9 (RI))

And then try communicating using 9600,n,8,1

Yeah! That works. Apparently, because 'DOS Compliant' programs run the serial port interface through the 'Official' INT14 vectors, it's really a requirement of IO.SYS that the DTR/DSR be used.
Now that I think about it, just about every piece of Comm Software I've seen, the programmer writes their own Port Interface Routines which bypass the INT vectors because it's faster to bypass them.
Matter of fact, I hooked the DTR/DSR jumper first, and because the IO was able to assert DTR, and see a signal come back on DSR, it said the remote end was READY!
(or is it the other way around?)
Anyway, thanks for your time and help.
:D

You're more than Welcome. Great to hear that it's finally working. :)