Detecting Trains

Train sensing has been implemented via light sensors. I needed 24 sensors around the track and decided that multiplexing was the only way to read them all. 3x 4051 ICs came in handy and were configured as per the schematic below. You can find a better explanation on light sensor implementation in the article here.

I've simplified the code for reading the sensors as I'll ensure all of them have sufficient lighting and therefore 'stable' values. The circuit waits a second after power-up to read the initial sensor values. It then marks each one as 'active' if the value is greater than 20 'points' above the initial value. If a reading comes in lower then the initially read value then that value is lowered accordingly. I've also created a special command (frame id: 0x333) to allow a reset of all sensor values (specifically if ambient light proves a problem.)

The node sends out the sensor values and then pauses 100ms. The CAN packet with sensor data has the frame ID 0x111 and then fills three bytes with the 24 sensors states. A '1' is used for occupied and a '0' for vacant. The message will be received by any node on the network with the appropriate filters set.

Controlling LEDs

To control the LEDs I've re-used the previous MAX7219 ICs that I had lying around. There's a much more in-depth article here on how to use this chip. The MAX7219 requires three wires to the Arduino... but I'd already used up all the digital pins. Fortunately you can use the Analog pins just as easily.

As the MAX7219 can receive bytes per row to control the LEDs I simply pass through the data from the CAN bus when appropriate. It would only take one CAN message as they contain 8 bytes of data. The Frame ID for this message is 0x222. You can see that I'm being pretty wasteful with Frame IDs but, fortunately, I don't have many specific messages to send.

Completed Sensor+LED Node

So, it was soldered and wired... quite a mess really. The CAN Controller was on-board but there was no 'direct communications' interface to the PC. This meant I had to pop the chip out (atmega328) each time I wanted to change the code... tedious and dangerous!! I managed to bend pins and confuse myself every now and then. Don't do this at home!

Controller Node

I've got a third node hooked up to the computer via my trusty old Arduino Mega. This node transmits data from the CAN Bus to the PC via the standard serial-over-USB connection. A .NET application then shows the layout and allows you to interact with the LEDs and sensors accordingly. It shows the status of the sensors at any point in time and allows you to create rules in a sequence which can determine the speed and direction of the train.

The physical design of this node is simply the Arduino Mega plus the CAN schematic as seen in my previous blog post on implementing the MCP2515 controller.

  if (CAN.buffer0DataWaiting()) {
    CAN.readDATA_ff_0(&length,frame_data,&frame_id, &ext, &filter);
    Serial.write("X");
    Serial.write(frame_data[0]);
    Serial.write(frame_data[1]);
    Serial.write(frame_data[2]);
  }

  while (Serial.available() >= 9) {
    // read the incoming byte:
    b = Serial.read();
    if (b == 'L') {
      for (int i = 0; i < 8; i++) frame_data[i] = Serial.read();
      frame_id = 0x222;
      CAN.load_ff_0(8, &frame_id, frame_data, false);
    } else if (b == 'D') {
      for (int i = 0; i < 8; i++) frame_data[i] = Serial.read();
      frame_id = 0x666;
      CAN.load_ff_0(8, &frame_id, frame_data, false);
      //printBuf(frame_id, frame_data);
    } else if (b == 'R') {
      for (int i = 0; i < 8; i++) frame_data[i] = Serial.read();
      frame_id = 0x333;
      CAN.load_ff_0(8, &frame_id, frame_data, false);
    } else if (b == 'P') {
      for (int i = 0; i < 8; i++) frame_data[i] = Serial.read();
      frame_id = 0x777;
      CAN.load_ff_0(8, &frame_id, frame_data, false);
    }
  }

LED+Sensor Node Code

The sensor code consisted of an initial sensor read and then constant sensor checking. The sensors were then determined to be either 'occupied' or 'vacant' and then the data was sent. There are no 'smarts' here... the sensor data is simply hammered over the network.

The receive buffers are also checked for a Frame ID of 0x222 or 0x333. The filters are set appropriately to ensure that only these messages trigger the interrupts. The LED data is sent to the MAX7219 controller on the 0x222 message and the sensors are reset on 0x333.

void loop() {
  send_data[0] = 0;
  send_data[1] = 0;
  send_data[2] = 0;
  for (sens = 0; sens < 8; sens++) {
    setOutputBit(sens);
    sensor_read = readInput(0);
    if (sensor_read < sensor[sens]) sensor[sens] = sensor_read;
    send_data[0] |= (((20 + sensor[sens])      <= sensor_read) << sens);
    sensor_read = readInput(1);
    if (sensor_read < sensor[sens]) sensor[sens] = sensor_read;
    send_data[1] |= (((20 + sensor[sens + 8])  <= sensor_read) << sens);
    sensor_read = readInput(2);
    if (sensor_read < sensor[sens]) sensor[sens] = sensor_read;
    send_data[2] |= (((20 + sensor[sens + 16]) <= sensor_read) << sens);
  }
  frame_id = 0x111;
  CAN.load_ff_0(3, &frame_id, send_data, false);

  frame_data[0] = 0;

  data1 = CAN.buffer0DataWaiting();
  data2 = CAN.buffer1DataWaiting();

  if (data1 || data2) {
    if (data1) CAN.readDATA_ff_0(&length, frame_data, &frame_id, &ext, &filter);
    if (data2) CAN.readDATA_ff_1(&length, frame_data, &frame_id, &ext, &filter);

    if (frame_id == 0x222) {
      for (int i = 0; i < 8; i++) lcl.setRow(0, i, frame_data[i]);
    } else if (frame_id == 0x333) {
      for (sens = 0; sens < 8; sens++) {
        setOutputBit(sens);
        sensor[sens] = readInput(0);
        sensor[sens + 8] = readInput(1);
        sensor[sens + 16] = readInput(2);
      }
    }
 }
 delay(100);
}

Controller Node Code

The controller was the middle-man for translating PC code to the CAN bus and vice-versa. Sensor data from the CAN bus was converted to serial data with a leading 'X' byte. On the contrary LED commands were received from the PC with a leading 'L' byte. The following 8 bytes were sent as a single message onto the CAN bus once this character was seen.

    using System.IO.Ports;
    SerialPort _serialPort;

    private void SetupComPort() {
        _serialPort = new SerialPort("COM3", 9600, Parity.None, 8, StopBits.One);
        _serialPort.Handshake = Handshake.None;
        _serialPort.DataReceived += new SerialDataReceivedEventHandler(HandleData);
        _serialPort.Open();
    }

    private void cb_CheckedChanged(object sender, EventArgs e)
    {
        Byte[] bytesToSend = new Byte[9];
        bytesToSend[0] = (byte)'L';
        for (int i = 0; i < 8; i++) {
            for (int z = 0; z < 8; z++) bytesToSend[i+1] |= (byte)((LEDs[(i*8) + z].Checked ? 1 : 0) << z);
        }
        _serialPort.Write(bytesToSend, 0, 9);
    }

    private void UpdateSpeed()
    {
        Byte[] bytesToSend = new Byte[9];
        bytesToSend[0] = (byte)'D';
        bytesToSend[1] = (byte)(direction ? 1 : 0);
        bytesToSend[2] = (byte)hSpeed.Value;
        bytesToSend[3] = (byte)points[0]; //for loop? probably should.
        bytesToSend[4] = (byte)points[1];
        bytesToSend[5] = (byte)points[2];
        bytesToSend[6] = (byte)points[3];
        bytesToSend[7] = (byte)points[4];
        bytesToSend[8] = (byte)points[5];
        _serialPort.Write(bytesToSend, 0, 9);
        Console.WriteLine("Sent: D" + bytesToSend[1] + "-" + bytesToSend[2]);
    }

Notes learnt from hooking all this up

• CAN Filters work, but you can still see messages
  On the CAN controller you can set filters to only allow specific messages through. It actually turns out that, regardless of the filter being set, if you constantly poll either buffer for a message that, if there has been a message sent, it will be available and can be received from the network. Filters simply prevent the message from triggering the 'message waiting in buffer' interrupts. So, the best bet is that you check for a message in a buffer first rather than simply constantly attempt to receive messages. Let the CAN IC tell you that a message is waiting!
• You can easily spam a CAN network
  Sending too many messages over the network will delay or prevent transmission of other nodes' messages. One node can send too many messages over the network preventing another from successfully getting messages into a third nodes' buffers. It's all down to how quickly the third node can receive the messages. If both receiving buffers are full then the message will fly on past and not be seen.
• Inserting and removing ICs
  
  PLEASE only do this when you need to and do this with care! Lever them out from both ends and DO NOT just use your fingers. Insert them evenly as well. It's too damn easy to destroy these delicate and expensive components.

...next will be a node to control the thottle, isolated blocks and point-servos.

One of the most popular uses for this technology is in the automobile where the network provides a communication channel between the ECU, Transmission, airbags, braking systems, etc...

As you'll have noticed, I've recently been investigating OpenLCB which uses this technology for communications between its nodes on a model railway. The article below will show how the CAN bus can be incorporated with an Arduino to allow communications between different microcontrollers/nodes on your network.

Topography

The OpenLCB project dictates that the CAN bus implemented via their standards must not be in the form of a ring. When I initially saw the Railstars:io prototype I expected that a ring would be required; the prototype shows an 'in' and 'out' communications port. Little did I realise that, upon closer inspection, the io could act as a termination point for the CAN bus that it connects to. We therefore will implement a layout as follows on our railways...

The OpenLCB project will use standard RJ45 cables (i.e. ethernet cables) due to the requirement of twisted pair technology to guarantee data transmission.

Interfacing with the Arduino via SPI

The Serial Peripheral Interface is a communication standard used to provide communications between integrated circuits. The Arduino has an SPI library and therefore allows us to easily communicate to the CAN interface.

We'll be using the MCP2515 and MCP2551 integrated circuits to transmit/receive our data from SPI onto the CAN bus. This setup has been done before in Sparkfun's CAN-BUS Shield, the CAN-CAN, the Universal CAN Library (Universelle CAN Bibliothek) and the CANduino. The CAN-CAN Schematic and Sparkfun's schematics provide a great reference point for hooking the whole lot up. Of course, you could also just grab their shield if you don't want to build everything yourself.

Schematic

The image below should be pretty self-explanatory. See the next section for the exact pins for the SPI interface. RESET and INT can go to any digital pin.

Building, troubleshooting and talking to one's self

I built two at the same time to be able to test node-to-node communications. There was nothing overly tricky in the construction... I just chose to use relatively tight pcb prototyping boards which didn't leave much room for error. The above schematic was followed and the devices were hooked up to my Arduino(s).

I tried the loopback test from the canduino project and got random responses... the data going in was not the same as the data coming back. I started the debugging process after letting out a little sigh.

It turns out that, on all Arduinos, the SPI interface can only be used on specific pins:

Note that the CAN library also then required a change as the pins in it are hard-coded to a 168/328 Arduino and wouldn't have ever worked with the Mega. You can find my fix for this down below.

I finally had responses after the pins were in the correct locations... but not the responses I wanted to see; I looked at the crystals next. My Arduinos all used 16.000MHZ crystals, but my local hobby shop only had 4mhz, 8mhz or 20mhz. This concerned me and I google'd and google'd to work out if, in the same circuit, multiple ICs could be driven off different oscillation rates. I decided that, since the 'SPI' interface had it's own 'bus rate' and the CAN bus also had it's own 'bus rate' that the crystals therefore did not affect these speeds. Also, the Arduino would dictate the speed of the SPI interface since it was the master (and slower.) I therefore bought 20mhz crystals for the MCP2515 chips, with my fingers crossed. Of course, this could have been the next issue.

Fortunately, from my previous attempts at barebones Arduinos, I had a 16mhz crystal on-hand. I swapped out the 2 capacitors and the 20mhz for the 16mhz and hooked it all up again. Nothing...

So, I then whipped out my Atmega328p 'barebones' Arduino and hooked it up to that. The SPI pins were different, as per above, so I made sure they were correct... and the CAN library from the canduino source had to be modified back to the required pins. After putting it all together I checked the serial output in the Arduino Serial Monitor and saw the correct response. The loop back test was working!

WTH... there was no reason that it should... except that maybe the SPI interface on my Mega was fried? I then, just because I hate caution and feed it to the wind all the time, swapped the 20mhz crystal and capacitors back in. It STILL WORKED! Good... I could keep the 16mhz for my other barebones Arduino.

So... with a known-working CAN node, I swapped it back onto the Mega. WTH... it worked. I now had my CAN nodes (by this time the other node built was also functioning thanks to it's guinea pig brother) talking to themselves. It was time to get them to talk to each other!

Talking in the CAN

Hah... there's an unwritten rule to not talk whilst in the toilet, but in our situation we'll make an exception. From the start I'd built the bus and was just itching to get the damn thing transmitting messages. The setup was simple: terminal blocks were used at junctions and standard dodgy speaker wire was the main network cable. 120ohm resistors were the terminators as per the standard CAN specification.

The only real issues here were the source code (or my lack of knowledge of how it worked) and the usage of crystals. Yes, they came back to haunt me... it turns out that, whilst I had the loopback going, I'd left a 16mhz on one node and a 20mhz on the other. In the source code you specify the 'CAN Bus Speed' which, of course, was configured the same on both Arduinos. The actual issue was that, when the Arduino told the CAN controller to run at bus speed '1000', the CAN nodes did this but, due to their differing crystals, their calculations of what '1000' meant were incorrect! Since one was running 4mhz faster (20mhz vs. 16mhz) it must've been communicating on the bus at a different rate and therefore confusing the hell out of the other node.

The next issue was the code... I looked over it and thought that each node would take turns in transmitting and recieving... I was wrong: you had to actually set one as the sender and one as the receiver. I configured this based on the Arduino class (by #IFDEF just as the SPI pins were configured) and then had communication! My nodes were live and functional!

RX/TX LEDs

The final step was wanting RX/TX activity LEDs. It turns out that the MCP2515 supports this, but you need to do a little configuration. If you view the datasheet at microchip you'll note that the RXnBF Pins can be configured as 'nothing', 'general outputs' or 'low on RX buffer full'. I was hoping that obe would be 'high on TX buffer', but no such luck. It actually turns out that the chip has two RX buffers and therefore two RXnBF Pins. LEDs attached to these pins will, once configured as per below, illuminate once the associated RX buffer is full. If you ever see both full then you might be losing data?

Second option: It turns out that in the MCP2515 Demo Board PDF that you can just put two LEDs on the RXCAN(1)/TXCAN(2) pins of the MCP2515.

Third option: It seems that you can also configure the INT pin to fire on TX buffer 'emptying'. You'll have to disable the pin firing on all other error situations to do this. By default, this pin is usually pulled 'high' by the MCU, so you must either disconnect that, use a resistor between the MCU and MCP2515 or just pull the pin high normally via a pullup resistor and then connect an LED in parallel with this to the INT pin. I imagine that in more complicated scenarios you'd actually want to know once the MCP2515 has generated an interrupt.

IDs: Standard or Extended?

All messages sent on the network have a 'frame id' of either (standard mode) 11-bits or (extended mode) 29-bits. It must be understood that this 'frame id' does not actually identify a node! It is simply an identifier for the actual message being transmitted. This identifier can contain any form of information you want; the bits are yours to play with.

One main use for this identifier is to record the intended recipient of the message you are sending. Depending on the amount of nodes in your network (don't forget to think of future scalability!) you can use anywhere up to 29-bits to uniquely identify them. Of course, this identifier could just be used to identify the 'class' of node and then you could put further data in the message to indicate the exact recipient. You could also go the other way and only use a portion of the identifier for the recipient code and have the rest for other uses.

The MCP2515 has in-built filtering to work on the identifier of incoming messages. If you're only using standard mode then the filters also apply to the first two bytes of the message. The filtering works inside the MCP2515 and therefore doesn't saturate your SPI link as the messages are stopped prior to being put into the RX buffer.

MCP2515 Modes

There's 5 modes that you can set the MCP2515 into. These are as follows:

Buffers

It needs to be noted that the MCP2515 has two receiving buffers known as Buffer 0 and Buffer 1. Messages will go to the first if it's free (and not filtered) and then the second. Filters can be set on both, but the second buffer is much more flexible with four filters.

I don't know the exact reason for the MCP2515 containing two buffers, and then why one is more flexibile than the other, but in the end it's up to the developer as to how to use them. Filters can be configured to allow specific message 'types' on each buffer. This then means that, for example, the developer could configure the second buffer to only allow emergency messages such as 'STOP THAT TRAIN' whilst the first deals with the standard communications.

Filtering CAN Messages via the MCP2515

With the base configuration, an MCP2515 controller will accept any messages sent across the network. This therefore means that your nodes need to filter each individual message coming across the bus to determine if they themselves are the intended recipient. Fortunately the MCP2515 has in-built configurable filtering to allow only messages intended for the node to be passed through its RX buffers.

The MCP2515 has 6 configurable filters with 2 masks. The first mask works in conjunction with the first two filters and applies to the first receiving buffer whereas the second mask works with the final 4 filters and works with the second receiving buffer. Filtering is enabled when any bit of a mask is '1' and disabled when the masks are completely zero'd out.

You may be wondering why both a mask and a filter are needed? As mentioned above, you may not have used the entire 'identifier' area of the sent message to indicate the recipient. Therefore, when you're checking an incoming message, you wont want to filter the entire identifier. As the identifier bits can be a '1' or '0', you need to initially specify which bits you want to check (mask) and then whether or not they are a '1' or '0' (filter).

In the table above, you can see that Node 1 failed to match. The filter applied was looking for '101' (5 in decimal) but the lower 3 bits identifier (that's what the mask was looking for) was actually '110' (6 in decimal). You can see that the actual result was '110' after the mask was applied to the identifier. The second node matched as the filter is actually looking for '110'.

Now, we have to use the full registers when we apply this to the MCP2515. This means filling out 29bits of data. When in doubt, fill everything else with zeroes. Each register in the MCP2515 is 8bytes, this therefore means that you need 4 bytes per filter and 4 bytes per mask. The 6 filters and 2 masks that were mentioned above are located in the following areas:

Right, now that you know you need 4 bytes for a filter and then 4 bytes for a mask... and you know where to store them... you'll probably now need to know how to construct a mask and filter. We'll start with a mask that looks for the value 11 (decimal!) [0x0b in hex, 1011 in binary] in the standard 11-bit identifier. As you can guess, I've just provided the filter by representing the value in binary; we simply need to zero-out the bits to the left to ensure we provide the correct number. Have I provided the mask? No! Look at the truth table below if we were to use 1011 as the mask.

They all matched!?!?!? Since we were only checking the 'exact' value via the mask, we weren't actually looking to see if any of the bits around the value were set. The basic principal is that we need to know the maximum length of the value we could be looking for and then use that as the mask. For example, if you have up to '11111' (32 including '0') ids on your network, then you want to make sure that your mask is '11111' and that your filter is the exact number of the node checking if the message is theirs.

That's better! Make sure your values are correct! So, in the example below we'll use '11111' as the max value and therefore the mask. We'll then use 01011 as the value of the node we're pretending to be and we'll insert these into the correct registers (being Mask 0 and Filter 0.)

Message Acceptance Process

So, two buffers with differing filters... what happens when a message arrives? The basic idea is that a message will hit the first buffer and, if not accepted, attempt to hit the second buffer. The message is then discarded if the second buffer is also configured to not accept this message.

Note: There are also two bits (RXM0 and RXM1) in the RXBnCTRL (where n is either 0 or 1 depending on the buffer) that determine how messages are accepted. Note: My code currently has the ability to set these registers; for the life of me I cannot actually get the chip to function as per the datasheet when these registers are set. If anyone else has succeeded in using the RXM bits successfully then please leave a comment and tell how you did it!

So, as long as the RXM bits are both set to '0', the message buffers will then process through the following procedure to accept or deny messages.

  for EACH BUFFER b: (initially 0)
    if (MASK 'b' is ZERO) { //mask 0 for buffer 0 and mask 1 for buffer 1
      Accept new message on Buffer b
    } else {
      using FILTERs 0,1 (if b equals 0) OR FILTERs 2,3,4,5 (if b equals 1)
        if (both the message and filter are 'extended') or (both the message and filter are 'standard') then
          for each '1' in MASK as 'x', does FILTER[x] equal message[x]?
            if all match then accept message
            else check next filter as this filters bits do not match the relevant message bits.
        else check next filter as this filter type does not match this message type.
      if still not accepted then TRY BUFFER 1
    }

A mask is disabled when all its bits are '0'. As soon as a bit is '1' then that mask applies to the relevant buffer. As per the section above, the bits in the filter are then checked against the relevant message bits based on what bits the mask specifies the process to check.

On the contrary, a filter is not 'disabled' when all bits are '0'; instead you have configured two filters, on the buffer related to the mask, which will only permit standard messages where the identifier is zero. If you set the mask on a buffer to anything other than 0 and then don't touch the filters, this will prevent extended messages from coming through (as both filters have '0' as the EXIDE bit) and also prevent any standard messages that do not have an identifier of zero.

In the event that you don't want to receive a specific message type, you must put a mask on both receiving buffers and then an appropriate filter to block out the specific identifier bits. On the contrary, make sure that your masks and filters are smart enough to capture all other data required for your CAN node.

If in doubt, write an 'all-seeing' debugging application to view all traffic on your bus... it'll allow you to diagnose why messages are landing where you might not want them to. As per above, setting both RXM bits to 1 will bypass your filters; this way you don't have to muck around with your own configuration too much. Just make sure you have more than two other nodes on the bus if you want another in Listen mode. Having one node on the bus, or two with one in listen mode, will mean that any message transmitted will stay perpetually on the wire. A message must be consumed by another node for it to disappear.

Storing Masks and Filters on the MCP2515

Scroll up to see the register addresses for the masks and filters. The contents of each of these registers looks as follows:

• *: 'n' is the filter number, i.e. RXF0SIDH is the 'Standard ID High Receive Register Filter 0'.
  [F|M] means that the name is 'RXF1SIDH' for Filter 1 and 'RXM1SIDH' for Mask 1.
• **: 'EXIDE': set this to '1' and this filter will only apply to Extended IDs, '0' means it will only apply to standard IDs.
  This byte is unimplemented for Masks. Just leave it as zero.
• ^: These two bits are not used if you are in standard mode as you only need 16 bits to check the first two bytes of data.

Have I lost you yet? Each filter and mask needs to be able to store both the Standard ID bits and the Extended ID bits. As mentioned before, if you're in standard mode then the 'lower' two bytes (i.e. bits 16 to 0 [17,18 are ignored!]) of the extended area are for matching against the first two bytes of data. You can disable this by ensuring that the associated mask has zeroes in the extended area. On the contrary, if you wanted to check the first byte in the data for a specific value then you would pass in '001111111100000000' as the extended area of the mask with the relevant extended bits set in filter.

Somewhere up above I mentioned we'd use '11111' for the mask and '01011' for the node id. We'll now store this in the registers. We'll use Mask 0 and Filter 0 for this and we'll make sure the rest are all zeroes so they don't apply. You'll note that the first register (RXM0SIDH) starts with zeros; as per above this means that the identifier could actually contain any data in this area and, since the mask is '0' for these bits, the acceptance process wont care at all! The registers will need to be set as follows:

So, as you can see above, we've put the mask 0b00000011111 in the 'standard id area' of Mask 0 and 0b00000001011 in the 'standard id area' of filter 0. Based on our logic above this will then only allow messages through that match the above requirements. Below is the code to actually do this on the Arduino.

#define MASK_0 0x20
#define FILTER_0 0x00
void CANClass::setMaskOrFilter(byte mask, byte b0, byte b1, byte b2, byte b3) {
	setMode(CONFIGURATION);
	setRegister(mask, b0);
	setRegister(mask+1, b1);
	setRegister(mask+2, b2);
	setRegister(mask+3, b3);
	setMode(NORMAL);
}

//set MASK 0 for RXB0 a mask checks all bits of the standard id.
CAN.setMaskOrFilter(MASK_0,   0b11111111, 0b11100000, 0b00000000, 0b00000000);
//set Filter 0 to 0x555. Therefore only messages with frame id: 0x555 are allowed through this buffer.
CAN.setMaskOrFilter(FILTER_0, 0b10101010, 0b10100000, 0b00000000, 0b00000000);

Note that only setting this for buffer 0 will mean that any message that doesn't match will come through on buffer 1. You'll need to also set a mask on buffer 1 to stop the messages completely. Of course, you can also only ever check buffer 0 for messages and not care if buffer 1 has anything waiting.

Filters in action: Guessing game.

Ok, who would've thought you could make microcontrollers play a game together. You know the old trick, someone else chooses a 'random' number and you get to 'randomly' guess it. Why don't we make our Arduino's play the same game?

We'll set the filter on buffer 0 to the number the receiver is thinking of. This means that the sender will only actually get a message through to the receiver if they guess the correct identifier. Both controllers will then swap roles. Just to make life easier we'll limit the range of numbers allowed, but we'll still make the guessing as 'random' as possible.

I could paste the full code here, but instead I'll just post the general idea.

Source code (including my version of the CAN Library)

The final piece of the puzzle is always the source code. I've included the guessing game example as well. Note that my code is based off the canduino and I intend to send changes upstream where possible to make life easier for everyone.

Download the library and example here.

I'd seen a few printers on eBay, most being USB. Serial was always to be my preferred method and I had the components on hand. I then saw the Thermal Printer at Sparkfun and decided that it'd be my first guinea pig.

Sparkfun Thermal Printer

The Sparkfun themal printer is, like most of their products, targetted at the Arduino. Thanks to this there is a wealth of information on their page on how to connect and use it. After hooking up a proper power supply (they recommend 9v @ 2Amps, so use a 7809 with a heatsink!) the printer just started spewing out whatever I threw at it.

The easiest way to use this is via the library found here: Displaying on Paper – Thermal Printer + Arduino. bildr.org is actually a really cool site full of interesting projects for the Arduino, check it out when you can!

There's a forum for discussing the above library, in which I've already posted my praises to the developer. If you need a hand then go over and ask away... they're always open to feedback and improvements to the library too!

Note that this printer uses small rolls of 58mm paper. I found a 10-pack of these at OfficeWorks (Australia) for AUD$9.95.

IBM 4610-TF6 (on Windows)

I'd finally found a dirt cheap printer on eBay that was RS-232. It was a chunky/retro IBM thermal printer and really was just a larger, more robust version of the Sparkfun thermal printer above. It didn't come with a power supply and, after purchasing, I realised that it wanted 38v! What the hell? It seems that the 'thermal' side of it uses a lot of current to burn the paper! It also wanted 3 AMPS at 38v... where the hell would I find that?

I installed the printer drivers here on a Windows XP 32-Bit machine (DOES NOT WORK WITH 64-Bit!) and provided it 12v @ 2A. The LED came on, but the printer showed up as 'offline'. All attempted connections via Hyper-Terminal showed the port as 'already open'; the printer driver would've been the cause. I uninstalled it and rebooted, but Hyper-Terminal wasn't receiving any responses after connecting successfully.

I then found a second 12v power supply and chained them together... Prior to this I'd re-installed the printer drivers and, upon the boost to 24v, the printer flicked to 'online' and the LED glowed slightly brighter. I could now also use the line-feed button on the top of the printer! I opened notepad, loaded a text file from the Arduino directory and, without thinking, hit print. The printer control panel window showed the job spooling up to 20 pages and then the printer started .... and kept going ... for an hour. It printed at a rate of about 1 line per 5 seconds.

I had no idea how to cancel it... so I had to let it go.

IBM 4610-TF6 (on the Arduino)

It was now time to make this printer talk to my Arduino Mega. I hooked it all up based on how the Sparkfun printer wiring and attempted to use the same code; nothing happened. I then used the code from Tom Taylor's Microprinter blog post. Once uploaded, I had junk coming out of the printer... It occurred to me that I probably needed a MAX232 in the middle to raise the voltages to proper RS232 levels (as per everyone elses examples!)

I hooked up the MAX232 as per the schematic below and then had a functional printer from my Arduino! Determining the actual commands to send it came next.

Fonts, spacing, etc...

Right, this gets tricky... you can either put 58mm or 80mm paper in this printer. 80mm is recommended as it has better chances of staying aligned with the paper cutter (coming out diagonally is actually an issue.) I had started with the 58mm but quickly went and bought 80mm paper (AUD$12 for 4 80x80 rolls) as I also wanted the extra printing space.

You can work out how many characters per line based on the font chosen, character spacing. It is pretty much expected that you're using 80mm paper. Font A is 10x20, Font B is 12x24 and Font C is 8x16. The Cash Receipt print line is 72 mm (2.83 inches) long. There are 576 dots per line and 203 dots per inch.

The Application Guide provides the following calculations:

• 20 CPI ⇒ 8-dot wide character + 2-dot space (Font C) ⇒ 57 characters/line
• 17 CPI ⇒ 10-dot wide character + 2-dot space (Font A) ⇒ 48 characters/line
• 15 CPI ⇒ 10-dot wide character + 3-dot space (Font A) ⇒ 44 characters/line
• 12 CPI ⇒ 12-dot wide character + 5-dot space (Font B) ⇒ 33 characters/line

IBM SureMark Thermal Printer Library for Arduino 1.0

IBM provides a great reference document for this collection of printers: Application interface specification for IBM 4610 printers. I found it to be a little hit-and-miss as to what commands are available on the TF6, but most worked well. Either way, I built the following library which provides the following functionality:

• Text Styles: Bold, Underline, Overline, Inverted, Arbitrary Font Scaling, Double Height/Width, Rotated, Upside-down
• Barcode Printing: UPC-A, UPC-E, JAN13 (EAN), JAN8 (EAN), CODE 39, ITF, CODABAR, CODE 128 (c), CODE 93, CODE 128 (a, b)
• Image Printing from data stream, image storing to printer RAM and image printing from printer RAM
• Message storing to printer RAM and printing from printer RAM
• Beeper sounds. (Example below has 'Mary had a little lamb')
• Paper cutting, line spacing, line feeding, etc...

Download the library and example here.

Other references

It turns out that, if I'd google'd more, I would've found a lot more help around the traps... here's a few locations to check out:

• Tutorial for RS232 + Thermal Printer with Arduino
• Tom Taylor's Microprinter
• [SOLVED] Connecting POS-Printer and Duemilanove
• Arduino and the thermal printers

Due to all this, and the desire to use Peco Setrack, I'd decided that instead of Peco Turnout Motors (which also require large amounts of voltage) I'd use the smallest RC servos I could find. Off to eBay I went and the following arrived not so long ago.

I had no idea what servos to purchase: they seem to be rated in grams as to how much they can lift? I read in a few random locations across the web that 9g would be more than enough for switching points.

Hooking up Servos to your Arduino

This could not be easier. Arduino 1.0 already comes with the Servo Library in-built. Simply include this header and then implement the following code. The basic idea is to initialise the Servo on a specific pin (they only require one pin to be controlled) and then hook up the external power source. As per usual, it's not recommended to power too many off the USB 5v.

Mounting Servos to control Turnouts

Got some piano wire? A paperclip? Resistor legs? Any solid piece of wire/metal/rod will work to connect your turnout to a Servo. As you can see below, I've used a .55mm 'hobby wire' to connect everything up as I don't need flexibility and I want it to be robust.

You could also be very tricky and build a full interlocking frame to control multiple points at once. I bought a few 'hinges' (no idea what the real word should be) to allow the rodding to turn corners but thought it easier in the end to just install another Servo .

Rotary Encoders allow you to switch the Turnout yourself...

Rotary Encoders are 'endless' switches which usually come with 5 pins + GND. You can continually turn them, allowing for applications where you want an inifinitely adjustable value. The pins are as follows: one side has two pints which are for the 'pushbutton', as the actual stem can be pushed into the base and provides a momentary switch. The other three on the other side are for the rotor location. The inside pin is 'common' and needs to go to ground; the outside pins are 'data' and need to be hooked into digital inputs somewhere on your Arduino.

You then simply download the rotary encoder library from PJRC, drop the main Encoder.cpp and 'utils' folder into your sketch folder and include the following source lines.

#define ENCODER_DO_NOT_USE_INTERRUPTS

#include "Encoder.h"
#include <Servo.h>

Encoder myEnc(7, 8);

Servo myservo;
long position = -999;
long srv = 0;
void setup() {
  myservo.attach(5);
}

void loop() {
  long newPos = myEnc.read();
  if (newPos != position) {
    if (newPos < position) {
      srv += 1;
      if (srv > 180) srv = 180;
    } else {
      srv -= 1;
      if (srv < 0) srv = 0;
    }
    position = newPos;
    myservo.write(srv);
  }
}

The code above will check if the rotary encoder has moved and, if it has, then check which direction and adjust the servo accordingly. Note that the servos will hum/jam if you try to turn them past any restrictions: i.e. once hooked to a turnout, the servo's movement will be limited and you should only move them as much as required... don't try and move them past the limits of the turnout. I'm quite sure that you will ruin either the servo or the turnout if you let it hum for too long past the movement of the switch.

What to do next?

Control your points based on timing? Or even based on track occupancy detection. Computerised turnout control will allow you to automate any movement over your layout. Of course, my current goal is to build a node for the OpenLCB project to control points via servos. This will need to store data, allow max/min settings per point, etc... but more as it gets built!

Actually, I lie... it hasn't taken a year to 'realise'... it's taken a year to actually need the ability to store information. It occurred to me, whilst looking at Don's OpenLCB railstars products, that they'd need to store everything they 'learn' as you set them up with controller nodes. All of my previous projects would've forgotten all settings once you disconnect the power!

Memory Types on the Arduino

After a little research, it turns out that Arduinos have three types of memory areas. These would be the flash, EEPROM and SRAM. The former is the location that all 'sketches' and other compiled program code go, therefore being the largest area. The EEPROM is, depending on your chip, an area around 1k to 4k in size for storing data to be persisted. Finally the SRAM is the 'running' area where data is stored during runtime of your code.

So, as you can see, the more you pay for the microprocessor, the more space you get to play with. I have used the Arduino Mega 1280 for a while and had never used the space available in the EEPROM... what a waste. Now I'm tinkering with the Atmega328P and, as it shows, there's a lot less space available to play with. Fortunately, depending on how frugal you are with data storage, there's more than enough for creating our OpenLCB nodes.

Working with the EEPROM

Arduino 1.0 (and all previous versions) include the EEPROM Library. This library includes two calls, being read() and write(). For the Atmega328P, I'm able to store a byte in 1024 areas. This expands to 4096 areas for the Mega.

By the way, for time-critical apps, an EEPROM write takes 3.3 ms to complete.

NOTE: As the Arduino page warns, EEPROMs are only good for 100000 writes! Please only write/update your EEPROM areas sparingly and when absolutely required.

Efficient storage of Bits/Bytes

Depending on your requirements, you may want to be more efficient in the way you store certain values. We'll start with booleans: if you're lazy and wont need to store over 1024 booleans on an Atmega328p then you can simply check the boolean and store a '1' or '0' in any of the 1024 areas. Of course, if you need more, then you'd want to efficiently use the 8 bits per byte that you have available. As each of those 8 bits can be a '1' or a '0', you can then actually store 8 booleans in each byte. It's simply a matter of 'or'ing 8 booleans together and left-shifting to ensure you set the correct bit.

byte setBit(store, bit) { //bit 1 is right-most
      store |= (1 << (bit - 1)); //set bit 5 to '1'.
}

byte clearBit(store, bit) {
      store &= !(1 << (bit - 1));
}

bool getBit(store, bit) {
      byte b = (1 << (bit - 1));
      return (store & b);
}

Arduino has a good bit of information on BitMasks and BitMath for those interested.

Using PROGMEM to store 'known' data

So, as previously mentioned, the Flash area has the most space available. The Arduino comes with the PROGMEM library for storing variables in this area. Note that you cannot easily write to this at run-time (I haven't dug far enough to work out if you really can) ... the goal is to just store large data in the flash and use it from there at runtime rather than copying to your limited SRAM first.

Firstly, you need to select from a datatype below:

Now, declare it in the PROGMEM 'space'. It seems that the Arduino devs recommended it to be stored as an array as you'd usually only use this space for large amount of data.
I've chosen the prog_uint16_t (note that this var size is a 'word'), the code below stores two of these values and then uses them during execution.

#include 
PROGMEM prog_uint16_t myValues[] = { 123, 456 };

int k; //counter? don't quite know what for.
int readValue1, readValue2;
void setup() {
      k = 0; //read the first word.
      readValue1 = pgm_read_word_near(charSet + k);
      k = 1;
      readValue2 = pgm_read_word_near(charSet + k);
}

void loop() {
      //now you should probably do something with these values...
}

And that's it.. I hope this helps some of you to limit your SRAM requirements and also to store data for users each time your device is switched off!

References

Firstly, a list of random links for random information on building your own Arduino:

• Arduino has a page on this: Standalone Assembly. Note that the diagram is WRONG and this schematic is not recommended.
• TheTransistor has their Minimalist Arduino Article which is perfect. This uses USB.
• Praveendb’s Weblog has a post titled Interface the Atmega 16/32 with the PC which shows how to connect the Atmega via a MAX232 Serial (NOT USB)
• There's a post at NKC Electronics Tutorials detailing how to assemble a 'Freeduino' V2.0 [MAX232] and then the 'Freeduino' v1.0 [Basic Serial Interface].

Serial or USB?

I know the DB-9 Serial Port is archaic... needs an Interrupt Request (IRQ) assigned to it etc, etc... but there's something nostalgic about plugging in a chunky cable instead of a new USB-B connector. It's also cheaper and easier to use parts on hand and I had a few MAX232s sitting around.

To use USB you'll need an FTDI chip to convert the USB signal from your PC to the TTL protocol of which the Arduino understands. Note that there are also FTDI chips which convert USB to RS232, the serial protocol that allows devices (specifically your old dial-up modems) to communicate over serial cables. You don't want one of these as you'd then have to convert the RS232 again to TTL.

Which Microcontroller?

Good question! Your choice of microcontroller comes down to size and quantity of digital/analogue inputs and outputs. I decided on the Atmega328P as it has enough IO lines for what I need on each OpenLCB node; I'll produce more node types and have them specialise rather than one node that does everything from one board. They're cheap on eBay and they are very similar to the MCU used in the Arduino Duemilanove (5 analogue and ~13 digital IOs.)

Schematic

You'll find schematics all over the web, although none seem to agree on what components are the exact bare-minimum for an Arduino... it actually makes it quite difficult to know exactly what you need. Below is a solid basis to start your Arduino-based invention, containing everything required to program over the serial port.

Building the prototype

There was not much out of the ordinary on the breadboarding of this project. It's actually quite simple and the standard rules of check, check and double-check your wire placement, IC pin numbers, etc... as you go is imperative. The serial cable connection on this project, due to the cable being rigid, can cause issues of dragging the board around. I'd recommend to seat connection and cable first and secure everything to your workbench... You'll then prevent your breadboard from upending when the serial cable chooses to move around.

Programming from the IDE

The MCU chosen is the Atmega328P and, as mentioned, it's closest match is the "Arduino Duemilanove w/ Atmega328". Once everything was connected I attempted to flash using this board, selected in the Arduino GUI, but it didn't work straight away. The initial error was that the chip device ID didn't match. It turns out that the Atmega328 has as a different code to the Atmega328P (something to do with Pico Power.) I had to hack the 'avrdude.conf' file buried in the arduino folder and then it just worked.

Before I knew it I had the servo library in and a mini servo from eBay controlling a Peco point on my layout.

Re-programming an Atmega MCU

I accidentally learnt how to do this... At one point I'd put the MCU in the wrong way around and expected that I'd killed it. The circuit then failed to work after numerous attempts with the TX and/or RX lights constantly lit. It wouldn't accept sketches and I therefore thought the best bet was to re-flash the bootloader + program.

It turns out that my Arduino Mega can be used as an In-Serial Programmer and so I set this up. This can be selected via the "Arduino ISP" option in the "Programmer" menu under the new Arduino 1.0 software.

(Note that the capacitor from +5v to RESET is a 100n non-polarised.)

After the re-flash and a reconfigure of the MAX232 in/outs (the schematic above is the final version that now works perfectly) it all just worked again... for one of the MCUs anyway. The second simply refused to receive sketches; the RX light would not turn off. I took this as a fundamental failure in the chip (I blame my bread-boarding skills) and therefore tried something sneaky: I copied the entire code off the MCU that worked and flashed it to the 'broken' one with avrdude and it's associated avrdude-GUI [direct download link]. It turns out this worked... the chip now did what the previous one did... but in the MAX232 breadboard it still would not accept a new sketch from the Arduino GUI. I attempted to find other methods to 'completely erase/reset' an Atmega, but I couldn't get it to work and so just accepted it's fate of having to copy it's brother.

Don E. Goodman-Wilson, who you would've seen commenting on a few of my posts here regarding DCC and Arduino, has gone all-out and started production of some pretty amazing technology. He's started a company called railstars which is currently providing DCC boosters, central units and throttles. Not only are these perfectly marketed and designed, they also now incorporate a new concept known as OpenLCB.

OpenLCB

OpenLCB is an initiative by the OpenLCB team to define a network (protocol and required hardware) to control pretty much everything on your model railway. The end result is layout control and automation which is easy to install, configure and extend. As of the 9th of February 2012, there are motions for NMRA to work closely with the OpenLCB project in a venture named NMRAnet... stay tuned for more information on that!

It should be noted that the OpenLCB team is still in the early stages of design work and, although prototypes have been built and tested, there is a lot of work to do to get final products to market.

The basic concept consists of a control bus with nodes located along a network bus, terminated at each end. Each node has it's own processor that can create and respond to events. Events can be anything from controlling accessories and trains on your layout to sending informational messages to remote displays. With this, you can have a node controlling points around your layout, a node controlling trains indirectly via DCC and a final node acting as a control panel with buttons and switches configured to send specific events.

In case you were wondering, the OpenLCB venture has no intention to interact with DCC. Other parties, such as Don with his railstars products, are currently bringing DCC in as an option, but do not intend to outright replace it! Don's efforts with railstars OpenLCB components will allow DCC commands to be transmitted over the OpenLCB protocol allowing each node on the network to respond appropriately. A lot of opportunities will open up with this as you will then be able to use the OpenLCB network to transmit DCC information, allowing completely separate DCC blocks on your layout.

You can find a lot more information about OpenLCB here at their 'First Look' page.

I want to control my DC Layout?

There are currently no nodes designed for use as standard DC throttles; fortunately, controlling DC layouts via the OpenLCB bus should be completely feasible! As per my previous articles on Arduino control of model railways, a simple PWM motor controller is all that is required to supply a model railway with the appropriate power levels. Since OpenLCB is also very compatible with Arduino, it would also therefore be quite practical to transform an Arduino+Motor Controller into an OpenLCB 'node'. This would mean that any 'controller node' could then send 'events' to the 'pwm node' which would then act accordingly... be that 'supply 50% throttle'.

I'd spoken to Don on this concept and he indicated that the OpenLCB key concept was to control 'Trains' rather than 'Blocks'. This is the same as DCC... as you supply the same power+data to all rails on your layout and the locomotives respond only when called. The issue then with DC control is that trains, sitting in blocks, will respond as soon as you apply power. One answer would be to have detection circuits around the layout which would follow movement and assume where each train was. Another would be to have the 'pwm nodes' act simply as 'accessories' that supply power to each block. This concept is still under discussion.

What's Next...

I really do want to get into development and testing of the OpenLCB system. Fortunately the whole lot is open source and one can even use standard Arduinos as 'nodes' based on the code available in the OpenLCB repository. Once I have enough components I'll be building and connecting a few nodes to test the communications functionality. After that I'll go ahead and design a block-controller and pwm node. At the least this will allow me to prototype some ideas whilst controlling my latest n-scale-in-a-table layout.

The OpenLCB project will also shortly be offering a 'dev kit' to parties interested in developing for the OpenLCB project. It will have enough components to create a local network able to control a layout. You can find out more information on the Japanese Modelling & Japan Rail Enthusiasts Forum.

I intend on keeping everyone updated as I tackle the concept of DC in the newly formed OpenLCB realm.

The review? It runs like a dog due to it only having a single motorised end carriage (fortunately with all-wheel pickup) and the lighting shines brightly though the shell.

As you can see, the train I bought included an add-on carriage and all packaging. The price tag was on-par with what I'm seeing on eBay nowadays. The train was in a glass cabinet on display when I bought it and I didn't realise that the base package only contained one coach. I have since found and purchased another coach from eBay and will attempt to extend this set. You can also see in the comparison shot of the two passenger cars that they are slightly differing in colour. Unfortunately, this is just a side-effect from purchasing second-hand; I have no idea what their story is and if the main set was left in the sun too long...

Either way, it's a great looking train set.

Of course, there's always concerns that driving 400kms might be a complete waste of time and this TAA on occupations near Great Western should have probably received more of my attention. Just in case you're wondering... an 'occupation' is where the Australian Rail Track Corporation has requested complete manual control of a section of track. In this case it was the area between Pyrenees Loop – Great Western Loop and Great Western Loop – Deep Lead Loop... they were to do ballast cleaning!? ... this might actually be worth the trek for!

Planning

As per usual, I perused through ARTC's Train Alteration Advice and determined items which might have applied to the 5th of November; fortunately there was nothing apart from the above ballast cleaning. I therefore recorded the times on ARTC's timetables for the area into a diamond diagram and, from this, worked out where I should have been when. I, this time, wanted to check out places I hadn't been to yet and therefore started working out what train I could see where.

How to read the above? The vertical axis shows the time-of-day and the horizontal the location. Each location has an arrival and departure time... so if you see a flat horizontal line for any service then it means that train has not stopped. Therefore, the train with the flat line will be moving whilst the diagonal will be waiting in a loop when you see two lines intersecting.

From the above you can see where all the regularly scheduled trains cross. I had errands to run on Saturday morning and, based on google maps estimates, could only just get to Tatyoon Loop by 11:00am. This would just be enough to see 6AM3 pass The Overland. The goal was then to wait for the Mineral Sands from Portland and follow it through to Murtoa. I would then wait for the Horsham container train, arriving in time to see the Southern Spirit arrive. 4PM6 would then be following and I'd choose a point along the way back to see this again.

Tatyoon

No, not Tatooine... there's no pod racing here. This was meant to be a loop for a pass, but it didn't seem anywhere near long enough. There was a seemingly-abandoned grain silo with a definitely unused siding for it. The poor old station platform didn't even have a station sign on it anymore... I imagine the last passenger service here would've been steam-hauled?

I waited up until the time 6AM3 was meant to arrive but realised that I was lying to myself and it wasn't coming. The lighting at Tatyoon wasn't the best for The Overland, so I bolted to Maroona and waited for it there. At the western-end of the loop was a great view with the railway sweeping to the left... it would've been perfect in the morning sun for a Melbourne-bound freighter!

Maroona

Yes, Ma-roo-na. Not to be confused with: Mooroopna, Moorooduc, Maroondah, Maroota, Mooralla, etc...
This township is located due-south of Ararat (not do be confused with Ballarat) and ... there isn't much to it. Fortunately, there's a junction here to Portland which means the railway infrastructure was slightly interesting. The roads in the yard had been used recently and it seems that the trains to Portland must arrive into the yard and then depart, crossing the main.

The Overland, running 25 minutes late, arrived from the East and proceeded at a slower-than-usual pace through the station. This was the first and last time I was to see it.

I then waited for the Mineral Sands train... but realised it was never going to turn up. I therefore decided the better option was to bypass Ararat and head to Murtoa.

Murtoa

I'd never been here either... It's a large detour from the highway and it's the reason why I previously beat The Overland to Horsham as, although it can do 115km/h, the path via Murtoa adds quite a few more kilometres. Of course, it also meant I wouldn't see The Overland at Murtoa as I was never going to catch up to it on the country roads. Murtoa is the junction for the branch North to Hopetoun... the rails were quite shiny, so something must've run that way recently, but the Mineral Sands train wasn't to run this day.

I decided that I'd wait here for the Horsham freight. There was no reason it wasn't running, but as The Overland was 25mins late, this train would probably also be late.

After dealing with wildlife (brown snakes, etc..) the train came through fast.

I then jumped in the car to Horsham... expecting to see the tail of this train, but it had a headstart on me and there was no chance.

Horsham

Last time we saw C501 and T386 doing the Horsham freight, this time it was 8030 and GML10. Other than that, not much as changed... same colourful characters on the platform watching the trains go by. Actually, there is now a rail tractor LOK001 doing the shunting/splitting of the container train instead of the actual locos that brought it in.

NR85 brought the Southern Spirit in around 20mins late. The consist was as long as usual.

And then 4PM6 came through on time based on its amended running.

And that was it... the day had turned dim and the freighter was running with the light for the rest of the trip... I chose to return home.

Ararat

So, the initial TAA I mentioned had something about ballast cleaning in it? I forgot to tell you that I actually saw the track gang in the first loop directly after Ararat. It had to be a loop (was a fair distance from the highway) as The Overland had already bolted through. I was hoping they'd be in a location closer to a road on the way back, but they'd already packed up and were in Ararat yard.

The next day...

The Southern Spirit spend the night in Maroona. It proceeded east via Melbourne but was to only stop at Broadmeadows briefly. Fortunately it was to pass the large standard gauge viaducts as per usual and I decided to catch it at the one closest to Jacana. The up V/Line SG Albury service was running around 30 minutes late, but the Southern Spirit then got the green and bolted past.

And that was it... this train returns via Melbourne on the 14th of November. It will actually pass via Southern Cross Station, after a pause up in Somerton. We'll see what happens...

West Footscray

Melbourne struggles when it comes to good trainspotting locations making use of the morning sun. The main issue is that most of the good locations (viaducts, etc...) are good in the morning for out-bound traffic and the afternoon for in-bound traffic. As the train was in-bound in the AM it was time to think of a new strategy. I'd previously checked out Middle Footscray, but the options were limited and so I instead headed up to West Footscray.

It turns out 3 other onlookers had thought up the same concept and we all sat and waited. Fortunately we didn't have to wait long as the usual suspects soon came through... The XPT, The Overland, NRs on containers, Gs on containers... etc... etc...

And then ... the one we'd all been waiting for...

Pretty ugly eh? a 44-Class arse-end-leading isn't the prettiest site at 9am in the morning. Either way, it was worth the wait as the damn thing hauled ass through Footscray. That was it for the mornings movements; the train wasn't due out again until 1830.

Departures

ARTC posted that the departure time was 1830 and the train was right on time... fortunately there was more than enough entertainment at Sims St right up until the train left.

...and that was a wrap... Supposedly the Southern Spirit is back in town again this weekend... might go out West and see what is happening.

Complete album here.

Infrastructure

Yass Junction Signal Box seems to have had a repainting. I imagine ARHS ACT are to be commended as they probably still have the lease on it. Meanwhile the mudholes around the place are still just as bad as ever.

...and then something different

It's always nice when the signals switch red... It means someone is in control and something different is happening. Seeing the points then shift is better, as it usually means something is about to wrong-road into the loop and allow a pass. This time around it was BL30 (I hadn't seen a BL in Yass before) leading 3x 48s on what must have been a pretty heavy load of grain.

The end of the loop is a fair way north of the station. The better viewpoint is a road bridge up along Cooks Hill Road. I could've just stayed and seen what was passing from the platforms... but I hadn't been up that way in a while.

It turns out that light-engine consists can fly! FL220 lead 48s35, LVR's 4702 and 48s33 on the up, flying past me near the road bridge. The poor old BL and 48s then struggled up the incline and continued north.

And that was a wrap... the day had actually warmed up and there was family to visit.

Time in Spain was to be shared between Valencia, Barcelona and Madrid. Valencia was visited briefly; the goal there was to head out of town to 'La Tomatina'... I can only recommend that NOBODY bother doing this... ever. Barcelona then received the most time and Madrid got one night.

We landed in Barcelona from Athens and headed straight for Barcelona Sants. We had a connecting train from there to Valencia in 'Preferente Class'. This happened to be first class and was purchased very cheaply!

Before we knew it we were speeding south to Valencia.

Valencia

The rail system around Valencia was quite nice, it seems they had recently extended the high-speed there and built a new station (or were in the progress of converting an old one.) The old Valencia Nord station was also very impressive.

As the main goal was a daytrip to La Tomatina in Bunol, there wasn't much time to check out the freight yards in the south.

Barcelona

I'd seen a lot of freight action near Tarragona from the train to Valencia and wanted to check it out. A day was spent on the rail around Barcelona and, due to a late start, I decided that Tarragona was a little too far. Instead I made it half way south through to Sitges and Cunit.

There wasn't a freight train to be seen and hardly any high-speed stock, mainly just standard EMUs floating around. I therefore decided to go to Martorell in the north of Barcelona where, via google maps, I'd seen that freight, passenger and high-speed converged.

Fortunately I chose to stop through Garraf on the way through. This town is on the coast just above Sitges and has a beautiful old station building. There is a tunnel to the south and it all provides a great backdrop for shots.

Especially when a high-speed consist comes through...

At Martorell I was instantly greeted by a freighter heading west.

I then wandered from the station to the high-speed line around one kilometre north. I only had to wait 5 minutes to see a train bolt past.

I then returned to Martorell station and was greeted by a SEAT Car Carrier.

I'd also seen via google maps that there was a nice tunnel/castle/vineyard area one stop east of Martorell. The station was known as Castellbisbal and was easy to get to. I caught the next service east and wandered up to the road overpass of the high-speed.

I then wandered back to the station.

When I last expected it a freight came through heading west.

And that was it for the daytrip...

Madrid

The final trip was 'Touriste Class' to Madrid. This was on the ICE-3'looking rolling stock from Barcelona Sants to Madrid Atocha. The service was non-existent compared to First Class, but the train was great. Unfortunately the track condition along the way lead to a few rollercoaster-like experiences. At one point we even had to hold on to our drinks! I couldn't believe they were running the train at 300km/h over the rough patches.

The final stop was Madrid Atocha. This was a newly rebuilt station, full of concrete. At least it was quite clean.

We stayed near a station called 'Principe Pio'. It seems to have two sides, one which they have rebuilt with the other falling into disrepair.

And that was it... the next day saw a flight to Hong Kong. They've since stopped freight to Hung Hom and so there was no real advantage to chasing trains. I vowed to do more upon returning to Oz.

Larissis Station (aka 'Athens Central', 'Larissa Station')

This is where everything starts to get very confusing; there is no direct Wikipedia reference to this station and, depending on which site you're browsing through, everyone has a different name for it. I've come across two reasons for this: firstly most people translate the Greek language into English differently and secondly it seems that the area used to have two stations for two different destinations. Peloponnisou, the second station, was closed in 2005, but I can't determine when the new Larissis station development started. Either way, as you can see below, it hasn't finished.

As I arrived a DMU was departing the original Larissis Station. The station was quite busy as the train was approaching.

The yard was looking pretty dismal... the track had been skewed to allow more point installations and there was a lot of material lying around in stockpiles.

I then did a lap of the area to see what had become of the new development. A track machine and a rail train were stabled in the empty platforms. I don't know how long 55-213 had been parked there, but there was absolutely no evidence of work being carried out at the time.

At the other end of the station you could see the tunnelling that was partially in use. It was also made obvious that there was a lot more work to do on the station.

Finally, the underpass to the shopping area and Metro station had some nice artwork of days gone by.

That was it for Athens... the rest of the time in Greece was spent driving a Nissan Micra in Santorini on the wrong side of the road.
The next stop was to be spain; it was finally time to use the Renfe tickets I'd previously purchased.

The city of Istanbul of two sides, separated by the Bosphorus River. It turns out that the western half is known as the 'European Side', as it's phyiscally a part of the continent of Europe, and the eastern half is therefore the 'Asian Side'. Locals don't actually use the terms as above; they simply say 'opposite side' depending on the context of the conversation.

Sirkeci, the European side

Right next to the Blue Mosque is the Sirkeci Railway Station, the end of the line for the railway coming from Europe. It used to be the initial station/final destination for the Orient Express when it was still in operation. Turkey does not yet have a rail tunnel from the European to the Asian side and so travellers must transfer to a different mode of transport here to continue their journey east.

Turkey operates a varied amount of electric rolling stock, most of which can be seen at this station. At ~8:00am each morning the international train will also arrive bringing in tourists from far afield. In the end, I failed to take a shot of the actual station itself... I seemed to have been too keen on the trains this trip rather than the infrastructure.

Speaking of infrastructure... freight trains do actually have a method of getting across the Bosphorus. Turkish Railways still operate a train ferry from Sirkeci to Haydarpaşa Station. The boats seem to be able to carry around 6 wagons; unfortunately I never got to see one in transit. Note that the last shot below is from the platforms of Sirkeci station. You can see the pipe train in the background which had been taken off the ferry in the few hours that I'd been on the other side of the river.

Haydarpaşa, the Asian side

It was nice to finally see some infrastructure and rolling stock after a pretty quiet western side. Haydarpaşa Station is the final station on the eastern side and all services heading into Turkey and further initiate there. There are a lot of loco-hauled passenger services and that means there is a lot of consist rearranging in the yard. There is also quite a bit of freight action visible as the ferry terminates just north of the station.

And then you have the other end of the train ferry... The final shot below was taken as our ferry was back to Sirkeci; there is now a different load on the boat.

Halkali, back on the European side

I had google maps'd this location and saw a freight yard. It was the last freight yard before the line narrowed into Sirkeci station and seemed to have a lot of rolling stock. I jumped on an EMU from Sirkeci which took 40mins to get around to the yard. Once there, there was not a sound to be heard... no one was working in the area and then the call-to-prayer came over the PA system. This was the final stop for the service I was on, so I held on to my train 'token' (they used coins as tickets in Turkey) and waited to return on the same consist.

Fortunately, while I was there a rail tractor shunted a ballast rake. There was also a rail consist stabled without locomotives.

And that was it for Turkey... the next stop was Greece.

Split

I'd seen from Google Maps that Split had a main railway station on the water and the line seemed to be the southern-most point of the entire Croatian system. There was quite a bit of freight infrastructure around the base of the harbour, but it was hard to tell from Google if it was still in use.

We landed by plane from Berlin and caught the bus into town. The single line could be seen paralleling the highway, but there was zero traffic. Closer in to town there was a selection of freight stock around an industrial plant, but the larger freight yards further into the city weren't visible from the road.

Split wasn't high on my railway-viewing list; the main reason was to check out the beaches and the town. Therefore the shots taken below were all done within a 20minute segment at Split Station at around 7am on a Wednesday.

First up was 2062 110 shunting the autorail into the station platform.

Next 2062 038 departed with a passenger service, presumably North.

2062 110 then ran back around to it's consist.

DMU 7122 001 arrived with a whole bunch of backpackers... this service gets close to the airport... they may well have been smart enough to only take a taxi a short distance and a train the rest of the way.

2062 110 then shot off north.

Dubrovnik

Dubrovnik used to have a connected railway line... but... politics prevailed and it was cut off in 1975. It was narrow gauge too! They also used to have a tram in the city, but this was cancelled around the same time.

The beaches though... the beaches are fantastic! Take an island tour... amazing. Unfortunately, the 'old town' is a bit of a disappointment. The shops are all nastily commercial and you have to pay to even get on the city wall.

Zagreb

This place was great... I hadn't expected much from Zagreb; all the reviews were that it was a drab city from the dark ages, but this turned out to be its charm. The city has a railway line through the south and also a large tram network.

There's a funicular tram and also a cable car up in the north which wasn't running the day we were in town.

The main station is known as Zagrebački Glavni kolodvor (Zagreb Main Station). All local and regional railway services start from this location meaning it is quite busy at all times of the day. International services also arrive/depart here and there were often a lot of annoyed backpackers hanging around for late trains.

I then headed west via Tram to the next station along the line. I can't remember the exact name, but it's definitely not in use anymore. The most action seen was the red diesel shunter heading further west.

The rest of the afternoon was spent wandering around the abandonded? freight yards to the east of Zagreb Station. There are some interesting 'garden' communities here where it seems everyone gets a plot of land and a shed to grow small crops. The line to the west is also quite busy!

I also took a trip out to Dugo Selo (further east) to see what would pass through. It was a pretty desolate station, but there were people waiting for the train. A loco-hauled service paused briefly in the yard, but it seemed to just collect papers from the station master. Passengers did try to get on it though, obviously faster than the EMU.

The final afternoon was spent at the main station... there's always something going on.

They also even pay respects to bygone eras via a plynth out the front.

The entire album from Croatia is available here.

Bochum

Being located in the North-Rhine area, Bochum is right in the mix of the Ruhr area known for it's large industrial complexes. From the train, this was immediately obvious; we passed freight train after freight train heading in and we also saw a lot of freight yard infrastructure. I was more than impressed with what I saw and was even happier to find a large freight yard in the middle of Bochum.

Checking in to the Ibis Bochum City was painless and the view was straight onto the train tracks... Unfortunately, due to 'non-smoking rooms' the window was sealed to prevent air-con wastage. I therefore headed straight out for a lap of the station to see what was going down. It turns out there is a good view of the platforms in the afternoon light from the south-west of the station... there also happens to be a carpark with minimal fencing that you can take some good shots from.

Proceeding onto the station platforms produced some better results. Due to the multitude of private operators involved, it seems that tickets are all checked on-board trains rather than having gated platforms. This meant that there was easy access to all platforms.

It turns out that the DB loves the loco-hauled end-cab-control system as well. The whole concept is that the motive power is all in the locomotive at one end, but the train can be controlled from the far-end passenger car as well. This would never happen in Australia as we have very strict operating rules; I also wouldn't want to be in an accident where you have an extremely heavy (not to mention powerful) locomotive pushing tin-foil cars in to eachother. Then again, having the loco hit something first means the passenger cars have free will to fly around... I suppose the point is not to be in an accident at all!?

From the station I continued on-foot around the yard to the north-east. There is a branch from this yard further north-east, but it looked pretty abandoned. Google maps shows that there are cars and relatively new-looking infrastructure... I didn't follow the line to confirm this.

Instead I continued around to a road-bridge over the east-end of the yard. Here came fun! After a few passengers services at the south end of the bridge..

I then heard a diesel pulling in to the yard. Here I saw a V90? diesel shunter pulling a small consist into a loop. It then proceeded to run around, getting ready to pull the consist back in the direction it came. In the meantime though, 3 other trains came through; two continued on, but the third dropped more load for the shunter to pick up and continue on with.

I'd spent a good few hours on the bridge and decided to return to the hotel... Fortunately there's good visibility of the rail all the way back.

The rest of the time in Bochum was spent checking out the city. It's quite old and, I suppose cold? It's hard to explain, but it was the underlying theme to the rest Germany as I was to find out. There wasn't much graffiti around and the buildings were quite clean, but the architecture was all very similar and there was a lot of concrete. Fortunately the people were very friendly and accepted our very limited knowledge of the German language. There also happened to be a festival on in the middle of town which went on well in to the night.

A 24-hour trip to Berlin [aka 'The Comedy of Errors']

This was always going to be one of the highlights of the time spent in Germany. The goal was simple; start from Bochum, get as far down the Rhine as possible and then intercept the overnight train and travel to Berlin. What happened in the end was nothing short of disastrous but, in the end, was a great trip and a good story to tell. We boarded a train south from Bochum and started our journey. There was meant to be an initial stop in Cologne, but a late start saw us skip this and head straight for the Rhine.

Wuppertal

As the train was snaking through Wuppertal I noticed a large amount of infrastructure looking something like a monorail track. It wasn't until I saw the vehicle hanging from it that I wished I'd stopped. Unfortunately, Wuppertal hadn't been on my radar for a visit, but if I'd known that monorail existed, then I'd have definitely checked it out!

It turns out it's called the 'Wuppertal Schwebebahn' or 'Wuppertal Floating Tram'. It was built over a century ago and, although it's had a lot of 'modernisation' work, still carries 25 million passengers a year! Wuppertal was built through the valleys alongside the Wupper river of which actual monorail was built suspended above.

St Goarshausen

After switching to VIAS GmbH at Koblenz, we proceeded across the Rhine in the direction of Frankfurt. The goal was to stop at a river-side station somewhere down the line to eat and check out the scenery. This railway has an interesting mid-way 'terminal' style station at Wiesbaden. The trains then reverse and head on to Frankfurt where they then turn around and bounce back to Koblenz.

I still don't remember why I chose St Goarshausen as a location for lunch and freighters, but it did pay off in the end... unfortunately it was also the place of initiation for the proceeding comedy-of-errors. We got off the train in a hurry, which vaguely reminds me that the location was chosen quite randomly, and made it down to the Rhine. Here we ate lunch and saw the tour buses and boats proceeding up and down the roads and river. All was swell until I got up to walk back to the station. It was time to see what ran on the line and it wasn't until I went to pick up my two bags that I realised I only had one! At that point I remembered that I'd thrown my 'carry on' bag on the rack above us in the train and had not remembered to take it back down as we were getting off.

It occurred to me that there was not much I could do after a few deep breaths... We paid for lunch and headed back to the station. Unfortunately it was well-abandoned and all the numbers to call weren't working from my Dutch Lebara sim card. The next VIAS train wasn't for an hour... so... I took photos of freighters as I had the camera around my neck.

The next service came and we boarded, waiting for the conductor. After checking our Eurail pass, we asked her what we should do. It was Saturday and her answer was to call Lost&Found on Monday. She was also finishing shift at the next stop and a new conductor coming on might be able to help. Unfortunately he spoke less english, asking if we spoke french.

We ended up at the terminal in Wiesbaden where we were meant to switch to DB and head on through to Freiburg. Unfortunately, without my bag (containing train tickets for the overnight train), we weren't going anywhere fast. The goal at Wiesbaden was then to find a station office and determine what the best plan of attack was. 5 minutes before arriving we decided that we might also continue on VIAS to Frankfurt, as the train we were originally on should have been cleaned prior to turning around?

We chose to alight at Wiesbaden and headed to the ticket counter to find an office. We expected that they could call Frankfurt to check the train we'd been on... I'd taken a photo of the train and knew the actual loco number. As we approached the end of the platform I noticed another VIAS train (amongst all the DB stock) was hanging in platform one. It had already bounced back from Frankfurt and was about to head off for Koblenz! I passed my luggage to my friend and bolted for it... I still feel sorry for the passengers waiting to depart as I stormed through the carriage looking for the shelf that I'd left my bag on. Unfortunately, it wasn't there.

Meanwhile, my friend had intercepted the conductor who was just finishing his shift and wandering down the platform. The language barrier had prevented him from getting the message through, but I rocked up and just used sign language to describe my bag. He all of a sudden realised what we meant and took me back to the drivers compartment. It turns out he'd seen it on the shelf at Frankfurt and put it in with the driver, expecting to return it to Koblenz and store it there. I could not believe my luck when he returned my bag back to me with my laptop, camera lenses, phone charger, train tickets, travel documents, etc... etc... in it.

We then jumped on the next train south towards Freiburg; the goal was to have Dinner in Worms.

Stuttgart

Not Freiburg you say? Not Worms either? I still can't give you the correct answer as to how we got here. We printed the 'travel advice' from the DB machine showing the connections... we went to the right platform... we got on the train that we thought was to take us in the correct direction and we ended up in Stuttgart. Now that I look at the map I realise that we headed south-east instead of due south.

It was getting to late afternoon and this foul-up meant that we wouldn't make the night-train intercept at Freiburg! I went to the station office and told the attendant my dilemma. I suggested Karlsruhe as an alternate intercept point and she indicated this would be fine... I also then assumed the train conductor would be informed. We then caught the next train to Karlsruhe after a snack.

Karlsruhe

We got here in good time for the intercept... I decided to practise night-time photography and tinkered with my camera.

We had a full meal at the station and, before we knew it, the night train was approaching.

We boarded the train and attempted to enter our cabin... it was locked. I let out a yelp, but then tracked down the conductor. He looked at my ticket and grunted... disappearing somewhere in the wrong direction. Before long he returned and proceeded to give me an ear-full about being late and informed me of their policy on re-selling rooms if the original passenger no-shows more than 2 stations beyond there original joining point. It turns out that, now when I look at a map, we should've continued further south to Offenburg... although I can't remember if that would've been possible. I think the lady at Stuttgart would've recommended that if it had been the case?

Either way, he pulled out his keys stating that he thought our cabin was no longer available... whilst still walking us towards it. He unlocked the room and we all saw that it wasn't occupied. He then continued the rant that we should have gotten on earlier and that we were making his job difficult. I explained the story and he stated that the DB station staff had no ability to contact train conductors if/when there are issues. We thanked him for his help and he went on his 'merry' way.

After 3 fails, we finally had somewhere to sleep and were on the way to Berlin.

Berlin

So... 0700 hours... off the train to Berlin Hauptbahnhof. Amazing station! How the hell do we get to Rosa-Luxemborg-Platz? It's amazing how dependent you get on technology... specifically data connections on mobile phones and google maps. We navigated the maps and jumped on a train to Alexanderplatz. This turned out to be another great station. We then transferred to the U-Bahn and ended up at the correct station. It was now 0800 and we dropped our bags... it's Sunday... turns out nothing is open!? So...

This city needs to be re-visited... there's a lot more to check out!

This city surprised me... I was expecting somewhat of a metropolis, Amsterdam being the capital and all. Instead it's a beautiful canal city with fantastic architecture, despite some of the houses leaning towards canals or other buildings.

Nederlandse Spoorwegen [aka 'Dutch Railways'] (Official site) is the national railway operator and provided us with all the transport requirements we needed. Multiple trips were taken out to random locations and the trains were always fast and on time.

Amersfoort

Just south-west of Amsterdam, Amersfoort is an interchange station for anyone wanting to head north/north-west. We used this interchange on the way through to Groningen. A modern EMU was caught from Amsterdam Centraal but then the connecting train was a Koploper to Groningen! Checking out this model of EMU was high on my priority list!

The Koploper looks very similar to the JR West Thunderbird (683 Series) and the standard 183/485 EMUs as well, but I'm not too sure who copied who. I also bought a model of this in HO by Lima; I'll post on that at a later date.

Groningen

My grandparents are from this area and it had to be visited... getting here by Koploper was an added bonus. Groningen is known for its high student population and universities. We had lunch in the town square and checked out the shops; there was a better selection there than the capital of Australia

Veendam

The Museum Railway S·T·A·R runs from Staadskanaal to Veendam and this wasn't far away from Groningen. We took the DMU from Groningen to Veendam and intercepted the first run of the SL for the morning from Staadskanaal. Note that this service has only just been re-connected to Veendam. The train used to stop one station short until June this year (2011) when they re-extended the service.

The STAR Museum Train had to cross a canal when coming from the south (Stadskanaal); a manually-operated bridge is turned into place when required.

We then took the next DMU back to Groningen and then connected to a return service to Amsterdam.

Venlo

The final day was spent taking the train from Amsterdam Centraal to Bochum, Germany. This was extremely easy and fast. There were three connections in total, all with no issues or delays. Venlo was the last stop before switching to the German railways and was a hub for freight train drivers to change shifts. There happened to be a constant procession of freighters pausing for 5 minutes in the yard, coming in from both directions.

You can find the whole album here.

I wont go in to deployment steps here... it's all covered on the web. The basic concepts were to point an apache virtual host at a new directory in /var/www and then browse to the application. To my delight it started, throwing an error. I hadn't even configured a thing yet, so how could I expect it to run?

After configuring the Facebook connector and the database connection the site came up and I could log in and muck around. It wasn't long until I hit the following error. It was only on a specific data class that extended the ActiveRecord interface and only when checking if the data was valid or trying to save it. I could happily create the class and change attributes...

Wrong number of arguments (1 of 0)

What the hell... I hadn't seen ruby exceptions before, so I started to dig. The RAILS_ENV environment variable was set to 'development' and so there was a 'development.log' file sitting in the 'log' directory inside the application. This provided a stack trace and a few other bits and pieces.

After a lot of code commenting and uncommenting I narrowed it down to the 'save' method of the specific data item class. This was inherited from the ActiveRecord::base class and I had no say in what it did or how it did it. I did know that it was expecting no arguments, so that's where the '0' came from in the error, but I was also not passing it any arguments, so where the hell did the '1' come from!?!?!

I then tried the 'valid?' call as well... same result.

I chose to override the 'save' function in the model file by using a pass through... all of a sudden the code continued (after hours of exceptions) and the next related table row creation had a null foreign key for the item that should have been saved. It turns out that by creating a pass through I bypassed the entire 'save' method and therefore didn't attempt to write anything to the db. As soon as I tried to use the base 'save'I got the same error but now in the model file.

I was stuck... so I tried to bring up the debugger via the mini WEBrick server. It, unfortunately, didn't give me any more information than what the development.log file had provided.

Next I tried downgrading and upgrading ruby and rails. I was impressed with the 'gem' system... but nothing helped.

The final step was to google more and more... I had already tried gutting my model implementation (there was extra code in the for other tasks) but none of this changed the inability to call 'save'. All of a sudden one google search came across someone mentioning something about a 'reserved word'.... I google'd further.

Reserved Words

It seems that Ruby has a few words that you MUST NOT GO NEAR if you want your code to work. The main issue is that, when you do, you'll have no idea what you have done as the error message that results has NOTHING TO DO WITH the actual problem. It turns out that after browsing to a post by someone with a similar problem I saw the comment stating that they had used the word 'notify' for a column name.

... so had the original developer of the code I had worked on ...

There was no response to the post that pointed this out in the previous link, so that either means the original author was too ashamed and it was the correct fix, or they found the real fix and never got back to this.

Either way, I corrected my database by changing 'notify' to 'notify_opp' and ... fkn presto ... 10 hours of debugging resulted in a SUCCESS!

Further information on these magical reserved creatures

Ok, the fun part... in hind-sight I've done a little research and there are sites indicating what 'words' are 'reserved' for ruby. Unfortunately, not all of them say that 'notify' is!

• Ruby QuickRef [does not]
• Ruby's reserved words [does not]
• Ruby on Rails - ReservedWords [does]

References:

• [Problem] wrong number of arguments (1 for 0)
• Wrong number of arguments (0 for 1) on notifiy method in Ruby on Rails
  I imagine the title should have been '(1 of 0)' ... but it is still the same issue
• Problem saving model in Rails
• rails forum: wrong number of arguments error ... same error, different reserved word.

Conclusion

Be bloody careful with errors from ruby that don't make sense and don't spend too long digging in to a dead end.
Be diligent with your google searches too.

I spent a lot of time debugging this and I hope this post helps out others in the same scenario.

As per usual, I'd google-mapped NY prior to coming and new that there wasn't much freight action on the island. I had seen a few yards on the the east coast of Long Island near Brooklyn and had decided that would be a first stop once I had time.

Car floats and empty lots on Long Island

I thought we all called them train ferries or rail ferries, but it turns out they're known as car floats in America. The New York New Jersey Rail, LLC run one from Bay Ridge to New Jersey on-demand. Turns out that when I visited there was no demand whatsoever, to the point where I was actually sure that the whole site had been abandoned. It wasn't until I google'd today that I realised it is the end of the Bay Ridge Branch owned by the Long Island Railroad....
Actually, as I'm writing this I'm seeing conflicting information on Wikipedia as to what carfloat service is actually still in operation...

I then walked north to the other visible yard on google maps but it turns out the photos are old and the yard no longer existed. I turned east to see the subway depot near 9th Ave Station. It was pretty cool, nice diesel maintenance equipment, but I'd failed to take any good photos.

CSX: The Bronx

This was a fun trip... on my last day in NY I decided to venture north to see a yard just across Harlem River. At the time of research I'd neglected to check suburb names and so just went for it, on foot. I found the CSX depot with quite a lot of rolling stock, random Amtrak services shooting through and a track gang working.

I walked the length of the yard south after coming from the intersection at Baretto Street. In the distance there were two CSX locomotives doing some minor shunting. Fortunately I waited around long enough for an Amtrak service to bolt through.

The next part was meant to be a leisurely stroll across to the large junction of the Metro North and Amtrak railway near 149th Street 'Grand Concourse'. As I crossed the streets I started feeling slightly conscious... it wasn't until I saw a portable police turret keeping an eye out on an intersection that I realised a tourist should probably not be walking through the district with a large camera hanging around their neck.

Metro North and Amtrak near 149th Street

This area provided a nice amount of action. Around 1 train every 5-10 minutes in both directions and from both Metro North and Amtrak. Although the sun wasn't in the best position, and there were a lot of fences preventing clear shots, it was a good location to just relax in the high 20-degree temperatures + humidity.

Harlem River

I then walked south and crossed Harlem River. There seems to be a lot of freight infrastructure on the northern side, including a low-lying viaduct allowing the trains to traverse the border of the northern shore. The main Metro North rail bridge is also a great backdrop.

Harlem-125th Street Station

This is one of the first stations on the south-side of the line on the bridge shown previously. Therefore it carried the expresses and locals stopping at this station. Fortunately the sun was in the right position for anything heading south. It was a pretty busy location and the foyer of the building was amazing.

And that was it for New York... the next day was Amsterdam...

California

The goal was simple... fly the red-eye A380 from Melbourne to LAX, jump in a hire-car and make it to San Francisco the 'scenic way'. A few days would then be spent in San Francisco before returning to LA via the inland route. This would include Yosemite and a few of the larger railroad junctions as seen from Google Maps.

San Luis Obispo

The Pacific Surfliner (I think?) happened to arrive just as we did. There were a few UP Locos stored as well... maybe for banking? The town was great, unfortunately we didn't check out the coffee; there were quite a few lively places around the station to do so though.

The pedestrian bridge at San Luis Obispo was well designed. It provided a great view of the station and yard too.

I had always thought that the Bachmann models of the Amtrak cars were just cheap and didn't include side-frames on the bogies... turns out they're actually like this in reality... not the prettiest view.

Paso Robles

The next stop via Highway 101 was Paso Robles. Not much happening here at all... I nearly expected to see the same Amtrak train coming through, but it seems that we beat it way too easily. The station has a Sushi shop built in, but the prices weren't what we were willing to dish out despite paying the US$.

Quarry Lake (east of Watsonville)

An accidental detour saw us visit a quarry near Quarry Lake. The initial plan was to divert from 101 to check out the seemingly large junction at Watsonville, but the weather and time wasn't on our side.

Caltrain Station, San Francisco

Caltrain is a loco-hauled/control-cab operating passenger service from San Francisco (right next to the baseball stadium) down to San Jose. Turns out there's a few great restaurants next to the station in San Fran and whilst waiting for dinner I had a few minutes with a friends camera to check out the yard. Fortunately the sun was also in my favour.

As you can see, it's a terminus; they'll end up in the water unless the dig or build over to Oakland. Unfortunately I didn't get to see any of the trains in action, nor ride one, but it's something I'll go back again for.

Trams/Trolley buses in San Fran

I was quite impressed to see the trolley bus routes in San Francisco. I had never actually seen any running and the biggest shock was the lack of noise. I'm used to diesel buses here in Australia and the electric versions are bloody quiet. I imagine it could even be a safety issue if no one can hear them coming?
Another impressive feature was that the trams used one of the trolley bus wires where they shared paths. Of course, the bus would not pick up the other polarity from the ground, so they needed two wires in the air. Trams, on the other hand, only used one and so you'd see, at intersections, trolley buses and trams banked up behind each other.

San Francisco Cable Car Museum

This is a must-see for any rail enthusiast. Sure, the they're not exactly 'trams', but the techonology behind the system is awesome. This Museum actually still acts as the motive power source for the cars. The cables are turned here to pull the cars up the gradients. The cars are controlled by levers where the driver can choose to detach from the cable and apply brakes... i.e. allowing them to stop at 'stops'. Hence the cables are perpetually spinning, or during hours of operation anyway.

And then... the Cable Cars...

The world-famous cars that run on the cables are a tourist trap. The ticket price is 4x a standard fare and the queues to ride them are usually large. The cars to move quickly, but I imagine there's a limit to the amount of cars on the cable at once as you'll often see the drivers at the end stops waiting for the other cars to climb the hill. Pretty frustrating as someone in the line waiting.

As for the ride, the gradients are awesome and the passing is pretty dangerous... hang of the side if you dare, but keep your head in!

Oakdale

A random stop through Oakdale on the way to the Yosemite National Park found a random caboose and the Sierra Railroad's Dinner Train. Not much was happening around the yards, so I didn't hang around long.

Fresno

The initial perception of Fresno indicated little railway infrastructure and life... fortunately I was wrong. After a little false navigation following disused lines I came across 'South Railroad Avenue' which followed the main line. It turns out that there's a junction and then the BNSF depot. Finally some real american horsepower. Santa Fe had always been my favourite railroad (first model train, etc...) and it was nice to see them, although in the amalgamated BNSF livery.

The last miles on Interstate 5

After Fresno the countdown was on to get back to LA before midnight. The plane to NY was leaving early the next morning and we needed some time to check out Hollywood. Along the way back there were a few freighters hanging around loading sites, one was from Golden State Feed and Grain and another from Rail America.

And that was it... New York was next.