---- The Poqet PC --------------------------------------------------------------
 Home  FAQ  LIST  SOFTWARE  DOCUMENTATION  MUSEUM  LINKS

Poqet PC Mailing List Digest
Volume 001, Number 120, 10 Jun 1997

Table of Contents


 <
Previous (Vol. 001, No. 119)

UP (to archive list)
 >
Next (Vol. 001, No. 121)

  1. FS SRAM Card by Yujin Nagasawa <ynagasaw@xxxxxxxx>
  2. Re: GPS & Poqet by compass@xxxxxxxx

Digest Articles

FS SRAM Card by Yujin Nagasawa <ynagasaw@xxxxxxxx>


From: "Yujin Nagasawa" <ynagasaw@xxxxxxxx>
Subject: FS SRAM Card
Date: Mon, 9 Jun 1997 21:14:00 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Verbatim 1MB SRAM Card for sale
$40+shipping

E-mail me for detail.
Thank you.

Yujin



Re: GPS & Poqet by compass@xxxxxxxx


From: compass@xxxxxxxx
Subject: Re: GPS & Poqet
Date: Tue, 10 Jun 1997 14:05:20 -0600
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Dear Alessandro,
Standard GPS protocol is 1200bps input and 2400bps output  as I recall (I may have 
these numbers reversed). I do not know anything about Garmin's I/O protocols. 
Yes, the Poqet hangs whenever it is waiting for data from the serial port, which never 
arrives.
It is possible that you are encountering data under-runs similar to those encountered 
when you try to run a printer from the serial port. After a certain number of 
characters are sent, the I/O buffers overflow in the Poqet. You do not get any warning 
or indication of this situation except that you can see the reults in the printed page 
produced. I t is possible that the Garmin protocols using 9600bps are overflowing the 
buffers of either the poqet or the GPS unit. Alternatively, it may be that the poqet 
is waiting for an XON/XOFF(software) or DTS/CTS(hardware) signal from the Garmin, 
which it does not detect. This does not mean that the signal is not asserted(sent), 
simply that the poqet does not detect it. If you can set the Garmin unit to accept a 
slower data rate, do so. This may solve your problem. You will lose nothing by 
reducing the data rate to 1200bps since this is most likely the native output rate of 
the hardware. In fact, the data as it is sent from the satellites is only 150bps, or 
is it 300bps I'll have to look it up again to refresh my memory (not 1500, but 150 
[one-hundred fifty bits per second]). This extremely slow data rate is why it takes so 
long to download a complete almanac from the satellites from a cold start.
	Just as lowering the data rate on a serial printer will lessen the data 
over-runs and under-runs, lessening the problem but not necessarily eliminating it, 
the same should hold for your problem. I checked with Poqet/Fujitsu several times 
regarding this problem, which they insisted did not exist if you turned off power 
management. They always said there should be no problem. I provided them with data, 
but never got an answer that worked from them. I learned to break my data into blocks 
of less than about 1000 bytes (+/- one printed page) and print the individual blocks.
	One more thought, as I recall, some of the data I printed through the serial 
port was much longer than 1000 bytes and it went just fine. It may depend on the 
software you use or on the print routines you use. I found that programs which relied 
on the DOS or BIOS print routines seldom worked reliably through the serial port and 
did not provide error messages when a malfunction occurred. Programs which buffered 
the printing themselves  and did not rely on the DOS/BIOS routines usually ran much 
better, gave me error messages when the serial port was full, detected overflow and 
XON/XOFF or CTS/DTS to prevent overflows, and recorvered from errors better.
	You might try installing a print spooler and sending all of your outgoing data 
through the print spooler. Most commercial print spoolers (not the ones that come with 
MS-DOS though) will take care of detecting error or over-run conditions and act 
appropriately. One good spooler is PCKWIK Powerpak for DOS. The last contact info I 
have for them is:
	Multisoft Corporation
	15100 SW Koll Parkway
	Beaverton, OR 97006
	(503) 644-5644
	1-800-234-KWIK (sales)
	(503) 646-8267 (fax)

Another good one is in the Norton Utilities.

There are also many old DOS print spoolers on the shareware market which may help.
If you use a print spooler, remember that you will need to use the DOS command MODE to 
redirect the printer to the serial port after installing the spooler. Here is an 
example of the MODE command:
	mode com1:9600,n,8,1,p
	mode lpt1:=com1:
The first MODE command sets up the serial port. The second mode command redirects the 
printer to the serial port.

Your floating point errors are probably caused by the lack of a math coprocessor or 
math coprocessor emulator in the poqet. The 486DX has a math coprocessor built into 
it. In fact, a 486 is really not much more than a 386 with a built -in math 
coprocessor. There is no way to add a math coprocessor to the poqet, but there is a 
maht coporcessor emulator available which may help. What may have happened is that 
GArmin may have compiled their software with the idea that a math coprocessor or 
emulator would be available. YOu could contact Garmin and ask them to recompile their 
object code and turn off the coprocessor flags in the compiler before doing so. Their 
programmers should be a ble to accomodate your request, but the program may run very 
slowly on the poqet. Another approach is to get a math coprossesor emulator, a 
software program which fools other programs into thinking that a coprocessor is 
installed and provides resonses to programs calling the math coprocessor as the Garmin 
software seems to do. Some are available as shareware. They is also one available 
commercially from a BIOS/DOS/RTOS company. Two that may help are:
	General Software Inc.
	320 - 180th Ave. NE
	Suite 400
	Bellevue, WA 98004
	(204)454-5755
	general@xxxxxxxx    Email
and
	Datalight
	18810 59th Ave. NE
	Arlington, WA 98223
	(360)435-8086

Good luck with your poqet hanging on you. This is probably caused by the poqet waiting 
for confirmation that it never detects. The Poqet does not do anything else while it 
is waiting for data or sending data. That is why you cannot press Ctrl-Break to stop 
the data transfer, which is what is going on as far as the serial port is concerned, 
even if the computer has effectively "hung". Check that your serial lines are all 
connected. But that may not be the problem. The poqet does appear to hang while 
waiting for the serial lines to be asserted or released. You probably already have a 
good book on the serial interface. If you don't have one, get one such as "RS-232 Made 
Easy", I don't remember the author's name. Also handy would be a diagnostic tool such 
as the RS-232 diagnostic tool from Radio Shack which has an LED on each of the serial 
lines, giving you a visual display of when eachof the lines is asserted or released 
(cost is $15-20).

Ron W. Hardy
Compass Consulting Co.
775 South Sunset Drive
Cedar City, UT 84720
voice:	801-865-7000
cell:	801-559-8000
fax:	801-586-5248
email:	compass@xxxxxxxx
web:	http://www.tcd.net/~compass/



Filename: PoqetPC/mailing-list/cgi/show-digest.htmt
Date Created: 30 Nov 1996, Last Modified: 13 May 2009
Created by Bryan Mason - E-Mail: poqetpc<at>bmason<dot>com