MOC Update - Horizontal Generator

 

 

 This is where we started.

 

 

This is where we ended up.

Again they are basically the same on the outside.  There were significant changes on the inside.  As in the Vertical Generator, we really started here.

This one took much longer to redo than the last one.  And it still needs some cleanup.  

The first issue is just how slow can I make the motor turn with a PWM input.  I have never been happy with the approximate 1100 Hz that LEGO used in its design.  One it makes a lot of noise.  The PWM frequency will resonate and if a PWM frequency in the human audio range is chosen, you can hear it.  The lowest PWM value is about 50%.  Below that it just hums at 1100 Hz. All of the other motor PWM designs I have done in the past, including a fishing trolling motor, I used 15 KHz or higher.  That way only the dogs could hear it.

Motor speed on the space guns on this module is important.  They can't just swing from one side to the other.  It has to be some slow movement that looks controlled.  When testing at 50%, they were moving faster than I wanted. 

The gear reduction on the left is for the space guns. Some of this was driven by where the motors had to go and also to make space for the Brick Buddy 3 controller.  Independent motor control was not important.  Thus we have a long shaft that runs the length of the module.  This drives the two Space Guns in opposite directions.

The Horizontal generator on the other hand could go quite fast as does the two vertical cylinders.  The speed control provided by this gearing arrangement was more than sufficient for what I wanted.  The gears on the left in the above picture power this set of features.

This shows the Brick Buddy 3 about to be put into place.  I have run the motor cables through the module.  And have run the power to the AUX port to power the Brick Buddy 3.

The Brick Buddy 3 is in place now and the motors are connected.  Most of the covering is also in place.   Unfortunately I will have to remove some of this when I run the wires for the LED lighting.  

The first LED Lighting is in the control room area.  I added three LEDs that were not there before.  This LED is behind the control room and will light up the area directly in front of the generator.  This module was always dark until the generator turned on.  I never liked that and this changed is meant to correct this issue.

In the control room I added two LEDs.  One is white and one is red.  My thinking is that in the beginning, the white LED will be on.  When the generator starts to spin up, the light will changed from white to red.  The picture also shows how the wiring runs between to 1x1 round plates to the other side.

You cannot see it (by design I might add) the wiring.  It runs on the right side behind the three 1x1 round bricks.  The round brick on the far right side is concealing a small gap in the wall that the wires run down.

Here you can see the gap at the very top of the picture.  This runs down to the Brick Buddy 3 using the PCB connection device.

This shows the LED wiring for one of the Space Guns.  The wire runs down behind and the underneath the two cones.  This design keeps the wire tight to the back of the Space Gun.  Then it runs underneath the plate and between two 1x1 round plates.  This keeps the wiring centered on the Space Gun.

These two pictures show the wiring going into the wall, between to 1x1 round plates.  The space between the two plates is quite large and allows for wiring to run in between.  The picture doesn't show it very well, but the hole in the wall is directly behind the Space Gun.  This allows for minimal service loop to allow the gun to rotate.  While the wire might look like it is close to the gearing, there is actually quite a bit of distance.

For now I am continuing to use the pulley system.  This allows for slippage when the Space Guns reaches the end of its travel and the motor is sill on.  I have tested the motor connection to the sensor in the scripting language.  When the sensor is activated the motor is either stopped or reversed.  Once I wire this up, the pulley could change to a gear, though I like that the gears/motor are not mangled.  That comes with a price though, changing the rubber band is not easy at this time.

 

 

 

Floating Platform Concept

 

This is a concept for a floating platform that will be next to the Space Port module.  Right now the Space Port look like this.

My vision is to have at least one and maybe to landing pads and a floating walkway connecting the Space Port module to the floating platforms.

These are the only two base plates available.  I have one set and will acquire a few more, depending on the price.  These are not available in large quantities, so they demand a good price. I am thinking right now two landing pads and one connection piece.

The first picture is my first attempt at this.  I need a lot of black pieces to do this.  We always use a black table covering and that will be required to get the right effect.  Then I would build a walkway, similar to the one in the second picture.  Except it would be anchored on one end to the Space Port (as it is in the picture) and the other end to the floating platform.  Then the detailing starts. This provides a completely new "canvas" to work on, spotlights, small control tower, landing lights, vehicles, different size spacecraft, etc, etc, etc.

More on this in the coming weeks.  I am planning on some small version of this for Brick Fest Live in San Jose, June 17-18.

Brick Buddy 3 Issue

 

Ran into an interesting problem.  I have 5 of the new controllers completely built with BT.  Two of them will reset when running a motor.  But only when using the AUX power port.  The board is powered through the USB port when developing and programming.  Only when it is installed, had I intended to use the AUX power port.  The AUX port connector is the same type as the other connectors I have used though out the Space Base.

This is the AUX input.  Diode or'ed with VUSB

This is the USB input

This is the motor controller I have used for years.

VPWR feeds two DC-DC converters that make 5VDC and 9VDC(Buck-Boost so it will run from an input of 3.3VDC to 20VDC).  The 5VDC has a 3.3VDC LDO on it for the PIC, BT, Memory, etc and that LDO has a 1.8VDC LDO for LED Controller core.

Working Observations

• Works on USB port powered by USB HUB, Phone Charger and all battery Packs
• Works on AUX port powered by USB HUB, phone charger and some battery packs

Non Working Observations or tried this, did not change behavior

• Added 220uF cap at VPWR
• Added 22uF caps on motor controller (C40,C41)
• Tried different cables
• Sometimes will cause the battery to shutdown, other times just causes a reset

Obviously there is something about some of the batteries and the aux port. 

• Does the PI filter network on VUSB make that much difference.
• Did my Chinese builders use crappy caps for the build.  I specified X5R and they said that is what they used.
• How is the 9V bus radiating back through the DC-DC and effecting the 5VDC.
• Are these battery power backs at the end of their life ( ordered a new one from Amazon, we shall see)

Anyway I am moving on, just have to remember which battery pack goes to which model for now or bring out the USB connection.

MOC Update - Vertical Generator

 This is where we started

This is where we ended up.

Yes they are the same for the outside.  To be fair, here is where we actually started.

The two on the side are the old controller and the power supply.  With the new Brick Buddy 3, the controller is smaller and the power supply is included.  The Vertical Generator was the easiest to upgrade.  

This is what it looked like originally underneath.  There was a lot of room in it.  This is now what it looks like.

I moved the motor for more front to back space, though probably did not need it.  Changed out the dual white LEDs for RGBW LEDs.  The plan here is to turn on the White LED at about 50%.  Then one side will randomly pulse RED and BLUE while the other side does BLUE and GREEN.  Also I can get to the USB MINI connector from the bottom.  Thus when I need to update the script, I can.

Here it is with most of the top covering installed.  Two other changes were to make the tower removable.  The two LEDs in the tower are now on a connector and the tower is design to be easily removable.  The Sand Blue platform was changed to also be easily removable.  That will enable an easy way to do firmware upgrades until I can get the Bootloader working.

Finally the power is supplied by the standard connector I am using through out the Space Base.

You can just see the white connector on the bottom.

 

 

 

 

 

Brick Fest vs Trains vs Blogging

 

Back to the old issue of working on stuff vs writing about stuff.  Working on three different things right now.

• Another IKEA bookcase hack in a closet.  Will update this in a few days.
• Getting closer to the trains being ready for the grand kids arrival
• Updating the Space Base for Brick Fest Live.  The configurations is changing from a semi circle that is 80" long and 30" deep to a curve that is about 120" long and 24" deep.  Most convention tables are only 30" deep and this caused part of the display to hang over the front edge.

I am making a concerted effort now to post more of what is happening, epecially about the upcoming Brick Fest Live.

 

 

RN4020 to RN4871 Update 2

In this post and the follow on post, I discussed the changes I have made for this transition to the RN4871.   I am getting near the end of this being done.  After testing with a several Play Store Apps (Nordic, Silicon Labs, and Microchip) I found that the name I assigned to the RN4871 was not showing up in the scan.  Again in the RN4020 this was not an issue, the SDN command was sufficient.  But for the RN4871 or maybe the version of BTLE that is running, this is an issue.  Unless you know the MAC address, the user would have a hard time determining which device listed is the Brick Buddy.  It is not uncommon for me to see 10-15 BTLE devices in my lab.  Not sure where they are all coming from, but these is a lot.  

Well it became apparent from examining those devices I was seeing that had a name attached, they were placing this in the Advertisement.  The RN4871 has an Advertisement limit of 30 bytes (31 bytes in later firmware).  Fortunately I had 11 bytes left from 30. So I added the name and that brought me up to 27 bytes total.  But as with adding the service, you could not just put the name in as text, as here.

NA,09,B_Buddy  

The NA command requires the actual hex bytes that represent the name.  This is alluded to in the RN4871 documentation, but is not really clear.  The 09 is the command for the complete local name.  

NA,09,422D4275646479     

It seems that everything works now.  The Android App finds it, connects automatically and the name is displayed with the last two address octets attached.  The Android App does allow you to name the Brick Buddy device and then bind that name to the MAC address.  From then on, it shows the name instead of the MAC address.  A more user friendly approach when you have multiple Brick Buddy's in a MOC.

Final change will be a check to see if the  RN4871 Non Volatile Memory (NVM) is valid.  Not sure how to do this yet.  I am somewhat concerned that reloading the NVM on every restart will wear this out too soon.  Especially for the device(s) I use for development.  The easiest way is probably to place a flag in the PIC EEPROM (or I2C memory when it is installed) that indicated a valid NVM.  Thus when the NVM is written and all commands have been accepted, the flag would be updated.  I currently have a config word that is kept, I just need to add this to it.

 

 

 

 

More Train Control

 

 In this post, I talked about the issues I was having getting the next build working.  I finally pulled the one installed.  I had replaced the 10L series with a 10ohm SMT0805.  While an SMT0805 will handle more power than an SMT0603, still not good.  So I replaced the 10ohm with the same parallel combination of 120 ohms to get it to 60 ohms.  

As the above picture shows, I finally finished with the way too many SOT23 I had to put down.  Also DigiKey had 6000+ of the Transceiver module, so I bought some to populate these boards.  The plugin module was a nice stop gap, but with it perpendicular to the board, I was always afraid that it would get damaged pushing a box underneath the layout.

All of this started with one signal that I could hear activating, but it would not move the signal arm.  This was an old style signal that I had buried in the layout as show here.

 

During the move, the black metal tab dislodged from the plastic plunger.  The plunger moves back and forth inside the solenoid plastic form.  You can see the tab better in this picture.  Now I have to replace the heavy paper that covered the solenoid housing.

 

 

 And finally this what one controller installed looks like.  Still a rats nest.

Understanding Parallel Resistance

 

I am back on the train control for a few days.  I explained these PCBs awhile back in these posts (post 1, post 2, post 3 and others).  I have installed one and have done some testing on it.  These replace the existing ones I had built many years ago.  

The major difference between the new design and the old design was how the relay(solenoid) driving circuit was controlled.  The driving circuit is a N Channel MOSFET with a DIODE for back EMF protection.  One side of the solenoid is connected to the positive voltage generated from the transformer accessory voltage (simple full wave rectification of the AC signal with lots of capacitance to make it as close to DC as possible).  The other side is connected to the driving circuit which grounds this side of the  solenoid, thus activating the solenoid.  In the original design by Marklin, they used NMOS transistor.  Because NMOS has a relatively high Rds ON, this required TO-220 type package to dissipate the heat.  I am using MOSFET with an Rds ON in the 100's of mOhms.  Thus a SOT-23 package works fine.  When I first did this, I set up a test where a switched a track every 5 seconds for several days.  The MOSFET never got warm.  That convinced me that this would work.

The original design had 32 driving circuits.  Therefore I needed 32 GPIOs, just to do this.  There was an I/O expander from Microchip, but then it was only 8 bits.  That would have meant I would need four of them.  In those days PCB fabrication was a more expensive than today, thus I looked for a smaller footprint solution.  I found a PIC16F1526 in a 64 pin QFP.  Thus I used this as the IO expander with SPI interface from the main PIC18F47J53.  The new design was driven by parts availability as  I described in the earlier posts.  This led to 3 16 bit I/O expanders.  This is the main difference.

The I/O expanders were OPEN DRAIN outputs, which meant when they were on, they needed to be pulled up to drive the gate on the MOSFET.  This afforded an opportuinty to push the gate beyond 3.3VDC and thus drive the MOSFET further into saturation. lowering the Rds ON.  

The new design uses a single MOSFET to provide a bias as shown in post 1 above.  That works for the schematic shown.  But when you put 40 driving circuits in parallel (new design has 40 solenoid circuits), things change.  Normally all the outputs of the I/O Expander are at ground.  Only when driving the solenoid for the several hundred milliseconds does the output tri-state and the bias control pulls it up to 5VDC.  Thus what you have is forty 10K resistors in parallel to ground that is then in series with the 1K pullup resistor on the MOSFET DRAIN, which at this time the MOSFET is off and the DRAIN is floating. 

Going back to circuit theory, the forty 10K resistors form an equivalent circuit of a 250 ohm resistor.  Then the voltage divider shows that the bias point is actually at 1VDC not 5VDC.  Activating a driving circuit has minimal impact on these calculations as 39 resistors in parallel only rise a few ohms.  

In an ideal world, the 1K series resistor should be 10 ohms.  That would change the bias point to 4.88 VDC. But if the MOSFET controlling the bias point should turn on, then 500mA will flow and the resistor would have to dissipate 2.5W.  Not possible with a SMT0603 resistor.  So I put two 120ohm resistors in parallel, which moved the bias point to 4VDC and the total power dissipation to 416mW or about 200mW in each resistor.  Not to specification, but much better than 2.5W.

So the question in my mind is what, if anything, did I do to the one PCB that is installed in the layout.  It seems to work.  There is nothing in my notes about changing the series resistor.  Once I get something installed, I am going to have to pull that one and see what I did.

Brick Shows What is Next

 Brick Fest Live!

 We will be at Brick Fest Live in San Jose CA, June 17 and 18.

Also we will be at Brick Fest Live in San Diego CA August 26 and 27.

 Here is the link to get tickets and the main website.

We attended the last time they were in San Diego, back in Nov 2021.  This towards the end of COVID, so it was a subdued event.  But now these events are going back to full engagement and we look forward to attending.

There may be more, still working on the details.

 

 

 

Microchip BLE Module Comparison

 This shows the relative size comparison of the Microchip BTLE modules.  Numbers are nice, but a visual portrays much more information.  The RN4871 is the smallest.  The newer RNBD451PE is somewhat larger, but maybe all you need depending on what your device is doing.

Enjoy!

 

 

 

RN4020 to RN4871 Update

 

I have had my head down while trying to make this transition that I described briefly in this post.  I have had some success and learned a few things along the way.  

I am no BTLE expert and I have tried to slug through the specifications, but it is a tough read for those of us who don't do this on a daily basis.  The RN4020 was 4.2 and the RN4871 says it is 5.0 and beyond.  I am assuming that some enhanced features were added.  My Android code was quite dependent on this real time read feature of the RN4020.  Without this, getting data back was difficult.  

After some reading, I implemented the Notification feature for each characteristic.  I had done this with the Heartbeat characteristic, but now all of the characteristics have this enabled.  This will also enable me to continue to support existing Brick Buddy I controllers.  The Android APP tested to see if Notifications are enabled on the Brick Buddy.  If they are, the new code is implemented, otherwise the Android APP stays with the old methodology.  So now I write to the Characteristic, the 18F26Q71 performs the tasks, updates the characteristic value and then notifies the Android APP the characteristic has changed.  The APP is waiting (in a separate thread) for a few seconds for the 18F26Q71 to respond (plenty of time at 64MHz).

Next issue was finding the the Brick Buddy during scanning.  The Android APP had implemented a scan search on the MyMakerTools UUID.  While it continues to work for RN4020 devices, it failed on all RN4871 devices.  I could scan for it along with every other BTLE device in the house and the neighborhood.  Sometimes I would see 20 devices.  At first I thought this was an issue with the Delphi compiler.  After tracing deep into the library, I decided this was not the issue.  This must be something to do with advertising.  Again, not a BTLE expert and if the spec changed, then I was not seeing it.  I found a note in a RN4870/4871 firmware upgrade document that said:

This led to lots of reading on the NA command, which is about advertising.  So in the RN4871, you have to purposely advertise services.  If the Android APP is filtering on a specific service list, those services must be advertised.  If not filtering on a specific service list, then all reachable BTLE devices show up.  The system will still connect, but it is multi step process that should just happen.

So here is the initialization of the RN4871 across the ASCII UART interface.  Will another sequence work, probably, but I know this works.

• PZ
• NA,Z  

reboot here

• SS,80            ; setup
  
• SN,B-Buddy       ; device name
  
• SDN,MyMakerTools ; mfg name
  
• PS,3425a5cca67643629592a88e132b8b52       ;service
  
• PC,b67e3a3b15c941b6a9f2fbf379418d12,12,02 ;characteristic
  
• PC,f18e901af3254dfd8cdb68506676dc08,16,08 ;characteristic
• PC,9bac1d289fc14db097c4896089ad26bb,16,08 ;characteristic
• PC,39bb1bf917ec41d2b5e4b78551b45740,06,08 ;characteristic
• NA,01,06         ; set flags
  
• NA,07,528b2b138ea89295624376a6cca52534    ;advertised service
  
• A                ; turn on advertising
  

 The first two clear out the services/characteristics and the advertisement data, followed by a reboot.  The next are setup and naming, followed by the service and the characteristics.  The first NA command sets the flags.  The first hex value is the AD Type which is found in Table 2-14 of the RN4870/71 Users Guide.  The next is an 8 bit value that reflects which flags are active.  You will need to search the internet to find this, but 0x06 is the most common value.  The last NA command is the advertised service.  You will notice that is does not match the service.  For whatever reason, the NA, 07 command will not take the value as the PS command does, it needs to be completely byte swapped.  Not the most user friendly, but probably made sense to someone.  Finally I purposely started advertising.  This is supposed to be the default, but it costs very little.  I did not test the initialization without this, so I don't know if the default is works also.

I am back to where I was with the RN4020.  I still need to verify the Android APP with the original Brick Buddy, but that is a task for another day.

 

 

Upgrading from RN4020 to RN4871

 

 I am in the process of upgrading the wireless interface for those people who want to install it.   I was hoping that moving from the RN4020 to the RN4871 would be simple and painless.  As is always the case now, it was not.

I use the ASCII interface over a standard serial UART.  While most of the commands are the same, there are changes.

1. They have included a delimiter on all GATT messages (%) plus a few others.  While it makes the parsing a little easier, it changed the way the parser worked.  
2. The RN4871 is very sensitive to power and the reset input (see this post).  When I designed Brick Controller 3, I used the PIC nMCLR input to reset the RN4871.  This in turn is driven by TC54 reset controller.  So that part is good, since it appears the RC type resets don't work.  I do have a spare GPIO now, so I could cut/jump that in if it becomes necessary.
3. There is a transparent UART mode, but I am not sure how much Android work that will entail, if it is even possible.
4. The most important change was the elimination of the real time read mode.  The mode would send a message across the UART that the phone was about to read the characteristic.  This would allows the PIC just enough time to update the characteristic value before the phone read it.  That is not implemented in the RN4871.  So I am looking at other ways to do this.

I mostly have the interface working.  It seems to be stable, though the code needs some work.  The 18F26Q71 running at 64MHz, is just too fast for a 115200 baud rate.  During initialization, I have to make sure that the RN4871 response has come in before moving on to another command.  While this implemented in essentially "wait for it to happen" code, this needs to move into the switch function of the BT_TASKS subroutine of the main loop.

 

 

 

 

Brick Days 2023 - After thought

 

 

Here is a video of the space base at night.  Could have been better,  Maybe I should buy a steady cam.😁