Link Copied
I have to turn off the num_threads to get it to compile, the linker throws an error. This is on a dell precision that is working hard on two accelerometers at the same time.
I created a new Fortran program in VS 2022, added the code and followed what I thought was the manual instruction to add the -qopenmp.
I then placed the picture and knew someone would advise me of my mistake.
I tend to agree with Andrew the problem is to small to be useful. I was using IFORT and WIN 32.
A two core machine is going to be doing other things, so I do not expect much change.
I have a program that spins up 4 threads and I time each thread, the 2nd and the 4th are identical except for the data, long term, say a day the 2nd returns in 1.5 seconds and the fourth in 10 seconds. As long as it is less than 12 seconds it is in front of the other two threads and God smiles at me again.
Here is the full solution.
It was just a bit of fun whilst I try and work out how to synchronize two accelerometers to yield the same frequency set for a given vibration.
This is 2 accelerometers at the same location on the same computer on two identical programs. The linear regression is the difference in speed - 1.03 factor. So the timer in the accelerometer is not returning real time, it is returning consistent time, but not in seconds, one uses the ticks on the computer to calibrate this data and then work out the dodgy factor to adjust the ratio of the FFT steps to real frequency and then compare the original results for frequency response. Of course you cannot get two accelerometers in one spot and I have not as yet bought a shaker. One day. But my desk shakes at 42 Hz.
The 1.08 is the difference once I add the code to determine the rate of the timing counter.
Jim:
Sorry I used a poor word choice and you are absolutely correct.
The program loops and reads the buffer from the accelerometer, in hexadecimal, one has to search through the hexadecimal for the ALPHA characters ST. Once found you have a data set that is 14 blocks long of acceleration data. You play with that.
Theoretically you can ask the accelerometer to send you "the internal timing counter" this is not fixed to real time in any strict sense, certainly not close enough to pass a test on this in Physics 1 at ANU. They were hard taskmasters. It is supposed to come back at a rate of 30 to 1 for the acceleration data, it does not, so I have to read the timing register directly, so as not to slow up the process to much I only do that about every 1000 data points.
Plus there is a horrendous latency time, you really do not know when the readings were taken - the buffer can be 1 to 1200 long.
So I use the ticks on the clock, each time I write a single record to the CSV file I put the ticks with it. I also store the ticks in an array of 835584 length - 16384 records in 51 sets.
I can then do a linear regression on the stored ticks data and get an approximation of the rate of progress on the data stream.
I have ten accelerometers, to save on NUC costs, this is the expensive part, I want two accelerometers running on the one NUC, as the PI wants to know the difference in stiffness for wood that is 260 years old that has no nails and nail - iron intrusion.
The slope on the linear regression of the tick data can be used to convert the FFT steps to Frequency. I can then compare the results for the two accelerometers at a single location, ie on my desk side by side.
On the output screen I can add the current estimated frequency. I average the frequency over 4 - 16384 time periods so it does not pop around to much.
If I plot the output rate for the overall 51 set files, about 8000 per day, I can get the rate difference between the two accelerometers and compare it to the estimate of frequencies and I can compare the estimated frequencies from the results.
The real issue is the serial read on the accelerometer, it is straight out of the 1980's.
This is the graph of three days monitoring the output for the two instruments, the third on at 1.015 times, reflects the addition of the code to monitor the frequency.
I do track the timing data from the accelerometer and compare it to the ticks to see if the number is remaining constant and it appears to as long as you take long enough time.
ST.COM manuals tell you all the electronics, but the physics is something else.
Theoretically the accelerometer is told to run at say 1666 Hz, but you will only get that if you do nothing else, as soon as you have code the buffer read rate slows up. As long as the read rate is above 1300 I am happy that gives 600 Hz and most structures are quiet above about 400 Hz.
