katies science project
Archiver
Posts: 46,084
When you find yourself asking such a variety of questions, it's time
to find something--anything--that works right and then expand from
that foundation. Building on Al's suggestion, here's a minimal
implementation of your data transfer:
w2=1000
Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
stop
Did that work right? Did hyperterminal get the expected 1000? If
and when it does, move on:
w2=0
Tach: w2 = w2 + 1
Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
if w2<10 then tach
stop
Did this give you the expected results? When that's working, try
one sample of some real data:
w2=0
input 7 ' (not necessary, pins default to input)
output 16 ' (not necessary or even syntatically legal w/ 16)
Tach: pulsin 7,1,w2
Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
stop
Does this reliably produce a reasonable result? If not, maybe your
sensor is looking for the wrong logic level or maybe needs
debouncing or a pulldown resistor. When satisfied, try the whole
enchilada:
w2=0
w3=0
Tach: pulsin 7,1,w2
Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
w3 = w3 + 1
if w3<1000 then tach
stop
BTW, are you synchronizing the start of the program with the onset
of the pulse stream? Pulsin will only wait up to ~0.131 seconds for
a pulse to arrive, then gives up. This modification may ease your
testing (but cause you to miss the very first pulse):
w2=0
w3=0
awaitFirstPulse: IF IN7 = 0 THEN awaitFirstPulse
Tach: pulsin 7,1,w2
Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
w3 = w3 + 1
if w3<1000 then tach
stop
to find something--anything--that works right and then expand from
that foundation. Building on Al's suggestion, here's a minimal
implementation of your data transfer:
w2=1000
Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
stop
Did that work right? Did hyperterminal get the expected 1000? If
and when it does, move on:
w2=0
Tach: w2 = w2 + 1
Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
if w2<10 then tach
stop
Did this give you the expected results? When that's working, try
one sample of some real data:
w2=0
input 7 ' (not necessary, pins default to input)
output 16 ' (not necessary or even syntatically legal w/ 16)
Tach: pulsin 7,1,w2
Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
stop
Does this reliably produce a reasonable result? If not, maybe your
sensor is looking for the wrong logic level or maybe needs
debouncing or a pulldown resistor. When satisfied, try the whole
enchilada:
w2=0
w3=0
Tach: pulsin 7,1,w2
Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
w3 = w3 + 1
if w3<1000 then tach
stop
BTW, are you synchronizing the start of the program with the onset
of the pulse stream? Pulsin will only wait up to ~0.131 seconds for
a pulse to arrive, then gives up. This modification may ease your
testing (but cause you to miss the very first pulse):
w2=0
w3=0
awaitFirstPulse: IF IN7 = 0 THEN awaitFirstPulse
Tach: pulsin 7,1,w2
Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
w3 = w3 + 1
if w3<1000 then tach
stop
Comments
> Thanks for the input. One quick question, I noticed you used hex
> rather than binary, which is faster?
The data transmission rate (baud rate)is the same in both cases, but
the data volume is four times greater with BIN, because you're
sending eight ASCII bytes (ASCII '0' or '1') to represent one data
byte. If you SEROUT in HEX, you send only two ASCII bytes ("00" thru
"FF") to represent one data byte.
> Also why do I get at least some data (good or bad) with a baud rate
> of 9600 but at higher baud rates I get what appears to be random
> symbols? Can I x-fer data at higher baud rates?
Your PC and hyperterminal should be able to handle the fastest data
your Stamp can throw at it, as long as you're using valid baud
rates. Transmitting artificial data rather than data from your
sensor may help to answer this question i.e., am I sending goofy
data or are the data being garbled in transmission? Once again,
does the following work correctly?
w2=0
onceAgain: Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
w2 = w2 + 1
GOTO onceAgain
Does it also work with faster baud rates? What are your non-working,
higher speed baud rate specifier values?
Regards,
Steve
I have a BS2 card. Again, all I'm trying to do is obtain 1 lousy
piece of information! That's it, just 1 lousy piece of data! I'm
going totally nuts with it. My Program is listed below. My
questions are:
#1) Look at the "serout" line of the program below, I incorporated
the binary format for the output as Al and Tracy suggested, for the
fastest transfer format. Please look at that line and tell me if you
have any more suggestions for transfer speed.
-when I use the "debug" screen to look at the data I should
have 15 data points but only have 5. Also, the data points don't
make sense, the pulses are getting faster and faster (shorter and
shorter) but the data dosen't reflect this. I "think" that the x-
fer speed for debug is to slow to capture all of the data. Could
this be true? Does "debug" run slower than the "hyper terminal"
screen?
#2) When I try to run at baud rates faster than 9600, I get funky
symbols instead of data. What's up with that? Is there any way to
speed up this? What could I be doing wrong.
#3) My photo diode has rise and fall times in the nano-second range
but what about the microprocessor and/ or the "pulsin" command? Is
the electronic board good enough/ fast enough the capture the data?
Eventually I will be sampling rpm (rps) of a rotating disc. But right
now I am "calibrating" it by measuring gravity over a 30 inch drop.
My pulse widths range from 80 msec down to 20 msec. Surely the BS2
can capture this?
I am at wit's end. I need to resolve these program problems to catch
the data for my daughters science project.
w2=0
w3=0
input 7
output 16
Tach: pulsin 7,1,w2
Serout 16,84 [noparse][[/noparse]bin w2.byte1,bin w2.byte0,":"]
`debug bin w2.byte1,bin w2.byte0,cr
if w3<1000 then tach
stop
format for transmission to a custom program. What you are doing is
sending ASCII 1's and 0's which is not optimal. Also, the way you are
sending them suppresses leading zeros and you are running them together.
Try:
Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
This should show up nicely on the debug screen (6 characters)
Debug by default does 9600 baud. I think you may be able to change the
terminal screen on the latest software.
The rise and fall time isn't the issue -- the pulse duration is. The
Stamp won't measure nanoseconds, but that shouldn't be an issue for you.
Regards,
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=1SEtE1hHM13BGgS1h0JhbnxH1Zqq2u6CxPBd4_tO7i0_ZWnSM2N1HtOPUIIwpZz7MC7uTvCPYjyQUnmOJdz1KpCQXfFb]michael.b.galbreath@b...[/url
> Sent: Sunday, December 09, 2001 9:13 PM
> To: basicstamps@yahoogroups.com
> Subject: [noparse][[/noparse]basicstamps] katies science project
>
>
> HELP! AGAIN!
> I have a BS2 card. Again, all I'm trying to do is obtain 1 lousy
> piece of information! That's it, just 1 lousy piece of data! I'm
> going totally nuts with it. My Program is listed below. My
> questions are:
>
> #1) Look at the "serout" line of the program below, I incorporated
> the binary format for the output as Al and Tracy suggested, for the
> fastest transfer format. Please look at that line and tell me if you
> have any more suggestions for transfer speed.
> -when I use the "debug" screen to look at the data I should
> have 15 data points but only have 5. Also, the data points don't
> make sense, the pulses are getting faster and faster (shorter and
> shorter) but the data dosen't reflect this. I "think" that
> the x- fer speed for debug is to slow to capture all of the
> data. Could
> this be true? Does "debug" run slower than the "hyper
> terminal" screen?
>
> #2) When I try to run at baud rates faster than 9600, I get funky
> symbols instead of data. What's up with that? Is there any way to
> speed up this? What could I be doing wrong.
>
> #3) My photo diode has rise and fall times in the nano-second range
> but what about the microprocessor and/ or the "pulsin" command? Is
> the electronic board good enough/ fast enough the capture the
> data? Eventually I will be sampling rpm (rps) of a rotating
> disc. But right
> now I am "calibrating" it by measuring gravity over a 30 inch drop.
> My pulse widths range from 80 msec down to 20 msec. Surely the BS2
> can capture this?
>
> I am at wit's end. I need to resolve these program problems to catch
> the data for my daughters science project.
>
> w2=0
> w3=0
> input 7
> output 16
> Tach: pulsin 7,1,w2
> Serout 16,84 [noparse][[/noparse]bin w2.byte1,bin w2.byte0,":"]
> `debug bin w2.byte1,bin w2.byte0,cr
> if w3<1000 then tach
> stop
>
>
>
> 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/
>
rather than binary, which is faster? Also why do I get at least some
data (good or bad) with a baud rate of 9600 but at higher baud
rates I get what appears to be random symbols? Can I x-fer data at
higher baud rates?
--- In basicstamps@y..., "S Parkis" <parkiss@e...> wrote:
> When you find yourself asking such a variety of questions, it's time
> to find something--anything--that works right and then expand from
> that foundation. Building on Al's suggestion, here's a minimal
> implementation of your data transfer:
>
> w2=1000
> Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> stop
>
> Did that work right? Did hyperterminal get the expected 1000? If
> and when it does, move on:
>
> w2=0
> Tach: w2 = w2 + 1
> Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> if w2<10 then tach
> stop
>
> Did this give you the expected results? When that's working, try
> one sample of some real data:
>
> w2=0
> input 7 ' (not necessary, pins default to input)
> output 16 ' (not necessary or even syntatically legal w/ 16)
> Tach: pulsin 7,1,w2
> Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> stop
>
> Does this reliably produce a reasonable result? If not, maybe your
> sensor is looking for the wrong logic level or maybe needs
> debouncing or a pulldown resistor. When satisfied, try the whole
> enchilada:
>
> w2=0
> w3=0
> Tach: pulsin 7,1,w2
> Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> w3 = w3 + 1
> if w3<1000 then tach
> stop
>
> BTW, are you synchronizing the start of the program with the onset
> of the pulse stream? Pulsin will only wait up to ~0.131 seconds for
> a pulse to arrive, then gives up. This modification may ease your
> testing (but cause you to miss the very first pulse):
>
> w2=0
> w3=0
> awaitFirstPulse: IF IN7 = 0 THEN awaitFirstPulse
> Tach: pulsin 7,1,w2
> Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> w3 = w3 + 1
> if w3<1000 then tach
> stop
manual. Even the bs2sx has a warning about baud rates 9600 and above. i use
the bs2sx to send lots of data at 9600, but always receive data in small
packets and use a checksum to check correctness. If you are using a bs2, you
will have some trouble receiving at 9600. If possible, drop your baud rate
when receiving to 4800 (not always practical I know).
Chris
Original Message
From: katie_sci_project [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=5OIhhL5XTVOCBtucUD5uAMbJeK8O1TZ0jIQO3xDqHRmP4Gl982KUh8kaHVN5QCm7jXUc4oRr-vb0xG_4jYr3CN26dgPOo9A]michael.b.galbreath@b...[/url
Sent: Monday, 10 December 2001 7:56 PM
To: basicstamps@yahoogroups.com
Subject: [noparse][[/noparse]basicstamps] Re: katies science project
Thanks for the input. One quick question, I noticed you used hex
rather than binary, which is faster? Also why do I get at least some
data (good or bad) with a baud rate of 9600 but at higher baud
rates I get what appears to be random symbols? Can I x-fer data at
higher baud rates?
--- In basicstamps@y..., "S Parkis" <parkiss@e...> wrote:
> When you find yourself asking such a variety of questions, it's time
> to find something--anything--that works right and then expand from
> that foundation. Building on Al's suggestion, here's a minimal
> implementation of your data transfer:
>
> w2=1000
> Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> stop
>
> Did that work right? Did hyperterminal get the expected 1000? If
> and when it does, move on:
>
> w2=0
> Tach: w2 = w2 + 1
> Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> if w2<10 then tach
> stop
>
> Did this give you the expected results? When that's working, try
> one sample of some real data:
>
> w2=0
> input 7 ' (not necessary, pins default to input)
> output 16 ' (not necessary or even syntatically legal w/ 16)
> Tach: pulsin 7,1,w2
> Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> stop
>
> Does this reliably produce a reasonable result? If not, maybe your
> sensor is looking for the wrong logic level or maybe needs
> debouncing or a pulldown resistor. When satisfied, try the whole
> enchilada:
>
> w2=0
> w3=0
> Tach: pulsin 7,1,w2
> Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> w3 = w3 + 1
> if w3<1000 then tach
> stop
>
> BTW, are you synchronizing the start of the program with the onset
> of the pulse stream? Pulsin will only wait up to ~0.131 seconds for
> a pulse to arrive, then gives up. This modification may ease your
> testing (but cause you to miss the very first pulse):
>
> w2=0
> w3=0
> awaitFirstPulse: IF IN7 = 0 THEN awaitFirstPulse
> Tach: pulsin 7,1,w2
> Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> w3 = w3 + 1
> if w3<1000 then tach
> stop
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..., "Chris Anderson" <fes@g...> wrote:
> Stamps don't like higher baud rates, it states that in the latest
stamp
> manual. Even the bs2sx has a warning about baud rates 9600 and
above. i use
> the bs2sx to send lots of data at 9600, but always receive data in
small
> packets and use a checksum to check correctness. If you are using a
bs2, you
> will have some trouble receiving at 9600. If possible, drop your
baud rate
> when receiving to 4800 (not always practical I know).
> Chris
>
>
Original Message
> From: katie_sci_project [noparse][[/noparse]mailto:michael.b.galbreath@b...]
> Sent: Monday, 10 December 2001 7:56 PM
> To: basicstamps@y...
> Subject: [noparse][[/noparse]basicstamps] Re: katies science project
>
>
>
> Thanks for the input. One quick question, I noticed you used hex
> rather than binary, which is faster? Also why do I get at least
some
> data (good or bad) with a baud rate of 9600 but at higher baud
> rates I get what appears to be random symbols? Can I x-fer data at
> higher baud rates?
>
>
> --- In basicstamps@y..., "S Parkis" <parkiss@e...> wrote:
> > When you find yourself asking such a variety of questions, it's
time
> > to find something--anything--that works right and then expand from
> > that foundation. Building on Al's suggestion, here's a minimal
> > implementation of your data transfer:
> >
> > w2=1000
> > Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> > stop
> >
> > Did that work right? Did hyperterminal get the expected 1000? If
> > and when it does, move on:
> >
> > w2=0
> > Tach: w2 = w2 + 1
> > Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> > if w2<10 then tach
> > stop
> >
> > Did this give you the expected results? When that's working, try
> > one sample of some real data:
> >
> > w2=0
> > input 7 ' (not necessary, pins default to input)
> > output 16 ' (not necessary or even syntatically legal w/ 16)
> > Tach: pulsin 7,1,w2
> > Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> > stop
> >
> > Does this reliably produce a reasonable result? If not, maybe
your
> > sensor is looking for the wrong logic level or maybe needs
> > debouncing or a pulldown resistor. When satisfied, try the whole
> > enchilada:
> >
> > w2=0
> > w3=0
> > Tach: pulsin 7,1,w2
> > Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> > w3 = w3 + 1
> > if w3<1000 then tach
> > stop
> >
> > BTW, are you synchronizing the start of the program with the onset
> > of the pulse stream? Pulsin will only wait up to ~0.131 seconds
for
> > a pulse to arrive, then gives up. This modification may ease your
> > testing (but cause you to miss the very first pulse):
> >
> > w2=0
> > w3=0
> > awaitFirstPulse: IF IN7 = 0 THEN awaitFirstPulse
> > Tach: pulsin 7,1,w2
> > Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> > w3 = w3 + 1
> > if w3<1000 then tach
> > stop
>
>
> 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/
Let's say I write the following
C var byte
C=10
SEROUT ....,[noparse][[/noparse]C] ' .... = whatever
Now, this is going to literally write a 10 out the serial port. If you
look at this with hyperterminal, it will be a line feed because ASCII 10
is a line feed. 65 is an A, 48 is a 0 character, etc.
If you have a terminal program set to not add any characters (like extra
line feeds) you can capture this stream to a file and use the right
tools to pull the bytes back out (for example, under Unix or Cygwin use
od on the file). A custom program can do this too. This is what we meant
the first time by "sending binary" since the data isn't interpretable as
characters. Looking at the output on a terminal will look like garbage.
Now the other way to write this is:
SEROUT ....,[noparse][[/noparse]bin C]
Or
SEROUT ....,[noparse][[/noparse]dec C]
Or
SEROUT ....,[noparse][[/noparse]hex C]
Etc.
This formats the data into ASCII bytes. So the first example write
"1010" which is 4 bytes (49, 48, 49, 48)
The second writes two byte "10" (49,48).
The third example writes one byte "A" (65).
However, if you output say 10, and 0, you'd get "A" "0" which is the
same thing you'd get if C=160 ($A0). That's why in the last message I
put a space in the output to make it more readable.
You can also have the Stamp pad to a particular number of digits. So:
SEROUT ....,[noparse][[/noparse]hex2 C]
Would write out 0A00 (4 bytes, 48, 65, 48, 48) if you wrote a 10 and a 0
out (which would require 2 calls of the above statement -- or if you
write [noparse][[/noparse]hex2 C, hex2 C1]). Now you can tell which is which because each
output has 2 characters all the time.
In general, hex will be more compact than the other formatted modes. To
send one byte you'd need:
8 - binary characters (bin)
3 - decimal characters (dec)
2 - hex characters (hex)
Or, if you forego the ability to read the output you can leave off all
the modifiers and get 1 byte per character. This isn't always possible
in real life since some devices want to consume certain characters (like
XON/XOFF) or want to ignore characters with a 0 value. However, if you
control both ends of the link you can usually make it work. On the other
hand, if you can afford 2 bytes per byte, sending ASCII makes it much
easier.
Hope that helps.
The Stamp does have some trouble reading data at high speeds but it
shouldn't have any trouble sending at higher speeds. There are two
factors that come into play. First, the Stamp may not be able to process
one character in time to read the second character. This isn't the
processor's fault (I don't think), but rather the fault of the serial
EEPROM used to store programs. SERIN/SEROUT command may span several
bytes. When sending this isn't a big problem. We talk about "1 stop bit"
or "2 stop bits" but this is really a sham. A stop bit is just the RS232
line being idle for a MINIMUM amount of time. If I send an A and then
wait 1 hour and send another character than I just generated a 1 hour
stop bit. So when sending, the Stamp's delay between characters just
looks like a long stop bit. The other side doesn't care because stop
bits can be any length as long as it isn't less than the minimum.
Sometimes setting a fast device like a PC to use 2 stop bits can help
when sending to a slower device, but for the slow device to send, it
should be no problem.
The other problem you have with higher speeds is accuracy of the baud
rate clock. According to the Stamp manual, a BS2's baud rate parameter
is:
Baudnumber = 1,000,000/baud - 20
So the actual baud rate for a given baud number is (remember algebra?):
1,000,000
Baudnumber + 20
So 84 is 9600 baud, right? No. Do the math and you'll find out it is
really 9615.4 baud! That's a .16% error which is probably OK (although
I've had devices that also used software UARTs that required me to shift
to a nearby number like 85 (-.8%).
Anyway, sending at higher that 9600 ought to be OK as long as the
receiver is fairly tolerant speed wise. The throughput (as Tracy pointed
out) won't be very good because there is more time between characters
than you spend sending characters at high speeds. The analogy is my wife
who drives through a green light, sees a red light up ahead, and still
accelerates to full speed :-) Then she slams on the brakes and waits for
the light to change. My mechanic had never seen a car with 25000 miles
on it with brakes completely shot like that. Same thing here - You can
send each character as fast as you want, but then you have to wait
before you can send the next character.
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=jGGXdmKwVpdSFv7jTZiq9oJLQGyzna4T7ZPZGztH5uYusKGov6G1FkdIU4p8m48mfVBEwdzpeVuA1SUkRwx03jHhgs3wNXFv]michael.b.galbreath@b...[/url
> Sent: Monday, December 10, 2001 5:56 AM
> To: basicstamps@yahoogroups.com
> Subject: [noparse][[/noparse]basicstamps] Re: katies science project
>
>
>
> Thanks for the input. One quick question, I noticed you used hex
> rather than binary, which is faster? Also why do I get at least some
> data (good or bad) with a baud rate of 9600 but at higher baud
> rates I get what appears to be random symbols? Can I x-fer data at
> higher baud rates?
>
>
> --- In basicstamps@y..., "S Parkis" <parkiss@e...> wrote:
> > When you find yourself asking such a variety of questions,
> it's time
> > to find something--anything--that works right and then expand from
> > that foundation. Building on Al's suggestion, here's a minimal
> > implementation of your data transfer:
> >
> > w2=1000
> > Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> > stop
> >
> > Did that work right? Did hyperterminal get the expected 1000? If
> > and when it does, move on:
> >
> > w2=0
> > Tach: w2 = w2 + 1
> > Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> > if w2<10 then tach
> > stop
> >
> > Did this give you the expected results? When that's
> working, try one
> > sample of some real data:
> >
> > w2=0
> > input 7 ' (not necessary, pins default to input)
> > output 16 ' (not necessary or even syntatically legal w/ 16)
> > Tach: pulsin 7,1,w2
> > Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> > stop
> >
> > Does this reliably produce a reasonable result? If not, maybe your
> > sensor is looking for the wrong logic level or maybe needs
> debouncing
> > or a pulldown resistor. When satisfied, try the whole
> > enchilada:
> >
> > w2=0
> > w3=0
> > Tach: pulsin 7,1,w2
> > Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> > w3 = w3 + 1
> > if w3<1000 then tach
> > stop
> >
> > BTW, are you synchronizing the start of the program with
> the onset of
> > the pulse stream? Pulsin will only wait up to ~0.131 seconds for a
> > pulse to arrive, then gives up. This modification may ease your
> > testing (but cause you to miss the very first pulse):
> >
> > w2=0
> > w3=0
> > awaitFirstPulse: IF IN7 = 0 THEN awaitFirstPulse
> > Tach: pulsin 7,1,w2
> > Serout 16,84 [noparse][[/noparse]hex2 w2.byte1," ",hex2 w2.byte0,":"]
> > w3 = w3 + 1
> > if w3<1000 then tach
> > stop
>
>
> 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/
>
Puzzling, I hope for Katies' sake that you do not tear out all your hair!
I am wondering about the calibration method, using gravity.
Presumably, the experiment will not repeat very often, so your
existing program is going to display a lot of garbage during the
"dead times. Here is what I would suggest:
w3=0
Tach:
pulsin 7,1,w2
branch w2,[noparse][[/noparse]tach]
serout 16,84, [noparse][[/noparse]dec4 w2,tab]
w3=w3+1
if w3<1000 then tach
stop
The pulsin command waits up to 0.131 second for the leading edge of
the pulse. If a pulse does not come along, it bails out and the
value of w2 will be zero. If that happens, the branch command will
immediately send the program back to Tach:. The branch command is
faster than If-then in this case. There is no reason to execute the
serout command if there is no data. The serout takes a lot of time
that would be better spent looking for the pulse. This should not
be an issue when you are using this as a tachometer with a repetitive
signal < 0.131 seconds.
Even with the decimal modifier and serout at 9600 baud, the loop
should execute in well under 16 milliseconds.
Are you sure that the output from your photodetector is correct and
nice and clean--what circuit? The pulsin command is written to time
a clean low-high-low pulse on P7.
-- regards,
Tracy Allen
electronically monitored ecosystems
mailto:tracy@e...
http://www.emesystems.com
often but let me explain what I'm doing by calibrating using gravity.
I have a strip of thick poster board with slots cut into it, .25
inches long, centered every 2 inches apart (there are 15 slots in the
poster board strip and the strip is approx 36 inches long). I have a
2x4 board, 13 inches long with a rectangular slot cut through it, full
length. I attach a weight to the end of the poster board strip, the
slot acts as a track for the poster board to fall through. There is a
"U" shaped optical sensor with a light source in one side and a light
receiver on the other side. The sensor is at the end of the slot and
oriented such that it will trigger on the slots. So I "should" get 15
data points pretty quickly (at 30 inches the strip is traveling at
approx. 115 inches per second) when I release the weight.
--- In basicstamps@y..., Tracy Allen <tracy@e...> wrote:
> Dear Katies' dad,
>
> Puzzling, I hope for Katies' sake that you do not tear out all your
hair!
>
> I am wondering about the calibration method, using gravity.
> Presumably, the experiment will not repeat very often, so your
> existing program is going to display a lot of garbage during the
> "dead times. Here is what I would suggest:
>
> w3=0
> Tach:
> pulsin 7,1,w2
> branch w2,[noparse][[/noparse]tach]
> serout 16,84, [noparse][[/noparse]dec4 w2,tab]
> w3=w3+1
> if w3<1000 then tach
> stop
>
> The pulsin command waits up to 0.131 second for the leading edge of
> the pulse. If a pulse does not come along, it bails out and the
> value of w2 will be zero. If that happens, the branch command will
> immediately send the program back to Tach:. The branch command is
> faster than If-then in this case. There is no reason to execute the
> serout command if there is no data. The serout takes a lot of time
> that would be better spent looking for the pulse. This should not
> be an issue when you are using this as a tachometer with a
repetitive
> signal < 0.131 seconds.
>
> Even with the decimal modifier and serout at 9600 baud, the loop
> should execute in well under 16 milliseconds.
>
> Are you sure that the output from your photodetector is correct and
> nice and clean--what circuit? The pulsin command is written to time
> a clean low-high-low pulse on P7.
>
> -- regards,
> Tracy Allen
> electronically monitored ecosystems
> mailto:tracy@e...
> http://www.emesystems.com
>often but let me explain what I'm doing by calibrating using gravity.
>I have a strip of thick poster board with slots cut into it, .25
>inches long, centered every 2 inches apart (there are 15 slots in the
>poster board strip and the strip is approx 36 inches long). I have a
>2x4 board, 13 inches long with a rectangular slot cut through it, full
>length. I attach a weight to the end of the poster board strip, the
>slot acts as a track for the poster board to fall through. There is a
>"U" shaped optical sensor with a light source in one side and a light
>receiver on the other side. The sensor is at the end of the slot and
>oriented such that it will trigger on the slots. So I "should" get 15
>data points pretty quickly (at 30 inches the strip is traveling at
>approx. 115 inches per second) when I release the weight.
Okay, that makes it much more clear what is going on. But does not
resolve the problem. Do you have an oscilloscope or a voltmeter or
other means to verify that the 0-5 volt signal is getting to input
pin P7 on the stamp? You should be able to run the following program
and see the value change from 0 to 1 as you move the strip slowly
through the slot.
loop:
debug bin1 in7
goto loop
Does it show "0" or "1" when the path is clear?
Are there any components in addition to the module?
Response at low speed does not guarantee response at higher speed.
As Steve suggested, go for the minimal program and get that working.
Tach:
pulsin 7,1,w2
branch w2,[noparse][[/noparse]tach]
debug dec w2,cr
goto tach
Is your pulsin command supposed to be measuring the time for the
0.25" slots or for the 2" dark bands?
At 3:12 AM +0000 12/10/01, katie_sci_project wrote:
>But right
>now I am "calibrating" it by measuring gravity over a 30 inch drop.
>My pulse widths range from 80 msec down to 20 msec. Surely the BS2
>can capture this?
From 0.5 a t^2 = d I get the time for it to fall 30" as t=0.23
second, and the terminal velocity as 7.4 feet per second, =88 inches
per second? At that rate the last 2" dead band should take about 22
milliseconds, and the last 0.25" slot about 2.8 milliseconds. (Why
do I get different numbers than you did?) Those pulses are well
within the capability of pulsin, but 2.8 milliseconds is pressing the
envelope to execute the whole tach loop, that is, if pulsin is set to
measure the time for the 2" dark band to pass.
-- best regards
Tracy Allen
electronically monitored ecosystems
http://www.emesystems.com
mailto:tracy@e...