1054: How to modify its Phidget example C++ code

[dan.hariton]

Hello:
Question: How to reduce the minimum default aperture (?timeOut?) of 32msec to 16msec and to 8msec?

Connected the 1054 Frequency Counter to measure frequency from a programmable TTL signal generator, the UDB1005.
http://www.amazon.com/SainSmart-UDB1005S-Function-Generator-Frequency/dp/B00JTRFZB4
Running C++ on Open Suse Linux 13.2 x64, and the Phidgets "FrequencyCounter-simple.c" //FrequencyCounterTest.cpp
The example program tracks correctly the dial-in frequency in the sense that the aperture automatically tracks the lower frequencies by becoming longer to capture a longer period.
Here below are (abbreviated) results:

Attach handler ran!
PhidgetFrequencyCounter
Version: 101 SerialNumber: 427727
// Dial-in a decreasing frequency:
// 10-->9-->8-->7-->6-->5-->4-->3-->2-->1 [KHz] and
// 1000-->900-->800-->700-->600-->500-->400-->300-->200-->100 [Hz] and
// 100-->90-->80-->70-->60-->50-->40-->30-->20-->10 [Hz] and
// 10-->9-->8-->7-->6-->5-->4-->3-->2-->1 [Hz]

Count Event (0) - 320 counts in 32ms - 10003Hz
Count Event (0) - 288 counts in 32ms - 9000Hz
Count Event (0) - 256 counts in 32ms - 8000Hz
Count Event (0) - 225 counts in 32ms - 7001Hz
Count Event (0) - 192 counts in 32ms - 6002Hz
Count Event (0) - 160 counts in 32ms - 5003Hz
Count Event (0) - 128 counts in 32ms - 4003Hz
Count Event (0) - 96 counts in 32ms - 3000Hz
Count Event (0) - 64 counts in 32ms - 2000Hz
Count Event (0) - 32 counts in 32ms - 1000Hz
Count Event (0) - 29 counts in 32ms - 900Hz
Count Event (0) - 25 counts in 31ms - 800Hz
Count Event (0) - 23 counts in 33ms - 700Hz
Count Event (0) - 20 counts in 33ms - 600Hz
Count Event (0) - 16 counts in 32ms - 500Hz
Count Event (0) - 13 counts in 32ms - 400Hz
Count Event (0) - 9 counts in 30ms - 300Hz
Count Event (0) - 6 counts in 30ms - 200Hz
Count Event (0) - 4 counts in 40ms - 100Hz
Count Event (0) - 3 counts in 33ms - 90Hz
Count Event (0) - 2 counts in 25ms - 80Hz
Count Event (0) - 2 counts in 29ms - 70Hz
Count Event (0) - 1 counts in 17ms - 60Hz
Count Event (0) - 2 counts in 40ms - 50Hz
Count Event (0) - 2 counts in 50ms - 40Hz
Count Event (0) - 1 counts in 33ms - 30Hz
Count Event (0) - 1 counts in 50ms - 20Hz
Count Event (0) - 1 counts in 100ms - 10Hz
Count Event (0) - 1 counts in 111ms - 9Hz
Count Event (0) - 1 counts in 125ms - 8Hz
Count Event (0) - 1 counts in 143ms - 7Hz
Count Event (0) - 1 counts in 167ms - 6Hz
Count Event (0) - 1 counts in 200ms - 5Hz
Count Event (0) - 1 counts in 250ms - 4Hz
Count Event (0) - 1 counts in 333ms - 3Hz
Count Event (0) - 1 counts in 500ms - 2Hz
Count Event (0) - 1 counts in 1000ms - 1Hz
...
//Dial-in a frequency step:
//1KHz-->1Hz-->10KHz-->1Hz-->100KHz-->1Hz-->1MHz-->1Hz-->1KHz

Count Event (0) - 32 counts in 32ms - 1000Hz
Count Event (0) - 1 counts in 1000ms - 1Hz
Count Event (0) - 320 counts in 32ms - 10006Hz
Count Event (0) - 1 counts in 1000ms - 1Hz
Count Event (0) - 3201 counts in 32ms - 100000Hz
Count Event (0) - 1 counts in 1000ms - 1Hz
Count Event (0) - 32020 counts in 32ms - 1000000Hz
Count Event (0) - 1 counts in 1000ms - 1Hz
Count Event (0) - 32 counts in 32ms - 1000Hz
Closing


Would very much need to reduce the 32msec aperture to 8msec.
I do not need frequency readout smoothing(averaging).
For lower frequencies the example program increases the aperture in order to capture one longer period, this is fine.
For higher frequencies, the example program reduces the aperture down to 32msec, beyond which the aperture remains a constant 32msec.
At 1KHz I just need 1msec not 32msec.
My goal is to get as many frequency readings as possible, and live with the numeric jitter.
Need more data points and less numeric A/D precision.
The frequency I am monitoring varies from 0Hz to 300Hz max, in less than 1 minute.
The frequency variation is monotonic, decreasing (300Hz-->0Hz) or increasing (0Hz-->300Hz).
At 300Hz would like the aperture to adjust (decrease) to 4msec.
I could not locate the 32msec limit in the example program.
Please advise.
Thank you,
Dan

[Patrick]

1054 works by giving you events with number of counts / unit of time. The time resolution is 1 microsecond, so you can calculate accurate frequencies, but the data is only delivered from the 1054 to the PC at 32 ms intervals - and this is a fixed interval that cannot be changed.

Are you looking for faster response time, or greater accuracy?

-Patrick

[dan.hariton]

Thank you for this clarification.

Are you looking for faster response time, or greater accuracy?

Definitely faster response time. This is my primary concern.
My goal is to get as many frequency readings as possible, and live with the numeric jitter.
Need more data points and less numeric A/D precision.
Need the frequency to be calculated and transmitted to PC after 1 count (when the input frequency is 300Hz~400Hz).
Presently one transmission occurs after 10 counts (with the input frequency being 300Hz~400Hz and with 32msec communications aperture). I really can use all the other 9 counts/data points. Any suggestions regarding alternative ways/mods/hardware capable of 3msec (10x faster) communications aperture?
No greater accuracy needed. The present hardware accuracy quoted as +/-1usec (microsecond) is fine. (Scenario: digital counter counting 1MHz pulses via clock gating; counter resets on incoming falling edges, etc). Would a hardware modification be possible (at what cost?) Could you please describe what obstacles / technical difficulties contribute as limiting factors. Suggestions /contacts?
Thank you

[Patrick]

What OS are you using?

The interrupt rate is hard coded in the firmware, and not changeable. I may be possible on Windows to change the interrupt rate - I know this used to be possible, but this may make the firmware unstable.

-Patrick

[dan.hariton]

What OS are you using?

The interrupt rate is hard coded in the firmware, and not changeable. I may be possible on Windows to change the interrupt rate - I know this used to be possible, but this may make the firmware unstable.

-Patrick

Running C++ on Open Suse Linux 13.2 x64, Intel i7 processor 3.4GHz 16GB DIMM
These are the Linux steps:
1) Open a root shell
SU + password
2) Compile the executable "execname" file
gcc example.c -o execname -l phidget21
3) Either run the executable with on-screen display for real-time visual evaluation:
./execname
4) Or run the executable with ">" output redirect and save results to "filename" text file
./execname > filename.txt

The possibility to change the interrupt rate seems encouraging.
Linux is my preference over Windows.
Definitely need going faster with unstable firmware risk penalty.
How much faster is the question?
Would the instability manifest gradually or like a step? I hope and wish to find-out.

Thank you, please advise.

[Patrick]

Changing the rate on Linux would require changing the kernel USB driver and recompiling the kernel. Also, I had a look, and this change is no longer possible on Windows.

I modified the firmware to use 4ms intervals, and it's stable. If you like, I can sell you a modified 1054, or you can send yours to me and I can re-flash the firmware.

-Patrick

[dan.hariton]

...I modified the firmware to use 4ms intervals, and it's stable. If you like, I can sell you a modified 1054, or you can send yours to me and I can re-flash the firmware.

This 4msec is really nice ! Thank you so much.
I did purchase two 1054 Phidgets, each having dual inputs. Would like both 1054 Phidgets to have their firmware re-flash-ed, and would like to mail them to you for this modification.
Please send (or email) the complete name and address where I may send these two Phidgets.
I will attempt to pay full postage for FedEx with 1-day deliveries (both to send and to return).
NB FedEx does require the recipient's phone number.

[Patrick]

Sent you an e-mail.

-Patrick

[dan.hariton]

I have tested the improved 1054 frequency counter. It is working well. The improvement consists in reducing the communications aperture window (where applicable; for one frequency reading) from 32msec to 4msec.
Before -at 250Hz input frequency- the old 1054 was generating 30 frequency readouts per second.
After -at 250Hz input frequency- the new 1054 is generating 250 frequency readouts per second.
A welcome improvement of 8X.
Here are the test results for the new 1054 (same 1054 with new firmware):
For the same input frequency=250Hz I ran the 1054 FrequencyCounter-simple.c program for 1 minute.
In the 1054 FrequencyCounter-simple.c program I reduced
#define FREQS_SIZE 20
to
#define FREQS_SIZE 1
In 1 minute the 1054 collected 60000msec/4msec=15000 frequency readouts.

Readout sample:
//1054 4msec-Aperture Phidget Frequency Counter
//Version: 102 Serial Number: 427727
Count Event (0) 1 counts in 3.990 msec 250.627 Hz
Count Event (0) 1 counts in 3.990 msec 250.627 Hz
Count Event (0) 1 counts in 4.030 msec 248.139 Hz
Count Event (0) 1 counts in 3.990 msec 250.627 Hz
Count Event (0) 1 counts in 3.990 msec 250.627 Hz
Count Event (0) 1 counts in 4.000 msec 250.000 Hz
Count Event (0) 1 counts in 3.990 msec 250.627 Hz
Count Event (0) 1 counts in 4.000 msec 250.000 Hz

Excel statistics on the 15000 frequency readings:
249.984Hz = Average Frequency
0.866328973Hz = Standard Deviation (*)
250.627Hz = Maximum Frequency
247.525Hz = Minimum Frequency
(*) NB standard deviation has meaning only for a Gaussian distribution (not the case here); I computed it just to get a warm and fuzzy feeling, what if...

Thank you Patrick

[Patrick]

Glad to hear it's working out for you.

-Patrick