This project was made in collaboration with 49ers Racing Formula SAE and their Internal Combustion team. The group was tasked with using the Particle Argon platform to create a system which could wirelessly measure engine coolant temperature and flow rate entering and exiting the car's radiator. The requirements of the project, as defined by Professor John McAlpine, are as follows:
- the system must use at least three Particle Argons
- the system must use at least three different sensors
- the system must have bi-directional communication between Argons
- the system must be able to graph the results as measured by the Argons
Guided by these requirements, the following sensors were chosen for the project:
- DS18B20 Temperature Sensor
- Battery Voltage Sensor (Included On Board Argon)
- GREDIA Hall Effect Flow Sensor
The concept is that using these sensors, the heat from the engine being dissipated by the radiator could be calculated at any given moment using the values measured from each sensor, as shown in the figure below:
Now in terms of how the Argons would be used, three would be employed for this project. One would be placed at each side of the radiator, and the other would be places elsewhere on board the vehicle to be used as a hope base. The bi-directional communication between these boards is rather simple:
Note that Particle A in the figure will be connected to both the flow sensor and a temperature sensor, whereas Particle B will be connected only to a temperature sensor. Because the coolant loop of the car is a closed loop, the mass flow of fluid is constant throughout the system, and therefore only needs to be measured once.
WiringTo wire this system, three enclosures were 3D Printed which would house the Argons and the sensors would be connected using a 5-Pin aviation socket connector. The Argon wiring diagram is shown below:
Note that a pullup resistor was required for the temperature sensors, and it uses a digital pin, whereas the flow sensor uses an analog pin and does not require a pullup resistor. Within the Argon code, a library called OneWire made the coding quite easy for the temperature sensor, and the flow sensor sends voltage back which is read by the Argon and calculated back into a flow rate from voltage using the equation f = (7.5*Q-4), where f is pulse frequency and Q is flow rate in Liters/min. This calculation is done in the code for Argon A before that data is sent back to Argon C.
The third sensor, the battery voltage sensor, is used to track battery voltage (as the system is intended to be wireless, battery life is a key element). Each argon is powered by a bank of 3 AA batteries, each producing 1.5 Volts for a total of 4.5 Volts. When the voltage reading dips below 2.8 Volts, just more than half total capacity, a light is turned on to indicate to operators that the batteries need to be changed. This was a beneficial way to do it because it kept cost lower by removing the need for more expensive Li-Po batteries.
AssemblyThe completed wiring and enclosures are pictured below. Note that the battery pack is stored below the red breakout board, and the switch originally included in the battery housing was removed and relocated to the outside of the enclosure to allow for the power supply to be turned off when not in use.
The original plan was to test this system on the Dynamometer in the Kulwicki Laboratory. Unfortunately, due to external circumstances, the wiring harness for the engine that was to be tested on the dyno is not yet complete, and therefore it cannot be tested in this way.
However, as a proof of concept and to show that the system works while the dyno is not an option, two cups of water were prepared; one hot, and one iced. Each of the two temperature sensors was placed in the hot or cold water until the temperature stabilized, and then they were quickly swapped. As soon as they were placed in the opposite temperature water, the command was sent from the home base Argon to begin recording the data, the data was passed from the sensor Argons back to the home base.
In addition, connected to the Home Base was the fluid flow sensor, which was tested by blowing air through it. As air is a fluid just like water, which is the coolant used in the FSAE engine, this was a perfect way to prove that the system works.
Meanwhile, all of the sensor data is simultaneously passed from the Home Base via a Webhook to Adafruit.io where it is plotted (see below for more info). This test was chronicled in the video below to show exactly how the test was performed and display the system in action:
Data GraphingIn order to effectively visualize data being recorded by the Argon's sensors, a tool such as Adafruit.io is used. A webhook included in the Argon's code collects data as it is published and passes it along to Adafruit, where it is compiled, plotted, and can be easily viewed and digested. One major limitation of this particular tool, however, is that it limits the number of times a webhook can be published to 30 times per minute. Meanwhile, the data from the Argon system is collected and published 60 times per second. Any time the Adafruit.io system detects that data is being published faster than this, it throttles the collection of data and causes a large delay in the data.
In an attempt to overcome this, the temperature data in the proof of concept test was slowed down to be collected only once every 3 seconds, or 20 times per minute. Despite the loss in detail in the data, this was considered to be an acceptable solution to the problem at hand, without having to pay extra money for upgraded features. An example of what the plotted data from the proof of concept looks like can be seen in the figure below:
This simple experiment confirmed that our system would be able to work once the dynamometer was in working order and could be refined enough to be used on the actual race car to monitor engine coolant temperatures in real time while in operation on the race track. It also proved that the two-way communication between the boards was working as designed, something which was a major challenge and milestone in the development of this project.
The biggest challenges that the group faced in this project was the limitation of the Argon's ability to publish events. In order to get higher fidelity data, a quicker data acquisition rate (~10 Hz) would be much more ideal. Furthermore, this roadblock was even more evident when it came to the Adafruit.io HTTP API, which is limited to 30 messages per minute in the free version, half the ability of the Argon to publish events. This means that the API would throttle multiple times throughout a test, leading to a loss of detail in the data. For the success of this test, the upgraded product was purchased for $10, which increased the limit to 60 messages per minute. Using a custom API and a different platform, such as an Arduino or Raspberry Pi would potentially mitigate these issues making it better and easier to use in practical application on track.
To that end, there are plans in place to continue the development of this system and to improve it enough to be used in real-world application.
Comments