Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 37

Thread: A few "almost there" shots of the new board.

  1. #11
    Join Date
    Jan 2006
    Posts
    22

    Default

    WOW. I have soooooo much to learn!

    Absolutly excellent work yaddatrance!

    Looking forward to the production release.

  2. #12
    Join Date
    Jun 2005
    Location
    SoCal
    Posts
    508

    Default

    Thanks ElGordito! I can't wait either...

    In case you want to know what a brick of chips looks like fresh from the factory.


    Exactly 1000 SX52 Microprocessors in vacuum sealed packaging...

    The parts are all trickling in, and my garage is getting packed...
    We're setting up for a production run, and I got to say, it's freaking scary...

  3. #13
    Join Date
    Oct 2005
    Location
    The Netherlands
    Posts
    97

    Default

    even that looks cool!

    Keep us updated yadda! Very cool!

  4. #14
    Join Date
    Jan 2006
    Location
    Charleston, SC
    Posts
    2,147,489,446

    Default

    Yadda;

    I am sitting here in awe at what you have accomplished! You've designed a custom board and went through the trouble to have it professionally etched and silkscreened for what is likely a one-off or at best limited production run... I'm speechless!

    (As an aside, what does your "day job" entail? I'm guessing you're an electrical engineer of some sort? Are lasers part of your day job?)

    Anyway, back to this board you've designed... I can follow your reasoning behind wanting better color control, and I appreciate the increased bandwidth required to impliment 8 channels of 8-bit color information for a single projector, but you mentioned above that you used this new board of yours to control 7 separate sets of galvos - 3 of which were part of a whitelight setup that would require full color control. So how did you get around the bandwidth problem between the board and the computer? (Don't tell me you loaded the entire show onto the board first?)

    I would have thought that trying to run that many scanners, with all that color data besides, would end up overloading just about any connection - including USB... Let's see... assume 30,000 pps times 2 bytes for each coordinate times 2 scanners = 120,000 bytes/second for each scanner pair. Now multiply by the 8 bytes of color control for each point and you're at 938Kbytes per second for a scanner pair with full color control. Now multiply that by 7 sets of scanners and you're at 6.4 meg/second. That's a lot of data! (Especially since you can't afford to dip below that rate at any time without adversly affecting the show.)

    Then I got to thinking about the ILDA file format, and realized that in order to support 8 bytes of color information, you had to come up with a new file format, which also means you're probably running custom software in addition to your custom hardware. So in addition to being highly skilled in electronics, you also write your own laser show software?

    Gee, did I miss anything? And what are you going to do for act II?

    It's too bad there isn't a larger market for this kind of thing. I'd bet you could put Pangolin out of business! (Wonder if they'd be interested in purchasing your design?) Then again, you clearly have plans to construct more of them. (What else are you going to do with 1000 SX52's?)

    Anyway, back to reality: For the rest of us mortals, is there any possibility of you building a stripped down version of this design - say, one that might only support 2-4 sets of scanners and not be built with parts that have 5 nines of tolerance? Something with a price tag that is less than 4 figures? And more to the point, will it include the custom software that you've written to take advantage of all these new color features?

    I have to admit that for the moment this is not something I can afford. But there will come a time when I will want to upgrade. And before I even think about saving up for a used Pangolin or X-29 system, I'd rather have a hard look at a controller designed by someone in the business... A controller designed specifically to address the inherent flaws of other units.

    When you get time, please keep us informed about the progress of this project!

    Adam

  5. #15
    Join Date
    Jan 2005
    Location
    USA
    Posts
    457

    Default

    Quote Originally Posted by Buffo
    Yadda;

    I would have thought that trying to run that many scanners, with all that color data besides, would end up overloading just about any connection - including USB... Let's see... assume 30,000 pps times 2 bytes for each coordinate times 2 scanners = 120,000 bytes/second for each scanner pair. Now multiply by the 8 bytes of color control for each point and you're at 938Kbytes per second for a scanner pair with full color control. Now multiply that by 7 sets of scanners and you're at 6.4 meg/second. That's a lot of data! (Especially since you can't afford to dip below that rate at any time without adversly affecting the show.)

    Adam
    Im not part of the dev team or anything but if I remember correctly he is utilizing the capabilities of USB 2.0 so he can get throughput of 50MB/sec so that rather simplifies the bandwidth constraints.

    Also: From my understanding the board uses a frame buffer system and everything is streamed to the board and the sx52's processing power and IO lines are utilized to keep everything realtime.

    No loads, no waits, no hot spots, no bullshit. Just a great solution

  6. #16
    Join Date
    Jun 2005
    Location
    SoCal
    Posts
    508

    Default

    Hi Buffo! Thanks for the compliments...

    Spec is absolutely right... We skipped to a current generation bus and
    dedicated a complete micro to nothing but handling the bus protocol.
    The SX is dedicated to handling the laser timing and output...

    USB2.0 High Speed... which will push up to 480Mbps (50-60MB/s)

    We actually did a lot of tests using IDE and firewire as candidate busses for
    the bandwidth we needed. IDE's PIO mode was too slow, and Firewire
    had a lot of licensing encumburances...

    The 1000 chip run was actually necessary to ensure that we had ANY
    chips available as the manufacturer did a "last call" on that specific model.
    Apparently not enough people wanted the 800lbs gorilla of microcontrollers...

    A subnote for microcontroller designers... The most important thing when
    looking for speed is not Mhz (though we're clocking ours at 100Mhz) it's
    the actual pipeline... the "big" PICs for example has a 4 stage pipeline which
    means that say a 18F458 running at 40Mhz is actually only capable of 10Mhz
    of usable speed if you don't really carefully plan out your program execution
    and steps. The timing for the board was so critical that we ended up going
    through lots of micros before we found one that could handle our load,
    It was a lot more painful than it sounds since we had to learn the specific
    assembly code for it, figure out how each manu handled the special registers
    and eek out some performance tuning.

    Short-term we're migrating our designs to the SX48, but thinking of jumping
    up another level to the IP3000 class of processors which make the SX52
    look small and tame. I don't think the IP3000 is considered a microcontroller
    though...

    We're thinking that combining an IP3000 with a FPGA will get us into
    some really ludicrous territory... so that's where the next gen stuff is heading.

    Oops, I got to run and drop my surfboard off at the shop to get fixed before they close... So I'll continue blathering on later...

  7. #17
    Join Date
    Jan 2006
    Location
    Charleston, SC
    Posts
    2,147,489,446

    Default

    Quote Originally Posted by yaddatrance
    Oops, I got to run and drop my surfboard off at the shop to get it fixed before they close... ...
    Jezzz... All this, and you SURF too?

    USB2.0 High Speed... which will push up to 480Mbps (50-60MB/s)
    I know that the USB2.0 spec is 480Mbps, but I didn't think anyone had actually attained anything close to that in real life. Evidently you've figured out a way to tap at least a significant fraction of that bandwidth with your design, while avoiding the slowdowns imposed by most OS's.

    By the way, what OS are you running this custom software of yours under? (If I had to guess, I'd guess Linux?)

    And if you're worried about Firewire licensing issues, then you clearly have a product in mind that you will be marketing at some point. (Yay! Everyone rejoice!)

    The most important thing when looking for speed is not Mhz (though we're clocking ours at 100Mhz) it's the actual pipeline... the "big" PICs for example has a 4 stage pipeline which means that say a 18F458 running at 40Mhz is actually only capable of 10Mhz of usable speed if you don't really carefully plan out your program execution and steps.
    You're speaking of branch prediction, yes? Trying to avoid having to flush the whole pipeline and start over if you guess wrong on a branch decision... So why not go with a shallow pipeline (fewer stages) design and suffer the drop in clock speed? (Realizing that to accomplish all complex instructions in just a few stages mean that they must take longer, thus the clock must be slower...) Or were there no options in this category?

    The timing for the board was so critical that we ended up going
    through lots of micros before we found one that could handle our load,
    It was a lot more painful than it sounds since we had to learn the specific
    assembly code for it, figure out how each manu handled the special registers
    and eek out some performance tuning.
    This would be a major project for a mid-sized engineering department at any normal company. You pulled this off in your spare time? I'm impressed beyond words... Just how long have you been at this?

    thinking of jumping up another level to the IP3000 class of processors which make the SX52 look small and tame.
    How will this affect the price of the boards? (My guess is, more expensive...)

    So I'll continue blathering on later...
    Please - blather on! It's intriguing to read about your progress, even if it does stretch my electrical knowledge right to the limit in order to comprehend what you are trying to explain!

  8. #18
    Join Date
    Jun 2005
    Location
    SoCal
    Posts
    508

    Default

    Yep, best time to surf is actually winter in here in San Diego...
    I'm not actually very good, since I was transplanted here 5 years ago,
    but I have lots of fun anyways.

    The laser board is pretty much just me and my friends trying to fix
    all of the reasons we grew to hate doing laser shows for fun/profit... We
    were using industry standard solutions before and waiting for that "perfect"
    system to come out... we waited and waited, until we realized that we
    could just skip ahead and make it for ourselves in much less time.

    The FB16 actually enumerates as its own USB Controller, so it can allocate full
    bandwidth if necssary (vs devices which use, say, a HID class which is rate
    limited)... The dedicated processor also really helps.


    We actually develop on Windows, Linux and OSX... I don't actually have
    a strong preference. (If I had to choose it'd be Tru64, but that's pretty much
    kicking a dead horse)... We have the board working on all three, but
    I like linux for server apps and windows for the painlessness of developing the
    user interface... OSX takes second place to one or the other depending on
    what it's doing...

    I'm excited about bigger and faster because we can lose this analog problem
    with scanheads if the hardware is beefy enough... A set of scanheads controlled
    by a DSP with pure digital signals until the very last step would go a long way
    in solving a lot of the problems we see today. Consider that when you
    run a "tuned" scanhead at faster than its tuning that it still displays a rock solid
    image, just compressed... by using a physics-on-a-chip engine, you could
    compensate for the compression, etc. etc. etc... The problem of course is
    that to be effective you'd want to send signals out and sample the position
    detector well into the Ghz range... which is actually quite simple by today's
    THz engineering levels.

    I guess it's the consideration that your cell phone, manufactured by
    penny a day sweatshop workers shouldn't be more high tech than gear
    that costs more than a semester of college or a nice used car.

    Somewhat amazingly, actual production costs of "really high tech" systems
    which use VLSI/BGA and all the modern goodies is much lower than
    using discrete system components. The tooling costs of getting set up and
    the learning curve of engineers developing such systems is what prevents
    more people from going that route... luckily we already went through that
    learning curve through day jobs

  9. #19
    Join Date
    Jan 2006
    Posts
    22

    Default

    Yadda,
    Let me know if you need any beta testers.

  10. #20
    Join Date
    Oct 2005
    Location
    The Netherlands
    Posts
    97

    Default

    Quote Originally Posted by ElGordito
    Yadda,
    Let me know if you need any beta testers.
    whaha! Yeah, I second that

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •