Fundamentals of laser device control

[groundhogstate]

In my current project I am going back to basics - the first aim is to understand in detail how the laser device CHOP functions. I hope this makes it much easier in the long run to exercise precise control of the laser output - to date, my approach has been more or less ‘throw in a SOP and see’. To good effect, mind you, but there are too many abstractions in the process for my taste. Hence: I am starting by eschewing the laser CHOP (it’s extremely useful - too useful for this purpose ) in favour of plugging CHOPS directly into the laser device.

All going well, this development might form the basis of a from-first-principles tutorial. Let’s see.

The first topic: Waveform transmission.

Here is a simple network: It draws a (closed) spiral. Even in such a simple test, some puzzle arise.

Aside: the queue_seconds appears to be frames rather than seconds - it comfortably hovers around 20-25 for a 90-sample pattern and seems to decrease as the sample rate increases.

Notice the points_written channel in the info CHOP. If we feed this channel , use a Trail CHOP to select the final two samples, and attach to a Slope CHOP, we can see that the rate of point writing is nsamp * frameRate samples per second, as one would hope (assuming the slope CHOP produces the rate of change with respect to time, not samples, which appears to be true). It’s not always smooth - the hiccups below manifest as a slight jitter in the beam pointing when tracing animations.

While it is true that changing the sample rate parameter of the patterns that parametrize the curve (labeled r and theta) does not change point_write_rate, it nonetheless changes the output pattern. It seems there are ‘magic numbers’ for sample_rate such that this test spiral renders smoothly and without flickering or visible scanning. They are strange numbers: 17, 25, 35, 38, 42, etc. What’s more, some sample rates (e.g. 59) produce a pattern wherein all the (x,y) points in the parametrization are marked by bright spots (where the laser scan dwells), but in others the laser seems to continuously trace the curve, and the brightness is uniform (eg 60). These figures seem independent of the length of the patterns and of the project framerate.

So - are the frames fed out at sample_rate with the specified number of points? The fact that the point_write_rate is independent of the sample_rate appears inconsistent with this, which would entail that the write rate is proportional to the sample rate.

Moreover: Changing the sample rate in the pattern chops does affect the duration - apparently - of the downstream patterns as one would expect. With sample rate of 25 and 90 samples, the pattern is displayed as 3.6 seconds long:

But one does not observe the laser making a leisurely scan of the spiral over 3.6 seconds: Instead, the entire curve is illuminated. One might then surmise: Ah - the sample rate is immaterial to the laser. The points in the pattern buffer are sent in a single frame!

Well - no. Jacking the number of samples up to 2400 one does see that the point write rate is indeed up to 144000/sec, and one can watch the laser trace out the pattern - timing it against a stopwatch on my phone, I clock an average of about 0.7 seconds per loop - or about 40 frames give or take 5%. In this case, the sample rate does affect the visible scan speed: Dropping the sample rate from 60 (as above) to 35 with 2400 samples increases the scan period to about 1.25 sec, 75 frames.

It would appear that an excess #points is dispersed over several frames and that

2400 samples over 75 frames with 35 samples/sec → about 32 samples/frame

2400 samples over 40 frames with 60 samples/sec → about 60 samples/frame

Here it seems that the number of points per frame is controlled by the sample rate of the pattern - and at the same time, the point write rate is not affected, which I haven’t managed to reconcile yet.

One is left wondering: What is the arithmetic behind this? What is the process that takes a pattern input to the laser device and produces the (x,y,r,g,b,…) point set that the ShowNET API receives?

Summary:

	Observable
Parameter	Write speed	Flicker
Frame rate	Affected
Sample rate	No effect	Affected
Pattern length	Affected	No visible effect (small #points); affected (large #points)

[groundhogstate]

As one of the resident laser gurus @eric.b I wonder whether you can shed any light here?

[eric.b]

Sample rate assigns the scan speed for the given frame, so a sample rate of 60 would be low in this context. The API handles these edge cases so I doubt the laser is actually using a scan speed of 60 pps.

The Laser Device CHOP will work best with a timesliced input with a high sample rate, like the signal generated by the Laser CHOP.

queue_time_seconds is in seconds, but for large numbers of samples with low sample rates it will be impossible to reach the desired queue size and will stay high. Let’s say you have a rate of 60, but your non-timesliced input size is 300 samples, then that means 5 seconds worth of samples are being written each frame. The queue decreasing in size as you increase sample rate makes sense because the queue can now accept more points per second.

points_written simply increments by the number of points written each frame, if the laser accepts them. If your input sample size is 300 for the frame, then it will increment by 300 for the frame.