Miscellaneous notes

Here is the place for design notes, howtos, errata, ideas for further improvement - everything that is not documented in the PDF documents or the release package. Items will be added as they cross our mind or otherwise come to our attention...

Additional links and literature

KNX AN095, "Non-selective Data Link Layer acknowledge on multicast frames" has interesting things to say on when to send L2-ACKs.

The Wayback Machine has a copy of the schematic of the TP-UART interface developed at FH Deggendorf (Reference 3 in our paper). The corresponding paper by Stocker and Grzemba (Reference 8) does not contain information about the interface hardware.

GerbMerge looks like a convenient tool for merging (panelizing) Gerber files (especially from EAGLE).

Various comments on the hardware design

  • Our LEDs actually only need 0.1 mA to light up, but they need 0.3 mA for reasonable brightness.
  • Besides the lack of parity support, the reason why we could not use the TI SW-UART library (described in the paper briefly as "insufficient performance") was that it took at least two entire bit times from calling TI_TA_TX until the start bit showed up on the line. Therefore, the MSP430 could not pass on the characters it received from the PC to the TP-UART fast enough (since we wanted the interface bit rate to be identical and did not want to put any restrictions on the PC for compatibility reasons). Part of our solution was to start transmitting the start bit and prepare for the first data bit (output at compare interrupt) already in TI_TX_Byte.
  • We use an external oscillator instead of the DCO as the MSP430 clock source since it makes things considerably easier and the added power consumption is not relevant in our case.
  • ACTIface does not contain the two 10 nF capacitors between VCC/VSP and ground that are "recommended" in the TP-UART datasheet (C5 and C6 in the "typical application circuit"). We did not experience any ill effects, but you may want to add them.
  • A USB based interface (for example, starting from the ACTIface design and using a USB-to-serial converter from FTDI, or replacing the MSP430 with a USB capable microcontroller) would be easier to connect to current PCs; also, it would not have any power issues. One of the reasons why ACTIface still has a RS-232 interface was that we thought it would be a good idea for cross-development of embedded software that - once deployed on its production platform - actually communicates with the TP-UART via a UART interface (and not USB).
  • We added an additional send/return signal path (RTS/CTS besides RXD and TXD) since we thought it would be nice to have in some situations. However, all TP-UART status outputs are also connected to the MSP430, which can send information about their state via the UART interface.

Signal level conversion and PC side power supply

A (hopefully) helpful note: On ACTIface, UART levels are straightforward. For both sides of the MSP430, logic "1" (i.e., Mark/Idle, RS-232 -10V) corresponds to a high (Vcc) voltage level.

Design notes:

  • The voltages that are applied to EXT_PWR are those that the MAX1488ECPD will drive the RS-232 outputs to (that is, they are the voltages that the PC will see as TXD and CTS).
  • The 9V block battery is directly connected to the inverter input (through a protection diode) to avoid voltage drop across the rectifier and regulator (even if the regulator is a low drop type). The diode protects the voltage converter if the battery is connected with wrong polarity and prevents current into the battery when an external power supply is connected. Its forward voltage incurs a certain voltage drop, but this is not relevant considering the potential benefits.
  • The switch contact of the power socket is not used to switch between the external and "parasitic" (RS-232 status line) power sources, since this would mean routing power from the RS-232 status lines (or battery) through the rectifier and voltage regulator. No harm should be done if an external supply (or battery) is connected while the PC is driving RTS (and the RTS select jumper is set to connect it as a power input), since RS-232 line drivers must be current limited. (Wikipedia says "RS-232 drivers and receivers must be able to withstand indefinite short circuit to ground or to any voltage level up to +/-25 volts", and all line drivers we checked complied with that.)
  • D4 and D7 on ACTIface protect the optocoupler inputs from the negative voltages caused by Mark states (which are beyond the maximum ratings for the HCPL2531). D3 and D8 protect the line driver when the PC drives DTR and/or RTS to the wrong state. PWR_OK has no protective function.
  • Until the PC has properly initialized its RS-232 line driver, signal lines can not only be at V+ or V-, but also at ground potential. If DTR is in space state and RTS at ground level, PWR_OK will glow darkly although the power supply is actually not "OK".
  • T1 on ACTIface is necessary since the TP-UART SAVE output current is not sufficient to drive the optocoupler input. This is relevant when no MCU is fitted or when the signal should be passed to the PC without going through the microcontroller. This should not be a problem for TXD and TSTOUT_TW.


  • The RS-232 outputs of our lab PC had a fairly linear internal resistance of 1 k. When 5 mA were drawn, they dropped to 5 V. The sentence in Section 3.2.4 of the "Enhanced TP-UART interface board" report referring to the voltage drop due to the power consumption of the MAX1488ECPD ("It loads the status lines lightly enough that the RS-232 output levels are in the non-critical range of +/- 8 to 10 V") also applies to DTR and RTS on this lab PC.
  • Regarding our (failed) experiments to get by using power from DTR alone: The "low power IC" that failed to reach "stable operating conditions using DTR alone" was a MAX220 that was supplied (from DTR) via a 5V linear voltage regulator. The voltage regulator output did not reach 5V if it was powered up with the MAX220 connected; if the MAX220 was connected later, its RS-232 line outputs were so close to 5V that it was actually useless. The low-power optocoupler with a "signal rise time" at "unacceptable levels" (which data errors at 19200 bit/s) was a HCPL-2730 (or HCPL-2731).
  • It can be assumed that commercial KNX/EIB TP interfaces also contain optoisolation. Systematically disconnecting RS-232 status lines using a suitable break-out box would allow finding out which of these lines are used to power them.
Having your cake and eating it too:
  • It is possible to use only DTR for power (leaving RTS for data) when bending the RS-232 specification. This is possible by connecting V- to GND. This results in Mark levels of 0V: While this is not RS-232 compliant (levels between -5V and +5V are forbidden), all popular RS-232 receivers will interpret 0V as a Mark state. In this case, a simple CMOS inverter (4011) can act as a line driver. Actually, this is the approach taken by Christian Troger's design.
  • It would be nice to be able to select between proper Mark levels and 0V Mark levels (with RTS available for data), for example by providing a jumper that optionally connects V- to GND. However, this is not possible with the MAX1488E, since this IC does not work when Vee = GND.

Microcontroller selection

  • We wanted our MCU to have at least one hardware UART (to simplify the firmware). Two hardware UARTs would even have been better, but microcontrollers that have them were too large for our purposes.
  • "Popular product families": Our definition of "popular" was the existence of a user community that is active and visible on the Web.
  • The precise specification of the type we selected: TI  MSP430F1232 28 pin plastic small-outline (R-PDSO-G28), 50 mil (1.27 mm) pin spacing (TI package code "DW"). The MSP430F123 has an analog voltage comparator, while the F1232 has a 10 bit A/D converter; on ACTIface, they can be used interchangeably.
  • The MSP430 on ACTIface is a 3.3V type. The TP-UART delivers 5V on its VCC output, which makes a voltage regulator necessary. Interface levels on the TP-UART are adapted via its VIF pin.
  • Today, other microcontrollers may fit the bill as well (for example, the Atmel x8 picoPower series).

Diode selection

The "typical application circuit" in the TP-UART datasheet uses SMD components. Since we wanted to use THT components wherever possible, we had to find equivalent types. Our thoughts concerning the diodes (U2, D1) were:

Instead of the SMAJ43CA (TVS diode), Christian Troger uses the Fairchild P6KE51CA in his interface board. We followed this decision, since the P6KE51CA has identical or better characteristics than the reference part:

  • Identical reverse stand-off voltage (43V)
  • Reverse leakage current does not differ
  • Sightly narrower breakdown voltage range
  • Higher peak pulse current
The TP-UART datasheet describes the BYG21 as a "fast rectifier". The closest THT equivalent is 1N5408 (used by Christian Troger), but its package (DO-201AD) is inconveniently large. The Microsemi 30S10E3 would fit the requirements (peak forward current 150A vs. 200A) but was not available in Austria. We decided to use the Multicomp HER158G:
  • Better (faster) reverse recovery time than the BYG21
  • Higher junction capacitance. We think this should not matter because the diode is mainly operated forward biased.
  • Slightly higher reverse current. This should do no harm, since it is in the microampere range.

Although the HER158G works perfectly for us, we cannot exclude that there may be an impact on the AC characteristics of the circuitry. To be sure, voltage traces at the cathodes of the two different types would have to be compared.

Reset behaviour: Additional notes

"Depending on the PC configuration, this is often propagated to the application as 0x00" (paper, p. 15): The 0x00 character comes from TP-UART TXD changing from high (which is the idle level, causing the PC side of the interface to transmit a space state) to low - provided the PC processes the UART character despite the framing error that is caused by the missing stop bit.

On power-up and when the TP-UART receives a U_Reset.request service, D6 prevents the TP-UART RESn signal from resetting the MSP430 via RST, ensuring that the TP-UART-Reset.indication can be properly passed on to the PC. However, if the reset button is pressed (or RTS is connected as a reset signal and activated), the MSP430 will start up too late and miss the Reset.indication service. 
It would be possible to work around this by letting the MSP430 send a TP-UART-Reset.indication on its own after startup in case it receives no such indication from the TP-UART. However, to ensure consistent behaviour under all circumstances (it may be that the MSP430 was reset, but the TP-UART was not), the MSP430 should actively reset the TP-UART by sending a U_Reset.request in this case.

Simultaneous traces of EIB+, TP-UART VCC, SAVE, nRESET and TXD on bus power-up and power-down (with the buffer capacitors from the "typical application circuit") would be interesting.

End-of-packet signalization - as BREAK or ESC?

Showing the end-of-packet condition as a break signal is elegant, since it is "out of band". However, if a serial port implementation can handle BREAK states, it is likely to translate them into an escape sequence anyway (asynchronous signals are another possibility, but would be inconvenient for our purpose). Glibc (at least on Linux) can either use SIGINT or an escape sequence: "If neither BRKINT nor IGNBRK are set, a break condition is passed to the application as a single '\0' character if PARMRK is not set, or otherwise as a three-character sequence '\377', '\0', '\0'." (man 3 termios). Therefore, it is probably more useful to use an escape sequence from the start.

Software that would be nice to have

Firmware for testing the hardware: Turn on all LEDs for 3 seconds, then map the state of each switch and button to one LED (just copy byte from input to output port for this). Echo back all characters received via RS-232.

Firmware for testing the U_AckInformation time frame (cf. page 10, par. 2 in the paper): When a frame appears on the medium (created with an arbitrary KNX/EIB device) , the MSP430 waits for the maximum possible time as described in the paper (the expected frame length would be set via the DIP switches or via RS-232) and then sends a U_AckInformation service. Any bus monitor can be used to check if the TP-UART actually sent a L2-ACK.

Firmware for generating faulty frames in analog mode (cf. page 14 in the paper).

A PC test/demo program that uses termios to access the serial port and can be compiled without changes on both Linux and Windows/Cygwin (only using free tools):

  • Interactively send service requests (reset, state request, change to bus monitor mode) on key press
  • Send predefined frames contained in a text file (frame by frame, upon key press)
  • Show and decode services received from TP-UART (without actually decoding any KNX/EIB frame data)
  • Support both the Break and the Escape variant of end-of-packet signalization
  • Acknowledge frames incoming from the network if they are contained in a text file
  • Turn on/off DTR and RTS, show CTS status