Laser Projector (Red, Green, Purple) "Laser 3D Party Light" from Spencer's

[swamidog]

if it's helpful. i can load the frames into LSX and photo/video them for you.

I suspect you are right on the money, there. Don't worry about digging after this color-shifting-blanking-weirdness if it doesn't support your work on the soundcard DAC project. I will get there as I have time. I think the first thing I will do is cobble together an ILDA file reader, leveraging James' code if possible, to see what's really being fed to the showcard. Then I can be absolutely sure what it's getting when I feed it some random file or other.

The stopwatch method is not good for determining actual peak scanning speed as you said, but at least it tells me roughly how many points per second I should have if I want to do long-term synchronization with music.

[mixedgas]

If you just want to see if the position data is there, scroll down to ILDA-READ on this page. You'll need a DOS window to run it in. You're not the first one to need a ILDA FILE sanity check
I had similar problems long ago. Its so old it only does type zero .

http://laserfx.com/Backstage.LaserFX...loadIndex.html

It does not do color, color is there, but not enabled in the posted version. I have not seen the source code in years, but I'll look in the piling system.

You can also create data with ILDA-WRITE, also type zero 3D. I know Laserboy has a data table input function, but you might find that useful as well.

Steve

[tribble]

if it's helpful. i can load the frames into LSX and photo/video them for you.

Thanks for the offer swamidog, I'll keep you in mind! I have done some preliminary explorations with a hex editor and I can confirm that the Spencer projector does at least one thing "different" than expected per LaserBoy. I plan to create a collection of test frames in the next week or so that test color and blanking offsets, photograph the results, modify the files to show "as expected," and put both sets of files up for review. It will be interesting to see what LSX and other tools do with them.

You're not the first one to need a ILDA FILE sanity check

Thanks for the links, Steve! I'd already started writing my own ILDA parser/reporter when I got your message, but I'll check it out. I'm going to try to accommodate the other section formats as well for complete ILDA file diagnosis. ;-) That will take some time to complete.

[tribble]

OK, I couldn't wait.

Using LaserBoy, I created two lines, each with 7 colors, separated by a blanking trace:



I used zILDA to make sure it agreed with the layout. This picture came out sharper so I annotated it with vertex number and vector color:



I used my ILDA dumper to show the contents of the frame:

File is 160 bytes.
First section type: 0
Name: ESI.....
Owner: LaserBoy
Points: 16
Identity: 0
Total: 0
Scanner: 0
Last Byte (must be zero): 0
Point           x       y       z       Color   Blank   Last
Pt.     0       -32000  10000   100     55      B
Pt.     1       -23000  10000   100     0
Pt.     2       -14000  10000   100     16
Pt.     3       -5000   10000   100     24
Pt.     4       4000    10000   100     31
Pt.     5       13000   10000   100     40
Pt.     6       22000   10000   100     48
Pt.     7       31000   10000   100     55
Pt.     8       31000   -10000  100     55      B
Pt.     9       22000   -10000  100     0
Pt.     10      13000   -10000  100     16
Pt.     11      4000    -10000  100     24
Pt.     12      -5000   -10000  100     31
Pt.     13      -14000  -10000  100     40
Pt.     14      -23000  -10000  100     47
Pt.     15      -32000  -10000  100     55              L

Then I duplicated the frame a bunch of times in to an ILDA format 0 file and projected it with the Spencer projector. Here is the annotated result:



SO! There are a couple of interesting things going on here in the projector logic:

• Draw vectors with the colors in their START vertex, unless...
• If the source has the blank bit set, draw a blank vector
• If the destination has the blank bit or 'last' bit set, draw a LIT vector with the color of the vertex BEFORE the source (I call this 'holdover color'.) Basically, the projector does not blank and does not update the current color when the destination vertex has the blank bit set.

So, how do we accommodate these odd behaviors?

• We have to shift the color value ahead for every vertex
• We have to duplicate a vertex near a blank or last vertex and twiddle the blank bits:
• For the first vertex, we have to copy it, insert the copy after the original first vertex, unset the blank bit, and copy the color from the second vertex
• For embedded blank vertices, we have to duplicate the vertex BEFORE the blank, copy the color from the original blank vertex, and clear the original blank vertex's BLANK bit.
• For the last vertex, we have to copy it, insert the copy before the last vertex, and unset the 'last' bit on the copy (now the penultimate vertex)

That's not exactly how I would code it; there are some optimizations which could be made, but that's the basic logic of the manipulations.

I am not sure we have to do anything with sequences of blanks. I have not a test case with a sequence of blanks to see what happens. I think as long as the logic of adjusting things to accommodate the projector's weirdness in terms of src/dest blank bits and src color, it should work out.

This is what the adjusted file should look like. I haven't tried to create this file by hand; something will have to be written to generate it:

Point	x       y       z       Old Col.    New Col.    Blank   Last
0       -32000  10000   100     55          0           B	
NEW     -32000  10000   100                 0		
1       -23000  10000   100     0           16		
2       -14000  10000   100     16          24		
3       -5000   10000   100     24          31		
4       4000    10000   100     31          40		
5       13000   10000   100     40          48		
6       22000   10000   100     48          55		
7       31000   10000   100     55          55		
NEW     31000   10000   100                 55          B	
8       31000   -10000  100     55          0           (cleared)	
9       22000   -10000  100     0           16		
10      13000   -10000  100     16          24		
11      4000    -10000  100     24          31		
12      -5000   -10000  100     31          40		
13      -14000  -10000  100     40          47		
14      -23000  -10000  100     47          55		
NEW     -32000  -10000  100                 55	
15      -32000  -10000  100     55          ?                   L

[masterpj]

I really like where this thread is going and how it's developing.
Keep it up dogp!

Just wanted to say that.

[masterpj]

LaserBoy does not support time shifting in ILDA files because there is no such thing!

ILDA files have no information in them at all related to time!

The idea of that format is to be able to exchange art between different systems. It is nothing but consecutive frames of vectors with or without color definitions.

To that end, it works just fine!

That implies that whatever system is used to decode them and display them is responsible for optimizing them.

One only needs to consider the idea of 3D art. Think about it. What is the point of 3D art? ~To show it (in 2D) in different rotations. Every different rotation will have all kinds of different angles. There is no way to put dwell into a 3D ILDA frame in any meaningful way.

That needs to be done within the system that displays it.

If anything, I was trying to convince DogP that building a LaserBoy DAC would give him much better and more controllable results.

Waves are fully cooked and ALL ABOUT time! They have a fixed sample rate from the first sample to the last. The time shifts between the scanner and color signals are constant from beginning to end, based on the fixed rate.

James.

I think he means color shifting ?

[james]

Both DogP and tribble have noticed inaccuracies in the display of ILDA frames with this projector.

In a series of PMs the idea was kicked around that this might be due to the fact that scanners take time to respond to control signals and lasers do not. This issue is common to all laser projectors and any DAC worth using must have some time delay on the color signals to adjust for it.

The idea was proposed that this might be compensated for in the ILDA file itself.

My contention is that there are no provisions for this in the ILDA file format. It can't be done because an ILDA file is an arbitrary vector art format. There are no parameters for anything related to time. There is no fast rule for any particular scan rate. If you try to compensate by adding extra points here or there, the delay would be different for every different setting of points per second.

It looks like the firmware designers of this device got it wrong. They are looking at the anchor end of every vector for color and blanking when they should be looking at the destination end. Add to that, it also looks like they threw every weird idea they could come up with to "fix" that mistake, other than actually getting it right.

I guess this is just another example of why the ILDA file spec should be clearly written and truly available to the public from one genuinely reliable source.

James.

[mixedgas]

I sort of agree with James, this could have been handled much better in the micro-controller design phase. On the other hand, for 160$, its a pretty amazing unit.

Tribble, do me a favor. I'm just thinking ahead a bit. If you ever publish code or a program to correct for the Spencer's segment wierdness, do ONE thing. Change the owner name/frame creater field in the ILD file to "ADJUSTEDCOLOR" for modified frames, so we can tell them apart. Modified frames could wreck minor artistic havoc in shows using hardware that does the color the traditional way.

I'll tell you why I'm mentioning this. One of the intentions of the ILDA format was to stop the "Pulling" of points by hand to correct for scanner errors, back in the dark ages. Back then, each projector had its own wierd tuning that was like a personality. The industry and hobby has worked hard to eliminate the need for "pulling points".

Modified Wav files, I would not be so concerned about.

It would be interesting to know how this unit handles blanking delay, aka blanking shift, aka color lead/lag aka color delay etc.. On the green dpss, you need to lead by a few points or updates. On the direct diodes, you need to lag or be about even, depending on the scanners. That requires a O'scope and a carefully devised test frame to determine. I would not be shocked to find a setting for it in a config file some place on the SD.

Thanks,

Steve

[VJ AIWAZ]

ok so i went and picked up one of these today and its just what i thought it is impossible to get an RGB that is visible and still be 3A (4.95 mw)
this unit is putting out about 48mw on my coherent power meter and that is under modulation so its probably more like 60-80mw with no modulation

what makes this projector even more dangerous is the fact that it has a knob called focus that basically allows the unit to zoom the laser down to a dot

John

[tribble]

Well, here's my opinion on this projector and what I've found through my analysis so far.

I'm excited that there's a cheap mini projector with a built-in showcard that does a semi-respectable job of drawing graphics. Just the fact that it can be made to play so much content other than what it was delivered with at all is amazing and fun. The fact that there is FREE software available (LaserBoy) that you can use to create new art for it is FABULOUS. I haven't been this excited about my immediate prospects for laser joy for two years. The fact that the projector's firmware does not conform entirely to the standard defining the files it reads is regrettable, as it produces mangled art and makes creating new art that displays properly frustratingly difficult. I can't rewrite the firmware of the device. But, I think I can adjust the input to compensate.

I have documented above in detail how the Spencer projector does not display a standard ILDA file as the artist intended. I have also described how I think the ILDA file can be modified to display much closer to how the artist intended. I grant that it will not be exactly the same: to overcome the broken logic in the Spencer projector, one new point must be added to the frame each time a transition from a lit to a blank vector is encountered, plus one at the beginning and one more at the end of the frame. For some frames, this may be just two more points. For some frames, it could be dozens or more. It's understood that adding points will make the frame take longer to draw.

The idea was proposed that this might be compensated for in the ILDA file itself. My contention is that there are no provisions for this in the ILDA file format. It can't be done because an ILDA file is an arbitrary vector art format. There are no parameters for anything related to time. There is no fast rule for any particular scan rate. If you try to compensate by adding extra points here or there, the delay would be different for every different setting of points per second.

James, I understand you don't think it can be done, or don't think that the adjustments will be without unwanted side-effects, and I respect your experience and opinions. But, I'm curious (and perhaps stubborn) enough to want to find out for myself what's possible with this thing, since it's sitting on my desk and a "real" projector is some time off. No offense or disrespect intended, James! And, I have to give James a lot of credit and acknowledgement for helping me to understand enough about ilda files to even begin to describe where the problems are. Were it not for his help understanding how .ild files are put together in the first place, I would not know enough to have the (possibly incorrect) idea that something can be done to improve the Spencer projector's output. Most of my belief that this behavior can be accommodated with input file tweaks lies with my assessment that this is not a laser timing issue, but strictly a controller logic issue. I may end up wrong on that front.

But, my current hypothesis is that by adding and adjusting vertices to compensate for the Spencer projector's logic faults, the resulting image will be much closer to what the artist intended and be much more enjoyable to watch. I am willing to spend time (when I can find it) coding up a solution to test that hypothesis, and I will eventually post the results here for the group to see. If it works as I hope, I know that I personally will be far less frustrated trying to draw art to display on my Spencer projector without having to deal with lit vectors that display as blank or the wrong color and blank vectors that display lit. That is my motivation; I realize that the number of people who could benefit from this experiment can probably be counted on one hand, or one finger... but that's what hobbies are all about: pursuing your interests for the joy of seeing what can be done.

Tribble, do me a favor. I'm just thinking ahead a bit. If you ever publish code or a program to correct for the Spencer's segment wierdness, do ONE thing. Change the owner name/frame creater field in the ILD file to "ADJUSTEDCOLOR" for modified frames, so we can tell them apart. Modified frames could wreck minor artistic havoc in shows using hardware that does the color the traditional way.

Steve, I appreciate your concern and I am happy to modify the output to indicate that the stream has been "spencerized." I could overwrite both the owner and frame name fields with 'adjustedcolor', or I could choose something 8 chars or less and modify only the frame name. I'm not sure how I feel about overwriting the owner's credit from the frame, even if it's been adjusted to play better on the Spencer projector. Whatever the end result, I assure you I will do something along those lines. Also, the modified files do not even have to be named ".ild". The projector will happily play a file with any name, so long as it is listed in its control file (Picture.prg). For that reason I am thinking about defaulting the output file names to end in ".spn" so it will be immediately obvious that it is not a standard ilda file.

The Spencer showcard will never be a "proper" projector driver, and probably doesn't even bring out the best of what the rest of the hardware can do. Hopefully, DogP's soundcard DAC efforts will bring us closer to that goal. But, I am enamored of the idea of a tiny, standalone projector that can draw reasonable custom graphics, and I think I can improve the drawing and projection process with just a little effort, so I'm going to give it a try. If I fail, you can say "I told you so." If I succeed, I'm going to have a lot of fun. Either way, stay tuned.

BTW... you can currently purchase these online for $143 with the coupon DogP found. I forget what it is, but it's listed above somewhere. That plus an Osram PL450B gets you a nicely balanced 7-color projector for less than $200! Astounding!