Measuring PWM input signals

[virtuald]

Is there a way to read PWM input signals? We never got our FIRST provided accelerometer, and the one from last year works rather crappily... so we're experimenting with other ones. One I found has a PWM output signal, but I can't figure out what I should use to measure the signal appropriately. I have a feeling its in the counter object, but I'm not quite sure..

Thanks!

[jross]

I would use a counter.

[virtuald]

Can the counters measure the duty cycle of the input?

[jross]

If the signal has a defined period, it would be the pulse duration (from the counter) divided by the pulse period.

If the period also varies, you could use 2 counters, one to measure rising to falling and one to measure falling to rising.

[Joe Hershberger]

The only downside of measuring duty cycle when the period is changing (even using 2 counters) is that you may not get consistent samples (a high and low time that belong together). When possible, I recommend putting a low-pass filter on the PWM output and use the analog input to read the value.

Another option that is a bit heavy-weight is you can use DMA to ensure you get consistent samples.

[Mike Betts]

Joe,

I'm a dinosaur more used to interrupt handlers and such and not sure how LV works at it's internals...

Couldn't you do a data dependency to force a rising edge capture then a falling edge? Alternatively, could you clear the falling edge on receipt of a rising edge?

Switching from digital to analog domains seem to defeat the whole reason of being digital in the first place...

Regards,

Mike

[virtuald]

The accelerometer I have is a constant period with varying duty cycle. I didn't realize one could put two counters on the same channel though.

I was going to test this out today, but we didn't have time. Will have to wait until Monday.

[Joe Hershberger]

I'm a dinosaur more used to interrupt handlers and such and not sure how LV works at it's internals...

LabVIEW is just a programming language. I'm guessing you are referring to the FPGA and the robotics library.

The FPGA does have interrupt support. It will even timestamp the interrupt events in hardware so you can know exactly when the event occurred.

Couldn't you do a data dependency to force a rising edge capture then a falling edge? Alternatively, could you clear the falling edge on receipt of a rising edge?

You certainly could, but the whole point of the hardware acceleration is that the robot code does not have to keep up with every event that happens. If you did decide to go that way, the interrupts that this system provides will give much more accurate results with the same scheme because of the hardware timestamps.

Switching from digital to analog domains seem to defeat the whole reason of being digital in the first place...

It only defeats the "reason" if your reason was to be highly noise immune and if you filter in such a way that noise is easily introduced. If you buffer the signal after filtering, use a clean supply, and don't wrap the signal wire around a CIM, you should be fine.

There are many ways to solve this problem with the current system, and like all engineering, there are trade-offs you have to make.

Cheers!
-Joe

[virtuald]

It will even timestamp the interrupt events in hardware so you can know exactly when the event occurred.

Do tell about these timestamps. And does the counter have such a mechanism too (ie, I could get the timestamp of each edge?).

Personally, I love that the FPGA does all the 'hard' things for you. The main annoyance I have is that only things documented are the WPILib public interfaces -- all the lower level stuff is left as 'magic', and don't always provide all the possible options one might want.

[Joe Hershberger]

Do tell about these timestamps.

In the process of looking at the state of the InterruptableSensorBase class to explain this to you, I discovered that the class was never finished. I'm not sure if or how it has ever worked. It never reserves an interrupt number and it uses an uninitialized variable as the interrupt number. I guess no one is using interrupts since no one has complained about the total lack of functionality yet.

The way it is supposed to work, is you would use the tInterrupt object (assuming you constructed it successfully), and you would call readTimeStamp on it in your interrupt handler. There is one option that may not be clear: WaitForAck... If this is true, then the timerstamp will remain unchanged until the interrupt is acknowledged. Otherwise, it can change at any time. This only makes a difference if you are getting events very quickly... i.e. faster than you can enter the handler. It means that you are choosing if you want the time of the first event that cause you to vector the the handler or the time of the most recent event at the time the handler is executed.

And does the counter have such a mechanism too (ie, I could get the timestamp of each edge?).

It sounds like what you are wanting is actually exactly what the interrupts do (time stamp events). Counters do something similar (or rather the timers attached to the counters) but presumably more useful... they return the time between edges. It is asumed that you are interested in the difference, not the absolute times. You would just subtract the edge times once you get them anyway, right? Because it is a difference, you don't have to make sure you read two consecutive edges. You can just read whenever, and it is still valid.

Another way to accomplish this is with DMA (no library support in C++ yet). You can setup a DMA transfer that will send the timestamps to the processor memory every time an external line changes. There is only one DMA engine, though.

You could also use two counters (one for high semi-period and the other for low semi-period) and use DMA to transfer the samples so you know they are consistent.

Personally, I love that the FPGA does all the 'hard' things for you. The main annoyance I have is that only things documented are the WPILib public interfaces -- all the lower level stuff is left as 'magic', and don't always provide all the possible options one might want.

I hear you there. The documentation was a very manual process during the development this year. It took lots of time just to come up with the basic register documentation that we have now internally. I hope to release a full register map some time this summer. To do that, I need to develop a tool that will convert documentation in the code into a format that can be turned into a nice HTML format. Similar to the way doxygen works, but for register maps.