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.

Solar Shed - Update

 

We had 12" of snow and this completely covered the solar panel.  This caused the battery to completely drain.  That is the battery voltage was less than 10VDC.  Which leads me to this

1. Probably need a cutoff relay to disconnect the battery when there is no charging voltage and the battery voltage falls below a certain value.
2. If the battery is disconnected, then the controller needs power from somewhere else, probably a combination of the solar panel and a very large cap.
3. Which leads to the Curiosity HPC board is not going to work.  Need a custom board that I can put to sleep to save power.  75-90mA is just too much current.

Oh well more fun designing.

 

Light Buddy 2 - The Need

 

I have been working on a LEGO generator design for the large LEGO display.  I needed at least 5 LEDs.  4 of them generate a pulsating electric thingee, kind of like a lightning effect or an arc welding effect.  I do this with a PWM generator and then randomly change the times and pulse width.  Not perfect but it does a good job.   I needed this to be small and with some new PICs that have multiple PWMs and independent timers, I think I can get this down to a the size of a 2x4 Lego brick (15.5 x 31.25mm), although it is two sided.  The PIC controllers I am looking at are PIC16F18326, PIC16F18426, PIC18F06Q40 and PIC18F06Q41.  These are the large memory versions.  Once the code size is determined, may be able to move to smaller memory versions.  This will just give more flexibility in ordering, considering the state of IC availability has only marginally improved.

The amazing part was that the PCB vendor I am using for PCBs (PCBWAY) is selling  2 layer, 10 pieces for $5 total, $23 in shipping and 24 hour turn if in green, any other color is 5-6 days.  At those prices it is almost not worth wiring a manual proto anymore.  Could build some generic proto boards to play with.  The max size appears to be 100x100mm or just under 4x4".  And if I were to do multiple designs, the cost would be less since they will all fit in a single package.
 

This may be the next LED controller.

Solar Shed - Intstall

 

I kept all of the big currents (charging and SHED LEDs) on the add on PCB.  To make the A/D readings as stable as possible. I added a unity gain OP-AMP on all inputs, a 16 sample rolling average, some thought on the ground connections and ground pour on both sides of the add on PCB.  But the OP-AMPS have to powered by the development board, so minute current is flowing between the Curiosity HPC board and the daughter board.  Also during development the whole system is powered by USB, since the development board has the debugger built into the board (PIC24 16 bit).  When installed in the shed, the battery runs everything with a 5VDC LDO replacing VUSB.  That was enough of a change in the ground currents to cause the A/D readings to move a little.  Fortunately I coded all of the trip point values (Battery over voltage, Solar Input over/under voltage, etc..) as constants derived from a spread sheet.  This program takes almost 64K of FLASH because of the embedded fonts for the OLED.  So adding table look ups for converting A/D readings to voltage did not add much in comparison.

A major concern now is that the whole setup draws about 75mA when just idling.  The OLED only displays when a button is pushed.  And one LED is cycling at 50% to indicate that the main loop is running.  So I am guessing that the PIC24 implementation of the debugger is the main current draw.  I looked at the schematic and there is no clean way to cut the power.  Right now I get about 4-6 hours of some charge.  The sun is too low and the house next door is 5 feet higher and blocks the morning sun and the remainder of the day the angle is very low.  In about 6 weeks, the sun should be high enough to give more charge time and by spring it will be over 10 hours a day and very direct.  For now I will just watch the battery voltage to see what the trend is.

Light Buddy 1 - Operation

 

This video was taken with a standard HD Webcam (Logitech C922).  It does not do a very good job at closeups, which is why the device is slightly out of focus.  Additionally the LEDs, when on, tend to overwhelm the auto white balance.  One of these days I will get a better camera for this type of work.

This is a short video the Light Buddy 1 in demo mode.  Attached are the LEDs we sell in 1 x 1 and 1 x 2 plate format.  All of the LEDs have an integrated resistor.  Here is what is happening"

1.  The white LED in the upper left is on STEADY.

2.  The small blue LED left side center is in one of the pulsing modes.

3.  The purple LED in the lower right is in CyCLE mode then pulsing mode.

4.  The small blue LED on the lower left side is in CYCLE mode

5.  The green LED in the upper left is in STEADY then BURST mode.

Sometime later I will put together a series of videos that show the different LED modes that are possible.

 

Solar Shed - Final Testing

The Solar Shed thing is almost done.  Instead of trying to debug the final issues in the shed on the wood pile and me all twisted in a pretzel, I built up  an environment in my office.  Instead of the Solar panel I used a 24VDC power supply I had.  This allowed for testing most of the different voltage points that control the relays  and the battery charging.  Here is a summary of the voltage decision points

• If the Solar panel voltage falls below 14 VDC, charging is disabled.  No sense in charging at this point, the panel is providing very little current.
• If the battery voltage rises above 14.6 VDC, charging is disabled.  Don't want to over charge the battery.  Also a five minute backoff timer goes into effect.  That way the charger won't be connecting/disconnecting at the main loop revisit rate. 
  
• If the LED light switch is turned on, charging is disabled.  I want only the battery to supply the LED lights.
  

Got the coding done.  Now over a few days of monitoring the setup in the shed, I have needed to only change some constants.  Much easier to just take the laptop out to the shed and program the board, than try to step thru code.  Between the development board base and the PCB add on I built, there are some crazy ground currents that are effecting the A/D readings.  Thus the constants needed some updating.