Hi all.
As I also mentioned in one A13 topic, I have A20 OLinuXino board with 7" LCD and X-windows started on Debian wheezy. There are some sporadical flickerings like display is fast moving up and then down in short period of time. Without cursor movement it can happen a few times in single minute. script.bin is from original image downloaded from Olimex and adopted for LCD display. Kernel is 3.4.79+, custom precompiled.
The same thing happens with second A20 board, but with A13 is ok, without flickering.
When I connect 10.3" LCD on A20, flickering happens rarely, maybe few times in single hour and those aren't so expressed or intensive like ones with 7" display. I could say that it could be hardly seen.
Hi Dudo,
I've saw that you read my latest post on A13 forum.
I have also some LCD 10in, and don't have any flickering with those.
I've notice that if I put a finger on the 7in PCB, the flickering seems to be reduced.
I hope it is not an hardware design problem with an unconnected/floating wire getting into "antenna effect" ...
I wonder if Olimex folks can tell us what is the changes requires to "change_display.sh" script as it is mentionned in the other thread. Maybe they have done the fix on recent Debian image, but I want to stick with the current image I'm using, so I need to merge the fix into it.
As I mentioned above, the same 7" LCD works fine (without flickering) on A13 board, so I suppose connectors should be fine. But, I can make one more test. A20 board + second 7" display, to be 100% sure where the problem is.
I have the same issue on A20 + 7" LCD
Hi guys,
Try using a shorter cable or shielding the one you have. I had some issues with this as well, and a shorter cable solved the problem. Hope this helps!
This sounds more like a configuration issues than a hardware one and also the fact that Olimex mentioned this in another posting with the same issue when running Debian.
I have an A20 running Android and with the original Olimex A13-LCD7 it's rock solid, yet someone here posted that their A20 with the 7" and Debian was also having the same issue.
A small error in the timing would cause the display to be unstable. I've seen this with other displays when initially setting up timing etc.
Hi all
For this problem I solved by wrapping the CABLE-IDC40 with aluminum foil for food without connect it to the ground. To prevent short circuits insulated with tape or other system
https://www.olimex.com/forum/index.php?topic=1942.msg10886#msg10886
Worked quite much for me. Still few flickering, but much lesser.
Good luck.
I have the same issue today with a newly purchased A20 and LCD7.
I am using the
'official' debian image from the link on the wiki.
I found this:
https://www.olimex.com/forum/index.php?topic=2933.msg12278#msg12278
LubOlimex mentioned that there was a typo in the display configuration script but we never got to hear what exactly this was...
If it was fixed, it looks like it never made it into the 'official' image.
I spent a while trying different settings in the change_display_a20_OlinuXino.sh. I noticed that reducing the freq value slightly improved the flickering. I kept reducing in steps to see what value worked best and eventually arrived at 23.
I have no idea what this means, or what I have actuall done, but it works!
Maybe something has drifted in the LCDs or other components since Olimex initially tested the settings?
I would appreciate the opinion of someone more experienced
"7.0")
x=800
y=480
freq=23
hbp=46
ht=1055
vbp=23
vt=1050
vspw=1
hspw=30
Is the someone who figured out how to get the real fix ?
BMK, could you share your modified "change_display_a20_OlinuXino.sh" script ?
I still get flickers depending of what is been displayed on LCD (some background images make the problem worst than others)
LubOlimex ? could you explain what was the fix you've mentionned back in March ?
Currently, I don't have flickering problems any more. But, there are some strange or invalid properties in script.bin which came with A20 image release7. When translated to .fex, 2 propeties have some different names:
lcd_vspw
lcd_hspw
than defined in fex guide or from script.bin from A13 image that I have:
lcd_hv_vspw
lcd_hv_hspw
Also, value of lcd_io_cfg0 is sometimes 0 and sometimes 268435456.
Hi,
I have a setup with A20 and 10inch Olimex LCD connected with the standard IDC40 cable.
I have the same issue vertical jumping of the image.
After done some measuring, i found some basic hardware design errors.
1/ The Dotclk is critical and running > 40 Mhz TTL signal over a IDC40 cable is simply not done unless one uses a signal/ground wire layout in the IDC cable, uses correct impedance matching and uses the correct driver.
2/ in case of the Olimex cable only a few Ground signals are used for up to 27 fast changing and time critical TTL signals. Equals bad design!
3/ The Dotclk signal is routed next to the vertical sync signal. Due to capacitive coupling in the flat cable the vertical sync signal is disturbed.
Solutions.
1/ I have a semi solution: at the LCD side of the cable. Put a 220R resistor on the vertical signal to the ground. And put a 470R resistor on the Dotclk to ground.
2/ Final solution don't use IDC40 cable, or use a very very short one. The best solution is connecting the LCD direct to the CPU board with a solid ground plane.
Marc,
Nice work Marc.
I've seem some issues with the Olimex IDC cable. It's too long you as noted and I switched to a shorter one of about 100mm. This seems to be stable but I would like to consider a replacement option seeing as I use a custom LCD anyway.
I am looking at making a small 4 layer PCB that plugs into the PCB header and routes the LCD signals via a 50 way FPC cable instead. The additional lines will allow me to place GND lines between those that need it. The more flexible FPC will also help with manufacture too.
When I have gotten to this stage, I will check carefully the DOTCLK and keep this away from the other lines. My LCD does not use V and H sync so I can drop these from the cable although if I plan to allow others to use the same board with the Olimex displays, I may leave them in.
Hi,
Be careful with the length of your FPC cable. depending on the length a 7inch with WVGA resolution may work as the dotclk is lower than the 10inch WVGA resolution.
Consider a LVDS transmitter-receiver solution for longer cables.
Running 27 TTL signals on a cable may give bad result on EMC compliance test.
In fact all signals are critical even RGB signals, all signals should respect the "5 ns" setup time to dotclk.
See your LCD timing specifications.
Another problem can be ground bounce (difference between Ground on LCD and ground on CPU) when all signals are changing form logic "0" to logic "1" at the same time, consider white characters on a black background. If signals are not within specifications one will have a less sharp image.
Marc,
Just a random thought about the need for more grounds in the cable, isn't that why ata/133 cables used 80 conductor cables on 40 pins IDC connectors? I don't have the required cable or hardware to test this theory but it sounds like the fix to a similar problem...
But then again, I'm no engineer ... Just a thought
DW
Thanks Marc,
Actually thinking more about it, it might be a good idea to build an LVDS interface for the system. Although the A20 can output LVDS I am thinking that a board that plugs into the 40 way header and then converts the existing RGB into LVDS. This then runs over the FPC (or other cable) and is converted back to RGB on the LCD board.
I think this would offer a far better solution to the EMC requirements and at the same time remove the issue of flickering that is being seen.
Coupled to this we could add a touch driver to the board that communicates via I2C for those with resistive touch panels.
I'll look into this over the next few weeks and see about building a prototype.
@deskwizard,
Yes indeed this is correct, but don't use a ATA133 cable. This cable and connector or special designed for the ATA pinning.
But the idea is correct, to use flat-cable for high speed one needs a flat-cable layout having
"signal-gnd-signal-gnd" layout, and correct impedance matching of the driver to the cable impedance.
So in short,
Higher resolution LCD will be less stable.
For 10 inch LCD the dotclk is typical 51 Mhz
For 7 inch LCD the dotclk is typical 33 Mhz
The main issue with the Olimex LCD pinning is "Dotclk not surrounded by Gnd signals"!
One has two options.
1/ use a very short cable
2/ make a LVDS interface (see dave-at-axon post)
Marc,
Is that means that software solution mentionned by LubOlimex is not true ?
@martinayotte,
I don't know if the solution mention by LubOlimex is true or not.
My problem was with 10 inch display and the cause was hardware,dotclk signal was interfering with Vertical signal.
Marc,
Hi Marc,
I've chosen the DS90C383MTDX and DS90CF384MTDX because I can get those easily here and they are cheap. I had thought about FPD-LINK III but that is a lot more complex to design in and some devices require I2C to configure them. The chipset I have chosen will work up to 45Mhz and needs no drivers.
They are simple to use and will make it quick to create a prototype. I'll re-engineer my LCD PCB to use a 40 way FPC. It's more ways than I need but I have stock of them along with the FPC connectors so makes sense to re-use them in this design. I also use the 40 way in another design so it means less stock to hold.
I'll create the board for the A20 side and I may design a receiver board for the LCD end that can plug into the existing A13-LCD from Olimex, although I don't need this as I have a custom LCD anyway, it could be offered to those wishing to sort out issues with the Olimex design.
It should mean that it will work with the 10" display too???
So, for piggyback setup the simplest and effective solution would be to interconnect the boards with PCB
with signal lines on one side, and GND plane on the other side?
Quote
2/ The best solution is connecting the LCD direct to the CPU board with a solid ground plane.
@dlombardo
Yes, this will do the job,
Quote from: dlombardo on June 30, 2014, 12:04:27 PM
So, for piggyback setup the simplest and effective solution would be to interconnect the boards with PCB
with signal lines on one side, and GND plane on the other side?
Quote
2/ The best solution is connecting the LCD direct to the CPU board with a solid ground plane.
@dave-at-axon
Regarding your LVDS PCB design, look for PCB design rules, application notes, evaluation board layout examples from the chip manufacturer.
I expect one should route the LVDS signals with respect to the correct signal impedance, route them as pair, respect equal length for all pairs, have a solid ground plane, correct placed decoupling capacitors ...
This LVDS signals run at > 400 Mhz signal speed. This is normal no problem if you respect all design constrains.
Good luck with your PCB design,
Marc,
Thanks Marc.
I use Altium Designer and I have setup the rules to route the LVDS as differential pairs with impedance and length matching as per the design documents.
I'll post back here in a few weeks when I have the PCB and tested it.
For all the newbies like me 8)
See *PROPER SOLUTION* at the end if starting from clean Debian release 7 image on default HDMI :)
Some explanation ...
I did find the Olimex Debian release 2 image, downloaded, dd to a card, boot and voila ... the image was still :)
So, I decided not to do any HW change before I get the same picture quality in Debian release 7.
Indeed I got it, comparing script.bin from those these releases. Like many did before :)
Did those 4 changes in script.bin.
Ok, I was :o, because after I got still picture I could not find the problematic one by elimination i.e. changing back parameters one by one.
But, since my system was not clean Debian release 7 any more, specially the script.bin, I used a clean image and ...
QUICK SOLUTION:
- install Debian release 7 (current wiki linked) image on a card
- boot A20 with HDMI monitor (and USB keyboard /w mouse for convenience)
- open terminal execute sudo /root/change_display_a20_OlinuXino.sh and select LCD -> 10", reboot
-> system starts on LCD with flickering and tearing issues
- fix the lcd_io_cfg0 from 0 to 268435456 in script.bin on a setup partition (there are 2 partitions on the card ;) )
* on boot this partition is mounted in /media/[ID]
* script.bin in /opt/sunxi-tools/ does not seem to matter
umount /dev/mmcblk0p1
mount /dev/mmcblk0p1 /mnt/mmc
cp -a /mnt/mmc/script.bin /mnt/mmc/back_up/script_r7_LCD10.bin
/opt/sunxi-tools/bin2fex /mnt/mmc/back_up/script_r7_LCD10.bin /mnt/mmc/back_up/script_r7_LCD10.fex
vi /mnt/mmc/back_up/script_r7_LCD10.fex
-> EDIT lcd_io_cfg0 for the LCD display 0
/opt/sunxi-tools/fex2bin /mnt/mmc/back_up/script_r7_LCD10.fex /mnt/mmc/back_up/script_r7_LCD10_fixed.bin
cp /mnt/mmc/back_up/script_r7_LCD10_fixed.bin /mnt/mmc/script.bin
sudo reboot
PROPER SOLUTION: (maybe even quicker then the solution above :) )
Boot A20 Debian release 7 (current wiki linked) image on a card with HDMI monitor (and USB keyboard /w mouse for convenience)
Change the lcd_io_cfg0 from 0 to 268435456 setting for the LCD 10" in /root/change_display_a20_OlinuXino.sh
(I find it cleanly writen using switch/case syntax 8))
and rerun /root/change_display_a20_OlinuXino.sh
sudo vi /root/change_display_a20_OlinuXino.sh
sudo /root/change_display_a20_OlinuXino.sh
Can someone please describe this settings value and include proper value in the official Debian image change_display_a20_OlinuXino.sh :)
Maybe the HW issue is to be solved ASAP, but please, start from using *lcd_io_cfg0 = 268435456*.