3digit multiplexed LCD (custom) driver

[_q12x_]

Hello !
I am building for some time a cct to drive a 3digit multiplexed LCD. (from aliexpress)

From the sellers on aliexpress I managed to find a circuit diagram of the LCD. I color it myself to understand exactly how to actually drive it.
After making the cct in reality, I discovered that those COM1-4 pins in the diagram are actually inverted on my LCD device. That alone eat me a couple of days and numerous hours of error debugging. I trusted the diagram too much.

My Driver Circuit.
I initially started with a PIC 12F508 and I was 'sure' it will work. It didnt. Then I back down to Arduino and here is the circuit with it, 'mimicking' the PIC pins and role. So using Arduino I am paralleling the PIC. You got me so far?
(click to see a large file img) View attachment LCD_3digitF-arduino.jpg
I understand this is probably a hard subject for some, all I ask is your thoughts. What it may be the solution to the problem? To somehow find the real problem and make it work. If you worked already with such stuff, then lucky me. If not, then we will make assumptions, until we will find some good results. That's the idea of my question on your forum here.
As you can see, I am using logic ICs to drive only 1 single digit (from 3). I am driving each segment of 1 digit. Specifically digit 3, the blue marked one.
I have a video with a lot of detailed experimentation and testings and error showing. I will give you the link (from youtube) if you want to help me and if you are into this subject. Send me a private request and I will send you the link. I can not post it here officially because I am swearing a lot in the movie and ... I don't want to upset some too sensitive souls around here. I know there are great and really helpful guys here. If the video is too much for some, discussion will be fine for me as well. No problem. I will answer every question !
So...the real problem is like this:
- I get a lot of 'glitching' when the segments are moving to form a number. Does not matter the speed, the 'glitches' are always there. Both with PIC code or arduino code.
A 'glitch' (for example) is when Im powering segment B but segment F is activated as well, for some strange reason. Thus, making the number a blob of segments instead of a clean number as intended.
The first thought I had was "the code" must be the problem. So I commented out -everything-, leaving the minimum minimorum code, and is still glitching, with no difference from before. I start to believe it is not the code anymore. It is a pure hardware matter !
An english friend told me he thinks that clock (marked with red square) must be synchronized from code. I thought that as well. Im actually starting

my movie with this setup as well. But then I understood better the problem.
So my response to him and how I see the situation, is like this:
This XOR_CLK is there only as a segment driver and not the logic driver. Its only purpose is to clock how fast 1 segment is rendered. If it will clock too slow, the segment will flicker, if too fast, the segment will show correctly, with no flicker at all.
Switching between segments, is another -very different- story. So this XOR_CLK is absolutely independent of the logic clock from the code !!! The code role is to open and close those doors called 'buffer' or 'transistors' or even 'relays'. It has NOTHING to do with the ---segment--- display frequency ! Get my point now? This is how I see it.
Lets say I will clock it directly from code. I will set it to very slow speed, so the logic switching 'doors' will run 1by1 very slowly, and ALSO the segment rendering, also very slow ! You see how separate they are, now?
I think I expose a long and somewhat complicated question.
Tell me your experience and what you may think on this issue. I will provide any links or files are needed, on request.
I give you both PIC12F508 PIC link code (made in CCS C program) and Arduino link code. Take a look.
Thank you !

 

[_q12x_]

I might find a solution.
I will update you soon if is good or not.

 

[_q12x_]

And, it didnt work....
The idea I had was to use another type of shift register, one that is latching the output. I searched and find 74LS595 and I made a quick test in Proteus with it. It appears it is doing what I needed to. But not having this particular component right now, I made an improvisation already.

You see those red marked zones? I made a 'Storage' zone. In sim I used buffers, but in reality I used transistors. When the code is finishing sending 1segment, it is activating that area. And it is indeed working fine, both in sim and in reality.
In reality it is still not working. If Im powering with 3V everything, the LCD display shows nothing. If im powering with 5V some buffers, or the XOR IC, I got again those double segments as before instead of 1. The code runs fine, both in slow and fast speed. So... still not there yet.
See if you can think of anything to improve from the hardware perspective.
Thanks.

 

[_q12x_]

I believe I solved the glitching problem ! I also buy 10pcs of 74LS595 I present in the movie.
I start to believe.... the low voltage is a problem for high fv's ! So the fastest I run this thing, it clearly needs more voltage to --barely-- lit up the segment !!! so, I believe it will need somewhere about 7V or even 9V. Not for the entire cct, just for LCD display itself. At 1ms display speed probably will start to show up at 7V, and at faster than 1ms probably at 9V... I will have to test it out.
These are the hints from all my testing so far.

 

[_q12x_]

I took a 2days break and I decided I will NOT continue this project as it is now. With the logic ICs. It demands higher voltage and I dont want to risk the IC's that are involved. The LCD I dont care that much but the ICs I have them in limited number. I also dont know how to add that higher voltage to the cct because it must come from the clock itself passing through some buffers. And that might potentially damage the buffers.
Also, another important reason is the fact that these LCDs are working already at 5V or even 3V ! So if there are already other solutions for less voltage driving, I will wait until I will find those solutions and understand them better. This is a first trial I did here anyway. Some ideas I got them wrong, and no one can see it.
The 3d reason; the HT1621B driving chips will come soon enough. They should be the answer to drive these multiplexed troublesome LCDs.
----
I plan, while waiting for the chips, to drive the 'easiest' 4digit LCD. This should be no problem, right? I wonder how it will behave at fast speed. This is the current problem I have right now with the 3digits, speeding up the segment location to create a number, is diminishing the segment contrast to 0%, not even gray. The higher the speed, the lower the contrast.Thats how I deduced it needs higher voltage. So I kind of expect this to happen from the new 4digit LCD. The history to repeat. If not, and everything will work fine, then that will be awesome. But I dont raise my expectations for now. Im kind of beat up at this point.

 

[_q12x_]

I didnt managed to make the multiplexed LCD work, but this Static LCD was a breeze.

 

[_q12x_]

SO, I have NO idea how these multiplexed LCD work.

Some days ago:....I have an idea.... I believe, all the segments must get a CLK signal, in the same time. All 7 segments of a single digit, or all 21 segments for all 3digits. Right? On every connection line. Now, if I want to activate a segment, I will switch the normal CLK signal into a NOT_CLK signal. While everything else is normally CLK-ed.
----
Said and done.
Today, I made this cct here (both in Sim and in Reality and both worked...but not really)

and what this does,
while C1 is 0, down buffer is activated, permitting the oscilator to feed on the C1 line of the LCD.
When C1 is 1, up buffer is activated, opening the inverted signal through the XOR get on the C1 line of the LCD.
So instead of floating C1(and C2) line of the LCD when are not used, I am oscilating them all the time. Just to keep them active and not floating. Thats the idea. And it worked in reality and in the sim !!!

The problem is, if I add some oscilation on the COM wires, either I get the correct segment displayed, and if Im inverting the signal, Im getting random segments litting up. If the COM wires are floating, everything is fine as until now.
But the big problem didnt got resolved with either cct. The segment gets dimmed out as the fv rises.
Damn. At least I tried my best.
---------------
From another perspective, I managed to make a static LCD driver only from Logic Gates + some friend corrections.
As you can see it is number 2 displayed in the img. This cct worked both in Sim and Reality.

I already made a Sim file with a 40110. to drive this 4digit static LCD,

all its 4 digits actually. That's cool...
I only made it in Sim. It waits to be made in Reality. I actually put this project aside, and give priority to the multiplexed one. Damn... it didnt work.

 

[_q12x_]

I am missing something important and I have no idea what.
This cct is working fine in Sim.
But in Reality is working with errors. Some other segments litting up and doesnt show anything on 3V, only on 5V. For all those gates I suppose.
It is trying to do the right thing in Reality. But is doing it with bugs.

For this one I had to change the code a bit. I know it is working, I can see it working, but with bugs. Those I can not understand from where are coming. Very misterious LCD device.