An introduction to electronic weighing
Filtering Data
Before displaying the data, some sort of filtering is usually required that removes fluctuations in the weight display caused by noise and vibration, but filtering comes at the cost of response time. The raw samples from the ADC take 100ms to acquire, so any form of low-pass filtering will slow down the response time into the region by fractions of a second. In the case of a workshop balance, a couple of seconds for the reading to settle is not a problem, but in other cases (e.g., a batch-weighing application), every second adds to production time and therefore costs money. Filtering and ultimate accuracy will always be a trade-off. In this application, 10 samples are simply averaged before the result is passed for display (Listing 3).
Listing 3
Averaging ADC Readings
01 #define SAMPLES 10 02 03 int32_t samples[SAMPLES]; 04 int32_t average = 0; 05 uint8_t sample = 0; 06 07 // main acquisition loop 08 while (true) 09 { 10 samples[sample++] = ADS1232_Read(); 11 if (sample == SAMPLES) 12 { 13 sample = 0; 14 } 15 16 average = 0; 17 for (uint8_t i = 0; i < SAMPLES; i++) 18 { 19 average += samples[i]; 20 } 21 22 average /= SAMPLES; 23 24 // pass the averaged data to the display here 25 }
Practical Precision
In terms of practical precision, you must keep a few things in mind. Of the theoretical 24 bits of precision available from the ADC, the datasheet itself admits that only 19 bits are useful at the highest gain setting. The load cell I have chosen has a maximum output of 4mV (1mV/V, with an excitation of 4V), so it uses only one fifth of the available range (20mV) of the ADC. That's about 100,000 counts. Practically, I have found I can achieve stable readings to 10,000 counts. For a 100g scale, that means one count is equivalent to 10mg. The current software limits that further, giving a resolution of 100mg (i.e., 1,000 counts), which seems more than adequate for the requirements of a general-purpose laboratory scale. There is certainly scope for better filtering and other techniques to improve the precision, but at some point the limitations of the (cheap) load cell will become the limiting factor.
Display Driver
The display has a three-wire serial interface. The chip select (CS) line must be asserted before data can be written, and once that is done, data is presented on the data (DAT) line, being clocked into the chip by asserting the write (WR) line and then negating it (Listing 4). The interface is too slow to keep up with the microcontroller at full speed, so busy-wait loops are necessary to slow the WR line pulses down to just over 3µs.
Listing 4
Writing a Single Bit to the Display
01 /** */ 02 static void LCD_WriteBit(bool bit) 03 { 04 // set the data line 05 HAL_GPIO_WritePin(LCD_DAT_GPIO_Port, LCD_DAT_Pin, bit); 06 07 // assert the WR line 08 HAL_GPIO_WritePin(LCD_NWR_GPIO_Port, LCD_NWR_Pin, 0); 09 10 // busy wait 11 for (uint8_t i = 0; i < 50; i++) 12 ; 13 14 // negate the WR line 15 HAL_GPIO_WritePin(LCD_NWR_GPIO_Port, LCD_NWR_Pin, 1); 16 17 // busy wait 18 for (uint8_t i = 0; i < 50; i++) 19 ; 20 }
The display chip has a small amount of internal memory, and the individual bits in this memory correspond to the different segments in the display characters, as well as decimal points and the battery state indicator. Each transaction with the chip is called a command, and the first three bits of that command determine the type of command. The rest of the transaction comprises an address in the internal memory and the data to be written.
The process of writing a complete digit involves conversion from the required ASCII digit to the memory bit pattern to illuminate the display correctly. This code is not complex, but quite long, so I won't include it here. I refer the interested reader to the source code on my GitHub page [11].
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
![Learn More](https://www.linux-magazine.com/var/linux_magazin/storage/images/media/linux-magazine-eng-us/images/misc/learn-more/834592-1-eng-US/Learn-More_medium.png)
News
-
NVIDIA Released Driver for Upcoming NVIDIA 560 GPU for Linux
Not only has NVIDIA released the driver for its upcoming CPU series, it's the first release that defaults to using open-source GPU kernel modules.
-
OpenMandriva Lx 24.07 Released
If you’re into rolling release Linux distributions, OpenMandriva ROME has a new snapshot with a new kernel.
-
Kernel 6.10 Available for General Usage
Linus Torvalds has released the 6.10 kernel and it includes significant performance increases for Intel Core hybrid systems and more.
-
TUXEDO Computers Releases InfinityBook Pro 14 Gen9 Laptop
Sporting either AMD or Intel CPUs, the TUXEDO InfinityBook Pro 14 is an extremely compact, lightweight, sturdy powerhouse.
-
Google Extends Support for Linux Kernels Used for Android
Because the LTS Linux kernel releases are so important to Android, Google has decided to extend the support period beyond that offered by the kernel development team.
-
Linux Mint 22 Stable Delayed
If you're anxious about getting your hands on the stable release of Linux Mint 22, it looks as if you're going to have to wait a bit longer.
-
Nitrux 3.5.1 Available for Install
The latest version of the immutable, systemd-free distribution includes an updated kernel and NVIDIA driver.
-
Debian 12.6 Released with Plenty of Bug Fixes and Updates
The sixth update to Debian "Bookworm" is all about security mitigations and making adjustments for some "serious problems."
-
Canonical Offers 12-Year LTS for Open Source Docker Images
Canonical is expanding its LTS offering to reach beyond the DEB packages with a new distro-less Docker image.
-
Plasma Desktop 6.1 Released with Several Enhancements
If you're a fan of Plasma Desktop, you should be excited about this new point release.