The Project board is for sharing projects based on Silicon Labs' component with other community members. View Projects Guidelines ›

Introduction

Back in 2012, before Christmas time, [member='Marius G'] and myself did a company wide x-mas tree soldering challenge project. This project was very popular among the employees. This year we decided to do it all over again. But, there is a slight difference from last year...

Back then, company wide meant 40-50 trees, so the project was doable even with a single soldering iron and a couple of evenings worth of organizing and soldering. Now, after the Silicon Labs acquisition of Energy Micro, company wide means more than one thousand trees, specifically we decided to do 1200 of them this year.

Volume of 1200 circuit boards is a total game changer. Since there is not enough soldering irons or electronic labs in the company (despite the name), we decided to do the Christmas tree 2.0, DFM-style (design for manufacturing). As always, time is of the essence, holiday season presents a hard deadline to be met. It didn't help that the final decision to do the project came in November. To get the kits to all company locations around the world before the holiday, shipping first week of December is required. No time to loose.

Design for Manufacture

First task on the agenda was to re-design the tree so it would be manufacturable on a larger scale. This generally means: Surface mount everything on the PCB!

On the 1.0 version of the tree, the LED's were through hole and had to be manually bent upwards. This requires manual labor and therefore not doable in this year's 2.0-version. We still wanted 12 LED's visible from all sides of the tree, the solution: Side-emitter, bi-color LED's.

 


sideemittingLED.jpg

Last years tree was focused on manual soldering and we didn't want to include too many additional components outside of the strictly necessary ones. Automated assembly opens up for having more components at a very minimal added cost, since assembly is so fast anyway. We decided to add a reverse battery protection circuitry, since it can easily happen that the batteries are inserted the wrong way.

 


We also had to come up with a new way of connecting the halves together. Last year, version 1.0 had a fancy way of sliding two PCB-halves together down the center of the tree. To get an electrical connection across to the second half, some blobs of solder had to be put between the two halves after the were put together. This would also require manual labor as there isn't really any standardized manufacturing process for handling the 3-dimensional finished trees. Some rethinking required. We ended up doing two separate side-branches that each connected to the main-part of the tree by header-connectors.

connection_between.jpg

Panelization

For simpler handling at the board assembly house, the PCB had to be panelized. We ended up on a panel-design with 8 trees per panel.

The idea is that each receiver of a kit must manually break out the tree-halves from the mini-panel. This ensures that each kit gets the correct parts and it simplifies the de-panelization at the manufacturer.

 

panel.jpg

 

 

Production programming and test

Manufacturing of electronics on a large scale also requires some sort of verification of each produced unit, typically called production test. The x-mas tree also had to get some software uploaded to the EFM32 on the main-halve of the tree. There was no time to make a fancy production test jig with needle-bed or similar. We decided to use a pre-made needle-pin connector, called tag-connect, for simple and quick programming.

tagconnect.jpg

After successful programming, the LED's light up, telling the operator that everything is OK, and that the LED's work. Voilà, all functionality is tested. To simplify it even more, we used code from the an0062 serial wire programming application note to enable a starter kit to handle the whole show.

 

prodtest.jpg

Component sourcing requires some open-mindedness... 

The delivery time of a batch of reasonably priced PCB's is typically 2-3 weeks, so from start of November we only had some days to do the schematic and layout. Maybe, just maybe, we could squeeze in time for a prototype-PCB to verify everything. During the schematic capture, it turned out that finding components that was actually in stock at a distributor was a potential show-stopper. After some compromises (see picture below, connectors that matched were not in stock), we had a design with a bill of materials we were confident could be sourced in time for day zero, production day.

not_matching.jpg

Time for prototyping or not?

After laying out the pcb, we did order a 3-day (expensive...) prototype-run from a nearby PCB-manufacturer. But after some careful re-planning and checking prices on 2-week PCB-delivery of 1200 trees, we decided to order the whole batch of PCB's without having received and tested the prototypes yet. I figured we might have time to sneak in some revised Gerber-files to the PCB-house after actually sending in the order.

After receiving the prototypes it turned out we had to do a slightly revised layout... Apparently the AAA-batteries that the battery-holder manufacturer has is slightly larger than the ones I had laying around... (not really true, but the holders were 0.5 mm too far apart...shit!) I called up the PCB-house and asked them nicely if I could give them some revised Gerbers, turned out they hadn't started looking at the files yet, so no problem, pewh...

 

battery_issue.JPG

Software

Marius G had his hands full with writing a revised version of the software for the 2.0 version of the tree. We had to go away from charlie-plexing the diodes because of their 3-lead connection, the charlie-plexing was actually quite compute-intensive, so this saved us some cpu-time, which results in longer battery life, at least when all the diodes are off. The capacitive touch button is still there, LESENSE is used for capsense. When the user touches the button it wakes up the tree to a random display of blinking LED's.

Production day, or so we thought

Finally the day of production came. The pcb's had arrived the week before, all components were in house at the assembly-facility. We decided to go there to make sure things went without a hitch, and also to hand over the final version of the code/production programmer setup. We spent some hours going through all the details of the testing, de-panelization and packaging of the kits. What stickers should be on the box etc. (This was thought out before-hand, but always good to double check everything), all the way down to details like; where in the box the batteries should be taped so the don't move around during shipping.

Lost components

After running a few panels through re-flow on both sides, it was clear that some components on the secondary side was missing... What had happened?

Turned out that they had fallen off in the re-flow-oven. Here's a picture of finding the components in the oven:

photo 9.JPG

By the way, the oven is slightly more capable than your average kitchen-stove:

 


oven_wattage.JPG

The battery-connector and the right-angle header on the secondary side where a bit too heavy to stay in place at the bottom-side during re-flow of top-side components. (A good reason to stay away from secondary side components, or at least try to put connectors and heavy stuff on top-side.)

 


The solution was to glue the components in place on the secondary side. There is a special machine dispensing glue, but this had to be set up, so there was not time to do full production that day. Next day production went without a hitch, it only took a couple of hours pushing all 1200 boards through assembly/re-flow. This is what 1200 flat-packed Christmas trees look like:

flat_packed.jpg

 


Folding the boxes and packing the kits is another story, it is done the old fashion way and is labor intensive! Here is a snapshot of half of the 1200 boxes, folded and ready to be filled:

boxes.jpg

 

Result

1200 xmas trees; enough to make a 12 square-meter forest - or hand one out to each employee of Silicon Labs!

  • Projects
  • 32-bit MCUs
  • I've attached the code to this post. Unzip it in your Silabs root directory and it should compile out of the box Robot Happy. Let me know if you have any issues.

    A few words about the software running on the trees. There's two things that are pretty interesting.

    Frist, we need a good source of random numbers. To generate those I used the AES module. The AES key is simply DEVINFO->UNIQUEH || DEVINFO->UNIQUEL || 4 || 1. The last two numbers were determined by a fair dice roll and are thus guaranteed, by me, to be random. The data used is simply a counter counting up from 0. Since each block is 128 bits long, we essentially have pseudo-random numbers for as long as the earth lasts. The nice thing about doing it this way is that it's incredibly fast. Only about 70 clock cycles for generating 4 words of randomness (AES time). In the XMAS v.1 project I also used the AES module, but in feedback mode. I took the previously random generated data and fed that back to the AES. The downside of doing that is that there isn't any guarantee that you won't get stuck in a small loop of certain numbers that repeat. Of course, being pseudo-random, this means that you will essentially get the same pattern every time (until you press the touch button the first time).

    The second thing I want to talk about is the way I did software PWM to make the lights fade in and out. I use the RTC as the main engine behind this, which limits the frequency, but it is sufficient to provide nice looking LEDs. This also allows the tree to go down into EM2 in between toggeling the LEDs. Basically, I generate a list of events that needs to be executed. This list is sorted on timeout.



    typedef struct
    {
      uint16_t time;
      uint16_t portClear[PORT_IN_USE];
      uint16_t portSet[PORT_IN_USE];
    } event_t;

    For every event we do (conceptually):



    for (i = 0; i < PORT_IN_USE; i++)
    {
      GPIO->P[i].DOUTSET = event[x].portSet[i];
      GPIO->P[i].DOUTCLR = event[x].portClear[i];
    }
    RTC->COMP1 = event[x].time

    To avoid tearing, the event list is double buffered and swapped every time the RTC overflows. The trick of course, is generating the event list. This means that executing the RTC handler is quite fast, and we can sleep a lot of the time.

    I did a lot of tweaking to make sure that the batteries last for two weeks. The problem of course is that LEDs draw quite a lot of power! So to conserve power, in the regular blinking mode it is only blinking at half strength and fairly seldom. You can increase this of course, at the expense of battery time.

    All of the effects are implemented as engines which do the different effects, it's an easy interface, so expanding with your own should be easy. The names of the effect engines are: blinkengine, faderengine, makiraengine, morseengine, partyengine, rotateengine and testengine.



    Attached Files

    0
  • Thanks very much for the sharing this!  I'd like to make more of them.  Will the Eagle and Gerber files be available, as they were for last year's design?


    0

  • brouhaha wrote:

    Thanks very much for the sharing this!  I'd like to make more of them.  Will the Eagle and Gerber files be available, as they were for last year's design?



    I'm happy to hear that you are interested in making some yourself!  :-) This year's tree we only have gerber-files and schematic in PDF/OrCAD-format. I've attached it.

    The reason for not using Eagle is basically the short time from project-start to manufacture. I chose to use the standard work-flow we have for other EM-kits that we produce at the same CM. I figured using the same work-flow towards them would minimize the risk, since everything had to work at first try. Also, because of the very time constrained project, I had literally two days to finish schematic and layout (and those two days were saturday and sunday...). So I chose to spend my time on schematic and component-sourcing (turned out to take almost a week just to find components that we could source in time). There was no time for f*-ups with footprints/panelization/paste-stencil and so on. It had to be 1200 pcb's straight from rev00 so to speak. 

    It shouldn't take too long just redoing the schematic and importing the new footprints in last years eagle-design. That was basically what the layout guys did, only in their CAD-software.


    Attached Files

    0
  • Thanks! I plan to make some to give out to family and friends in late 2014, and a small forest of the to put in my window. The only change I plan to make is to add a regulator and MicroUSB connector for external power, and have it remain active continuously when on external power.

    Thanks again for sharing the design and providing the opportunity to win one! I'm taking it to my family's dinner tomorrow for use as a centerpiece, and to the 6502 Group holiday dinner on Sunday.
    0
  • Thanks for making this great gift! My five year old loves this new christmas decoration (Look mum, it blinks differently if you just put your finger here :-) . I think I will need to introduce him into the world of programming using this...


    0
  • I'm a lurker on this forum, but strongly interested in the Gecko family Robot Happy


    I wanted to thank you guys  for this great gift! And how it was received by my 3 year old?


    One picture is worth a tousand words:


    Ania and  Christmas Tree.JPG


    0
  • Hi,

     

    I have one of these christmas trees(the version with the side-emitter LEDs). Unfortunately my son has been a little heavy handed with it and one of the LEDs has fallen off. Does anyone have the manufacturers part code for these LEDs?

     

    thanks

    Simon

     

    0