diyAudio (
-   Digital Line Level (
-   -   spdif switch module for LCDuino (

linuxworks 26th March 2011 08:04 AM

spdif switch module for LCDuino
a sneak peek of some development I'm working on for the LCDuino lcd controller system.

an spdif 'pod' switch:

I like the idea of a remote pod. a wire concentrator that can be thrown on the floor or behind a cabinet or just out of the way!

its linked to the main preamp via a simple i2c cable (power,gnd, clock, data). nothing special.

the lcduino can be configured to talk to 2 different kinds of i/o switch. one is the relay based delta2 that gives 8 assignable relay ports, 'punchable' to the input or output bus (pick and choose). the other is an spdif switch like this one here. you send it a 3 bit a0,a1,a2 addr and it picks 1 of the 8 and sends it thru. simple ttl stuff that works just fine for spdif. 5v toslinks make the job even easier.

on the side are leds that map 1:1 with the input ports. those leds are software settable and when the system wants to, it shows those leds as the one that is currently active being bright and the others off. when the whole system is on standby, all leds are off. even when the system is up and running but put into 'dark theater mode' all leds go off but all functions still work.

you can assign analog volume levels to the i/o ports. if one spdif line was from your tv audio and another from mp3 player, you may want to have one level control run hotter than the other. this has a memory that keeps track of where you were at just before you switch to another port. you always have the last-used vol setting - even for a digital i/o port!

its an early POC but plans will come shortly. software support is already there in alpha test and is planned to be released (open source) really soon (weeks).

I love having a PGA vol controller and an spdif switcher all integrated, with sleep timer, named port screens and various display modes. hopefully others will see value in this architecture and module series.

Brett 26th March 2011 08:31 AM

Subscribed. Watching with interest.

linuxworks 27th March 2011 08:19 PM

more pics. no schematic yet, I went direct to perf board; but I'll draw one up later on. this will at least get the idea across.

some notes, referring to the pcb top photo, component side:

top/right pair of connectors (6pin) carry i2c. pinout is same as LCDuino: 2 pins at one end for power (paralleled), 2 for gnd, then data then clock. the keyed red connector is the same as the unkeyed 'courtesy' pass-thru, as I call it ;) it lets me daisy chain the i2c connection if I need to.

below that are the red/black/blue jumpers. you can set a 3bit user address on the port expander, the chip to its right (pcf8574). you can know this PE chip by its addr block to the top/left area and its i2c pullups in blue tombstones to the right, near the vcc power pin.

to the right of that chip are 4 nonkeyed jumpers. one is common vcc and the other 3 are for the software settable leds. the pcf chip loves to sink current but not source; so I dangle the leds off vcc and connect to ground to activate. this also means that my logic at the controller side has to invert and send 1's to all leds that should be OFF. those leds occupy the upper bits in the 8bit byte. the lower 2 bits or 3 bits contain the binary encoding of the port you want to select (001, 010, 011, etc). those are the bits0..bit3 and if you look at the wiring side, you will see the direct blue wires going straight across from the PE chip to the 'switch' chip.

the switch chip is bog standard ttl stuff; 74151 style. I plan to try various 'ALS' and other tech to see if it matters but I suspect it won't matter at all. the swtich chip has 2 connectors; one with red marker (lol) to send power and gnd to the toslink blocks. the other keyed connector is the 1 output (bottom pin closer to the power white molex) and 4 input pins. those go direct to the toslink blocks.

with the leds being a software abstraction, you can do things like this:


  // force the upper bits to be all 1 (which turns OFF our leds!)
  pcf.write(7, B11110000 | input_selector );



    inverted_shifted_mask = ~(1 << (input_selector+4));
    inverted_shifted_mask &= B11110000;  // only keep the top 4 bits
    pcf.write(7, inverted_shifted_mask | input_selector );

here I take the 'bitmask' version of the port number (ports start at port0) and shift that up into the upper area of the byte for 'led display purposes'. the lower portion of the byte contains the binary encoding of the port #, intended not for humans but for the 74151's benefit ;)

this software trick saved me having to decode binary into a 1-of-n mask just for the leds and it also lets me turn all leds off when the user presses the 'all lights out' remote button. if all lights are off, you could press an ID button and the leds can come up, show themselves, then turn off after a delay.

Lerg 27th March 2011 08:26 PM

Could this type of SPDIF switch also be used for a single input for multiple outputs?
I have more than one DAC that I want to use with a single SPDIF device, and I haven't found anything nice that would let me use them both without having to swap cables.

linuxworks 27th March 2011 08:48 PM

absolutely! you could completely map 1 input to a 'bus' and then have the outputs be bit-addressible in what I call 'multi-mode'. on my controller firmware, I support input selection (gui/web guys call that 'radio button' behavior) and also output selection (both styles; radio-button and also toggle-button, which is what you are asking for). in toggle button, you press the output port # (on the IR remote) to toggle it on/off. all ports that are on, still stay on but yours toggles states. the user can pick 'multi mode' and get that behavior on output_ports OR he can go to single-mode and have outputs feel like inputs, in that its 1-of-n radio button style.

the switch would be a bit different but the port expander would be the same. I would have the single input pin go to a 'bus' concept and then each output port (repeater port, essentially) would go thru an AND gate and either pass the data or not pass the data (assert all 0 or all 1 and not let pulses thru to the toslink senders). not at all hard. maybe I'll build one of those, too, as POC ;)

linuxworks 28th March 2011 06:05 AM

thinking more about the implementation of the more complex cross-connect switch.

if you wanted to have more manageable outputs, perhaps each output would have its own private 1-of-8 input selector. there would be 8 internal 'send busses' which come from the 8 possible input ports (toslink TORX blocks). each output 1-of-n would share all 8 TORX outputs, so depending on fanout, buffering may be needed (not sure).

1-of-8 selectors need 3 bits. if you are ok with 4 input ports, then you can now get by with 2 bits. the # of input ports you allow defines the n part of the '1-of-n' and also the # of bits needed in addressing.

if you go with 4 input ports, max, that's 2 bits of address. how many of those will fit in a byte? 4 of them. and so if you are ok with having 4 output ports, you could do this all in a single 8-bit port expander like the PCF chip I used. you take the parts of its 8bit byte (the pin numbers) and send a pair to one 1-of-n chip and then another pair to another chip, etc.

you formulate the byte you want from the user's setup. the user somehow defined the punchdown relationships (I want outputs 3,4,5 to be attached to input 1, etc) and so you make the binary mask from that describing all 4 outputs and their 1-of-n binary addresses and send that off to the PE chip. if the user changes one 'knob' position, you recalculate the new byte and send it out. any bits that are the same can stay the same, you do the right logical OR or AND as needed.

this assumes you want a multi by multi switch. if you want simpler, perhaps more optimizations can be done.

linuxworks 24th May 2011 12:27 AM

code is finished. you can get a copy of the .zip file (source that is buildable on any arduino IDE) here: The LCDuino-1 Display I/O Processor (follow the 'download' link on the left).

'spdif switch' mode is just the software running with no volume control engines configured. go into the config menu (on the lcd, using the IR remote) and set the vol engine to 'n/a' and set the i/o engine to 's-addr' and you should be able to name ports and have the names show up on the top line as you change inputs.

3nity 25th May 2011 10:01 AM

Really interesting.
I was wondering if it's possible to use it as a simple Sample Rate Display.
I.E. it checks the sample rate (bit depth) of the S/PDIF stream and displays on lcd.

Or is there a better way? Pardon my noobie question.
Thank you.

linuxworks 25th May 2011 02:19 PM

I would like to get a samplerate display. its not easily done. there is no receiver to decode the stream and show any base frequency.

however, it might be possible to put a freq->voltage converter in there and roughly map the basebase freq (as sampled) to a samplerate frequ. there are only a few standard SR's so it might not be too hard to hack it like this.

currently though, nothing 'sniffs' the data; its just passed thru as-is. but I do like the idea and have thought about it for a while. its just beyond the layer-1 nature of this design, at the moment.

Vladco 31st May 2011 08:33 PM

Linuxwork it's an interesting controller. I interested to know if it will work with regular relays (not latched) because I've got some on hands.

All times are GMT. The time now is 12:12 PM.

Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2017 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 18.75%
vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2017 DragonByte Technologies Ltd.
Copyright ©1999-2017 diyAudio