Week #21 - June 13th to June 19th - CAN Filtering and GPIO

This week I focused on getting the One-Wire GPIO sensor working on the device. There are numerous tutorials online to show the basics of how this is done. One such tutorial can be found here: Raspberry Pi DS18B20 Temperature Sensor Tutorial - Circuit Basics. The image below shows the general configuration of the sensor and the required resistor that is used to pull up the communication line.

The actual sensor that was used is housed inside a stainless probe as shown in the water bath used for testing.

Connections at the back of the Raspberry Pi were done using a simple breakout board on with screw down terminals. The resistor is just above the terminal board and the sensor harness is the black cable coming out of the image towards the camera. This harness will be incorporated into the serial port in the final case design so it can be used if needed.

Once the hardware was wired up it was time to configure the GUI and OS to utilize it. All of the tutorials on the internet including the one above go into detail about the quick steps needed to turn on the one-wire feature of the RPi. Once the feature is turned on, Linux makes a text file in the OS that can be read to get the current values of the sensor. Each sensor has it's own folder based on the ID of the sensor. The GUI is programmed to check this folder and return the sensors that are present as shown below. Sensor ID 28-0516a025e1ff is the temperature sensor. The bus_master controls the one-wire bus and is not an actual sensor. I will remove that from showing up in future builds.

There is more flexibility over controlling the one-wire device updates because the program needs to poll them when commanded. In this case it was necessary to create a whole new thread that just processes the selected GPIO signals. The following chart shows an example of the temperature sensor readings in operation starting with holding in my hand and then placing in a glass with ice, taken at 1 second intervals.

The other part of the system that I worked on this week was to filter the CAN messages that are being gathered on the hardware. Using the filters I can reduce the amount of overhead that is being picked up when the CAN bus is running at very fast speeds. The code snippet below configures an iterable Dictionary file of filters to apply taken from the messages inside the .dbc file. Each frame id will also use the same can_mask. Can_mask is an old method of filtering and even though it filters nothing using the value 0x1FFFFFFF, it is needed for the API that is being used to prevent an error.

The settings window has been updated to allow for selection of CAN hardware type and also the .dbc file to be used. The dbc file list is generated from the dbc folder in the project so as new files are added or removed the list will update automatically.

The datalogger screen has also been updated to incorporate some additional features. The most important feature is some status information to show that something is happening when the logger is running. I expect to add a printout of the CAN frames being logged to the small window at the bottom left corner of the screen, and then also the ability to check that the influx server is running on the RPi. The complete window is not fully operational at this time. Logging to an ASC file locally will be very simple to implement since it is part of the API so I added it in to be able to push the file to a remote server for later diagnosis.