|
|
Post by gjaky on Apr 3, 2016 15:13:00 GMT -5
I am thinking on a fan mod on the XG, the topic is not new... I've pretty much read all the threads regarding this, and here is my version on this.
The biggest heat source in the XG are the STKs mounted on the bottom and the original neckboards, these are more or less cooled by simple thermal convection, and they are mounted inside the chassis. The two high speed fans on the sides move the most air inside the chassis, and cooling the neckboards as well. The fans underneath the tubes tubes are more or less useless.
So I'd put two big 120mm fans on the STK chip compartment on the bottom (on the ceiling this is up of course) and cover all the holes for the STKs, and suck the air out by the two big fans (be quiet! shadow wings sw1 2200RPM version), hece the air would be suck through the chassis.
I'd bypass two of the tube-coil coolers, and let the green do its job alone. I'd replace the high speed fans on the sides with the two low speed fans salvaged from under the tubes, to suck some air in eg. helping the big fans.
As laready known most noise made by the turbulence in this machine since the air is going trough small holes, putting the slow fans ner to the sides aim to help this problem
With finishing the VNB project I expect to lower the heat dissipation on the neckboards too opposed to the original neckboards, which run very hot by the way.
On the deflection board I already put a Nanoxia Deep Silence 60, which is actually poorer than the original fan were, but it does it's job, and keeps the heatsink at good temperatures at 54kHz scanrate.
I am about to replace the fans in the power supply with this type too. Also note with the VNB project the NEC power supply would be offloaded by the neckboards, which saves about 50W of power for that supply, the new supply for the neckboards will be out of the chassis, since there is no room for it inside...
|
|
|
|
Post by gjaky on Apr 20, 2016 11:46:51 GMT -5
Just because the high demand LOL...
So while I am at home and shouldn't lift any weight after a hernia surgery I am forced to reading / writing / speculating, instead of tinkering with the XG-VNB project.
This was a good time for me to evaluate the Horizontal defletion system of the XG more deeply. The most common problem with the XG is that they do not like the standard 1080p timings coming out from consumer devices, simply too much is cropped off the sides.
I made through myself the calculations that Scott shared once on the other site, and Nashou was kind enough to point me there.
Originally I was thinking of modifying the H-DEF board by using new generation SiC MOSFETs and adjusting the resonant capacitors to reach the desired fast retrace time. This could deliver the advantage of a cooler operation of the deflection board with only two FETs, instead of the 10 as is right now. The downside of this project would be the relatively high cost and the countless working hours to optimize the performance.
But now I more feel like to trick the XG and behave in a way it should not. It sounds very mystic isn't it? The deflection board already employs all the features that needed to display 1080p 60Hz nicely they are just no used as we would want them.
As it was already showed in the old thread the XG has autonatically variated retrace time depending on the scan frequency.
1080p 60Hz (with 2200 total pixels horizontally) has a blanking time of ~1.9us and scanrate of 67,5kHz.
The retrace time in the range of 30-77kHz the retrace time is 2.6us. While this might be true, but the blanking time is unfortunately much larger than this: I find this to be ~3.6us, anything shorter than this will be cropped down from the picture.
The next range is 77-120kHz, where the retrace is 2us and I found the minimal needed blanking time to be 2.5us. But this is unfortunately still would not be enough.
In the last range between 120-135kHz there is a very promising 1.4us advertised retrace time, that could be just enough for us!
All we have to do is to make the projector believe it is working in the 120-135kHz range while it does not. As far as I see this little cheat would not make harm to the pj, the only downside could be a slightly increased heat dissipation on the DEF board.
So now I am after the best solution idea to trick the pj.
|
|
|
|
Post by dummyload on Apr 20, 2016 13:30:22 GMT -5
Good thinking and get well soon.
|
|
|
|
Post by gjaky on Apr 21, 2016 2:29:11 GMT -5
Good thinking and get well soon.
Thank you  In the mean time I did further tests which went quite well. I've played with display timings while I was in the >120kHz range with the XG, and it seems there only ~1.6us total blanking time is needed to fill the raster, this is very good! I did not run it for hours at that scanrate but what was nice is that I saw no apparent raster ringing, but I also must admit that at 120kHz the raster width is nowhere as wide as at say 54kHz, but leave that for later. Again this is very good result as 1.6us is almost enough to even display frame tripled standard 1080p timing (this need 1.57us blanking time) not just 1080p 60Hz. |
|
|
|
Post by gjaky on Apr 21, 2016 11:21:38 GMT -5
The retrace time controll signals born on the OSC board. The H sync signal is converted to voltage by a F/V IC, and that is sampled by an ADC, then the local CPU decides what is the proper configuration for the deflection system. These signals not just used on the deflection board but also used for convergence signal timings as well. Because of this the modification should be carried out where it is born, so all the usage of the signal would remain consistent.
Here is my idea:
The output of the F/V IC should be monitored on the OSC board and above a given frequency say 60kHz a comparator kicks in and takes over the controll of the retrace setting signals and sets the 1.4us retrace mode. Below that it would behave just as before.
Further testing is needed to determine the translation ratio of the F/V converter ie. what voltage output equals to what frequency input.
|
|
|
|
Post by gjaky on Aug 21, 2016 8:24:54 GMT -5
The retrace time controll signals born on the OSC board. The H sync signal is converted to voltage by a F/V IC, and that is sampled by an ADC, then the local CPU decides what is the proper configuration for the deflection system. These signals not just used on the deflection board but also used for convergence signal timings as well. Because of this the modification should be carried out where it is born, so all the usage of the signal would remain consistent. Here is my idea: The output of the F/V IC should be monitored on the OSC board and above a given frequency say 60kHz a comparator kicks in and takes over the controll of the retrace setting signals and sets the 1.4us retrace mode. Below that it would behave just as before. Further testing is needed to determine the translation ratio of the F/V converter ie. what voltage output equals to what frequency input. Today I revisited this topic. I managed to do the circuit on the OSC board and it works! So it is possible to run the XG with standard 1080p 60Hz timings (2200 total pixels, horizontal) without cropping the image, in fact there is still some room to move the picture within the raster... One thing though the H-DEF board gets hot, which might be normal at high scan rates, but I have no experience with that, as I certainly do not want to overstress the H-DEF board, so a little more measuring is needed to see all voltages are within specs. |
|
|
|
Post by gjaky on Aug 21, 2016 11:36:34 GMT -5
As it seems it produces roughly about the same heat as in 1080P 72Hz normally.
|
|
