Monday 16 May 2016

Surround Sound Switch #7: Wrapping Up

Spinning The Room

This is a quick summary of the contents and conclusions reached in my recent series of six articles on the subject of Surround Sound Stage Rotation switch designs and prototypes. The series is about various ways of rotating the sound stage of a surround sound / home cinema audio system, so as to make any chosen wall or corner the focus of the action.

Said action takes place in an arena I've dubbed the octoroom. This is a bit like a normal rectangular room, but with a satellite speaker in every corner, and another in the centre of each wall.

Part 1: The Mother Of all Relay Boxes

I start out by examining the ready-made solutions available in the market. This doesn't take too long, as there are none. The hopelessness of seeking help from the audio kit manufacturers is bemoaned.

I spend most of our session together longing for an earlier time, when things like the MORB-1 were available in shops.

Part 2: Rolling your own Commutator

I detail my personal colour scheme for octoroom wiring, explaining its minor deviations from the relevant standards. Then it's on to another pipe dream, this time involving acres of pristine copper plated (or more likely brass, or other alloy) substrate. An imaginary comb made of brushes is used to illustrate the ideal to which our prototypes can hopefully converge.

I spend most of our session together longing for an earlier time, when such commutators were available in shops.

Part 3: Bulgaria (rotary switches)

The ideal 8-pole commutator can be simulated by helically wiring a suitable stack of wafer switches. I discover 7P8T palladium contact rotaries for sale in Bulgaria, and buy them for research. They turn out to be ex-telecomms system components, too fragile, difficult to wire, and otherwise unsuitable for audio use. But they inspire a passive rotary switch design, which eventually becomes my first successful prototype.

A new feature dubbed Mode 5 is introduced, for the specialist who needs to analyse custom curated surround sound music recordings. It allows a 5.x remix to be "stretched out" over the whole 7.x room, without adding in any sound processing by the receiver.

Now that concrete prototypes are beginning to emerge, I describe a scheme for quickly and conveniently swapping them in and out of the home cinema system. The scheme is based on Bulgin 8-pin, cable- and panel-mounting, plugs and sockets.

Part 4: Group Theory (toggle switches)

The mathematical area of permutations teaches that a single 8PDT switch, suitably wired, can rotate our sound stage through any single angle that's a multiple of 45°. Such rotations can also be composed, or applied one after the other, simply by stringing two or more such switches in series, in any order. So, we can choose a suitable chain of three "basis rotators", say 45°, 90° and 180°, and by selectively turning certain ones on and off, achieve any multiple of the atomic 45° rotation.

Eight pole toggle switches exist, albeit outside the unspoken, hobbyist budgetary scope of this series. But usefully, permutation theory also shows that a safe implementation of the 90° rotation can equally be achieved by splitting our 8PDT switch into two more readily and cheaply available 4PDT units ganged together, and that the 180° can similarly be reached by this means, or even by ganging together four DPDT units.

What is meant by safe in this context, is that under failure conditions, when one or more of the component switches fails to operate, no damage other than a seriously mixed up surround sound image will be caused. Amplifier outputs will not become cross-connected, nor asked to drive two or more loudspeakers in parallel. Sadly, the same can't be said about the 45° rotation stage.

There's a brief, unintelligible diversion, something about binary clocks, I dunno...

I make two more successful passive prototypes based entirely on 4PDT toggle switches - first some big Hong Kong ones with screw terminals, then smaller switches with solder lugs. Each prototype contains a 90° and a 180° rotator, as well as the new Mode 5 feature, which takes up one further 4PDT switch for a total of five. The 45° rotator has been dropped temporarily, as there's no easy way to guarantee that its two associated 4PDT switches will always be operated simultaneously and kept forever out of the potentially destructive one on, one off state.

Part 5: Relayer (electromagnetic relays)

Essentially the same audio circuit can be transcribed from the toggle switches in part 4 to the 4PDT electromagnetic relays in this part. With the addition of a 12V PSU and a 4-bit hexadecimal thumbwheel switch, prototype number 4 - the first active device in the series - is born.

The 45° rotator is reintroduced, since the two 4PDT relays that constitute it can now be guaranteed driven together and kept synchronised. Even under rare fault conditions, e.g. a relay coil burning out, the risk of damage can at least be mitigated by assessing which failure mode - amplifier outputs shorted together, or loudspeakers becoming paralleled up - is the less serious, and wiring the switch contacts accordingly. A free online circuit simulator is used to pre-verify the audio wiring schematic.

I finally have a full 8-position, manually operated, prototype sound stage rotator.

Part 6: Arduino (remote control)

No sooner has it arrived, than the hex thumbwheel switch is replaced by an Arduino Uno, driving the relays and relay pairs through bipolar npn transistors. A wiring self-test program is written, seen operating in a YouTube video. This verifies again that all audio pathways are switched correctly, as the compass orientation rotates, and as Mode 5 is switched on and off.

Home is an MB4 project box
The test wiring is removed, and an IR receiver module is interfaced to the Arduino. Suitable IR codes are obtained by "sniffing" an old Sony BD player remote; these are then embedded into the code, and verified to operate as expected.

Some speculation about future development occurs, but prototype number 5 feels like the logical end of this road. There's life after prototyping, of course. I still have to design a suitable custom PCB, using just the bare ATmega328P chip and a 16MHz crystal, so I can keep my Arduino Uno board for future projects. Still have to stick it all in a box. And so on and on...

Acknowledgements

Thanks to my wife for putting up with (a) so many odd deliveries of random munitions from Amazon, Ebay, Maplin (hi Scott!) and RS Components, not to mention international arms shipments from USA, Hong Kong, Germany and Bulgaria; and (b) the too many hours I spent locked away in the man-cave, playing with screwdrivers, soldering irons, and ticking devices bristling with hundreds of multicoloured wires.

Special mention to Georgi, my Bulgarian rocket scientist colleague, for pushing me to the Arduino limit, and convincing me there would be merit in these investigations. Without his input, I'd have contented myself with a twisting plug and socket manual solution.

The End

Tuesday 10 May 2016

My Cat Here

Meet our Cleo

Of course the Internet is made of cats, everybody knows that. So here is our latest contribution, and indeed our latest family member: Cleo, aged almost one and a quarter.

Actually she's still at the Scottish SPCA rehoming centre right now, just awaiting a little dental scale and polish, and whatever other surgical interventions might be appropriate (ssshhh). But she has been duly reserved, her new home is ready and waiting, and we've been busy planning and buying her new toys and other worldly chattels.

Cleo strikes you at first as a quiet wee lass - indeed, "A very timid little lady" is the first entry on her vet's record. She's recently lost her owner(s), sadly no longer able to take care of her. And just at this time, with all she's been through and the upset in her life, she can appear a little reluctant to make new friends. But she didn't have to spend too long as a rescue kitty. As soon as she appeared in her temporary accommodation quarters, as soon as she came forward to get tickled, as soon as she miaowed, she was all ours.

Insofar as any cat can ever be said to belong to any of us... anyway.

The very lovely Cleo Kerr, everybody!

Thursday 5 May 2016

Surround Sound Switch #6: Arduino (remote control)

SparkFun Electronics Arduino Uno R3
Previously:
Mother Of all Relay Boxes
Rolling your own Commutator
Bulgaria (rotary switches)
Group Theory (toggle switches)
Relayer (electromagnetic relays)
Adding remote control to the relay-based prototype can be fairly trivial, since quite often the work has mostly been done for us already by others. One such easy route is via Arduino and infra-red, for which many IR receiver modules are cheaply available. Also available incidentally are WiFi and Bluetooth modules for Arduino, not to mention the fully Wi-Fi integrated MKR1000 and Uno WiFi, so there's no shortage of options. But today, I'll just be looking at IR.

Arduino pins driving transistors driving relays.
The Arduino Interface

Regardless of the connectivity solution adopted, the first requirement is for the Arduino device to take over operation of the four signals controlling the seven relays. At the moment these terminate at the thumbwheel switch, which can selectively operate one or more coils by connecting their lower ends to 0V. In the case of a relay pair, this results in a current of 150mA sinking through the switch contact - much more than an Arduino digital output can either sink or source (20mA continuous recommended, 40mA absolute max).

The solution is to use a transistor, as shown in this circuit diagram, to amplify the current capacity between each Arduino output and its associated relay coil(s). Here I've used my old favourite, the silicon bipolar npn device; MOSFETs are another option. The relay drivers are on pins 2 (45°), 4 (90°), 7 (180°), and 8 (Mode 5). The four so-called freewheeling diodes (e.g. 1N4007), slung across the relay coils in reverse, protect the transistors from the back EMF generated when the highly inductive load is switched. Now when one of these four Arduino outputs goes high (+5V), current flows through a resistor into the transistor base, switching it on. This allows a larger current to flow from the +12Vdc rail through the relay coil(s) and the transistor to 0V. Any general purpose npn transistor with the following specifications will do:
min DC current gain hFE ≥ 40
max DC collector current IC ≥ 200mA
max collector-emitter voltage VCEO ≥ 20V
max total power dissipation Ptot ≥ 100mW
The popular 2N2222 is one example of a suitable component, but note that its frequently cited European "functional equivalent" BC548 is actually ruled out by having too low a maximum collector current (100mA). Now let's choose an appropriate resistor value:
Rmax = Vcc / (Imax / hFE) = 5V / (150mA / 40) = 5V / 3.75mA = 1.3kΩ.
I'd probably recommend using 1kΩ or so for that extra 30% safety margin. If the base resistor value is too high, the base current will be too low to ensure the transistor saturates and remains outside its high dissipation, potentially destructive "linear" mode. By contrast, when in digital mode, the transistor is either fully off (collector current is zero) or fully on (collector-emitter voltage is essentially zero), so in each case, the power P = I * V ≈ 0.

The IR Library

The Arduino microcontroller development system has access to an excellent free IR control library, Arduino IRremote, by Ken Shirriff. Thanks Ken! This code resource both sends and receives infra-red signals. Many people have made use of this, including Jason Poel Smith, who very reasonably asks,
Most of the buttons on a remote control are never used.
So why not use them to control appliances and other electronics around your house?
then goes on to do just that - repurposing any unused command on any of your IR remotes, to control an electrical outlet switch. He even includes a simple and easy-to-use learning mode, whereby a single additional button press is all you need to teach your electronics which new signal it has to respond to.

The Command Set

Our requirements are a little more complicated than controlling the state of a single relay, but not by that much. We have to drive three transistors to control the orientation, and a fourth for Mode 5. So, four digital outputs, rather than one? No big deal.

Now for our UI commands. We'd like buttons to take us directly to a particular orientation, numbered maybe 0-7, maybe 1-8, or maybe mapped to the physical layout of a numeric pad - whatever you prefer. Two more buttons, to rotate from the current orientation by 45° increments, either left or right. A toggle, and/or two separate commands, to engage/disengage Mode 5. A reset button to set the orientation back to 0 and disengage Mode 5.

Sketch

Can't remember the last time the blog known as My Code Here contained any actual computer code, but anyway, here is the full Arduino sketch source for the project:

/*
  RoomSpin
  Audio soundstage rotation switch for 7.x surround sound system with 8 satellites
  http://mycodehere.blogspot.co.uk/2016/05/surround-sound-switch-6-arduino-remote.html
  This code is in the public domain - created 6 March 2016 by John Michael Kerr
*/

#include <irremote.h>
#include <irremoteint.h>

//#define TEST

void setup()
{
  setupRelays();
  #ifdef TEST
    setupTest();
  #else
    setupMain();
  #endif
}

void loop()
{
  #ifdef TEST
    loopTest();
  #else
    loopMain();
  #endif
}

// Main program setup & loop

void setupMain()
{
  setupReceiver();
}

void loopMain()
{
  long code = readReceiver();
  if (code)
    performCode(code);
}

// IR receiver handling

const int pinIR = A5;

IRrecv* receiver;
decode_results code;

void setupReceiver()
{
  Serial.begin(9600);
  receiver = new IRrecv(pinIR);
  receiver->enableIRIn();
}

long readReceiver()
{
  long result = 0;
  if (receiver->decode(&code))
  {
    result = code.value;
    Serial.println(result, HEX);
    receiver->resume();
  }
  return result;
}

// Command codes

const long
  codeDigits[8] =
  {
    0xbeef0000,
    0xbeef0001,
    0xbeef0002,
    0xbeef0003,
    0xbeef0004,
    0xbeef0005,
    0xbeef0006,
    0xbeef0007
  },
  codeLeft = 0xbeef0008,
  codeRight = 0xbeef0009,
  codeMode5_ON = 0xbeef000A,
  codeMode5_OFF = 0xbeef000B,
  codeMode5_TOGGLE = 0xbeef000C,
  codeReset = 0xbeef000D;

// Command codes for Sony BD (RMT-B119P)
//
//const long
//  codeDigits[8] =
//  {
//    0x00090B47, // 0
//    0x00000B47, // 1
//    0x00080B47, // 2
//    0x00040B47, // 3
//    0x000C0B47, // 4
//    0x00020B47, // 5
//    0x000A0B47, // 6
//    0x00060B47  // 7
//  },
//  codeLeft = 0x000DCB47, // Left arrow
//  codeRight = 0x0003CB47, // Right arrow
//  codeMode5_ON = 0x000E0B47, // 8
//  codeMode5_OFF = 0x00010B47, // 9
//  codeMode5_TOGGLE = 0x00066B47, // Blue
//  codeReset = 0x000E6B47; // Red

int compass = 0;
bool mode5 = false;

bool codeToMode(long code)
{
  switch (code)
  {
    case codeMode5_ON:
      return true;
    case codeMode5_OFF:
      return false;
  }
  return !mode5;
}

int performCode(long code)
{
  for (int c = 0; c < 8; c++)
    if (code == codeDigits[c])
      return rotateTo(c);
  switch (code)
  {
    case codeLeft:
      return rotateBy(-1);
    case codeRight:
      return rotateBy(+1);
    case codeMode5_ON:
    case codeMode5_OFF:
    case codeMode5_TOGGLE:
      return setMode5(codeToMode(code));
    case codeReset:
      mode5 = false;
      return rotateTo(0);
  }
  return 0;
}

int rotateBy(int eighths)
{
  return rotateTo(compass + eighths);
}

int rotateTo(int eighths)
{
  compass = eighths & 7;
  setRelays();
  return compass;
}

int setMode5(bool value)
{
  mode5 = value;
  setRelays();
  return 0;
}

// Drive the relays

const int pinCTRL[4] = {7, 8, 12, 13};

void setRelayMask(int pin, int mask)
{
  setPinMask(pin, compass, mask);
}

void setRelays()
{
  for (int p = 0; p < 3; p++)
    setRelayMask(pinCTRL[p], 1 << p);
  setPinIf(pinCTRL[3], mode5);
  delay(100); // Let the relays settle.
}

void setupRelays()
{
  for (int p = 0; p < 4; p++)
    pinMode(pinCTRL[p], OUTPUT);
}

// Low level I/O support

void setPinIf(int pin, bool condition)
{
  digitalWrite(pin, condition ? HIGH : LOW);
}

void setPinMask(int pin, int value, int mask)
{
  setPinIf(pin, (value & mask) != 0);
}

// End of tab

This listing shows placeholders for the actual IR remote codes generated by your remote. Run the program with the Serial Monitor enabled, then blast it with your own remote, making note of the hex code generated by each of your chosen command buttons. Then search my source for the string 0xbeef, and replace these hex constants with your own. The numeric keys (here numbered 0 to 7) are stored in order in the codeDigits array, and the command names following these should be self-explanatory.

I'm currently using this prototype with codes for a Sony BDPS590 Blu-Ray player (remote control model number RMT-B119P), these are the codes in the commented-out section below the placeholders. Known affectionately to my wife and me as as "stubby buttons", this is a well-behaved remote - most buttons generate a single code followed by a stream of 0xFFFFFFFF, as long as they're held down. The only exceptions are volume up/down, mute, and the other TV buttons, whose output depends entirely upon which make & model of TV you've programmed it for. With other remote brands, be prepared to do a little C++ protocol tweaking to handle alternate and/or repeating code complications.

Wire Test

Last time I promised you a fully automated wiring test using just the Arduino Uno with no additional hardware. How are we going to achieve that with only 14 digital I/O pins available on the development board, when there are 19 or 20 terminations on our relay loom? Count them: 4 control inputs, and on the audio side, 7 or 8 inputs plus 8 outputs. Answer: by pressing the Arduino's six analog inputs A0-A5 into service. These work just as well as digital inputs, and bring the available total to exactly plenty. In fact I've already used A5 to interface the IR receiver module (pinIR in the code), rather than the default pin 11.

Say we keep the existing pins 2/4/7/8 attached to the four coil controls, as in the diagram above. Now associate pins 3/5/6/9/10/11/12/13 respectively with the eight audio amplifier outputs. For test purposes these will take the place of the physical amplifier outputs in real life.

Next, for the loudspeaker inputs, associate analog inputs A0-A5, operating in digital mode, with the first six, and pins 0/1 with the remaining two.  The IR receiver module must be disconnected from pin A0 during this test. Now all our test program needs to do is drive the coil controls with every binary pattern from 0 to 15, and for each pattern, walk a single bit (actually a logic zero) from the first audio amplifier output through to the last, checking that it appears only on the expected loudspeaker input pin, if any.

Note the change in I/O terminology here. While designing the relay network, we called the amplifier signals inputs and the loudspeaker destinations outputs. That made sense from the viewpoint of the switch. Now in the Arduino software, from the perspective of the system testing the switch, our ins & outs are swapped around.

Here is the source code for the wire test, which should be added as a new tab to the main code above. Then in the main sketch, remove the double slashes from the line //define TEST. Remember to undo this edit (and reconnect the IR receiver module) once the wire test is complete.

/*
  WireTest
  A wiring test utility for the RoomSpin project
  http://mycodehere.blogspot.co.uk/2016/05/surround-sound-switch-6-arduino-remote.html
  This code is in the public domain - created 6 March 2016 by John Michael Kerr
*/

const int
  pinIN[8] = {A0, A1, A2, A3, A4, A5, 0, 1},
  pinOUT[8] = {3, 5, 6, 9, 10, 11, 12, 13};
  
int
  output,
  expected,
  actual;

void setupTest()
{
  for (int p = 0; p < 8; p++)
  {
    pinMode(pinIN[p], INPUT_PULLUP);
    pinMode(pinOUT[p], OUTPUT);
  }
  writeOutput(0xFF);
}

void loopTest()
{
  for (compass = 0; compass < 8; compass++)
  {
    setRelays();
    for (int mask = 1; mask < 0x100; mask <<= 1)
    {
      writeOutput(mask ^ 0xFF);
      delay(50); // Let the outputs settle.
      readExpected();
      readActual();
      while (actual != expected); // Crash!
    }
    writeOutput(0xFF);
  }
  mode5 = !mode5;
}

void readActual()
{
  actual = 0;
  for (int p = 0, mask = 1; p < 8; p++, mask <<= 1)
    if (digitalRead(pinIN[p]))
      actual |= mask;
    else
      actual &= ~mask;
}

void readExpected()
{
  int mask = output ^ 0xFF;
  if (mode5)
    mask = useMode5(mask);
  mask <<= compass;
  if (mask > 0xFF)
    mask >>= 8;
  expected = mask ^ 0xFF;
}

int useMode5(int mask)
{
  switch (mask)
  {
    case 0x01:
    case 0x40:
      return 0;
    case 0x02:
      return 0x01;
    case 0x20:
      return 0x40;
  }
  return mask;
}

void writeOutput(int value)
{
  output = value;
  for (int p = 0, mask = 1; p < 8; p++, mask <<= 1)
    setPinMask(pinOUT[p], output, mask);
}

// End of tab

There's one headache with using up all 20 I/O pins in this way. Serial communications normally proceed via Arduino pins 0 and 1. With these tied up, how are we to glean any diagnostic information form the wire test?

My simple solution is first to add LEDs with series current limiting resistors to all twelve output pins (four relay drivers and eight audio channels). Now run the test, and jump into an infinite loop as soon as any unexpected result occurs. That's the function of this rather suspect looking line of code, with its barely noticeable empty loop statement:
while (actual != expected); // Crash!
All being well, these LEDs will flash binary patterns and masks, repeating one full test cycle every eight seconds. When the unthinkable happens, the LEDs become frozen, displaying in an unambiguous snapshot the state of all output signals, at the instant of fault detection. Yay diagnostics!

Here's a short video of the wire test in action. It's a bit less dramatic than its title suggests. But if you've read this far, you know that already.



In a past life, I worked with embedded systems and microcontroller projects, based on hardware such as the Motorola MC68HC705 series [pdf], for over 15 years (1980-1995). This is the first time I've used a high level language which I didn't have to design and implement entirely on my own. Okay, it's only C++ with a little preprocessor supplied syntactic sugar, but I'm still impressed. I like your brave new world!

Future Expansion

Hmm, so back into normal operation, and the Arduino Uno still has a bunch of those analog input pins free, eh. It's tempting to drive them with signals derived from the actual audio waveforms, suitably rectified and limited, then perhaps using some custom automatic gain control (AGC) code, translate those input levels to PWM brightnesses feeding a retro ring of eight front panel LEDs. When the audio is quiet, these LEDs could pull double duty by indicating the currently selected orientation.

In fact that was the thinking behind the quirky output pin selections for the relay drivers and the IR receiver module. Since outputs PD3/5/6 and PB1/2/3 are capable of PWM operation, they're reserved for future LED driving duty. I'd be happy enough driving these LEDs in pairs just like the relays, but if you demand one LED per audio channel, you might want to reassign some I/O and use the Arduino Leonardo. That board offers an additional PWM output on pin 13, as well as extending analog input capability to several of the digital I/O pins.

Any other additional features? Maybe we'd also like the switch to revert automatically to the default, powered-down state, after a few hours of inactivity - just so we don't accidentally leave the relay coils needlessly burning up the watts for weeks on end when not in use.

Two Distinct Defaults

Typically a switch like this will spends most of its life in just one particular orientation, with an occasional foray into a second, still less frequently a third, and so on. Obviously it's worth wiring the most frequently used orientation as the default one, which has been called "North" in my descriptions to date, and in which all seven relays are de-energised. Then for most of the time you can simply have the device unplugged or switched off, saving power and component life.

Less obviously, the second most popular switch state might benefit from being stored in non-volatile memory, and selected automatically on power up. That way, whenever movie night, holiday projector time, or whatever other occasion rocks up, you need only power up, and the sound stage rotates instantly to the secondary setting, ready for the evening's entertainment.

Such a fixed "secondary default" could easily be programmed with a few seconds' work. A better solution however might be to introduce a new command, allowing the current switch state to be saved in the Arduino microcontroller's non-volatile EEPROM memory with the press of a button, and subsequently, to be retrieved from there upon power up. Or to automate the process completely, write the state to EEPROM every time it's changed, so the switch effectively remembers its setting through a power cycle. Just be aware of the EEPROM erase/write limit of nominally 100,000 operations.

The EEPROM storage requirements of this design are reasonably low, at one half of a byte.

Next time: wrapping up.