Below you’ll find the differences between release 3.00 and release 0.0.2.3
A new manual is also available for release 3.00
OC32 versions 0.0.3.x are temporary/beta versions that have been discontinued as of 3.00 and are no longer supported. This means 3.00 is newer than 0.0.3.x
Please note: Both the OC32 firmware and OC32Config have undergone major changes:
OC32 Device Configuration has been significantly overhauled. Previously, a device definition could be loaded, but then this definition became a collection of loose pins in OC32Config and the OC32.
From 3.00 onwards, OC32Config and the OC32 recognize the connection between the pins as a “device”. This allows OC32Config to write all definitions belonging to that device to the OC32 with a single button, and read them back with a single button. The number of buttons in OC32Config under “Device Configuration” for writing definitions to and reading from the OC32 has been greatly reduced, which hopefully makes things a lot clearer for “normal users”. The old buttons are still there, but they’re hidden behind an “expert mode”.
In OC32Config, the option has been added to save a custom or modified Device as a DeviceDefinition to your PC’s file system
You can assign an “eXtended Address” from 0 to 95 to an OC32. The normal module address then becomes a Channel Address. Together, the eXtended Address and the Channel Address form a unique address. This way, 16 * 96 = 1536 module addresses are available.
In practice, you’ll never use all of these addresses. The idea is that you either use normal addressing or extended addressing on a single channel. Otherwise, it gets very confusing. However, you can make clever use of the channel numbers: For example, use channel number 1 for normal (operational) control. If you already have several OC32 modules active (on channel 1) and you want to add an extra module, you set that module to channel 0. You can then configure that module, assign its desired extended address, etc. Once you’re done, you set the module to channel 1 and it can join the rest.
Assigning an eXtended Address to a module is done with OC32Config on the “General” tab. It’s best to do this while you’re not using eXtended Addressing for that specific module. After all, if you want to assign an address to a module that doesn’t have a known eXtended Address yet, that module won’t know which eXtended Address to listen to. That’s why it’s also handy to reserve a separate channel for such purposes.
Selecting the eXtended Address of the module you actually want to communicate with is done at the top of the OC32Config window.
Besides an eXtended Address, there is also an eXtended Group Mask. Soon it will also be possible to control certain OC32 functions per group of modules. You then send such a command to one group within one channel. Each OC32 can be a member of none, one, or multiple groups. There are 16 groups defined.
Many digital systems won’t be able to control the OC32 using eXtended Addressing yet. At the time of writing, no system can do this, not even Dinamo. Some systems probably never will, because they are no longer being developed, such as Koploper.
You can communicate with the OC32 via 2 protocols. Although these protocols can be used interchangeably, they are fundamentally different. For configuring and testing the OC32, OC32Config uses the OC32 protocol. Operational control software can also use this OC32 protocol. The OC32 protocol is bidirectional and now (as mentioned above) also allows eXtended Addressing, so you have enough addresses to control everything.
Additionally, the OC32 understands the “old” OM32 protocol. The OM32 protocol doesn’t support eXtended Addressing and is limited to 16 modules * 32 pins, which is 512 “outputs”.
With OM32 Flexible Addressing, we use the address space for the 512 addresses as a linear address space. So the addresses are no longer divided over 16 modules, but you can distribute these addresses randomly over as many modules as you use, as long as the total number of required addresses doesn’t exceed 512. In practice, this often leads to much more efficient use of addresses. After all, a Dutch signal with 3 lamps occupies 3 pins, but can be controlled via 1 address. A German exit signal with a distant signal occupies 9 pins, but can be controlled with 1 address. In other words: almost every “device” occupies multiple pins and thus multiple addresses in the “old” situation, but can be controlled via 1 address.
You can now assign 0 to 6 OM32 addresses to each Pin. You give the first pin of the device 1 address, and the following pins 0 addresses. You give the OC32 module the first OM32 address it should listen to. The OC32 then calculates the OM32 address used to control the device in question.
You can calculate which address that is, but it’s also shown on the configuration tab of OC32Config next to the pin number. The condition is that you have entered AND activated the OM32 Flex Start-Address on the “General” tab. If the OM32 Flex Start-Address isn’t activated, the OC32 works the old-fashioned way with OM32 addresses, regardless of how many addresses you’ve assigned to each pin!
OM32 Flexible Addressing also works the other way around. Sometimes a device uses only one Pin, but you need multiple addresses to control the functions. For example, a 3-way MCC turnout, controlled with a Servo. If you want to control that from Koploper, you need at least 2 addresses. You can solve this in the OC32 by performing a redirect from another, unused pin, but sometimes that’s inconvenient or even impossible, for example if you have many such devices on one OC32. In that case, you actually need more than the 32 available addresses per OC32. With OM32 Flexible Addressing, this is possible by assigning multiple addresses to a pin.
There is one important limitation with OM32 Flexible Addressing. If this function is activated, only one OM32 command still works: “Set Aspect”.
For the first address assigned to a pin, the Aspects are linked 1-to-1, so Aspect 0 controls position 0, Aspect 1 controls position 1, etc. For the next address, Aspect 0 controls position 2, Aspect 1 controls position 3, etc. For any subsequent address, Aspect 0 controls position 4, Aspect 1 controls position 5, etc.
Flexible DCC addressing works the same way as the Flexible OM32 addressing described above. You could/had to set the DCC start address already, so nothing has changed there. What has been added is the ability to assign 0..6 DCC addresses to each pin. This way you can save DCC addresses or, the other way around, assign multiple DCC addresses to a device without having to use redirects. With DCC, this is even more important than with serial addressing, since unfortunately almost no DCC system can generate Extended Accessory Decoder Packets, which allow you to set 1 DCC address in 32 positions. You are therefore forced in almost all cases to fall back on the “straight” and “diverging” positions, so only 2 per DCC address.
Since iTrain now supports Extended DCC Accessory Packets in combination with certain command stations, the possibilities in the OC32 for this have been further optimized.
You now have the option to assign Basic DCC addresses and Extended DCC addresses separately. So the OC32 now has not only a DCC start address, but also an XDCC start address. Basic and Extended are therefore 2 different address spaces that you can use both, interchangeably if desired.
To each OC32 Pin, you can now assign a maximum of 1 XDCC address in addition to a maximum of 6 DCC addresses.
In terms of counting, the DCC specification is highly unclear, especially regarding starting at address 0 or 1. This is made even more difficult because a Basic DCC accessory decoder actually has 4 addresses, each with 2 outputs, each with 2 states. So it’s unclear whether decoder 1 starts with address 0, 1, 4, or 5. After consultation with iTrain and others, the following implementation was chosen for the OC32:
If you use your OC32s for trackside accessories as well as roadside accessories and day/night lighting, this combination offers even greater savings. Suppose you control your train accessories with DCC, your car accessories with RS485, and the day/night simulation autonomously or via ETI inputs. In that case, from now on you only need to assign DCC addresses to devices that need to be controlled via DCC, and OM32 Flex addresses to devices controlled via RS485.
It was already possible to activate the events defined for the Trigger Inputs via software (from an Aspect Definition) using a “soft-event” instruction. The possibilities for using the Event Trigger Inputs have been greatly expanded:
Due to the expansion of possibilities, the “Event Configuration” tab of OC32Config has been greatly simplified. That sounds contradictory, but with all the new options, it simply didn’t fit in the window anymore. You now have to configure the settings pin by pin. It has its pros and cons.
It’s now possible to configure a Pin (so one or more of the 32) as an input. This creates, among other things, the possibility to use the OC32 as an independent control unit for analog model layouts without PC control. Of course, you still need a PC to configure the OC32, but once that’s done, you can control the OC32’s functions via push buttons, reed switches, switches, or other external signals connected to a number of pins on the OC32. In a sense, it’s an extension of the Event Inputs that the OC32/FULL and OC32/ETI already had, only the function is slightly different.
To use a Pin as an input, a resistor bank must be placed in the relevant group of pins and this must also be set as such in the hardware configuration (General tab).
CAUTION: The input voltage on a Pin must never be more than +5V or less than 0V, otherwise it can cause irreparable damage to the processor! To minimize the risk of damage, it’s best to choose a resistor bank with a somewhat higher resistance value, e.g., 470 Ohm or 1k, provided of course that this is possible for the use of the other pins in the group.
An input is Active(1) or Inactive(0). The Pin can be high-active (normal) or low-active (inverted). High-active means the Pin is seen as Active if the input signal is greater than 4V. The Pin is seen as Inactive if the input signal is lower than 1V. Low-active is the reverse. With the low-active (inverted) setting, the OC32 generates a so-called “Pull-Up”. This means the Pin is “high” (so Inactive) if nothing is connected. In that case, you can easily connect a switch or push button between the Pin and GND. Switch/button closed is then Active, switch/button open is Inactive. With the non-inverted setting, the state is undefined if nothing is connected to the Pin.
A mechanical switch (almost) always bounces when toggled. That’s why the OC32 has a “debounce” function. The OC32 then checks a few times in a row whether the input is truly Active or Inactive before drawing that conclusion. This delay is called ON-delay and OFF-delay and can be set per Pin via OC32Config. The default delay is 4, approx. 100ms. If you’re bothered by bouncing inputs, you can increase these values. Usually, if it’s needed at all, only increasing the OFF-delay helps enough. If you want the OC32 to respond to very short pulses, you’ll have to decrease (one of) these values.
A Pin becoming Active triggers Aspect 1 of that Pin. Becoming Inactive triggers Aspect 0 of that Pin. So you can use the Aspect Configuration to set exactly what should happen when the input becomes Active or Inactive.
Previously, the OC32 could only receive commands from a digital system or PC. From now on, the OC32 can also report events back to the PC. The condition is that the connection to the OC32 is RS485.
Reporting an event is nothing more or less than an Instruction in an Aspect Definition. So a report can be activated by, for example, a state change of a Pin set to Input, but also at certain moments during the execution of a sequence.
With the PM32, you can control 64 turnouts (128 coils) with 24 wires.
The same technology is now also in the OC32. The OC32 now has an instruction that allows turnouts to be operated sequentially using multiplexing. To use this, a number of Pins must be equipped with source drivers and a number of Pins with sink drivers. In most cases, you’ll need to amplify the outputs with transistors on a DS32. The number of Pins you use is flexible, e.g.:
The first two options are obviously nonsensical, but a device definition will be made for the last 3 options.
The pins not used for multiplexing can of course be used for other things.
The OC32 has 2 serial ports: RS485 and RS232/TTL. The latter can only receive. Of course, that specific port does have a transmit capability, but it wasn’t used by the OC32. With “SendSerial”, that port can send data to external devices, such as MP3 players and all sorts of other things you can control with simple serial commands.
If you use the SendSerial capability, you can no longer use the RS232 port on the OC32 to control your OC32 itself. This means control must then take place via RS485 or DCC (or both). The RS232 port will still work, but will start missing packets while transmitting with “SendSerial”
The following instructions had already been declared “obsolete” and are a legacy from the OM32 era. These instructions have now been permanently removed:
What these functions did can now be achieved better and more flexibly with sequence instructions.
