Fixing the Vivanco AV Control 5
|2009-07-19||Added last paragraph.|
Fixing the Vivanco AV Control 5
The number of SCART inputs is "always" to small. Actually, with my present setup, with the Yamaha switching video signals of different types, the need of a SCART input selector was not there as before. Rather, I needed a signal splitter, so that the dBox could provide both RGB for the TV, and YUV for the Yamaha, to me forwarded to the projector. For this, the Vivanco AV Control 5 appeared to be an interesting alternative, completely RGB(/YUV) capable, with remote control, reasonable band width, and moderate price tag . I purchased one such on 2004-04-13. Unfortunately, it turned out to have three problems:
- The infrared remote control protocol is strange, using alternating codes (I fail to see for what reason)
- The housing was extremely ugly, cheapish silver-plastic look, absolutely incompatible with the rest of my equipment, or with my taste for that matter...
- The format switching voltage on pin 8 of the SCART plug did not work properly: On voltages that indicated 4:3 format, although somewhat low but still within the specs, the device erroneously went into 16:9-mode.
The problem with the silly remote codes was solved with some systematic work with the Pronto, analyzing the codes. Every key on the remote control can send two different codes, one "501"-code, and one "701"-command. These are sent alternating in the following sense: Assume that the first key you press sends a 501-code, and the device reacts on it. Then the next key, regardless of which, will send its 701-code, the following its 501-code, and so on. So far so good. However, after having received a 501-command (701-command), the device is in a state where it only reacts for 701-commands (501-commands)! I.e., both the device and have an internal two-state state-machine, and they need to be synchronized for the remote control to work! Needless to say, this makes the life of users and designers of alternate remote controls more difficult. For usage in an integrated home-theater environment, it is desirable to put the device in a known state. To achieve this, I have selected a brute-force method: every key on the Pronto sends both the 501-code and the 701-code. This works reliably, but of course has increased cost associated, both in time for sending two codes, and in added memory requirement.
The ugly plastic front was replaced by an aluminum angle, appropriately cut and drilled, bought at a local hardware store. The rest of the housing, together with the aluminum profile, was spray painted matt black. See pictures.
The incorrect switching voltage was somewhat harder. I emailed the Vivanco hot line (on 2004-04-16) regarding the problem. I received a reply somewhat later, stating that they (or their manufacturer) were aware of the problem, but (of course...) other manufacturers were to blaim, because they equipped their boxes with too weak power supplies(!). Looking deeper into the circuit, it turned out that there were some badly selected Zener diodes that were responsible for the mis-behavior. Changing these (D32 (for input AV1), D22 (AV2), D17 (AV3), and D27 (AV4)) to, say, 5.6 Volts fixes the problem. Vivanco was informed on 2005-02-06.
On 2007-02-15 Samuel Wong of Welkintec Ltd. wrote me a very nice mail and presented himself as the designer of the device. He described in detail the changes his firm has made to fix the problem with erroneous switching voltages. He also described the the used IR protocol as the original Philips RECS 80 codes (SAA3008); Transmission Mode: Mode 1 (reference time REF equals 3To), Subsystem Address: -100. This protocol is described in detail here. My project Harc contains an implementation of the protocol (file recs80.xml), and the device is supported through the device file avcontrol5.xml.