[linuxworks]

Quote:

Originally Posted by cetoole /img/forum/go_quote.gif I guess that was basically my point, its a great receiver, but Wolfson, in their infinite wisdom, decided to make it reliant on a uP if you want to use more than one input. I know you are a software guy, and figured you would already have some kind of processor in here for use with the remote, so put two and two together to get five.

here's the 'processor' I'll be using:

link:

TinyIR2 Learning IR remote control receiver

its a black box - no source code, of course ;(

it gives me active-high outputs and I 'take it from there'.

that's life in the integration business - you often don't have access to other internals and HAVE to view things as 'velcro integration' so to speak

 

[BrianDonegan]

nm

 

[linuxworks]

update: the proto works. it was simple, like I had hoped (planned. no, hoped, really)

just a 4052 analog switch (using half of it) with toslink opto blocks in and 1 going out.

the usual choke/cap bypass for the toslinks is there.

no reshaping at all. just real low-budget 'does it work' testing.

it seems to work. and given how good modern dacs are, I'm not 100% convinced its worth 'prettying up' the signal any more than it is now. I'm getting lock and I'm hearing sound. that's at least a good start

for testing I'm using back-to-back gamma1 dacs. one is a half build (just the usb/spdif board) and that gets me opto-out from my pc. I go into this switch and then out of it into another Y1 dac that takes opto-in spdif and makes analog sound from the other end

dial in a 2 bit binary address and the right input port is mapped to the single output.

$20 or less in parts.

perhaps I'll work this up into a proper project. I've now learned how to deal with controllers and lcd displays (and IR remotes) and so just having a remote controlled user-label display that picks digital inputs - that could be cool just on its own (?)

 

[Pricklely Peete]

Wow totally cool !!!

I love following your projects in the hopes of learning some of this stuff

On the 1 out jack how hard would it be to use a combi jack (SPDIF and Optical ?) like the one used on the Auzen Prelude SC digital output ? It would mean using a plastic adapter for Toslink out but you could use a SPDIF as normal without much or any SQ loss.

Of course it's just something that occurred to me while reading this thread that might give you some additional flexibility provided the additional circuitry can be incorporated. Maybe 1 in and 1 out using the combi jack ? I have no idea what part number that is or where to source one. It seems to do a very good job with the Auzen card. I can get a solid 24/96 signal lock via Tolsink using a plastic fiber cable NP whatsoever to the HT processor 3m away using this jack (same goes for SPDIF coax).

If this idea (is lame and) counterproductive to what you are trying to do please forgive my lack of knowledge and experience and go easy on me

Peete.

 

[Gatsu]

Grats on getting on HackaDay

Personally I've never worked with that PIC before (only worked with the PICAXE so far) but it looks like he may have given enough information to allow reverse engineering of the code.

 

[linuxworks]

Quote:

Originally Posted by Pricklely Peete /img/forum/go_quote.gif Wow totally cool !!!

thanks

Quote:

On the 1 out jack how hard would it be to use a combi jack (SPDIF and Optical ?) like the one used on the Auzen Prelude SC digital output ? It would mean using a plastic adapter for Toslink out but you could use a SPDIF as normal without much or any SQ loss.

sounds like something like this?

that's a combo opto+coax jack. tricky stuff!

if the connector is buyable, sure, why not. its only a physical layer thing - the bits are the same.

I'm thinking about how to best give flexibility in 'physical jacks' and try to decouple that from the main board design.

 

[linuxworks]

Quote:

Originally Posted by Gatsu /img/forum/go_quote.gif Grats on getting on HackaDay

that blew me away - I had no idea at all

I noticed a HUGE spike in my view-count on flickr and it wasn't until someone replied on that photo that it was on H.A.D. ha!
Quote:

Personally I've never worked with that PIC before (only worked with the PICAXE so far) but it looks like he may have given enough information to allow reverse engineering of the code.

no need to reverse engineer, the source will be coming along with schematics. first, though, some testing has to be done. it passes the 'yup, bits are flying' test but I'd like to do a bit more test equip-level testing before throwing out circuits. so far, I'm encouraged but I know the crowd here is mighty picky about their bit accuracy (lol). more testing is needed but it does look good, so far.

 

[linuxworks]

new photos of the thing being 'bits in flight' tested:

here is my first test, going across media types going from a gamma1 'lite' (usb to spdif), thru the switch and then out via opto to a full gamma1 dac.

the wiring isn't exactly to-spec (LOL!) but I'm just doing INFORMAL testing at this point. the last 2 pics show it going from coax up to TTL level (for the switch), thru the switch chip and back down to coax level (half volt) again. source was my 'popcorn hour' media streamer and sink was my m-audio superdac2496 (many years old AKM-based dac). bits flew and I heard the music just fine.

until the battery died.

and then it was jumper cables for the rest of the nite

 

[TeraHz]

Nice switch linuxworks. Do you know if the digital-analog-digital conversion affects the bit stream? That is, have you tried passing encoded audio through the switch without breaking it (like DTS or DD)?

 

[linuxworks]

Quote:

Originally Posted by TeraHz /img/forum/go_quote.gif Nice switch linuxworks. Do you know if the digital-analog-digital conversion affects the bit stream? That is, have you tried passing encoded audio through the switch without breaking it (like DTS or DD)?

it cannot affect it. not in *this* switch.

this switch does not go above the PHY (physical) layer. it does not 'unwind' packets or understand them at all. nothing is edited or changed. its just a physical repeater, not even a real bridge (in the datacomm sense).

since dts and dd5.1 don't use enormously higher data rates than normal old spdif, I'm sure they will be as bit-perfect as pcm, thru a switch like this. in fact, dts will refuse to 'run' if it gets less than bit-perfect data presented to it (same with dd5.1, I think). so if you get a signal 'lock' light, at all, you're golden.

 

[linuxworks]

I should update this thread. I think I even forgot about it

here's what I have, right now, on this spdif project:

I re-did the coax-in section. in fact, I'm making this a very modular design so you (the builder) can pick what options you want and not have stuff you didn't.

here's the coax-in 'port board' in proto form:

parts needed for it:

and there is is, being tested (it works):

that's the coax-input board (with 2 independant ports).

now the switch guts, the 'fabric' as its sometimes called:

and the initial wiring, just getting started

this is where the switching happens. this chip supports up to 8 input ports. I am going to build for 4 (the row of 4 red headers). it supports 1 ttl output which directly drives opto-out and can drive a coax-out in a similar board fashion like the coax-in board.

here's an opto port; there's little point in this having its own 'board' so I air-wire it and secure it (well) to the rear panel with a screw. much better than board mounting even though its a lot more work:

that mostly covers the switch and its i/o 'port boards' (or flying ports, in the opto case, lol).

next post has some info on the cpu controller that is made for this.

 

[linuxworks]

here's the controller photos, also using proto board (no pcb designed. yet.)

this sort of turned into a project all in itself

but from it comes a general purpose i/o (lcd, IR remote) board that I can re-use in all my other DIYs.

here's where I used it, to integrate some functions in amb's latest y2 (gamma2) dac:

 

[TeraHz]

Quote:

Originally Posted by linuxworks /img/forum/go_quote.gif this switch does not go above the PHY (physical) layer. it does not 'unwind' packets or understand them at all. nothing is edited or changed. its just a physical repeater, not even a real bridge (in the datacomm sense).

Very cool! Thanks for updating the thread as well. This is my next project (after the y2 is finished)!

 

[linuxworks]

more updates

I'm happy enough with this build

I also found a local source of opto-in parts (8mhz, old style, but they work at redbook audio rates just dandy). I may grab some extras in case people want them; when you build switches, you often need lots of parts for ports. lucky that I found some input ports since you need more of those than output ones

so, this is the main switch fabric board. you send in 2 or 3 bits of constant 0 or 1 on each of the wires and the binary-numbered input port is connected to the single output.

you don't really even need a controller. if you are ok with just having 2 switches and using binary to select the 4 states, hey, have fun, the circuit will work fine just the same

but for just a bit more work, the lcd and IR front-end can be integrated and that will select the 2 or 3 bit binary address for you, in a nice friendly way.

 

[linuxworks]

more updates

informally, it seems to work. I'll soon begin some scope level testing to see what the waveforms really look like, just out of curiousity. but for practical use, I see no reason to not use something like this. I've been using the previous version for a while, now, and I'll start using this version now that its all boxed up. I don't hear any sonic problems; it just seems to pass the bits thru unharmed.

I'll have SPDIFmaster at the bay area meet (this saturday) in case anyone local wants to come check it out