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

[tribble]

Dog, trust me on this, tune at 8 or 10 degrees some time in the future. The smaller the angle, the faster you can go.

Steve

Well, the scanners will go faster, but if the showcard is generating artifacts because it can't decode the file fast enough, tuning the scanners faster does nothing for us until we can either get an ILDA pigtail or a soundcard DAC working.

[tribble]

Speed 20 is actually ~16.67KPPS (60us/sample). So, IMO, I'd tune for speed 20. According to the 20KPPS ebay auction, the galvos are supposed to be good for 20K at 20 degrees, and 31K at 8 degrees (maybe it's exaggerated, I dunno).

That is so funny... because I spent some time last night 'homing in' on the pps was at speed 20 empirically last night by adjusting the number of points per frame to keep time with a song I was trying to sync to. I came out with exactly the same number! (Well, I came out with 59.9902 or something, and when I saw that, I said "I bet it's clocked at 60." And it worked perfectly, at least over 90 seconds.

[mixedgas]

I dont have time (at least this week) to go into the scanner hardware math, but the way the world works, is to tune the ILDA patten fast at a small angle. You then open up the scan angle and slow down the scan speed as needed. Since you can measure the values of the pots (well most of them) with a DVM before you retune, its not hard to get back.

The above scheme works well with continious time controllers like the Spencers where things come out at a nearly constant rate.

Wish I had time to explain, but this week is going to be a train wreck.

Steve

[DogP]

BTW, here is the original factory tune at 8 degrees @ speed 20 (no blanking, so no goofy timing stuff):


Looks pretty good IMO... and it even looks decent with the original power supply (not much worse, mostly just the tail at the bottom is more pronounced). I assume at 8 degrees, there's not much stress on the power supply.


On the power supply front, I tried adding large caps, but the inrush current of too large of caps kicked in OCP. 10000uF wouldn't start at all, 4700uF was really good, but I could only have it on one rail. I was able to run 2200uF on both rails, and get a definite improvement (one 4700uF and one 2200uF wouldn't run either).

With both 2200uF, the +15V rail dropped to ~500mVpp, and the -15V rail dropped to ~400mVpp. This is with the caps at the power supply (measurements at the amp board), though there's space in the chassis, so I'll probably move the caps in there and attach them to the amp board and get better performance (note that most of the -15V rail is sag, so the PS probably isn't seeing much dip and isn't compensating enough). The +15V rail had the same sagging effect with the 4700uF cap (and only ~300mVpp). I'd also like to connect the original connector to this power supply, so I can close these boxes up nicely... and the caps at the amp board should definitely help with the longer wire run and connector losses.
+15V:


-15V:


Overshoot @ 25 degrees:


If this says anything, it's that large caps do help, and that a larger power supply would probably be even better, since it'd probably have better specs to begin with, and that it could handle the inrush current of the even larger caps. But, there's always the law of diminishing returns... in this case, <$20 gets you a big improvement over the factory power supply. Another $50 will probably give only a slightly better image.


The other fun project I did yesterday was building my HFD circuit.


I haven't wired the ins and outs to the circuit yet, but I printed it and attached it to perf board, and soldered that to the back of the board, attaching to the +15V/GND/-15V. I built the circuit exactly as the Cambridge schematic had it, so it should pretty much connect right into the existing circuit. I'll probably wire it up tonight, and hopefully try tweaking the tuning (or blow something up trying... 50/50).

I'll probably have to wait until I finish my sound card DAC to tune at higher speeds. On that note, I got my parts ordered... I'll probably get them on Wednesday or Thursday.

DogP

[DogP]

Success! I wired it up, made a couple modifications to the original circuit, and it works!

I ran the wires through GND vias and connected to the component pads:


And connected up to my circuit:


I changed the 7.5k and 10k resistors going into the summing amp, both to 4.7k (to closely match the original schematics, since I was adding another signal to the sum).

I didn't fully tune it (only adjusted LFD and the new HFD), but this is speed 20 @ 8 degrees:


I also noticed that they had a R and C on the output of the final amplifier (12 ohm and 0.01uF in series)... that seemed to me like they were trying to use it as a LPF, maybe as a replacement for real HFD. It wasn't in the Cambridge circuit, so out it went (pulled the resistor). Not much difference, except the tail on the bottom line has a steeper bend, so I think that's what it was doing. At speeds faster than 20, maybe it'd be noticable (I didn't take before/after pics of the other speeds). I'd be careful removing it if you don't have the HFD circuit though... it could be there to prevent high frequency oscillation.


DogP

[White-Light]

Turn the blanking on so you can see the wood for the trees - ie you'll see the ILDA pattern clearer with the blanking lines hidden.

[tribble]

Looking great! It'll be interesting to see how the soundcard dac works at higher speeds. BTW... Do you know what speed number corresponds to 20Kpps? Is it a linear function?

[mixedgas]

The R and C are a snubber circuit to protect the low cost audio amplifier from back emf surges and oscillations. You should consider re-installing it, but with a smaller C if needed.

Steve

[DogP]

Turn the blanking on so you can see the wood for the trees - ie you'll see the ILDA pattern clearer with the blanking lines hidden.

Heh, yeah... blanking would be nice, but the software on the MCU does goofy things (described earlier) which changes the timing when blanking is used. So it's hard to get a feel for what it's doing, so I turned blanking off.

BTW... Do you know what speed number corresponds to 20Kpps? Is it a linear function?

I did two days ago, but I don't remember now. It was 24 or 25... I'll check again.

The R and C are a snubber circuit to protect the low cost audio amplifier from back emf surges and oscillations. You should consider re-installing it, but with a smaller C if needed.

Ah, I think you're right. I'm used to seeing clamping diodes across coils, which I was going to install, except that the LM1875 datasheet says that they're already integrated in the package. The diodes should be sufficient for protection, right? I guess they probably don't damp oscillations though... maybe I'll check the amplifier output on the scope and see what kind of ringing is going on, and try to optimize it a little bit. The way that tail changed, it seems that it was overdamped before.

DogP

[DogP]

Okay... here is a graph and equation for "Speed" vs. KPPS (in DAC update speed, not including blanking weirdness or any other stalls). It should be close, though of course aligning to the exact edge, and the discrete steps on my scope cursor make it impossible to say it's perfect.


I also looked at the goofy hiccups, and I think I see the cause, and not exactly a solution, but a major improvement. It seems to be related to the actual ILDA file size, and the file system. For instance, a 4K (0x1000) byte file looks fine, but as soon as the file grows beyond that, it gets slower with hiccups (even just adding garbage at the end of a file, which doesn't even get used). 4K looked suspicious to me, since that's the default allocation size for FAT32 on this size partition. So, I decided to try some other allocation sizes. 8K and 16K seemed to make no difference. 2K seemed worse, and I think 1K was the same as 2K. BUT, 512 Bytes looks really good! I'm thinking this might have to do with the fact that an SD card has a block size of 512 bytes (plus who knows how any of this is handled in the MCU code). The downside is that it's REALLY slow on the PC... so copying files, saving changes to the .prg, etc. are noticeably slow.

I didn't investigate every file size and every allocation size combination, so feel free to experiment, but from what I've seen, the 512 Byte allocation size only improves things, which lets us run at higher speeds without hiccups (slight jiggle first noticed on the ILDA pattern at speed 28, vs. speed 21 on 4K allocation size). The refresh also feels quicker using the built-in repeat functionality, and the hiccups seem more minor (but I didn't go back and forth to verify). A lot of this might depend on size as well... I imagine a file that goes just barely into the next allocation unit will perform better with a smaller unit than one that is perfectly sized to the allocation unit. But I haven't seen one instance where the performance is worse using the smaller allocation size.

BTW, Windows XP wouldn't let me set the allocation size in the Format GUI, so I had to use this command line: format <SD card letter, i.e. f:> /fs:fat32 /q /a:512 . Of course make sure you have all your files backed up off your card, because it will erase it.

DogP