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

[colouredmirrorball]

It's definately a fault in the projector logic. If it was a delay issue the white would still be there.

I wonder what went wrong in the factory.

[tribble]

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

Wow, John, thanks for the measurement! Is that power out of the box? Were you able to dial it down? What was the minimum you could achieve and still have all three lasers turning on to give all 7 colors?

I need to find a laser power meter that won't break the bank.

[james]

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.

I think we got our wires crossed here.... My statement is that the time delay between the scanner and the color signals cannot be encoded into an ILDA file. I believe that this projector's problem CAN be fixed in an invalid version of the ILDA file. I'm glad to hear that the modified file format does not need to be called a *.ild file!

James.

[mixedgas]

Tribble, You've done so much great work on this thing. I'd be glad to calibrate you a silicon cell and attenuator at 3 wavelengths and 50 mW each.
Readout is with your voltmeter. You'll get a chart with it.

I'll supply the ceramic attenuator material and the 10 turn potentiometer/load resistor. You supply the silicon photo cell.

Digikey part numbers 751-1012-ND, 475-1350-ND or PDB-C110-ND for example, would work just fine.

Glad to hear you can call it dot SPN.



Steve

[VJ AIWAZ]

well it was the reading after i zoomed down to a dot it was fluctuating from 0mw(some frames have black outs )to about 47mw depending on the frame and that is out of the box new i haven't touched a single thing that any user is not supposed to touch
i was even able to get it to lock in at about 45mw or so by switching it to pause when it was playing a hot frame

so basically its totally illegal it is a class IIIB product and should not be sold with out a variance(in effect for Spencer gifts) a product report on file with the CDRH a or sold to any one who does not have a valid variance and in NY (where i am) with out a NYS class B operators license (and a $600 registration fee to NYS)
all the proper import papers for a non ionizing radiation emitting device and a bunch of other stuff that would need to be done to the projector itself to make it complaint

[tribble]

I think we got our wires crossed here.... My statement is that the time delay between the scanner and the color signals cannot be encoded into an ILDA file. I believe that this projector's problem CAN be fixed in an invalid version of the ILDA file.

OH, sorry, I completely misread your post!! I am glad to hear that.

Tribble, You've done so much great work on this thing. I'd be glad to calibrate you a silicon cell and attenuator at 3 wavelengths and 50 mW each.

Wow, Steve, thanks!! I will look at the parts tomorrow and order one. I don't know what else to say.


... and in other news, my friends, we are getting closer:



tribble

[james]

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

Steve

That makes no sense in the context of this conversation.

The internal DAC that comes with this projector doesn't play waves!

As far as I know there are two pertinent kinds of waves for use in laser display; standard, generic multi-channel waves made from ADAT transcriptions with arbitrary signal levels and no laser specific formatting or sub-code information and LaserBoy Formatted Waves.

LaserBoy waves follow all the rules of the Microoft RIFF WAVE file format and the extensions to the wave header are "legal". LaserBoy waves open in any wave player or editor that supports waves of 6 or 8 channels.

LaserBoy Formatted Waves solve the problem of the time shift between the scanner and color signals by sample shifting between the individual tracks of the wave. The number of samples each track is shifted is stored in a block of integers in the header of the wave so that the wave can be read, un-shifted and properly displayed in the LaserBoy vector editor as 24-bit color, framed vector art.

LaserBoy also has the ability to open a LaserBoy Formatted Wave, read the sample shift block of integers and re-shift all the tracks and save that with a new block of integers to suit a different laser projector than the one it might have been originally designed for, without having to regenerate the wave.

LaserBoy knows how to CORRECTLY read all formats of ILDA and it does a really nice job of optimizing vector art into waves to produce a very nice (scanner safe) display.

LaserBoy produces waves that are an exact (not arbitrary) 16-bit scanner, 8-bit per color channel representation of the ILDA art from whence they came.

James.

[mixedgas]

Quote:
Wow, Steve, thanks!! I will look at the parts tomorrow and order one. I don't know what else to say.
End Quote.

No big deal, I have a 75 mW air cooled ILT Krypton that I need to put some run time on to keep the tube healthy. Thus your red will be calibrated at 647. Green will be 532, and blue will be 488 or 445.

Silicon's slope is not that bad, except in the blue, so ballpark cal at three points is pretty good.

Round can detectors with big sensors can be press fit in a piece of brass, and I love to mess with my lathe. That takes care of the housing.

Steve

.

[DogP]

Wow... I don't show up for a couple days and all kinds of cool stuff happens. Maybe I'll leave for couple weeks next time.

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

Yep... I don't want to get into this discussion again, other than to say I agree that the ILDA format doesn't specify time (but does specify sequence... it's not just a point cloud), but on the Spencer's projector, a .ild file plus the specifications in the .prg, does specify time. If we do the pre-processing to make it play well on the Spencer's projector by shifting colors and manipulating points in a file that just happens to be a valid (but bad looking) .ild file, I think that's still okay. Just so it's clear that it's meant for the Spencer's projector at a specified rate, not a .ild for art sharing.

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

Attachment 36396

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:

Attachment 36397

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)

Nice tests... couple questions. The missing white, are you sure that's not lazy green again? What if you changed the colors to have red or blue be the color to turn on for white? Also, regarding the weird handling of the blank vectors... does it handle a black (non-blank) vector differently than a blank one?

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.

There's no config file on the SD card (other than the .prg). I plan to probe around with the scope tonight though, so I'll try to determine what it does in regards to dpss vs direct. From what I've seen, my guess is nothing (green always seems much slower than the rest, unless they tried compensating, but didn't compensate enough). You could probably drive any color with any signal and they'd all have the same timing (though don't try that, because IIRC the green laser polarity is reversed on the connector).

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

Hmm... interesting. That seems to support what everyone's been saying, that these shouldn't be visible in light areas, yet I can clearly see mine with the lights on. Have you checked the power of so-called IIIa laser pointers? I didn't notice the output of each laser being much brighter than the cheap laser pointers. Also, is that 48mW with all colors (so ~16mW each), or did each color do about 48mW?

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.

Yes, I like the idea of changing the file extension. Of course there's other Chinese SD card driven laser projectors sold elsewhere that probably have the same controller (not just ones sold by Spencer's), but I think .spn is a reasonable extension. Though, now I wonder whether the old version has the same quirks as the new one (they're different software on different MCUs).

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.

I agree... even when I get the soundcard DAC built, I plan to make it switchable between the embedded SD card and USB soundcard... the standalone portable-ness of it is one of the biggest features IMO.

DogP

[DogP]

So... I spent some time looking at this last night. It got kinda late, so I didn't feel like uploading all the pictures and writing a long post... so here's a short one until I get home and upload the pics.

First, regarding the stray points that tribble reported on the higher speeds. I'm fairly sure that's caused by long .ild files, and probably the SD card buffering. When I played his red ILDA test pattern at high speeds, I got a completely predictable repeating set of stray points. But they weren't in the file, and didn't appear at low speeds. His file had the test pattern repeat many times inside one .ild file (so it was a larger .ild file)... but if I play just one frame, and use the repeat functionality in the .prg, it doesn't suffer from the stray points (but has a lower frame rate, because it re-buffers at the beginning of the file).

Also, I looked at the output of the first stage amp (LM324) from the controller board on the oscilloscope, and there was no noticable degradation at higher speeds, so I think the signal coming out of the controller board is fine. The higher speed degradation is most likely on the Galvo/Amp side of things. Related to that, I swapped the LM324s for some nicer opamps in the X section on the amp board, and it looked terrible... probably beyond adjustment, so I'm gonna try swapping to some of the others that I have laying around. If nothing comes close, I'll just swap the old LM324s back in. The circuit isn't too complex either, so I'll see about drawing up at least a partial schematic, which would make it much easier to analyze the circuit (I snapped a pic with the LM324s off, so I could see where any of those traces went without having to check them with the meter).

I've got a lot more to report... but it'll have to wait for the pictures to make sense.

DogP