MicroSD Memory Card Transport Project

No, the 24.5760MHz Neutron Star clock is only supplying the SDtransport192 with a clock signal - the Buffalo is still my "old" Buffalo32S with its stock clock, no mods here. Will go ackoDAC soon, not sure yet which clock I will use with it (probably another Neutron Star) but I don't think it'll be synchronous clock mode, 24.5760MHz looks a bit too low for me even for an ESS9022.
 
No, the 24.5760MHz Neutron Star clock is only supplying the SDtransport192 with a clock signal - the Buffalo is still my "old" Buffalo32S with its stock clock, no mods here. Will go ackoDAC soon, not sure yet which clock I will use with it (probably another Neutron Star) but I don't think it'll be synchronous clock mode, 24.5760MHz looks a bit too low for me even for an ESS9022.

No Bertel, it's not too slow - try it with what you have, you might be surprised ;)
 
I will let Bunpei report regarding clock frequencies which are the two fixed frequencies used in the SDTrans192 as per its design by Chiaki. (I think you will find these elsewhere in the thread.) We did not look at the correlation between low freq phase noise vs. sound, and I am not aware of whether we have such data available. (Again I would prefer if Bunpei reply to such questions.):)

SDTrans192 use two master clocks, 22.5792 MHz and 24.576 MHz.
Except NDK oscillators, we have no phase noise measurement data. However, I believe a low phase noise clock brings more accurate sounds.
 
I have removed both oscillators from the SDtransport192's PCB and now inject a 24.5760MHz clock signal (I upsample all files to 32bit/192kHz, best results in combination with my Buffalo) from my D-Labs Neutron star (the best clock I know of, NewClassD Neutron Star). I can confirm Bunpei's and elecon's findings - quite a deal more detail and transparency while at the same time the tonal balance and warmth has become much more "right" and life-like. Clock upgrade definitely recommended! :up:

I'm not sure I understand. The two oscillators you removed had different frequencies. Did you now substitute both of them with the same Neutron Star clock (i.e. hooked up in parallell)? Am I missing something?

Kurt
 
I'm not sure I understand. The two oscillators you removed had different frequencies. Did you now substitute both of them with the same Neutron Star clock (i.e. hooked up in parallell)?

Hi Kurt,

I have removed both oscillators but have substituted only the 24.5760MHz one by now directly injecting the clock signal from my 24.5760MHz Neutron Star clock. For the time being I am not providing a 22.5792MHz clock signal because I don't need it, I upsample everything to 32bit/192kHz, out of all possible combinations of bit rate and sampling rate I had tried this gives me the best results in my setup. (The 24.5760MHz clock signal is for 48/96/192kHz while the 22.5792MHz clock signal serves 44.1/88.2/352.8 DXD) Should I change my mind at some point in time and e.g. go DXD I can always hook up a 22.5792MHz clock signal (another Neutron star with this frequency then, or an NDK solution, or something else) externally, no problem.

Best,
Robert
 
Last edited:
So you think it's sonically better to upgrade the SDTrans clock rather than the Buffalo clock (supposing you would use a Neutron Star for only one of the two)?

Kurt,

I haven't touched the clock of my "old" Buffalo32S yet and won't do so because I am in the process of deciding to go either Buffalo II or ackoDAC anyway. Until very recently I had planned to equip SDtransport192 and DAC independently with separate clocks (Neutron Star with 24.5760MHz for SDtransport192, some other high quality clock, probably also a Neutron Star, at 100MHz for ESS9018-based DAC, since from the specs and data I had understood that the ESS chips don't need to be slaved to the transport's clock but are designed to work best totally independent with their own clock at a much higher frequency of 80-100MHz). As jkeny has mentioned above too, I have only recently learnt that synchronously clocking both SDtransport192 and ESS90XX-based DAC is possible and might be beneficial. I have not further looked into that yet but need to do so in order to take the decision on which DAC to use and how to set it up.

So I can't judge what is sonically better, upgrading only the SDtransport192 clock or upgrading the Buffalo clock - personally my strong believe is that either of them should have the best possible clock.

Best,
Robert
 
Last edited:
Dear RayCTech,

thank you for the tip! I am kinda analphabetic when it come to remote control design solutions ;)

Yes, please hook one up and test it out. Would be much appreciated! Maybe you could take a photo of the setup that shows how you wired it.

I have a few remote controls from QLS Hifi that I used to use for the QA550

Regards,

The remote control of/for the SDTrans are up and running..

Works great!

As the outputs from the TinyIR2 are low and pulses high a inverter to make a high that pulses low are needed.
I used the four small inverters seen in the picture.
A resistor will also need to be added in series to allow the buttons to work.
I used a JFET LU1014D as regulator at 3.6 volt (I run the SDTrans at 3.6 volts) - the standard regulator for the TinyIR2 cannot be used as it is 5 volt. A 3.3 volt regulator are needed to work with a standard SDTrans192.
I can post more information with component values and the configuration of the TinyIR2..
 

Attachments

  • DSCN2769.jpg
    DSCN2769.jpg
    448 KB · Views: 787
The remote control of/for the SDTrans using the TinyIR2 are configured with D2, D3 and D5, and uses outputs 4, 5, 6 and 7.

Connect the outputs via a series resistor (I will check value) to the buttons as shown on the picture. Hit the learn button on the TinyIR2 and program outputs 4, 5, 6 and 7 with the remote (buttons) you want.

Remember: Use a 3.3 volt regulator and inverters between the TinyIR2 outputs and the series resistors..
 
Last edited:
Dear Raytech:

I am very happy that you spent all this time and got it working:) Much appreciated!

Please post more info on component values and the config of the TinyIR2.


Regards,

I have not used much time on this, but due to I myself controls the SDTrans directly from the uP that controls the DAC I needed to find some spare time..
I will post all info regarding this simple remote control of the SDTrans as soon as I have some time for it...
 
It has been a week since I received my SD Trans from Bunpei. I am running I2S feeding a Buffalo II. I listened briefly to the supplied pre loaded card with different hi rez formats, but have spent the bulk of my listening time going through familiar material ripped from EAC > 44.1k/16 bit. The sound stage is spacious even in my smallish room, but the real news is the accurate reproduction of instruments and vocals, the overall presentation of music is outstanding. The way each piece of the music sits in it’s own space is extraordinary . So far, all that I’ve thrown at it is reproduced in a relaxed and balanced manner. I listen to a lot of pop and it does an excellent job separating busy, compressed, passages found with many of these songs.

Granted some source components I used in the past needed an upgrade, but I’d bet money the SD Trans will stand up to anybody’s anything digital source.

Sd Trans> Buffalo II with lots of Placids> mono block F5’s> Eben X-Centric = sonic bliss. I finally really like my system.

Thank you Bunpei and Chiaki for bringing this awesome piece to DIYA. I will be anxious to try the NDK oscillators you recommended.
 
A few silly questions perhaps from a digital idiot :

Is it not true that we can use similar method to access a Hard Disk Drive as to access an SD card ?
If yes, is it not at least possible in theory that we can use this to play whatever format of music from a hard disk ?
Do we have to compromise on performance (such as jitter) because of the size of the storage ?


Patrick
 
Is it not true that we can use similar method to access a Hard Disk Drive as to access an SD card ?
I think it's a good and tough question.

Unfortunately, my answer is "NOT TRUE".

As you may know generally , or in this specific case of SDTrans192, a simple serial "SPI interface" is employed for a read-out of WAV PCM data from a SD/SDHC memory card. As far as Chiaki and Bunpei know, there is no hard disk drive that supports SPI interface. (Neither, an external converter that gives an IDE/SATA drives an appearance of SPI interface.)
 
Among the links Patrick showed, the only

MAX3421E USB Peripheral/Host Controller with SPI Interface

seems theoretically feasible.
However, I am not willing to try this because the transfer rate in USB is limited (12 Mbps) and vast amount of commands for controlling the USB side might be essential. Please ask Koon his comments.