Wonky sync, AFC, and an Ikegami HTM-2050R2: Help wanted

[SamIAm]

I've written up an intro in case anyone wants to know why I want to do this thing I'm asking for help with.

Skip down to the bolded part to get to the real question.





I've got one of these things, and it's gorgeous. It's one of Ikegami's last CRT studio master monitors, and it was made very well.

The only trouble is, like the BVM-A series, it gets caught up on imperfect sync timings. Enter the PC Engine's sync signals, courtesy of viletim:





We've got digital Hsync, Vsync and Csync, the last of which is ready to get mixed into the composite video signal, where it will come out looking roughly the same.

Here is the key thing: while you'll count seven falling edges on the Hsync line, you'll only count six corresponding falling edges on the Csync line. The PC Engine is missing one H-sync pulse in its Csync and composite video signals. It's getting lost when the Vsync pulse ends. This is all even easier to see if you look at the output of an LM1883 that's splitting all the syncs off of a composite video signal (red=Csync, orange=Vsync, yellow=Hsync):





The loss of this pulse throws the Ikegami's horizontal sync oscillator all out of whack, and the top third of the picture winds up being skewed like it's in a funhouse-mirror.

But why doesn't this happen on consumer TVs?

It's because consumer TVs are built to deal with wonky sync timings, and the thing they deploy for it is called AFC, or automatic frequency control. There is not a whole lot of information out there about exactly how this works in televisions in particular, and I'm certainly no expert, but it appears that AFC effectively keeps track of where the sync timing should be based on where it's been recently, and it feeds the CRT's horizontal oscillator a separate pulse in addition to the one that it's getting (or in this case, not getting) at that moment from the main video signal.

What's interesting is that there seem to be different "speeds" of AFC. I really wish I knew more about what's going on with this. I have a BVM-2015 that has an AFC switch with 7ms/2ms/0.5ms settings. On 7ms, it screws up with the PC Engine, but on 0.5ms, it works just fine. Sadly, my Ikegami HTM-2050R2 doesn't have a switch like this. For the longest time, I just assumed it didn't have AFC at all.
(Edited)

Then, one day, I managed to get my hands on the HTM-2050R service manual and saw this on the deflection card block diagram:





Whoa!

But frustratingly, when I opened up the system, I didn't see a switch. Looking closely at the schematics page, I discovered that it seems to all be automatic.


If you skipped the lengthy intro, here is the real question.


I could be completely wrong about how all of this is working, but I would like to try to force the various AFC modes...or rather, to turn off the undesirable ones...in this Ikegami monitor to make it less fussy about console sync signals. I suspect that the system is simply not allowing itself to select the right mode.

AFC fast, normal, and slow all come out of an NJU3718. Where exactly they are born before that, I'm not sure. Each one travels into a separate 2SC3398 transistor, and from there, into a single 4053B multiplexer. From there, a signal is sent to the main oscillator, a UPC1883. In the schematics, these are all spread out, so I made up an image in paint with the circuit lines added. There are no additional components in between.





The function of the 4053B seems critical to understand. It's difficult for me, but looking at the datasheet, I think that it's not so much "selecting" so much as it's sending something to the UPC1883 anytime it gets a pulse from any of the three AFC speeds.





So, I might be barking up the wrong tree entirely, but I'd like to try poking at this. Based on what works with the BVM, it seems I should isolate the "fast" AFC by disabling the "slow", and possibly the "normal" speed as well. If that doesn't work, I'd like to try isolating the others. How can I do this? I have some ideas, but I'm not confident.
(Edited)

Cutting circuit traces might work, but I'd rather not abuse the PCB that much. Taking out resistors 268/270/272 would break each of those lines, and it wouldn't be that arduous take those out and put them back in...but is that really the best place to cut the signals?

Also, rather than cut them, could I just ground them somewhere, even just for a short test, or would that be a fantastically bad idea? It looks like shorting the signal after it goes through the transistor would affect more than just the AFC line, but how about before it? The NJU3718 datasheet seems to indicate that it can tolerate one, and no more than one, output pin being shorted.

I really wanted to bounce this off someone before embarking on this crazy endeavor. Please let me know if you have any thoughts.

Thank you!

[Xer Xian]

I don't know enough about modding to help you, but I definitely think you're onto something interesting here so I did a small research about this AFC stuff. Most of it is way over my head though so you'd probably be better off reading the quoted parts more than my comments ^_^

As you already explained, the Automatic Frequency Control is a part of the TV horizontal deflection circuit that is meant to filter out noise so as to sync the horizontal oscillator frequencies to the (actual) horizontal sync pulses (I had to upload ugly screen grabs because Google Books doesn't let me copy any of the content):





But why only the horizontal sync is affected? The AFC is not necessary for vertical deflection because the vertical sync circuitry operates at lower frequencies, so in this case it’s possible to add a low pass filter that suppresses noise pulses:





Still, it's not exactly clear to me why the AFC 'gets it right' on consumer TVs but fails on pro-monitors, and also why some of these allow to select between AFC modes with different "time constants"? May the latter refer to the length of the samples of horizontal oscillators' frequencies that are taken to be compared with the actual sync pulses? If that's the case, I don't see how changing the time length can have a bearing on the end result. Moreover, at least in the case at hand there's no noise interference to be filtered out but actually a missing sync pulse to be added in at regular intervals, and going by the previous descriptions of how the AFC operates, it's difficult to figure out how it could play a role (at least for me). I found out that the AFC also goes under the name of 'flywheel synchronization', and I bumped into this definition:

Automatic frequency control of a scanning system by using the average timing of the incoming sync signals, rather than by making each pulse trigger the scanning circuit; used in high-sensitivity television receivers designed for fringe-area reception, when noise pulses might otherwise trigger the sweep circuit prematurely.

Now, I don't know if this is a particular implementation of AFC or if it's just another wording of the same stuff above and I'm just dumb, but if the sync regularization was carried out by averaging the sync timings over a given interval then I can see how it would make a difference in our case - the missing sync pulse would be averaged out, provided that the time interval for averaging is large enough. This would explain why selecting the slower 7ms setting solves the sync problem of the PCE.

But if that's the case, then why the AFC time constant setting (which was once included even on 9” CRTs: see page 5 of this manual) was at some point taken out? But.. why was it even there to begin with really? After all, the AFC circuit was introduced to filter out noise interference and pro monitors weren't meant to receive broadcast TV (they don't even have a TV tuner). A very likely explanation is to allow for better video-tape reproduction - it turns out that VCRs tended to produce recordings with wonky horizontal sync as well:





This is also reinforced by the brief description of the AFC setting I've found on some CRT manuals (for example see here) and also by the fact that some BVM's have a setting that solves most horizontal skew issues that is called 'VCR Mode' - most likely nothing else than a different (slower) AFC time constant setting. Apparently this used to be an issue important enough as to warrant marketing of dedicated hardware to address it, such as this one. As for why the AFC setting was taken out on later pro CRT monitors.. it's just a guess but probably VCR/video-tape use was no longer widespread when the last monitors were being sold, and the manufacturers just left the faster AFC setting as standard.

I'm sorry that after this little wall of text I haven't helped you one bit, but at least it served as a free bump

[SamIAm]

Wow, thanks a lot! There is some very good stuff in there!

Averaging would certainly explain why the longer time constant setting on the BVM gives better results. That's a valuable find indeed.

I was looking at this book yesterday. It explains the same thing about how AFC is originally intended for noise. Of course, the fact that VCR Mode is the same thing makes perfect sense.


EDIT: I take it back, I think the smart thing to do is to just sever the line, not short it. Comparatively, it's a bigger pain in the rear, but it's the only thing that I think is both safe and effective.


Anyway, thanks again, Xer Xian. I'll update the thread with results, hopefully soon!

[SamIAm]

Sorry! Meant to edit, wound up replying.

Since I bumped this anyway, I'll try to add something: the reason why shorting the signal from the NJU3718 is a bad idea is that A) the infinite current draw could damage the part, and B) the signal might make it through anyway, especially if I put some kind of current-limiting resistor on line that's causing the short.

[SamIAm]

First of all, I was misremembering something: it turns out that it was the faster 0.5ms setting on the BVM that gave a better result, not the slower 7ms one.

I actually have another monitor with a slow/fast AFC switch, and it's the same there: the fast setting gives the better picture. Sorry about all of that. I wasn't home when I wrote the above posts.

-----------------

So, what I did yesterday was to remove the resistors between the 2SC3398 transistors and the 4053B on the slow and normal AFC lines. It didn't work. The horizontal sync became massively screwed up, and the usual high-pitched CRT whine became a lot louder for some reason. Here's hoping that I didn't damage anything.

I could try restoring the normal line first and leave out the slow one, but given the reaction I got with the fast line only, that probably won't work either. Without cutting traces or lifting IC legs, the only other thing I can see is to take out resistors 274/276/278, which sit between the output of the 4053B and the UPC1883. I'm not optimistic and may not even bother.

I really wish I had an oscilloscope...

For now, I think I'll go back to trying this mod to turn the PC Engine's H and V sync digital pulses into something more usable for a CRT receiver.

I anyone has any comments, fire away. Otherwise, I probably won't update this again unless I go through with more experiments.

Thanks again to Xer Xian for his help.

[Xer Xian]

No problem, I just connected a few dots in a way that made sense, but still it was pure speculation - and in fact the 'sync-through-averaging' hypothesis turned out to be wrong.. I wish someone who actually knows about this stuff would chime in, but anyway, considering your last finding, if the AFC does play a role on this (I still think so) what's actually required to improve the sync is taking samples from the hor.deflection drive more frequently.. reducing the granularity helps detect small anomalies I guess.

Above all anyway, it's a bit of a shame that you couldn't get it to sync after restoring the fast and normal lines - dumb question, but I guess you tried removing one resistor only each time (so as to only restore one line), right?

[lewolfeur]

Thx for all these information that must the same problem on my 1990r with french n64 rgb.
http://imgur.com/a/kCCHp

[Xer Xian]

Just for reference, here's the retroRGB webpage about this issue on the BVM A-series. He solved the SMS skew issue by feeding the vga out from a gscartsw into an Extron RGB 580xi and then setting it to output composite sync - no idea if that could work with the PCE. He also considers VCR Mode to be nothing else than AFC, but he says nothing about the different AFC time constant settings.

Thx for all these information that must the same problem on my 1990r with french n64 rgb.
http://imgur.com/a/kCCHp

Well this is not just a skew issue, the sync is all over the place in those pictures. User hyrulebr has the same monitor, you may consider dropping him a message to ask if he has that issue with the N64 as well (I think Brazil adopted the PAL standard as well).

[HiroWorship]

SamIAm, it kills me that I didn't see this earlier before you started removing components from your Ikegami, but as they say, better late than never...

To cut to the chase I think we should chat because I bet we could assist each other in doing various types of experiments like this.
I live in Tokyo and I also own an HTM-2050R, as well as a perfectly functioning BVM-2011 w/ AFC that I've used to vet many sync experiments.
I also have 2 Extron RGB interfaces to help with problems like this, one of which I would be happy to lend you.
I'm working on several projects involving getting sync working with Japanese analog broadcast equipment.

Feel free to continue the conversation here, or if we want to take it to a wider scope, feel free to PM me.
It will be good to have someone locally to trade ideas with.

[SamIAm]

I think I've understood something that I wasn't before.



The NJU3718 is a sending the AFC signal as a digital pulse - it's either 5V or 0V, roughly. When the high 5V hits the 2SC339B transistor, it opens...but it's not sending current. Rather, it's allowing current to drain to ground.

Pins 9, 10 and 11 on the 4053B are where the AFC signal goes in, but the actual power for this is coming from that long horizontal line you see on the upper right. Sadly, the schematic cuts this off, and I get the feeling it's not just a simple power rail, but that's OK (edit: Nope! Just a plain 9V power rail!). The point is that pins 9, 10 and 11 sit between two resistors, and if I'm correct, these function like a voltage divider when the transistor is allowing the current to pass through to ground. It follows that it's when the voltage is being divided that these inputs are low, and when it's not being divided that they're high. Here's a simulated circuit that shows what I mean.

Therefore, by cutting out resistors 268, 270 and 272, I force the 4053B to output a constant high instead of a constant low. Also, in order to force the 4053B to output a constant low, I could (theoretically) restore the resistors I cut out, but put the leg that was going to the transistor directly to ground instead.

Whether I do any of this, we'll see. I still haven't had the time at home to put the resistors back as they were and make sure I didn't do any harm with the last experiment.

----------------------

SamIAm, it kills me that I didn't see this earlier before you started removing components from your Ikegami, but as they say, better late than never...

To cut to the chase I think we should chat because I bet we could assist each other in doing various types of experiments like this.
I live in Tokyo and I also own an HTM-2050R, as well as a perfectly functioning BVM-2011 w/ AFC that I've used to vet many sync experiments.
I also have 2 Extron RGB interfaces to help with problems like this, one of which I would be happy to lend you.
I'm working on several projects involving getting sync working with Japanese analog broadcast equipment.

Feel free to continue the conversation here, or if we want to take it to a wider scope, feel free to PM me.
It will be good to have someone locally to trade ideas with.

I just saw your post in the middle of writing this update.

Sure! I'd love to chat. There can't be too many of us trying to make this stuff work.

What Extron are you using? Have you gotten PC Engine video to display properly on your Ikegami before?

I bought an SS 200, and it didn't seem to do a damn thing. The PC Engine had the exact same warping as it did before. I actually have another Extron, but I haven't gotten around to making a custom D-sub 9 pin cable for it.

(And I have one more in addition to that, but the internal power supply is fried and the voltages are really custom and weird, so I can't just use some random wall-wart and a couple of off-the-shelf linear regulators to replace it.)

Oh, one more thing...is yours a 2050R or a 2050R2? I think the differences are extremely minor, but one of them might be that they took ought the 480p enable switch in the R2. Mine doesn't have it.

[HiroWorship]

I just saw your post in the middle of writing this update.

Ironic that I've been looking into getting active on this board again and I run in to your post right in the middle of your big adventure...
No better time than the present, though!
I love how much information the guys on this forum share with all of us and it's high time I started making some contributions where I can.

I’m using 2 Extron RGB 160xi units. I don’t have any experience with the SS 200 (or the Sync Stabilizer units in general) but looking at the specification sheet it appears to only support horizontal frequencies of 30 kHz and above so that might be the issue. The RGB interfaces (including the 160xi) go down to 15 kHz so no problem supporting a 240p signal there.
The 160xi uses a standard DE-15 d-sub VGA connector for the input and BNCs for the output so it’s relatively easy to integrate into an analog setup. It can also split or combine sync (RGBHV to RGBs in both directions) as needed and can output sync-on-green; all of this is very helpful in troubleshooting sync on our monitors (as the 2050R supports RGsB just like most Sony pro monitors).

What you are seeing when using an RGB-modded PC Engine on the 2050R is flagging at the top of the image (and you have already shown exactly what causes this - in fact, your knowledge of the signal analysis and engineering aspects of this issue is well above my own and I am truly impressed). My personal theory is that the multiformat monitors that arrived at the tail end of the pro CRT era, such as our Ikegami 2050Rs, the JVC DT-Vs, and the BVM A-series, no longer required the ability to handle wide variances and inaccuracies in the sync signal as the majority of the broadcast video production pipeline had moved to digital by that point, and most if not all of this era of monitors were sold with HD-SDI input cards and the anecdotal evidence I have gathered from broadcast engineers suggests that the analog inputs were rarely used. Since HD-SDI doesn’t concern itself with such variances in sync, those features were removed from these monitors (again, an educated guess). I’ve looped a 480i signal that has flagging in the image on the 2050R into my BVM-2011 (an analog chassis model that seems to deal well with just about any sync that’s thrown at it) and the BVM was fine, no adjustments needed.
I believe the AFC (or “VCR mode”) was removed from these later monitors for the same reason as above: studios (at least in Japan) had completed the transition to Betacam digital tapes by that point and didn’t need to compensate for (or observe, in case of the “slow” setting) analog video tape jitter using AFC.

So with that in mind, getting back to your question - can the 2050R display a signal from an RGB-modded PG Engine without flagging using an Extron RGB interface? With a pretty high degree of certainty I believe the answer to be “yes.”

I can confirm that I observe flagging in the image from my own RGB-modded PC Engine (Duo RX) on the 2050R.
I have not actually been able to test the PCE through the Extron as I can currently only obtain sync over composite video from the PCE and the Extron needs RGBs to function properly. I haven’t had time to construct a sync separation circuit for it at this time.
However, the reason that I am reasonably confident that this will work is I have experimented with the Dreamcast outputting 480i from a TORO VGA box and was able to correct the same issue on the Dreamcast output.
The TORO 480i output in RGBs directly to the 2050R caused the same flagging issue as observed with the PCE.
However, when taking the TORO output (both RGBHV and RGBs) into the Extron RGB 160xi and then output to the 2050R (tested with both RGBs and RGsB just in case), I was able to correct the issue.

The RGB interfaces have a DIP switch marked “SERR” that controls serration pulses and this switch can fix the flagging issue. The Extron RGB interface manual says to set the SERR switch to off to remove serration pulses if flagging in the image is present; somewhat counter-intuitively one must actually set the switch to on to fix the flagging issue on the 2050R. I assume that the Extron digital sync signal processing corrects the flaws in the sync signal and sends correct serration pulses to the monitor in this case.

Once I am able to obtain RGBs from the PCE I will repeat the experiment and let you know if it works but I believe the cause to be similar and thus I am relatively confident that the same fix will work. (RetroRGB used a similar fix for the BVM-A with the Master System’s equally wonky sync signal).

To answer your final question, yes I have the 2050R2 (type 2) unit. I can’t find any evidence that the HTM-2050R (without the 2) was ever sold in Japan as all I see are the 2050R2 units (although the front panel says “HTM-2050R”).
I too was influenced by the Reddit thread about enabling 480p using DIP switches on the remote control board and I bought the monitor thinking I could get it to display 480p, but alas, as with you I could not get it to work.
In fact one of the questions I originally wanted to ask you was if you had better luck!
I was able to convert my unit from a “Type 2” unit (240p/480i/1080i) to a “Type 1” configuration (240p/480i/1080i/720p) using the DIP switch trick. This leads me to believe that there may still be a way to get 480p to work as I have not been able to try all of the DIP switch combinations. Have you played with any more of them?
(BTW to enable 720p enable switch #4)

[Lawfer]

HTM-2050R2

I know of the HTM-2050R, but never heard of the R2 variant? Does that model even exist? If so, what are the differences?

[lewolfeur]

Just for reference, here's the retroRGB webpage about this issue on the BVM A-series. He solved the SMS skew issue by feeding the vga out from a gscartsw into an Extron RGB 580xi and then setting it to output composite sync - no idea if that could work with the PCE. He also considers VCR Mode to be nothing else than AFC, but he says nothing about the different AFC time constant settings.

Thx for all these information that must the same problem on my 1990r with french n64 rgb.
http://imgur.com/a/kCCHp

Well this is not just a skew issue, the sync is all over the place in those pictures. User hyrulebr has the same monitor, you may consider dropping him a message to ask if he has that issue with the N64 as well (I think Brazil adopted the PAL standard as well).

He not have a rgb modded 64.
Also for 64 some game works, some half and other have problem. seem that some resolution work and other not.
https://www.youtube.com/watch?v=Z_YLnwS ... e=youtu.be

For Neogeo AES
http://imgur.com/a/MVyZ0

I sure all Ikegami htm model released after 2050 have the same issue with sync.

[Lawfer]

Also for 64 some game works, some half and other have problem. seem that some resolution work and other not.
https://www.youtube.com/watch?v=Z_YLnwS ... e=youtu.be

Woah, what's happening there? Looks kinda like what happens when you want to output RGB without enabling EXT SYNC, except way worse.

[lewolfeur]

after the logo perfect dark the game switching resolution 288p to 576i or the opposite.

[Lawfer]

after the logo perfect dark the game switching resolution 288p to 576i or the opposite.

It might be that it can't sync to 288p?

[Dochartaigh]

Most (ok, all of this is a bit over my head, but I wanted to chime in with my own sync issues related to AFC and BVM-like monitors.

My problems are mostly with the Pi2SCART board for a Raspberry Pi 3 - this common RGB outputting device must likewise be missing a "horizontal slices in the vertical sync block" as the RetroRGB page says. I've put about 10 hours into researching this so far...here's my personal experiences (with some recent friends and forum-members input....it basically all comes down to that elusive VCR Mode/AFC feature and if it can be turned on or not...

• BVM-D20F1U, with VCR Mode (AFC) off, top 20% of the image is skewed. VCR Mode ON = perfect (slight jittering at times still though).

• BVM-D9H5U (similar basic specs as the more common BVM-D14 below - including both using the same BKM-129x input card), VCR mode is listed in the manual, but blue'd out in the menu (blue = "Menu settings displayed in blue cannot be changed"), sync skewed on the top - ZERO current fix...

• BVM-D14H5U, Imaged skewed with Dreamcast on a Toro, using BKM-129x input card. Same skewing problem as the 68x card - and yet again on another Sega system (could just be coincidence...see RetroRGB's problem with Sega Master System on the BVM A-Series though). VCR Mode is again in the menu (AND in the manual as a feature), but blue'd out and inaccessible. - had another friend with a D14 check his as well: blue'd out.

• PVM-9L3, not a PVM but does use the same 129x input card as above. Ironically this lower end model has NO problem with skew unlike it's higher-end, same-size and TVL count, BVM-D9 with the same exact 129x input card. This PVM series probably falls into the consumer TV category in that it probably has a built-in AFC of some type for more consumer-oriented video sources (i.e. NOT a BVM Broadcast-type monitor which are more touchy as we've seen).

• Panasonic BT-M1950Y. While not a BVM, it is Panasonic's highest SD monitor they ever produced. Image is skewed normally. This one does have an AFC feature which corrects the problem (same as VCR), their manual says """AFC (switching of time constant for the AFC) – use to set the time constant for the AFC (auto fine-frequency control) to correct skew distortion of video signals input via a videotape recorder or other video equipment.""" Has a Normal, Fast, Slow setting = these fix the skewing.

• Placeholder for my BVM-14F5U which works perfect – I need to check the on-screen menus to see if VCR Mode is in there somewhere, and if it's turned on. There's no mention of VCR Mode in the manual, however in the Maintenance Manual there is a big long paragraph all about it's "AFC Circuit" which I assume is built in and always on? which would make sense as to why this monitors image isn't skewed.

That's about it...don't know if this helps at all but I wanted to chime in with my experience so far in regards to AFC. This VCR mode being disabled (yet mentioned in the manual as being available????) has basically bricked my portable BVM-9 project (anybody want to buy a REALLY expensive 9" BVM? lol). I also contacted Mike Chi who makes the RetroTink board, and he mentioned a customer of his on a BVM did have to turn on VCR Mode which leads me to believe all the available Raspberry Pi RGB solutions at the moment are missing this part of the sync signals (I emailed him back with more info about this exact sync issue and am waiting to hear back from him). This really stinks as it means there's no Raspberry Pi RGB solution for a BVM unless it has AFC... (or, well, if you're OK running the signal through like multiple converter boxes to get it's sync recreated and straightened out of course).

I'll be staying tuned in this topic - I would REALLY like to see if any solutions are found on this Ikegami as maybe it'll help people with Sony BVM's s well.

[lewolfeur]

Also have two d14 but still in my storage and not tested them, if its without the possibility to activate the vcr, i am disappointed

[Xer Xian]

There can't be too many of us trying to make this stuff work.

There are quite a few people trying to come to terms with picky pro-monitors, as you can see from this thread (and the BVM-A series, or DT-V series) following (Btw, Lewolfeur and Dochartaigh you have way too many CRT monitors ^^ )

Anyway, allow me one last digression to set things straight on the different 'time constant' AFC modes after a few erroneous posts I've made. The answer in how they are relevant was actually contained in the book linked by SamIAm, "Monochrome And Colour Television" by R.Gulati (*cough* full PDF is available by *coughcough* google search *cough*). I didn't concern myself with the exact definition of 'time constant' in this case (it's beyond my grasp), but if you want here's specific the wikipedia voice. Here's the relevant quote from the book instead, pag.313,319:

The discriminator in the AFC circuit develops a slowly varying voltage, the magnitude of which depends on deviation of frequency of the horizontal oscillator from its correct frequency. [...] The AFC circuit output is filtered by a low-pass filter to obtain an almost dc voltage, which then controls the frequency of the horizontal sweep oscillator. [...] 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 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.

On another note, about this:

Therefore, by cutting out resistors 268, 270 and 272, I force the 4053B to output a constant high instead of a constant low. Also, in order to force the 4053B to output a constant low, I could (theoretically) restore the resistors I cut out, but put the leg that was going to the transistor directly to ground instead.

I'm really not qualified to talk about technical stuff, but I guess that the 2SC339B transistor is part of the LPF that filters the output of the AFC circuit to "obtain an almost dc voltage, which then controls the frequency of the horizontal sweep oscillator" (from quote above). If that's the case, wouldn't you risk an incorrect driving of the horizontal oscillator by cutting the resistor of all the AFC LPF lines (I legit don't know)?

[Dochartaigh]

(Btw, Lewolfeur and Dochartaigh you have way too many CRT monitors ^^ )

Can some mod step in here? Xer Xian needs to be banned. Seriously. That is sacrilege! lol (and for the record I've been downsizing!!!)

[SamIAm]

I just saw your post in the middle of writing this update.

Ironic that I've been looking into getting active on this board again and I run in to your post right in the middle of your big adventure...
No better time than the present, though!
I love how much information the guys on this forum share with all of us and it's high time I started making some contributions where I can.

Thanks! Glad you're with us!

I’m using 2 Extron RGB 160xi units. I don’t have any experience with the SS 200 (or the Sync Stabilizer units in general) but looking at the specification sheet it appears to only support horizontal frequencies of 30 kHz and above so that might be the issue.

Well, color me embarrassed for missing this.

The thing is, it works with 15KHz, or at least it seems to. However, it just doesn't fix anything.

My SFC also has a tiny bit of jitter in the top five scanlines or so when running on my Ikegami, and these come through with the SS 200, too.

The RGB interfaces (including the 160xi) go down to 15 kHz so no problem supporting a 240p signal there.
The 160xi uses a standard DE-15 d-sub VGA connector for the input and BNCs for the output so it’s relatively easy to integrate into an analog setup. It can also split or combine sync (RGBHV to RGBs in both directions) as needed and can output sync-on-green; all of this is very helpful in troubleshooting sync on our monitors (as the 2050R supports RGsB just like most Sony pro monitors).

Dang. Maybe I should have picked up a 160xi when I was last in the States.

I have a 202 plus and a 304, the latter being the one with the fried internal power supply. I think it needs two voltages, 15V and 6.8V, and the latter is the one that's a pain to replace. I could see if 6V only would work, or I could get back to hunting the elusive 7V linear regulator, but getting 6.8V exactly is something I've given up on.

The maker of the power supply offered to repair it for me for free...if I paid for two way registered mail to Taiwan, which is 5000 yen.

Anyway, unless I find a 160xi floating around, I'll need to make that Dsub 9-pin cable no matter what I use next.

So with that in mind, getting back to your question - can the 2050R display a signal from an RGB-modded PG Engine without flagging using an Extron RGB interface? With a pretty high degree of certainty I believe the answer to be “yes.”

I can confirm that I observe flagging in the image from my own RGB-modded PC Engine (Duo RX) on the 2050R.
I have not actually been able to test the PCE through the Extron as I can currently only obtain sync over composite video from the PCE and the Extron needs RGBs to function properly.
I haven’t had time to construct a sync separation circuit for it at this time.

Does the 160xi strip sync off green? You could just feed composite video into the green input if all you're looking to test is whether the image skews. Of course, it might mess the sync up anyway since composite is so much more complicated as a signal. If you're bored, you could also try making the lowpass filter they recommend in the LM1881 datasheet. It's a 620 ohm resistor in series with the signal and 510pf capacitor to ground, a typical RC filter configuration, and it kills the color burst after the sync pulse. That should make composite video basically indistinguishable from green. I think, anyway.

However, the reason that I am reasonably confident that this will work is I have experimented with the Dreamcast outputting 480i from a TORO VGA box and was able to correct the same issue on the Dreamcast output.
The TORO 480i output in RGBs directly to the 2050R caused the same flagging issue as observed with the PCE.
However, when taking the TORO output (both RGBHV and RGBs) into the Extron RGB 160xi and then output to the 2050R (tested with both RGBs and RGsB just in case), I was able to correct the issue.

Really? I have the DC outputting RGB over a plain scart cable (not sure if it's c-sync or composite video sync), and it works fine on my 2050R.

The RGB interfaces have a DIP switch marked “SERR” that controls serration pulses and this switch can fix the flagging issue. The Extron RGB interface manual says to set the SERR switch to off to remove serration pulses if flagging in the image is present; somewhat counter-intuitively one must actually set the switch to on to fix the flagging issue on the 2050R. I assume that the Extron digital sync signal processing corrects the flaws in the sync signal and sends correct serration pulses to the monitor in this case.

Maybe it's because it's not meant for 15KHz, but my SS 200 only made the problem worse for the PCE when I flipped that switch.

Once I am able to obtain RGBs from the PCE I will repeat the experiment and let you know if it works but I believe the cause to be similar and thus I am relatively confident that the same fix will work. (RetroRGB used a similar fix for the BVM-A with the Master System’s equally wonky sync signal).

Well, if you beat me to the punch, please do let me know!

To answer your final question, yes I have the 2050R2 (type 2) unit. I can’t find any evidence that the HTM-2050R (without the 2) was ever sold in Japan as all I see are the 2050R2 units (although the front panel says “HTM-2050R”).

Interesting. Somewhere, I saw a picture of a 2050 that had a different layout of heat sinks on the back of it, so the R1 variant must exist somewhere.

I too was influenced by the Reddit thread about enabling 480p using DIP switches on the remote control board and I bought the monitor thinking I could get it to display 480p, but alas, as with you I could not get it to work.
In fact one of the questions I originally wanted to ask you was if you had better luck!

I was able to convert my unit from a “Type 2” unit (240p/480i/1080i) to a “Type 1” configuration (240p/480i/1080i/720p) using the DIP switch trick. This leads me to believe that there may still be a way to get 480p to work as I have not been able to try all of the DIP switch combinations. Have you played with any more of them?
(BTW to enable 720p enable switch #4)

It's definitely a bummer that the option doesn't seem to be there for us. Good to know about switch #4, at least.

But I probably won't be playing with this too much. For now, I really want to get the PCE to display, and hopefully to correct the slight jitter on the SFC at the same time.


Hey, you didn't by any chance pick up that 2050R2 from a couple of months ago on Yahoo Auctions that the guy had had refurbished by Ikegami? I'm kicking myself for not getting that. I wouldn't be surprised if that had a new tube in it.

[HiroWorship]

HTM-2050R2

I know of the HTM-2050R, but never heard of the R2 variant? Does that model even exist? If so, what are the differences?

It certainly does as both SamIAm and I own one!
There is VERY little documentation on these monitors available online and so I am unable to determine what the differences between the versions are.
It could be similar to the A, E, and J region designations on the later BVM models, or it could indicate a different feature set. No way to be sure unless I call Ikegami, although who knows how much they will answer questions about discontinued monitors.

My problems are mostly with the Pi2SCART board for a Raspberry Pi 3 - this common RGB outputting device must likewise be missing a "horizontal slices in the vertical sync block" as the RetroRGB page says.

Unfortunately I do not have access to the Pi2SCART board but I would guess that this is a similar issue to the PC Engine one. It must not be generating serration pulses or if it is they are out of spec.
The analog consoles that I am aware of that have this skewing/flagging issue are:
- Sega Master System (Genesis/Mega Drive has some odd sync issues but not this exact problem)
- PC Engine
- Neo Geo AES
- Dreamcast used through a TORO VGA box

I'll be staying tuned in this topic - I would REALLY like to see if any solutions are found on this Ikegami as maybe it'll help people with Sony BVM's s well.

Certainly, and I will continue to perform tests as I am able.
That being said, if you look at my above post you will see that I was able to fix the skew from the TORO Dreamcast VGA box that you mentioned as occurring on a BVM-D14H5U using an Extron RGB interface. I am quite confident that such an external device will be the required fix for these issues on multi-format monitors from this era.

Without being too didactic, I think that those of us who have been bitten by the pro monitor collecting bug need to understand that the signals produced by our game consoles were never intended to be displayed on anything other than consumer-grade CRT televisions, and the pro monitors that we love were never designed to display any signals other than strictly in-spec analog video signals in a broadcast studio environment (with the ability to compensate for VTR jitter using AFC/VCR mode on some units). The fact that some consoles display on some pro monitors without additional equipment is in fact a happy coincidence and thus I’m not bothered by needed to use additional equipment to bridge that gap in cases where the console is pushing an out-of-spec signal.

That’s just a long winded way of saying that I think the best and only answer to this problem will continue to be “use an RGB interface to bring the sync signal into spec” but I will of course continue to update with any more findings.
As the Extrons require RGBs my progress will be directly related to the speed at which I can build cables that extract RGBs from my consoles to use on this Ikegami.

[SamIAm]

Holy crap.

So, I love the look of this HTM-2050R2 so dang much that I've always been on the lookout for another one. They don't pop up often, though. On Yahoo auctions, it's literally just two or three per year.

Last week, I bought another one at a very agreeable price, and it arrived just the other day. To my horror, when I turned on the unit, it had AWFUL phosphor burn-in. There was a big "REC 000-00-00" stamp, and it had obviously spent its life running in a windowed mode that left a giant rectangle. I had never seen a tube this shot before.

The guy who sold it to me is a bulk seller of old studio equipment. He listed the monitor with a picture of it displaying the SMPTE color bars, which somehow hid the problem, and he described it as "confirmed working". I thought I was hosed. Yahoo Auctions has almost no customer protections, and strictly speaking, the seller didn't lie. I sent him an email with pictures and asked about a refund or an exchange, but I was fully prepared to be turned down.

To my shock, he has offered to send me another HTM-2050R2 that he has in storage, which he confirmed as not having burn-in. Not only that, but when I offered to dispose of the bad one for him instead of sending it back, he agreed.

You know what this means? This means I have a fully expendable unit to experiment on.

There can't be too many of us trying to make this stuff work.

There are quite a few people trying to come to terms with picky pro-monitors, as you can see from this thread (and the BVM-A series, or DT-V series) following (Btw, Lewolfeur and Dochartaigh you have way too many CRT monitors ^^ )

Yeah, I just meant with this particular model.

If I manage to discover something that helps people, that would be fantastic. In the meantime, if anyone has schematics for the BVM-A and DT-V series monitors, by all means, start scouring them for AFC-related circuitry.

I'm really not qualified to talk about technical stuff, but I guess that the 2SC339B transistor is part of the LPF that filters the output of the AFC circuit to "obtain an almost dc voltage, which then controls the frequency of the horizontal sweep oscillator" (from quote above). If that's the case, wouldn't you risk an incorrect driving of the horizontal oscillator by cutting the resistor of all the AFC LPF lines (I legit don't know)?

I don't think that's quite what's going on. The AFC signals in this HTM-2050R2 are purely digital until they go into the upc1883, which is presumably where all the analogue magic happens.

I admit, there is a lot that's still a mystery to me. The proper way to do this would be to break out oscilloscopes and/or logic analyzers. I just don't have that equipment...for now...

I did discover something important last night, though. In the schematic that I have, a small amount is cut off by it being divided into separate A4 pages. With a little sleuthing, though, I figured out one component that was partially cropped out: an NJM78L09UA, which is a simple 9V regulator. This connects back to the line in the upper right of image I posted.

One more thing...and I had discovered this much earlier but hadn't mentioned it...I had two lines mixed up in my old image.

I've updated the images in my older posts to include both of these things.

[SamIAm]

It could be similar to the A, E, and J region designations on the later BVM models, or it could indicate a different feature set. No way to be sure unless I call Ikegami, although who knows how much they will answer questions about discontinued monitors.

You know, I wrote their branch office where I live (Fukuoka) and they were really nice to me. They even went out of their way to dig into their archives and find an operator's manual to send me.

Another guy wrote Ikegami USA and got the service manual. Ikegami Japan politely declined to give me that one - they said I might electrocute myself.

Both of these, I can give you if you like.

That’s just a long winded way of saying that I think the best and only answer to this problem will continue to be “use an RGB interface to bring the sync signal into spec” but I will of course continue to update with any more findings.
As the Extrons require RGBs my progress will be directly related to the speed at which I can build cables that extract RGBs from my consoles to use on this Ikegami.

If an Extron fixes the problem, then that's fantastic. I'd only feel dumb for putting off making an adapter cable for so long.

It would be quite cool, though, if there were a solution along the lines of cutting just the right line somewhere in the monitor's circuitry.

Now that I have a disposable unit, I'm going to try basically everything I can think of. At this point, it's for science!

Although I'm being a moron for doing this without a logic analyzer...

[HiroWorship]

Thanks! Glad you're with us!

Good to be here!

The thing is, it works with 15KHz, or at least it seems to. However, it just doesn't fix anything.

My SFC also has a tiny bit of jitter in the top five scanlines or so when running on my Ikegami, and these come through with the SS 200, too.

Just my two cents: I’ve found that in the world of analog video signals (unlike digital/HDMI etc) equipment rarely refuses to function completely; it just acts erratically when fed with the wrong signal type. My guess is that the SS 200 sees the 15 kHZ signal and tries to do something with it but is unsuccessful because it wasn’t designed for it.

Case in point: I have a RGB switch that technically only accepts RGBs but when I fed it RGBc (sync on composite video) it will work fine on some content and not on others (lots of white areas in the screen will cause the voltage to jump out of spec). One of my projects is getting things set up to work around this but that’s a subject for another post.

Point is, that’s what makes troubleshooting these issues so difficult because it very hard to know what is causing erratic behavior - signal out of spec, equipment settings wrong, aging or blown caps in the hardware, etc etc.
Thrilling, but frustrating!

I can confirm that the SFC causes jitter at the very top of the picture (top right in my case) on the 2050R2 for me as well. Once I get RGBs out of the SFC I’ll let you know if the Extron fixes it (I think it will).

Dang. Maybe I should have picked up a 160xi when I was last in the States.

I have a 202 plus and a 304…

Anyway, unless I find a 160xi floating around, I'll need to make that Dsub 9-pin cable no matter what I use next.

Looks like both the 202 plus and the 304 support 15 kHz, so I’m guessing that either might work if you can get the cable input sorted. I don’t envy you trying to fix the internal power supply on the 304; it’s probably easier to just get a different unit for 2000 - 3000 yen or so.

Anyway, offer to lend still stands if you want to test the 160xi on your Ikegami. I’ll throw a BNC to DE15 cable in there too if you want.
That way, you can see if it solves the problem and if so you can decide what to use for a permanent solution. I don’t use both of mine at the same time anyway and won’t until I finish some other projects first.

Does the 160xi strip sync off green?

It might, since the manual says it can get fed a RGsB input and output RGBs. Haven’t tried yet though. I appreciate your suggestion of a circuit (and I’m again impressed by your knowledge and experience in that area that I am far from achieving) but I think the quickest route will be to build a RGBs solution for the PCE (which I need anyway) and test it that way. 2 birds with one stone, if I can get the time.
I might ask for your help with understanding that circuit once I get there (another topic, obviously).

Really? I have the DC outputting RGB over a plain scart cable (not sure if it's c-sync or composite video sync), and it works fine on my 2050R.

Yeah, I think this has to do with how the TORO box combines sync. It can output both RGBs and RGBHV from the DE15 connector and my guess is it handles sync in a way that doesn’t play nice with some pro CRT monitors and causes a flagging issue exactly like the PCE. If your SCART cable is using sync on composite video that wouldn’t be an issue. I have a Dreamcast SCART cable like that I might try but the Extron fixes the issue on the TORO which is a great piece of evidence to this puzzle.

Maybe it's because it's not meant for 15KHz, but my SS 200 only made the problem worse for the PCE when I flipped that switch.
Well, if you beat me to the punch, please do let me know!

Sorry it didn’t work on the SS 200. When I can I’ll update on the SERR switch with PCE output on the 160xi.

Interesting. Somewhere, I saw a picture of a 2050 that had a different layout of heat sinks on the back of it, so the R1 variant must exist somewhere.

I’m sure it does… maybe a regional difference? Seems the 2050Rs outside of Japan are different than the ones here and I’ve only ever seen 2050R2s for sale here. Certainly looks like the remote boards are different based on the Reddit 480p thread.

It's definitely a bummer that the option doesn't seem to be there for us. Good to know about switch #4, at least.

But I probably won't be playing with this too much. For now, I really want to get the PCE to display, and hopefully to correct the slight jitter on the SFC at the same time.

I might keep looking at the DIP switches and playing with them, depending on how expendable I might consider this monitor to be. I really want to get 480p working on it since that’s why I bought it in the first place!
Now I have a PVM-D20L5DJ on the way for 480p purposes so I’ll have another to compare but it will still be great to have 480p on this Ikegami.

I hear you about wanting to get the PCE to work.
Happy to help (we can discuss more on PM).

Hey, you didn't by any chance pick up that 2050R2 from a couple of months ago on Yahoo Auctions that the guy had had refurbished by Ikegami? I'm kicking myself for not getting that. I wouldn't be surprised if that had a new tube in it.

I saw that! Not me unfortunately. I got the one that went up after that one.
Still, luckily my tube seems to be in really good shape.
Unfortunately I’ve never seen another 2050R2 to compare it to so I don’t have a frame of reference but subjectively everything appears to be in working order and there is no burn-in.

[HiroWorship]

Holy crap.

Holy crap indeed!!
Congratulations on the free monitor!

You must use the set with the shot tube to perform some experiments. If you wouldn’t mind trying the other DIPs I would be very very grateful - still chasing 480p on this thing but don’t want to brick it.

Both of these, I can give you if you like.

Thanks so much!! That would be great. I’ll PM you.

[lewolfeur]

Yeah, I just meant with this particular model.

If I manage to discover something that helps people, that would be fantastic. In the meantime, if anyone has schematics for the BVM-A and DT-V series monitors, by all means, start scouring them for AFC-related circuitry.

for the dt-v 1710/1910

Must be this chip M52346SP

http://datasheet.octopart.com/M52346SP- ... 104119.pdf

[SamIAm]

Here are some better datasheets:

http://elcodis.com/parts/5964598/UPC1883.html
This is the UPC1883 in detail, in Japanese.

http://www.ti.com/lit/ds/symlink/cd4053b-mil.pdf
This is the 4053B, directly from Texas Instruments.

The 4053B was good to look at again. I think I understand it more.



Pins 9, 10 and 11 are like switches. Take pin 11 as an example - it controls what comes out of pin 14.



When pin 11 is off, whatever is flowing into pin 12 can flow out of pin 14.

When pin 11 is on, whatever is flowing into pin 13 can flow out of pin 14.

I'll spare you all more giant images (for now), but let me walk through two situations.

#1 - NJU3718 outputs digital logic high on pin 24 (AFC Fast):
Input on TR205 (2SC3398) transistor opens.
R267 and R268 create a voltage divider; input A on 4053B (pin 11) goes low
4053B's ax channel (pin 12) is switched to
9V is allowed through 4053B's output A (pin 14)
Voltage flows through C242 and R274 to HAFC input on UPC1883

#2 - NJU3718 outputs digital logic low on pin 24 (AFC Fast):
Input on TR205 (2SC3398) transistor closes.
R267 and R268 do not create a voltage divider; input A on 4053B (pin 11) is high
4053B's ay channel (pin 13) is switched to
Nothing goes through 4053B's output A (pin 14)
HAFC input on UPC1883 gets nothing.


I think that this is all correct.

However, I really can't say any more about what is going on with this unless I'm able to actually get a look at at least the digital signals from the NJU3718. For example, does it ever output two highs at the same time on different speeds? That would change the voltage going into the HAFC input.

The block diagram makes it seem like it should be only one at a time; they do use the word "selector" after all. But then, they also call the 4053B a selector, and that's not what it is at all. It's just a bunch of switches. There is no logic that allows one line to override another. The thing that decides when there will be slow/normal/fast AFC pulses must be much earlier in the chain - it's whatever is feeding the NJU3718 all that serial data that it turns into parallel data.

Anyway, with what I know now, and with an expendable unit I'm not afraid to abuse, I can exhaust all permutations (of which there are twelve) and if none of those work, then that means I'm finished...unless I can sniff out where and how the AFC is actually created.

[Xer Xian]

@lewolfeur: thanks for providing the diagrams of the DT-V series. I can't find anything AFC-related in that chip though, nor anywhere else on the manuals except for pin 18 and 24 on the UPC1884CT sync processor (here's a link to the documentation). They're input pins though, so the signal should originate somewhere else.. anyway we are probably off-topic with this here.

However, I really can't say any more about what is going on with this unless I'm able to actually get a look at at least the digital signals from the NJU3718. For example, does it ever output two highs at the same time on different speeds? That would change the voltage going into the HAFC input. The block diagram makes it seem like it should be only one at a time; they do use the word "selector" after all. But then, they also call the 4053B a selector, and that's not what it is at all.

Actually, the exact word they used is a very engrish-flavoured '(AFC Mode) Serecter'

I agree with you that the AFC mode selection most likely happens before going into the UPC1883 Sync processor, otherwise having three different AFC lines earlier in the chain would make no sense (so I disagree when you said earlier that the 'analogue magic' happens in the UPC1883 - but I liked how you phrased it). The key to sorting out this must be somewhere in the IC207 circuitry and you look in a good position to figure it out - you even have a test subject at your disposal now ^_^ Anyway I should really bow out of tech-talking now, that's not really my strong point at all.. so I guess that's a good luck for now

[lewolfeur]

Removed