Help Start My Project: Hardware Selection

Hi Spark Funners! I am new here and to electronics in general. I’ve had my involvement with a little bit of soldering here and there in the past, but never actually tinkering with a micro controller.

I have a project I want to start with in order to get my feet wet in this as well as help a different hobby of mine, auto racing. The problem right now is my eyes glaze over at all the different parts and products I can get to do the same things. So many ways to skin the cat…. But what’s the simplest?

Ok so here is my current conundrum:

The goal is to process strain data from 4 different strain gages adhered to each axle of an AWD vehicle to measure torque. The data should be sent to the main controller in the car which will convert all sampled data into an analog 0-5v signal for the car’s computer to datalog the telemetry data. A rotating axle means the electronics will have to be small, battery operated, and have wireless connectivity to the main unit inside the car.

Of all the available things from Spark Fun, what is the best way to skin this cat? So, I know I will need 4 wheatstone bridge strain gages (from Omega) as well as a load cell amp like the HX711 for each one. Now we need to set up electronics to control and communicate from each node at each axle. Which micro controller is best suited here? Of course, we can find any nano board and separate RF radio chip etc, then we complicate it way more than we need to. Not only that, it will likely drain more precious power than we’d like.

So now for board selections of the wireless nodes. We’ll need a 3.3v board mainly because of battery power source with charging capability. For the boards, I see there are some with RF like the LoRa board, Xbee boards, and Bluetooth boards. I don’t want to have to breakout a separate wireless com board if I don’t have to. I just need a simple wireless communication link that transmits recorded strain gage data to the main unit within the car. What’s the best board for my project here?

As for the main unit in the car, that will be decided once the nodes are figured out I suppose. No point in getting something that is incompatible with the rest of the network. The biggest hurdle is the remote node units.

So what do you guys recommend and why? Lets hear it.

Thanks!

Hi ItzGenX!

I certainly want to welcome you and encourage you to learning more about electronics in general, and computers in particular.

Based on many decades of working with both, I’d very strongly advise you to start out with something like the [SparkFun Inventor’s Kit. (The [Sparkfun Inventor’s Kit for micro:bit uses the micro:bit which uses the graphical “makecode” system to program if you’re shy about text-based programming, though considering your goal, I recommend doing the Arduino based one.)

I don’t really want to discourage you, but as a retired Engineer, the project you’re describing is definitely non-trivial. I presume that you’re talking about having the strain guages on the rotating axles. This introduces a LOT of complexity in getting the data out – although there are ways to deal with them, they’re not for the “faint of heart”. (I’d be inclined to go with slip rings to get power to the sensors, have the analog to digital portion on the axle, and have another slipring to get the digitized data into the non-rotating world.) With short range communication needed in a car, I might start by looking at the Artemis (be aware, though, that portions of the software are still under development), but in reality, once you’ve made the transition from rotating to non-rotating, you’re probably better off going with wired connections. The RF noise in an auto can be a problem (ignition noise, both from your vehicle and nearby vehicles, can play havoc with things like BLE), plus you may be trying to transmit through metal parts which is, to say the least, difficult. Another point of complexity is the need to calibrate the strain guages. And I’m not at all sure that you’re going to be able to get the “car’s computer” to datalog the data (and going back to an analog signal introduces yet more complexity).

If you have someone who really knows what they’re doing to act as a “mentor” to guide you, you might be able to do this project as a “first one”, but if you are doing things on your own, at least do your self a favor and get your “feet wet” by starting with some “beginner’s” stuff, like the “Inventor’s Kit”, keeping your goal in mind though.

With all that being said, I still want to wish you the best of luck with it! BTW, I should mention that over the years, I’ve abandoned several projects, but have still had a LOT of fun!](SparkFun Inventor's Kit for micro:bit v2 - KIT-17362 - SparkFun Electronics)](SparkFun Inventor's Kit - v4.1.2 - KIT-21301 - SparkFun Electronics)

I am no stranger to C++, so text based coding isn’t too crazy. As long as I have a few examples of usage and a list of commands and syntax, I should be able to figure that part out. I do have Arduino components in mind as well. The biggest dilemma I am facing is which to choose from at this point. There are so many out there. I am thinking of shying away from BLE and leaning more towards a separate radio transceiver like the RFM69HCW.

The reason I am focusing on a battery powered unit with wireless connectivity is really for simplicity of being able to take it off the car when not in use or charging the batteries. Slip rings are bulky and pose a reliability issue due to their wearing components. Additionally, slip ring connectors in the high speed variant (over 2k rpm) cost an arm and a leg. We’re talking over $1000 each, and I would need 4 of them. The car’s axle speed reaches about 2200 rpm on the back straight of certain tracks (near 190mph).

My car’s ECU (Haltech Elite 2500) should easily accept an analog or frequency signal as it does have several spare inputs that are user configurable. It lets you calibrate sensors etc from there. So for calibration, I can adjust what values being fed in would actually equal, and enter it into the ECU manager. I can do this by simply hanging different weights with a 2 foot bar on the wheel axle nut while jacked up in the air to have some calibration data.

After proof of concept and prototyping:

I plan on encapsulating the hardware into an epoxy resin sleeve split in half as two shells that can be screwed or bolted together onto the axle shafts. The electronics hardware with counter weights will be in one shell, and the other half will have the battery. Simple male/female pins cast into the shells will mate together to provide power connection between the two. An access hole to plug in the USB connector will also be along the split mating surface. A flat silicone gasket will be between the two shells to prevent any water or dust getting into the battery or USB connections. The only wires protruding out of the resin shell should be the 4 wires for the wheatstone bridge strain sensor and a piece of antenna wire. The antenna wire can be wrapped around the axle and zip tied down, nail polish or cap the end of the wire to prevent moisture wicking back to the radio. The strain sensor wires will be terminated into a weatherproof connector. Casting molds and jigs will be created for repeatability in the case I need to make more later.

The RF noise in an auto can be a hassle (ignition noise, each from your automobile and close by vehicles, can play havoc with matters like BLE), plus you can also be making an attempt to transmit thru metallic components which is, to say the least, difficult. Another factor of complexity is the want to calibrate the pressure guages. And I’m no longer at all certain that you are going to be in a position to get the “car’s computer” to datalog the facts (and going returned to an analog sign introduces but greater complexity).

ArizonaClark:
I don’t really want to discourage you, but as a retired Engineer, the project you’re describing is definitely non-trivial. I presume that you’re talking about having the strain guages on the rotating axles.

I’d written a lengthy reply yesterday but apparently rebooted my PC prior to submitting. Only the sharpest minds can pull off such a feat so take that into account when assessing the next couple paragraphs.

In any case, I agree that this is much more of an analog sensor design project than a digital controller and wireless telemetry project. Making an axle into a torque transducer will not be easy, if it’s possible at all. For one thing, strain gauges are normally bonded to a highly engineered and machined material so that they flex an optimal amount and in the desired direction. This comes at the expense of overall strength which is at odds with how a vehicle axle needs to perform. I’m imagining the torque will be in the hundreds of foot-pounds so I also agree calibration might be a challenge. I’d definitely get the torque transducer repeating and somewhat linear on a bench before moving to any controller or radio aspects or thinking too much about protecting the system from environmental hazards.

In case we haven’t rained on OP’s parade enough already, there’s another mechanical problem. I’m not sure how or even whether you can fully separate the horizontal & vertical shear forces from the desired rotational torque. The axle will be rotating but it will also be moving & flexing with the suspension, up and down with shifts in weight & road imperfections and forward and backward with braking, steering, throttle, etc. This motion also complicates the use of slip rings. This means that OP might overcome the very significant challenges of actually making a functional torque transducer from a vehicle axle and then figuring out a way to get the electronics integrated only to find the data doesn’t significantly correlate to torque.

That said ItzGenX, I think your approach of putting a battery on the axle would probably be the way to go. Come to think of it, I wonder if centrifugal force has a major effect on common battery chemistry.

Hi ItzGenX!

This morning it occurred to me that there might be less challenging, but still possibly very interesting project for you to “get your feet wet” in electronics: record the readings for an IMU (Inertial Measurement Unit) and maybe feed them into the ECU. You could get accelleration (in three dimensions), and if you get one with rotation, you can see when the vehicle deviates from “optimal course”. You get some useful data, and experience with electronics, with a “first project”. (I’d remind you that had NASA tried to send men to the moon and back with their first rocket, they would have almost certainly failed. IMHO, it’s much better to take several smaller steps in the direction you want to go than to attempt a giant leap.)

I also think that brow has a good point that there are other stresses involved that can throw off your measurements. Plus, I’m a bit leary of thinking that the response of the drive shafts will be all that linear. Single point static calibration is far from ideal, though I’ll admit that it’s better than nothing. You might could do better with one of the “guage” type torque wrenches (if it’s been properly calibrated), and doing it with the shaft at several different angles, also seeing how the reading changes when you apply different torques.

I think that brow will agree that we very much want to see you eventually succeed with your project, it’s just that based on our experience, we don’t want you to “bite off more than you can chew” and get discouraged.

Turning the axle into a torque transducer is simple enough by measuring shear of the twisting axle shaft of known torque values and logging the data for calibration. Typically, this means having two strain sensors mounted on opposing sides of the shaft to mirror each other which can cancel out any bending or stretching and focus more on shear/twist. The shear is measured with the resistor grids in 45 degrees to the rotating axis of the shaft. Each strain sensor has two grids laid on them aiming 45 degrees upwards and downwards in a < layout. Braking will measure a negative value from zero load which is to be expected and can be logged in the ECU as well. The strain sensors will be bonded directly to the center of the axle shafts, and the only prep will be removing the paint/corrosion coating prior to bonding. I have several engineering papers referencing the optimal positioning and setup of strain sensors to measure shear/torque on a rotating shaft. Solid metal shafts usually have a linear elasticity when twisted which is good unless it has been through some form of plastic deformation. Even if readings do not come out linear, I can map a custom sensor calibration curve for each axle in the car’s ECU in small intervals up to about 400 ft. lbs. per axle reliably since the axle nuts are torqued down to about 390 ft. lbs. The remaining calibration can be extrapolated based on the known curve.

The calibration data does not need to be exact. It is more of a reference point to the car itself in historic datalogs to monitor overall performance health, locate drivetrain issues, and incorporate torque limiting or AWD biasing strategies based on known grip levels of surface conditions for any given event. The key is consistent data rather than real world comparable exact force values, and ballpark figures will do well as long as it scales between each axle on the car in a predictable manner.

I have already calculated the centrifugal G’s that the units will be subjected, and it came out to around 120-130G’s peak if the car was ever topped out, and most of the usage would be under 50G’s on more common smaller tracks. Originally, I was going to plan for only two units, one for the front and rear driveshaft. However, the larger diameter of the driveshaft coupled with a faster rotation speed equated to 8500-9000G’s at peak speeds which would only be possible with induction based power transfer that would complicate things even more. I think the cylindrical metal AA sized lithium cells can handle the 130G’s every once in a while. Dropping the battery at waist height onto solid concrete would produce far more loading which I have admittedly done quite a few times fumbling with other projects, and the batteries were fine and still in use.

At this time I am going to go for the following:

-Redboard Artemis to act as the main unit.

-Redboard Artemis Nano to act as the sensor node unit.

-HX711 Load Cell Amp to interface strain sensor set on a dummy axle.

-915MHz Transceiver RFM69HCW for wireless linking since Artemis’s bluetooth appears to not be so great at the moment for com links. The radio can be removed once bluetooth is ironed out.

First, I’ll start with baby steps and get the Redboard to light an LED or something. Then try to have the Nano board to communicate with the main unit and light the same LED remotely in both directions. After that, I’ll dive all the way in and get some strain data on the bench, then try to beam it over to the Redboard.

Once I figure all this out, I’ll move onto the next project which is a graphical 7"-9" LCD acting as a digital gauge cluster operating on CAN bus data that the ECU is spitting out.

Hi ItzGenX!

Sounds like you DO have a lot more expertise than your original post suggested.

I’ve thought of another potential problem, and that is that the axle, being metal, may interfere with the RF, whatever you’re using. (It will definitely be “near field”, and will, therefore, change the “pattern” of the antenna.) A simple way to check to see if this is going to be a problem is as soon as you get the Redboard and the Nano “talking” to each other via RF is to set up a program where the RedBoard sends a message to the Nano to which it responds, and if the Redboard gets the right response it sends one message to the serial monitor, and if it doesn’t get the correct response it sends a different message, like the count of missing/incorrect responses, to the serial monitor. Set up the axle on the bench, and, usiing (for instance) masking tape, attach the Nano roughly where you plan to put it permanently, placing the Redboard roughly the distance away that it will be in the car (or maybe even a little farther). Now rotate the axle slowly through at least one or two (better more) revolutions. If you have no missed responses, great! If possible, repeat this with the axle inside its housing.

I trust that you’ll look for an LCD screen that’s “automotive rated” – cars sitting in the sun all day can get quite hot inside, and some LCDs aren’t built to stand up to that.

Good luck with your project, and I hope we hear about your progress and completion!

Thanks for the responses.

I think with bluetooth having such a tiny built-in antenna, the axle shaft would cause a problem with signal eclipsing. Although, metal and surrounding sheet metal all over can also cause somewhat of a reflection of some RF signals, so more testing is definitely warranted in that regard. Currently, the Artemis’s bluetooth radio doesn’t have fully functional libraries and code to reliably link and communicate with other Artemis MCU’s. When they figure that out, I’ll definitely give the BLE a test to see if it is even practical in my application.

With bluetooth out of the picture right now, I plan to use the RFM69 which will have an antenna wire almost 3 inches long for the rated frequency. That is more than enough to fully loop around the axle shafts, so rotational eclipsing shouldn’t be a problem, but it will still need to be tested while in the car. The main unit’s radio transceiver location is at the center of the car, and it will be mounted in the transmission tunnel with the antenna tethering down and adhered to the bottom of the transmission which has line of sight to the wheels, not the axles. I am counting on some degree of RF bouncing here to complete the communications journey.

Thanks for the recommendation of an error check/responding between the units. I’ll definitely incorporate that to keep an eye on any possible packet losses.

The LCD I have chosen is from 4D systems which appears to have been used in many automotive projects when google searching and browsing youtube. I’ll loop back to this as the second phase of the project.

Sorry for the delay in responding – it’s been a bit hectic around here the past few days.

That length of wire antenna is (likely) calculated for it being in “free space”, and more-or-less straight. If you wrap it around something, say a cardboard tube, you dramatically change the “pattern”, as well as possibly changing the resonant frequency. Substitute a conductor, especially a ferromagnetic one (e.g. a piece of steel) for the cardboard tube and you are going to throw the resonant frequency WAY off, as well as doing bizzare things to the emission pattern. I’m not an antenna guy by any stretch of the imagination, but I do know a few of the basics. I presume that you’re going to be using the 915 MHz version rather than the 434 MHz version. (In the U.S. the former is in the “ISM” band and doesn’t require a license. The latter is in one of the “ham” bands and you could use it for non-commercial use if you have an Amateur Radio License.) You might be able to find help in checking the resonant frequency from Hams in your area, and might even find someone who can do the math to try and see how that antenna will perform. In any event, be sure to do testing early on.

Anyway, good luck, and please keep us posted!