Hey mcs, what happened to your DIY HD rec'cer?

GroupDIY Audio Forum

Help Support GroupDIY Audio Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Littlebush deleted the thread! :sad:

You have been away for a while, so you probably haven't been following the project status. I guess you remember I had a big problem. Some times the recordings I made sounded like white noise. The reason was/is that the date in one byte sometimes got scrambled. It happened in the MSB, so the errors were very noticeable... I changed the byteorder (it was wrong anyway), so the problem moved to the LSB. Now the recordings always sounded like music, but sometimes acompanied by a little background hiss. Then I didn't really get any further for some time.

But I did make some more parts. A new 24 bit/96kHz A/D converter and a control panel complete with LCD peakmeter (and a remote control option of course :green:). I also did some work on the software, so I now have a filesystem on the drive.

Then tonight after I saw your post I fealt like doing a bit of work. I have tried a lot of things to solve the noise problem, but without any luck. But all the changes I made were at the "audio" part of the circuit (where the audio data get's written to the FIFOs). But what if the problem was in the "drive" part (from FIFO to drive)?

I decided to try a Tim Taylor solution (more power :wink:), so I replaced the original Siemens C501 CPU (or MCU actually) with a Winbond W77C32, which is almost 3 times as fast. This would change the bus timing, so I thought it would probably either make the problem worse or change nothing...

But the first test recording I have made sounds noice free! This may be luck of course - I'll make some more recordings tomorrow. Could this have been caused by a slightly faulty controller? Who knows...

Best regards,

Mikkel C. Simonsen
 
This is great news! You're a rocket scientist :thumb:

I'm really keen on this project. Do you have any (new) pics?

Great stuff Mikkel :grin:
 
indeed, great to see this project continuing to evolve :) what new adc chip are u using now then? I'm still yet to test a PCM1804/OPA1632 design I've eagle'd but a good DAC is higher priority really...was thinking of the new PCM4104 which is a 4chan dac (i need plenty of chans ;p) with possible transformer balanced outs...

a fella called Pilo (think he posted a cpl time in the last arena) who is the brains behind most of this project is also playing with a PLL/PIC control board but I know he's been having a few rubs of chin with regards to the SPI n whatnot...mebbe u have a better solution?

All aiming towards a v tasty DIY multi-chan adc/dac/adat box with a modular architecture for the adc and dacs (mebbe have them as SIMMs which plug into a main buss brd?)

Nice
 
[quote author="daArry"]indeed, great to see this project continuing to evolve :) what new adc chip are u using now then?[/quote]
AD1871 (I did post schematics and pics at the "other place"). It can be cascaded for up to 8 channels.

a fella called Pilo (think he posted a cpl time in the last arena) who is the brains behind most of this project is also playing with a PLL/PIC control board but I know he's been having a few rubs of chin with regards to the SPI n whatnot...mebbe u have a better solution?
A better solution for what? I am also using the SPI ports of the chips I use, and I don't have any problems (yet).

All aiming towards a v tasty DIY multi-chan adc/dac/adat box with a modular architecture for the adc and dacs (mebbe have them as SIMMs which plug into a main buss brd?)
The stuff I'm making is quite modular... I'm not sure the SIMM idea is good. In a system like that you have to decide what signals should be present on the bus in advance. Then later you may need different signals for something, so you need extra cables as well as the buss. The way I do it (cables) may look less nice, but it's very flexible...

Best regards,

Mikkel C. Simonsen
 
[quote author="sismofyt"]Do you have any (new) pics?[/quote]
New to you probably - others may have seen them.

Here's the new ADC:
ADCon2_small.jpg


The control panel:
HDRPan2_small.jpg


And some old pics. The main board:
hdrec.jpg


And the old ADC:
a-d-conv.jpg


Best regards,

Mikkel C. Simonsen
 
I did post schematics and pics at the "other place"

Ah yes, I remember now after seeing the pic...

A better solution for what? I am also using the SPI ports

I meant maybe u could help with his issue with the SPI...was late, wording cudda been better....just wanna get this project wrapped up and I'm sure - with all the talent around - a great thing can be done :wink:

The way I do it (cables) may look less nice, but it's very flexible...

Yup, ur right :)
 
Hi!
Well, I didn't read/post on a lot on RIP TT, but your recorder was one of thread I followed ;)

The stuff I'm making is quite modular... I'm not sure
the SIMM idea is good. In a system like that you have to decide what signals should be present on the bus in advance. Then later you may need different signals for something, so you need extra cables as well as the buss. The way I do it (cables) may look less nice, but it's very flexible...

Well... first I didn't think about a bus... the problem is that we want a modular design, at least for adc and dac stuff (adc can be replaced AES/spdif transmiter, and ADC maybe by receiver, but there are clock issue to take care about there). And I first think of using alesis only chip, so al1402 and al1401 for adat, al1101 for adc, and didn't think about dac... the problem is that those adc chip only need a wdclk to work, but usually other adc need a master clock and bit clock... same for adat chip. The big problem to keep things modular is to have every signal avalaible somewhere, and this is what I first though and did... actually, this wasn't modular at all : sync problem first, and then how to keep enough wire for everything?
There come the idea of the bus... but digital audio only bus, for adc and dac (adat and clock are providing and taking signal from the bus, but not connected to them like the adc and dac). I'm not going to use dimm socket for first use but a standard 2x20 pinhead.

The bus connector also provide psu.

tell me what you think about it, nothing etch by now, so I can still change stuff :) and I would be very happy to have your opinion.

next the spi...

better solution for what? I am also using the SPI ports of the chips I use, and I don't have any problems (yet).

so... clock chip (pll1700, or another of the same kind), dac, maybe adc, pga (vol control), and maybe other device are working in SPI mode. Easy to handle it on software side. The problem is that some chip can't be chained... like adc and clock... so the idea is to have 4 "standard" spi signal (din, dout, ck, and cs) and some adress line (I think 4). so the cs signal for a chip is a logic "and" between cs and an adress decoder chip. My problem was where to put adress decoding stuff? on the core/clock pcb, or on module (adc, pga, dac) pcb...
I choosed the second solution... but this make things harder to connect an already designed dac with a spi interface to it, as it will need the decoding hardware... I'm still wondering what's the best;

I want to keep things doable by, almost, anyone... so putting one connector per module on a pcb is too much drill. So if each module use exactly the same signal, then there's no problem, I didn't choose 2x20 for nothing, it's the sze of standard IDE cable ;)

well tell me what you think about, because this is really making me mad!!!

oh another question, on the bus connector, do I have to separate each audio signal (clock, and data) by gnd?


thank you!

Pilo
 
[quote author="pilo"]There come the idea of the bus... but digital audio only bus, for adc and dac (adat and clock are providing and taking signal from the bus, but not connected to them like the adc and dac). I'm not going to use dimm socket for first use but a standard 2x20 pinhead.

The bus connector also provide psu.

tell me what you think about it, nothing etch by now, so I can still change stuff :) and I would be very happy to have your opinion.[/quote]
Currently I just use 10-pin headers for most signals. I have one for the SPI port and one for the audio signals so far. I keep the clocks seperate (I don't use a dedicated clock circuit yet). I guess some would say you should use coax for the clock?

I don't think SIMM or DIMM sockets are a good idea. You need high precision PCBs to fit the sockets, and you also need weird cutouts which is expensive. A 2*20 header sounds like a better/cheaper/easier to DIY solution to me.

next the spi...

so... clock chip (pll1700, or another of the same kind), dac, maybe adc, pga (vol control), and maybe other device are working in SPI mode. Easy to handle it on software side. The problem is that some chip can't be chained... like adc and clock... so the idea is to have 4 "standard" spi signal (din, dout, ck, and cs) and some adress line (I think 4). so the cs signal for a chip is a logic "and" between cs and an adress decoder chip. My problem was where to put adress decoding stuff? on the core/clock pcb, or on module (adc, pga, dac) pcb...
I choosed the second solution... but this make things harder to connect an already designed dac with a spi interface to it, as it will need the decoding hardware... I'm still wondering what's the best;
As you can see on the photo above my control board includes 5 SPI ports. In, out and clock are paralleled, and I simply use a seperate pin on the MCU for each SPI port. Why make it more complicated? MCUs with a lot of I/Os are easy to get. I can just upgrade from the current chip I use (with 32 I/Os) to a chip with 48 or 64 I/Os if I run out of pins...

I would never add address decoding to the individual modules. If someone decides to buy an evaluation board and use that with your system, that board will often have an SPI port. So you would have to add an address decoder yourself before connecting the board - and I don't think that's very user friendly ;)

You would have the same problem is somebody decided to use my ADC (which has a plain SPI port on a 10-pin header), or if somebody builds a board using the schematic in the datasheet.

I want to keep things doable by, almost, anyone... so putting one connector per module on a pcb is too much drill. So if each module use exactly the same signal, then there's no problem, I didn't choose 2x20 for nothing, it's the sze of standard IDE cable ;)

well tell me what you think about, because this is really making me mad!!!
I would put a connector per. module on the main board. The people in Bulgaria that make my boards don't seem to mind drilling a lot of holes ;)

With seperate connectors you could also add buffering to the signals, to keep the modules from messing up each others signal. You could place buffers on the individual modules, but then you have a problem with "foreign" modules again...

oh another question, on the bus connector, do I have to separate each audio signal (clock, and data) by gnd?
Yes! One row of your 40-pin connectors should be ground.

Best regards,

Mikkel C. Simonsen
 
I haven't posted any updates to this for a long time...

Yesterday I decided to get all the boards connected, to see if it would work as a whole. This is the result: :green:
HDRBoard.jpg


The only new boards are the powersupply and clock:

PSU.jpg
Clock.jpg


And it does work - sort of. The powersupply works fine, but I think it's a bit weak. The ADC locks up when it runs on that powersupply - if I use a larger powersupply it doesn't (always). I think I need to keep the ADC in reset untill the voltage has stabilized.

The clock does generate a clock signal (thanks for the xtal daArry!). But it doesn't really care what frequency I tell it to generate - it stays at 48kHz (the default). I think this may be a reset/timing issue also.

Best regards,

Mikkel C. Simonsen
 
:thumb:

was worth it just to see the results so far!!

so, u thinking of makin this lot portable then? Be ideal for mobile recording :green:
 
What's more portable than a big, heavy, piece of wood? :green:

Best regards,

Mikkel C. Simonsen
 
guess u could stick some wheels on :wink:

then again tho, I'm sure u could avr, atmel or relay it to walk itself! :green:
 

Latest posts

Back
Top