Installing Light Buddy 2 - Part 2

 

Now I need to place the LED's and the wiring.  First I need to change the sand blue 1x1 round tile to one that is transparent red, as shown here.

But between the size of the dish and the hole that had to be drawn, the 1x1 round tile will not fit.  You can see that from this picture.

What I need is an extension.  My first thought was a 1x1 round brick as shown here.

But as you can see not much light is coming through.  My next thought was a 1x1 round plate with an open stud.  But the only transparent ones I had were light blue and I really wanted red.I checked Bricklink and while it said they existed, the number of stores that had them was 3.  Not a good probability of getting them.  The only other transparent color that was a possibility besides light blue was orange and that did not appeal to me.  So I thought that by reducing the distance from the LED to the transparent 1x1 round tile, maybe that would help.  That led to this, which is similar to the 1x1 round plate with open stud.

While it is brighter, it is really only visible if you are looking straight down on it.  Looking closer at this arrangement, I see that the lip on the 2x2 dish is blocking the LED light, forcing it straight up.  That realization led to the final configuration.

The transparent red 2x2 dish and the 1x1 round tile are both lighting up.  This is the effect I wanted.  The wiring now runs down the 2x2x2 cone with open stud, through the center hole of the 6x6 round plate into the cavity where the Light Buddy 2 will be.

Placing the four LEDs under the 2x2 round transparent light blue bricks was fairly easy.  The wiring is small enough that it will run under the 2x2 round brick or through the gap in the side where it fits on a stud on the 6x6 plate.  It then follows the wiring from the top through the hole in the center of the 6x6 round plate and into the cavity below.

Next step is to connect the wiring up to the Light Buddy 2 and place it in the cavity.

 

Installing Light Buddy 2 - Part 1

 

While the firmware is not yet complete, I went ahead and started building the first instance of this new LED Controller.  

This requires doing something that is controversial in the LEGO community and that is modifying the bricks.  My take is that drilling holes for wiring or letting LED light though, when no other option is possible and this holes cannot be seen, is acceptable.  Modifying bricks for an artistic effect is pushing this idea too far for me.

The first modification is the sand blue dish on the top.  In the build, the sand blue 1 x 1 round tile on the top will be replaced by a transparent red tile, so that that a glowing LED can be placed there.  There is no open stud in this part, so I will need to drill a hole for the wires.

The next two pictures show the problem.  First the hole has to leave the surrounding shoulder plastic so that the tan cone has something to connect to.  Second, in this configuration the dish is not stable.  Attempting to drill in this manner will likely result in the dish tilting and the hole not being where I wanted it.

The solution is to use 1x1 round plate with an open stud.  This picture shows that I have chosen a drill bit that will just fit into the open stud.

By placing the 1x1 round plate on the dish, it will serve as a drill guide.  The dish is now facing down and in the most stable position.  This makes drilling the hole very easy.

And here is the result.

The generator LED's are placed at the bottom of the 2x2 round transparent light blue bricks.  But the 6x6 round tan plate will not the LED light up into the 2x2 round domes on the 6x6 tan plate.  Here is where major modifications are needed.  The 6x6 tan plate has a hole in the center which will be needed for the wires coming down from the top of the dish.  Thus I need to drill holes of the same size where the center of the 2x2 round bricks attach.

There are two approaches to this. 

Drill from the bottom.  But as this picture shows, the location of the holes is not a normal circle.  That odd shape will cause the drill bit to wander and force the part to move unless it is tightly clamped down.

Drill from the top.   This approach is easier, but there does not exist a natural drill guide.  I would be guessing where the center is.  Thus as with the dish drill above, I am using a 2x2 round tile with a hole in the center.  This places the hole exactly where I want it.

Here is the 6x6 round plate with the four additional holes in it.

Next installment will be installing the LEDs.

LIght Buddy 2 - The Build Part 2

 

 

After spending the AM looking into this, I finally found the problem.  It is and isn't my new PCB.  Above is a photo of the setup.

The absolute source of the issue is the USB battery.  But it is only doing what it was designed to do.  All USB batteries have a minimal current flow cutoff circuit designed into them with a timeout delay.   When the current drops below a preset limit, the battery turns off after the delay.  This minimizes the self discharge rate.  The silver battery in the picture is the one I use for development because it seemed to have a very low cutoff, as in it doesnt turn of as long as something is plugged in.  The LED lights indicating current charge level never went out.  Other USB batteries I have require at least two devices connected with motors and LEDs active, to stay on.  And when they shut off, they shut off completely.  But when I connected the Analog Discovery to the PCB, I found this.

Sometimes the dropout is deeper,  down to just under 2VDC and varies in time from this to about 20ms.  It also happens every 27-28 seconds, which is probably the batteries timeout.  When I switched the power source to a wall charger, all of this went away and the debugger worked without failure for over 30 minutes.  Final test was to add a 100 OHM resistor load to the USB battery using the USB power connector (PCB with red and white punch down blocks on it).  Worked the same as the wall charger.  Removing the 100 ohm resistor and it reverts back to resetting every 27-28 seconds.  

My PCB just did not draw enough current to keep the battery happy.  The USB battery would start to shutdown the voltage, the PCB would start to draw more current as the voltage decreased.  This increase in current was just enough to restart the battery.  Rinse and repeat.
 

MIcrochip PICKIT 4 Not the Problem

I use the Tag-Connect 6 pin connector with Pogo Pins.  Very small footprint.  It appears that the one I have been using for a long while is now flaky, which is why the PICKIT 4 would not connect.  I had another one, but it only had an RJ-11 connector, so I went digging for my ICD3.  Fortunately the ICD3 will do at least two of the four processors I have chosen.  So I thought I would look at buying an ICD4, just to be current.  Well it is EOL, happened back in late September.  The forums seem to indicate they could not build any more, no parts.  In particular no FPGAs are available at an acceptable price.  So that leaves an ICE4 @ $1800 or PICkit4 which I have.  I just might have to buy another PICKIT 4 for insurance purposes.  I did look on Ebay for an ICD4, none to be found and the Asian market wants $1950.  Digikey, Mouser, Newark, etc have all pulled the listing as obsolete.  The Microchip website claims they will continue to update the programmer.  This has only solved my connection problem, the BOR problem still exists as does the debugger resetting when in debug mode.

For older PICs, theICD3 and PICKIT 3 are adequate, not as many breakpoints, but otherwise mostly equivalent.   ICD3 and PICkit3 are not getting any new PICs added to them, so these two will only be the older PICs going forward.  Ends up being the two most likely candidates, PIC16F18326 and PIC16F18426, are old enough that ICD3 and PICkit3 will work on them.  The only issue that will push me to the other two PICs (PIC18F06Q40 and PIC18F06Q41) will be execution speed.  The PIC16F runs at 32MHz and the PIC18F runs at 64MHz.  PIC power is not the issue here, with 6 LEDs running at 25mA each. The power difference is 3mA vs 13mA.  So 10mA increase which leads to 153mA vs 163mA in total power, 6.5%.  I can live with that.  And if the LEDs use less current, say 5mA each,  Then its 33mA vs 43mA, 30% increase.  But the total power is down 73%.  All good.

Tomorrow I am going to try and track down the Brown Out Reset issue, because now I am convinced that is also resetting the PICkit/ICD in debug mode.

Light Buddy 2 - Build Part 1

 

Part of the development time was me copying code from the PIC32 project and not getting all the code.   Then there was a mismatch in the com protocol between the PC and the PIC that had to be fixed. Again, all for the good as I develop a lot more consistent interface and infrastructure code across all of my projects.

When I moved to the PCB two things started happening that were not present on the Microchip Curiosity Development Board.  I could not buy PIC16F18326 parts and had to settle for the LF version.  Should be NO big deal, though it did force the LDO decision to a 3.3VDC version.  First every few seconds the Brown out Reset would fire.  Added code to print out the the registers that tell you what caused the reset, so I know that was it.   Once I disabled BOR, that quit happening.  But now I dont know if what the PIC was seeing is not causing other issues.  

Second the PICKIT 4 is unreliable, not sure why yet.Part of it was a poor connection to the board.  I fixed that, but it will still reset it self after a few seconds.  This is probably related to the BOR issue, just not sure how to debug this, especially if the drop out is very narrow.  Also had to upgrade XC8 and MPLAB X to 5.5, which means the 64bit version.  But as the picture shows I moved to an ICD3 to continue working.

While this PIC runs at 32MHZ max, I am pushing it when running all six LEDs in full feature mode.  I can tell the service loop is not getting around as fast by the way the LEDs react.  It may be OK, I just need more time to refine the loop.  The loop is every 100msec and that may not be enough time to service 6 LEDs.  Also the free compiler does not do a great job on speed optimization.

As an aside, several people have suggested using switches to select the LED modes.  I passed on the switches for now.  The serial port makes it much easier to develop the lighting features and provides a console feature for printf.  Though I had to finish the PC program first before I could get started on the PIC firmware.  Every time I add new features to this Windows software, the whole structure of the program slightly mutates, thus more testing for older features to make sure I did not break them.   The software is getting more structured and easier to modify, just takes time.

Light Buddy 2 -The PCB

I received the REV 1 PCBs.  As you can see, they are exactly the size I wanted.  This picture below shows the PCB in the base of Power Generator design I am working on.  I had to extend the height with a 3 x 3 Modified Facet Brick.  That should give all the height I need.  Will probably turn the PCB over and attached the round plates and then mount the PCB to the round plate.  I can always add more 1 x 1 round plates to increase any spacing I need.  So far I am very happy with this.

In the mean time I have been working on the software.  Here I am using a Microchip Curiosity LPC Development board (P/N DM164137) with a PIC16F18326.

Most of the code came together rather quickly.  As I mentioned in the previous posts, this PCB can use 4 different PICs (PIC16F18326, PIC16F18426, PIC18F06Q40 or PIC18F06Q40).  My recent experience with lack of availability drove me to this.  But I wanted one piece of firmware.  Thus I have been experiencing the joy of #IFDEF.......#ENDIF.  I have actually spent quite a bit time with the development board and two of the PICs building the app.  Since these 4 PICs span a few years of introduction, the consistency on the peripheral naming is not great.   I finally have the first two in the above list working at the 95% completion point, the other two are about at the %60 point.  But the last two in the above list should come up quickly since most of the infrastructure is there.  I will have to move to a newer XC8 compiler and newer version of MPLAB X, though to finish up with those newer PICs.

Just as an aside, sometime in the last few years, Tech Writing at Microchip under went some changes.  The datasheets are laid out a little differently now.  I am using PICs that have dedicated PWM controllers in addition to the normal CCP/PWM modules.  On the PICs the CCPs are numbered  1 to 4 like normal.  But the PWMs are number 5&6 on one PIC and 6&7 on another.  The Timers names are different as are the UARTs.  I ended  up with lots of #IFDEF to handle this, including an additional system type 'h' file, because there was some circular reference driving the compiler to spit all kinds of weird errors.

Since this is an old fashion RS232 interface, I had to resurrect some very old code.  For all of my PC LEGO control, I am trying to use one windows APP.  In the USB HID world this proved to be quite easy since identification is built into the USB HID protocol.  The WIN APP then just determines who just connected and adjust accordingly.  Well plugging in an RS232 device that stuff doesn't happen.  You have to code it.   Integrating this into the existing code was not hard, just time consuming.  Surprisingly some remnants of old RS232 interfaces were still present in some of the code.  Dont think I have started form scratch in a long time.

I am fairly close to building a few and testing.  While these do not have a remote control feature, in some cases hiding it in something small is advantageous.

I am now wondering if I can make a smaller one😋

 

 

Light Buddy 2 - The Design

 

Here is what the board looks like.  It is very simple, just a fancy way to control 6 LEDs to produce fixed (kind of) lighting effects.  No remote of any kind.

The voltage regulator, U2, will take up 16VDC and produce either 3.3VDC or 5VDC, haven't decided what voltage to run at.  The intended input is VUSB, so if it is 5VDC, it will just follow the input.  J9 is the power input (GND-VUSB-GND to help prevent incorrect connections).

J8 is a standard TTL/CMOS level RS-232 interface.  My intent is to allow the 6 outputs to be programmed in some fashion, TBD.  The problem is anyone who does this will need a RS232 to USB converter.  For me, this not a big deal, for some LEGO users, this may be a bridge to far.   So when you order it, I would program with the desired effects.  The buyer would pick from a selection of choices.  I have also considered a BT module that plugs onto J8 and J9.  Then you would use the Light Buddy Android App to update it.

The remaining parts are six N-FETs to drive the LEDs and protect the processor outputs from excessive current draw.

On the backside, the two circles is where small 1 x 1 round LEGO plates will attach to the PCB (super glue).  This allows the board to be mounted into the LEGO Model.

The processor is either PIC16F18326, PIC16F18346, PIC18F06Q40 or PIC18F06Q41 families.  They come in different memory sizes, I always start with the largest until I figure out how much I really need.

Finally, the absolute bane of my existence, connectors.  All of these are of the 2mm type.  But as you can see they are large compared to the board.  I have used smaller 1mm 2 pin connectors before, but they are very difficult to un-mate.  Everyone complains about them.  Obviously J8 doesn't need to be populated unless you intend on using the RS232 interface.  J9 could be soldered in.  That just leaves J1 for the LEDs.  They also could be soldered in, but that would make working with the LEGO model more difficult.  You should be able to plug in individual 2 pin 2mm male connectors into J1 for each LED.  I keep looking for a solution to this problem, but have not found anything yet.