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.