 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Micromite: Measuring the Width of a Pulse
  Page 2 of 2 |
|||||
| Author | Message | ||||
| dmasz Newbie  Joined: 12/09/2013 Location: PolandPosts: 21 |
Gents, is it doable to extend PULSIN function to measure period of N pulses? as total length or mean value of pulse period over N pulses it could give in some conditions more constant results. br Dan |
||||
| Goeytex Regular Member  Joined: 12/05/2014 Location: United StatesPosts: 74 |
I am not exactly sure what you mean, but it seems to me that you could write a function with the existing pulsin that increments a counter variable for N number of consecutive pulsins and then take the sum of the measurements. But a limitation of Pulsin ( any platform or language) is the command processing overhead. With the Micromite this is ~60 - 70us. In other words consider a 2 pulse burst where the first pulse is 10us, and the second is 20us and there is a space of 30us between each pulse. With 2 consecutive Pulsin commands the second pulse will be missed because it take the program > 30us to jump to the 2nd pulsin command, process it,( interpreter) and then execute. For pulse trains with a space time of <70us, what you are wanting to do would likely require a different function/command and would over complicate the function of pulsin, which is to measure the width of a single incomming pulse. |
||||
| dmasz Newbie Joined: 12/09/2013 Location: PolandPosts: 21 |
Goeytex as you mentioned. If you will try to count pulses in interpretative Basic then you will bang you head on the wall of basic performance.(overhead as you desribed) that is why if pulsin will have another parameter to give you as output total length of N pulses it will be easy to take mean period and it will be very useful for measurements when you are trying to avoid error caused by noise, vibration or nature of physical machine. if you will try to measure measure speed of engine then you will notice that speed is not dead constant it varies and it is better to do couple of measurements and then average result than to relay on measurement of just one pulse. pulsin can be used not only to measure electronically generated pulses some time you are trying to measure physical generated pulses. N pulse option would be useful for sensors with equally spaced pulses like rotational encoders to measure period of N pulses to get good average. D. |
||||
| Goeytex Regular Member Joined: 12/05/2014 Location: United StatesPosts: 74 |
Something like this? a = PULSIN( pin, polarity,N,[, t1 [, t2]] ) Where a = total time of N pulses... Interesting... |
||||
| dmasz Newbie Joined: 12/09/2013 Location: PolandPosts: 21 |
yes this would be prefect 
D. |
||||
MicroBlocks Guru  Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Would a pin configured as a counting input not work for that? Microblocks. Build with logic. |
||||
| Goeytex Regular Member Joined: 12/05/2014 Location: United StatesPosts: 74 |
Being new to MMBAsic, I am not sure. I have not yet tested the counting or period functions, but I think one of these may work. Bill |
||||
atmega8 Guru Joined: 19/11/2013 Location: GermanyPosts: 722 |
Geoff, Thank you for this fast Response and new Function. But i think, that every Function that completely blocks Interrupts, like Pulseins could cause many Problems. Every Atmega Controller can do this in the Background in Hardware, without blocking any Interrupts. I think a PIC can also do this. But i don't know this in Detail and even i will never in my live be able to build a Interpreter, as you did;-).. Wouldn''t it be possible to have Functions that do not Block Interrupts? With the DS1820 onewire you also implemented it non blocking..... And there are other Functions that will block in the micromite.... Just an idea... THX Dietmar |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3196 |
Yes, that is definitely on my todo list. It will be a while though, in 10 days I head off to California and Ireland for two and a half months. During that time I will have internet access to this forum but further development will have to wait until late August. I should be spending my time getting ready for the trip but PULSIN seemed so easy that I gave it a go. Interrupts in MMBasic work differently compared to hardware interrupts as in a PIC. A hardware interrupt can break into running code but they are not flexible enough to be used as MMBasic interrupts. So MMBasic uses software interrupts where the interpreter checks at the end of each command for an interrupt and if one has occurred, it then runs the appropriate interrupt code. Normally this is OK because most commands execute in less than 50uS and therefore any interrupt source would be checked every 50uS. But it does mean that commands that take a long time (such as IR SEND) will delay the interrupt check. There is no easy solution to this. It is very hard to break into a BASIC command and run some other code because the interpreter needs to keep track of many items of information while a command or function is being executed and that would be lost by executing some other code. In MMBasic the only command that can be interrupted in the middle is the PAUSE command and that was not easy to implement. This is doable but it would extend the running time of the command and block interrupts for longer. Geoff Geoff Graham - http://geoffg.net |
||||
| atmega8 Guru Joined: 19/11/2013 Location: GermanyPosts: 722 |
Geoff, thank you for the explanation. Now i can better understand why things are like they are. |
||||
| dmasz Newbie Joined: 12/09/2013 Location: PolandPosts: 21 |
it could extend waiting time but t1 and t2 will take care, not to stuck forever. 
Dan |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
i take it you have in mind a specific application, where pulses arrive fairly frequently, but have some small jitter in their length? an approach that would be 'almost as good' as what you are asking for would be to use a running total weighted to slowly replace older results with newer: T(n+1) = q.T(n) + (1-q).PULSEIN(pin, pol) where q is a fraction just less than 1, representing the weighting. for example, the following code should be placed in the main loop of your program, with the main loop executed perhaps 50 times a second, and your pulses arriving at pin 2 at the rate of several hundred per second: temp = PULSEIN (2, 1) IF temp<>-1 THEN pw = (0.96 * pw) + (0.04 * temp) after running for a second or so, pw will contain a weighted average of the pulse width - weighted towards newer values. as the pulse width increases or decreases, pw will track it. slow changes will track very closely, rapid changes might take a second or so to 'catch up'. to make the tracking quicker, try using 0.90 and 0.10 as the multipliers, but in most cases a slow tracking is more useful. you may end up using values of 0.99 and 0.01 to achieve good smoothness. or, if you see a sudden change in pulse width, you might want to create a 'jump' by assigning temp directly to pw: temp = PULSEIN (2, 1) IF temp<>-1 THEN IF (temp=0) OR (pw=0) THEN jump = 0 ELSEIF ((pw/temp) >1.5) OR ((temp/pw)> 1.5) THEN jump = 1 ELSE jump = 0 ENDIF IF jump then pw = temp ELSE pw = (0.96 * pw) + (0.04 * temp) ENDIF the above will reset the value of pw to the currently read pulse width if the difference between the two is more than 50%. the logic is a bit convoluted due to the need to make sure neither pw nor temp is zero before checking the ratio. i assume that MMbasic does not do 'incomplete evaluation' of logic expressions! rob :-) |
||||
| Page 2 of 2 |
|||||
 Print this page |
