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.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/neonixie-l/23535526-26bb-432a-b809-8c3e83918727n%40googlegroups.com.
