|
|
|
 It's all about bragging rights, awards, and pushing the envelope, not necessarily winning or practicality. - ahecht [more] |
 |
|
|||||||
|
||||||||
|
|
Thread Tools |
Rating: 
|
Display Modes |
|
|
|
| It's all about bragging rights, awards, and pushing the envelope, not necessarily winning or practicality. - ahecht [more] |
|
|
|||||||
|
||||||||
|
|
Thread Tools |
Rating:
|
Display Modes |
|
#38
12-07-2010, 05:35
|
|||
|
|||
|
Re: Unexpected results from Encoder::GetRate()
I finally took the time to look into this issue. I found the source of the mysterious factor of 2 that was introduced for the patch. It's caused by the fact that the "Period" variable for TimerOutput is a fixed point number that is not decoded when TimerOutput is read as a complete structure... only when read from the direct accessor. That means the decoding must be done in the driver. Since the fixed point format is 24 bits with 25 integer bits, the data must be shifted by 1 bit position... the factor of two!
I've attached the final patch that went in for those who are curious. -Joe 
|
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| [BB] An unexpected change in plans | yodameister | General Forum | 22 | 01-12-2009 21:26 |
| Inconsistent reading from encoder get rate | rwood359 | National Instruments LabVIEW and Data Acquisition | 5 | 13-01-2009 19:10 |
| Results from Drexel, thanks from 365. | archiver | 2001 | 1 | 24-06-2002 02:44 |
| Results from GLR? | archiver | 2001 | 0 | 24-06-2002 02:44 |
| results from regionals | archiver | 2000 | 0 | 23-06-2002 22:31 |
Threaded Mode