Including Power

 

Following up on this post, here is a quick tutorial on how I make sure these small PCBs fit exactly where they belong.

Here is what we are building.  This is a small PCB the size of a 2x3 plate.  When only one connector is on each side, we can place a 1x2 tile on each end.  If there are 3 connectors on the one side, then only a 1x1 tile will fit.

I use a scrap plate (6x10) and then some 1x2 and 1x4 bricks.  They are arranged as shown here.  (Now everything red was probably not a good choice for photography).  Then I verify that the small PCB will fit.

Then I place a small drop of super glue on the center of each tile, maybe just a little to the inside.

Spread the glue around.

Then place the the PCB into the fixture and press.

To prevent any excess super glue from bonding to the bricks, after about 2 seconds I start removing them.  If there is any super glue on the bricks, I remove it with a piece of foam.  A paper towel would disintegrate and bond to the brick.  A cloth could also be used.  Then I let it sit there for  bout 10 mins to make sure the bond is strong.  Then the entire assembly can be removed.

 In two weeks we will be arriving in Omaha for Brick Days.  We are excited to participate in this convention.  We have been there the last two years, first as a attendee then as a presenter.  This is one of the conventions that is real fun to attend.  The convention is April 22 and 23.  You can get tickets on the web site.  If you are anywhere near Omaha, it is well worth it to attend.

Just as a reminder, here are some pictures from last year.

More MPLAB Fun!

My next step on the Brick Buddy 3 code development was to implement the Bluetooth Interface.  The Brick Buddy 3 uses a RN4871 instead of the RN4020.  I was hoping that the change over was going to be simple, but that does not look like what will happen.

My plan was to use a Mikroe Click Board with an RN4871 on it.  I also have one with an RN4870, which is just bigger version with more I/O pins.  You can see the RN4871 in the picture above on the left. Well the best laid plans, things did not go as planned.  After several failed starts at communications, I finally managed to get Tx/Rx connected.  The RN4871 reset line also worked as advertised, but the system would reboot itself randomly or sometimes continuously.  In the beginning I had just connected the serial port of the RN4871 to FTDI serial to USB converter and used TeraTerm to watch the RN4871 output.  The %REBOOT% would show up every few seconds.  

Searching the Internet this seemed to be an issue with earlier firmware versions.  Also the RN4871 seemed to be sensitive to voltage ripple.  So I did two things to hopefully improve performance.  First I upgraded the firmware to 1.42.  But that did not seem to do much improvement.  So I backed down to 1.41 and there appeared to be improvement.  Next I had a 10uF capacitor across Vcc and GND, right on the click board.  The multiple resets went away and everything seemed to be more stable.  Which one did it, not sure, but it needed the firmware upgrade.  While this picutre is not very good and my soldering was below average on this, you can see the capacitor across the two pins.

With a stable system I started walking through the code I had been using for the RN4020 with modifications for the RN4871.  It would always hang on the first command.  I started stepping through the command and the while loop would not iterate. It always sent the same character to the RN4871.  No matter how I wrote the code, it would not iterate or would iterate by random numbers. I changed the variables to different types, nothing matter.  First I suspected the ISR was changing things.  But that was not the case.  After a day of this, I decided to install every Pack available for MPLAB 6.00. and for the PICKit4.  Most of them installed, then said they do not apply.  But whatever I did, the loop started iterating correctly. I was then able to walk through the command list and could watch the RN4871  respond to each.  Then I used a generic BTLE tool on my phone to see that the RN4871 was correctly advertising all of the characteristics.  

Now it became obvious that a parser was needed.  Different commands result in different ASCII responses.  Thus this is very similar to the old Hayes AT modem.  Looking around I finally found a parser that was generated by the MPLAB Code Configurator, that was a start at this.  It can be found on Github.  This is where I stopped and moved on to ohter things. If time permits I will come back to this and see if I can get something working in a day or two.

Lego Fix

 The weather finally cleared enough for us to make a trip into the Bay Area. This is our once a month a trip to see friends, do some shopping and search for bricks.  Hereaare  some pictures of what I got.  They are in the tub ready for washing.  Most of what I found are technic bricks  that I need for building infrastructure for  the space base.

 

 

 

 

Entrance Design - Part 3

 

Part of the complete rebuild of the Space Base is to improve the setup and take down without having to worry about small wires.  It started this in this post.   Since there are a lot of modules in front of the entrance, I added two of these (next picture), one  on either side.  The version is a little different in that there are three connectors on the front, but no connector on the back.  I soldered in wires that connect back to the main distribution point. 

The distribution point is shown in this picture. It is attached underneath the Entrance and connects all lighting in the Entrance structure to a USB port.

This ides went rough several iterations before I achieved a usable solution.

First it needed to be recessed so that there was sufficient room for the wire bend radius.  But if I did that, I would be guessing at where the connection point was.  That led to the idea of a removal module that I could easily connect the individual cables to .  This picture above shows this.  A single technic pin brick makes the connection.

This series of pictures shows the build.  The 1x3 tile area in front is a gripping point for removing the module.  The tiles on top help it slid in and not have studs tying to slide by tubes.  

This picture shows the socket area of the module.  A1x2 technic brick with a single hole is the socket for the previously mentioned technic brick with a pin. There is a 1x1 hole for the wire to slide through.

Finally the above picture shows the module attached and hanging on it's wire. The Distribution module can be seen at the back on the right.  

Only a live setup is going to tell me if this was a good idea.  So until Brick Days in Omaha, we will not know if this was a good idea.

See you on April 22.😀

 

 

 

Entrance Design - Part 2

Lighting design was a challenge.  The easy part was the conference room, which needed only white light.  The briefing room was done in red.  The third floor area was done in blue to match the transparent light blue windows.  Finally the two side areas that over see the hanger floor were done in white.  Here are the pictures.  First the conference room.

Next is the briefing room.  The red is really bright.

PIC18F46Q71 and I2C

I have been caught up in an I2C nightmare most of the week.  Basically a few years ago Microchip change their implementation of the I2C controller.  Instead of the MSSP which did both SPI and I2C, they now have separate SPI and I2C controllers.  Now it is true that the MSSP probably did not give as much control over the protocol process as one would like.  I am sure the MSSP worked great with all of Microhip's I2C products.  But as with any "specification" it is subject to interpretation, which probably led to a less than ideal mating with other companies products.  The new controller has more settings for SMBUS which is slightly different than I2C in timing and voltage levels.  And it has a more automated mode of working.  It may be better and more flexible. I dont know.  It wasn't that easy to get working in the master state. 

But the PICs I am moving to have this new controller.  There are very few working examples and the firmware that the MCC generator gives you is buggy and hard to understand how to actually implement. It is mostly a cooperative multi-tasking implementation with switch statements and lots of function calls to set one bit in a register.  Now I2C was never straight forward as a protocol, but the MCC code seems to make it more complex than it needs to be.  Sometimes you just want to read an external EEPROM memory and do a simple task.  Not have 10 peripherals running that need to be serviced on a regular basis.

What I found when searching the Internet for working example code was this example on a PIC18F46K42 and a Curiosity HPC.  Since I was working on an HPC this was perfect.  I downloaded the project and started working.  Using my Digilent Analog Discovery 2 as an I2C protocol analyzer, I could see when it worked and when it didn't.   Then I used the driver (.c) and header (.h) files as the starting point for my driver/header files.  Kept modifying these files in the example project until I could read and write the I2C EEPROM I had installed in one of the Click Module sockets on the HPC.  At this point I moved the files back to my project and the PIC18F46Q71 and started testing.  Some minor tweaks to the initialization were needed, but it seemed to work just fine.  

The I2C driver I have running is very basic and runs to completion.  That is it is blocking and will hang the system.  But for now that is OK.  I will need to implement some form of cooperative multi-taksing to get the LP5569 to work, since that is the way it is setup right now.   My only issus is when reading the EEPROM.  The sequence is to write the client address followed by the two bytes that hold the memory address.  this is followed by a restart condition and the PIC resends the client address with read set and starts reading the memory.  Here is the protocol analyzer's view of that sequence.

and just the restart area

The data sheet implies this is OK.  The stop bit is not long enough and all the client IC sees is the restart condition.  We shall see.

 I will leave with this comment form another developer, which was pretty typical of those who posted.

"When you make it hard to use your products, developers will move to other products."