The multiplexer idea is a good one, but if you are using a 28P device
(PIC16F876) with two pins dedicated to TX and RX, then you will have enough
pins available to read all the ports without a demux. With a PIC16F627/8,
if you use the MCLR pin as an input, you will STILL have EXACTLY enough
pins to read all the shafts, and the data can go out thru RX/TX (best
approach).

The way to do this is to read the ports in and save the two bytes precisely
every 5ms or less. This ensures that you will be able to detect an approx
19ms pulse. Compare the LAST bit with the THIS bit for each input, and
toggle on the rising edge (or whatever you decide). Then advance THAT
shaft's counter. Its really easy. Be sure to check for ALL bits; more than
one might have changed.

The thing to watch for when dealing with cables to shaft encoders and / or
hall sensors is that they are notoriously noisy, and can pick up cellphone
noise and other things very easily. I'd put an RF choke on EACH input
(about 0.5uH) and a tiny bypass cap after that (100pf is fine) AND a 7V
Tranzorber on each input. Make sure that your pullups are stiff enough to
provide the PIC with a clean signal. Finally, use overall shielded cable to
&n from the hall sensors.

Sounds like a fun project, take a stab at it. The PIC will do this job and
loaf 90% of the time. I'd use a ramic resonator as a clock, and 4mhz should
be enough unless you need to do other things.

--Bob


At 04:59 PM 9/2/2003 -0500, you wrote:
>Hi all,
>
>I am a hobbyist who is trying to help a friend with a project. He
>wants to monitor the speed of about a dozen shafts on his potato
>digger. The shafts normally run around 200 rpm, but each shaft may
>run at a different rpm. One or more shafts may even stop if the
>digger is overloaded. I am wondering which approach you might
>consider most feasible to monitor so many shafts. On each shaft is a
>16 tooth sprocket and a hall effect sensor. I already have a 5.7"
>LCD display from Amulet Technologies to display the speeds.
>
>One idea I have is to use one PIC16F877 and a 16 to 1 multiplexer
>(or two 8 to 1 multiplexers if a 16 to 1 doesn't exist) and measure
>the pulse period of each shaft in turn. The trouble with this is if
>a shaft is turning at, say, 30 rpm, it may take a long time to get a
>reading. If I am correct, with a 4MHz clock and Capture Mode set to
>every fourth rising edge, it would take a half second; 15 rpm would
>take a full second. If more than one shaft is turning so slowly, I
>think the time it would take to update all the shaft speeds would be
>unacceptably long. If I set Capture Mode to occur on every rising
>edge instead, this situation improves but I'm guessing my RPM's may
>show a lot of fluctuation as the input frequency may not be stable.
>
>Another idea is to dedicate a PIC that has a UART to each shaft and
>poll each of them in turn. Those PIC's could either measure the
>pulse periods or count the pulses. I have some PIC16F628's available
>to try.
>
>Any other ideas or advice? I've enjoyed reading the posts for a few
>years now, and finally am finding the time to try a few projects.
>
>Thanks in advance,
>Patrick Murphy
>James Valley Colony
>
>P.S. I have put together an Excel spreadsheet showing Hertz to RPM
>and pulse periods using the various Capture Modes and a 4MHz (or
>other) clock. If anyone is interested in it, let me know off list
>and I would be glad to e-mail a copy to you.
>
>--
>http://www.piclist.com#nomail Going offline? Don't AutoReply us!
>email listserv@mitvma.mit.edu with SET PICList DIGEST in the body

--------------
Bob Axtell
PIC Hardware & Firmware Dev
Tucson, AZ
1-512-219-2363

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body