Open john30 opened 10 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"?
the more edges are counted (i.e. the longer the time between two "ebus -v" calls is), the more unreliable is the measurement, so the 2711 Hz are not really reliable. I guess your device it right at the edge with 2424 Hz, so I'd suggest to set the deviation to 30 and see if that helps. "stable connection" meaning communication with the devices on the bus I guess? or do you refer to WIFI stability? in the latter case, try with the new firmware version released today, as it contains several commits in ESP-IDF wrt WIFI
Sorry, I get back so late. Stable would mean for me, retrieving Data via comand line on my raspberry running ebusd. I receive various error messages besides successfull ones, like "SYN Received", "received ERR: invalid argument" or "wrong symbol received". My ping rates to the adapter are like this - usually arround 2-4ms: 18 packets transmitted, 18 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 2.041/4.520/14.681/3.697 ms I had to move the wifi-mesh-station next to the heater or the adapter would connect to a different base. Bases are connected over ethernet then. For now I tried your latest firmware, which improves the situation a bit. I also switched the raspberry pi to an ethernet-connection.
I'm thinking about ditching the network connection and move my py next to the heater and use USB.
you might want to give the current version a try
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.