Vertical Geenrator Platform Build (Part 1)

Spent some time working on platforms.  I need to show mostly finished platforms at the next Baylug meeting.

 These two pictures show the below compartment taking shape.  It will have two Minifigs inside controlling the power feed into the containers (one of which can be seen later). I plan on using a blue LED backlight to light the compartment.. 

 

This shows the windscreen type cover for the compartment so that you can see down in.

 This was a fit check to see how everything was going to fit on it.

A first look at a mostly completed structure.  Probably going to change the slope color to sand green so that it stands out or at least surround the opening with sand green.  Still needs detailing and some structure in the front half still.

Light Buddy Firmware (part 7)

Back to the LP5569.  I have been working on this on and off for several days and finding very little info on this.  Dont know if it will help the Maker community, but I will publishing the initialization routines, at a minimum, once I am done.

I started by writing a small set of routines to interface to the LP5569.  Then I started writing an initialization routine, followed by a status routine.  To start the testing I did some very limited writes and reads.  However everything that came back was all zeroes.  Because of the way my I2C routines are structured, I know that LP5569 is ACKing the request, otherwise the routine would hang. (Great for testing, but bad news in production.)  With out a USBEEE to decode the I2C messages, I had to resort to doing the decoding the old fashioned way, with a scope.  The scope confirmed that I indeed was getting back zeroes and that all portions of the I2C protocol was working.

I go back to the data sheet to see what I am missing.  What I was trying to do was map the LEDs to the one of the 3 Control Engines in the LP5569.  While the data sheet is not bad, it does suffer from assumption.  It is obvious that the writer was very familiar with the LP5569 and assumed the reader was almost as knowledgeable.  I had missed in the register definition section that the Engine Mapping registers were READ ONLY from I2C.  So initializing these is a waste of time.  Once I got past this the writing and read back worked much better.

The next problem was setting the PWM state for each of the nine LEDs.  Again writing did not seem to have an effect.  It always return all zeroes.  My first thought is that this was a read only register too.  But it is clearly marked R/W.  So I did a search on the data sheet for all mentions of PWM. In section 8.3..1.2.1 it says
  
"This register cannot be written when the program execution engine is active,which could result in undesirable behavior. Care should be taken to update these registers only when the program execution engine is idle."

Looked at all of the engine control registers and read them back.   All were in the default state, which is off.  The register definitions never mention idle as an Engine state, so this was causing some consternation on my part.

Continuing the search, I found in the section on LED fault detection a sequence listed.  In this sequence, you need to first enable the LP5569 through the CONTROL register (called the CONFIG register in the register summary table) and then set the PWM setting to 100%.  So I switched the order and now I can control the PWM percentage.  A few other setup registers were programed and checked, with success.  Now it is off to seeing if I can actually control the LEDs.

Light Buddy Firmware (Part 6)

Got some what side tracked by my day job. After the little problem with the I2C address and the fact that my UBEEE died on me, I decided to work on the PIC controlled LEDs and the sensor inputs. Here are several pictures of the unit with the sensor input attached and the LED output attached.  You will notice in the second picture that the sensor board attaches to the top of the Light Buddy^TM , a nice byproduct.

The LEDs were straight forward.  They were up and running quickly using the code from the Brick Buddy.  I am not happy with the performance of the two PWM LEDs,  These are randomly generated pulse widths, which in turn give a random brightness to the LED.  While one works as expected, the second one seems to have less range of brightness.  The two channels are setup identically and programmed in the same loop.  So this is somewhat of mystery right now.  But there are bigger problems to tackle right now, since I am convinced this is not a hardware problem.

The sensors were also straight forward.  The three switches are Interrupt On Change (IOC) capable and a simple interrupt routine handled all there state.  The POT tool a little longer, acutally had to get the scope out to determine what was what.  But after making sure that all of the bits in the path were set correctly, it started delivering data.

This part is now finished and it is back to the LP5569.

Light Buddy Firmware (part 5)

After installing the LP5569 on one PCB the other day I have been struggling for two days to talk them.  Being 4x4mm 28 pin parts, I decided to use the reflow toaster oven to put these parts down.  While I could not find any shorts, there was no acknowledgement.

This forced me to get out my USBEE device to look at the I2C bus to make sure it was doing what it was supposed to. It confirmed that no ACK was coming back, but that the data coming out of the PIC was OK.

What I did notice though was that while I was only reading this address, the display was showing either a read or a write depending on which chip I was trying to address.  That is not right.  I went back to the data sheet to look at addresses.  Most of my experience in I2C has been where the address is in 8-bit format and the Bit 0 is not used, so you just put the address in as listed.  As you can see from this figure, that is not the case with the LP5569.  The actual byte value used needs to be shifted left one bit. 

The lesson here is to always READ THE DATA SHEET first.

Plans Change

Plans change and we have to adapt.  We were not accepted to the Bay Area Maker Faire this year.  Since this May deadline is no longer present, I am shifting to presenting improved Lego products for Bricks by the Bay and then maybe a product for the European Train Show in July, my other passion.

While we are disappointed, there is still plenty to do for the other events coming up this year.

Vertical Generator Implementation

Here is a picture of just how the vertical generator might be used.  As one of my advisers is quick to remind me, detail is what makes it real.  So I have added a lot of hoses, need some more minifigs and other details on the platform now to make it look more real.

Light Buddy Firmware (part 4)

Achieved all of the basic functionality, internal EEPROM, timers, USB, and the support structure.  Tested all the features and they look good.  What I like to do on each one of these is test the timer routines to make sure all the arithmetic was correct.  You would think after about 30 of these PIC implementation, I would have this down, but I continue to surprise myself with stupid mistakes.

Here are three scope shots that show the pulse width for the 1ms, 10ms and 25ms timer settings.  I use the timers in both a blocking function and as an interrupt driven timer.  The PIC18F25K50 has two 16 bit timers that I use for this.  The two 8 bit timers will be used for the PWM engines.

Here are the scope pictures.

1 ms

10 ms

25 ms

The timing was not too bad.  If the scope's calculation on frequency is correct then the actual timing was

1ms    => 1.005555ms  or 0.5555% error
10ms  => 10.01645ms  or 0,1645% error
25ms => 25.05286ms  or 0,21145% error

This is good enough for timing the light s on a MOC.

Next is to install the LP5569 LED controllers and get the I2C bus working.  Never used these before so it should be interesting.  Plus these are very small parts, so installing is going to be fun.

Light Buddy Firmware (part 3)

Well the boot loader worked, at least it would come up and the PC would recognize that it was in bootload mode.   I could then load a file and program it.  So it all looked good.  But resetting the device only brought back the bootloader.  Since the bootloader was compiled hex code from a previous project, getting into it to see what was happening was going to be problematic.  Besides I would have to get the professional version of the XC8 compiler to make it fit in the required space.  Not something I wanted to do at this point, even for a month.

Looked at the source code to see if I could get any hints as to what was happening and compared the schematic against the one from the project the bootloader came from.  And that is when the light bulb went on or the load of bricks hit me (the later being more apropos considering what this is intended for).

To force the PIC into the bootloader mode you need to hold down the push button connected to RB2.  Reading a low then causes the bootloader firmware to enter bootloader mode, otherwise it will just launch the program at 0x1000.  Well like any pushbutton implementation there is a pullup resistor to force the input high when the button is not pressed.  And....................it was not installed.  Put the resistor in and everything works the way you would expect.

Now I am off to building all of the required infrastructure (I2C, EEPROM, Timers, LP5569 driver, etc) to make the device functional.

Light Buddy Firmware (con't)

Back after looking for bad solder connections and the like.  I made a few last minute changes when laying out the PCB, to make the routing more straight forward.  One of these was swapping the labels for RB5 and RB6.  Well RB6 is part of the In Circuit Serial Programmer.   The fix required cutting a trace and jumping one via to a trace.  If you look real close at the PCB, just to the left of the PIC, you might be able to see it.  Need to use one strand of a 28AWG stranded wire to do the jump.  The via holes are only 10mils.  Here is a better look.

Now it connects and the bootloader loads.  Maybe now we can get somewhere.

Light Buddy Firmware

Here is the minimal built Light Buddy^TM , that we will be using to bring up the firmware.  First step is to connect the PICKit3 and program in the bootloader. And it did not work.  The PICkit3 could not recognize the connection, NOT GOOD.

Light Controller PCB Assembly

Received the PCB and started building it up.  Here is the blank PCB.

My usual bring up of a new design is to install the power section and the USB connector, then test the power for shorts and opens.  Once I see all of the power rails up and running I will move on to components.  This is to prevent any component waste..

Here I have installed the PIC18F25K50 and its supporting parts.

Just to the left of the processor is a pattern for a TAG-Connect programmer connection.  In these tight spaces, I find this is the best.  Since I usually use the HID Bootloader methodology, I use this connection once to load the bootloader and then use the USB interface for all loading and debugging (traditional printf statements).

Now it needs to be mounted so I can use it for programming.  This device was designed to sit on a 6x8 plate.  So I drill out the four corners with a #43 drill bit (2-56 body clearance).  I use the partial holes on the back side underneath the studs as guides.

 

This puts the holes in the center of the studs as this picture shows.

Next step is to assemble the PCB to the plate.  I use 1/8" ceramic spacers for minimal clearance and 1/2" long 2-56 flat head screws.   This can be problematic trying to keep the screws in place while trying to assemble the spacers, PCB and then the nuts, as this picture shows.  Two of the screws have popped out of their holes.

So once the 4 screws are in place, I place a another 6x8 plate on the bottom as shown here.  This forces the screws to be seated all the way and makes it a lot easier to mount the spacers and PCB.

This picture shows the mounting plate with screws and spacers ready for the PCB to be attached.  The other 6x8 plate is holding the screws in place.

And finally the PCB is attached.

Now it is on to programming.

Vertical Generator

I started building the vertical generator as a standalone model so that I can test the functionality and figure out how to light it.  The base needs to be tall enough that a minifig can standup and look like they are controlling what is happening, realizing the spinning axle will be in the center.  Also needs to be a roof light so that you can see everything in the control section.  There will be two  minfigs in there. Here is a view of the three main subsections built.

You can see that two minifigs is the max amount that will fit.  The two outboard engines will be used to connect hoses to the platform.

 

The reverse side of the roof of the base/bottom of the top section is shown here.  The astute observer will notice that the square tile has a hole in it for the axle.  Not a normal Brick piece and was modified by me.  Need a smooth surface for the generator to  spin on.

These two pictures show the generator attached to the base.  The top section is built in such a way that only the spinning generator can be seen and not the axle.  The goal is to make it look like it is spinning in space.

The final design with a temporary base.The number of 8x8 dishes on the top is strictly a function of color scheme, the detail effect we are trying to achieve and the length of the axle that needs to be taken into account.  This version only has one dish since the axle used would only go through one 8x8 dis and the final 10x10 dish on the top.

Again lighting this section is going to be challenging.  This needs the random PWM lighting effect I used in the original MOC I did last year.  It would be nice to also to have an LED on the top with a ramp effect which would simulate a rotating beacon.  These will be task for a a later time.

The other item on the top section is should the entire enclosure be trans light blue or should the back piece be tan.  The entire glass effect is nice, but the tan piece allows for hiding wires.  The problem here is that you cannot center the tan piece in the back..So for now I will leave it as all glass and just figure a way to minimize the wires exposure.

I worried that the generator would wobble just enough to strike the enclosure.  Testing to date has shown this not the case if everything is properly seated.
 
Finally here is a short video of it running.

Lighting Controller Inputs/Outputs

To make it easier to control the inputs to the Lighting controller, I am making a small board with three small push buttons and small potentiometer.  As in the Brick Buddy^TM , there will be a script function to wait on one of these three inputs and then do something specific.  The potentiometer will be used to vary lighting levels, PWM rates and burst length and randomize effects.  Obviously it can do them all at the same time, but each model will be different and thus will want different effects.  Here is the front side with the input controls.

To save costs, this board will be dual function.  One side will do the input function, as shown above.  The other side will be the output connector for the two PIC PWM controllers and the two ON/OFF LED controllers, see below.  The assembly will be one or the other and not both, at least not right now.

The above are 3D models of what these look like. My only issue with the design is the connection of the outputs.  Right now these are standard 0.1" spacing connectors.  You can either solder directly to the PCB or put in 2 pin connectors and connect to them.   Could put in the JST type connectors used by the LiPO batteries that are popular on the Maker Sites.  but building mating cable connectors is difficult.  In the end, it seems easiest to just wrap wires around post.

Horizontal Generator Model

In the post on the First Look at Four Platform MOC I showed the vertical spinning generator model.  The post also showed a horizontal spinning generator.  I acquired four of these trans light blue 10x5 x6 half cones from one of the new Ninjago sets.  I thought they looked intereesting and started playing with how to mount them.  Mounting them back to back was interesting and will discuss this in a later post.  I continued to play with these parts and some 10x10 octagon plates and then finally finished the model of this.  Here is the model in it's current state.

I managed to hide the small gearbox in the middle.  That way the drive will be underneath.  Unfortunately it does not look like the longest axle will span the width, so not sure how that is going to work yet.  Also still playing with the colors, may have to get my two consultants involved with that.  Finally have some ideas for hoses installed to look like power cables coming out for powering the base.

Light Cotroller PCB

Finished the prototype of the light controller last night.  Here is the PCB model.

The functionality that finally got implemented is as follows:
1. The six LP5569 LED engines were spread across the three connectors on the left, each one has two.  There are 3 LED connections per engine for a total of 6 LEDs and 4 power connections.  The connector is a standard 10 pin header and any PC 10 pin ribbon cable can be used to connect the LEDs.
2.  The connector on the bottom has the two PIC PWM engines and the two ON/OFF LEDs plus two power connections.  This connector is a the same connector used to power the Brick Buddy^TM . I will have more on this later this weekend.
3.  The input control was changed to three ON/OFF type contacts and one analog input.  This way you could set the brightness or the blinking rate or who knows what I will dream up.  Again uses the same 6 pin connector as #2 above, with these four inputs and power/ground.
4.  Included a RN4020 BLE module, though I will probably not implement the firmware at this time.  This is more of a set it and forget type functionality, at least now.

The PCB fabs should be back next week, so maybe by next weekend something will be up and running.

New Light Controller (Update)

Here is the basic block diagram for the Lighting Controller.  Looks like a lot of LEDs, but to recap what is driving this.  My first battle fort had three blasters, two with 2 barrels and 1 with 4 barrels.  Then it had two power generator LEDs, one with 2 LEDs.  Finally there were two other flashing LEDs on the MOC.  That totals to 13 LEDs and ideally 6 independent controllers  I would have put in more lights, but the Brick Buddy only went had 4 independent controllers and only one had a PWM controller on it.  This is what is driving this design.

Decided to use a pair of TI LED controllers in addition to the two inherent PWM controllers inside the PIC.  The LP5569 allows for three LEDs per controller, which is 9 actual LEDs.  The IC will sink up to 25mA per  pin, so that up to two LEDs could be attached per pin with a load sharing resistor of 10 to 20 ohms.  Thus this design has up to 8 independent LED controllers.  In addition (and not shown) is two ON-OFF type signals that can sink >100mA each.

Connectors are always problematic in this type of design.  One goal is to make it small, but with all of the LED connections, this becomes difficult.  So for the 18 LEDs on the two LP5569s, I have decide to go with three standard 2x5 10 pin connectors.  These are the standard PC serial connectors and allow for use of off the shelf connectors and ribbon cables.  Still requires either soldering or twisting/taping wires.  But LEDs in a MOC can be anywhere and including a connector for every LED would take alot of room and be prohibitively expensive.  This way I don't burden the person who only wants a few LEDs with the cost of 18 single connectors.  The other two connectors use the standard 6 pin on the Brick Buddy which allows me to use those cables for other purposes.  One will connect the the sensors and the other will connect the two PIC PWM controllers and ON-OFF LEDs.

There are 4 digital sensor input and one analog sensor input.The digital sensors are all interrupt on change inputs, so the controller should be responsive to input.  The analog input would be used to vary the lighting effects, not sure how, but it is completely a frimware issue. I have some ideas for a companion board that will have a few buttons and a potentiometer on it along with some connectors to mate out to the standard power functions connector.  This will allow for standard input functions to be used.

As mentioned in the previous post, the BLE module will be optional.  I probably will not start work on the Android interface until after Maker Faire is over.  The goal would be to show a working interface at Bricks By The Bay in July.

The PCB layout has begun and right now it looks like it will all fit on 6x8 plate with a 4x8 plate on top.  This will allow for the LED lighting connectors to be exposed.

New Light Controller

After building the first single platform MOC, it became obvious that four light controllers are not enough as the MOC gets bigger.  Therefore I am working on a new Brick Buddy^TM , Light Buddy.  The basic functionality is 8 to 10 light controllers, with at least 8 of them under PWM control to provide some unique lighting effects.  Additionally a few that just power on when power is applied.  Finally some input lines that can be used to control the lights through interaction with the user or the MOC.  All of this is to be powered by a USB power source.  Optionally it will have a Microchip RN4020 BLE module included.  I am including this now because it might be useful.  But this might change as I am thinking this is more of a set and forget type functionality.

The Windows program will be the same as the Brick Buddy^TM , to keep it simple for the user.  If the BLE module survives, then the same will be true for the Android app.

Right now the PIC processor that I am looking at in the 28 pin version (PIC18F26J53) will not have enough GPIO to have inputs, after the LED control, BLE Module and external memory for the user program.  Hope to have a finalized design this weekend.

First Look at Four Platform MOC

This is the first attempt at building a 4 platform MOC.  Not sure where this is headed right now.   Also not sure about the order that I want.  I have used the two angled connectors on the ends and the straight connector in the middle.  One detail I want to model is an energy control station.  The beginnings of this are on the straight connector.  The angle connectors can accept minimal detail because of the angle.  But I have ideas on how to handle.this.

I have been working on the two cylinder designs as spinning generators.  We will see where this goes.  I have modeled what the vertical one might look like here.