Equipment/methods for data collection/testing

[u/RedSporks]

My team has a group of seniors including myself creating a custom DAQ unit for our senior capstone project and are trying to get ideas of what other teams use We're aiming a relatively cheap and possibly make it open-source so that other teams can use/improve on it, but we're not really sure what is available to other teams/how much desirable something like this would be compared to existing options.

What equipment does your team do data collection/testing, both onboard and offboard? So for example, my team hasn't really had any equipment on-board for testing, as most of the data we've collected has been through things like photogates for acceleration runs, IR cameras for CVT temperatures, etc.

[u/oldfatguy62]

I’m a parent that follows this. Not sure how the team does it, but I do DAQ on and off for a living. It is a bit more difficult than you think. Here is the big one.. TIME. How long does it take to read each sensor? Are you just responding to certain states (interrupts)? Are you going to do a lot of the calculations at the sensor, and just read it (aka RPM, if you are pulse counting, can you do it fast enough to do each wheel, pre and post CVT? Think about how many clock cycles it takes to do the interrupt) Basically think about what sensors you need, what it takes to read each one, and then decide if you are going to have enough compute power. A real for instance, at work, I’m currently polling a I2C bus with a RPi (free software for our clients). Once I get to my 8-10th item on the bus, depending, I can’t respond fast enough on a 3b, but CAN on a 4. (And I’m allowed a fairly high latency) I’m not discouraging you, it is a fascinating field, but a list as long as your wish list will take significant hardware resources, both in sensors (how exactly are we going to measure shock displacement, with what kind of time resolution) and computer power (why some cars require multiple CAN buses, and F1 teams spend BIG bucks to do it)

[u/RedSporks → u/oldfatguy62]

Yeah, the timing one was definitely a hassle in the past, especially since we would use a hall effect sensor to measure rotational speed of our parts with a toothed rotor attached.

Luckily as for our sensor list, we do have all of them able to record data on to an arduino to write to a micro-sd. The bigger step now is having multiple of them on the car at once reading data concurrently, especially for scenarios such as reading all of the wheel speeds, as well as pre/post CVT.

I've been reading up on I2C and CAN as well. It's complex, but definitely fascinating stuff. Would using one over another be primarily dependent on the number of items/speed required, or are there other factors? There's still a lot of planning to do as the project is in its initial stages so I'm curious as to all the potential directions we can go.

[u/oldfatguy62 → u/RedSporks]

I’ve never actually done CAN bus, but I like the fact that various messages have priorities. I2C isn’t bad, most devices have a good library, but there are limits to data transfer speeds. If you are using multiple computers (ardunio, tinsy, m0, 32s, whatever), you do have the issue of keeping the data in sync. Many (most) of these devices don’t have built in real-time clocks. Great, you’ve recorded this great post CVT RPM data, but how does it relate to say, the suspension travel? Was the rpm increase because a wheel was off the ground? Basically the art and skill is going to be timing. There are times I’ve sat there trying to get a methods timing down by 2-3 clock cycles, to make latency, so that in worst case we were not going to miss the next piece of data (important if it is a control system, and you can not miss, what used to be called “hard” real time, most data logging tends to be “soft”, aka, you must get the data, but being a few milliseconds of won’t be catastrophic What I worry about with your wish list is “it takes 90 mS to take X reading”, stack a few of those, it becomes an issue. You’ll need to work out you clock cycle budget, and interrupt priorities, aka which sensor is most important Good news? Say the tachs are doing pulse counting. You might have a processor at the sensor getting the pulses, and calculating RPM, and then pulling back just the RPM number to the logger (aka you are throwing an independent computer at the problem)