Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
Thank you very much. That's interesting to look at.
The main oscillator is not a UPC1883, but a TDA4856. Made by Phillips, not NEC.
http://pdf.datasheetcatalog.com/datashe ... 4856_2.pdf
EDIT: Scratch that, maybe it does have an AFC-like function.
More tomorrow. I've been learning a lot of new things. I might actually have to buy a logic analyzer now...
The main oscillator is not a UPC1883, but a TDA4856. Made by Phillips, not NEC.
http://pdf.datasheetcatalog.com/datashe ... 4856_2.pdf
EDIT: Scratch that, maybe it does have an AFC-like function.
More tomorrow. I've been learning a lot of new things. I might actually have to buy a logic analyzer now...
-
- Posts: 1535
- Joined: Thu Mar 02, 2017 6:53 pm
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
An update to VCR Mode on a Sony BVM-D14(and I assume the D9 as well), but like the manual says, these units DO have VCR Mode, and it's able to be turned on, but ONLY with the Composite/S-Video (Y/C) BKM-127W input card (thank you to lewolfeur for this revelation).
I wonder how we could make VCR Mode accessible for RGB sources using the more common BKM-129x card? Any ideas?
Update on the Raspberry Pi 3 RetroTINK-RGB board by Mike Chi (posted with his permission) in regards to sync:
“””I use a XNOR gate to combine the horizontal and vertical syncs. The output does contain horizontal slices in the vertical sync but it's not 100% to spec since there it causes a slight time shift in the horizontal sync during the vertical sync period. This causes the AFC PLL to have to re-lock at the start of every new screen refresh.
For my PVM and BVM, this results in that dampened oscillation like in the figures you [I sent him the link to the RetroRGB site about AFC and the 68x card) sent but by the time it gets to the active image area it's fine. One user had a BVM-D20F1U that didn't behave until he turned on VCR mode but it sounds like you don't have that option.
I think the safest choice is to use a modified RetroTINK-RGB where I modify the device to output a pure HSYNC (instead of CSYNC). You could combine the HSYNC and VSYNC lines by connecting them to the sync input and output lines of your BVM (don't worry it sounds weird but that's what I do for my BVM). That would preserve the correct HSYNC information during the VSYNC period.”””
So I bought his board and am going to see if it fixes my problem as ideally I bought the BVM-D9 specifically for a RetroPie project. I’ll report back with if this worked.
I wonder how we could make VCR Mode accessible for RGB sources using the more common BKM-129x card? Any ideas?
Update on the Raspberry Pi 3 RetroTINK-RGB board by Mike Chi (posted with his permission) in regards to sync:
“””I use a XNOR gate to combine the horizontal and vertical syncs. The output does contain horizontal slices in the vertical sync but it's not 100% to spec since there it causes a slight time shift in the horizontal sync during the vertical sync period. This causes the AFC PLL to have to re-lock at the start of every new screen refresh.
For my PVM and BVM, this results in that dampened oscillation like in the figures you [I sent him the link to the RetroRGB site about AFC and the 68x card) sent but by the time it gets to the active image area it's fine. One user had a BVM-D20F1U that didn't behave until he turned on VCR mode but it sounds like you don't have that option.
I think the safest choice is to use a modified RetroTINK-RGB where I modify the device to output a pure HSYNC (instead of CSYNC). You could combine the HSYNC and VSYNC lines by connecting them to the sync input and output lines of your BVM (don't worry it sounds weird but that's what I do for my BVM). That would preserve the correct HSYNC information during the VSYNC period.”””
So I bought his board and am going to see if it fixes my problem as ideally I bought the BVM-D9 specifically for a RetroPie project. I’ll report back with if this worked.
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
I was contacted by a french person of ikegami, he want i give him all information, description, diagram of the connection to monitor. (maybe there already in the beginning of this topic)
He will try to transfer it to an old ingeneer of ikegami (if there still one) for know if there is a possibility of modification for this sync issue .
He will try to transfer it to an old ingeneer of ikegami (if there still one) for know if there is a possibility of modification for this sync issue .
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
Wow.lewolfeur wrote:I was contacted by a french person of ikegami, he want i give him all information, description, diagram of the connection to monitor. (maybe there already in the beginning of this topic)
He will try to transfer it to an old ingeneer of ikegami (if there still one) for know if there is a possibility of modification for this sync issue .
I would be happy to make a detailed summary of the situation, and to provide all documentation. You could send it to the French Ikegami representative.
Would the old Ikegami engineer be Japanese? If so, I could write to him directly in Japanese.
For now, I will start preparing the documentation.
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
I have made many incorrect assumptions. So many, in fact, that I really ought to update the OP.
Having said that, I think I'm beginning to reach an understanding of what's happening here.
The UPC1883 is the heart of the HTM-2050R2's deflection card. It's the IC that takes the sync signals and controls the yoke with them. However, Ikegami did something with it that not only goes against what the datasheet recommends, but defies logic entirely. The only way it makes any sense at all is if Ikegami didn't mark something critical on their schematic...and that's what I currently suspect is exactly what happened. (EDIT: Nope! Seriously, this makes no sense.)
Allow me to explain.
This is a block diagram of the UPC1883, with the bottom cut off since that only deals with vertical sync:
![Image](http://i.imgur.com/dcWOMsG.png)
Pin 26 is the input for the sync pulse, and pin 17 is the input for the flyback pulse. As I understand it, AFC in general works by comparing a new and incoming sync pulse with the in-progress flyback pulse to see if there is a difference. A difference indicates that the sync pulse is not in the right place, and the circuit will act to correct it accordingly.
Therefore, the actual comparing happens inside of this UPC1883. This is something I had quite wrong before; I thought that at least part of the AFC process was happening externally, but it's not.
So, what the heck are pin 24, the 4053B "sync selector" and all of the external slow/fast/normal things all about? Contrary to what I thought before, pin 24 is not an input - rather, it is there to output a voltage. It is the modulation of this voltage by an external circuit that determines exactly how the AFC deals with a difference in the sync/flyback pulses.
Let's look at the extra info on pin 24 in the detailed Japanese datasheet.
![Image](http://i.imgur.com/GpreIFn.png)
The circuitry you see here is simply what's inside of the IC. The 3.5V is vaguely the "pin voltage" which I am only realizing now is an output. On the right, where it tells you what to attach to the pin, it says "Construct a lag-lead filter. The time constant of this filter will influence horizontal jitter. Generally, in cases where there is fast, fine jitter, make the time constant long, and in cases where there is large, deep jitter, make the time constant short. However, please consider this only after confirming that there is no jitter component in the signal being input to pin 26."
By the last sentence, I assume that they mean to make sure that your monitor circuitry design itself isn't adding jitter on its own.
This, from the block diagram above, is what they mean when they say a lag-lead filter:
![Image](http://i.imgur.com/5D2uKD0.png)
I'm just learning about what these are really all about. You know, they actually mispelled lag lead filter in the datasheet (ラングリード instead of ラグリード) which threw me off the trail since I couldn't google it. Anyway, at last, let's repost that schematic from the previous page and take a look.
![Image](http://i.imgur.com/ILWNQci.png)
You'll notice that there is indeed a 3.3k resistor / 2.2uF capacitor combo just like in the UPC1883 datasheet. This is what they recommend. The other selectable lines have a 3.3k resistor / 1.0uf capacitor and a 2.2k resistor /0.22uf capacitor combo, which must simply give different time constants.
What it looks like is that none of the other crap before this really matters. The 4053B (IC207) is nothing but a group of switches. The NJU3718 is nothing but a switch-flipper, and it's not even the thing that decides which switch to flip - that happens much earlier in the chain, probably by some computer on the motherboard.
The only thing that matters is which resistor/capacitor combo is being used to modulate the output of pin 24 and create a time constant for it. This is where that paragraph Xer Xian posted before applies:
Here is what confuses the heck out of me: lag-lead filters are supposed to go to ground. The example diagram here has it going to ground. Meanwhile, the stupid Ikegami schematic has it switching between the 9V power rail and nothing, just an open circuit.
What I suspect is that in the schematic, they neglected to mark that pins 13, 1 and 3 of the 4053B (IC207) go to ground. This is the only way any of this makes sense.
As you can see in this link, 9V at one end of one of these lag-lead filters and 3.5V at the other cause things to come to a stand-still, effectively just turning it off. Therefore, what probably happens is that the NJU3718 only toggles one of these pairs at a time, giving it access to ground, while the other two are negated by the 9V connection.
What I'm going to try next is to simply bypass the 4053B entirely and force specific lag-lead filters on pin 24. One resistor, one capacitor, soldered to pin 24 and ground. Everything else gets cut off.
EDIT: Damn it, pins 1, 3 and 13 really do look like they're floating and not grounded. How the hell is this supposed to work? I found other datasheets for TV oscillators like this, the TA8867AN, the CXA1871S and the NJM2257, and they also have lag-lead filters going to ground. It just doesn't make any sense! Screw it, I'm trying the idea above anyway. All I want to do is try connecting the AFC filter pin like they have in the datasheet. Hopefully nothing will blow up.
CXA1464AS, too.
Having said that, I think I'm beginning to reach an understanding of what's happening here.
The UPC1883 is the heart of the HTM-2050R2's deflection card. It's the IC that takes the sync signals and controls the yoke with them. However, Ikegami did something with it that not only goes against what the datasheet recommends, but defies logic entirely. The only way it makes any sense at all is if Ikegami didn't mark something critical on their schematic...and that's what I currently suspect is exactly what happened. (EDIT: Nope! Seriously, this makes no sense.)
Allow me to explain.
This is a block diagram of the UPC1883, with the bottom cut off since that only deals with vertical sync:
![Image](http://i.imgur.com/dcWOMsG.png)
Pin 26 is the input for the sync pulse, and pin 17 is the input for the flyback pulse. As I understand it, AFC in general works by comparing a new and incoming sync pulse with the in-progress flyback pulse to see if there is a difference. A difference indicates that the sync pulse is not in the right place, and the circuit will act to correct it accordingly.
Therefore, the actual comparing happens inside of this UPC1883. This is something I had quite wrong before; I thought that at least part of the AFC process was happening externally, but it's not.
So, what the heck are pin 24, the 4053B "sync selector" and all of the external slow/fast/normal things all about? Contrary to what I thought before, pin 24 is not an input - rather, it is there to output a voltage. It is the modulation of this voltage by an external circuit that determines exactly how the AFC deals with a difference in the sync/flyback pulses.
Let's look at the extra info on pin 24 in the detailed Japanese datasheet.
![Image](http://i.imgur.com/GpreIFn.png)
The circuitry you see here is simply what's inside of the IC. The 3.5V is vaguely the "pin voltage" which I am only realizing now is an output. On the right, where it tells you what to attach to the pin, it says "Construct a lag-lead filter. The time constant of this filter will influence horizontal jitter. Generally, in cases where there is fast, fine jitter, make the time constant long, and in cases where there is large, deep jitter, make the time constant short. However, please consider this only after confirming that there is no jitter component in the signal being input to pin 26."
By the last sentence, I assume that they mean to make sure that your monitor circuitry design itself isn't adding jitter on its own.
This, from the block diagram above, is what they mean when they say a lag-lead filter:
![Image](http://i.imgur.com/5D2uKD0.png)
I'm just learning about what these are really all about. You know, they actually mispelled lag lead filter in the datasheet (ラングリード instead of ラグリード) which threw me off the trail since I couldn't google it. Anyway, at last, let's repost that schematic from the previous page and take a look.
![Image](http://i.imgur.com/ILWNQci.png)
You'll notice that there is indeed a 3.3k resistor / 2.2uF capacitor combo just like in the UPC1883 datasheet. This is what they recommend. The other selectable lines have a 3.3k resistor / 1.0uf capacitor and a 2.2k resistor /0.22uf capacitor combo, which must simply give different time constants.
What it looks like is that none of the other crap before this really matters. The 4053B (IC207) is nothing but a group of switches. The NJU3718 is nothing but a switch-flipper, and it's not even the thing that decides which switch to flip - that happens much earlier in the chain, probably by some computer on the motherboard.
The only thing that matters is which resistor/capacitor combo is being used to modulate the output of pin 24 and create a time constant for it. This is where that paragraph Xer Xian posted before applies:
The time constant of the RC filter provided at the output of the discriminator, determines how fast the dc control voltage can change its amplitude to correct the oscillator frequency. A time constant much larger than 64 μs is needed for the shunt capacitor to bypass horizontal sync and sawtooth components in the control circuit while filtering out noise pulses. However, a large time constant may not permit the control voltage to change within a fraction of a second when sync is temporarily lost while changing channels. Also, if the time-constant is too large, the dc control voltage may be effected by the vertical sync pulses, causing bend at the top of the picture. A typical value of the AFC filter time-constant is about 0.005 second, i.e., a period nearly equal to 75 horizontal lines.
The filtering circuit that follows the diode section of the discriminator controls the performance of the AFC circuit. Too large a time constant makes the control sluggish, while insufficient damping, on account of too small a time constant, causes the oscillator to ‘hunt’ returning to the correct frequency. Excessive hunting in the AFC circuit appears as ‘weaving’ or ‘geartooth’ on the picture.
Here is what confuses the heck out of me: lag-lead filters are supposed to go to ground. The example diagram here has it going to ground. Meanwhile, the stupid Ikegami schematic has it switching between the 9V power rail and nothing, just an open circuit.
What I suspect is that in the schematic, they neglected to mark that pins 13, 1 and 3 of the 4053B (IC207) go to ground. This is the only way any of this makes sense.
As you can see in this link, 9V at one end of one of these lag-lead filters and 3.5V at the other cause things to come to a stand-still, effectively just turning it off. Therefore, what probably happens is that the NJU3718 only toggles one of these pairs at a time, giving it access to ground, while the other two are negated by the 9V connection.
What I'm going to try next is to simply bypass the 4053B entirely and force specific lag-lead filters on pin 24. One resistor, one capacitor, soldered to pin 24 and ground. Everything else gets cut off.
EDIT: Damn it, pins 1, 3 and 13 really do look like they're floating and not grounded. How the hell is this supposed to work? I found other datasheets for TV oscillators like this, the TA8867AN, the CXA1871S and the NJM2257, and they also have lag-lead filters going to ground. It just doesn't make any sense! Screw it, I'm trying the idea above anyway. All I want to do is try connecting the AFC filter pin like they have in the datasheet. Hopefully nothing will blow up.
CXA1464AS, too.
Last edited by SamIAm on Wed Aug 09, 2017 8:40 am, edited 6 times in total.
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
Yes say him that we have some monitor 1990r and 2050 and there is some sync problem with some video game console, he want the diagram of how we connect console to monitor, the console description (it would be best to give him the description of composite sync signal from each console who have problem) In my case only neogeo aes NTSC-J and nintendo 64 PAL. (but i am sure the other console who have problem on 2050 have same problem on 1990r)SamIAm wrote:Wow.lewolfeur wrote:I was contacted by a french person of ikegami, he want i give him all information, description, diagram of the connection to monitor. (maybe there already in the beginning of this topic)
He will try to transfer it to an old ingeneer of ikegami (if there still one) for know if there is a possibility of modification for this sync issue .
I would be happy to make a detailed summary of the situation, and to provide all documentation. You could send it to the French Ikegami representative.
Would the old Ikegami engineer be Japanese? If so, I could write to him directly in Japanese.
For now, I will start preparing the documentation.
Yes the old engineer will must be a japanese or someone who know well these model, dont know if we can have after a direct mail to contact him.
Of course, it guarantees nothing thereafter, the person or persons are likely to see these information, we'll see if that gives some positive things about for us, a mod to do or else.
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
Ah, OK. If he said it like that, he might not be able to do much for us. There is a big difference between helping someone connect something properly and set all the right settings, and helping them open the system and modify the way it works. Due to the danger involved, he is probably obligated by company rules not to assist us at all.
But if you're reading this, Ikegami guy, please do help us if you can!
---------------
![Image](http://i.imgur.com/F9kHLrY.png)
This is the schematic of the BVM-2015's AFC switch. See where it says AFC.SW and S/N/F? Notice how it has the same lag lead filters set up. In fact, all it does is vary the resistor value.
What I think I'm going to do is connect a lag lead filter like the UPC1883 document says to do, including a 2.2uf capacitor, but to use a potentiometer to try to find the best value possible.
But if you're reading this, Ikegami guy, please do help us if you can!
---------------
![Image](http://i.imgur.com/F9kHLrY.png)
This is the schematic of the BVM-2015's AFC switch. See where it says AFC.SW and S/N/F? Notice how it has the same lag lead filters set up. In fact, all it does is vary the resistor value.
What I think I'm going to do is connect a lag lead filter like the UPC1883 document says to do, including a 2.2uf capacitor, but to use a potentiometer to try to find the best value possible.
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
Will reply him this friday with the information i have and link to this topic, i you want to send me addition information , because i am not as good to the research like you do in this post, i will add them.
we will see if this result to something.
also pick up 3 day ago a d20f1 and seem like he have a sync issue with neogeo aes, vcr mode to "on" and still same. ( dreamcast 240p test suite worked without sync issue)
https://www.youtube.com/watch?v=a4Pa6U2 ... e=youtu.be
we will see if this result to something.
also pick up 3 day ago a d20f1 and seem like he have a sync issue with neogeo aes, vcr mode to "on" and still same. ( dreamcast 240p test suite worked without sync issue)
https://www.youtube.com/watch?v=a4Pa6U2 ... e=youtu.be
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
Fascinating development!
Remember how I said I bought a second HTM-2050R2 that turned out to be junk, the seller was going to send me another one, and I would have an expendable unit to experiment on? Well, the other one came. After getting the resistors I took out back on the first unit (no damage done - it works again), I busted open the expendable unit to get the deflection board out.
It was clearly a revised version.
I should note from the beginning that PC Engine video does basically the same thing on this set, although it is slightly different.
Anyway, the 4053B? Gone. The three 2SC3398 transistors? Gone. Every resistor from 267 to 277 and capacitors 242 and 243? Gone, all with nothing to replace them - just empty solder pads. And the connection to the NJU3718? Cut. Literally the only thing left of that entire mess in the schematic I've posted a few times was a single resistor/capacitor combo, connecting to pin 24 and looking just like a lag-lead filter...except that it's still connected to the damn 9V rail and not ground.
I'll take real pictures later, but this is what the revised schematic would look like.
![Image](http://i.imgur.com/0cBFKEI.png)
So, why the hell is the resistor/capacitor lag-lead filter connected to 9V and not ground? I don't know, but the next time I have a minute to fool with this, I'm going for the ground connection like in the UPC1883 datasheet.
Wild guess time: Ikegami may have been setting up to allow the user to select slow/normal/fast AFC from within the digital on-screen menu. That would explain why they would involve a digital-signal chip like the NJU3718. Using a 4053B as a switch multiplex makes perfect sense in this case. Then, they probably gave up on it at some point, but left some of the parts on the board (when you're selling a CRT for $10,000+, a few more pennies in parts matters little).
Why on earth they have the filter(s) going to 9V is beyond me. Maybe it's supposed to be like that for a reason I'm not aware of; maybe it's just a mistake that didn't cause any problems. But since the PC Engine video is equally messed up on this board, I strongly suspect that this AFC filter function is and has always been improperly implemented.
I can't wait to try fixing it!
EDIT: Nope! I'm wrong again. It turns out that you can have 9V at the other end of the capacitor and it will work.
It sounds like these lag-lead filters involve simply charging a capacitor, then discharging it in the opposite direction. When it finishes charging and discharging is based on how large the capacitor is, and how much resistance is between it and the voltage source.
Link to simulated circuit.
Remember how I said I bought a second HTM-2050R2 that turned out to be junk, the seller was going to send me another one, and I would have an expendable unit to experiment on? Well, the other one came. After getting the resistors I took out back on the first unit (no damage done - it works again), I busted open the expendable unit to get the deflection board out.
It was clearly a revised version.
I should note from the beginning that PC Engine video does basically the same thing on this set, although it is slightly different.
Anyway, the 4053B? Gone. The three 2SC3398 transistors? Gone. Every resistor from 267 to 277 and capacitors 242 and 243? Gone, all with nothing to replace them - just empty solder pads. And the connection to the NJU3718? Cut. Literally the only thing left of that entire mess in the schematic I've posted a few times was a single resistor/capacitor combo, connecting to pin 24 and looking just like a lag-lead filter...except that it's still connected to the damn 9V rail and not ground.
I'll take real pictures later, but this is what the revised schematic would look like.
![Image](http://i.imgur.com/0cBFKEI.png)
So, why the hell is the resistor/capacitor lag-lead filter connected to 9V and not ground? I don't know, but the next time I have a minute to fool with this, I'm going for the ground connection like in the UPC1883 datasheet.
Wild guess time: Ikegami may have been setting up to allow the user to select slow/normal/fast AFC from within the digital on-screen menu. That would explain why they would involve a digital-signal chip like the NJU3718. Using a 4053B as a switch multiplex makes perfect sense in this case. Then, they probably gave up on it at some point, but left some of the parts on the board (when you're selling a CRT for $10,000+, a few more pennies in parts matters little).
Why on earth they have the filter(s) going to 9V is beyond me. Maybe it's supposed to be like that for a reason I'm not aware of; maybe it's just a mistake that didn't cause any problems. But since the PC Engine video is equally messed up on this board, I strongly suspect that this AFC filter function is and has always been improperly implemented.
I can't wait to try fixing it!
EDIT: Nope! I'm wrong again. It turns out that you can have 9V at the other end of the capacitor and it will work.
It sounds like these lag-lead filters involve simply charging a capacitor, then discharging it in the opposite direction. When it finishes charging and discharging is based on how large the capacitor is, and how much resistance is between it and the voltage source.
Link to simulated circuit.
Last edited by SamIAm on Wed Aug 09, 2017 9:52 am, edited 1 time in total.
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
Makes sense to me. Also, that was some good reverse-engineering, figuring out about the UPC1883 and the IC207 roles (or lack thereof)! This thread, with all the twists and revelations, feels like reading a crime novel - I'm loving itSamIAm wrote:Wild guess time: Ikegami may have been setting up to allow the user to select slow/normal/fast AFC from within the digital on-screen menu. That would explain why they would involve a digital-signal chip like the NJU3718. Using a 4053B as a switch multiplex makes perfect sense in this case. Then, they probably gave up on it at some point, but left some of the parts on the board (when you're selling a CRT for $10,000+, a few more pennies in parts matters little).
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
I'm glad I'm not just annoying people with all of these posts. It helps me think to lay out everything and have to explain it.Xer Xian wrote:Makes sense to me. Also, that was some good reverse-engineering, figuring out about the UPC1883 and the IC207 roles (or lack thereof)! This thread, with all the twists and revelations, feels like reading a crime novel - I'm loving itSamIAm wrote:Wild guess time: Ikegami may have been setting up to allow the user to select slow/normal/fast AFC from within the digital on-screen menu. That would explain why they would involve a digital-signal chip like the NJU3718. Using a 4053B as a switch multiplex makes perfect sense in this case. Then, they probably gave up on it at some point, but left some of the parts on the board (when you're selling a CRT for $10,000+, a few more pennies in parts matters little).
![Very Happy :D](./images/smilies/icon_biggrin.gif)
--------------------------------
Here's another link to the same set of simulated circuits as before, with minor modifications. If you're wondering what a time-constant can do, not so much what it is, this can help fill you in. On the far right oscilloscope, you'll see a pure pulse, while on the other four, you'll see the pulse get stretched by varying speeds and amplitudes of capacitor discharge. There is a slider on the right that will let you adjust the resistor on the bottom circuit. Notice how a 1uf capacitor discharging through a 3.3k resistor has a similar profile to a 2.2uf capacitor discharging through a 1.2k resistor.
Recall that the junk unit has only a 3.3k resistor and a 2.2uf capacitor as a lag-lead filter on pin 24. This is the same as the slowest of the three speeds on my original HTM-2050R2. Slow means a long time constant. The UPC1883 datasheet said "In cases where there is large, deep jitter, make the time constant short." The extreme warping of the PC Engine picture suggests that we need to make the time constant shorter, which means that I should replace the junk unit's 3.3k resistor with something like a 1.2k resistor.
By the way, I think that my previous experiment with taking other resistors off resulted in pin 24 of the UPC1883 getting no lag-lead filter at all. That would explain why the result was so drastically bad.
So, a shorter time constant seems like the best idea to start with. However, it's possible that the solution will be much the reverse of that. Take a look at this excerpt about "hunting". Even if you don't read the text, just look at the graph. This is illustrating what happens when the time constant is too short: basically, the AFC circuit winds up overcorrecting any problems. See how it looks like it would result in a picture that waves back and forth repeatedly? Well, that is exactly the kind of distortion that I see in the PC Engine video.
![Image](http://i.imgur.com/UIetmA7.png)
An entire pulse missing and an over-agressive correction would explain why the picture is bad for the entire top third of the screen.
Thus, today I bought a 10k potentiometer. I plan on taking out the 3.3k resistor in the junk unit, running long wires between the solder pads and a breadboard with this potentiometer on it, and while wearing PVC gloves, I'm going to try adjusting the resistance while the unit is on. Don't worry, this is all pretty low-voltage.
If turning the resistance down below 3.3k improves the picture, then we know that the time constant before was too long. However, if turning it down makes the problem worse, and/or if turning it up makes it better, then it's this hunting that's the problem, , and I think...
![Image](http://i.imgur.com/5D2uKD0.png)
...that that might mean toying with this dinky little 0.001uf capacitor. EDIT: I can't help but notice that most other oscillator datasheets that designate a filter like this one have that little cap as 0.01uf...
If you want to know what a time constant really is, take a look at this RC time constant calculator.
Now, look at the example time constant filter in that excerpt: 1m resistor with a 0.005uf capacitor. Run this through the calculator, and you get a time constant 0.005 seconds, just like they said. 3.3k and 2.2uf is 0.007 seconds, or 7ms.If a voltage is applied to a capacitor of Value C through a resistance of value R, the voltage across the capacitor rises slowly. The time constant is defined as the time it will take to charge to 63.21% of the final voltage value.
My BVM's slow AFC setting is 7ms. Normal is 2ms, and fast is 0.5ms. If I use the 2.2uf capacitor, that means I need a 1k resistor for 2ms. The lowest I can get with this capacitor seems to be 1ms, which I can do with 500 ohms.
EDIT: Sigh. On my junk unit, one of the screws that held the deflection board's heat sink to the main chassis was badly stuck, and I had to chisel it. I did the mod on the board...now the system won't turn on. I didn't have time to look into it, but I think the power board got rattled in the process since it's right behind where I was hitting. Here's hoping it's just something mundane like a connector that got knocked loose.
If it's really dead, then hey, at least it was the junk unit.
EDIT2: What am I thinking? Too much hunting would result in every sequential line being alternately left or right of where it should be. What I'm seeing is collections of lines making large wave patterns. It's definitely not over-hunting. It's probably not enough hunting. If I can get my stupid junk unit to come back on, I'm going right for smaller resistance values.
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
It was a day of successes and defeats.
First, as I mentioned in an edit above, I had a tough time getting a screw out of my junk 2050. It was holding the deflection board in place, so I had to get it. The head got totally stripped, and in the end, there was nothing but to chisel the thing. It came out, but the next time I tried to turn on the system, it gave no sign of life. I checked the fuse and many other things on the power board, which were all near the screw and took a relatively high amount of shock from the chiseling, but there is no sign of trouble. Meanwhile, when I plug it in and turn it on, none of the test-points for any of the voltages give anything, even for a moment.
Thus went the first defeat. At least it was the junk unit.
I took the simplified deflection board from the junk unit and quickly modified it so that it would have a 10k pot in place of the 3.3k resistor and connected it with wires so that I could adjust the pot in real-time with the TV on. Luckily, this board is fully compatible with the good units, and it still works.
Unlike last time, where my experiment caused total chaos on the screen, this functioned. Set to about 3.3k, the pot gave the same results as I always get, and adjusting it, I could see changes. Just the fact that I've come this far - I've understood what time-constants in AFC are about, and I've successfully implemented the mod I've always wanted to try - was very gratifying. It feels like a success.
That's why it doesn't bother me terribly that it didn't fix the problem with PCE video. Reducing the resistance and shortening the time constant moved the distortion up the screen a little, but it far from fixed it.
![Image](http://i.imgur.com/E4d4SiZ.jpg)
This is pretty much what it's always looked like.
Increasing the resistance didn't really hurt at first, but at the full 10k, the whole picture started wobbling a little.
I also tried the SFC to see if the jitter in the top few lines could be removed by adjusting the AFC here, but it couldn't. That's a little more disappointing, to be honest.
In terms of what else might be tried, there are two things: 1. Swap the 2.2uf capacitor with something smaller. This would give the time constant pulses a different shape (not sure if that matters) and allow me to push for shorter constants than the 2.2uf cap allows. 2. Swap the 0.001uf capacitor with something larger. No idea what this will even do (my money is on nothing at all), but I'm just curious since so many other designs use a 0.01uf capacitor.
On the other hand, I've got all the parts to try the mod I linked to before that will take the raw Hsync and Vsync pulses from the PC Engine and reshape them, then mux them together. I'm a lot more optimistic about getting that to work.
There are also the Extrons...but I'm not as hopeful about them. Adding an altogether missing pulse seems beyond what these were designed to do.
No matter what happens with this current mod...even it it turns out that dealing with a missing pulse beyond what the oscillator in the HTM-2050R2 is capable of even with the AFC adjusted...at least we'll know for sure. That's a good enough result for me!
First, as I mentioned in an edit above, I had a tough time getting a screw out of my junk 2050. It was holding the deflection board in place, so I had to get it. The head got totally stripped, and in the end, there was nothing but to chisel the thing. It came out, but the next time I tried to turn on the system, it gave no sign of life. I checked the fuse and many other things on the power board, which were all near the screw and took a relatively high amount of shock from the chiseling, but there is no sign of trouble. Meanwhile, when I plug it in and turn it on, none of the test-points for any of the voltages give anything, even for a moment.
Thus went the first defeat. At least it was the junk unit.
I took the simplified deflection board from the junk unit and quickly modified it so that it would have a 10k pot in place of the 3.3k resistor and connected it with wires so that I could adjust the pot in real-time with the TV on. Luckily, this board is fully compatible with the good units, and it still works.
Unlike last time, where my experiment caused total chaos on the screen, this functioned. Set to about 3.3k, the pot gave the same results as I always get, and adjusting it, I could see changes. Just the fact that I've come this far - I've understood what time-constants in AFC are about, and I've successfully implemented the mod I've always wanted to try - was very gratifying. It feels like a success.
That's why it doesn't bother me terribly that it didn't fix the problem with PCE video. Reducing the resistance and shortening the time constant moved the distortion up the screen a little, but it far from fixed it.
![Image](http://i.imgur.com/E4d4SiZ.jpg)
This is pretty much what it's always looked like.
Increasing the resistance didn't really hurt at first, but at the full 10k, the whole picture started wobbling a little.
I also tried the SFC to see if the jitter in the top few lines could be removed by adjusting the AFC here, but it couldn't. That's a little more disappointing, to be honest.
In terms of what else might be tried, there are two things: 1. Swap the 2.2uf capacitor with something smaller. This would give the time constant pulses a different shape (not sure if that matters) and allow me to push for shorter constants than the 2.2uf cap allows. 2. Swap the 0.001uf capacitor with something larger. No idea what this will even do (my money is on nothing at all), but I'm just curious since so many other designs use a 0.01uf capacitor.
On the other hand, I've got all the parts to try the mod I linked to before that will take the raw Hsync and Vsync pulses from the PC Engine and reshape them, then mux them together. I'm a lot more optimistic about getting that to work.
There are also the Extrons...but I'm not as hopeful about them. Adding an altogether missing pulse seems beyond what these were designed to do.
No matter what happens with this current mod...even it it turns out that dealing with a missing pulse beyond what the oscillator in the HTM-2050R2 is capable of even with the AFC adjusted...at least we'll know for sure. That's a good enough result for me!
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
Keen to see how you progress with this, SamIam.
I was having a look at one of my old TV repair books and found a section on AFC modifications for TV's. I'm not sure if it will help you or not but thought I would post the info in case it does. The important part to note is the author recommends reducing the value of the capacitor(s) in the anti-hunt network to shorten the time constant.
![Image](http://i.imgur.com/1oh8XMJ.jpg)
![Image](http://i.imgur.com/COkTPWq.jpg)
I was having a look at one of my old TV repair books and found a section on AFC modifications for TV's. I'm not sure if it will help you or not but thought I would post the info in case it does. The important part to note is the author recommends reducing the value of the capacitor(s) in the anti-hunt network to shorten the time constant.
![Image](http://i.imgur.com/1oh8XMJ.jpg)
![Image](http://i.imgur.com/COkTPWq.jpg)
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
@xga - Thank you so much for taking the time to get those scans to me.
I recently did the following:
1. Tried replacing the 0.001uf cap with a 0.01uf cap. It only screwed up the picture. Interestingly, leaving it off altogether didn't cause any noticeable effects until I switched the unit in and out of the on-board HD test patterns. After that, the oscillator somehow stretched the 240p image 2x vertically!
2. Tried swapping the 2.2uf cap in the main RC time-constant filter with a 0.22uf cap. Although I was able to push the constant shorter than before, it didn't help much at all.
I'd be happy to try some things with an anti-hunt circuit added to the main filter, except that I don't feel like I really understand how it works or how it's supposed to be implemented.
Instead, I just had a crazy thought, and if someone thinks it's incredibly bad, please shoot it down.
Let's look at this summary of what AFC is, and what is implicitly coming out of pin 24 on the UPC1883.
My crazy idea is, what if I just clamped this voltage with a zener diode?
It would require getting an oscilloscope to see what the real voltages are, but it seems to me that if I can clip this first giant voltage spike caused by the missing pulse, it should make it much easier and faster for the system to get back to its proper state.
Thoughts?
![Smile :)](./images/smilies/icon_smile.gif)
I recently did the following:
1. Tried replacing the 0.001uf cap with a 0.01uf cap. It only screwed up the picture. Interestingly, leaving it off altogether didn't cause any noticeable effects until I switched the unit in and out of the on-board HD test patterns. After that, the oscillator somehow stretched the 240p image 2x vertically!
2. Tried swapping the 2.2uf cap in the main RC time-constant filter with a 0.22uf cap. Although I was able to push the constant shorter than before, it didn't help much at all.
I'd be happy to try some things with an anti-hunt circuit added to the main filter, except that I don't feel like I really understand how it works or how it's supposed to be implemented.
Instead, I just had a crazy thought, and if someone thinks it's incredibly bad, please shoot it down.
Let's look at this summary of what AFC is, and what is implicitly coming out of pin 24 on the UPC1883.
What this should mean is that when there is an altogether missing pulse, there should be an uncommonly enormous voltage generated at pin 24. It should be far, far greater in size than any voltage developed by a slightly mistimed pulse, or an extra pulse caused by noise. On an oscilloscope, it should show up as a great peak, followed in this case by smaller and smaller peaks as the UPC1883 finds its way back to the proper timing.[AFC] detects the difference in frequency [between the sync pulse and the flyback pulse] and develops a dc output voltage proportional to the difference in frequency between the two input voltages. The dc control voltage indicates whether the oscillator is ‘on’ or ‘off ’ the sync frequency. The greater the difference between the correct sync frequency and the oscillator frequency, larger is the dc control voltage. This dc control voltage is fed to a large time constant filter [at pin 24], the output of which is used to control the oscillator frequency.
My crazy idea is, what if I just clamped this voltage with a zener diode?
It would require getting an oscilloscope to see what the real voltages are, but it seems to me that if I can clip this first giant voltage spike caused by the missing pulse, it should make it much easier and faster for the system to get back to its proper state.
Thoughts?
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
there my test with my multiformat (dt-v1900cg, d20f1,1990r)
http://imgur.com/a/YTTZI
its not help but just a comparison to add.
http://imgur.com/a/YTTZI
its not help but just a comparison to add.
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
here the first reply from french ikegami branch : (Hope the translation is good)
*(Competing monitor are dt-v and bvm-d).
But for my case i already use a gscartsw v3.4 (csync "on"), so still a problem with my french n64 and aes.Information taken, the sync input of the monitor must receive a composite sync signal (csync) and only that. These monitors are initially intended for professional use (broadcast) and therefore to receive the signals used in this type of environment (RGB + S).
Consoles that do not provide a sync signal must go through a sync separator that will remove the video from the composite video signal (CVBS) to keep only the H & V sync (csync).
The *competing monitors that apparently accept the CVBS signals on the sync input must in fact already have a sync separator on that same input.
Again, this conversion is not necessary when working in a professional environment, since a dedicated black burst signal is used.
*(Competing monitor are dt-v and bvm-d).
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
Well, thanks for taking the time to contact them.
The HTM-2050R2 takes composite video as sync with no problem. That's what I use with multiple other consoles, and it works fine. I've also used an LM1881 to change the PCE composite video to CSYNC with no effect on the result.
If I run out of ideas, maybe I'll try contacting NEC about the UPC1883.
----------------------
I've started looking at used oscilloscopes on Yahoo Auctions. In the meantime, it's finally time to try my next experiment.
Since it turned out that using a shorter time constant barely changes anything, my new hope is that I can do something else externally at the UPC1883.
Based on the descriptions of AFC that I've read, it looks like the missing pulse could result in the capacitor at pin 24 getting a relatively large, high voltage charge. My new theory is that it's the release of this charge that's screwing things up. Thus, I'm curious about what will happen if I use a diode, or multiple diodes, to short higher voltages to ground and prevent that charge from building. At its most rudimentary, the new circuit would look like this:
![Image](http://i.imgur.com/THWDXKd.png)
Silicon diodes have a characteristic that they don't turn on and allow current to flow until a certain minimum voltage is reached - typically, this is listed as 0.7V. Low amounts of current can be passed at as little as 0.4V, however, and quite a lot can pass at 0.6V.
The arrangement above should result in <0.4V charges to the capacitor being completely unaffected, and >0.6V charges being completely clipped.
0.4V is not very much, so I'm going to keep a bunch of diodes handy so I can stack them. Two diodes in a row should result in the same thing as above except with the numbers being <0.8V and >1.2V. Three would be <1.2V and >1.8V, etc. By mixing in germanium diodes, which fully conduct at 0.3V, I could adjust in even smaller increments. Also, by putting a resistor between the diodes and ground, I could attenuate the clipping.
Current, at least, should be plenty limited by the 1.2k resistor.
Also, I just learned something important: the voltage at pin 24 might be negative during this missing-pulse area.
Here is another link to a pair of simulated circuits, with the difference being the number of diodes in series. You can easily flip switches and adjust potentiometers to control the attenuation of the wave. In addition, if you edit the voltage level of the source (where it says 20Hz) you can see how the diodes don't do anything to low-voltages.
This is all admittedly a shot in the dark, but for the time being, it seems the most reasonable thing to try to me.
![Smile :)](./images/smilies/icon_smile.gif)
The HTM-2050R2 takes composite video as sync with no problem. That's what I use with multiple other consoles, and it works fine. I've also used an LM1881 to change the PCE composite video to CSYNC with no effect on the result.
If I run out of ideas, maybe I'll try contacting NEC about the UPC1883.
----------------------
I've started looking at used oscilloscopes on Yahoo Auctions. In the meantime, it's finally time to try my next experiment.
Since it turned out that using a shorter time constant barely changes anything, my new hope is that I can do something else externally at the UPC1883.
Based on the descriptions of AFC that I've read, it looks like the missing pulse could result in the capacitor at pin 24 getting a relatively large, high voltage charge. My new theory is that it's the release of this charge that's screwing things up. Thus, I'm curious about what will happen if I use a diode, or multiple diodes, to short higher voltages to ground and prevent that charge from building. At its most rudimentary, the new circuit would look like this:
![Image](http://i.imgur.com/THWDXKd.png)
Silicon diodes have a characteristic that they don't turn on and allow current to flow until a certain minimum voltage is reached - typically, this is listed as 0.7V. Low amounts of current can be passed at as little as 0.4V, however, and quite a lot can pass at 0.6V.
The arrangement above should result in <0.4V charges to the capacitor being completely unaffected, and >0.6V charges being completely clipped.
0.4V is not very much, so I'm going to keep a bunch of diodes handy so I can stack them. Two diodes in a row should result in the same thing as above except with the numbers being <0.8V and >1.2V. Three would be <1.2V and >1.8V, etc. By mixing in germanium diodes, which fully conduct at 0.3V, I could adjust in even smaller increments. Also, by putting a resistor between the diodes and ground, I could attenuate the clipping.
Current, at least, should be plenty limited by the 1.2k resistor.
Also, I just learned something important: the voltage at pin 24 might be negative during this missing-pulse area.
Without an oscilloscope, I have no way of knowing what's really going on with this thing, but the diode solution could still work with a negative voltage. All that's necessary is turning the diodes around.
Here is another link to a pair of simulated circuits, with the difference being the number of diodes in series. You can easily flip switches and adjust potentiometers to control the attenuation of the wave. In addition, if you edit the voltage level of the source (where it says 20Hz) you can see how the diodes don't do anything to low-voltages.
This is all admittedly a shot in the dark, but for the time being, it seems the most reasonable thing to try to me.
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
here the second reply from french ikegami branch : (Hope the translation is good)
I dont have a oscilloscope, maybe there is other method to mesure. itSo if you are already using sync strippers, the csync signals may be out of tolerance for this type of format (Analog RGBS).
It is therefore necessary to measure the RGB and sync signals after the sync strippers (amplitude, duration, stability).
If you do not have an oscilloscope for these measurements, try to get close to a professional video technician, it will be equipped.
It can also test the monitor in analog RGBS with a broadcast signal generator.
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
Apologies if these bumps are excessive.
The diode trick, as I tried it anyway, didn't work. By the end, I had stacked six of the damned things, and even included a 2K resistor between them and ground. This should have allowed at least 2.4V, and probably more like 3.5V, to go in and out of the capacitor unaffected, and only halved the voltage after that, yet it completely screwed up the picture in every case. Even when I tried the Mega Drive, which has a completely stable picture and shouldn't have been in need of much AFC correction, connecting the diodes sent the horizontal hold into complete disarray.
It may be of interest that the AFC voltage was purely positive. Connecting a diode in reverse, which should have affected negative voltages, did absolutely nothing.
I'm still looking for an oscilloscope.
If I had to guess, I'd say that the voltage that is charging the capacitor is constant, and the variable is the amount of time every scanline that it's charging it, depending on the phase difference. With a time constant like 5ms, 9V charging the capacitor through a resistor for even an entire scanline's worth of time (63.5us) would only get the capacitor up to some sub-1V amount.
If I'm right about the charging voltage being constant, then it's probably either 3.5V like the datasheet seems to say, or 9V like what powers the IC itself. Also, any fix would no longer involve limiting the voltage on this line, but rather limiting the charge time. That would be a much more complicated thing. I've got to have a scope to see what's really happening before I start sinking money into parts.
Meanwhile, I did have another idea. The fact is, using Hsync and Vsync from the PCE's internal bus sounds awful, especially since I have a few PCEs I'd like this to work with. I'll do it if I have to, but I'd rather modify the composite video sync if I can. It would make modding and cabling far simpler, and preserve compatibility with my other TVs, too.
It seems to me that getting any pulse in there, even if it's not optimally timed, could roughly fix the problem. My idea involves a simple timer that senses when it's been too long since the last falling edge in the sync signal, and reacts by giving out a pulse that I can mix in with an XOR gate. Things are made complicated by other faults in the PCE's Csync, however, I've done the math, and if I can tune things precisely (i.e. with an oscilloscope) I think that whatever error that would still be in there with a mistimed inserted pulse would still be several times less "off" than what we have now. It's worth a try.
The diode trick, as I tried it anyway, didn't work. By the end, I had stacked six of the damned things, and even included a 2K resistor between them and ground. This should have allowed at least 2.4V, and probably more like 3.5V, to go in and out of the capacitor unaffected, and only halved the voltage after that, yet it completely screwed up the picture in every case. Even when I tried the Mega Drive, which has a completely stable picture and shouldn't have been in need of much AFC correction, connecting the diodes sent the horizontal hold into complete disarray.
It may be of interest that the AFC voltage was purely positive. Connecting a diode in reverse, which should have affected negative voltages, did absolutely nothing.
I'm still looking for an oscilloscope.
If I had to guess, I'd say that the voltage that is charging the capacitor is constant, and the variable is the amount of time every scanline that it's charging it, depending on the phase difference. With a time constant like 5ms, 9V charging the capacitor through a resistor for even an entire scanline's worth of time (63.5us) would only get the capacitor up to some sub-1V amount.
If I'm right about the charging voltage being constant, then it's probably either 3.5V like the datasheet seems to say, or 9V like what powers the IC itself. Also, any fix would no longer involve limiting the voltage on this line, but rather limiting the charge time. That would be a much more complicated thing. I've got to have a scope to see what's really happening before I start sinking money into parts.
Meanwhile, I did have another idea. The fact is, using Hsync and Vsync from the PCE's internal bus sounds awful, especially since I have a few PCEs I'd like this to work with. I'll do it if I have to, but I'd rather modify the composite video sync if I can. It would make modding and cabling far simpler, and preserve compatibility with my other TVs, too.
It seems to me that getting any pulse in there, even if it's not optimally timed, could roughly fix the problem. My idea involves a simple timer that senses when it's been too long since the last falling edge in the sync signal, and reacts by giving out a pulse that I can mix in with an XOR gate. Things are made complicated by other faults in the PCE's Csync, however, I've done the math, and if I can tune things precisely (i.e. with an oscilloscope) I think that whatever error that would still be in there with a mistimed inserted pulse would still be several times less "off" than what we have now. It's worth a try.
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
Bumps are never excessive when you have new findings (of any kind) about a matter that is still relevantSamIAm wrote:Apologies if these bumps are excessive.
![Smile :)](./images/smilies/icon_smile.gif)
Now that your efforts to change the time constant and/or clip the regulating voltage didn't yield positive results, at least it's clear that bending the AFC circuit to one's will is not a trivial matter. I have little to add to the discussion unfortunately. Actually, I now even wonder if the AFC circuit should have any relevance at all in the case at hand. If it "compares the phase of the horizontal sync signal with that of a sample of the horizontal output signal and produces a DC correction voltage proportional to the phasing of the two signals" - just how would that work out with a missing sync pulse? During that timeframe there's nothing in the sync signal with which to drive the horizontal oscillator. There should be no mismatch, and therefore no phase difference to be picked up by the AFC circuit. Either that, or now my understanding on this matter is even worse than before (which is not unlikely)
![Neutral :|](./images/smilies/icon_neutral.gif)
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
Well, I can tell you this: changing the amount of resistance in the lag-lead filter on the AFC pin via potentiometer in real-time causes the distortion to move, so the AFC circuitry is responding to the missing pulse somehow or another.Xer Xian wrote:Bumps are never excessive when you have new findings (of any kind) about a matter that is still relevantSamIAm wrote:Apologies if these bumps are excessive.![]()
Now that your efforts to change the time constant and/or clip the regulating voltage didn't yield positive results, at least it's clear that bending the AFC circuit to one's will is not a trivial matter. I have little to add to the discussion unfortunately. Actually, I now even wonder if the AFC circuit should have any relevance at all in the case at hand. If it "compares the phase of the horizontal sync signal with that of a sample of the horizontal output signal and produces a DC correction voltage proportional to the phasing of the two signals" - just how would that work out with a missing sync pulse? During that timeframe there's nothing in the sync signal with which to drive the horizontal oscillator. There should be no mismatch, and therefore no phase difference to be picked up by the AFC circuit. Either that, or now my understanding on this matter is even worse than before (which is not unlikely)
My impression is that the incoming sync pulse is compared with a sawtooth wave that is the result of previous sync pulses.
![Image](http://i.imgur.com/IGCqx4d.png)
This is from just one of the circuit examples in the "Monochrome and Colour Television" book, but every AFC circuit does seem to compare to sawtooth waves.
What happens when there is no pulse? I honestly have no idea. Does the sawtooth wave sink or rise to an extreme and cause an enormous control voltage on the next pulse? Does it settle at zero and take a while to build up again? Without an oscilloscope, I just can't say. I've been assuming the former, but maybe it's the latter, or something else entirely. Yesterday, I tried something just for the heck of it: I stacked as many diodes as I could to see if there wasn't an intermediate area between total disarray and no effect at all. The result, which was visible 11 diodes in, was that the skewing gets worse, not better, with voltage clipping.
A used oscilloscope is coming in the mail next week. Here's hoping it works!
In the meantime, I'm going to go back to trying to either get correct sync from the PCE's internal bus, or to sneak a pulse into the existing composite video sync signal. I'm simply out of ideas for modding the monitor itself.
--------------------
EDIT: So here is why getting a good signal from the console instead of modding the monitor is a pain. Again, this sync info comes from viletim, who was very gracious and thorough when I asked about the PCE's trouble with HTM-2050R2s a long time ago and had no clue where to even begin.
![Image](http://i.imgur.com/TgIoA4f.jpg)
In this image, you'll count four falling Hsync pulse edges in the first line. That's what we want. In the Csync line at the bottom, you'll count only three falling edges in the same time interval, with the missing edge being the last one. It should look like one last serration pulse.
The Japanese fellow who created this mod that takes sync from the internal Hsync and Vsync digital signals was working with a JVC DT-V1910C. The big difference between that monitor and the Ikegamis is that it has separate inputs for Hsync and Vsync. Why is this important? Well, imagine that you're feeding these Hsync and Vsync pulses into an XNOR gate to combine them.
![Image](http://i.imgur.com/2a6mMT9.png)
When you do this, all of the Hsync pulses before Vsync come through just fine, and the serration pulses during Vsync are inverted like they should be. However, look at how the beginning and end of Vsync line up with Hsync. At the end, the XNOR gate restores our missing pulse, even if it's going to be thin...however, it also adds one at the beginning because the Vsync edge doesn't line up with Hsync. Thus, trying to combine these signals with a simple logic gate is basically going to give us five pulses instead of four, and give us a fun new kind of warping to look at.
The circuit the Japanese fellow created involves two 74HC123 IC's for a grand total of four one-shot monostable multivibrators. He did this so he could put both signals through two phases: the first simply delays the two syncs, presumably to help to picture line up on the screen like it should, and then the second redefines the widths of each pulse. This is especially important for the Hsync line, since the digital pulses are about 11us wide while the broadcast standard is apparently 4.7us (and that's what the Csync widths are).
In short, it ought to be possible to finely adjust the delay phase so that the start of the Vsync pulse lines up like it should. Maybe adding something like a lowpass filter would help make sure that no really thin spikes make it into the final signal. But dang, it's all a pain.
The one hope for a fast cure is that Extrons might be built to combine H/V sync in a smart enough way that they don't create any new pulses. This is the next thing I'm going to try.
Meanwhile, there is the other option, which is to try to get another pulse into the existing Csync line. My idea for this also involves a 74HC123, and a simple timer circuit that gets it to fire into an XNOR gate whenever too much time has gone by since a falling edge.
However...there is always a however...the PCE's Csync is really weird. The falling edge at the start of the Vsync pulse is 4.7us late, as is the rising edge at the end. If we're going to sneak an extra pulse in there after the end, it's not going to have the right timing. Granted, just having something is probably way better than having nothing, but there might still be some skew leftover. If I use an EL1883 to split off the Hsync pulses, re-time the Vsync pulse entirely and XNOR them back together, it might turn out a little better, but sheesh.
Today, the game store I like to go to had a beat up white PCE with a Tennokoe 2 for a very decent price. It will make a much better guinea-pig than a Supergrafx, that's for sure. I hate that this might be what I have to do, but I'm going to finally focus on using the digital H/V syncs to make this work.
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
![Image](http://i.imgur.com/wlBQGwT.jpg)
This is the internal H/V sync lines going directly from the PCE's expansion connector into an Extron 202 Plus, and the single Csync line from that going directly to the Ikegami. Don't ask why it's in black and white, because it's a long, boring story.
You'll notice that there is still some skew up at the top. I don't know what's causing it, but astonishingly, if I adjust the picture's vertical position downward on the Extron and then back up on the monitor, I can essentially put the skew in the Vblank area and get around it. Maybe the Extron is still doing something funny like causing an extra pulse when the Vsync signal from the PCE goes low. Killing the serration pulses and/or changing the Vsync width didn't help, but I'm really keen to see if using a newer unit with all the fancy digital processing will. I think it's time to see whether my 304 is going to blow up if I don't give it exactly the same weird voltage that the dead power supply used to.
Regardless, this all makes me believe that using two 74HC123s to get the pulse-lengths and timings just right will work. If this solution is compatible with all of my TVs, then that's what I'll go with instead of the Extron. I'll mix the syncs together with an XNOR gate and replace the composite-video-sync in my RGB cables with the output from that.
It takes a relatively big board to fit three ICs, three potentiometers, two resistors, about eight ceramic caps and tons of wire. It will be tough to squeeze everything inside of a system. If I get the test-board I'm putting together now to work, I'll see if I can design a smaller version that's still easy to solder together.
It appears that the H/V syncs from the console are a full 5Vp-p, unlike the Csync line which is apparently much less. Even when using the TTL input on the Extron, it might be wise to put some extra resistors in series to limit the current. I have some extra potentiometers sitting around, so I'll see what the highest resistance I can get in there is in case someone else wants to use this solution.
Side question: When using external sync, how on earth would adjusting the horizontal position at the Extron cause the brightness to change? That's what I'm seeing. I'll have to try it with my other sets.
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
![Image](http://i.imgur.com/EJXHavh.jpg)
There we go. This is the internal H/V sync going to an Extron SS 200. The color signal is connected directly to the monitor. Again, the black-and-white is a long story and basically won't happen to anyone but me.
The Extron SS 200 works fine with 15khz. Strangely, this document says it can do 15khz even though this one doesn't. Let it be known that it can indeed do it.
A few notes:
- According to my multimeter, the SS 200 draws 6.5mA from the console via the Hsync line with 510 ohm termination enabled, and 13mA with 75 ohm termination enabled. On this and any Extron that has the option, I'd recommend to make sure you set it to 510 ohms if you are running these internal signals directly to the unit. While 13mA isn't too terrible, it's still going to generate more heat and potentially lead to damage.
- I found that both sync lines can handle about 800 ohms added in series to the SS 200 without losing the picture. I have some leftover 680 ohm resistors from another project, so I'm going to stick those in there. That's high enough that even if I accidentally ground one of the lines, I won't draw more than 7.35mA. As above, I'd recommend putting in series resistors to anyone using these signals.
- Meanwhile, these same lines drew a mere 0.4mA on my Extron 202 Plus at the TTL port, and they were OK with 5k of in-series added resistance, too. I never found a way to get rid of the distortion, though.
- In other, slightly related news, the 202 Plus has a 7805 regulator built into it, and I used that to add an internal LM1881. Now I can just feed this thing sync from whatever and it will be a snap to adjust the picture position.
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
So did you managed to fix the issue then?
From what I am seeing is that the only way to get proper geometry on the Ikegami for consoles such as the PC Engine is to pass the output through a processor, is that it?
From what I am seeing is that the only way to get proper geometry on the Ikegami for consoles such as the PC Engine is to pass the output through a processor, is that it?
Why is the NO BURST led on?SamIAm wrote:
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
In so far as that I can play the PC Engine on this Ikegami, yes.Lawfer wrote:So did you managed to fix the issue then?
My initial aim in this thread - to modify an Ikegami to make it more flexible with imperfect sync - didn't work out. At this point, I don't expect to find a solution, although I will at least look into things a little bit further when my oscilloscope arrives.
Sort of.From what I am seeing is that the only way to get proper geometry on the Ikegami for consoles such as the PC Engine is to pass the output through a processor, is that it?
To get the PC Engine displaying properly on an Ikegami monitor, the important thing isn't so much to use an external converter as it is to use the PCE's internal Hsync and Vsync lines, since those are still pure and properly timed. Granted, in order to use them, you basically need to pass them though something in order to mix them properly. Also, even if you have something like a DT-V monitor with separate H/V sync inputs, you would draw too much current and damage the PCE if you connected those internal lines directly to a monitor input terminated with 75 ohms. If you just took off the terminators, it might be OK, but I'd check with a multimeter before settling on that solution.
The Extron solution is external and, with all of the extra wiring it needs, not very convenient. It is probably possible to mix the internal H/V sync and output them as Csync via a board installed internally. Since I bought all the parts already, I would like to try that.
Keep in mind that most consoles work just fine with unmodified composite video being fed into the Ikegami's ext. sync input. My Mega Drive, Saturn, Neo Geo CMVS, PS1 and 2, and MSX all display without any flaws. The SFC has a bit of jitter at the top, but it's quite playable. By the way, I found out why the jitter exists. This is byuu, of Higan/BSNES fame, talking about the number of 21MHz master clock cycles in a scanline:
In order to fix this, we basically need to regenerate the sync entirely. I'm actually looking into the possibility of using an Arduino for this.All scanlines are 1364 cycles long, with one exception:
NTSC-only with interlace off on scanline 240 on an odd field ($213f.d7=1) is only 1360 clock cycles. It has something to do with the NTSC color burst, I don't know exactly, but it really is short, crazy as it sounds.
Well spotted!Why is the NO BURST led on?
In short, the picture itself is being provided by composite video. However, my Ikegami's composite video card is damaged. It doesn't show color, and it causes the no-burst lamp to light up.
This is essentially why the pictures I've posted recently have been black-and-white.
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
As promised, here are some oscilloscope shots of pin 24 of the UPC1883.
This is what it looks like both when there is no signal going to the monitor at all and when there is a stable system like the Mega Drive connected.
![Image](https://i.imgur.com/xoZjJbm.jpg)
This is what it looks like with the PCE connected with its flawed composite sync.
![Image](https://i.imgur.com/SoVbMqd.jpg)
The most surprising thing about this is the voltage level. The largest p-p differential is only about 270mV. How it was that six stacked diodes connected to ground were able to conduct any of this is beyond me. Anyway, the crucial thing to note is that there is no single enormous spike that we could clip off to try to bring things back into order. We might be successful at clipping those smaller spikes and improving things somewhat, but I have to say that I'm very skeptical that this would lead to a result that's actually preferable to using the PCE's internal HV syncs. As you can see in the post above, those give a pretty flawless result.
Another interesting this is that these readings were all taken directly at pin 24. Putting the probe between the resistor and the capacitor in the lag-lead filter didn't give me any results. Perhaps that's only because I'm still figuring out how to use this oscilloscope, but anyway, that diode-clipper idea I had before might work better if I connect the diodes on the other side of the resistor. Maybe I'll try that someday. For now, however, I think I'm going to with the PCE-internal-sync solution and call this done.
It also appears that an Extron might work as a sole solution for rectifying the composite video sync after all. I've been PMing with HiroWorship about it for a while, and his Extron 160xi might be able to do it without leaving any distortion behind. He just has to do a grid-pattern test to confirm. My old 202 Plus doesn't fix it by a long shot, unfortunately.
This is what it looks like both when there is no signal going to the monitor at all and when there is a stable system like the Mega Drive connected.
![Image](https://i.imgur.com/xoZjJbm.jpg)
This is what it looks like with the PCE connected with its flawed composite sync.
![Image](https://i.imgur.com/SoVbMqd.jpg)
The most surprising thing about this is the voltage level. The largest p-p differential is only about 270mV. How it was that six stacked diodes connected to ground were able to conduct any of this is beyond me. Anyway, the crucial thing to note is that there is no single enormous spike that we could clip off to try to bring things back into order. We might be successful at clipping those smaller spikes and improving things somewhat, but I have to say that I'm very skeptical that this would lead to a result that's actually preferable to using the PCE's internal HV syncs. As you can see in the post above, those give a pretty flawless result.
Another interesting this is that these readings were all taken directly at pin 24. Putting the probe between the resistor and the capacitor in the lag-lead filter didn't give me any results. Perhaps that's only because I'm still figuring out how to use this oscilloscope, but anyway, that diode-clipper idea I had before might work better if I connect the diodes on the other side of the resistor. Maybe I'll try that someday. For now, however, I think I'm going to with the PCE-internal-sync solution and call this done.
It also appears that an Extron might work as a sole solution for rectifying the composite video sync after all. I've been PMing with HiroWorship about it for a while, and his Extron 160xi might be able to do it without leaving any distortion behind. He just has to do a grid-pattern test to confirm. My old 202 Plus doesn't fix it by a long shot, unfortunately.
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
hi guys !
I have exactly the same problem with my ikegami HTM1990R.
I'm french and i'm not a pro in electronic, but i have tried to solve that with success for my nintendo 64 with RGB mod.
but the pc engine has always a little wave:
https://www.youtube.com/watch?v=A-iab4ANM-Q
i have the service manual for my monitor but it's really hard to understand something inside this web of component.
my solution is just using an arduino with interrupts for recreating the missing pulse in the composite sync.
but when i see the wave, i RLC attenuated oscillation, and if i try to read the end of this topic, it's also your result.
but i'm not a boss in english for enderstanding all of your explications...
is it possible thaht someone make me a resume with simple words ?
do you have found a solution for this wave ?
why this problem is seen on neogoe/n64/pce but not on other consoles ?
I have exactly the same problem with my ikegami HTM1990R.
I'm french and i'm not a pro in electronic, but i have tried to solve that with success for my nintendo 64 with RGB mod.
but the pc engine has always a little wave:
https://www.youtube.com/watch?v=A-iab4ANM-Q
i have the service manual for my monitor but it's really hard to understand something inside this web of component.
my solution is just using an arduino with interrupts for recreating the missing pulse in the composite sync.
but when i see the wave, i RLC attenuated oscillation, and if i try to read the end of this topic, it's also your result.
but i'm not a boss in english for enderstanding all of your explications...
is it possible thaht someone make me a resume with simple words ?
do you have found a solution for this wave ?
why this problem is seen on neogoe/n64/pce but not on other consoles ?
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
Buyed a ossc 1,6 and make some test.
Passing through the OSSC 240p signal to 1990R the n64 is now stable signal and neogeo is also normal, but still very small wave at top and less pronounced without csync.
https://imgur.com/a/HnGjx
Passing through the OSSC 240p signal to 1990R the n64 is now stable signal and neogeo is also normal, but still very small wave at top and less pronounced without csync.
https://imgur.com/a/HnGjx
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
Does that mean that a Csync RGB Scart cable directly to monitor might have the same results ie removing most of the problem?
Re: Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted
Since this is back from the dead, let it be known: An Extron 160xi with serration-pulse-removal enabled can take sync stripped directly from the PCE's composite video via LM1881 and output a signal that will result in a normal, accurate picture on an HTM-2050R2.
Note that an Extron SS 200 will not do this despite having the same setting. There is something unique about the way the 160xi is processing the sync. Exactly which Extrons can fix the problem and which ones can't is currently anyone's guess.
If your PCE's picture skews on your monitor, you have three choices:
1. Feed the internal H/V syncs into an Extron.
2. Build that Japanese fellow's circuit to re-shape and re-time the internal H/V syncs, combining them if your monitor doesn't have separate H/V sync inputs.
3. Get a very particular model of Extron and an LM1881.
In the end, I went with #3 because it was non-invasive and I was able to pick up two 160xi units for cheap. 160xi's even have a +5V power rail, so I was able to install the LM1881 internally and have an RCA cable running out of it to hook up the PCE's composite video.
Note that an Extron SS 200 will not do this despite having the same setting. There is something unique about the way the 160xi is processing the sync. Exactly which Extrons can fix the problem and which ones can't is currently anyone's guess.
If your PCE's picture skews on your monitor, you have three choices:
1. Feed the internal H/V syncs into an Extron.
2. Build that Japanese fellow's circuit to re-shape and re-time the internal H/V syncs, combining them if your monitor doesn't have separate H/V sync inputs.
3. Get a very particular model of Extron and an LM1881.
In the end, I went with #3 because it was non-invasive and I was able to pick up two 160xi units for cheap. 160xi's even have a +5V power rail, so I was able to install the LM1881 internally and have an RCA cable running out of it to hook up the PCE's composite video.