Friday, January 19, 2018

Entering the world of Tiny model trains: T-Gauge

Playing around with a new model train. I got my hands on a few pieces of track and a motorized chassis from Eishindo. The scale is 1:450 (T-Gauge) which is, well, tiny. The tracks are 3.3mm apart and is with bed just 12.5 mm wide. The train is just 52mm long (and it's the largest one available) and the radius of the smallest circle is 120mm.

Anyway, I didn't order any control box or whatever, just the track and a train. From what I've read the train needs about 4-4.5V to run and the official control box is just a PWM controller. Since I have plenty of Arduino's and a bunch of H-bridges in my parts collection I thought "why not make my own?"

So here we are:
100Hz PWM, 32% duty cycle seems to result in a velocity of 80mm/sec, which is about 130 km/h in full scale.

My goal is to embed all the electronics within the train itself. As you can see there is a bit of space available inside the chassis. Power is transferred to the train through the tracks. One rail is positive, the other is ground. By switching polarity the train changes direction. Power is picked up from the track by all wheels and transferred through some springs to the bus bars which runs through the top of the train. The springs also keep the bogeys attached to the train. The motor is connected to the bus bars through two springy connectors that just press against the bars.

This opens up some opportunities for a plug and play controller. Sliding a PCB between the motor connectors and the bus bars makes it easy to pick up power from one side and provide power to the motor on the other side while doing some controlling in between. So I'm going to need an H-bridge to control the motor and a micro controller to handle some logic and control the H-bridge.
Since there's no way to tell which of the bus bars is positive and which is ground I'm also going to need a few diodes. The ATtiny85 seems like a good choice: fairly small form factor (8 pin soic) 5 IO pins (1 for picking up an input signal, 2 for the H-bridge and the remaining 2 for some lights).  For the H-bridge I found the L9110 (which is the cheapest H-bridge in 8 pin SOIC on E-bay...)

There's a few ways to set up communications with the controller. Wirelessly (radio waves (BT, 2.4GHz, etc), infrared) or through the tracks. Since I'm trying to fit this in a space that measures about 5mm in width and ~15mm length there's just no space for wireless (and it's lame). So I'm gonna go with what most digital train systems use: communications through the tracks. The most popular existing system is DCC which communicates to decoders by switching the polarity of the tracks at a certain frequency (high frequency for a 1, low for a 0).
Decoders will have to rectify the incoming AC power to DC and should also detect the frequency of the AC signal; nothing a few diodes can't handle. I'll also need a capacitor to smooth out the power and deal with the noise the motor generates.

Parts list:
1x ATtiny85-20SU
1x L9110 H-Bridge
1x 1K resistor (pull up for reset line)
4x Diode to form a full bridge rectifier
Few capacitors

Sounds like a plan, but after measuring the available space I realize that there's not enough vertical space available to accommodate a populated double sided board...
So back to the drawing board it is...

Wednesday, April 27, 2016

From prototyping to product

Last post I ended with a blinking LED, just to verify that uploading code to the ATtiny works. The next step was testing the software SPI routine and actually talking to the MAX7221 ICs. Nerd Ralph wrote a wonderful software SPI implementation that I wanted to give a try. And of course it didn't work. Most likely it was something I was doing wrong. The LED displays were not doing anything, so time to bring out the oscilloscope!
Sure enough I was getting some signals out of the ATtiny, but I was missing the clock signal. After some debugging I found a typo I introduced to the SPI code. After fixing that, I got the right signals on the scope:
And of course, the LED displays finally did their magic:
Okay, cool, that works!

I already had some PCBs designed and manufactured using the same schematics I had on the breadboard.
So it's basically just four MAX7221's wired to an ATtiny24a. The MAX's are daisy chained in two strings of two. I'm using software SPI here because I need the SPI hardware to communicate with the main micro of this project. The ATtiny will act as an SPI slave.
Laying out this board was a nice challenge:

The pin layout of the MAX7221 so does NOT match the pin layout of the LED displays, so there's no way of doing this without a bunch of vias.
There's four displays on the front of the board and a couple of passives for the rotary encoder.
On the back we find the ICs and some more passives. As well as a connector for the rotary encoder and an ICSP header that also doubles as a connector to the main board.
The electrolytic capacitors, displays and connectors are through hole, all the other components are surface mount. The resistors and caps are 0603's. It's tiny, but everything can be soldered by hand. Even by me. And I suck at soldering.
Oh wow, it actually works!
Final shot: the prototype on the breadboard and the completed board next to it.

Sunday, April 24, 2016

Prototyping

I've been working on a little project for a while now. I want to build a programmable DC load, which isn't that complicated in itself. But I also want it to have a nice user interface. I didn't want to go with the standard 4 line character displays that everybody seems to be using. Instead I want to use a couple of segment LED displays to display voltage, current, power and resistance. The main reason for that is that I believe they're easier to read than a cheap LCD. The other reason is that they look much nicer IMHO :)

I have got a nice Hammond sink box in my parts bin that I'd like to use for this project. It's a big aluminium housing that can act as a heat sink. You can just bolt TO-220 packages to it on the inside; pretty neat.

Anyway. This means the dimensions are pretty much fixed and there's not much room to work with. This is what I came up with:

I'll probably move the connectors to the bottom and the rotary encoder to the right, but this should give you an idea of the dimensions.

The user interface will have its own micro controller to handle all the input and "menu" logic. I'll use an ATtiny24A for this (2K ROM, 128 RAM, 128 EEPROM, 14 pins) and four MAX7221's.
I already did some testing with an Arduino Nano to play with the rotary encoder and two displays. That worked pretty well, time to really start prototyping:
Yeah, messy. But nothing spectacular, just scaling up the previous setup. The icky part is using a new micro.
When using a bare ATtiny on a breadboard you only need two extra components: one ceramic cap (100nF) across the power supply pins and one resistor (1K-10K) between VCC and RESET. The ATtiny has an internal oscillator which it will use as a clock by default, so no need for a crystal.

Now for programming these micros. I always like to start of easy, just to make sure the programmer is wired correctly and I didn't mess up the clock settings. So I wrote a small program that toggles a specific pin every second, compiled that and uploaded it using avr-dude and a cheap USBASP dongle. And then all hell broke loose.
For starters, Windows 10 doesn't like the unsigned USBASP drivers, so I had to jump through some hoops to get that done. Then I managed to upload a program, once. After that I got all sorts of verification errors. Thinking the programmer was at fault, (since it was spewing out some warnings), I attempted to upgrade its firmware, bricking it in the process. Yay.
Plan B. Use an Arduino Nano as ISP programmer. That's simply a matter of uploading the AruinoISP sketch and wiring it to the ATtiny.
Still, no success. I could download the existing program from the ATtiny, but uploading a new one resulted in verification errors: it wouldn't write the new program.
Double checking the avr-dude configuration for the ATtiny with the datasheet didn't bring up any errors; that seemed to be okay. Then I attempted to write a custom binary file of all zeroes. That worked! But writing anything else didn't :/
Final step: swapping the ATtiny for a new one. Surprisingly, I was able to upload my program and finally got a blinking LED! But it was blinking too slow, so I probably got the speed wrong. After fixing my code the upload failed again! Comparing the uploaded code to the code read from the micro it finally hit me: bits were only being set to zero! Meaning the memory wasn't cleared before writing! Double checking the flags being passed to avr-dude I noticed the -D flag. Removing that fixed the problem! That only took an entire afternoon :/

So, next problem. The LED was only blinking every 8 seconds, instead of every second. The ATtiny is supposed to run at 8 MHz, but apparently it was only running at 1 MHz. A quick peek in the datasheet revealed the cause: CKDIV8 was enabled in one of the fuses, causing the clock to be divided by 8. All this setting does is set the default value of the clock prescaler to 8 instead of 1. This can either be fixed by burning new fuse values, or by setting the prescaler in code. I opted for the latter, because (a) that's easier to do than googling how to burn fuses, (b) I'm lazy and (c) it will work for new ICs with default fuses.

Two lines of code later, the LED is finally blinking at the right speed :)

Next: porting the existing code...

Tuesday, April 19, 2016

Fun with MAX7221 chips

Just a quick, short post here to show some stuff. I've been playing around with some seven-segment LED's and MAX7221 IC's; great fun. In collaboration with a colleague I've built a build monitor for our Jenkins CI server.

If you're interested in the source code: you can download it here
I'm using Atmel Studio 7 this time instead of the Arduino IDE. I had to roll my own UART interrupt handler in order to get everything to work correctly. The HardwareSerial class of Arduino just didn't cut it. I'm using AVRDude to upload the resulting HEX file to the Arduino.


It's three custom PCB's with a MAX7221 and seven segment display. The PCB's can be daisy chained. You can order the PCB's here. The bottom unit connects to an Arduino Nano. Vcc and Gnd connect to the 5V and Gnd pins. CLK to pin 13 (SCK). DIN to pin 11 (MOSI). CS to pin 9.

This is the schematic for a single PCB:
The PCB layout:
And a 3D render:
Yay, boards!

Doing some debugging:




It's working!



Combined with our CI Traffic light:


Tuesday, October 20, 2015

Synergy on Raspberry Pi


This article was written while Synergy version 1.7.4 was the latest version, I'll try to keep this up to date with new Synergy released, check the end of the article for a change log.

The latest version of Synergy at the last update of this article is: 1.7.6

I love to use Synergy when I'm working on multiple PC's at the same time. It lets you control multiple computers with a single keyboard and mouse. You just move your cursor off one side of your monitor and it appears on the device next to it and keyboard redirects keyboard input as well, neat!
So when I ended up with a second pair of input devices on my desk because of my new Raspberry Pi, having it use Synergy was pretty high on my wish list :)

The standard Synergy client you can get using apt-get is pretty old. It's version 1.3.something whereas the current version is 1.7.4, so that's not going to work. I found this tutorial on how to compile Synergy from source, but that article is outdated as well. Fortunately compiling it isn't that difficult. It's a pretty well documented process, but it doesn't exactly specify which dependencies there are. So here we go!

Step 1: update apt-get

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install gcc cmake libx11-dev libxtst-dev qt4-dev-tools libcurl4-openssl-dev libssl-dev libavahi-compat-libdnssd-dev


The documentation also mentions python and gmake as a dependency but I think those are included in a clean Raspbian installation. I also ran into some problems related to ZeroConf (missing headers), those seem to be included with libavahi.

Step 2: get the source code

Even though you'll need to pay for Synergy nowadays (if you want binaries) you can still get the source code for free: https://github.com/synergy/synergy or you can get a tar.gz from the download page (after a login).
If you have git installed, you can do

git clone https://github.com/synergy/synergy.git

Or get the tar.gz and run

tar -xzf synergy-v1.7.4-stable-c734bab-Source.tar.gz

Enter the folder that was created.

Step 3: build it

Start by configuring the build

sudo ./hm.sh conf -g1

This will generate the needed build script and will check if all prerequisites are present. When that completed successfully you can start the actual build.

sudo ./hm.sh build

This took about an hour to complete on my RPi 2B, so grab some lunch or diner while it's compiling. When it completed successfully, the binaries will be in the ./bin folder.

Step 4: deploy it

This is just a matter of copying the binaries:

sudo cp -a ./bin/. /usr/bin

Step 5: configure it

From this point on you can just follow the adafruit article. The only difference is that I didn't have a ~/.config/lxsession/LXDE folder, it's called LXDE-pi on my RPi instead.

sudo touch ~/.config/lxsession/LXDE-pi/autostart
sudo nano ~/.config/lxsession/LXDE-pi/autostart


And add the following content to the autostart file:

~/.startsynergy.sh

Exit nano (ctrl + x) and make sure you save the changes. This calls the startsynergy script whenever you start LXDE (Lightweight X11 Desktop Environment).
Now create the startsynergy script:

sudo nano ~/.startsynergy.sh

And add the following content:

#!/bin/bash

killall synergyc
sleep 1
synergyc --name pi 192.168.0.16
exit 0


This stops all running Synergy clients. It then starts a new Synergy client. "pi" is the name of the client, you'll need this name when you configure the Synergy server. The IP address needs to match that of your Synergy server.
Finally you'll need to set the rights on the newly created script:

sudo chmod 777 ~/.startsynergy.sh

Step 6: use it!

startx

 RPi on the leftmost monitor, showing the Jenkins dashboard in the browser. The other four are from my main PC (left to right: SourceTree, Eclipse, Jira and Notepad++). And one keyboard/mouse to rule them all! :)

Changelog:
2016-01-05: v 1.7.5 tested, no changes needed.
2016-03-29: v 1.7.6 tested, no changes needed.

Wednesday, September 9, 2015

How do they do it?

Just got some more parts in the mail:
10 nRF24L01+ boards for a whopping $8.12 and free shipping. Seriously, how do they do it and make a profit? I wouldn't be able to send an empty envelope to China for that kind of money...
A couple of years ago I ordered 4 of those boards for $10.40, that's $2.60 each, and now they cost $0.81...

Tuesday, September 1, 2015

First prototyping board assembled!

Got the last pin headers in the mail today!

It's annoying that I still have to rely on wires for this to work properly, but that's the price I pay for not double checking the footprints. The next version (almost done) will have a nice socket header to plug the nRF in.