Post by thread:[PIC]: Challenge! (Everyone loves a...)

Hi all, Here's a challenge (actually I'm looking for free development help :) I need to convert a 16-bit number (which holds number of cycles between pulses on a port pin) to RPM. Operating a 16c71 at 4MHz. For example, Time:2 holds a value of 0x7510 meaning there are 117 counts of 256 Tcy each at 1us, plus 16 extra Tcy, giving a speed of 2002 RPM. Eh, doesn't sound TOO tough, you say? Here's the kicker: I have 50 lines in which to write this. I have access to 16-bit division code already in the program, if that helps. Any, and I do mean ANY, advice is welcome. --Andrew _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email spam_OUTlistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

When you say "I have 50 lines in which to write this." do you mean 1) You have one 50 words of program memory available for this routine 2) The routine must complete in 50 cycles 3) Both 1 and 2 -Adam Drew Vassallo wrote: {Quote hidden}> > Hi all, > > Here's a challenge (actually I'm looking for free development help :) > > I need to convert a 16-bit number (which holds number of cycles between > pulses on a port pin) to RPM. Operating a 16c71 at 4MHz. > > For example, Time:2 holds a value of 0x7510 meaning there are 117 counts of > 256 Tcy each at 1us, plus 16 extra Tcy, giving a speed of 2002 RPM. > Eh, doesn't sound TOO tough, you say? > > Here's the kicker: I have 50 lines in which to write this. > > I have access to 16-bit division code already in the program, if that helps. > > Any, and I do mean ANY, advice is welcome. > > --Andrew > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > -- > http://www.piclist.com#nomail Going offline? Don't AutoReply us! > email .....listservKILLspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

>When you say "I have 50 lines in which to write this." do you mean >1) You have one 50 words of program memory available for this routine >2) The routine must complete in 50 cycles >3) Both 1 and 2 50 words of program memory. I'd prefer it to complete in less than a few hundred cycles if possible, but at this point I'll take anything. I know I'm asking a lot. I had thought of just counting the number of pulses in a given time frame (e.g., .25 seconds), then multiplying it out to a full minute, but the error would be more than a few hundred RPM, which produces unacceptable error at slower speeds. I'd have to count pulses for at least a full second or two to get reasonable accuracy this way. At 4MHz, this would be a 24-bit number, which isn't too bad. I was just hoping there was an easier way. Then there's always the problem of converting it to BCD :) --Andrew _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email .....listservKILLspam.....mitvma.mit.edu with SET PICList DIGEST in the body

On Thu, 21 Dec 2000, Drew Vassallo wrote: > Hi all, > > Here's a challenge (actually I'm looking for free development help :) > > I need to convert a 16-bit number (which holds number of cycles between > pulses on a port pin) to RPM. Operating a 16c71 at 4MHz. > > For example, Time:2 holds a value of 0x7510 meaning there are 117 counts of > 256 Tcy each at 1us, plus 16 extra Tcy, giving a speed of 2002 RPM. > Eh, doesn't sound TOO tough, you say? > > Here's the kicker: I have 50 lines in which to write this. > > I have access to 16-bit division code already in the program, if that helps. > > Any, and I do mean ANY, advice is welcome. How accurate does it need to be? Your scaling factor is about 1/15. 1/15 = 1/ (16-1) ~= 1/16(1 + 1/16) Division by 16 is trivial: swapf t2h,f swapf t2l,f movlw 0x0f andwf t2l,f andwf t2h,w xorwf t2h,w iorwf t2l,f ; xorwf t2h,f ; not needed because of trick below ; now add 1/16 of the above to itself swapf t2h,w addwf t2l,f movlw 0x0f andwf t2h,f skpnc incf t2h,f One more instruction then the mystical 12 barrier - suggesting there's an optimization lurking somewhere. Now, the challenge is to figure out how the above code works. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

> I know I'm asking a lot. I had thought of just counting the number of > pulses in a given time frame (e.g., .25 seconds), then > multiplying it out to > a full minute, but the error would be more than a few hundred > RPM, which > produces unacceptable error at slower speeds. I'd have to > count pulses for > at least a full second or two to get reasonable accuracy this > way. At 4MHz, > this would be a 24-bit number, which isn't too bad. I was > just hoping there > was an easier way. Count pulses for a period. Based on the number of pulses in that period (lots for high RPM, few for low RPM) decide on the size of your window. 1-2 seconds for low speed, .25 for high speed. Dynamic window size. Re-think the window size at the end of the window (just loop). Perhaps have several window sizes. May be easier than dealing with 24-bit numbers. Just a thought... -Rob -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listservspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

If its just divide by 15, then the part of Nik's brain that is on my web server says: ; ACC = ACC * 0.066666 ; Temp = TEMP ; ACC size = 16 bits ; Error = 0.5 % ; Bytes order = little endian ; Round = no ; ALGORITHM: ; Clear accumulator ; Add input / 16 to accumulator ; Add input / 256 to accumulator ; Move accumulator to result ; ; Approximated constant: 0.0664063, Error: 0.389629 % ; Input: ACC0 .. ACC1, 16 bits ; Output: ACC0 .. ACC1, 13 bits ; Code size: 28 instructions cblock ACC0 ACC1 TEMP0 TEMP1 endc ;copy accumulator to temporary movf ACC1, w movwf TEMP1 movf ACC0, w movwf TEMP0 ;shift accumulator right 4 times swapf ACC0, w andlw 0x0F movwf ACC0 swapf ACC1, w movwf ACC1 andlw 0xF0 xorwf ACC1, f iorwf ACC0, f ;add temporary to accumulator movf TEMP0, w addwf ACC0, f movf TEMP1, w skpnc incfsz TEMP1, w addwf ACC1, f ;shift accumulator right 4 times swapf ACC0, w andlw 0x0F movwf ACC0 swapf ACC1, w movwf ACC1 andlw 0xF0 xorwf ACC1, f iorwf ACC0, f skpnc bsf ACC1, 4 ; Generated by http://www.piclist.com/cgi-bin/constdivmul.exe (November 17, 2000 version) ; Thu Dec 21 19:06:26 2000 GMT {Original Message removed}

maybe I'm missing something (AND I don't have a solution to offer), but it looks to me like the rpm is inversely related to the timer value, which means simply dividing by 15 won't work. The basic equation looks to me like: 60 x 1,000,000 (conversions for minutes and us) rpm = ------------------ 16 bit timer value Also looks like the slowest speed that can be measured with 1us ticks and a 16 bit number is 915 rpm... (is this adequate?) Again, *I* don't know how to do this is 50 words! > I need to convert a 16-bit number (which holds number of cycles between > pulses on a port pin) to RPM. Operating a 16c71 at 4MHz. > > For example, Time:2 holds a value of 0x7510 meaning there are 117 counts of > 256 Tcy each at 1us, plus 16 extra Tcy, giving a speed of 2002 RPM. > Eh, doesn't sound TOO tough, you say? > >>How accurate does it need to be? Your scaling factor is about 1/15. >>1/15 = 1/ (16-1) ~= 1/16(1 + 1/16) -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email @spam@listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

www.piclist.com/techref/microchip/math/radix 16bit to BCD unpacked 5 digit 50 inst, ~200 executed 5 output registers from John Payson 16bit to ASCII Decimal 5 digits in 0 temp registers, 42 instructions, ~266 executed by Rich Leggit tweaked by Scott Dattalo.and bugfix by Dmitry Kiryashov and Nikolai Golovchenko --- James Newton (PICList Admin #3) KILLspamjamesnewtonKILLspampiclist.com 1-619-652-0593 PIC/PICList FAQ: http://www.piclist.com or .org {Original Message removed}

On Thu, 21 Dec 2000, Mike Mansheim wrote: > maybe I'm missing something (AND I don't have a solution to offer), > but it looks to me like the rpm is inversely related to the timer value, > which means simply dividing by 15 won't work. The basic equation looks > to me like: > > 60 x 1,000,000 (conversions for minutes and us) > rpm = ------------------ > 16 bit timer value > > Also looks like the slowest speed that can be measured with 1us ticks > and a 16 bit number is 915 rpm... (is this adequate?) > Again, *I* don't know how to do this is 50 words! > Of course you're right. I wasn't thinking. Hey, but if you need a fast 1/15 routine then what I posted will work! 60E6 = 0x3938700 this is ~ 0x7271 * 0x800 = 0x3938800 >> 11 Maybe someone (with more time than me) sees a trick to take advantage of this. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email RemoveMElistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

>maybe I'm missing something (AND I don't have a solution to offer), >but it looks to me like the rpm is inversely related to the timer value, >which means simply dividing by 15 won't work. The basic equation looks >to me like: > > 60 x 1,000,000 (conversions for minutes and us) >rpm = ------------------ > 16 bit timer value > >Also looks like the slowest speed that can be measured with 1us ticks >and a 16 bit number is 915 rpm... (is this adequate?) >Again, *I* don't know how to do this is 50 words! No, you're not missing anything. It is not a 'divide by 15' or anything that simple. You're right on with the 915 rpm max. Too bad you don't have a solution, you seem to understand the problem :) I suppose it's a 26-bit (32) divide by 16-bit, but that's probably some serious code. Too bad Nikolai doesn't have an "inverse of a multiply by a constant" code generator :) And yes, 915 rpm as the lowest limit is more than adequate. A max of about 20,000 rpm is the absolute ceiling, but that's not a problem as a count of 0x0001 is over 230,000 rpm. Using an actual time value rather than a "number of counts per XX time" gives a MUCH improved resolutionn and lower error. However, if anyone offers a method that makes use of the "number of counts per XX time" that is within 200 rpm, I'd probably take that. --Andrew _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email spamBeGonelistservspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

Drew, What are you measuring the RPM of? What I found for a tach functionality for an on-board data logger for my model boats is to use a fixed period of reporting, and have it just count pulses in that period. There was too much variation rotation-to-rotation for the other method to be as useful as I would have liked. My operating range was about 600-60000 RPM. Andy -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email TakeThisOuTlistservEraseMEspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

>What I found for a tach functionality for an on-board data logger for my >model >boats is to use a fixed period of reporting, and have it just count pulses >in >that period. There was too much variation rotation-to-rotation for the >other >method to be as useful as I would have liked. > >My operating range was about 600-60000 RPM. This sounds similar to my operating range. What did you use for your time period? And did you resolve it into RPM? If so, your multiplier is your error. i.e., if you had a time period of 16 bits at 4MHz, you'd have 6 pulses in 0.065535 seconds, resolved to RPM is 5493 RPM. However, if you were almost at 7 pulses, which would be 6408 RPM, you'd be off 14%. Plus, if you had this on a display, it would vary between these two values constantly. This is what I wanted to avoid. The trick is to get the time frame as high as possible to lower the multiplier. Your resolution at a 16-bit time counter is 60/.065535 RPM or 915. Not good enough at speeds of 2000 rpm, ~ 50% error and low resolution. Hmmm.. --Andrew _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email RemoveMElistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

>Using an actual time value rather than a "number of counts per XX time" >gives a MUCH improved resolutionn and lower error. However, if anyone >offers a method that makes use of the "number of counts per XX time" that is >within 200 rpm, I'd probably take that. > Here are two answers. 1. count pulses for 600 ms ( 1/100 th of a minute) and the answer is rpm/100. (ie a count of 1 == 100 rpm). 2. On the other hand if you are doing pulse by pulse control, for a speed control system, then maybe you could pre-calculate the setpoint in pulse period (us) rather than rpm. I have just completed a project that did just that. Ray Gardiner rayEraseME.....dsp.com.au mail from: dsp systems -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservmitvma.mit.edu with SET PICList DIGEST in the body

Drew Vassallo <RemoveMEPICLISTEraseMEEraseMEMITVMA.MIT.EDU> wrote: > if you had a time period of 16 bits at 4MHz, you'd have 6 pulses > in 0.065535 seconds, resolved to RPM is 5493 RPM. However, if you > were almost at 7 pulses, which would be 6408 RPM, you'd be off > 14%. Plus, if you had this on a display, it would vary between > these two values constantly. This is what I wanted to avoid. Drew: Two easy ways to avoid that quantization error are: 1. Implement a moving-window average over the last however-many samples. This will introduce a little lag between speed changes and display changes, but you may be able to live with that. 2. Only allow the display to change after you see the speed move in the same direction TWICE. In other words, if you're showing "6" and you get a "7" sample, don't change the display unless the very next sample is "7" or higher. Similarly, if you're displaying "6" and you see "5", leave the display at "6" unless the next sample is "5" or lower. -Andy === Andrew Warren --- RemoveMEaiwspam_OUTKILLspamcypress.com === Staff Systems Engineer, IPD === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

>> 60 x 1,000,000 (conversions for minutes and us) >> rpm= ------------------ >> 16 bit timer value > I suppose it's a 26-bit (32) divide by 16-bit, but that's probably some > serious code. Too bad Nikolai doesn't have an "inverse of a multiply by a > constant" code generator :) if you want to use this equation, break 60E6 into 15E6 * 4; 15E6 is a 24 bit number. Nikolai DOES have a 24 by 16 divide at: http://www.piclist.com/techref/microchip/math/div/24by16.htm which is 28 words (note that there are two routines on this page; he says the first is actually 24 by 15). Since the dividend is a constant, the math guys could probably make this routine even more efficient - not me. Add 6 words to multiply the result by 4: bcf 3,0 rlf AARGB2,f rlf AARGB1,f bcf 3,0 rlf AARGB2,f rlf AARGB1,f (you don't care about the top byte of the result) Extra rounding errors are introduced by breaking the dividend into 2 pieces. A quick spreadsheet check, for timer values from 3000 to 65535, shows that this calculation won't vary from a one step integer divide by more than 3 rpm (e.g. you'll get 912 rpm instead of 915 at timer = 65535). As far as the conversion to BCD, I believe Mr. Newton already referred to John Payson's routine, which takes a 16 bit number and converts it to a 5 digit BCD - should be exactly what you need. I've seen it on Mr. Dattalo's site: http://www.dattalo.com/technical/software/pic/bcd.txt Hopefully, you didn't mean 50 words to do the math AND the conversion to BCD, because this routine looks to be about 50 words itself. Perhaps you can find something shorter - I get the impression this was written to maximize speed - common knowledge that you can save space by giving up some speed (but I'm not pretending to have analyzed this routine). You did mention you already are including a 16 bit divide - perhaps you can save some space by using the 24 by 16 in place of it, if the ram is available. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

>I suppose it's a 26-bit (32) divide by 16-bit, but that's probably >some serious code. Yep! I don't have a divide 32 by 16 but 48 by 24 www.piclist.com/techref/microchip/math/div/48by24ng.htm is 108 instructions (about) If you can scale it down a bit to 25 by 16 www.piclist.com/techref/microchip/math/div/24by16.htm is only 28 instructions 608 cycles. Division into a constant ought to be possible and more efficient. How about a "Reciprocal" under a maximum value like an extension of www.piclist.com/techref/microchip/math/div/recip32k-ng.htm followed by a multiplication by constant www.piclist.com/techref/piclist/codegen/constdivmul.htm ? --- James Newton (PICList Admin #3) RemoveMEjamesnewtonKILLspampiclist.com 1-619-652-0593 PIC/PICList FAQ: http://www.piclist.com or .org {Original Message removed}

James Newton <jamesnewtonSTOPspamspam_OUTpiclist.com> wrote: > How about a "Reciprocal" under a maximum value like an extension of > www.piclist.com/techref/microchip/math/div/recip32k-ng.htm > followed by a multiplication by constant > http://www.piclist.com/techref/piclist/codegen/constdivmul.htm ? James: If the crystal were changed from 4 MHz to 64 * 1024 * 1024 4 MHz * ---------------- = 4.474 MHz, 60 * 1000 * 1000 then the second half of your solution (multiply by constant 60,000,000) could be replaced by a 26-bit left shift (which is really just a 2-bit left shift with a "virtual" 24-bit left shift). -Andy === Andrew Warren --- spamBeGoneaiwSTOPspamEraseMEcypress.com === Staff Systems Engineer, IPD === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email KILLspamlistservspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

Merry Christmas Scott and other guys. ;) Some magic is here. ;) ; high=a.b low=c.d movlw 0xF0 andwf low,F ;c.0 swapf low,F ;0.c swapf high,F ;b.a andwf high,W ;b.0 xorwf low,F ;b.c swapf high,W ;a.b addwf low,F ;a.b+b.c movlw 0x0F andwf high,F ;0.a skpnc incf high,F ;add carry ;12 clocks/words WBR Dmitry. {Quote hidden}> Division by 16 is trivial: > > swapf t2h,f > swapf t2l,f > movlw 0x0f > andwf t2l,f > andwf t2h,w > xorwf t2h,w > iorwf t2l,f > > ; xorwf t2h,f ; not needed because of trick below > > ; now add 1/16 of the above to itself > > swapf t2h,w > addwf t2l,f > movlw 0x0f > andwf t2h,f > skpnc > incf t2h,f > > One more instruction then the mystical 12 barrier - suggesting there's an > optimization lurking somewhere. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

Just another idea. The result of > 60 x 1,000,000 (conversions for minutes and us) >rpm = ------------------ > 16 bit timer value can be in range of 60000000 to 915.5 rpm. If the maximum rpm fits into 16 bits, you can use your 16 bit division routine to do that! Just initialize nominator (dividend) AND remainder with 60*1e6 (0x3938700), and branch to the division loop start: FindRPM clrf y0 movlw 0x87 movwf y1 movlw 0x93 movwf rem0 movlw 0x03 movwf rem1 jmp divide16by16_loopstart 8 instructions! Happy Holidays everyone!!! Nikolai ---- Original Message ---- From: Drew Vassallo <@spam@snurple@spam@spam_OUTHOTMAIL.COM> Sent: Thursday, December 21, 2000 22:06:19 To: spamBeGonePICLISTKILLspamMITVMA.MIT.EDU Subj: [PIC]: Challenge! (Everyone loves a...) {Quote hidden}>>maybe I'm missing something (AND I don't have a solution to offer), >>but it looks to me like the rpm is inversely related to the timer value, >>which means simply dividing by 15 won't work. The basic equation looks >>to me like: >> >> 60 x 1,000,000 (conversions for minutes and us) >>rpm = ------------------ >> 16 bit timer value >> >>Also looks like the slowest speed that can be measured with 1us ticks >>and a 16 bit number is 915 rpm... (is this adequate?) >>Again, *I* don't know how to do this is 50 words! > No, you're not missing anything. It is not a 'divide by 15' or anything > that simple. You're right on with the 915 rpm max. Too bad you don't have > a solution, you seem to understand the problem :) > I suppose it's a 26-bit (32) divide by 16-bit, but that's probably some > serious code. Too bad Nikolai doesn't have an "inverse of a multiply by a > constant" code generator :) > And yes, 915 rpm as the lowest limit is more than adequate. A max of about > 20,000 rpm is the absolute ceiling, but that's not a problem as a count of > 0x0001 is over 230,000 rpm. > Using an actual time value rather than a "number of counts per XX time" > gives a MUCH improved resolutionn and lower error. However, if anyone > offers a method that makes use of the "number of counts per XX time" that is > within 200 rpm, I'd probably take that. > --Andrew -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestspam_OUTmitvma.mit.edu

Sorry, no answer to the question, but 50 words is enough if you have access to an external divide routine. The question is, what do people do about the duty cycle variation with RPM induced by sensor amplifier non-linearity. In other words: when measuring period to get RPM the sensor amplifies the 'edge' of the transition in the input and causes amplitude distortion depending on RPM. This causes speed-dependent modulation of the edge in time. Sometimes both edges move away (widen the pulse) and sometimes they move together, and sometimes only one moves. Unless a very good symmetrical sensor and amplifier are used. This can be up to 10% with some sensors and speeds. So what do you do ? Measure a ON and a OFF period and average ? Don't care ? Peter -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-request.....TakeThisOuTmitvma.mit.edu

>The question is, what do people do about the duty cycle variation with RPM >induced by sensor amplifier non-linearity. In other words: when measuring >period to get RPM the sensor amplifies the 'edge' of the transition in the >input and causes amplitude distortion depending on RPM. This causes >speed-dependent modulation of the edge in time. Sometimes both edges move >away (widen the pulse) and sometimes they move together, and sometimes >only one moves. Unless a very good symmetrical sensor and amplifier are >used. This can be up to 10% with some sensors and speeds. So what do you >do ? Measure a ON and a OFF period and average ? Don't care ? Surely this only becomes a problem while the speed is changing, in which case it will not matter because by the time the display is updated the speed is different anyway. If being used in a closed loop system there may be other problems, but I would not have thought they would be worse than from a sensor where the waveform did not vary in shape or duty cycle with speed. Once the speed is constant, provided there is a stable trigger on the edge, then measure from (say) positive edge to positive edge. At any given speed this must be correct for that speed unless the shift in the transducer is such that other dynamics come into play which cause pulse dropout, or is there some fundamental thing I have missed here. -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-requestKILLspamspammitvma.mit.edu

>>My operating range was about 600-60000 RPM. > >This sounds similar to my operating range. What did you use for your time >period? And did you resolve it into RPM? If so, your multiplier is your Snapshots of system variables (uptime, voltages, RPM, current) are taken every 100mS and stored to a Flash chip. The data is post-processed by a PC. >error. i.e., if you had a time period of 16 bits at 4MHz, you'd have 6 Uptime is kept in a 32-bit variable which is bumped about every 750uS (I forget the numbers, but it works off TMR0 rollover with an 11 MHz osc). RPM is not calculated in the PC, which has control over all the configuration of the chip (ie, all the registers are stored in internal EE). This allows me to tune performance to see something special. >constantly. This is what I wanted to avoid. The trick is to get the time >frame as high as possible to lower the multiplier. >Your resolution at a 16-bit time counter is 60/.065535 RPM or 915. Not good >enough at speeds of 2000 rpm, ~ 50% error and low resolution. Try this instead: RB0 is the interrupt for the tach. The time frame for updates being sent (snapshots) is about 100mS. The total number of counts is handed off about every 100mS. I say about because it varies a little. This is why uptime is sent - it's dead-nuts accurate. Back on shore, the data (512K-2M) is offloaded to a PC. Then the PC calculates the deltas, averages the RPM over the last N samples, and dislays that. Andy -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestRemoveMEmitvma.mit.edu

Peter, I use a modulated IR optical proximity sensor on mine. It is watching a reflective/non-reflective wheel with 50% duty cycle. Output goes through an AGC circuit, then into a comparator with one side being the data, the other side an integrator out of the AGC. The output goes to RB0, which only ever triggers on the falling edge. Yes, the phase DOES shift a little, but at high speed it's rock steady. At low speed, the motor doesn't run as smoothly (makes sense when you think about mass and application of power) so there is some wiggle between readings. This is why I went to 100mS snapshots - at 600 RPM (a goal for the original design) that means 10 rotations/snapshot - and then sliding window the results. Andy "Peter L. Peres" <RemoveMEplpspamBeGoneACTCOM.CO.IL> on 12/22/2000 04:30:28 AM Please respond to pic microcontroller discussion list <spamBeGonePICLIST@spam@spam_OUTMITVMA.MIT.EDU> To: TakeThisOuTPICLISTspamMITVMA.MIT.EDU cc: (bcc: Andrew Kunz/TDI_NOTES) Subject: [PIC]: Challenge! (Everyone loves a...) Sorry, no answer to the question, but 50 words is enough if you have access to an external divide routine. The question is, what do people do about the duty cycle variation with RPM induced by sensor amplifier non-linearity. In other words: when measuring period to get RPM the sensor amplifies the 'edge' of the transition in the input and causes amplitude distortion depending on RPM. This causes speed-dependent modulation of the edge in time. Sometimes both edges move away (widen the pulse) and sometimes they move together, and sometimes only one moves. Unless a very good symmetrical sensor and amplifier are used. This can be up to 10% with some sensors and speeds. So what do you do ? Measure a ON and a OFF period and average ? Don't care ? Peter -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestEraseMEmitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestEraseMEspam_OUTmitvma.mit.edu

> The question is, what do people do about the duty cycle variation with RPM > induced by sensor amplifier non-linearity. In other words: when measuring > period to get RPM the sensor amplifies the 'edge' of the transition in the > input and causes amplitude distortion depending on RPM. This causes > speed-dependent modulation of the edge in time. Sometimes both edges move > away (widen the pulse) and sometimes they move together, and sometimes > only one moves. Unless a very good symmetrical sensor and amplifier are > used. This can be up to 10% with some sensors and speeds. So what do you > do ? Measure a ON and a OFF period and average ? Don't care ? What you describe only results in a small phase shift, and only the derivative of the phase shift shows up as a frequency error. Unless you have a very unusual application, this tiny error is insignificant and evens out in the long run anyway. It is best to measure entire cycles. In other words, use either the rising edge of the falling edge, but ignore the other. In most frequency measurement applications I've done with PICs, I've used the CCP module to measure the period and inverted it to get instantaneous frequency. Then I usually apply some low pass filtering to the extent the rest of the application can tolerate it. This is an easy way to "average" out several recent readings. In fact, I apply low pass filtering whenever possible when measuring real world inputs. Often when using A/Ds I read them more often than needed in the foreground loop and low pass filter the result. The rest of the system just grabs the latest filtered value instead of kicking off a deliberate A/D reading. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, EraseMEolin@spam@embedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList @spam@piclist-unsubscribe-requestspam_OUT.....mitvma.mit.edu

Hi Scott. Cap of morning coffee brought another idea. ;high=a.b , low=c.d movlw 0xF0 andwf low,F ;c.0 andwf high,W ;a.0 xorwf high,W ;a.0^a.b xorwf high,F ;a.0 xorwf high,W ;a.b swapf low,F ;0.c swapf high,F ;0.a addwf low,F ;0.c + a.b skpnc incf high,F ;0.a + carry ;11 clocks/words Nice puzzle to train visual imagination ;) WBR Dmitry. -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestEraseMEmitvma.mit.edu

Hi everyone. I'm quite new to this PIC thing so I apologize for bursting into your conversation. It seems that this problem needs to be addressed in the same way that professional tape recorders control capstan speed. The shaft being measured needs a marked disk or band around it marked off in say, 1 degree segments of reflective or translucent and non reflective or opaque bands. A sensor then uses these to obtain a frequency that is proportional to the RPM. Rough calculation gives 100 Hz equal to approx 16 rpm and 1MHz giving 166000 rpm. I think the nominal speed is about 2000 rpm? Then this gives a periodic time of about 80 uS. Well inside your 16 bit no. I hope I haven't missed some blaring point, as I said I'm new to this field. Regards Brandon -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestspamBeGonemitvma.mit.edu

Ok, Dmitry... I've been staring at it for an hour now.... I have to get back to work. Just to make sure, this code divides by 15 right? Do you feel like helping a poor student of your ways to understand the "magic + morning coffee" ? This part just completely fry's my brain. xorwf high,W ;a.0^a.b xorwf high,F ;a.0 xorwf high,W ;a.b --- James Newton (PICList Admin #3) RemoveMEjamesnewton@spam@spamBeGonepiclist.com 1-619-652-0593 PIC/PICList FAQ: http://www.piclist.com or .org {Original Message removed}

From: Peter L. Peres <plpEraseME@spam@ACTCOM.CO.IL> >The question is, what do people do about the duty cycle variation with RPM >induced by sensor amplifier non-linearity. In other words: when measuring >period to get RPM the sensor amplifies the 'edge' of the transition in the >input and causes amplitude distortion depending on RPM. This causes >speed-dependent modulation of the edge in time. Sometimes both edges move >away (widen the pulse) and sometimes they move together, and sometimes >only one moves. Unless a very good symmetrical sensor and amplifier are >used. This can be up to 10% with some sensors and speeds. So what do you >do ? Measure a ON and a OFF period and average ? Don't care ? > >Peter I'm dealing with this right now. I assume you are trying to measure RPM. Measuring leading edge to leading edge rather than a half cycle (leading to trailing) is a start and after that averaging helps. The REALLY keen may note the maximum rate at which the system is capable of changing speed and deduce something about the distortion from this. Russell -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestspamBeGonemitvma.mit.edu

Alan, you got the point right, but the idea is, you use period measurement when the spindle is too slow to wait for a full rotation. Now, taking the time between two identical edges will fix the problem, but for that you need at least two marks on it (paint marks, mirrors, holes, whatever). With two marks an auto-calibration becomes difficult... Maybe someone on this list has done it by changing between period and frequency measurement at a certain rpm ? This is very hard to do. Peter -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

>Hall effect The integrated Hall sensor will not have the slope problem since it has built-in hysterezis. However, you need to check the specs. It is possible that it was meant for slow keying and that it has some sort of delay built in (as in, key debounce delay). The Hall sensor proper does not have a problem with the slopes, the amplifier that follows it may have if the frequency of the pulses is high enough wrt. its bandwidth. F.ex. a 30 rpm spindle read out with a 3 degree wide dot will require an amplifier capable to pass about 500Hz at least for 10% error, 5000Hz for 1% (I assume that the error is due to the slopes alone). At 50% duty cycle the problem does not occur directly, only as phase modulation when rpm changes. This can cause some spectacular backfires in a poorly designed ignition system <g>. Peter -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

>Interesting. I hadn't heard of that. I'm just using a hall effect >(transistor output) sensor. I didn't know that the trigger would vary >enough to cause any significant errors in period. I mean, I realize >there'll be some error, but not 10%. Is there any information on this >anywhere? I haven't seen information on this, so I was asking. Cheap sensor types are notorious for this. For example the reflective IR couplers people like to call 'pigsnouts'. In general, if you connect a phototransistor + LED + pullup to a digital input instead of a comparator then it will happen to you. The highly assymmetrical impedances in the phototransistor + pullup arrangement include a parasitic capacitance and as the frequency increases the output will likely raise less. Its slopes will be inclined at a certain angle. If you measure period (using a hole or strip of dot of paint) then the slope widths can reach 10% of the dot width very fast. If you happen to be using something like this to adjust engine firing points etc then you want to bother about this probably. Andy did the right thing and pre-processed the opto signal as he should have, but this is not always an option in low cost devices. However, there are software ways to do this. Some of them are quite intricate. Peter -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

At 12:00 23/12/00 +0200, you wrote: >Alan, you got the point right, but the idea is, you use period measurement >when the spindle is too slow to wait for a full rotation. Now, taking the >time between two identical edges will fix the problem, but for that you >need at least two marks on it (paint marks, mirrors, holes, whatever). >With two marks an auto-calibration becomes difficult... > >Maybe someone on this list has done it by changing between period and >frequency measurement at a certain rpm ? This is very hard to do. > Actually it's not that hard, you do *both* calculations and choose which one to return. If the period timer overflows, then you set the frequency to zero. This imposes a lower bound on the range of frequencies that can be measured, if you want good resolution at low rpm then you generally need multiple pulses per rev to get good resolution. If using proximity switches, or similar then you must take care to make sure the targets are mounted accurately to avoid jitter. When you change to count mode, then it is advantageous to smooth the results before display. I use the following algorithm, which is a bit like an RC style low pass filter. each time through the loop do the following. total = total - average total = total + new_value average = total / n is you choose n to be some power of 2, then this can be fairly efficient. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

> If you measure period (using a hole or strip of dot of > paint) then the slope widths can reach 10% of the dot width very fast. Which doesn't matter if you just want frequency. You merely end up with a phase shift in the frequency, but it's still the same frequency. > If you happen to be using something like this to adjust engine firing > points etc then you want to bother about this probably. OK, I agree it matters in this application since you are trying to measure phase. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, spamBeGoneolinKILLspam@spam@embedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

>> If you measure period (using a hole or strip of dot of >> paint) then the slope widths can reach 10% of the dot width very fast. > >Which doesn't matter if you just want frequency. You merely end up with a >phase shift in the frequency, but it's still the same frequency. Olin, I said period. For slow spin you need to measure period to get a usable realtime rpm readout (rpm is obtained by F=K*1/T where K is related to t/T of the dot or stripe you use - and to the slope fudge factor I was talking about). Under about 300 rpm there is no other way (because of averaging etc). >> If you happen to be using something like this to adjust engine firing >> points etc then you want to bother about this probably. > >OK, I agree it matters in this application since you are trying to >measure phase. Worse, you usually want instanetaneous rpm (with any phase cancelled) if this is used in a control loop. I leave it to your imagination as to what happens if the I constant in PID needs to be tuned with frequency because of the slopes. When frequency-or-period measurement is used, it is necessary to make sure that the transition if monotonous in both directions (if not smooth). Otherwise again control systems based on this may go 'crazy' in the transition area. Peter -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

I don't know, Peter. An LM339, a cap and a resistor are pretty cheap! Andy "Peter L. Peres" <plpspam_OUT@spam@ACTCOM.CO.IL> on 12/23/2000 05:16:10 AM Please respond to pic microcontroller discussion list <spamBeGonePICLIST@spam@MITVMA.MIT.EDU> To: RemoveMEPICLISTEraseMEKILLspamMITVMA.MIT.EDU cc: (bcc: Andrew Kunz/TDI_NOTES) Subject: Re: [PIC]: Challenge! (Everyone loves a...) >Interesting. I hadn't heard of that. I'm just using a hall effect >(transistor output) sensor. I didn't know that the trigger would vary >enough to cause any significant errors in period. I mean, I realize >there'll be some error, but not 10%. Is there any information on this >anywhere? I haven't seen information on this, so I was asking. Cheap sensor types are notorious for this. For example the reflective IR couplers people like to call 'pigsnouts'. In general, if you connect a phototransistor + LED + pullup to a digital input instead of a comparator then it will happen to you. The highly assymmetrical impedances in the phototransistor + pullup arrangement include a parasitic capacitance and as the frequency increases the output will likely raise less. Its slopes will be inclined at a certain angle. If you measure period (using a hole or strip of dot of paint) then the slope widths can reach 10% of the dot width very fast. If you happen to be using something like this to adjust engine firing points etc then you want to bother about this probably. Andy did the right thing and pre-processed the opto signal as he should have, but this is not always an option in low cost devices. However, there are software ways to do this. Some of them are quite intricate. Peter -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email spamBeGonelistservspam_OUTRemoveMEmitvma.mit.edu with SET PICList DIGEST in the body

I had a 1V 1% reference available from other portions of the circuit, used that at the input to the 339. Andy "Peter L. Peres" <.....plpRemoveMEACTCOM.CO.IL> on 12/28/2000 04:01:59 PM Please respond to pic microcontroller discussion list <PICLIST@spam@MITVMA.MIT.EDU> To: EraseMEPICLISTRemoveMESTOPspamMITVMA.MIT.EDU cc: (bcc: Andrew Kunz/TDI_NOTES) Subject: Re: [PIC]: Challenge! (Everyone loves a...) >I don't know, Peter. An LM339, a cap and a resistor are pretty cheap! > >Andy And a pullup at the output of the 339 and a 1/2Vcc divider (or did you use the IC as current sensor). == 4 parts minimum. Sometimes there is not enough room for 2 parts (including the PIC). Where do I put 4+ ? ;-) Peter -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics