Railing Ideas

 Railing in the Main Entrance and the Platforms has been a design issue for a while now.  I started with this idea.  Using transparent light blue 1x1 round plates, stacked four high.  Then capped with transparent blue 1x tiles.  This idea is shown here.

The issue for me is that this was just too massive.  A railing should not be a focal point, but with this design, it was just over whelming.  

I moved on to this.  Much simpler using the telescope to support a 1x tile.

But this reminded me to much of a church alter or communion rail.  So this did not work either.

What is a railing, especially in an industrial type setting.  In it's simplest form it is just pipe connected with T-Joints.  So how can we do this.  There are no true pipes in the Lego system.  The closest item is a bar.  They come in many sizes and shapes, these are but a few examples.

Additionally there is need for flexibility in length.  The longer it is, the harder it will be to fit into irregular space.  The shorter it is, the more you need.  And so cost becomes an issue also.  If you need lots of them, you would prefer they be inexpensive.

Which leads to this.  This is the same concept in two different forms.  On the left is a round 1x brick and on the right are three 1x1 round plates with an open stud.  Both are capped by the mechanical claw and 4L bar.  What is nice about this idea is that the bar comes in multiple colors.  Here I am using transparent light blue bars. I could have used a 1x1 tile with an open O clip instead of the claw, but somehow the square tile on top of the round pillar just did not seem the right idea.

Here is a view how this idea turned out.  At first getting two bars into one clip was challenging.  But after a few, I developed a method that made it fairly easy.  Getting the first one int he correct place made the rest easy to do. 

While I like the three stacked plates and the pillar it forms, I will be staying with the round brick for now.  The simple lines fit better with the austere design of the space base.

Brick Days - Omaha

 

Well we are a week from leaving for Brick Days.  So over the weekend I decided it might be good idea to see if the Space Base will fit in the car.  Or will I have to rent a van to get it there.  

Well the great news is it fits😀  And we have room for our suitcases, which makes the wife happy. 

The wife gets to bring here small traveling sewing machine to work on stuff.  

This will be a great time and we are looking forward to it.

 

 

 

 

 

Brick Buddy 3 Its Alive

 

Well kind of.  The light flashes (see yellow arrow) which means the main loop is working.  As you can see all of the through hole connectors need to be installed and a few other parts.  I can start testing the LED control right a way and then move on to motor control.  The only mistake so far is on the back side.  I added an I2C EEPROM for more memory storage of scripts.  This type of memory does not have the restrictions on it as does using any left over program flash for this purpose.  The clip holds the Tag-Connect ICSP connection for the PICKit.  For now I am using the on chip EEPROM.  When the time comes, I will "jury rig" something to make the connection and have the memory.

But the first day was a roller coaster.  It works then it doesn't.  And it all came down to writing internal EEPROM with the debugger attached.  This is FYI for anyone using PIC18FxxQxx processors, but might apply to K processors also.  

I added the FTDI part (did not have the assembler do any backside parts), Windows recognized the FTDI part and my Brick Controller PC APP that controls all my boards connected just fine.  I needed to do some Win APP updates for this board, so I downloaded the firmware just to reduce the variables.  This is the same base code that runs in all boards.

It downloaded just fine and started running.  I disconnected the ICSP,  unplugged the USB and reconnected and nothing.😮  No lights, no connections, just nothing.  How do you find a problem, without a debugger.  Okay, the ICSP has three wires PGC, PGD and MCLR.  Has to be MCLR or some power up config.  Checked all of that, everything looks good.

I have an LED on a PORT pin.  So I built an infinite while loop that toggles the LED, just in case I needed to look at it on a scope. Put the loop as far in the beginning of the code as I could and it works.  Now I started moving the loop further down the initialization until it failed.  It failed while writing to the EEPROM.

I have base code that gets the serial number, evaluates it and then decides if it is valid (generally fails on all 0xFF, which is a new programmed part).  If it fails, it will save a generic serial number that will validate, but that I know indicates the serial number needs updating.  Also a good test of read/write of wherever the storage is.  I have had problems in the recent past with some newer processors (non Q type) where the solution was to use the library to read/write.  But for my code for this Q processor, I just followed the data sheet example.  When I tried to use the library, the compiler said use the MCC, the library is deprecated.  I examined the MCC generated code and other than using ASM in the lock sequence, there appeared to be no difference, except.....

All of these new processors are 24 bit address for ALL memory.  I noticed the MCC code was intentionally loading all three NVMADR registers.  Where in other processors with 256 bytes of EEPROM, the upper bits really did not matter.  Well in this PIC, they do, if you are not using the debugger.  With the debugger attached, you dont need to load the upper 16 bits, but a normal production start and yes you need to correctly load those 16 bits.  Don't understand it, but that is the way it works.

Now I can get back to updating the Win APP.

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.