Networking Harman Luxury Audio’s Range of Amps
By Sam Burkin – Field Support Engineer
(written regarding ARCAM SR250, AVR390, AVR550, AVR850, AV860 and LEXICON RV6, RV9 and MC10)
So when my boss said, “Sam! Write an article about networking our current range of AV products!” I thought to myself, “Well, that’s going to be a short article, as there’s not much to say about the networking of our units, we’re going to need a considerable amount of filler here.” It turns out though that I was just displaying a lack of imagination. Once I started thinking about the subject it extended out and out and out, and in the end it turns out that a Pulitzer is not going to be that much hard work to win after all.
Our current range of AVR’s/processors (from here on both types of product are referred to under the umbrella of “AVR”) are not bristling with a hoard of network related bells and whistles. They are primarily designed to have source components connected to them, and then deliver outstanding sonic quality from those source devices that is a cut above the competition. In my opinion the AVRs we make deliver on that in spades. When networking these products there is only a cabled option and we find leaving DHCP to sort things out is often the best way. This was why my initial thought was that the sum total of the article would be:
- Remove the AVR from its box
- Plug the AVR in to the mains
- Connect the AVR to a router with a network cable
- Turn on the AVR
- Enjoy how clever you have been in successfully connecting the AVR to the network.
Thinking about the installation process as a whole though, there are more facets that can be explored.
So where to start? Well, the primary functions of the networking on this range are to allow IP commands and calibration of the system using Dirac room correction software. The network module used in the units is also capable of being a UPnP rendering point, allowing internet radio and Spotify Connect so those functions are available. However the real golden…no scratch that…, platinum, über function that networking our AVR’s delivers is Dirac, and so a good place to start is right there.
Dirac room correction software that we would run on a laptop when calibrating one of the AVR’s units interacts with the unit using IP commands. That is an important thing to remember because in many installs there will be a home automation processor present that also communicates with the AVR via IP. The AVR’s can only have a single socket open at once which means they can only talk to one device over IP at a time.
If your AVR is connected to your home automation processor by IP and you then connect with Dirac, this will sever the connection with your home automation processor. Quite understandably, the home automation processor will be designed to be relatively aggressive in trying to re-establish a connection; after all who wants a flaky home automation system which gives up at the first whisper of a dropped packet? This means that the automation processor will almost certainly be successful in re-establishing a connection with the AVR. In turn though, that will mean that the IP connection to Dirac will be severed. Dirac is almost certainly going to be considerably more passive in its attempts to reconnect compared to the automation processor, so that will be that. The battle for the attentions of the AVR will have been fought. The home automation processor will have won, and the room correction programme will give you an error message and not work.
The solution to this is simply turning the control processor off during calibration, and turning it back on after. This will prevent the battle mentioned above.
On a related note, if there is a control processor in play that is connected to the AVR by RS232, you have to go into the menu and change the control method to IP whilst calibrating. By default the unit comes out of the box set for IP control but if being connected via RS232 the option for control will have been changed to RS232. If you are using Dirac version 2.X then the device discovery will still work and you will see the unit in the programme. Try and connect though, and you’ll get an error message. Using Dirac version 1.X the unit just won’t show up at all. To avoid this make sure that the unit is set to MENU > GENERAL SETUP > CONTROL > IP.
That segues neatly into that the fact that there are 2 versions of Dirac, and that this can be exploited to an installer’s benefit.
Relatively recently, Dirac rewrote their front end software from scratch for a couple of reasons. The result is a programme that looks a lot glossier, and has some new practical controls and features. One thing that has changed behind the scenes is how the application uses Internet connection. Dirac 2.X requires a connection to the outside world at all times when running.
When you turn up to install a unit you may have little or no idea what the network is like on site. You can ask some questions of the end user to get a vague idea but it is only once you get hands on that you can really understand. This means that the network could be rock solid and operate at warp speed or it could be dial up distributed from a router that should have been taken behind the barn and shot in the late nineties. Every 6 months or so I even still receive a calls from installers exploring their options for installing a unit in a property with no internet connection at all. Apparently there are still some people that are not interested in seeing dogs riding skateboards, cats playing the keyboard, and Australian people dropping things off a massive tower.
If you turn up to a site and the network is disgraceful or non-existent, here is trick to have up your sleeve. Download both versions!
Dirac 2.X requires a connection to the outside world at all times. However, Dirac 1.X only requires an internet connection when you open up a fresh install for the first time, and when you optimize your project filters. In instances where networking is problematic, you can break out Dirac version 1.X which will allow you to perform all of the measurement side offline, do the optimization on a mobile hotspot, and then upload the project to the AVR offline. By doing this, many hours trying to wrangle the network into submission can be saved.
For the above workaround it is possible to connect a computer directly to one of the AVR’s to carry out calibration, however it is easier to take a cheap and pre-tested router with you. It’s a useful thing to carry in an install kit for many purposes so I generally recommend carrying one anyway.
“That’s rubbish! Networked equipment should just work!” one gentleman said to me once. Well in theory there are networking standards and you would hope that devices that conform to them will work with each other. As with anything humans produce though, networking standards are created with tolerances. This unfortunately means that sometimes the planets align against you and things don’t work that you expect should.
The principle is aptly demonstrated with Parachuting. When you are thousands of feet up and heading towards the ground at around 120mph, it is pretty important that when you pull your rip cord that something happens to slow you down. Your primary parachute should work, it should be carefully packed each time with great care to ensure this. Still, at the risk of speaking out of turn for parachuting experts, most would likely tell you a well-packed reserve chute is still required fare in the event the primary one fails.
Redundancy. “The inclusion of extra components which are not strictly necessary to functioning, in case of failure in other components.” Employ this for parachuting and it could one day save your life. Employ it for installing an AVR and it might save you hours or days of needlessly wasted time. Fail to employ it for parachuting and the good news is you don’t have long to wait before it isn’t a problem anymore. Fail to employ it when installing and you might end up having the less grisly but more expensive result of wasted hours or days. As we all know, time is money.
As we have touched on, the other main function of the AVR when networked is control via IP, either for control by an automation processor or the free control app available for iOS and Android for both ARCAM and Lexicon.
The free apps can be a useful diagnostic tool even if they are not going to be used all the time, so it is worth being aware of their existence. A number of times I have fielded calls where an installer was looking for ideas because a unit was not responding to a control processor. The app is potentially useful with that because it uses the same commands that a control processor would over IP. Some control processors have a front end that doesn’t present the installer with these commands directly, but by the time the commands get spewed out the back end to the AVR they are exactly the same as the commands the app would send.
If you turn off your control processor, fire up the app instead and check whether you get a response. If the AVR is responding fine to the app, you know that:
- The AVR is configured correctly
- The AVR is talking to the router
- The AVR will respond to the commands if it receives them
You can then look elsewhere for an issue.
If the AVR does not respond, it may not put you on the verge of a solution, but it does get you started in narrowing down why commands are not resulting in a response.
The command protocols are detailed in a document simply called RS232 for ARCAM and RS232 Protocol Documentation for Lexicon. This document can be downloaded from the products’ respective web pages:
The commands themselves are identical via RS232 and IP but there are also other useful things in there like the port used for IP commands, the RS232 pinout, the command and response formats, and at the very back, all the IR commands are listed including discrete commands not emitted by the supplied remote.
To try and keep things simple, most of the commands are simulated IR commands. This means that you have a byte in the command format that tells the unit the string you are sending relates to an IR command, and 2 bytes that dictate what the command actually is. This means if your chosen automation processor is programmed by manually entering the entire hexadecimal string, you can largely copy and paste, changing only 2 bytes each time. There are some commands that are not in this format but they are the much more obscure ones, usually to do with fetching the status of the unit.
I think the final thing to mention then is that when you use networking equipment (like switches, power line adapters, wireless to Ethernet bridges etc. etc.) between the router and the AVR, this equipment is not going to be a completely transparent part of the network. Even unmanaged switches are not transparent, so if you are installing an AVR (or any piece of equipment) using a network extension device and issues arise, I would suggest as a first port of call, bypassing the network extension device and seeing if matters improve. Because of the tolerances in the networking standards mentioned earlier, some network extension devices just won’t get along with some equipment. Sometimes you will stumble across those combinations and often the network extension device seems to slip under the “suspicion radar.”
In summation, all networks are different, and becoming more and more complicated as we are finding new ways to integrate more technology into our lives. Therefore, when you install, go prepared. Have some tricks up your sleeve for those days when you seem to have angered the HiFi gods.
I hope this has been helpful, at least vaguely informative, and if not then at very least a pleasant read.