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 <flataeg...@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+unsubscr...@googlegroups.com
> <mailto:neonixie-l+unsubscr...@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/5CAC3C86-BBF1-42A6-B0D6-CD316EAB83B5%40gmail.com.
