DIY A/D field recorder project

Do you plan on an internal hard-drive?

You will certainly need a microcontroller. CF is probably the easiest interface to use since there's tons of code around already for pretty much every uC out there (it also happens to be the easiest since most of the logic is in the CF module itself, writing to flash RAM is non-trivial). Other than that I don't imagine it would be too difficult, as long as you can push the data through the controller fast enough. That looks like it'd be about 700KB/s, which I don't think would be a problem for a 20MHz uC (common these days) running slim code, and it's definitely not a problem for decent flash or microdrives; you might want a few KB of SRAM as a buffer though, especially for flash.

Lots of interface issues though, how do you name files, gotta create proper headers etc.

Yeah, some sort of removable flash memory like compact flash would probably be the way to go. If you use a hard drive, you'll probably not want to remove it from the recorder on a regular basis in order to read it, so you'll need some sort of interface to your computer. This would complicate things for you. For convenience, however, a USB interface would probably be optimal anyway. You'll probably still need a microcontroller, though, because I don't see any other way of controlling the recorder's functions. You will need the uC to the status of buttons, light up LEDs, display stuff on LCD, etc. I also don't see any way to write to the flash memory without a uC. It should be at least simpler than writing to a hard drive, because I think you'll need some kind of ATA controller. Here's a couple of MP3 player projects that uses different types of flash memory:

http://web.media.mit.edu/~ladyada/make/minty/faq.html
http://www.techdesign.be/projects/020/020.htm

Have a look here (scroll down a bit for the interesting part).

http://www.prodigy-pro.com/forum/viewtopic.php?p=3876

Mikkel (mcs) is the guy who runs the electronics.dantimax.dk website (which you may know) and apparently he actually made the recorder work. If you ask him, maybe he'll share some relevant information about the project.


/U.

Has anyone successfully done this project?  I'm very interested in doing it myself, and would be very grateful for any pointers in the right direction  The link above is now dead, I'm curious if anyone knows that forum post now lies.  I have limited (read: no) microcontroller experience, but I'm a fast learner and I'd love to get my feet wet doing this sort of thing.  Thanks!

A lot of your problems are around file formats. I would think you would want to be able to pass files between the device and a computer. That would probably mean a USB stick or flash card, I'd be thinking SDHC rather than compact flash. So you probably want to be able to create and manipulate a FAT32 directory structure. A uproc, maybe with onboard program, like a PIC, could probably handle this. It can also deal with the A/D configuration.

 

Then there's the question of a User Interface. How are you going to name files? You could have an auto-incrementing numbered system, like a digital camera, I guess. So, one button, push to start recording, push to stop recording. What about monitoring and recording levels? You can have auto, but it's never very satisfactory, it hunts or pumps when you least expect or want it. So I guess a couple of bargraph displays, a volume control and a headphone socket. 

 

Then there's laying out the analogue front end. This is going to be critical to the performance, and of course you want to be able to keep the digital noise out of the analog bits.

 

Then there's buffering and shuffling. Some SRAM is probably the easiest way of dealing with the buffering, it's simple to implement and fast. I'd probably use a CPLD to manage the buffers (2 or more), you write to one, when it's full you write to the next and unload the fulll one to the flash memory. You can make the buffer match the flash block size. If you read it out to the flash at twice the sample rate you'll have plenty of time to manage the flash write procedure, SDHC cards are fast enough to swallow HD video so some audio channels should be OK. A CPLD will allow the construction of a simple finite state machine counting memory addresses and rolling over from memory chip to memory chip. The simplicity and regularity of the CPLD will simplify the problems with the last issue, the clock.

 

The clock.obviously requires an intrinsic low jitter and the distribution and usage should not introduce further problems. One of the areas contributing potential problems to the clock is the design of the power supply.

 

In the tradition (short) of digital cameras, most people will want to be able to play back the recording on the same device, that'll add a button or two, how are you going to select which recording to play back?

 

w

hmm first problem to get past is the DXD license is it not? i get the feeling wordsandsigns hasnt really thought this through past the fact he/she wants one and perhaps doesnt have the money to buy it. DIY is always cheaper right? you know its actually not going to be cheaper to build it as a one off without the economy of scale; you know that right?

 

even without factoring your time this will cost you considerably more than just buying a MR-1 (which is now an outdated model) on the cheap off ebay. fast learner or not there is a myriad of highly technical disciplines and technologies at work here, by the time you learn it all DXD will be a dead format.

 

without putting words in his mouth, i think this is probably what wakibaki is saying, but by way if giving you just a small partial outline of the process and seeing what you say? he actually has maybe got the skillset to do this, maybe. and he would be one of the more savvy users on this board. Hes certainly far closer than I am and i doubt very much he would take it on, I sure wouldnt.

 

sorry wakibaki if thats not what you were doing, i know you are actually a very helpful person, ive seen that so i'm not saying you are playing games

Edited by qusp - 11/24/11 at 6:26pm

No, not at all qusp, that's a fair summation. It didn't occur to me that it might be thought that I was playing games, I'm not. It didn't occur to me about the licensing business either, I just set out to outline some of the requirements to build such a device, and I did imagine that that might be a bit of an eye-opener, but I didn't just want to be a wet blanket. What I've laid out is a not-unreasonable rough sketch, although it's not uncommon for such to require modification as the details are filled in.

 

It's not that different from something I proposed building a few years ago, a fully solid-state uncompressed PCM playback device, which at the time didn't exist, and which I conceived as a 'blameless' (minimal jitter) player.

 

Not many people expressed an interest, and since I don't feel that jitter is as big a problem as many other people do, I wasn't driven to build one. Even when you know how to do it in outline, there's always a lot of work in the detailed implementation. Probably weeks of full-time work in this case, even without documentation.

 

 

w