Measuring travel time of hammer

[Bob_Schor]

---

@BAJ19 wrote:

The sampling rate is approximately 30Hz as you said (see my reply to GerdW)  and we can calculate time manually but is there any communication between arduino and labview regarding the sampling rate?. and Is there a way to measure the time (or samples) automatically since the impact will be done multiple times.

---

Your Arduino program is sending data.  I don't know how your code runs, but it certainly outputs a lot of data per line, and also seems to output some "header" lines (judging by the data in Header.txt, which seems to come from Arduino).

Do you have any control over what Arduino sends to you?  There seems to be a lot of redundant and potentially unnecessary fields.  For one, you can eliminate all of the text fields (such as "X(Yaw):  ").  Second, there seems to be redundant information -- you have X, Y, Z as Roll, Pitch, Yaw, and as eul (which I assume are Euler angles, look identical to R, P, Y).  I'm further guessing that q are a quarternion representation (also redundant), etc.  If your sensor is a 6-DOF sensor, you only need to send 6 numbers!  Less data per line means (potentially) more samples/second.  Of course, you might not have much choice, as you might be using "canned code" from a third party that just gives you all these numbers.  Too bad -- 3D accelerometers are pretty cheap and simple (though calibration can be an interesting Problem-to-be-solved).

I don't know how you "time" your study.  I presume you set up the hammer, then do "something" to trigger it.  If I were designing this, I would do the following:

1. If timing were important to me, I'd want a sampling rate of 100-1000 Hz (for an event that lasts less than a second).
2. I would get "non-redundant" (a.k.a. "raw") data from the sensor.  For a 6 DOF accelerometer, this is 6 numbers.  If you have calibration data, and your acquisition system has adequate processing power, you could apply a calibration in the acquisition system and return results in calibrated units.
3. I would include a TTL Pulse that starts the Acquisition.  If the Acquisition system does not accept "triggers", it can wait in a "busy loop" running as fast as reasonable, just asking "Time to go?  Time to go? ..." until it is Time to go. 
4. Arduinos, of course, are inexpensive.  An NI DAQ device (a myDAQ or a USB-6002), which have triggers and much faster Analog Input capabilities, would be what I'd use if I wanted the kind of data and reliability that I think you need.

Bob Schor

[BAJ19]

Thanks Alot!!

I modified my arduino code to not send redundant information and increased my sampling rate to 60hz :). Whatever I do after that doesn't increase my rate anymore. Maybe limitation using serial visa? 

[BAJ19]

Thanks Alot GerdW!

Like you and Bob said, I modified my arduino code and stopped useless data being sent from it and now my sampling rate is 60Hz, an improvement but I will try to get it to 100Hz as specified by the sensor.

In the end i used the trigger and gate function to measure how many samples (using "number of waveform samples" vi) between the two level threshold and then do numeric calculation to obtain the travel time, since we know what the sampling period is. Thanks 🙂

[Bob_Schor]

Well, you could attach another "data dump" and we'll give suggestions ...  Hard to make recommendations without data.

Bob Schor

[BAJ19]

Sure!

Here is what I am getting after I modified the code. Much cleaner and uses way less data. Got my sampling rate all the way up to 152Hz now :). Don't know what else I can do to improve transfer rate now. 

[Bob_Schor]

Much better.  You still have a few places for improvement: 

• Header Field 8, "Calibration Status Values" (please, change the header to "Cal" if you decide to keep it!) has no entry in the Data columns below it (there's a double-<tab>, meaning Field 8 is represented by an empty string).  Surely you aren't "calibrating" individual readings, so I suspect this field can disappear (saves you 1 Tab character). 
• Fields 9-12 don't seem to be used at this step -- you write 0's in them.  Eliminating them will save 7 more characters (4 0's and three separating <tab>s).
• The header has a 13th field (because it ends with a <tab>, so there's a following empty field as <tab> (which is a field separator).
• Question -- how are you sampling?  I don't recall (and now that I'm answering your Post, I can't go back easily and see if you've posted code).  Ah, we are talking about Serial processing, so the answer is VISA, and thus there is no fixed hardware Sampling Time (as with DAQmx), no never mind what I was about to say about time.  Go to next point ...
• I'm assuming that the Time column represents something like LabVIEW's millisecond Clock, used as a timer.  If this is so, it looks like you've got about a 6 msec delta-t, corresponding to about a 150Hz sampling frequency (which is what you said), and thus much better time accuracy for your Hammer.  You should be more-or-less ready to get your data!
• You've got a 6-DOF sensor, but you really are interested in the net force acting on the hammer.  I don't know if you've calibrated your Accelerometer (or if it comes pre-calibrated).  Have you thought how you'd do it?  We had some students working with a Tri-Axial Accelerometer that had Axis Gains of 0.3 plus-or-minus 10% v/g, and an offset of 1.5 plus-or-minus 10% v/g, and none of these masters-level engineers(!) seemed worried about this (nor had thought about how to calibrate an accelerometer).  How would you do it?
• Also, how would you compute Net Force (which, I think, is the relevant measure you want)?

Bob Schor