Direct Reading of LCD Using General Purpose IO

Intro: Direct Reading of LCD Using General Purpose IO

Difficulty:easy..Schematics, Soldering, C Programming

Lots of devices have LCD (Liquid Crystal Display) screens - your microwave, digital clock, and bathroom scale are a few common examples. More than once, I have want to be able to read the information from the screen and use it in some way. I have come across a few guides on directly reading an LCD screen, but most seemed to be copied from some other source, lacking any real information of how it actually worked.

In this Instructable, I will teach you how to read LCD screen data by monitoring the individual control pins using an 8 bit AVR microcontroller. This information can also be used to directly drive an LCD screen if that is your end goal, although I will not be covering that topic in detail.

Looking for something to do with this technology? Check out my Instructable on creating an IoT coffee pot level monitor!

STEP 1: Parts and Tools

Parts and Tools

• Something with an LCD screen - I will be using this digital scale from Amazon
• Screw Drivers & Pliers - To open up the scale
• Wire Cutters & Strippers - To cut and strip wire
• Soldering Iron - To attach wires to the screen
• Hookup Wire - Very small gauge is fine for this low current application
• Multimeter - To measure voltage / resistance
• Hot Glue Gun - Useful for coating connections and holding things down

Circuitry Components

• ATmega328p - Used to read the state of the LCD screen
• 2 x 0.1uF Ceramic Capacitor - Decoupling Caps
• 1 x 10k ohm Resistor - Pullup for AVR Reset pin
• 1 x 22k ohm Resistor - ADC biasing
• 1 x 100k ohm Resistor - ADC biasing
• 1 x Normally Open Push Button - AVR Reset Button
• 1 x Voltage Regulator - I'm using an LD1086 3.3V LDO regulator
• 1 x 10uF Aluminum Capacitor - Regulator Stability
• 1 x 1uF Aluminum Capacitor - Regulator Stability
• Male Header Pins - To connect wires to breadboard
• Breadboard - for Prototyping
• Perfboard - If you are soldering an actual circuit

Additional Items

• AVR Programmer - I use the pocket programmer from Sparkfun
• Serial Enabled LCD Screen - To reprint what we are reading (from Sparkfun)
• Logic Analyzer - To see what the LCD pins are doing... I use this small one from Link Instruments

STEP 2: Open It Up

Does anyone ever open anything down?

1. Make sure your device is unplugged / remove any batteries!
2. Look for screws that hold the device together (likely on the back / bottom)
3. Remove any casing to reveal the inner circuitry
4. Charged capacitors can be dangerous, so be sure not to touch anything on the circuit board!

In the image, you can see the insides of the digital scale. There is a circuit with mystery black goo covering the controller, a few load cells, zero (touch sensor) and unit buttons, and the LCD screen. Not so long ago, this circuit would be populated with numerous components that could produce relevant data. Now, it is a single, inaccessible MCU with an external EEPROM chip. It's like the designers don't want us to do this sort of thing... Even with no accessible data points, we can get the information we want by directly reading the LCD screen.

STEP 3: LCD Connections

LCD screens are typically connected to a circuit in one a few possible ways...

• Socket Connection - Header pins going into a socket on the board
• Ribbon Cable - This sometimes plugs into a socket, but not always
• Direct Connection - The pins on the LCD screen board are held against the pads of the driver board by force

In the kitchen scale, the LCD screen sits in the frame, and the circuit board is held against it with a few screws. In this way, the driving pads on the circuit board are making contact with the LCD pins.

There is no soldered or cable connection. If the circuit is not tightly secured to the case, the connection to the LCD is lost - as evidenced by missing segments or a very dim screen. This can make it difficult to attach any additional wires to the LCD. If even a single LCD pins isn't making good contact with the board, part or all of the LCD will not work correctly.

The following image isn't of this exact circuit board, but it does demonstrate the LCD pads on the board...

STEP 4: Adding Wires to the LCD

This is where things get a little tricky. As mentioned in the previous step, the LCD pins still need to be making good contact with the driver board pads. You will have to use your best judgement to determine where you can solder wires to the board. I also recommend using incredibly thing wire; mine is 30 gauge.

1. Locate the pads that connect to the LCD
2. Solder wire leads to each pad (use thin wire, and small amounts of solder)
3. Solder the other end of the wires to a header pin (keep them in order!)
4. Reattach the board to the LCD.
5. Apply power to ensure the LCD is still working.
6. Optional - Coat the wire-header connection with hot glue for durability and insulation

At this point, we have no idea what wire does what, but that's OK. As long as you kept them in order (pin 1 on the lcd goes to pin 1 of the male headers, etc), it will be easy enough to figure out! At this point, we should probably talk a bit about how these LCD screens work.

STEP 5: Direct Driving of LCD

Most people aren't as interested in reading the LCD screen as they are in driving it, so the best way to learn how to read the screen is to learn how it is driven. One of the best explanations I have found is available in this Atmel Application Note - AVR340, but I will quickly go over the key points.

An LCD screen is a collection of segments that react to AC signals present on the control pins. The segments might make up an alphanumeric digit similar to a seven segment display, or they could be for a single icon on the screen such as the AM/PM text on a clock. One screen can have many segments driven by only a few pins - this is done through multiplexing.

A single pin is actually used to drive multiple segments, depending upon which of a set of COM signals is active at any given time. As mentioned above, the LCD is driven using AC signals, typically in the form of binary square waves (OFF or ON). However, the COM signals will have three states: OFF, 1/2 ON, and ON, where ON is full the source voltage. The linked application note gives the following example of this control scheme.

Notice, only one COM signal is active at any given time, and the LCD segment line will control different segments, depending upon which of the three COM lines is active. To enable a segment, the segment line needs to be out of phase with the COM line. In other words, if the COM line is HI, the segment line should be LO, and vice-versa.

The next step for us is to determine which of those LCD pins are COM lines, and which drive a segment!

STEP 6: Finding the COM Lines

In this step, we are using a logic analyzer to find the COM signals. In reality, an oscilloscope can be used and will actually make finding the COM lines easier; however, O-scopes typically have much fewer inputs than an LA. Even though we are looking for an AC signal, we can still read it on the LA by setting the triggering threshold level.

The digital kitchen scale operates at around 3.3V DC, so I have set the trigger for my LA inputs at 2.5V DC. This will make sure I only see the positive portion of the pulse, ignoring all of the other undefined regions.

1. Set the input trigger threshold to about 3/4 of the source voltage level
2. Set the horizontal time scale in the range of 5ms / division
3. Connect a wire to a known ground on the circuit (or the negative battery terminal)
4. Apply power to the scale, ensure the screen is working
5. Individually monitor a single Pin to see what the pulse looks like
6. Repeat for all pins until the COM line(s) are found

In my experience, the COM lines are typically found at the end of the LCD screen; hence, they should be the first few of the connection wires we soldered to the board. They are easily distinguished from the rest of the signals...

1. If using an O-Scope, they are likely the only signals that have three states instead of two
2. They repeat at regular intervals (likely a 10 - 50 ms period)
3. The state of the LCD screen does not effect the pulse pattern

The digital kitchen scale happens to have four COM lines which have a 32ms period. Each pulse is fully OFF or fully ON for about 4ms. These four lines have a permanently repeating pattern which never deviates, regardless of what is being displayed on the screen at any given time.

STEP 7: Decoding the Control Signals

This step is by far the hardest, as it will require you to solve a puzzle of sorts in order to decipher what the control signals mean. The more complicated your LCD screen is, the more difficult this process will become.

The digital scale LCD has 16 control lines - 4 are the COM signals and the other 12 drive segments. We need to monitor every single pin for various LCD states until we can discover which LCD pin is responsible for which segment(s). Since there are four COM lines, each control line likely drives four different segments.

Determine all possible segments for your LCD screen.

This is every known segment of the kitchen scale LCD screen. Actually, only the b and c segments of digit 4 are ever active, but all other segments shown are valid.

Record the Pin States for a known LCD screen

Using the logic analyzer (or O-Scope) we need to record the state of every single pin for all of the COM states. As long as the screen doesn't change, these patterns will repeat indefinitely; however, if a single segment changes, that particular control signal will change for one of the COM lines.I have highlighted the states of a few different pins for COM signals 1 and 3. Notice, a segment is ON when a pin is out of phase with the COM lines - when the COM is HI, the Pin is LO and vice-versa.

Create a matrix displaying all pin states for known LCD screens.

The hard part is finding the pattern - that is, which control lines are changing as a single segment of the LCD becomes active or inactive. It's a good idea to write all of these pin states down for various screens with subtle changes in which segments are active.

In this table, I put a 1 for any control line that is active (out of phase) with any of the COM signals, as seen in the previous pin state image. It is very important to take note of every active icon on the screen - some of them might be connected in seeming random ways.

The best way to find the patterns is to record the pin states after subtle changes. For example, the exact same time displayed with AM and then PM, or a digit displaying 0 and then 8. Remember, there are no chips or wire traces in the LCD, so the order of the control lines will likely correspond to the order of the segments on the actual screen.

Notice that the state of pins 11 and 12 seems very similar to 13 and 14. Given that the screen displays 0.0, could this mean that pins 11 and 12 drive digit 1, while pins 13 and 14 drive digit 0? This makes sense, given that there are six active segments used to form a 0, and the seventh active segment in pins 11 and 12 could be the decimal place! Additional readings with a similar display will help. For example, switching the mode from fl-oz to grams will change the display from 0.0 fl-oz to 0g. Suddenly, pins 11 and 12 all turn off, but pins 13 and 14 remain unchanged. I think we have found a pattern!

Fill in the map connecting control lines to LCD segments.

After enough readings have been taken, the complete pattern will be discovered. Since we are not directly driving the screen, the only way to test theoretical connections is to write down what you think the pins should be for a given display, and then make that display happen - in our case, this is done by switching to a certain mode and adding weight to the scale until a particular combination of digits is displayed.

In the case of the kitchen scale, the pins were arranged in a manner that actually made sense! The alphanumeric digits were grouped together, in the same order of their display. The only lines that were in a random order were the various unit icons, but that was to be expected. This table shows what control lines drive what segments for a given active COM signal.

STEP 8: LCD Reader Circuit Design

With a pattern (hopefully) found, we can create a circuit to read the LCD pins and do something useful with that data.

This circuit will be built around at ATmega328p microcontroller using all of the default fuse settings and no external clock source. Since the COM lines are analog inputs, we could read each one individually using the ADC, but this is unnecessary. The same effect can be achieved by reading just one COM line using the analog comparator, and then simulating the other three COM lines in software. You might also note that I do not have connections shown for pins 5 and 6. The reason is simple - I don't care about any of the data represented by those pins.

The analog comparator is really simple. We use R5 and R6 to create a bias voltage on AIN1. The output of this voltage divider is about 2.7V - similar to the 2.5V trigger threshold I used for the logic analyzer inputs! The COM1 line is fed into AIN0. Whenever the voltage on AIN0 rises higher than AIN1 or falls below it, the comparator will trigger. We will use this as an interrupt source to trigger the start of an LCD read cycle. This will also be used to keep our simulated COM lines in sync.

The last thing I want to point out are the connections to JP2 - I actually plan on taking full control of the digital scale. My circuit will be able to disable power to the scale and drive the mode buttons. I have opted to leave all of PORTC open. This frees the I2C pins for communication with other chips as well as a handful of analog inputs which might be utilized later. Your implementation will likely vary!

STEP 9: Firmware - Overview

The complete source code can be found in this GitHub Repository.

To start, our firmware will read the LCD screen and then print that information to another LCD screen for comparison. The only problem with this is that the LCD screen we want to use is serial driven, and our serial port transmit pin is being used to read one of the LCD pins. This isn't a big deal, it just means data from that pin will be inaccessible.

The code to do this is the main-v1.0.c file in the repo. This code is written in C. It does not use any Arudino libraries because that's not how I role. These are the basic building blocks of our firmware...

On Boot, Configure AVR Device

• Set IO Pins
• Turn Off Unused Modules (to conserve power)
• Use Timer 0 to simulate COM lines 2, 3, & 4
• Use Analog Comparator to Detect Com line 1
• Use USART0 to write to a local LCD screen

In Main Forever Loop

• Read LCD Screen
• Print Scale LCD screen data to Local LCD Screen

Interrupt Service Routines

• Timer 0 - Sync with COM 1, used to simulate the other COM lines actions every 4ms
• Analog Comparator - Triggered when COM 1 goes HI, turns on Timer 0

Other Functions We Will Need

• Read LCD - Initiate a reading of the LCD screen... probably enable the Analog Comparator and wait
• LCD Printing - Transmit a byte, string, etc to the local LCD screen

STEP 10: Firmware - Main-v1.0

As mentioned, the first version of the code will read the scale LCD screen and then write that data to a local LCD screen. This is merely a proof of concept... rewriting the data from one screen to another is fairly pointless! I believe I have commented the source code well enough for you to understand what is happening if you are at all familiar with AVR code, but I will go over a few of the finer points.

A few files are included:

• modules/avr.h - I include this in every AVR project I work on
• modules/lcd/SerLCD_2x16.h - Function Prototypes and Macros for writing to the local LCD screen
• definitions.h - All of our main macros and definitions
• util/delay.h - simple delay routines

The hardware modules are configured in the initialize_AVR() function found on line 486.

Analog Comparator

The analog comparator is triggered on the rising edge of COM 1. It then enables Timer 0 which simulates the COM 1 falling edge and the other 3 COM lines.

Timer 0
Timer 0 is setup to trigger an ISR every 0.2ms. A counter within the ISR will cause events to take place after so long (namely, ever 4ms), and a switch statement is used to perform different actions for each active simulated COM line. The state of the LCD pins is recorded for each COM line, and at the end of the cycle, the Timer 0 is disabled.

LCD Reading

The read cycle is started by the readLCD() function on line 311. This function simple enables the analog comparator and sits in a while loop until the read cycle has completed. The decodeDigit() function found on line 321 actually turns all of the pin state data into numerical numbers for each of the LCD digits.

LCD Writing

The LCD Writing Routines found starting at line 407 were written by me a while ago. They can also be found in the modules/lcd folder, but I copied just the functions I wanted to use to the main file so I wasn't compiling files from multiple locations. I think they are pretty self explanatory.

Main

In the Main function, the AVR device is initialized, and then enters a forever loop. Inside this loop, the LCD screen is read, and that data is decoded and printed to the local LCD screen for testing. Digit 4 is skipped, and I do not worry about the clock mode of the scale because I am not monitoring the AM/PM LCD pin segments.

In a previous version of the circuit, I was monitoring all of the LCD pins, hence my ability to print the clock mode data; however, the presented firmware cannot do this. Also notice the "&" symbol in the digits due to the Serial Transmit line used to print to this LCD screen stopping me from reading one particular Scale LCD pin.

STEP 11: Firmware - Main-v2.0

The second version of the firmware is almost identical to the first; however, I have removed all of the LCD printing functionality. There are no more LCD_write() functions, nor is USART0 in use. The other major difference is the addition of the updateLevel() function. This simple routine packs the weight displayed by the scale into two bytes of data. These bytes will be transmitted over the TWI bus to another chip, but that is part of another project, so I haven't included that code here. You should also notice that at the start of the main, the code forces the scale into weight mode in grams. This is done so that the data being transmitted from this scale to the internet is always consistent.

The main loop now reads the lcd screen and creates the two level data bytes before delaying for 1 second., nothing more, nothing less. All of the hard work is handled by the interrupt service routines for the analog comparator and timer 0.

STEP 12: Wrapping Up

I hope that by using this guide, you will be able to hack into any of your digital devices in order to read data from the LCD screen. As always, if you have any questions of comments, be sure to post them!

Like I said before, this project is actually part of a larger effort - building an IoT coffee pot level monitor. I have created a separate Instructable teaching you how to make it!

Comments

[mokkaa]

Thank you so much for putting the effort in and writing up this comprehensive instuction!

I'm currently in the process of reverse engineering the LCD of a precision body temperature thermometer. I'm facing the issue that, given the resolution of .01 ºC and display range of 36-40 ºC, it is quasi impossible to induce stable single segment changes on the display.

Does anyone have any suggestions of alternate methods for figuring out how the LCD is driven?

[pat.walsh]

Hi, I like the idea here as ADC's in some cheap scales are really quiet good. I'm trying to read one currently. When following your guidance with an oscilloscope I can find a number of signal lines which have an unchanging signal pattern (likely Com lines), some of which change when the digits on the display change (likely segment lines). However on these lines there appears to be 4 potential voltage levels (0, 1.1, 2.2 and 3.3V). This differs from the com lines you've noted. Any advice on how these might be read. The scales I'm looking at is a tiny low cost 50g full scale deflection called Digital Mini Scale TL-series. Also, there isn't any DC 3.3V or GND lines going to the Scale, rather there is a 50% duty cycle PWM square wave between 0 and 3.3V on one line. Any advice or pointers on where to read up about this type of signal profile would be appriciated. Thanks.

[Kurt E. Clothier]

Hi Pat, The COM lines should have a repeating pattern at a consistent frequency regardless of what is displayed on the screen. It's possible that additional voltage states are being used to reduce the number of COM and control lines which would also really complicated figuring out what they all do. Can you get a good o-scope image of these lines like I have shown in the image under step 5? If those extra V states mean something, you'd have to use an ADC to really sync with the COM lines rather than an analog comparator like I did here, and you might have to read all of them rather just using one to resync each cycles and timing the others internally. I haven't come across such a scheme, but I also haven't done anything like this in quite a while so I'm probably behind on the times. There isn't typically power or ground lines going to the screen because the current path to each LCD segment is made between the COM and control lines. The PWM signal you mentioned sounds like a backlight brightness control, but without knowing more about the screen I couldn't say for sure.

[Kurt E. Clothier]

Hello, Sandratra. Thank you for your interest in this project; however, I will not be able to create any such Arduino libraries for you because I refuse to use Arduino with any of my work. That said, Arduino code is written in C++, of which, all of my C code is still valid.

By the sound of your request, it also sounds like you want a single library that will "just work" to read an LCD (as is the Arduino way), but i can assure you that this is an impossible task since there are a plethora of different types of LCDs you might want to read, and numerous Arduino boards, each with different hardware capabilities.

I'm afraid this project requires some hardware/software skills that, in my experience, typical Arduino experimentation does not cultivate.

[SandratraA]

Hi kurt!! Thanks for you're reply!! Can you give me some example for paragraph 4 and 5 of AVR note please!! I really need this project but I'm so confuse in this paragraph!! Please thanks a lot

[TonyKnife]

Hi Kurt,

I too love this instructable - and have been popping back to it regularly this year for reference!

I've had some success with an alternative to the microcontroller route, and I thought I'd share it with you and your readers. I'm still perfecting it and will write the final version up as an addendum instructable referencing yours for all the hard work :)

My project is to upcycle an old Nintendo Game and Watch, with a broken screen, into a new LED version - there are two COM lines, but with 37 data lines the number of analog inputs needed on a microcontroller was an issue and the "decoding" wasn't something I was looking forward to.

The setup and process is exactly the same up to Step 8, then I started looking into options for logic IC's to do the processing.There are two chips I use, one for the COM lines is a 74HC541 (Octal buffer / line driver), which takes the COM inputs (grounded through a 104 ceramic capacitor, to introduce a slight delay) and converts it to a 3v TTL signal - this is delayed about 1/4 of the active duty cycle - the explain for this will follow), the output from this gives a crisp, slightly delayed 3v on, 0v off signal

The COM output is then fed into a set of 74HC534E chips as the control signal. These are Octal (8 inputs) D-Type (data typed) tri state flip-flops, inverting and triggered on the positive edge of the control signal. Each data line goes into an input and the output can drive an LED directly (electrical engineers please pipe up with what I'm meant to do with resistors and fanout here, because I'm still learning and know I don't have these right yet)

So the flow is, when the (slightly delayed) control signal goes from 0 to 3v, the state of the data signal is taken and inverted (remember, the LCD is visible when COM and Data oppose each other)

I've attached an image showing my breadboard set up with 32 data points shown, and converted to LED, I've also put together a little video demonstrating this. The nice thing now is with all 32 points shown at once, and side by side with a working Parachute game - I can hopefully identify the LCD to LED positions by seeing them instantly change when I do repeatable actions in parallel (like clock setting etc)

[SandratraA]

Hi kurt!! Thanks for you're reply!! Can you give me some example for paragraph 4 and 5 of AVR note in you're link please!! I really need this project but I'm so confuse in this paragraph!! Please thanks a lot

[Kurt E. Clothier]

A very interesting concept indeed. Without a logic analyzer to see the signals, using delayed LEDs to see what segments are what is about the next best thing, but I imagine the decoding process is going to be the same at that point. One point - I'm only using an analog input as a comparator for a single COM line for timing and synchronizing. All of the other data lines are digital inputs. Yes, the LCD lines are analog, but the swing is plenty big enough to trigger the digital inputs of the MCU.

Are you positive about that ratio of COM to data lines? 2 to 37 seems insane. I can't imagine why they didn't use more COM lines to reduce the number of data lines, unless they couldn't get the screen to refresh fast enough. Still, that's 39 lines to produce 74 total segments. In my scale, there are 4 COM and 12 data, so 16 lines produce 48 segments. 2 more COM lines would allow my scale to control 72 segments with only 18 total wires; however, it would reduce the screen refresh rate by 50%, unless they also increased the COM frequency (hopefully that make sense... the more segments you multiplex, the longer it takes to get through all of them).

Do note, using the LEDs to visually see the segments might not work because the frequency of the screen. Those COM lines are changing numerous times per second, so control of the data lines is also switching back and forth. Thus, in real time, those data lines are like schrodinger's cat - off and on at the same time.

[Rocket_1233]

Hi! Nice explanation.But i assume this method of reverse engineering is applicable only to LCD of which the datasheet and firmware is not available. Can you just let me know how the interface would be if i want to read data from an external LCD into my Raspberry Pi board and then use the captured data.

Thanks

[Kurt E. Clothier]

Hello. If you did happen to have the datasheet for the LCD, it should tell you what the COM lines are as well as which control lines map to which segments. That should make it all a lot easier, but actually reading the the segments would be identical to what I did here. There is no firmware to be available for the screen unless you mean that of whatever is driving the screen, which could be used to decipher the segments, but parsing that would likely be just as daunting as my described method.

Raspberry Pi is running an operating system (usually a derivative of Linux) and is thus very abstracted from the hardware. Because of this, you will have some difficulty getting the pin timing to work. A program on the Pi (even written in the ultra slow python) might not have a problem collecting data at the slower speeds of the screen (~ 8 ms per COM line in my case), but it will be difficult to sample the data at precise regular intervals. Without a hardware interrupt from the COM lines, you will have no way to know when to sample the lines. Using sleep or delay calls will be wildly unreliable. This is easily done on a regular microcontroller with interrupts.

In my opinion, you would really need an external circuit like mine to read the LCD data, which can then package that data however you like and transmit it to the PI using UART or I2C upon request from the Pi.

[Rocket_1233]

Thanks for the reply Kurt. The explanation has cleared most of my doubts. It has also enlightened me that interfacing with a Pi board would be difficult as i cannot sample the LCD data using interrupts, the same which would be done easily using a micro.

The intention here is to mock the LCD screen of a control panel and carry out the panel functionality without actually intervening manually.

Any more comments please let me know. Thanks again.

[Awest711]

Love this intructable! Took me awhile to understand as I am no EE, but I've got it now. As far as not using any hardware. I would think you could just use ATmega328P and guess and check, but this would be very near impossible without a lot of time. Also you could look at Girino the "fast" arduino oscilloscope. One question...

I am seeing a 60hz signal in my pins (using an AC power supply). I know I can filter it out, but I was wondering how does the screen still work with that kind of noise? All I can figure is the liquid crystals themselves are impervious to a 60hz signal...

[Kurt E. Clothier]

Yes, with a Logic Analyzer or O-Scope, it would take a LOT of guess and check! What all are you powering from 60Hz, the device with the LCD screen, the circuit / scope to read the data/pins, or both? My LCD COM lines had a 32ms period (31.25 Hz). The scale had an internal DC voltage regulator for the screen and circuitry, but was powered from an AC wall plug. 60Hz noise would definitely interfere with those signals. Are you sure you aren't introducing that noise by monitoring the pins? What are you using to monitor the pins? Do the LCD and your scope share a common ground line (they should)?

[kumar3214]

Hi,

Is there any alternative method by which we can determine,what pins wat it does?

[Kurt E. Clothier]

I'm sure there possibly are, but I found this method to be quite effective. I doubt you will be able to do this without some sort of instrumentation (O-scope, logic analyzer, etc) in order to visually see what is happening on the pins - they are changing at much too high of a speed to be read in other ways.

If you knew what the COM lines were, you could potentially just directly drive the LCD with random patterns until you figured out what was what, but that still requires you to figure out which pins are the COM lines in addition to how many COM lines there actually are.

[skmbi]

Super good Idea! Thank you to share the way how to do it.

I want my scale from Beurer (BG64https://www.beurer.com/web/en/products/weight/glas_diagnostic_scales/BG-64) to send weight to the thingspeak.com. Beurer is radio. How to analyse and use the radio info? Or I will need to use your way of reading LCD screen.

[Kurt E. Clothier]

Hi, and thank you!

I believe that particular scale is wireless transmitting data to the monitor (but I don't speak German, so the user manual is of little use to me!) So, if you can intercept those transactions, you can get the data to send from those radio signals. It also seems to have some sort of accompanying software, although I'm not sure if it has to be plugged into USB to use that or not... again, reading the guide would help, but I don't speak German!

If you can decipher what wireless protocol is being used (likely bluetooth or zigbee, but other RF signals are common) then you can build an RF receiver to get that data from the air. Figuring out the communication protocol is a whole different matter, and I'm afraid I can't guide you through that process.