Best way to measure period between pulses? Counters and FPGA

[Mr. Lim]

Originally Posted by jhersh

There is a finite resolution on the timing of the pulses. That period is 6.525 us per edge. In your system, does that correspond to 375 RPM? You may want to turn on averaging to improve the resolution (but increase the latency).



Sounds like a coincidence, maybe? Where are you getting 20ms as the refresh period? Just because that's the Driver Station's packet rate?



No. The FPGA only implements method 2.

Thanks a TON Joe!

This post clarified pretty much everything we're seeing.

We WERE hitting the 6.525us timing resolution per edge. That corresponded (coincidentally) with the resolution of 375 RPM we were seeing, at our desired speed.

There'll be a more detailed post, or even a whitepaper once we've sorted everything out, but we've got a really neat solution together involving SetSemiPeriod(true), a mostly white disc with a single small black sector, and an averaging window that holds about 10ms worth of reads at our slowest speed.

[Ether]

Originally Posted by Mr. Lim

we've got a really neat solution together involving SetSemiPeriod(true), a mostly white disc with a single small black sector, and an averaging window that holds about 10ms worth of reads at our slowest speed.

May I ask? What is the slowest speed you want to control, and what speed are you running your speed control algorithm?

[AdamHeard]

Originally Posted by jhersh

There is a buffer that will hold up to 127 samples for each counter / encoder. It has write pointer that does form a ring buffer. The sum of the samples between the write pointer - average_size (usually) and write pointer are summed every 0.1 us * average_size (yeah I know... overkill) and made available to the driver (i.e. not on demand) along with the number of samples available. When a counter is reset, the write pointer is moved to mark all samples unwritten (so the "count" returned would be 0).

The I/O is 6.525 us from sample to sample. The timer used has a 1 us resolution. So the actual resolution is 6..7 us. However, the error is not cumulative across the average. Regardless of the number of samples averaged, the error is less than 7.525 us.



The FPGA interface function is called writeTimerConfig_AverageSize(). Looks like we never exposed that to the WPILib API layer in C++ (and therefore Java). It's exposed in LabVIEW.

Cheers,
-Joe

So, we are unable to use this with C++?

[Ether]

Originally Posted by AdamHeard

So, we are unable to use this with C++?

See post #29 in this thread:

http://www.chiefdelphi.com/forums/sh...3&postcount=29

[TravSatEE]

Originally Posted by jhersh

That is what I was saying. It is not in the WPILib API layer in C++ and Java. That means if you care to use the hardware feature, you need to move down a layer.

Cheers,
-Joe

Are you aware of any other features that are not implemented in C++ or Java but are in LabView (even outside of counters)?

I'd also appreciate any clarification on what you mean by moving down a layer. Other than switching to LabView, is there some other action that can be taken? I thought the FPGA code was handled by the cRIO imaging tool and no modifications to the FPGA programming are allowed. Is this your understanding as well? I am not sure if your comment implies more is available.

[jhersh]

Originally Posted by TravSatEE

Are you aware of any other features that are not implemented in C++ or Java but are in LabView (even outside of counters)?

I think Java is missing SPI maybe?

In general we try to make everything the same.

Originally Posted by TravSatEE

I'd also appreciate any clarification on what you mean by moving down a layer. Other than switching to LabView, is there some other action that can be taken? I thought the FPGA code was handled by the cRIO imaging tool and no modifications to the FPGA programming are allowed. Is this your understanding as well? I am not sure if your comment implies more is available.

The FPGA code is there. It does not need to be edited.

The layer that most people write their code is only in the "User Code" layer. The layer below that is the "WPILib" layer. That is the layer that I mean that you need to edit if you want this functionality in that language. You may even be able to call into the FPGA interface layer directly from your user code if you call it at a time that it won't be overwritten by WPILib.

[Joe Ross]

Originally Posted by TravSatEE

Are you aware of any other features that are not implemented in C++ or Java but are in LabView (even outside of counters)?

I've been filing bugs in the WPILIB Java tracker when I find something that is implemented in LabVIEW but not in Java. See http://firstforge.wpi.edu/sf/tracker...ilib_java_bugs

The things I've found are SPI, DMA, and CAN periodic status. Someone else filed a bug about digital input interrupts only being partially implemented. For SPI, I attached an implementation that works for me in the tracker.

[TravSatEE]

Originally Posted by jhersh

I think Java is missing SPI maybe?

In general we try to make everything the same.



The FPGA code is there. It does not need to be edited.

The layer that most people write their code is only in the "User Code" layer. The layer below that is the "WPILib" layer. That is the layer that I mean that you need to edit if you want this functionality in that language. You may even be able to call into the FPGA interface layer directly from your user code if you call it at a time that it won't be overwritten by WPILib.

Thanks for your clarification, jhersh. I understand what you mean now. The students do edit WPILIB also. However, this year the netbeans plugin makes this more difficult. The wpilib netbeans project directory and source code were placed in .zip files. I have not understood why this was done. I think we need to make the code more quickly accessible, and this repackaging does the opposite.

Originally Posted by Joe Ross

I've been filing bugs in the WPILIB Java tracker when I find something that is implemented in LabVIEW but not in Java. See http://firstforge.wpi.edu/sf/tracker...ilib_java_bugs

The things I've found are SPI, DMA, and CAN periodic status. Someone else filed a bug about digital input interrupts only being partially implemented. For SPI, I attached an implementation that works for me in the tracker.

Joe, thanks for this input. I had actually stopped looking at this website since it seemed like the development work slowed down there and WPI had since created other websites. I do know that java wpilib has changed some since last year, but the underlying squawk java virtual machine is still timestamped December 2011 when the cRIO boots. There are other features missing as well, such as UDP networking support. This is actually highly misleading in the wpilib javadoc, as the documentation implies that the functionality exists. However, the code executes with a runtime exception. Frustrates the students to be this misleading. Some of the javadoc in general leaves a lot to be desired also.

I'll happily work with the key java developers on the above.

[Joe Ross]

Originally Posted by TravSatEE

I had actually stopped looking at this website since it seemed like the development work slowed down there and WPI had since created other websites.

The Support Page on screenstepslive says to file bugs in the firstforge tracker. There have been 7 java bugs closed since kickoff (4 documentation and 3 fairly simple bugs).

I figure that if there isn't a bug filed, you can't complain about it not being fixed.

[nightpool]

Hey, kinda a thread hijack, but this seemed like the best place to ask. We're using a photo-eye based encoder on our team (due to issues mounting traditional shaft encoders) and are having issues with GetPeriod() when we drop below 20 rps where it returns infinity about half of the time, and the correct speed the rest of the time. GetPeriod() apparently returns infinity only if the counter is "stalled". Does anyone know what this means, or if there's a way around it? Overriding GetPeriod doesn't work, as m_counter is private, not protected. I'm guessing that the FPGA has some kind of threshold where if it doesn't see an edge it assumes the wheel has stopped. Is there any way of modifying that, maybe giving it a large tolerance?

[Thad House]

The is a function you can use to set what the FPGA sees as stopped. its the setMinRate function.

[Joe Ross]

Originally Posted by sst.thad

The is a function you can use to set what the FPGA sees as stopped. its the setMinRate function.

In the Encoder class it's called setMinRate, in the Counter class it's called setMaxPeriod.

[MisterG]

Originally Posted by sst.thad

The is a function you can use to set what the FPGA sees as stopped. its the setMinRate function.

Originally Posted by Joe Ross

In the Encoder class it's called setMinRate, in the Counter class it's called setMaxPeriod.

Sounds like the answer to our problems.

I imagine that we don't want to use the stalled feature at all. Is there a downside to setting the max period to a high value? e.g. 6 seconds period is equivalent to 10 RPM. This would seem safe at any reasonably low speeds. Is there any functionality trade off to setting a high max period?

[nightpool]

Doesn't that mean it wouldn't be able to tell if the wheel is actually stopped?

[Thad House]

If you look at the code the only reason it has that function is to not have a divide by 0 error. In the get period function, it uses that bool in order to not make it divide by 0.