[RESOLVED!!!] Arduino UNO COLOUR NTSC Output with AD725 - Bad colours issue... - Page 1
Forum section: electronics / general

author: Axxel
author_rank: Contributor
timestamp: September 23, 2019, 05:18:26 pm
content: Dear friends.I repost here what I posted on the Arduino forum...https://forum.arduino.cc/index.php?topic=637290.0Why I do that? Because this problem I have dosen't looks to be a pure Arduino problem but an electronics problem with the RGB->COMPOSITE video converter AD725...So... Here we go!I'm trying to make an NTSC color pattern generator based on Arduino UNO full stock with stock 16mhz oscilator.The TVout Library looks great and works with interrupts, but the problem I tried to understant it, there is a lot of assembler code, and I don't understand nothing at the assembler code... It is very difficult for me to mod the library to get a colour output... due to my lack of assembler language...So I made a RGB + Sincro generator with a "raw method" and more easy to understand code based on this thread:https://forum.arduino.cc/index.php?topic=43085.0I modded it a little bit to have R, G and B channels.With some modifications to have an RGB output here is the code:You can download the code in the attachment.If you want this code run, please upload and compile with Arduino IDE 1.0.6. With the more recents one like 1.8, it will not work, another problem I have to FIX later... This should be due to the NOP; asm instruction... I don't know...I use this diagram to connect the AD725:The problem are the colours.Instead of THIS,I have this:The problem is not with pure R pur G or pure B, the problem is when I mix for example blue and red, as you can see instead of pink, I have a full-red...The red looks pale red.The yellow looks pale green.The green doesn't look... green but light blue...The white is not white but like gray...I loaded the game toorum quest 2.http://petenpaja.blogspot.com/2013/11/toorums-quest-ii-retro-video-game.htmlI have the same problems...So I think this is an issue with the AD725 RGB to PAL/NTSC encoder... I tried to change the resistors from the arduino to the AD725... No results.I think this issue is with the PIN 12 YTRAP... But I'm not sure...If someone had experience with the AD725 chip it can be great for hepling me there!Best regards...UPDATE AND SOLUTIONHere was the problem, the cable to the 4OSC pin when I move it, the colours changes.I shorted this cable as much as posible and here we go!

author: Benta
author_rank: Super Contributor
timestamp: September 23, 2019, 06:27:29 pm
content: Looking at your schematic, you've selected PAL instead of NTSC.

author: Axxel
author_rank: Contributor
timestamp: September 23, 2019, 06:33:35 pm
content: Hi! This is an error of my schematic. On my protoboard, this pin go to +5V pin. I actualized the schematic.But the problem isn't here.

author: StillTrying
author_rank: Super Contributor
timestamp: September 23, 2019, 07:59:41 pm
content: Quote from: Axxel on September 23, 2019, 05:18:26 pmI don't think it will be the YTRAP because there shouldn't be much 3.5MHz in the colour bar's luma anyway. I'd give it a try just leaving pin 12 open. All the long leads around the AD725 won't help much.

author: Axxel
author_rank: Contributor
timestamp: September 23, 2019, 09:21:09 pm
content: Quote from: StillTrying on September 23, 2019, 07:59:41 pmI removed the inductance and the ceramic capacitor... It doesn't change anything. Same problem.

author: StillTrying
author_rank: Super Contributor
timestamp: September 23, 2019, 10:42:14 pm
content: Quote from: Axxel on September 23, 2019, 09:21:09 pmI suppose that's right, with no 3.5MHz luminance in the colour bars it shouldn't have made any difference anyway.I can't think of any combination of fault that would change the colour bars to the colours you're getting.http://kudelsko.free.fr/mires/fonctionnement2.htm

author: Axxel
author_rank: Contributor
timestamp: September 24, 2019, 04:29:52 am
content: I connected the system on my bedroom tv (CRT). Exactly the same problem... So I can discard the LCD test monitor...

author: StillTrying
author_rank: Super Contributor
timestamp: September 24, 2019, 09:49:06 am
content: I suppose you could try one colour at a time, just disconnecting and grounding the other inputs, the link I posted shows what the separate shapes of the RGB signals should be.

author: amyk
author_rank: Super Contributor
timestamp: September 24, 2019, 12:03:58 pm
content: Your MCU should be powerful enough to do NTSC output directly; this is PAL, but a similar idea:http://www.linusakesson.net/scene/phasor/

author: Axxel
author_rank: Contributor
timestamp: September 24, 2019, 04:31:35 pm
content: Quote from: amyk on September 24, 2019, 12:03:58 pmDear friend. The idea of this project is to make an analog video synthesizer. I will use the arduino only to generate the VSync and the HSync into R G and B signals. The R, G and B signals will me maked by oscilators with various LFOs etc........Quote from: StillTrying on September 24, 2019, 09:49:06 amHere there is a video:https://youtu.be/mrLbUIjj_SAAs you can see, the GREEN isn't green but looks like a pale blue.The red isn't red but look like a maroonAnd the blue looks like dark pruple...As I can see RGB signals are from 0V to 1V... If by error I put +5V at the RGB inputs of the AD725 is there a risk of damage of the AD725?

author: Benta
author_rank: Super Contributor
timestamp: September 24, 2019, 04:46:59 pm
content: Sorry, but trying to do this on a breadboard is simply utopic. Try a stripboard with short interconnects.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 24, 2019, 04:59:46 pm
content: Not sure if anyone has already suggested it, but everyone seems to be stuck on the hardware side of things...Are you certain this is not a software issue there? The colors are one thing, but the shifted lines towards the bottom of the screen suggest there is likely a software issue.

author: Nusa
author_rank: Super Contributor
timestamp: September 24, 2019, 07:04:47 pm
content: Why are you using:#01ff00 instead of #00ff00?#fb0102 instead of #ff0000?#0301ff instead of #0000ff?I agree it shouldn't make much difference in result, but if you're going to call them pure colors use the pure input values. And if those colors suddenly work better, you will have discovered a mixing problem!

author: Benta
author_rank: Super Contributor
timestamp: September 24, 2019, 09:15:38 pm
content: I have to repeat myself:Quote from: Benta on September 24, 2019, 04:46:59 pmGot it?

author: Axxel
author_rank: Contributor
timestamp: September 24, 2019, 11:25:18 pm
content: Quote from: Nusa on September 24, 2019, 07:04:47 pmDear freind, those HEX value don't mean nothing in this case, this picture is only here to illustrate (I removed then and rectified my initial post) and as you can see I send only R,G and B values 0 or 1 - So we must obtain only 8 colours with this, not all the grayscales of each channel.Quote from: Benta on September 24, 2019, 09:15:38 pmDear frind. I can make a design with Eagle and make a PCB this is not a problem for me, but before I will wait to have some more corrects results. I agree with you, those wires can create some perturbations like noise on the picture but an error of this grade I don't think so.Quote from: SiliconWizard on September 24, 2019, 04:59:46 pmDear friend. This is a very interesting point, and here I will explain what I do:I have a NTSC pattern generator with PIC which is working well. The converter that use is the MC1377, a very good chip but OBSOLETE and DISONTINUEDYes, I can find it on Aliexpress but I think this is a chinese clone and developing something with an obsolete base is not a good idea. The AD725 looks more recent and it is disponible on newark.So, as you can see, I identified on the PIC the sync R G B outputs and I connected the arduino instead of the PIC to use all the MC1377 circuitery and surpise! It works! Correct colours here!Now, let's make the same operation but reverted... Let's send the PIC outputs SYNC R G and B signals to the AD725 breadboard. Same problem, bad colours...So I can conclude : THIS IS NOT A FIRMWARE ISSUE but a AD725 circuit problem...Is my AD725 has the inputs burned?

author: amyk
author_rank: Super Contributor
timestamp: September 25, 2019, 12:01:16 am
content: Simple enough to check, just try another AD725...

author: vk6zgo
author_rank: Super Contributor
timestamp: September 25, 2019, 12:18:43 am
content: Quote from: Axxel on September 23, 2019, 05:18:26 pmI used to play with PAL picture monitors for a living, & I have definitely seen an incorrect display like yours.It could be due to phase and/or level errors in the encoding, differential phase errors in the amplifier stages after the encoder, or faulty decoder or colour difference amplifiers in the monitor.The fact that the fault is the same with another TV seems to rule the last cause out, though.Differential Phase in NTSC systems can definitely cause colour errors---- with PAL, it is effectively,cancelled out, but still has the effect of desaturation of colours.An allied effect is Differential Gain, which causes the same sort of desaturation with luma level.These are both linearity based problems which affect Composite video.As the chroma "rides" upon the luma waveform, if the amplifier is non linear, the chroma will tend to be "crushed" or "stretched" depending upon the luma level.This normally results (in NTSC) in colours being changed both in hue & saturation, but your result looks like the total loss of one colour difference signal.What would make things easy would be if you had a vectorscope!I have a vague memory of switching a video generator so that the phase was NTSC, but the subcarrier was PAL, & that caused a similar dsplay to yours, but the last time I played with this stuff was in 1999!I don't know if this "stream of consciousness" type rambling is much help, but I can't offer much more at the moment!

author: BrianHG
author_rank: Super Contributor
timestamp: September 25, 2019, 12:23:06 am
content: Your earlier first photographs look like a massive overshoot of the source RGB levels into the video encoder, or, a chroma colorburst phase error. Try cutting the source RGB luminence by 50%.If that doesn't work:Your latest photo with the 2 colors above and below the screen show a problem with the chroma colorburst maintaining lock hue due to a source video impure/un-exact source video sync, sometimes due to the inaccuracies generated by microcontroller software video pattern generators. The only way to fix this is to fix the software, or, use really old all analog IC color encoders and only old analog TVs to display these images as new modern TVs with digital color decoders expect a constant relationship between video sync and the 3.579545Mhz color burst signal unless they go into low quality VCR color decoder mode. To trick these IC into this mode, you would need to sloppily replicate the video output timing errors of a VCR's video head speed & video tape timing alignment.However, this still means a proper 525i or 263p reference source lines. Also, the COMPOSITE sync you are sending out requires all the proper stabilization pulses as they encoder may use these to know when to stop placing color bursts when the vertical sync is about to begin.

author: Axxel
author_rank: Contributor
timestamp: September 25, 2019, 02:52:42 am
content: Vectorscope... Ahhhh.. Vectorscope... I saw one 3 or 4 years ago in a junk market... I saw it, it was cheap (40 euros) but I didn't bought it because I didn't think one day I will need it and I didn't know if it was working... And fixing it... I seriously doubt if I have the skills and the material to fix itBut...Yes, I tried various values of divisors bridge(1K with 4.7K - 1K with 5.6K, i quited the 75ohms resistors to try with 220,330,1K) the only thing I get is unpowering the intensity of the colour of the channel. BUT the CHROMA doesn't get fixed, the same colours but darker...Here is why there is a probability there:Quote from: BrianHG on September 25, 2019, 12:23:06 amThe wierdest thing there is the arduino RGB code encodes perfecfly with the MC1377, as you can see in these pictures.And as I remind... At the begining in the firsts firsts tests, I was getting the correct colours... But I'm not sure...Probably the AD725 is damaged... I don't know...The problem now I havn´t any AD725 here...I bought 5 AD725 on Aliexpress, I will receive them next monthAnd I bought an AD724 on Newark, hope this one will come soon there!

author: StillTrying
author_rank: Super Contributor
timestamp: September 25, 2019, 10:55:24 am
content: Random thoughts...For the RGB inputs the AD725 data sheet says0mV to 714mV AC-Coupled, and the 470R->75R dividers should give about680mVpp, so close enough. I think more than enough has been tried to eliminate the RGB input levels. From the data sheet I don't think 0 to 5V DC would harm the RGB inputs, but I don't think there's any point either.The RGB inputs clamp the AC coupled side to 0mV themselves. Is the HSYSNC connected? Just in case.I don't agree that this can't be made to work on a breadboard even on a carrier, because the 3.5MHz colour and it's critical phase are all done inside the AD725 from the 14MHz clock, By the time the 3.5MHz appears in the composite video output it's critical timing has already been done, - in theory.The video output wire's GND should be very close to the AD725's GND, even if it is just 2 bits wire. If the video output ground is just connected to a breadboard ground somewhere the phase of the 3.5MHz colour could well be off a bit, due to the breadboard GND noise and inductance.Is there any power decoupling on the AD725's carrier? 100n would do.Around the AD725 and carrier I'd definitely be using short lengths of single core instead of the long breadboard wires.A scope would be useful.

author: BrianHG
author_rank: Super Contributor
timestamp: September 25, 2019, 11:15:24 pm
content: How about a normal scope shot of the NTSC output waveform.Also, what happens when you adjust the 'TINT' control on your monitor?

author: Axxel
author_rank: Contributor
timestamp: September 26, 2019, 12:47:02 am
content: Quote from: BrianHG on September 25, 2019, 11:15:24 pmMy osciloscope fails, I will buy a rigol in a near future... I have an old one, I tried to get the NTSC signal but........ hard to see clearly...Of course I tried to adjust the TINT parameter of the monitor, but I can't find the correct colours....Quote from: StillTrying on September 25, 2019, 10:55:24 amYes, the divisor brigde is correct. The HSYNC go to the +5V. There are 100nf and 22uf decouplers on the analog power line and the digital power line. Scope... not posible for the moment...But yes! I'm waiting for the AD724 soon, I bought it yesterday!

author: StillTrying
author_rank: Super Contributor
timestamp: September 26, 2019, 01:23:36 am
content: "The HSYNC go to the +5V."Do you mean VSYNC, if HSYNC is not being driven that might be the colour problem."The AD725 accepts two common sync standards, composite sync or separate horizontal and vertical syncs. To use an external composite sync, a logic high signal is input to the VSYNC pin and the composite sync is input to the HSYNC pin. If separate horizontal and vertical syncs are available, the horizontal sync can be input to the HSYNC pin and vertical sync to the VSYNC pin. Internally, the device XNORs the two sync inputs to combine them into one negative-going composite sync.The AD725 detects the falling sync pulse edges, and times their width. A sync pulse of standard horizontal width will cause the insertion of a colorburst vector into the chroma modulators at the proper time. A sync pulse outside the detection range will cause suppression of the color burst, and the device will enter its vertical blanking mode. During this mode, the on-chip RC time constants are verified using the input frequency reference, and the filter cutoff frequencies are retuned as needed."

author: Axxel
author_rank: Contributor
timestamp: October 04, 2019, 02:46:53 am
content: Dear friends!I'm back there with some BAD news...I received the AD724. With this chip there is not colour trap, there is only an OSC - 4OSC Selector, so PIN12 to +5V.And I have ABSOLUTELY the same ugly colours...Here is the NTSC output seen on the osciloscope... My oscilsocope is OLD, and really tired... Bastetime is at 10usec/div, 0.2V/div and the 0 on the center.Sure, the problem is not the Analog Devices chip...Software should be the answer?

author: brabus
author_rank: Frequent Contributor
timestamp: October 04, 2019, 12:18:12 pm
content: On page 10 of the datasheet, you can find an interesting test circuit which uses a VGA port. You can try the chip using the same test signal you want to generate with the Arduino, and seek for the differences between the VGA Signal and the RGB you are trying to emulate.

author: Axxel
author_rank: Contributor
timestamp: October 04, 2019, 06:19:57 pm
content: I tried with real VGA Signal output form my laptop: (1024 x 768 @ 60Hz) - I also tried 800x600 but it's worst. We can't distingate the picture.On the CRT TV, the image moves up to down it is worst.Now I used the Arduino with library VGAX with the pattern example:LCD:CRT:I have exactly the same results with AD724 and AD725...

author: amyk
author_rank: Super Contributor
timestamp: October 04, 2019, 08:08:53 pm
content: Look at the input signal with the scope, and confirm whether it matches what you expect.

author: StillTrying
author_rank: Super Contributor
timestamp: October 04, 2019, 09:29:14 pm
content: There seem to have been others getting the wrong colours out of AD724s and AD725s, this one says.Solution: The width of the HSYNC signal was 6 us, out of spec of 2.8 ... 5.3 us for AD725.https://electronics.stackexchange.com/questions/442310/ad725arz-wrong-colorsMay be worth looking at the exact width of the HSYNC.

author: Axxel
author_rank: Contributor
timestamp: October 05, 2019, 06:18:14 am
content: Quote from: Benta on September 24, 2019, 04:46:59 pmHere was the problem, the cable to the 4OSC pin when I move it, the colours changes.I shorted this cable as much as posible and here we go!Thank you very much at everybody here