Interest for advanced digital audio?

GroupDIY Audio Forum

Help Support GroupDIY Audio Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

DannyW

Member
Joined
Jul 27, 2013
Messages
12
Hi!

Someone emailed me about this website, and it looks great! Always happy to see people building equipment they can use! I have been in to digital audio for some time now, and am mainly working with FPGA's to implement interfaces to various digital protocols like MADI, ADAT, SPDIF and others. I have a few of my designs at www.opencores.org, and have some tech stuff up on www.ackspace.nl, the hackerspace of my choice.

Some time ago I made a MADI FPGA core with help of an ethernet transceiver, and since last year it is commercially available in the Antelope Audio Orion 32. I am currently looking for other means of building some cool stuff with a bunch of guys (or girls?). The kits I want to make are not the easiest by far, but it is well worth building. For a start, I want to make a small converter for a bidirectional ADAT to SPDIF.

To see what I mean, this is some of my work in progress:

A closeup of the PCB design, it is double sided and intended for a 100x80mm enclosure.


This is the backside of the PCB design, and you can see that the front and back of the enclosure will be produced by the PCB manufacturer. This way I can put LEDs in the front in convient places. Also, with a smooth look, it will show as a professional device, and you can say you made it yourself! The final PCB will be in black for this reason.

I intend to release this project in 3 possible ways: a bare PCB, the PCB with all finepitch components and programmed flash memory, and as a complete device. I really want to sell just bare PCB's, so prepared to pay A LOT MORE for partially or fully assembled ones. I want to encourage the DIY spirit, so to say.

Leave a message if you want to show your interest!
 
DannyW said:
Some time ago I made a MADI FPGA core with help of an ethernet transceiver ..

You can do MADI entirely in the FPGA. Takes a bit of thought, the hardest thing being the gearbox from the 125 MHz domain to the 100 MHz and back. But certainly possible :)

-a
 
I used the Ethernet controller mainly for clock recovery. The 125MHz that is available inside the FPGA is not the same as the 125MHz of the incoming datastream. You can not use the internal clock for receiving an external stream. There is a number of solutions for this: One being oversampling. In that case the needed frequency for the design will overstretch the budget. The other way is by using a PLL to lock on to the stream. As dedicated Clock and Data Recovery (CDR) chips are expensive, an alternative is used. SSL uses an Ethernet controller as well, and RME uses an ancient Cypress HOTlink chip which does all the heavy lifting. The rest of the Ethernet chip is bypassed. That is the reason you can not use just any Ethernet chip, because not all of the can be bypassed that much. I never heard of an FPGA-only design for MADI, and for the longest time I also thought that it could be done in FPGA alone. I am very curious about your design, Andy!
 
DannyW said:
I am very curious about your design, Andy!

It's actually based on something we did to replace a TAXI protocol chip in a system that uses a 100 Mbit fiber interface.  It takes advantage of the input DDR flops and the clock manager in Xilinx Spartan-3AN parts, and I'm sure it could be ported to other vendors' devices.

Your DCM gives you a local 125 MHz clock and that clock phase shifted 90 degrees. With those two clocks and the input DDR flop you can sample the incoming signal on four phases of the 125 MHz clock. You use a few flops to resynchronize those four samples onto the the rising-edge 125 MHz in-phase domain, and then you look for which of the four signals transitions "first." The idea is that you want to sample in the middle of the bit time, so you choose the phase opposite of the one where you saw that "first" transition. Some additional logic is provided to handle what happens if the source clock is slightly slower or faster than the local clock. In that case, the bit transition can "wander" into the next or previous bit.

Once you have your bit, you undo the NRZI coding and push it into a 10-bit shift register. The MADI sync character is a unique 10-bit value JK, so you do a simple bit-slip process and monitor the parallel word looking for that sync. Once you get it, you set up something that generates a clock enable every 10 bits which lines up with the parallel bits in the right positions. In parallel with the sync detect, you also do 5B/4B decoding on the two received nybbles. In the simple case you get a flag indicating you've decoded two data nybbles and you can write them to a gearbox FIFO which is read in the 100 MHz domain. (Or you could dispense with the gearbox entirely and stay on the 125 MHz domain, if your application will let you do so.)

If you're using the non-data commas as a side-band communication path, you capture the comma and process it as you require. For example, if you're doing MIDI over MADI (or more generally, UART over MADI), you can use two of the commas, one to indicate line transitioned high, and the other to indicate transition low. MIDI at 31.25 kbps is slow enough for this to work.

OK, so now you've got bytes. You have to start monitoring them, looking for the frame sync. The good news is that the JK symbol is inserted at a channel boundary, and the first byte you get after it will include the frame-sync and channel-active bits so you can figure out where your first channel starts.

If you're going into a processor, you probably put the data into a DMA buffer and you're done. You don't care about clock recovery. If you're splitting the channels out to some ADAT transmitters (as your OpenCores project does), the same applies.

If you're doing a multi-channel DAC, then yes, you need to deal with audio clock recovery. The AES10 spec requires an external word clock, but it seems like some MADI implementations don't bother with it. Section 6.2 of the MADI spec says, "The link is not intended to carry sample timing information."

But since you know that your first channel of a frame always starts on a sample-time boundary (it has to, if you think about it), then you can fire a blip to a PLL which can give you a modulator clock frequency, which you can then feed to the DACs and also divide down and get the I2S or I28 or whatever else you need for the converter serial data interface.

OK, so that was a little bit longer than I thought it would be. I think you'll get the gist.

-a

PS: I suppose that you could use the 10-bit high-speed deserializer in one of the Virtex-4 (pricey) or say, Artix-7 (not available yet in the smallest packages), parts, and that would greatly simplify everything.
 
VERY interesting.
Danny, i tried to build your ADAT MADI converter from the webklik.nl website.
Would you give some support for that project here or via PM?

Thanks, Dirk
 
Even though this thread burst right into low level implementation stratosphere with Andy Peters' nybbles, I am curious on the end-user clocking set up of the bidirectional ADAT to SPDIF proposed/announced on this thread. What options are given to the end user, and how are they implemented?
 
Kingston said:
Even though this thread burst right into low level implementation stratosphere with Andy Peters' nybbles, I am curious on the end-user clocking set up of the bidirectional ADAT to SPDIF proposed/announced on this thread. What options are given to the end user, and how are they implemented?

From what I could gather from the opencores project, Danny used a Cirrus CS2100 clock generator chip to create a clock for the ADAT-format stuff from a word clock recovered from the MADI receive stream. There's the issue of crossing from the 125 MHz domain (the Ethernet chip's local bus side) to that domain, but a simple FIFO suffices.

BTW, that project is here. The VHDL source is fairly straightforward.

-a
 
I got the PCB's in, see the pictures:

20130818_200940_zps36e37c59.jpg


20130818_200927_zpse00bc7bf.jpg


I also made a start of the assembly of one:

20130818_200712_zps682be463.jpg


There are still some components missing, but I programmed the FPGA already and it is looking good. The LVTTL level of all output signals are up to spec.
 
Kingston said:
Even though this thread burst right into low level implementation stratosphere with Andy Peters' nybbles, I am curious on the end-user clocking set up of the bidirectional ADAT to SPDIF proposed/announced on this thread. What options are given to the end user, and how are they implemented?

I thought about this:

Clock Priority:
1 - Wordclock. If you present a workclock, every output works from this wordclock.
2 - Adat. If you input an Adat signal, with no wordclock, the system derives the wordclock from the Adat signal.
3 - SP-DIF. If no wordclock is connected, and no Adat input is available, one of the connected SP-DIF is used for wordclock generation.
4 - If all of the above fails, you have no inputs connected. A failsafe internal clock is generated.

Furthermore:

If you use S-MUX for Adat, the SP-DIF outputs 3 and 4 will be a copy of 1 and 2. Only 4 channels can be on the Adat at 96K.
If you connect wordclock, you are obviously using this as a professional device. The SP-DIF protocol will change to AES-EBU format.
At 96K, SP-DIF input 3 and 4 ( for channels 5 through 8 ) are ignored.
 
Hereby a full BOM for the SP/DIF - ADAT converter:

Unless otherwise noted: All resistors SMD0805 size, +/-1%. All capacitors SMD0805 size, +/-20%.

R1 100R
R2 75R
R3 75R
R4 220R
R5 100R
R6 75R
R7 75R
R8 220R
R9 100R
R10 75R
R11 75R
R12 220R
R13 100R
R14 75R
R15 75R
R16 220R
R17 4R7
R18 4R7
R19 3K3
R20 47K
R21 1K6
R22 33R
R23 1K
R24 100R
R25 47R
R26 82R
R27 1K
R28 150R
R29 150R
R30 150R
R31 10K
R32 10K
R33 10K
R34 1K
R35 1K
R36 1K
R37 1K
R38 10K
R39 10K
R40 470R
R41 470R
R42 470R
R43 470R
R44 10K
R45 10K
R46 10K
R47 10K
R48 470R
R49 470R
R50 470R
R51 470R
R52 10K
R53 10K
R54 10K
R55 10K
R56 470R
R57 470R
R58 470R
R59 470R
R60 10K
R61 10K
R62 10K
R63 10K

C1 100nF
C2 100nF
C3 100nF
C3 100nF
C4 100nF
C5 100nF
C6 100nF
C7 100nF
C8 100nF
C9 100nF
C10 100nF
C11 10nF
C12 1uF
C13 100nF
C14 100nF
C15 100pF
C16 1uF
C17 100nF
C18 47uF/50V SMD elco 10x10mm
C19 220uF/16V SMD elco 8x8mm
C20 100uF/16V SMD elco 6.3x6.3mm
C21 100uF/16V SMD elco 6.3x6.3mm
C22 100uF/16V SMD elco 6.3x6.3mm
C23 10nF
C24 10nF
C25 100nF
C26 100nF
C27 10nF
C28 100nF
C29 10nF
C30 100nF
C31 100nF
C32 100nF
C33 100nF
C34 100nF
C35 100nF
C36 100nF
C37 10nF
C38 10nF
C39 10nF
C40 10nF
C41 10nF
C42 10nF
C43 10uF
C44 100nF
C45 100nF
C46 10nF
C47 10nF

L1 100uH 2.1A 10x10mm
L2 Ferrite bead 0805
L3 Ferrite bead 0805

D1 BAT54S SOT23
D2 BAT54S SOT23
D3 BAT54S SOT23
D4 BAT54S SOT23
D5 BAT54S SOT23
D6 BAT54S SOT23
D7 SK56 SMC
D8 SK56 SMC
D9 1206 LED reverse mounting
D10 1206 LED reverse mounting
D11 1206 LED reverse mounting
D12 1206 LED reverse mounting
D13 1206 LED reverse mounting
D14 1206 LED reverse mounting
D15 1206 LED reverse mounting
D16 1206 LED reverse mounting
D17 1206 LED reverse mounting
D18 1206 LED reverse mounting
D19 1206 LED reverse mounting
D20 1206 LED reverse mounting

Q1 BC847 SOT23
Q2 BC847 SOT23
Q3 BC847 SOT23
Q4 BC847 SOT23
Q5 BC847 SOT23
Q6 BC847 SOT23
Q7 BC847 SOT23
Q8 BC847 SOT23
Q9 BC847 SOT23
Q10 BC847 SOT23
Q11 BC847 SOT23
Q12 BC847 SOT23

X1 Crystal oscillator 25MHz 5x7mm

U1 74HC04 SO16
U2 74AHCT04 SO16
U3 TLC2932A TSSOP14
U4 DS90LV018 SO8
U5 74AHCT541 SOW20
U6 LM2576S-5.0 TO263
U7 LM1117-3.3 SOT223 or eq.
U8 LM1117-1.2 SOT223 or eq.
U9 EP2C5T144C8 TQFP144
U10 EPCS4 or M25P40 SO(w)8

T1 DA101C
T2 DA101C
T3 DA101C
T4 DA101C
T5 DA101C
T6 DA101C
T7 DA101C
T8 DA101C

J1 Cinch RCA PCB connector
J2 Cinch RCA PCB connector
J3 Cinch RCA PCB connector
J4 Cinch RCA PCB connector
J5 Cinch RCA PCB connector
J6 Cinch RCA PCB connector
J7 Cinch RCA PCB connector
J8 Cinch RCA PCB connector
J9 DC power inlet 6.5mm/2.1mm
J10 2x5 2.54mm pinheader
J11 GP1FAV31RK0F
J12 GP1FAV31TK0F

P3 BNC connector PCB 8.15mm height
P4 BNC connector PCB 8.15mm height
P6 2x10 2.54mm pinheader (optional)

F1 Polyfuse 200mA 5.08mm pitch
S1 TL36WW150 switch APEM

SnD Kain PCB
MCREBS80 enclosure
 
Assembly of the front PCB part. The reverse mount LEDs are going here. You can choose your own colorscheme, but I've chosen for green for the lower (signal) leds, and amber for the top (Wordclock) leds.

20130820_185235_zpsb373a2e2.jpg


This is how the current state of the prototype is. Still waiting for the RCA connectors and the power switch.

20130820_185317_zps495da4aa.jpg


An impression of the enclosure.

20130820_185454_zps5ca9ad10.jpg
 
A modification - I forgot to AC couple my SPDIF output transformers. A minor oversight, but large performance impact. I'll ship out any bare PCB's with this modification in place, so you don't have to worry about it.
 
Image update:

20130824_101514_zps77bac43c.jpg


20130824_101947_zps8984391b.jpg


20130824_102008_zps5e706509.jpg


I'm now in the process of making all of the functions work, with writing some VHDL code.
 
Which rear-mount LEDs are you using?  I've always been interested in those for indicators on capacitive touch panels but never tried any.
 
I used the Avago HSMx-C265, but I know other companies like Kingbright make reverse mount LEDs as well.
 
Back
Top