maffi-git
commented
11 months ago I've done the mesuring as described and I get weird readings:
init_ebus: already switched to enhanced eBUS mode on TCP port.
init_ebus: clock frq 80000000 div 33 1/3, src clk 4
init_ebus: detected: 2575 Hz on 244 edges with 1980 +/1982 - edge width, 1005 H/858 L pulse width, i.e. 419 us H/358 us L period
init_ebus: master 2 0x10 delay=210 us [208-234]
execute: ebus -v
init_ebus: already switched to enhanced eBUS mode on TCP port.
init_ebus: clock frq 80000000 div 33 1/3, src clk 4
init_ebus: detected: 2711 Hz on 1023 edges with 1980 +/1982 - edge width, 910 H/858 L pulse width, i.e. 379 us H/358 us L period
init_ebus: master 2 0x10 delay=216 us [208-234]
execute: ebus -v
init_ebus: already switched to enhanced eBUS mode on TCP port.
init_ebus: clock frq 80000000 div 33 1/3, src clk 4
init_ebus: detected: 2424 Hz on 254 edges with 1980 +/1983 - edge width, 1120 H/859 L pulse width, i.e. 467 us H/358 us L period
init_ebus: master 2 0x10 delay=216 us [208-234]I'm starting to think that my connection issues with that Vaillant auroCOMPACT are because of the large deviations. In most cases it says 2424Hz. But 2711 is quite out of bounds.
I tried quite a lot of things, but nothing enabled a stable connection to the heater. Is it "broken"?
john30
Zolli
this is a continuation of https://github.com/john30/ebusd/issues/891 as it was misplaced there.
the recently released firmware is capable of analysing the signal wrt bitrate and arbitration delay.
in order to use that feature, the adapter needs to be udpated and then the following steps need to be performed:
the interesting part of the output after each "ebus -v" will look like this:
the first line shows bitrate measurement details with the calculated bitrate, min. clock counts for consecutive pos/neg edges, min. clock counts for H/L pulse widths, as well as calculated H/L pulse widths in microseconds.
the 2400 Bd target a H/L pulse width of 416 us which is basically 1000 clock counts. the minimal pos/neg edge width is targeted at 2000. so in the above example it looks like the actual bitrate on the line is a little bit higher than it should be, i.e. 2412 Bd instead of 2400, which is 0.5%. this is still tolerable, but when it exceeds 1.2% it might be problematic.
anyway, the firmware now also allows to adhere such situations by using the new bitrate deviation option in the web UI. this way, a slightly higher bitrate can be set which will then be used for transmission as well as reception.
the other 2 lines reveal the seen master addresses, independent of whether the message was valid wrt CRC, so when arbitration errors occur, "fantasy" master addresses would appear here. anyway, for each master it shows its current arbitration delay as well as the minimum and maximum seen for it since boot.
this allows for using the second feature of the adapter: to adjust the arbitration delay. the default for the delay is 200 us, but when other participants have a lower delay, then this should be adjusted accordingly.