To give some more context around some of the design decisions, I'll do a 
quick summary of the power supply design process here:

A main goal was to only use off-the-shelf magnetics. The transformer was 
chosen to have the highest available HV winding magnetizing inductance, to 
limit the reactive power in the Baxandall oscillator. Flyback transformers 
are deliberately wound to have a low magnetizing inductance, so they are 
not perfect for this application, but the chosen part works pretty well.

I originally looked at using the transformer in flyback mode, but this is 
not ideal for running voltage multipliers as the turn-on current in the 
switch (from charging the multiplier stack) is only limited by transformer 
leakage inductance, which interacts badly with peak current mode control. 
There are workarounds like using non-PCMC-controllers (as done in the 
original SCTV design), using fixed-on-time or hysteretic controllers, or 
filtering the current sense signal, but I wanted to explore something 
different. I had worries about startup behavior and control range in a 
self-oscillating design like this, but it behaves very well in my testing 
so far.

A cheap buck pre-regulator is used to control the secondary voltage. This 
part has not been fully tested yet, but the board has provisions for 
mixed-mode feedback to stabilize it if this turns out necessary. 

All voltages are doubler-derived to improve cross-regulation, to minimize 
focus variation when the cathode current (brightness) is adjusted. If a 
single secondary is used, this means more stages are needed for the PDA and 
cathode voltage multipliers, since the deflection voltage is limited to 300 
V in order to manage dissipation in the deflection amplifiers while 
maintaining acceptable slew rate. Luckily the transformer has a tapped 
secondary, so I can get 300 V for acceleration, and 550 V per stage in the 
other multipliers. 

One issue I found in my original design is that focus, brightness and 
astigmatism interact to a large degree. This turned out to have two main 
causes. One was sagging of the anode 2/4 voltage from the screen current, 
here I ended up buffering the astigmatism voltage with an emitter follower 
to make this supply stiffer while not having excessive dissipation in the 
potmeter. The second issue was that the cathode voltage moved around a lot 
relative to VG1 and focus due to the cathode being driven from a resistor 
chain. I originally expected that most of the cathode current would end up 
as beam current, but most of it actually goes to the control grid, as much 
as 90+ percent. This means that the cathode current was about 10 times 
higher than I expected. The trick here is to drive both the cathode and 
control grid from low impedance sources. Here I solved it with deriving the 
control grid voltage from a separate multiplier running off the filament 
supply, instead of the common divider chain that some other designs use.

Filament power is derived from another parallel transformer, I chose a gate 
drive transformer for its good isolation rating and low cost. I went with 
inductive current limiting on the secondary side for a few reasons. 1: it 
provides current limiting behavior during start-up, giving gentle warmup of 
the filament. 2: It allows easy selection of filament voltage by just 
changing the inductance without modifying the transfomers. 3: it allows the 
secondary voltage to be higher than the filament voltage, requiring less 
stages on the voltage multiplier in order to reach the target -Vg1 voltage. 
4: It provides some tank VARs to keep the Baxandall oscillator from 
dropping below the minimum required Q during startup with a cold filament.

The last trick is the -12 for the deflection amplifier constant current 
sinks. I played with different designs for the deflection amps, and found 
the simple long tailed pair with a CCS to work exceedingly well for its 
simplicity. The cheapest way I found of making the required negative rail 
for this was to make a capactive divider as part of the primary tank 
capacitance, and rectifying the voltage across the middle cap, which works 
fine since it's isolated by caps on both sides. It looks a bit funny, but 
works very well.

On Sunday, March 24, 2024 at 7:48:53 PM UTC+1 Anders Mikkelsen wrote:

> I know I'm a bit late in following up on this, but better late than never! 
> I got caught up in life and other projects as usual.
>
> I've put up some more photos and videos, plus some preliminary schematics 
> in this google album: https://photos.app.goo.gl/dzu7QLQbDr4ameMr8
>
>
> Best regards
>
> On Saturday, December 23, 2023 at 2:10:19 AM UTC+1 Max Di Noi wrote:
>
>> Actually, that code works well! I had a typo on a pin config. Seems to 
>> work well! Very pleased. I hope you find that snipped of code useful.
>>
>>
>> On 22 Dec 2023, at 17:58, Max DN <flata...@gmail.com> wrote:
>>
>>
>> Jörg,
>>
>> This is the code that I am using with DAC 4822 (similar to 4922 but with 
>> internal ref.). I can generate some nice sinewaves with 1V or 2V amplitude 
>> with the Teensy 4.1 powered by USB data cable and output displayed on my 
>> Rigol oscilloscope.
>>
>> And of course, I can draw a circle.
>>
>> I think the code is as slim as can be, see below. However when I plug it 
>> in the scope clock code, It doesn't seem to work well... I need to figure 
>> it out.
>>
>>
>> //code
>> #include <SPI.h>
>>
>> //typedef unsigned int mcp4xxx_register; // 16-bit MCP48XX/MCP49XX 
>> register for a single channel and 12-bit data
>> //
>> //const mcp4xxx_register mcp4xxx_channel_a =  0B0000000000000000; // for 
>> all MCP4XXX
>> //const mcp4xxx_register mcp4xxx_channel_b =  0B1000000000000000; // for 
>> MCP4XX2 only
>> //const mcp4xxx_register mcp4xxx_buffer_off = 0B0000000000000000; // for 
>> all MCP4XXX
>> //const mcp4xxx_register mcp4xxx_buffer_on  = 0B0100000000000000; // for 
>> MCP49XX only
>> //const mcp4xxx_register mcp4xxx_gain_two =   0B0000000000000000;
>> //const mcp4xxx_register mcp4xxx_gain_one =   0B0010000000000000;
>> //const mcp4xxx_register mcp4xxx_output_off = 0B0000000000000000;
>> //const mcp4xxx_register mcp4xxx_output_on  = 0B0001000000000000;
>> //
>> //
>> //const mcp4xxx_register mcp4822_channel_a = mcp4xxx_channel_a | 
>> //                                           mcp4xxx_buffer_off | 
>> //                                           mcp4xxx_gain_one | 
>> //                                           mcp4xxx_output_on;
>> //
>> //const mcp4xxx_register mcp4822_channel_b = mcp4xxx_channel_b | 
>> //                                           mcp4xxx_buffer_off | 
>> //                                           mcp4xxx_gain_one | 
>> //                                           mcp4xxx_output_on;
>>
>> const unsigned int  steps = 512;
>>
>> unsigned int sines_of_steps[steps]; // sine values scaled to 0 ... 4095 
>> (2^12 - 1)
>>
>> const byte          DACCSPin   = 10;
>>
>> void setup()
>> {
>>    int i;
>>
>>    for (i = 0; i < steps; i++)
>>    {
>>       sines_of_steps[i] = round((sin(TWO_PI / steps * i) + 1) * 2047.5);
>>    }
>>    
>>    pinMode(DACCSPin, OUTPUT);
>>    digitalWrite(DACCSPin, HIGH);
>>
>>    SPI.begin();
>> }
>>
>> void loop()
>> {
>>    unsigned int  i;
>>    for (;;)
>>    {
>>          for (i = 0; i < steps; i++)
>>          {
>>             SPI.beginTransaction(SPISettings(20000000, MSBFIRST, 
>> SPI_MODE2));
>>
>>             digitalWrite(DACCSPin, LOW);
>>             SPI.transfer16(0B0011000000000000 | sines_of_steps[i]);
>>             // bits: DAC channel A, buffer off, gain 1x 
>> (Vout=VRef*D/4096), output on, 12-bit data (D)
>>             digitalWrite(DACCSPin, HIGH);
>>             
>>             digitalWrite(DACCSPin, LOW);
>>             SPI.transfer16(0B1011000000000000 | sines_of_steps[steps - 1 
>> - i]);
>>             // bits: DAC channel B, buffer off, gain 1x 
>> (Vout=VRef*D/4096), output on, 12-bit data (D)
>>             digitalWrite(DACCSPin, HIGH);
>>
>>            SPI.endTransaction();
>>          }
>>                    
>>    }
>> }
>> Il giorno mercoledì 22 novembre 2023 alle 08:55:55 UTC jörg ha scritto:
>>
>>> Pretty nice photos.
>>> I like it too, to disable blanking and to see the painting beam.
>>> I did some tests with the MCP4922, too, but it was too slow for me.
>>> Mabe you've found a better way (code) driving it. If you don't mind, I'm 
>>> intersted in a code snipped and which lib you have used.
>>> I ended up in a AD5344, which works pretty well for me on the 
>>> teensy40/41). So maybe I will give the 4922 a second try.
>>> And I'm curious about your powersupply approach. Especial the +-5V and 
>>> noise. I'm using a switched one, which is too noisy.
>>> Last, I'm in the same problem, getting a sharp image an tweaking with 
>>> focus, astig etc. 
>>> So, if you get good results with the emitter follower, please share your 
>>> experience.
>>> Cheers
>>> Jörg
>>>
>>>
>>>
>>> On Monday, November 20, 2023 at 9:37:35 PM UTC+1 GDR GDR wrote:
>>>
>>>> wow! while the technical details are all "greek" to me, the images look 
>>>> amazing. I love the "artifacts" in them. I dont know how you took these, 
>>>> but it looks awesome! I like it as it is! not sure how this looks like in 
>>>> "motion" but looks great in the stills... can you post some more? cheers
>>>>
>>>> On Sunday, November 19, 2023 at 4:25:50 PM UTC-6 Anders Mikkelsen wrote:
>>>>
>>>>> I recently started playing with scope clocks again, after seeing 
>>>>> David's circle graphics clock the better part of two decades ago and 
>>>>> having 
>>>>> had it in the back of my mind since. This was prompted by Teensy 4.1 
>>>>> becoming available again on the market, and the official port of the SCTV 
>>>>> codebase for this platform. I got it up and running, and explored some 
>>>>> aspects around the design, I thought I'd share some info with the group 
>>>>> in 
>>>>> case anybody else can benefit from it.
>>>>>
>>>>> Firstly, off-the-shelf flyback transformers for low power auxiliary 
>>>>> supplies work very well in Baxandall oscillators to make the required 
>>>>> voltages at minimal cost and complexity, without using any custom parts. 
>>>>> I 
>>>>> used a Wurth 750310787, but many others are available. A buck converter 
>>>>> can 
>>>>> be wrapped around the circuit to get good line and load regulation, and 
>>>>> the 
>>>>> resulting BOM cost is less than 5 bucks. An off-the-shelf gate drive 
>>>>> transformer can be used to drive the filament, providing the required 
>>>>> isolation and power handling for a few bucks more, making a very simple 
>>>>> and 
>>>>> cheap design. 
>>>>>
>>>>> Secondly, the LT DAC in the design can be replaced by a much more 
>>>>> affordable (and easy to solder) MCP4922, without taking a hit on the DAC 
>>>>> update rate. A comparison of the two parts would suggest that the 20 MHz 
>>>>> maximum SPI rate of this part would significantly impact performance, but 
>>>>> in practice it ends up working at around 500 KSPS as well. The issue with 
>>>>> the original part is that it relies on 24 bit SPI transfers, which are 
>>>>> again implemented as an 8 bit and a 16 bit transfer, and the overhead 
>>>>> from 
>>>>> reconfiguring the SPI peripheral and waiting for the receive buffer to 
>>>>> fill 
>>>>> is significant. The MCP allows native 16 bit operation of the peripheral, 
>>>>> and use of the transmit FIFO to make the transfers without any 
>>>>> intervention 
>>>>> from the firmware once a set of XY coordinates are passed. I also 
>>>>> experimented with porting the code to run on an RP2040, which works well 
>>>>> so 
>>>>> far. I haven't assembled the RTC part yet, but everything else seems to 
>>>>> work with minimal changes to the code. The biggest effort was figuring 
>>>>> out 
>>>>> how to do efficient SPI transfers, which required some raw register 
>>>>> access, 
>>>>> and clock tree reconfiguration for synchronous operation of the SPI 
>>>>> peripheral (which is not the case with the Arduino default clock 
>>>>> frequency 
>>>>> for this board). 
>>>>>
>>>>> Thirdly, I did struggle a lot with getting a sharp image without 
>>>>> having a lot of interaction between focus, brightness and astigmatism. 
>>>>> Part 
>>>>> of it came from feeding the cathode from a high impedance point in the 
>>>>> divider, but a major factor turned out to be the source impedance of the 
>>>>> anode drive. Most circuits I've seen drive the anode from a potentiometer 
>>>>> fed from the deflection design. Most CRTs seem to draw an anode current 
>>>>> that's significantly higher than the screen current, often by an order of 
>>>>> magnitude, and this current causes the anode voltage to drift around as 
>>>>> the 
>>>>> brightness is adjusted. I initially used the high value of 1 Mohm for the 
>>>>> pot, which exaggerated this issue a bit as well. In electrostatic CRTs, 
>>>>> the 
>>>>> final anode together with the first set of deflection plates forms a 
>>>>> cylindrical lens, that affects both image geometry and beam focus. I 
>>>>> looked 
>>>>> at some oscilloscope schematics, and found some that use an emitter 
>>>>> follower to buffer the output of the astigmatism pot to deal with this, 
>>>>> and 
>>>>> I'm just waiting for some parts in order to try this out in my design. 
>>>>>
>>>>> I tried it with a range of old CRTs, and most of them struggle with 
>>>>> getting a sharp dot near the edges of the screen. I suspect this is 
>>>>> partly 
>>>>> due to my sagging voltages, but I'll see if the improvements address it. 
>>>>> Does anybody know what to expect in terms of corner spot size for typical 
>>>>> non-PDA electrostatic CRTs in the range of 30 - 100 mm screen diameter? 
>>>>> This is at 1200 V, and with enough beam current to make the scope clock 
>>>>> image readable in a room with normal indoor lighting.
>>>>>
>>>>> Some pictures attached in order to compensate for all the words.
>>>>>
>>>>> AM
>>>>>
>>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "neonixie-l" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to neonixie-l+...@googlegroups.com.
>>
>> To view this discussion on the web, visit 
>> https://groups.google.com/d/msgid/neonixie-l/23535526-26bb-432a-b809-8c3e83918727n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/neonixie-l/23535526-26bb-432a-b809-8c3e83918727n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to neonixie-l+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/05ceb157-2630-4560-9008-bd2dcc9dc396n%40googlegroups.com.

Reply via email to