At MyMakerTools we provide what powers your Maker projects and the Maker tools to be creative. This includes USB Power supplies to power your creations, the Maker Surprise line of Bricks & controllers, HO train goodies to make the layout stand out and soft wear to make your life just a little more comfortable.
Day 2 was the first public day. Attendance was very good and we had a steady stream of visitors all day.
Here is a picture of the hall
The highlight of the day was the light show for the builders. After dinner, they turned of the lights in the hall for 30 minutes. Quite a few of the MOCs had lighting of some kind, but a few had complete lighting systems, including ours. Unfortunately the camera did not do justice to what was on display.
Day ONE was mostly about setting up. There were several DRAFT plays and an informal talk on Trains. Finally towards the evening were several raffles for free goodies.
Always there are problems.
Here is a sequence of pictures as the Planetary Space Base assembles.
Aboce is the current center section. This used to have the the tall control tower on it, but that has been moved.
This is the Vertical Power Generator section.
This shows the Vertical Power Generator attached to the center section.
Here is the Main Defence section being tested.
The Horizontal Power Generator attached to the center section.
And a wider view showing both Generators and the center section.
The next two pictures show the MOC assembled.
Here is a quick video of the entire setup completely assembled.
A very good question. I would like to blog 4 to 5 times a week, but it never seems to happen. There is always too much to do and never enough time to do it.
I have been working on cleaning up the code some more for the train PCBs. By creating conditional compiles on the type of board, the amount of code that needs to be maintained has been reduced by almost half. This is a good thing, since making updates and adding new features is much faster now. The biggest change was to implement the Switch-Case structure using STATES in a cooperative multi-tasking model that is implemented in Harmony PIC32 code. The next big change was to implement structures instead of random variables everywhere. Again this is the standard in the Harmony implementations. With PIC18s and limited RAM, you have be careful about instantiating these structures multiple times or you run out of memory quickly. Judicious use makes the code much easier to maintain. But this did not come for free. It has taken time to work out these changes and then get them to work across the four PCBs the code runs on.
On thing that changed dramatically was the MiWi implementation. I have been using the last non-libary version of the MiWi framework for PIC18. Each PCB had its own implementation that may or may not be correct. One configuration item I know I got wrong was correctly setting the coordinator device vs end device role. This led to all kinds of issues on startup and trying to initialize the app sitting on top of the MiWi framework. Sometimes it would come up and other times it would just spin. So here is what I did.
First I created a module with a basic interface that starts and runs the MiWi framework. Using multiple implementation examples, I condensed this down to several functions calls that handle this within the Switch-Case model. These are:
MiWi _CreateNetwork is used by the coordinator device to create the network
MiWi_JoinNetwork is used by the end device to join an existing network
MiWi_AppTasks is used by both devices to service the MiWi framework through its various states, depending on the type of device.
There is a built in 10 second delay in joining an existing network, this gives time for the coordinator device to boot up. This assumes that all devices power on at the same time, which is true in my train layout. There are also two other support functions.
MiWi_ChannelScan is used by either device to scan all the channels and report the results. This is a wrapper for the framework implementation.
MiWi_CountConnections is used by the coordinator to count the current number of connections. I use this to determine if all the end devices have connected and then begin the application processes.
There are two states that are enumerated and one structure that contains all the information about the MiWi Network status and connections.
If you want to see the code, it can be download from the MyMakerTools website.
Here are the two latest PCBs. The top board in white solder mask is the MiWi-Bluetooth Bridge. This is used to control the Turnout & Signal PCB and the LED Controller PCB. The bottom PCB in yellow solder mask (I know it looks orange, but I have two PCBs done at different times with the same color). This is the LED Controller PCB.
The MiWi-BT Bridge uses two interfaces, USB HID and Bluetooth, to control the layout. I had done a brief discussion of it in this post.
In this picture I have both the MiWi and RN4020 BT Click modules installed. The modifications on the RN4020 Click module allow for RN4020 firmware upgrades. I have had good luck with this board and the MiWi side. I have used it to control the existing Turnout & Signal control PCBs that are installed in the layout. I built two of these. One is installed on the layout so I can make progress on the layout itself. The other I will use to continue the development of the MiWi interface with USB HID and to develop the BT side. Once that is done, I can update the Bridge PCB in the layout.
I have had limited success so far working on the BT side. Integrating the BT code I have from other projects is consuming more time than I thought. Mostly because I am updating the code to be more universal for future projects. While this work is impeding progress now, I am sure it will pay dividends on future projects.
The LED controller is very similar to the Turnout & Signal PCB. I had done a brief discussion of it in this post. Basically this controls 12 LED channels. Eight of the channels are connected to a PCA9624 from NXP. (Here is a link for more information.) The other 4 LED channels are controlled by the PIC18F27J53.
The PCA9624 allows for individual PWM control and up to 100mA of sink current. This should provide the capability for varying types of lighting effects on each channel, besides the normal ON/OFF. This is controlled through an I2C bus, which I will need to get up and running. I do have multiple examples of this from previous projects. I do plan on updating this also to a more universal format.
The pin configuration allowed for each of the 4 PIC connections to be controlled by a separate PWM controller in the PIC. Again this provides the flexibility for lighting effects.
Finally there is an I2C EEPROM for storing configuration. I intend to have the capability to have a default lighting setup. Otherwise when configuring the LED channels, one parameter will be whether or not this a power on configuration.
It has been a while since there was a chance to buy bulk LEGO by sifting through a Brick Pile. The two places I obtained bricks before have not offered this since Jan 2020. However, a 3rd party LEGO store in the Bay Area had a sale over the weekend with lots of variety. These pictures show what I got. I only had two hours, so I did not get as much as I would like. But it definitely scratched and itch that has been there for a while.
Mostly what I got was items for the continued work on the cliff area behind the Planetary Space Base. But there were other items that I needed for the Walker project I am working on also.
Plus there were several partially assembled items that were interesting, as shown here.
All in all, a good time was had and I may have to go back again.
This post is mostly about the PC software/PIC Firmware API and issues that needed to be resolved with the 10 year old software. But first a look from a high level what the main issue is. The combination of PC software and PIC firmware form a bridge between what the user sees and what the hardware does. The user sees a turnout or a signal a with a number associated with it. The hardware sees a PIC GPIO port that needs to be manipulated. Somehow these two perspectives need to be bridged in the PC Software and PIC firmware.
Since I have (or will have) a U shaped layout, turnouts,signals, uncouplers, LED lighting, etc on one side of the helix are even numbered and on the other they odd numbered. Where there are multiple track levels, the top level has 100 added to the number. The hardware interface to the train layout is 40 connection points that will energize a solenoid for a specified period of time. To reduce confusion, I will only describe how the turnout works. The remaining layout devices have similar functionality.
As a refresher, each normal turnout has two states. These two states are controlled by solenoids that are momentarily energized. Thus a turnout has two control wires, each energizing a solenoid that moves the points to either straight or turn. For those EEs out there is similar to a dual coil latching relay. You momentarily energize the the solenoid to position the points (or the signal) to the position that you want. Thus a single track needs two connection points from the hardware.
As a quick aside, in the old Marklin world, electrical connections were color coded by the pin connectors. These were
I have used these colors in the interface to ease the understanding and implementation of the interface. Also there are 3 types of turnouts, left/right for straight/curve, a slip turnout and a 3 way turnout (that uses 3 wires to control it) and two types of signals. Regardless they have similar functionality.
The task for the software is take the user number assigned to each turnout, which in turn has two wires connected to the hardware, determine the appropriate PIC GPIO pin and then transmit this data over the MiWi network. Here is the basic user interface
When the turnout is connected to the hardware, the port number is noted along with the action of that connection, straight (green) or turn (red). The information in this grid is kept in the EEPROM on the PCB in this format and in an INI file on the PC. The first two columns are populated by the software depending on the the hardware connected. The Device Type is chosen from a list that is derived from the Port Type column. The Action and Time(ms) column is chosen from a list that is derived from what is selected in the Device Type column. The User # is entered as number (1-255) by the user.
When the MiWi network initializes, the ports information is sent through the MiWi network to the Master MiWi device which is connected to the PC via a USB HID connection. Once all of the port connection data is received by the PC software, the data is sorted into another temporary table that is organized and sorted by the layout device (User #). This table describes which connection ports are connected to each layout device and what action each one of these connection ports does. Note that there is no requirement to use successive connection ports, it just make it easier to keep track of the layout devices. PC software and PIC firmware do not care if the green lead is connected to #1 and the red lead is connected #23 connection ports.
With this temporary table I call the Device Data Table, the GUI can determine which port number will need to be energized to set the turnout points in the correct state. If I chose to set turnout #35 to turn, the software scans the Device Data Table looking for turnout #35. Once it finds the table row with turnout #35, it scans the row looking for which port has been assigned to the turn (RED) action. Now it sends a MiWi message containing the board number, port number and the on time. The other data in the table is not relevant to energizing the solenoid. AS described above, it was used in the setup phase to help the user make the correct choices as to options for each layout device.
The PIC firmware then needs to translate this port number into a GPIO pin. To make this easier, the 40 connection ports are sequentially arranged in 3 MCP23S18 16-bit IO expanders. The last 8 pins are used for the track control. It is a simple matter of bit manipulation at this point. With a zero based port number, the lower 3 bits determine which bit in the 8 bit port needs to be set. The next 3 bits will choose which of the five 8 bit ports to use. The firmware then sets the bit, energizing the solenoid. After the directed time has expired, the firmware clears the bit and the solenoid is de-energized.
