Measuring a Pulse Width

I’m trying to measure the length of a pulse from a waveform generator to the mini-rc. The signal is a simple square wave; 5 Vp-p, 25 Hz. Unfortunately, I can’t seem to get interrupts on the mini-rc to detect any of the edges.
I have the function generator directly connected to the mini-RC. I am verifying the signal on an oscilloscope. Unfortunately, I just can’t seem to generate interrupts unless I am removing the PWM cable from the RC. Which makes me believe the software is working at least half correctly. I think it has something to do with the internal pull-up resistor inside the RC. Can anyone shed some light on this? Thanks.

5 Vp-p with a 2.5 V DC offset, right? That would be a train of pulses…
I’m tired and should be studying analog filters for my exam tomorrow, so the only help I can offer now is the digital input schematic from Innovation First:
It doesn’t look like the pull up resistor is messing your readings, unless you’re actually using a square wave that swings 2.5 V up and below ground.
Hope that didn’t sound too confuse.

OK, I’m going to make a SWAG at this. After re-reading your description, this is what I think my be happening. When a system, the mini-rc in this case, has a pull up resistor on it, it’s signal will always be high. ( I can hear you saying “duhhh, I know that”) To pull that input low, you need to ground the input, or at least pull it down low enough for the circuit to detect it as low. But, her comes the SWAG, the ground level needs to be referenced to the same ground used on the system with the pull up, got it? My guess is that the signal generator is not tied to the ground of the mini-rc, and therefore, the mini-rc if floating and not able to see the 0vdc portion of the square wave. I hope you are running the mini-rc from a battery, if so, just connect a wire from the ground of the signal generator to the negative input of the battery driving the mini-rc. The signal generator might/should have a ground connector on the front of it for situations just like this, or at least in easy access to the front. But, if you are running the mini-rc from a power supply, be careful connecting the two together, if the ground of the signal generator is slightly different from the ground of the power supply you could fry stuff quick. Once you like the magic smoke out, the mirrors don’t work :ahh: … just kidding. Measure the potential between the two grounds. If you see just a couple millivolts, you should be cool.

5 Vp-p with a 2.5 V DC offset, right?


The waveform generator I am using is an HP model. I have connected a BNC cable to the generator and that cable breaks out into two alligator clips, one positive and one ground. I connected the positive clip to the mini-RC’s signal wire and connected the ground clip from the generator to the ground on the mini-RC. The mini-RC is being run off a battery. So I think they are both using a common ground.

Sounds like your hook up is correct.

If I am reading the comment by Manoel and your response correctly, I have to assume you are injecting a 5vp-p signal running from +2.5 to - 2.5 vdc. If so, I would say you have a -2.5vdc off set. This could work if the electronics in the mini-rc consider anything above 2.4 vdc a high. But my guess is it won’t. It probably needs something closer to 4.5vdc to be considered a high.

Is there a way to adjust the offset to 0vdc? That way your signal will be running from 5vdc to 0vdc. Therefore, the mini-rc will see a high of greater than 4.5 vdc and a low of less than .5 vdc. Both should be good values for high and low.

The signal does start at 0Vdc and runs up to 5Vdc. I verified that using the scope.

OK, I’m not following. What is the 2.5vdc offset you are speaking of?

The square wave you referred to

does not have a DC offset. You can get technical and define the DC offset as the constant term in the Fourier series below or just look at the waveform generator and check how far you got the “DC Offset” dial from zero :stuck_out_tongue:

Anyway, you are really using a 5V pulse train and my initial concerns were pointless. Which leaves me without ideas of what is going on. :slight_smile:
Could you possibly hook the waveform generator to an optoisolator just to make sure there’s nothing else interfering?

A couple of points here. 24 years ago, when I got my EE, a DC offset was defined as you stated. It still is today. In real world applications, a DC offset can be determined a couple different was, running it through the Fourier Series is one of the most time consuming and accurate ways. Looking at the dial on the signal generator is the quickest, but least accurate. Measuring with a scope or DVM is the most accurate and fairly quick.
When I asked about th offset, the reason was that an offset of 2.5vdc can prevent a circuit from ever seeing a transition from high to low or low to high.

Here’s why. Lets assume that the interrupt, or digital, input on the mini-rc identifies a signal as a high when it is above 4.25vdc and a low as below .5vdc. Now a 5v p-p signal with a 2.5vdc offset is running from 2.5 to 7.5 vdc. So, it never sees a level below .5vdc and therefore never sees a low. On the other hand, if the offset is -2.5vdc, the signal runs from -2.5vdc to +2.5vdc, so the input never sees a high. In either case, the pulse train never cycles the input high and low so that neither the rising nor falling edge can be detected.

If, in fact, the signal at the input is connected as Mike indicates and the signal is running from 0 vdc to 5vdc, then I too am at a loss as to what is the problem.

BTW, I am not building this, Mike D. is.
I was also wondering if you could just run the signal to a small transistor circuit that just short the signal input to gnd, and released it back to 5vdc instead of running the signal generator directly to the input. This would eliminate any problem with the signal generator being able to sink the needed current to pull it low. (This shouldn’t be an issue, but I have seen stranger things) It will also isolate it like the opto that Manoel suggested. In fact, the opto isolator would be easier to implement.

I’m almost 99% sure that the signal runs from 0Vdc to 5Vdc. Tomorrow morning, when I am back in my school’s lab, I will verify that this is completely true.

For some background, I am attempting to write software for the Parallax Inc. PING))) sonar sensor. The pulse width of it’s response corresponds to the distance between itself and an object.

Currently, I am using bench top equipment to operate the PING))). A function generator triggers the PING))) to measure and an oscilliscope measures the returning pulse width. The sensor is accurate wthin an inch. At only $25, this sensor looks very exciting for FIRST applications.

The difficulty in this project is the mini-RC signal pin will be both an output and input. I have been able to trigger the sensor from the RC. Unfortunately, the mini-rc hasn’t been capable of reading the response.

By simulating a response from the sonar sensor using the function generator I am hoping to isolate the problem in my code.

Mike is right and needs a +2.5vdc offset. A waveform generator will output a waveform 1/2 Vp-p (2.5v) above ground and 1/2 Vp-p below ground. The offset moves the entire waveform above ground.


Wow, that is a cool little sensor, and low cost as well. I like the simplicity of it’s design and operation. I can see your difficulty with using the mini-rc I/O as both an I and an O. This is what I might try: Use a second I/O as and output to trigger the PING))). Tie it to the same input pin as the input you are using, then write your code to ignore the triggering 2 to 5 micro second pulse. Only allow it to sample a pulse longer than 100 micro seconds. (It looks as though the minimum pulse width from the PING))) is 115 micro seconds.) Now, if you can figure out how to switch the I/O from out to in and back, then your job gets easier. Let us know how your testing goes and how the project as a whole turns out.

You should be able to do this with the EDU-RC by using a timer and interrupt one or two to determine the delay. These signals can also be configured to be a digital output, which will come in handy when you need to strobe the SIG pin. A more elegant solution would employ the built-in CCP hardware to calculate the time delta automatically. You might consider looking at the IR receiver code from 2004, which uses the aforementioned interrupt method to bin the incoming IR sensor pulses. For an (unpublished) example of how to use the CCP hardware, have a look at accel.c in this zip file:


Knowing the specifics of the signal generator makes a huge difference. I have used several different generators and they are not all created equal. I did make an assumption :eek: . Some generators have a selection for coupling, AC/DC, much as a scope has. In AC, there is no offset and the signal is averaged around 0 vdc. In DC, you set the amount of offset, + or - relative to 0 vdc. Your correct, when DC coupled, a +2.5vdc offset would be needed to shift a 5vp-p signal to run from 0vdc to 5vdc.

Thanks for the link to the IR receiver code. I have been wanting to learn more about CCP functionality and usage. This should go a long way in building my understanding. Now that I’ve learned a wee little bit about C, I can at least follow most of what is happening.

Function generators? Scopes? All that to try and get a FRC to use a sonar range sensor? Most pic basic interpreters and compilers have a pulse in and pulse out function in the language. The stamp sample code is very easy but, with the FRC and C this common simple device is giving people fits. I have a Daventech SRF04 which is very similar to the stamp device except it has a separate trigger and pulse pin. I soldered 4 wires to it. Plugged it into a bread board with a Pic 18F452 basic interpreter chip and wrote the following code.
func main()
dim range
sonar 0,1,range
print “Distance=”,range/64,“inches”
pause 20
goto loop

In about 1 hour I was testing it out. This post points out a major problem with the FRC as it is now. EE’s love it, non professionals fight it. I don’t have any answers but, to take First further with sensors and autonomous mode, something needs to change. The challenge to sensors should not be the hardware-software implementation but, the application of the info they give us to come up with strategies for the game. Too many teams this year chose an autonomous mode strategy of doing nothing.

The 2004 IR receiver code can be found in receiver.c, which can be found in this file: Also keep in mind that the CCP-based code I mentioned earlier won’t work on the FRC-RC because IFI put output buffers on the CCP pins.


Well, for those that guessed I was using a -2.5V to +2.5V pulse you were right. After adjusting the offset I was able to get the mini-RC to trigger. (See attached) Thanks for the heads up.

I wrote a quick program to test how many edges per second (interrupts/s) the mini-RC was receiving. I was getting very odd results. At about 1Hz there was 2 interrupts/s, which was good; however, at 1kHz there was 2,200 interrupts/s. After awhile I realized it was the printf statement that was introducing the error. Does anyone know just how much of an impact making a printf causes?



When ever we get strange results, I always suspect the printf statements, problem is we never seem to be able to determine how much of an impact the printf statement has on the performance. It seems like you have a perfect setup to experiment with and find out how much an impact printf makes. Perhaps you could use the Dashboard program to help compare the results of using printf statements versus not.

I’m no expert but, could your Interrupt handler be counting all interrupts and not just the portb pin transitions. The printf statement will generate interrupts.

Hmm…when you say it was “about 2 interrupts/s”, are you sure you weren’t getting about 2.2 and not noticing the excess? And are you sure it was right on 1kHz? That 10% looks like it could maybe be adjustment error on the signal generator.

I would expect printf to eat time and push the number of interrupts/sec down, not up.

Oh, wait…printf/the serial drivers use interrupts, don’t they? If I remember correctly (haven’t tested it), interruptible pins can set their interrupt flags without their particular interrupts enabled (so the flag is set but we don’t jump out to an interrupt), so when another interrupt comes along the ISR might take action on a disabled pin. Is this right or am I confused? At any rate, perhaps something similar is happening in your case; you could be checking the state of your inputs in the ISR without determining whether an interrupt actually originated from them, and so if printf throws an interrupt, it might conceivably cause overcounting. Of course, aren’t printf’s interrupts high-level ones handled by the Master processor? Hmm…I’m confusing myself now. Comment?

Allow me to state that I generally have no idea what I’m talking about, so please don’t laugh too hard.