EEVblog Electronics Community Forum
Electronics => Beginners => Topic started by: Chemist_Guy on December 30, 2019, 01:48:53 am
-
For a little project I'm working on I'm trying to hack a cheap scale to interface it with an Arduino. My thought was open it up, probe the pins which go to the LCD and determine the signals which could be fed into the digital pins. It's a chip on board, so no hope finding a part number. I've been able to locate the pins and figure out the encoding scheme, however the signal is a bit weird. Instead of pulsing at 0 V and 5 V, it's going at 0, 1, 2, and 3 V. (It runs off 2 AA batteries, hence the 3 V max). Look at the graph to get a feel for what it being output. It's putting out four bits at 0 and 2 V, then inverting them between 1 and 3 V. There is also a second line putting out another 4 bits and together they give the 7 bits needed for the 7 segment LCD, plus one bit that is always 0.
At this point I was wondering, what is this encoding scheme called and more importantly how would you go about getting this signal to be readable into the Arduino digital input pins. Ideally it would be a single chip, but I'm trying to keep this as non-Rube Goldberg as possible.
Thank you for your help!
-
I suspect you will find another signal that toggles at 1/3 data rate, when that is high invert your data
-
That is typical multiplexed LCD drive - nothing unusual. The datasheet for an LCD controller or MCU with integrated LCD controller will have some info on how it all works.
Another possible approach would be to use a strain gauge amplifier to directly read the strain gauge. The HX711 is a popular low cost chip that you could eXperiment with.
-
Refer to the ATmega328P datasheets for logic input thresholds. It's around 2.7V for a "1".
edit: I believe OP is showing the LCD drive signals? It would be much easier to get a HX711 shield/board and use that.
-
So you need to read an arbitrary analog level, as a digital signal? An analog-to-digital converter, you might say?
The simplest case is a 1-bit ADC, otherwise known as a comparator. (Digital input pins count too -- all real signals are analog, after all -- but they have terrible accuracy so aren't practical to abuse in this way.)
You might use a couple of comparators to determine which state it's in, and read it into the AVR* as say 2-5 parallel bits (depending on how much encoding you want to do, and how much cleverness you bring to bear). Could also be sequential, say if you have a counter advancing the threshold -- assuming the bit times are reliable, so you have plenty of opportunity to check against multiple thresholds.
Or you can use the ADC proper, if you have enough channels and sample rate. The AVR has a 8/10 bit converter, more than adequate here. Conversion takes something like 0.1ms so if the axis in your plot is ms, that's more than enough. Internal mux has 8 channels, or you can add an external (analog switch / mux-demux) to expand to even more.
That should be easy enough in Arduino-land. Some abuse could be done, like overclocking the ADC to squeeze out more samples at far less accuracy, but likely not so easy to do, and probably not necessary.
Note that the signals are repetitive, so you have multiple chances to read the display, even if you're only checking say one logic level per scan, or every other bit, or something. It's unlikely the display data is being updated very quickly (but it would be interesting to find it is).
*Assuming whatever original Arduino board, I guess.
Tim
-
Of you want to drive a naked LCD from an arduino then you will need to find and understand the LCDs data sheet.
A particular issue is that the LCDs must have a waveform with an average voltage of zero volts. That implies accurate timing and accurate voltages on the drive pins, which I doubt an arduino could achieve.
For small manufacturing runs it is much more practical to buy a combined LCD plus driver ic module. The driver provides the accurate voltages and timing. The interface to the arduino is the standard non critical digital values,. You read the module/driver data sheet to see the digital signals and protocol that the arduino programming must use to get the driver to display the information.
-
I have done exactly this - on two different scales.
First thing you have to do is not design circuitry - it is to understand the signals. Here is one very important clue:
A particular issue is that the LCDs must have a waveform with an average voltage of zero volts.
This translates into a symmetry where, whenever you have a 0V signal, you will also have a 3V signal closely associated with it. Likewise a 1V signal will have a 2V signal closely associated with it. Follow the signals and you will find you only need to distinguish between two voltage levels.
The second part of this is to understand the scanning pattern for driving an LCD display - how the multiplexing is done.
If you spend the time examining these, you should be able to draw up a table of signals that will allow you to decode the information displayed. Here is the table from one of my projects...
(https://www.eevblog.com/forum/beginners/interfacing-a-4-voltage-level-digital-signal-and-an-arduino/?action=dlattach;attach=899236;image)
Edit: The top table shows the key voltages measured. The bottom four tables are an expansion of this information, showing the voltages across each segment during each step of the multiplexing scan. From this expanded view, it can be seen:
1. That a potential of 1V is not sufficient to drive the crystals, but 3V is
2. How the average of zero volts is attained
3. How the segments on inactive rows will not be driven while receiving the same signals that will drive segments on the active row (Which I think is brilliantly elegant!)
-
In what turned out to be a fairly reliable approach, I found I only needed to know when a 3V signal was present. A 3V signal will read High on a digital pin, whereas a 0, 1 or 2V signal will read as Low.
My approach did not take any consideration of the multiplexing frequency of the LCD - just that it scanned fast enough to read all signals at least twice for each step in the multiplexing sequence.
This gave me the segments that were "on". It was then a matter of decoding what each combination of segments meant.
Fun times. ;D
-
One extra piece of information....
I connected the LCD signals directly to digital inputs of an Arduino compatible board (in one project it was a Mega in another it was a Nano). This only had one negative effect: When the Arduino was not powered, the LCD signals were loaded down to the point that the LCD display no longer showed anything. However, when powered up, the LCD display worked perfectly.
This condition was not a problem for both of my projects as they both communicated with a PC via USB which supplied the power. I ditched the batteries for the scale in favour of a 3V low drop out regulator - a LP2950CZ did the job.
-
It would be much easier to get a HX711 shield/board and use that.
Not sure about the OP, but I did not want to get into the whole measurement circus, so I went down the "read the display" approach. Of course, this meant you had to work within the constraints of the scale as manufactured.
To give you an idea of what that entails, here is an extract from the operations manual I wrote for my most recent project:
3. Limitations
By following the approach used, there are some limitations that cannot be avoided and some that require a workaround.
a. Sampling rate
Since the capture system reads the display, the sampling rate is immediately limited by the update rate of the display value. This is determined by the scale circuitry and cannot be changed. This occurs at a rate of approximately 2.5 times per second.
The signals necessary to display this value on the LCD operate at a much higher speed. In reading this value, it takes one complete cycle of the LCD display signals to capture the necessary information. This takes approximately 16 milliseconds. During this there can be transient variations in this signal that can translate into incorrect readings, so multiple samples must be taken in order to gain confidence in the value.
b. Resolution
The resolution available is only that which the scale has been designed to provide. The best resolution has been found to be one milligram, with the units set to grams.
c. Linearity and Repeatability
The linearity and repeatability are a function of the scale as manufactured. These figures are not given in the documentation supplied with the scale, but an internet search has identified them as follows: Linearity: ± 2 digits Repeatability: ± 2 digits
d. Temperature stability and Drift
These are properties of any electronic measuring equipment. Since this unit will be used over much longer time scales than intended, these parameters need to be considered. It is important that users refer to the notes and recommendations in the relevant part of the Calibration section. Other environmental factors - e.g. humidity and EMI - might also need addressing.
e. Mathematic processing
Any built in mathematic processing of values - such as averaging - cannot be bypassed.
f. Inactivity timer
As a unit designed for battery operation, there is a timer that will switch the scale off after a period of inactivity. Analysis has shown the intended usage of the modified scale does not reset this timer, so special consideration must be given to avoid this shut down.
The resolution of this issue has introduced a compromise in some circumstances. This is explained in detail in the section: "Keeping the scale alive".
g. User controls
With only four buttons - each of which perform specific functions - there is limited ability for user input, without mechanical modifications. However, a basic interface has been implemented (as outlined in the Overview) with a moderate degree of functionality.
h. Microcontroller timing accuracy
Separate to the scale, the microcontroller has it's own timing reference - a "clock" which provides timing signals for its operation. However, since these timing signals do not need to exactly match a real time clock for the microcontroller to function properly, the interval and period timings derived by the capture system may run slightly faster or slower than a real time clock. Some limited testing has shown the microcontroller running around 1 second fast over 20 minutes, but this can vary between microcontrollers and also with changes in ambient temperature.
i. Overloading and Use of the TARE function
(Here I discuss the behaviour of the specific scale used in this project. You can TARE yourself into problems!)
I also wanted to limit the mechanical modifications on one of the projects, so I designed an interface that used the existing buttons on the scale. It was very useful to have an "ON" button ... Once the scale was on, pressing it again did nothing on the scale, so reading it became the primary control. The "Tare" button was also useful during the setup process. (This project took timed samples for an evaporation study.)
-
Here is a video I did showing it in use. (I'm not a presenter - so be kind.)
https://www.youtube.com/watch?v=0u4rZkep75w (https://www.youtube.com/watch?v=0u4rZkep75w)
-
(It runs off 2 AA batteries, hence the 3 V max)
Certainly two AA batteries will put the voltage into the realm of 3V - but in my last project, I tested operation over a range of supply voltages from 3.3V down to 2.7V.
What I found was that the LCD signals remained unchanged at 1V, 2V and 3V - so there is a little buck/boost regulation going on in there. Mind you, for the current required for an LCD display, that isn't a big ask. I suspect this will be a common approach in LCD drivers.
I was tempted to run the scale directly off the 3.3V available from the Arduino, but I went for the LDO regulator running off the 5V USB supply. Without a datasheet on the scale's chip on board, I felt it safer to go that extra step - especially as the units were headed to the other side of the world.