-
-
Notifications
You must be signed in to change notification settings - Fork 132
Legacy hardware
The following is a list of legacy hardware that won't receive any support from the author and might even be unusable with ebusd now or in future. Use of these interfaces is as such experimental and not recommended:
- eBUS Adapter Version 2.0/2.1/2.2
- eBUS Platine v1.6
- Prof. Dr. Peter A. Henning et al.: EBUSD-Interface USB For some of these, the --latency option needs to be set due to delayed sending/buffering in the converter.
- Mikrocontroller.net: eBus USB Adapter
When connecting to a hardware interface that needs a serial connection and does not use hardware based arbitration (like eBUS Adapter Version 3), a decent UART needs to be used that does not buffer too much data in it. Known working devices of such kind are:
- FTDI based (like FT232)
- CP2102
- some RS232 to Ethernet converters
The Raspberry Pi's built-in UART is unreliable, although it has been made to work under certain circumstances.
However, there is a special "ttyebus" kernel module that works flawlessly with the lowest possible latency required for eBUS usage.
On FreeBSD it is recommended to use only FTDI based chip devices, as currently only this driver is supporting low latency settings.
ebusd automatically sets the low latency flag since commit 343a443. When using a version before that, the following command can be used to set the low latency flag in the serial device again (replace /dev/ttyUSB0 with the right device):
/sbin/setserial /dev/ttyUSB0 low_latency
FTDI driver for MacOS provides ability to change different settings, including latency. See vendor documentation for the details.
For all but the recommended eBUS Adapter Version 3.0 and eBUS Adapter Version 2.0/2.1/2.2 interfaces, a potentiometer on the adapter has to be adjusted to the current environment (i.e. voltage, cable length, etc.) in order for the hardware interface to work correctly.
ebusd can be used to support this adjustment by starting it without any CSVs in raw mode in foreground, e.g. like this (after stopping ebusd if it is already running as daemon, i.e. service ebusd stop):
ebusd -f -c /tmp --logareas bus --loglevel info --lograwdata=bytes -d $DEVICE
The parameter $DEVICE needs to be replaced by the corresponding /dev/ttyUSB0 or whatever device is used.
Starting with the potentiometer turned to the maximum left position (counter-clockwise), it has to be turned slowly to the right (clockwise) until ebusd reports "signal acquired" without toggling between signal and no signal, and shows lines like this:
2015-12-24 12:07:16.955 [bus notice] <aa
2015-12-24 12:07:17.001 [bus notice] <aa
2015-12-24 12:07:17.047 [bus notice] <aa
2015-12-24 12:07:17.093 [bus notice] <aa
2015-12-24 12:07:17.097 [bus notice] <10
2015-12-24 12:07:17.102 [bus notice] <50
2015-12-24 12:07:17.107 [bus notice] <b5
2015-12-24 12:07:17.111 [bus notice] <04
In case there is currently no traffic on the bus, around 20 lines per second with <aa should appear (the upper 4 lines in the example output above).
As soon as another device uses the bus, the values change to e.g. something like in the last 4 lines in the example output above. These should appear in short peaks and the pattern should return to the <aa values.
Most important for the potentiometer adjustment are the regular <aa lines. If those are showing up reliably and no lines with "signal lost" appear, the setting is fine.