To make the next step here I need the garage to do some construction work. In the mean time I am building up more control boards for tracks and lights. All the controllers work on a Zigbee derivative mesh network (MiWi), which is why I cant use the LEGO controllers. The light controller uses I2C memory for configuration/script storage (PIC18F47J53 has no internal EEPROM) instead of SPI like everything else. This is because the LED controller is I2C and the MiWi controller is SPI. With two MSSP controllers, one for SPI and one for I2C. The MiWi controller could share the SPI, but then mesh network traffic can get bottled up. The demand on the I2C network is very sparse. All of this drove me to refactor the code base to abstract the memory access type. This was a little more complicated, but I have the I2C working. Microchip has fairly good DEMO code, but when you start to modify, it is not as stable as you might want. Plus they #ifdef to the limit, so it will run on every demo board or processor they ever made.
I have been stuck trying to upgrade my train software. Since I have 4 working controllers and one bridge in the mesh now, things are a little funky. It all works until the PC asks the bridge to send the configuration data from each controller. Some 200 pieces of config data plus all the ACKs need to move thru the mesh. This data exchange is a complete handshake. The PC sends a very specific request to the bridge, the bridge sends a message to the specific controller, the controller responds to the bridge, the bridge sends to the PC and the process start over. I spent days tracking down what was causing it to get way out of sync. Plus I did lots of code refactoring to eliminate redundant code. It took two laptops, one connected to the bridge as a controlling link and as a PIC debugger and one connected to a controller to watch message traffic. After a few days I think what is happening is that the bridge is getting the same message from multiple controllers as the mesh tries to make sure all messages get thru. At least I am getting the same RF message at the bridge multiple times and then bridge just turns these around and sends them to the PC over USB. The only way to confirm this is to get another PC and hook up the wireless sniffer and watch all the packets go back and forth. But I decided to band-aid it so I could move on. Now I just track the data at the PC, if I already had that piece of data, any repeats were just dropped on the floor The system initializes properly now, but I got this feeling this will come back at me.
Now I moving on to why some track solenoids don't want to fully activate. Some of these are 50+ years old, but this is the original "German Engineering" and "Built In West Germany". My guess is that the FET grounding one side to activate the solenoid is not getting close enough to ground eg, not showing a large enough potential across the coil to get it to move. I may have to remove the track and rebuild the switches by cleaning the solenoid actuators.
No comments:
Post a Comment