sending data to a file on a PC
Archiver
Posts: 46,084
1)I am on a BS2 revA basic stamp. I want to send data to a data array
file on a PC. how do I do it!
Here is the short program:
w2=0
w3=0
input 7
output 0
Tach: pulsin 7,1,w2
w3=w3+1
serout 0,16486,[noparse][[/noparse]"1/4rev# ",dec w3," count: ",dec w2,cr]
debug "1/4rev# ",dec w3," count: ",dec w2,cr
if w3<1000 then Tach
stop
Again, It runs in debug but how do I get this data to be store into a
file on the PC?
2) Also, is there any way to change the baud mode on the debug screen?
It is pre-set to 9600. thanks katie's dad
file on a PC. how do I do it!
Here is the short program:
w2=0
w3=0
input 7
output 0
Tach: pulsin 7,1,w2
w3=w3+1
serout 0,16486,[noparse][[/noparse]"1/4rev# ",dec w3," count: ",dec w2,cr]
debug "1/4rev# ",dec w3," count: ",dec w2,cr
if w3<1000 then Tach
stop
Again, It runs in debug but how do I get this data to be store into a
file on the PC?
2) Also, is there any way to change the baud mode on the debug screen?
It is pre-set to 9600. thanks katie's dad
Comments
you start the Stamp.
Sid
> file on a PC. how do I do it!
> Here is the short program:
> w2=0
> w3=0
> input 7
> output 0
>Tach: pulsin 7,1,w2
> w3=w3+1
> serout 0,16486,[noparse][[/noparse]"1/4rev# ",dec w3," count: ",dec w2,cr]
> debug "1/4rev# ",dec w3," count: ",dec w2,cr
> if w3<1000 then Tach
> stop
>Again, It runs in debug but how do I get this data to be store into a
>file on the PC?
Use Hyperterminal instead of the debug window. It is already
installed on most PCs, or available from <http://www.hilgraeve.com>.
Open a new connection direct to your com port. Use "capture" to open
a file for your data.
Another great option is Stamplot from
<http://www.selmaware.com/stampplotlite/home.htm>
It is designed for the stamp and has lots of neat functions for
graphing your data.
>2) Also, is there any way to change the baud mode on the debug screen?
> It is pre-set to 9600. thanks katie's dad
Not on the debug screen that pops up automatically. However, you can
open a debug screen intentionlly and set the baud rate to other
values. In that case, you will have to change the debug command in
your program to SEROUT 16,baudmode,...
-- Tracy
In basicstamps@y..., Tracy Allen <tracy@e...> wrote:
> >1)I am on a BS2 revA basic stamp. I want to send data to a data
array
> > file on a PC. how do I do it!
> > Here is the short program:
> > w2=0
> > w3=0
> > input 7
> > output 0
> >Tach: pulsin 7,1,w2
> > w3=w3+1
> > serout 0,16486,[noparse][[/noparse]"1/4rev# ",dec w3," count: ",dec w2,cr]
> > debug "1/4rev# ",dec w3," count: ",dec w2,cr
> > if w3<1000 then Tach
> > stop
> >Again, It runs in debug but how do I get this data to be store into
a
> >file on the PC?
>
> Use Hyperterminal instead of the debug window. It is already
> installed on most PCs, or available from <http://www.hilgraeve.com>.
> Open a new connection direct to your com port. Use "capture" to
open
> a file for your data.
>
> Another great option is Stamplot from
> <http://www.selmaware.com/stampplotlite/home.htm>
> It is designed for the stamp and has lots of neat functions for
> graphing your data.
>
> >2) Also, is there any way to change the baud mode on the debug
screen?
> > It is pre-set to 9600. thanks katie's dad
>
> Not on the debug screen that pops up automatically. However, you
can
> open a debug screen intentionlly and set the baud rate to other
> values. In that case, you will have to change the debug command in
> your program to SEROUT 16,baudmode,...
>
> -- Tracy
"PULSIN" it measure pulse width, actually the count (in 2microsecond
increments) of the pulse width and then transfers this "count" (plus a
carriage return, see debug line below) to the debug screen.
- max/ min pulse width range from 8 msec. down to 2 msec.
- The corresponding "counts" are approx. 3960 and 960.
- The data is being x-ferred to the debug screen BETWEEN pulses. The
corresponding time between pulses is 65 msec down to 16 msec which I
"think" should be do-able (at 9600 bits/sec).
Now the question: in the debug screen (see program below), do I
assume 2 words are being x-ferred (the variable "w2" and the "carriage
return", is the carriage return a WORD?) If I assume this, at the
debug transfer baud rate default of 9600, it will transfer the two
words (32 bits) at 32bits / (9600 bits/sec) = 3.3 milliseconds. Is
this correct? If so, from above I have worse case 16 msec. to
transfer the data and I should be ok???????
Question#2: Can I get faster baud rates in Hyper Terminal? And if so
how? I tried to get hyper terminal working yesterday thanks to help
from some of your suggestions (greatly appreciated) but it would only
run if debug was "active". By active I mean if I make the debug line
in the program, text, the hyper terminal doesn't want to run. I tried
to increase the baud rate above 9600 but don't think it would work at
the higher rates (maybe it did work at 19200? (Can't remember for
sure) Try and be as simple as possible as I am not great with the
computer.
Question#3: Does anyone know what is the fastest baud rate that data
between the BS2 rev.A and the PC is? And are there any "tricks" or
peculiarities that will help me with the x-fer of data.
Program w2=0
w3=0
input 7
output 0
Tach: pulsin 7,1,w2
w3=w3+1
serout 0,16486,[noparse][[/noparse]dec w2,cr]
debug dec w2, cr
if w3=1000 then Tach
stop
---
In basicstamps@y..., Newzed@a... wrote:
> You use Hyperterminal and "Capture" the file. Capture must be
called before
> you start the Stamp.
>
> Sid
I think I understand your question. The debug command always works at
9600, but the SEROUT command has a flexible baud rate. Doing SEROUT to
pin 16 is about the same as doing DEBUG. You'd look up the baudrate
constant in the manual and set hyperterm to the same. So to keep
everything the same you'd use 84 (9600 baud):
SEROUT 16,84,[noparse][[/noparse]dec w2, CR]
The problem is the dec modifier creates a string of ASCII characters.
This is nice for reading but not nice for maximizing transfer rates. If
w2=4321, for example, your statement will transfer 5 bytes ("4" "3" "2"
"1" CR). Also there is some overhead to account for. Remember, in asynch
protocols like RS232 the stop bit may be as long as you want (we say 1
stop bit, but that really means 1 stop bit minimum).
If I were trying to go as fast as possible, I'd take the dec out and
transmit bytes directly:
SEROUT 16,84,[noparse][[/noparse]w2.highbyte, w2.lowbyte]
Or
SEROUT 16,84,[noparse][[/noparse]b4,b5]
Now you are only transmitting two bytes. Practically, this can be a
problem too, though since if the PC picks up in the middle of a stream,
it won't synchronize. You must make sure the PC is listening before
turning on the Stamp. Any missed characters will destroy your
synchronization.
A compromise would be to send the data as 4 character hex:
SEROUT 16,84[noparse][[/noparse]hex4 w2,CR]
Now your software could sync on the carriage return and you always get 4
characters + the CR.
Timing analysis: An 8 bit byte requires 1 start bit and 1 stop bit so
the total is 10 bits. So even assuming 100% throughput (that is exactly
1 stop bit each time) a 9600 baud data stream is only 960 bytes per
second. That's just over 1mS per byte. In the above example, it would
take just over 5.2mS to transfer the whole thing. In real life, there
will be some overhead, so that number is probably optimistic. Still, if
you have 16mS that should be OK.
If you know your count will always be <$3FFF you could stuff the bytes
to get more efficiency. You'd build two bytes, one would always have bit
7 set and the other would always have it clear. You'd then unpack the
bytes back to a word on the PC. This gives you 14 bits sent in two
bytes. I'll leave that as an exercise "for the reader" :-)
Good luck!
Al Williams
AWC
* Easy RS-232 Prototyping
http://www.al-williams.com/awce/rs1.htm
>
Original Message
> From: katie_sci_project [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=uFxrRnUnd4H3Jchkg1l029zq7JbpH8PpHLJrT6jVYYMIvc2rqSKPZl5yhcbk2GjXdF656uOVzcTuD1sNYFu_Do1kpVlgBA]michael.b.galbreath@b...[/url
> Sent: Friday, December 07, 2001 8:12 AM
> To: basicstamps@yahoogroups.com
> Subject: [noparse][[/noparse]basicstamps] Re: sending data to a file on a PC
>
>
> My card is a BS2 revA. The program below does one thing. It uses
> "PULSIN" it measure pulse width, actually the count (in 2microsecond
> increments) of the pulse width and then transfers this
> "count" (plus a
> carriage return, see debug line below) to the debug screen.
> - max/ min pulse width range from 8 msec. down to 2 msec.
> - The corresponding "counts" are approx. 3960 and 960.
> - The data is being x-ferred to the debug screen BETWEEN pulses. The
> corresponding time between pulses is 65 msec down to 16 msec which I
> "think" should be do-able (at 9600 bits/sec).
>
> Now the question: in the debug screen (see program below), do I
> assume 2 words are being x-ferred (the variable "w2" and the
> "carriage
> return", is the carriage return a WORD?) If I assume this, at the
> debug transfer baud rate default of 9600, it will transfer the two
> words (32 bits) at 32bits / (9600 bits/sec) = 3.3 milliseconds. Is
> this correct? If so, from above I have worse case 16 msec. to
> transfer the data and I should be ok???????
>
> Question#2: Can I get faster baud rates in Hyper Terminal? And if so
> how? I tried to get hyper terminal working yesterday thanks to help
> from some of your suggestions (greatly appreciated) but it would only
> run if debug was "active". By active I mean if I make the debug line
> in the program, text, the hyper terminal doesn't want to run.
> I tried
> to increase the baud rate above 9600 but don't think it would work at
> the higher rates (maybe it did work at 19200? (Can't remember for
> sure) Try and be as simple as possible as I am not great with the
> computer.
>
> Question#3: Does anyone know what is the fastest baud rate that data
> between the BS2 rev.A and the PC is? And are there any "tricks" or
> peculiarities that will help me with the x-fer of data.
>
> Program w2=0
> w3=0
> input 7
> output 0
> Tach: pulsin 7,1,w2
> w3=w3+1
> serout 0,16486,[noparse][[/noparse]dec w2,cr]
> debug dec w2, cr
> if w3=1000 then Tach
> stop
> ---
>
> In basicstamps@y..., Newzed@a... wrote:
> > You use Hyperterminal and "Capture" the file. Capture must be
> called before
> > you start the Stamp.
> >
> > Sid
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the
> Subject and Body of the message will be ignored.
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
--- In basicstamps@y..., "Al Williams" <alw@a...> wrote:
> Hi Katie,
>
> I think I understand your question. The debug command always works
at
> 9600, but the SEROUT command has a flexible baud rate. Doing SEROUT
to
> pin 16 is about the same as doing DEBUG. You'd look up the baudrate
> constant in the manual and set hyperterm to the same. So to keep
> everything the same you'd use 84 (9600 baud):
>
> SEROUT 16,84,[noparse][[/noparse]dec w2, CR]
>
> The problem is the dec modifier creates a string of ASCII
characters.
> This is nice for reading but not nice for maximizing transfer rates.
If
> w2=4321, for example, your statement will transfer 5 bytes ("4" "3"
"2"
> "1" CR). Also there is some overhead to account for. Remember, in
asynch
> protocols like RS232 the stop bit may be as long as you want (we say
1
> stop bit, but that really means 1 stop bit minimum).
>
> If I were trying to go as fast as possible, I'd take the dec out and
> transmit bytes directly:
>
> SEROUT 16,84,[noparse][[/noparse]w2.highbyte, w2.lowbyte]
> Or
> SEROUT 16,84,[noparse][[/noparse]b4,b5]
>
> Now you are only transmitting two bytes. Practically, this can be a
> problem too, though since if the PC picks up in the middle of a
stream,
> it won't synchronize. You must make sure the PC is listening before
> turning on the Stamp. Any missed characters will destroy your
> synchronization.
>
> A compromise would be to send the data as 4 character hex:
>
> SEROUT 16,84[noparse][[/noparse]hex4 w2,CR]
>
> Now your software could sync on the carriage return and you always
get 4
> characters + the CR.
>
> Timing analysis: An 8 bit byte requires 1 start bit and 1 stop bit
so
> the total is 10 bits. So even assuming 100% throughput (that is
exactly
> 1 stop bit each time) a 9600 baud data stream is only 960 bytes per
> second. That's just over 1mS per byte. In the above example, it
would
> take just over 5.2mS to transfer the whole thing. In real life,
there
> will be some overhead, so that number is probably optimistic. Still,
if
> you have 16mS that should be OK.
>
> If you know your count will always be <$3FFF you could stuff the
bytes
> to get more efficiency. You'd build two bytes, one would always have
bit
> 7 set and the other would always have it clear. You'd then unpack
the
> bytes back to a word on the PC. This gives you 14 bits sent in two
> bytes. I'll leave that as an exercise "for the reader" :-)
>
> Good luck!
>
> Al Williams
> AWC
> * Easy RS-232 Prototyping
> http://www.al-williams.com/awce/rs1.htm
>
>
> >
Original Message
> > From: katie_sci_project [noparse][[/noparse]mailto:michael.b.galbreath@b...]
> > Sent: Friday, December 07, 2001 8:12 AM
> > To: basicstamps@y...
> > Subject: [noparse][[/noparse]basicstamps] Re: sending data to a file on a PC
> >
> >
> > My card is a BS2 revA. The program below does one thing. It uses
> > "PULSIN" it measure pulse width, actually the count (in
2microsecond
> > increments) of the pulse width and then transfers this
> > "count" (plus a
> > carriage return, see debug line below) to the debug screen.
> > - max/ min pulse width range from 8 msec. down to 2 msec.
> > - The corresponding "counts" are approx. 3960 and 960.
> > - The data is being x-ferred to the debug screen BETWEEN pulses.
The
> > corresponding time between pulses is 65 msec down to 16 msec which
I
> > "think" should be do-able (at 9600 bits/sec).
> >
> > Now the question: in the debug screen (see program below), do I
> > assume 2 words are being x-ferred (the variable "w2" and the
> > "carriage
> > return", is the carriage return a WORD?) If I assume this, at the
> > debug transfer baud rate default of 9600, it will transfer the two
> > words (32 bits) at 32bits / (9600 bits/sec) = 3.3 milliseconds.
Is
> > this correct? If so, from above I have worse case 16 msec. to
> > transfer the data and I should be ok???????
> >
> > Question#2: Can I get faster baud rates in Hyper Terminal? And if
so
> > how? I tried to get hyper terminal working yesterday thanks to
help
> > from some of your suggestions (greatly appreciated) but it would
only
> > run if debug was "active". By active I mean if I make the debug
line
> > in the program, text, the hyper terminal doesn't want to run.
> > I tried
> > to increase the baud rate above 9600 but don't think it would work
at
> > the higher rates (maybe it did work at 19200? (Can't remember for
> > sure) Try and be as simple as possible as I am not great with the
> > computer.
> >
> > Question#3: Does anyone know what is the fastest baud rate that
data
> > between the BS2 rev.A and the PC is? And are there any "tricks"
or
> > peculiarities that will help me with the x-fer of data.
> >
> > Program w2=0
> > w3=0
> > input 7
> > output 0
> > Tach: pulsin 7,1,w2
> > w3=w3+1
> > serout 0,16486,[noparse][[/noparse]dec w2,cr]
> > debug dec w2, cr
> > if w3=1000 then Tach
> > stop
> > ---
> >
> > In basicstamps@y..., Newzed@a... wrote:
> > > You use Hyperterminal and "Capture" the file. Capture must be
> > called before
> > > you start the Stamp.
> > >
> > > Sid
> >
> >
> > To UNSUBSCRIBE, just send mail to:
> > basicstamps-unsubscribe@y...
> > from the same email address that you subscribed. Text in the
> > Subject and Body of the message will be ignored.
> >
> >
> > Your use of Yahoo! Groups is subject to
> > http://docs.yahoo.com/info/terms/
> >
<michael.b.galbreath@b...> wrote:
> My card is a BS2 revA. The program below does one thing. It uses
> "PULSIN" it measure pulse width, actually the count (in 2microsecond
> increments) of the pulse width and then transfers this "count" (plus
a
> carriage return, see debug line below) to the debug screen.
> - max/ min pulse width range from 8 msec. down to 2 msec.
> - The corresponding "counts" are approx. 3960 and 960.
> - The data is being x-ferred to the debug screen BETWEEN pulses.
The
> corresponding time between pulses is 65 msec down to 16 msec which I
> "think" should be do-able (at 9600 bits/sec).
>
> Now the question: in the debug screen (see program below), do I
> assume 2 words are being x-ferred (the variable "w2" and the
"carriage
> return", is the carriage return a WORD?) If I assume this, at the
> debug transfer baud rate default of 9600, it will transfer the two
> words (32 bits) at 32bits / (9600 bits/sec) = 3.3 milliseconds. Is
> this correct? If so, from above I have worse case 16 msec. to
> transfer the data and I should be ok???????
>
> Question#2: Can I get faster baud rates in Hyper Terminal? And if
so
> how? I tried to get hyper terminal working yesterday thanks to help
> from some of your suggestions (greatly appreciated) but it would
only
> run if debug was "active". By active I mean if I make the debug
line
> in the program, text, the hyper terminal doesn't want to run. I
tried
> to increase the baud rate above 9600 but don't think it would work
at
> the higher rates (maybe it did work at 19200? (Can't remember for
> sure) Try and be as simple as possible as I am not great with the
> computer.
>
> Question#3: Does anyone know what is the fastest baud rate that data
> between the BS2 rev.A and the PC is? And are there any "tricks" or
> peculiarities that will help me with the x-fer of data.
>
> Program w2=0
> w3=0
> input 7
> output 0
> Tach: pulsin 7,1,w2
> w3=w3+1
> serout 0,16486,[noparse][[/noparse]dec w2,cr]
> debug dec w2, cr
> if w3=1000 then Tach
> stop
> ---
>
> In basicstamps@y..., Newzed@a... wrote:
> > You use Hyperterminal and "Capture" the file. Capture must be
> called before
> > you start the Stamp.
> >
thank you very much. do I have to set up a file and then capture the
data to the file or do I capture the data and then x-fer it to a file?
> > Sid
>"PULSIN" it measure pulse width, actually the count (in 2microsecond
>increments) of the pulse width and then transfers this "count" (plus a
>carriage return, see debug line below) to the debug screen.
>- max/ min pulse width range from 8 msec. down to 2 msec.
>- The corresponding "counts" are approx. 3960 and 960.
>- The data is being x-ferred to the debug screen BETWEEN pulses. The
>corresponding time between pulses is 65 msec down to 16 msec which I
>"think" should be do-able (at 9600 bits/sec).
>
>Now the question: in the debug screen (see program below), do I
>assume 2 words are being x-ferred (the variable "w2" and the "carriage
>return", is the carriage return a WORD?) If I assume this, at the
>debug transfer baud rate default of 9600, it will transfer the two
>words (32 bits) at 32bits / (9600 bits/sec) = 3.3 milliseconds. Is
>this correct? If so, from above I have worse case 16 msec. to
>transfer the data and I should be ok???????
Hi Katie, and Katie's Dad,
I'll get very specific about the timings, which I have looked at very
carefully. Reference
<http://www.emesystems.com/BS2rs232.htm#sertime>.
You have,
serout 0,16468,[noparse][[/noparse]dec w2,cr]
[noparse][[/noparse]first issue, you had 16486 as the baud mode--the last two digits
reversed--It makes a big difference!]
Worst case, w2=3690, the serout will transmit 5 bytes, say, ascii
codes $33, $36, $39, $30 and $0D. At 9600 baud, each character
(start bit + 8 bits + stop bit) takes 10/9600 = 1.042 millisecond.
But there are other delays on the Stamp. It takes about 4
milliseconds from the time the stamp hits the serout command to the
instant it actually starts transmitting bytes. That includes the
time the stamp takes to read in the command from eeprom and for it to
format the bytes for transmission as decimal. Also the Stamp puts in
an additional 180 microseconds between bytes. That is in addition to
the the stop bit. So the total time for the command to complete is
about...
4+ 5*1.042 + 4*0.18 = 9.93 milliseconds.
Still, I think the program loop should have ample time to execute in
less than 16 milliseconds, at 9600 baud.
>
>Question#2: Can I get faster baud rates in Hyper Terminal? And if so
>how?
Set the hyperterminal baud rate when you create a "new connection" on
the file menu. You would name your new connection something like
"Stamp19200" and select a connection direct to the com port and
choose the baud rate you want. You can then will have an icon on
your desktop that you can click on to start up with those parameters.
I recall that you can change the baud rate of an existing connection
by editing its Properties (right click on the icon).
>I tried to get hyper terminal working yesterday thanks to help
>from some of your suggestions (greatly appreciated) but it would only
>run if debug was "active". By active I mean if I make the debug line
>in the program, text, the hyper terminal doesn't want to run. I tried
>to increase the baud rate above 9600 but don't think it would work at
>the higher rates (maybe it did work at 19200? (Can't remember for
>sure) Try and be as simple as possible as I am not great with the
>computer.
Your existing serout command sends data to P0 on the stamp, not to
the system serial port. You need this command to send to the system
port at 9600 baud:
serout 16,16468,[noparse][[/noparse]dec w2,cr]
With "16" instead of "0". Debug always sends to the system serial
port at 9600 baud.
>
>Question#3: Does anyone know what is the fastest baud rate that data
>between the BS2 rev.A and the PC is? And are there any "tricks" or
>peculiarities that will help me with the x-fer of data.
The fastest standard baud rate that the BS2 will transmit is 38400:
serout 16,$4006,[noparse][[/noparse]dec w2,cr]
($4006=16390). $4000 transmits at 50000 baud, which is not standard.
However, that will not help as much as you might expect with the
speed, because the overhead delays are constant. At 38400
time to xmt 5 bytes = 4.0 + 5*(10/38400) + 4*0.18 = 4.72 milliseconds.
That is some improvement, but not 4x improvement.
I concur with Al's suggestion of just sending the raw binary data,
serout 16,16468,[noparse][[/noparse]w2.byte0,w2.byte1]
The timings for that are
0.9 + 2*(10/9600)+ 2*0.25 = 1.4 milliseconds.
But then you are left with the task of reconstructing the decimal
data on your PC.
>
>
>Program w2=0
> w3=0
> input 7
> output 0
>Tach: pulsin 7,1,w2
> w3=w3+1
> serout 0,16486,[noparse][[/noparse]dec w2,cr]
> debug dec w2, cr
> if w3=1000 then Tach
> stop
>---
It seems to me that the program will run through once, and when it
hits the "if" command, w3=1, so the program will stop??
Good luck!
-- regards,
Tracy Allen
electronically monitored ecosystems
mailto:tracy@e...
http://www.emesystems.com
> port at 9600 baud:
>
> serout 16,16468,[noparse][[/noparse]dec w2,cr]
> With "16" instead of "0". Debug always sends to the system serial
> port at 9600 baud.
Just a single nit. Port 16 is always inverted no matter what, right? So
technically you should use 84 not 16468, although if I recall it doesn't
matter because the Stamp assumes port 16 is always inverted.
Al Williams
AWC
* 8 channels of PWM
http://www.al-williams.com/awce/pak5.htm
> > port at 9600 baud:
> >
> > serout 16,16468,[noparse][[/noparse]dec w2,cr]
> > With "16" instead of "0". Debug always sends to the system serial
> > port at 9600 baud.
>
>Just a single nit. Port 16 is always inverted no matter what, right? So
>technically you should use 84 not 16468, although if I recall it doesn't
>matter because the Stamp assumes port 16 is always inverted.
>
>Al Williams
>AWC
>* 8 channels of PWM
>http://www.al-williams.com/awce/pak5.htm
>
That's right, it doesn't matter for port 16. Either $54 or $4054
gives the same result--physical pin 1 is always pulled low in the
resting state and goes high for the start bit. However, it does
matter if one is using flow control.
serout 16\15,$4054,[noparse][[/noparse]x]
will not transmit until P15 goes high, while
serout 16\15,$54,[noparse][[/noparse]x]
will not transmit until P15 goes low.
FWIW, I mixed up my units in calculating the speed for
serout 16,16468,[noparse][[/noparse]w2.byte0,w2.byte1]
It should be:
0.9 + 2*(10/9600)*1000+ 2*0.25 = 3.48 milliseconds.
not
0.9 + 2*(10/9600)+ 2*0.25 = 1.4 milliseconds.
-- Tracy Allen
eme systems
2229 Fifth St.
Berkeley CA 94710
mailto:tracy@e...
510-848-5725
fax:510-848-5748