Bricks by the Bay 2020

As I stated in this post, Bricks By The Bay 2020 will be a virtual affair.  We have signed up to attend.  This is the email announcement that we received.

After careful consideration, we've decided to take Bricks by the Bay into the online arena with a virtual version of the convention starting with an opening ceremony at 7 PM Pacific Friday July 10 continuing throughout the day on Saturday July 11.  While nothing can replace the feel of ABS under our fingertips, we hope to maintain the cool and clarity of our Vision 2020 theme and provide a fun and interesting experience for all of our fans. 

We will have virtual tours of MOCs built by Bricks by the Bay builders, panel discussions, workshops, LEGO Masters participants, talks, games, contests and a chance for you and your family to show off your own MOCs.

You can sign up for the virtual convention on this website (www.bricksbythebay.com) starting June 1.  There is a limit of 1000 attendees.  Registration for the virtual convention (per connection) will be $5.  If you visit us in the real world in 2021 we will have a printed convention brick for 2020 virtual attendees.

Let us know if you would like to be part of a presentation at the virtual convention. We will be contacting people from our recent survey but please let us know again if you do not hear from us.  We are assembling the schedule at this time!

We will be returning to the real world June 17-20, 2021 with our new theme being Looking Back which should allow your Vision 2020 MOCs to remain relevant while also giving you a chance to also build a depiction of history either recent or long ago.  We hope to see you at the Santa Clara Convention Center in 2021!

Attendees

So how is this going to work. Don't know, but it could be interesting.  Unfortunately I will not have anything new done in time.  So I will be attending as a viewer and not a presenter.  Going to the presentations will be fun, though I probably should have volunteered my presentation from 2018 on the the Planetary Space Port.  If they are anything like the Zoom meetings, the discussions might be more robust than a typical in person lecture.  How they are going to do MOCs will be interesting to see. 

I can see where this can even be applied next year to a full convention, where you can get people to attend from around the world, that otherwise could not go. 

Vendors

Bricks by the Bay is also considering some type of virtual presence for vendors.  This will be limited to a non interactive vendor hall.  But in the future this could be interactive with the right technology.  As soon as I know how this is going to work, I will update everyone.

BC2 - Integration Begins

Started integrating all the code that I developed earlier on the PIC32MX470 Curiosity Board.  First up was getting the HID device to work.  Well did not go exactly as planned.  First the transferring from the Curiosity Board to the BC2 Proto by changing the BSP files there was a small burp.  So I had to start that all over again. 

Two things happened:

1. Using the project copy function in MPLAB X, did not do what I thought it should.  The code would not compile and the Harmony framework would not start.  Web searches showed I was not alone in this.  In the end I just manually copied the directory and then went into MPLAB X and made sure all files were relative and not absolute.  To make sure there was no absolute references, I renamed the original directory.
2. The Harmony framework will on occasion  will want to overwrite existing code with what it thinks are changes.  In reality these could be additions that were added.  I assume the process is to never modify the files Harmony generates, but at least for me, this seems impossible.  So when the BSP changed, other code segments I had added were deleted.  Had to start over and be more diligent about the changes I approved.

With that hurdle overcome, compiling and running worked up to the point that the PC was to enumerate the USB HID device. The device was reset, but never configured and the PC announced the device was recognizable.  MY first thought was the same problem I had encountered on the Curiosity board.  But after examination that was not the problem.   I spent a day and half looking at everything I could think of.  Prepared another BC2 proto board just to see if there was a problem in assembly.  Reviewed the layout and the connections, this was my first working USB Type C connector board.  Everything was where and how it should be.  My only clue was that it seemed to be running slow, but I assumed that some loop was taking to long since the USB wasn't working.

I had long ago connected a serial port to spew the debug messages from the Harmony framework and the ones I put in it.  But now this was not working either, bits were coming but the baud rate was wrong.  Curious!  Checked all the code to make sure the baud rate was set correctly, no issue.

Then the light bulb went on, the clock setup had to be wrong.  Even the though the code indicated it was running at 80MHz, looking further into this segment, showed it was only a #define.  Now with the running slow I noted earlier, I went to look at the clock setup.  Sure enough it was using the setup from the Curiosity board.  Changing that to correct values and the USB HID connected to the PC followed by the PC software recognized the proto as a Brick Controller 2.  Now integration can truly begin.

BC2 with Basic Motor Control

I have basic motor control working.  Motor Port 2 has some issue in the forward direction.  Looking at the pin on a scope shows the waveform, only at a few hundred mVolts.  I suspect there is a short to ground somewhere but I have not spent the time to look for it.  The other 3 Motor Ports work so I moved on for now to testing and driver development. 

When I first started testing, the PWM frequency was 20KHz, but on the scope it did not seem as though LB1836M motor driver could handle it.  I eventually lowered the PWM frequency to 5KHz, which seemed to work better.  I have read where Lego is using 1150Hz.  After finishing some driver cleanup, I am going back to retest the PWM frequency and generate documentation for no load motor conditions.  Just so I have it for future reference.

Here is a video that shows the basic driver going forward and reverse.  The motor starts at 100% and then slows down 5% every second.  It is actually easier to hear the change than see it.  This particular MOC I use at shows for customer interaction.  I have the Android App (modified for show use) running on a small tablet and the customers, mostly kids, can rotate the turret left or right and then fire the cannon.  It also has a clear front so you can watch the large (multiple gears) gear train work.  Because the gear train is so large, there is a large amount of the slop and slip in it.  This slop was always obvious when it changed directions in that you could hear the motor turning but the turret was not moving.  Then once the gears caught up it would move in the new direction.  I suspect this is also happening even when going in the same direction.  As the motor slows down in small steps, the gear train takes time to catch up.  I need to run this test by increasing the motor speed and see what happens.

BC2 with Basic PWM

Hard Lessons Re-Learned

After the I2C was working I moved on to PWM for the motors and the single LED controlled by the PIC32.  This seemed very easy from looking at the examples in the Microchip Harmony Framework.  I used my Digilent Analog Discovery 2 USB device to watch the signal.  These are great devices that can be a 2 ch scope, 16 input logic analyzer, waveform generator, etc.  For looking at signals under 2MHz, this much easier than pulling out my Tek Scope.  See here for more information https://www.analogdiscovery.com/

And here is where the fun began.  The circuit I was testing was a single pin driving a FET with 196 ohm current limiting resistor in the path as shown here.

I was using the Digilent USB device hooked up as logic analyzer.  Nothing would show up at the two pins where the LED connects, J13.  Then using another lead and probing the gate and the source pin on the FET, the expected signal was there.  But on the other side of the current limiting resistor nothing.  After a few hours, it becomes clear this is an open collector driver, of course there will be no signal because it is an open circuit.  I dug up a 330ohm resistor to put across the connector, J13, and still nothing.  So I changed to scope mode and the signal is there.  But since there is a current limiting resistor and I was measuring between the current limiting resistor and the 330ohm, the signal did not return to zero, actually a little over 1V.  So the logic analyzer portion of the Digilent wont work, as one would expect.

Well after a day and half of this, I verified that it all works.  It actually always worked,  I just did not know it.  Next step is to get all 4 motor ports working in forward and reverse and then write a driver for the PWM portion. 

Here is a quick video of the PWM signal incrementing from 5 to 100%, in 1% steps.  The PWM frequency is 20KHz, not sure it needs to be that high.  LEGO seems to use 1150 Hz, but I am afraid that will generate unwanted audio tones.  But that is easily changeable and have setup constants that will do all the necessary arithmetic.  At 20KHz there are 2000 steps with this PIC32, much more resolution that we will ever need.

BC2 and LED Control with I2C

After a successful power up, I moved on to the I2Cbus interface.  On the I2C bus is the LED controller, LP5569, and the USB Power Controller, STUSB4500.  The STUSB4500 was not in ready stock anywhere, so that was a DO NO INSTALL during assembly.  The STUSB4500 is only accessed once and that is during PCB configuration, at least that is the current implementation.  So I built the Harmony 2.0 driver around the LP5569.  What I have now is a very basic driver that does the following:

• RESET
• Initialize
• Configuration (enable/disable)
• Register Dump
• Update all PWM registers
• Basic Write Register
• Basic Read Register
• Read/Modify/Write Register

There is still a lot of clean up work and optimization that needs to happen.  This is a standalone program for now, which means it will need to be integrated with the other pieces.  But I am quite happy with the current state.

There were some development issues.  The PICKIT4 does not seem to like MPLAB 4.2 very much.  It would hang occasionally and does not the PIC32 register or SFRs.  Changing back to the PICKIT3, at least solved the register and SFR issue.

The LED control in Brick Controller 2 consists of 10 LED ports.  In the original Brick Controller there were only four LED ports and this was not sufficient.  The LP5569 will control 9 LEDS either individually or in up to 3 RGB groupings.  Port 10 is under direct software control and is connected to a PWM port on the PIC32.  The intention is to have ON/OFF, Burst, Cycle and the PWM functionality on all 10 LED ports, but we will see how this goes.  The LP5569 is a much more capable device with multiple types of controls, but these advanced features will have to wait until the basic BC2 is done.

The next step is implement the PWM features of the PIC32 that will be used with the 4 motor ports and LED port 10.  I will be using LED port 0 as the prototype, since in this implementation it is much easier to observe.

Here is a quick video of a single LED with varying intensity.

BC2 Power Up

After checking for shorts on the PCB and finding none, I applied power.  I suspected it would not work without the USB Power controller and I was correct.  But grounding the control for the P_FET brought 5 VDC to the power section and all the DC-DC converters powered up. 

Then I built the Board Support Package for the Microchip MPLAB X Harmony system.  Finally did a very simple program to blink the BLUE/YELLOW USB connection LEDs that I use in all of the MyMakerTools products.   The result is below.

Next is to build the I2C driver and the application code for the LP5569 LED controller.  I have this mostly done from a previous prototype, but need to convert it to the Harmony structure.

BC II PCBs have Arrived

Received the Brick Controller II PCBs.  Over the next few days I will be doing the necessary static testing to ensure that 1) I designed it correctly and 2) the manufacturer built it correctly.  Follow the progress here as I test these in conjunction with the MP3/FLASH module.