j4cDAC: a new open-source DAC project

[DMills]

Would having a command to 'arm' a rate change and a bit in the per point flags that would cause the rate change to be loaded into the pulse generator do?

It would mean you could only have one change pending at any given time (Unless we had a small fifo of the things!), but it should work, would be reliably synchronous and be relatively clean to implement.

Regards, Dan.

[JohnYayas]

The current protocol can do that, but only asynchronously (not lining up with a specific point). Do you need the changes to happen synchronized to the points? How often?

It would need to happen synchronously so that point rates of frames could be controlled on a frame by frame basis in order to useful.

[DMills]

That is possible, but I don't think it quite does what you want because a frame designed for say 12K ILDA scanner speed will not look right when output at 12K to a set of scanners calibrated for 30K ILDA (The point pulling will be all wrong).

It is actually probably better to output such a frame twice (thus getting the sequence timed for 24K, or three times (timing correct for 36K) while retaining the relatively correct scanner impulse response). It would run slightly fast, but only slightly (30/24) and at least the scanning will be correct (more or less).

Reworking frames for different rates in a reliable way in software is seriously non trivial, as you first have to produce a model of the scanner path run by the slower scanners (Never the same thing as just join the dots), and scan amps are NOT really LTI devices. Then you have to sample the derived path at the faster speed and pull the resulting point set, nasty does not even touch on it.

Still, making the firmware do this sync rate switch is actually not that hard, so it may as well go in (As in I can write this once the hardware is available).

Regards, Dan.

[JohnYayas]

That is possible, but I don't think it quite does what you want because a frame designed for say 12K ILDA scanner speed will not look right when output at 12K to a set of scanners calibrated for 30K ILDA (The point pulling will be all wrong).

In some circumstances I agree. But, there are not many of those circumstances from my experience. The normal mode of operation for Spaghetti is and always has been to very the point rate for each frame. It's works well and allows for wider scan angles.

[chad]

In some circumstances I agree. But, there are not many of those circumstances from my experience. The normal mode of operation for Spaghetti is and always has been to very the point rate for each frame. It's works well and allows for wider scan angles.

So how do you keep output looking smooth from frame to frame. The reason the big boys tune to a 30k output and maintain that output even with simple frames is to keep a consistant brightness and flicker level with frames of varying complexity.

I can see how your method would be better for scan angle and brightness but as for constancy in output, not to mention compatibility with an ilda frame, I would think it would mangle the output?

.02c

chad

[JohnYayas]

So how do you keep output looking smooth from frame to frame. The reason the big boys tune to a 30k output and maintain that output even with simple frames is to keep a consistant brightness and flicker level with frames of varying complexity.

I can see how your method would be better for scan angle and brightness but as for constancy in output, not to mention compatibility with an ilda frame, I would think it would mangle the output?

.02c

chad

I guess you could ask Spaghetti users if their output looks mangled.

[Zoof]

Since most DACs don't support this, it has become standard practice to do that in the laser show application. And since PCs are faster than embedded devices it isn't a bad thing to offload that functionality to the control software.

a good color mapping and color correction would be nice to offload to the firmware.

[chad]

I guess you could ask Spaghetti users if their output looks mangled.

not knocking it, just trying to figure out how you can have your cake and eat it too .

On another note I am really excited about this project.

chad

[DMills]

Not really, we send 16 bits of resolution to the DAC (only use 12 with the standard chip), and a set of colour lookup tables is a tiny amount of RAM in PC terms, but HUGE in terms of what is available on that ARM (64K all up, and half of that wants to be used for the point buffer).

Operations like taking logs (and in fact any FP math) is also much faster on a PC then it will be in a FPU less microcontroller, so why do on the micro what is far easier done on the PC?

The only possible reason to do colourimetry in the DAC would be if we were sending it 8 bit data but had more then 8 bits of output resolution.

Regards, Dan.

[JohnYayas]

Not really, we send 16 bits of resolution to the DAC (only use 12 with the standard chip), and a set of colour lookup tables is a tiny amount of RAM in PC terms, but HUGE in terms of what is available on that ARM (64K all up, and half of that wants to be used for the point buffer).

Operations like taking logs (and in fact any FP math) is also much faster on a PC then it will be in a FPU less microcontroller, so why do on the micro what is far easier done on the PC?

The only possible reason to do colourimetry in the DAC would be if we were sending it 8 bit data but had more then 8 bits of output resolution.

Regards, Dan.

That's pretty much how I see it as well. Besides, once you start adding processing into the firmware, you aren't able to reproduce the exact same results on a system that is using a different DAC. For example, swap the DAC out with an EasyLase and your output would look different. That's not good.

An example of this is with the Pangolin abstracts that run on the QM2000 board. Kind of a nifty way to handle it if you have a limited power PC but you can't reproduce those abstracts with other DACs (unless there is a way to export to ILDA so the shows are not cross-portable.) For a proprietary system like Pangolin that is fine, but for an open source DAC it doesn't.

I think things like final color level balance and maybe final scaling should be done after the DACs so that you deal with that on an analog level instead of reducing your bit range.