My quote from Magic Crystal was two years ago for 22 and 24 MHz. It was a good value but did not fit the price requirements for the product I was working on.
At 400 Euros they are quite pricy but few options that will fit that footprint with that performance. If a larger package is acceptable there are other options.
At 400 Euros they are quite pricy but few options that will fit that footprint with that performance. If a larger package is acceptable there are other options.
The specs seems to be similar to CCHD-957, only double frequency
... but the price ... ouch!Buffalo IIISE with Ian's FIFO and Luckit WaveIO
Just finished my DAC. As Luckit WaveIO supports two simultaneous outputs, SPDIF and I²S, and Buffalo DAC supports to switch between two inputs, also SPDIF and I²S, I managed to be able to switch between Buffalo onboard Clock CCHD950 (and SPDIF) - and Ian's FIFO Clock CCHD957 (and I²S). Interesting comparison! Furthermore I realized to switch onboard clock between mains/ shunt regulator supply - and battery LiFePO4 supply, indeed an improvement with the latter. FIFO dual XO board is always fed with battery LiFePO4.
Just finished my DAC. As Luckit WaveIO supports two simultaneous outputs, SPDIF and I²S, and Buffalo DAC supports to switch between two inputs, also SPDIF and I²S, I managed to be able to switch between Buffalo onboard Clock CCHD950 (and SPDIF) - and Ian's FIFO Clock CCHD957 (and I²S). Interesting comparison! Furthermore I realized to switch onboard clock between mains/ shunt regulator supply - and battery LiFePO4 supply, indeed an improvement with the latter. FIFO dual XO board is always fed with battery LiFePO4.
Attachments
Hi Ian,
Just rationalising the number of controllers I'm using and what not. With the idea that driving the FIFO from an arm raspberry pi/beaglebone ... it would make sense to control the si570 from the same device.
Now I'm going to try writing the application in python first (will be re-using some other code I've already half-written for controlling Denon AVR). But just so that I get an idea of the timing involved.
100ms gives time for:
1. command send from si570 - 70bits = 8ms
2. processing time at controller - ??
3. command send from controller - 70bits = 8ms
So I've got ~75-80ms in the computer to decide what to do then reply, does that sound right?
So, if my experiments in python don't work out with my beaglebone I have the option of using one of it's on-chip RISC co-processors that are intended for realtime industrial comms and programming it in assembly but ... there's a learning curve to that for me and it would be hugely overkill if the python option gets the job done in time without too many hacks. Also that's beaglebone specific so won't help anyone who isn't using an AM355x processor, ie RPi and similar. Alternatively it could easily be done in C++ but again, I've got little experience there so would need to learn a bit first.
Hopefully I've got some code to share next week
I'll write something for Arduino at some point but little motivation for me at the moment because I doubt I'll use that for myself.
Hi Ian,
Just rationalising the number of controllers I'm using and what not. With the idea that driving the FIFO from an arm raspberry pi/beaglebone ... it would make sense to control the si570 from the same device.
Now I'm going to try writing the application in python first (will be re-using some other code I've already half-written for controlling Denon AVR). But just so that I get an idea of the timing involved.
100ms gives time for:
1. command send from si570 - 70bits = 8ms
2. processing time at controller - ??
3. command send from controller - 70bits = 8ms
So I've got ~75-80ms in the computer to decide what to do then reply, does that sound right?
So, if my experiments in python don't work out with my beaglebone I have the option of using one of it's on-chip RISC co-processors that are intended for realtime industrial comms and programming it in assembly but ... there's a learning curve to that for me and it would be hugely overkill if the python option gets the job done in time without too many hacks. Also that's beaglebone specific so won't help anyone who isn't using an AM355x processor, ie RPi and similar. Alternatively it could easily be done in C++ but again, I've got little experience there so would need to learn a bit first.
Hopefully I've got some code to share next week
I'll write something for Arduino at some point but little motivation for me at the moment because I doubt I'll use that for myself.
Hi hochopeper,
Yes, you are right. The window time is 100ms, you at least have 75-80ms to response and take over the control. The very basic Arduino has 16MHz clock. I think no matter what board you are going to use, you will have enough time to control the clock board. The USART communication takes much longer time than the instructions. I suggest you software doing some listening job first and make sure the protocol is working, then the control job.
I don't think you need a interrupt routine. Please let me know if you need any help.
A small tips for USART dubug: source a USB-UART acapter from Digikey (768-1117-ND) or other supplier, by using UART utility software, make a PC as a UART monitor, that would be great help to software developing.
Good luck.
Ian
Try this one first:
"http://www.digikey.ca/product-detail/en/UMFT230XB-01/768-1117-ND/3029128"
Good luck.
Ian
Hi Ian,
I've already got a FTDI 3.3V cable USB FTDI TTL-232 cable and one of these Saleae Logic - 8-Channel USB Logic Analyzer as well as a 3.3V arduino and a beaglebone so I've got options aplenty - writing the software side is the focus now. I'm even thinking it would be easy enough to use serial over xbee too and I have some of those sitting in a box here also. All these parts sitting here from other projects ... the challenge with going back to a full general purpose OS is going to be the OS scheduling ticks, especially when using a language like Python where it runs in a virtual machine and has an additional layer of abstraction. But the advantage of Python is that I could write it in a way that would run on beaglebone/rpi or on a windows/linux/osx computer with a 3.3V ftdi interface and potentially even the xbee would work also, though the wireless latency may be too much there, I'll give it a go though and report back. The only place the python part won't run is on an arduino but I'll write that part later, maybe.
Cheers,
Chris
I've already got a FTDI 3.3V cable USB FTDI TTL-232 cable and one of these Saleae Logic - 8-Channel USB Logic Analyzer as well as a 3.3V arduino and a beaglebone so I've got options aplenty - writing the software side is the focus now. I'm even thinking it would be easy enough to use serial over xbee too and I have some of those sitting in a box here also. All these parts sitting here from other projects ... the challenge with going back to a full general purpose OS is going to be the OS scheduling ticks, especially when using a language like Python where it runs in a virtual machine and has an additional layer of abstraction. But the advantage of Python is that I could write it in a way that would run on beaglebone/rpi or on a windows/linux/osx computer with a 3.3V ftdi interface and potentially even the xbee would work also, though the wireless latency may be too much there, I'll give it a go though and report back
. The only place the python part won't run is on an arduino but I'll write that part later, maybe.Cheers,
Chris
Last edited:
Good to know somebody running si570 from Arduino.
Yes, it's a bit tricky to write a Si570 driver
.Ian
Hi Ian,
I've already got a FTDI 3.3V cable USB FTDI TTL-232 cable and one of these Saleae Logic - 8-Channel USB Logic Analyzer as well as a 3.3V arduino and a beaglebone so I've got options aplenty - writing the software side is the focus now. I'm even thinking it would be easy enough to use serial over xbee too and I have some of those sitting in a box here also. All these parts sitting here from other projects ... the challenge with going back to a full general purpose OS is going to be the OS scheduling ticks, especially when using a language like Python where it runs in a virtual machine and has an additional layer of abstraction. But the advantage of Python is that I could write it in a way that would run on beaglebone/rpi or on a windows/linux/osx computer with a 3.3V ftdi interface and potentially even the xbee would work also, though the wireless latency may be too much there, I'll give it a go though and report back
Cheers,
Chris
I'm interested in writing an Android App, control the clock board from a cell phone or Nexus via a bluetooth UART adapter
. Ian
I'm interested in writing an Android App, control the clock board from a cell phone or Nexus via a bluetooth UART adapter
Ian
I was going similar path but using the Python part that I mentioned above in back end of a web interface that could be entirely device agnostic rather than writing a dedicated app for each type of mobile device
[I have iPad, Nexus 7, Galaxy Nexus and iPhone 4 in my house between me and my wife so I don't like writing software that limits the number of devices I can use and I swap between windows, linux and osx for computers so ... ]When I have something to test on that front I'll let you know first so we can test that side out - there are some more features I've got in mind that I'm sure you'll like
Chris
Last edited:
Dual xo clock board modification for 90.3168/98.3040MHz XO
Principle of modification
To run 90.3168/98.3040MHz XOs, dual xo clock board needs to work at quadruple speed mode. Normally, dual xo clock board feeds full speed MCLK into FIFO for single and double speed mode. The new modification idea is that if we feed half speed MCLK into FIFO, the single speed mode will become double speed; and double speed will become quadruple speed. That's what we want.
To achieve this modification, we just need cut the old FIFO clock trace, generate new MCLK/2 by an additional flip-flop and feed it into FIFO. The attached schematic shows the details.
Dual xo clock board can support 90.3168/98.3040, 45.1584/49.1520, 22.5792/24.5760 MHz XOs with this modification, . Firmware in both FIFO and clock board will keep no change.
Material
1. 1G80 flip-flop in TSOT23-5 package
2. 33 ohm 0603 chip resistor
3. a small piece of wire (I use 0.1mm coil wire)
Steps of the modification
step1: Cut the old clock trace at bottom side of dual xo clock board PCB before R28;
step2: Stack 1G80 on top of the last 1G79, band pin 2,3 and 5 of 1G80 down a little bit (be careful of break off), bridge the three same pins down to the 1G79 buy solder;
step3: solder a wire to jump pin1 and pin4 of 1G80 together, and then solder one pin of the 33ohm 0805 resistor to either of the pins or to the jumper wire;
step4: connect the other pin of the 33 ohm resistor to the pin4 of J7 with by a wire;
Now you can enjoy your 90.3168/98.3040MHz XOs. Pleas look upon your XOs as half of its frequency for settings according to previous documents.
Tips: To run OCXOs, battery direct power is preferred for higher current and lower noise, please refer this post for modding details.
http://www.diyaudio.com/forums/digi...mate-weapon-fight-jitter-275.html#post3485233
Ian
Principle of modification
To run 90.3168/98.3040MHz XOs, dual xo clock board needs to work at quadruple speed mode. Normally, dual xo clock board feeds full speed MCLK into FIFO for single and double speed mode. The new modification idea is that if we feed half speed MCLK into FIFO, the single speed mode will become double speed; and double speed will become quadruple speed. That's what we want.
To achieve this modification, we just need cut the old FIFO clock trace, generate new MCLK/2 by an additional flip-flop and feed it into FIFO. The attached schematic shows the details.
Dual xo clock board can support 90.3168/98.3040, 45.1584/49.1520, 22.5792/24.5760 MHz XOs with this modification, . Firmware in both FIFO and clock board will keep no change.
Material
1. 1G80 flip-flop in TSOT23-5 package
2. 33 ohm 0603 chip resistor
3. a small piece of wire (I use 0.1mm coil wire)
Steps of the modification
step1: Cut the old clock trace at bottom side of dual xo clock board PCB before R28;
step2: Stack 1G80 on top of the last 1G79, band pin 2,3 and 5 of 1G80 down a little bit (be careful of break off), bridge the three same pins down to the 1G79 buy solder;
step3: solder a wire to jump pin1 and pin4 of 1G80 together, and then solder one pin of the 33ohm 0805 resistor to either of the pins or to the jumper wire;
step4: connect the other pin of the 33 ohm resistor to the pin4 of J7 with by a wire;
Now you can enjoy your 90.3168/98.3040MHz XOs. Pleas look upon your XOs as half of its frequency for settings according to previous documents.
Tips: To run OCXOs, battery direct power is preferred for higher current and lower noise, please refer this post for modding details.
http://www.diyaudio.com/forums/digi...mate-weapon-fight-jitter-275.html#post3485233
Ian
Attachments
Hi guys,
I know this has already been discussed before, but the thread is terrifyingly long and using the search function hasn't helped.
So, how exactly do you implement the power supplying with batteries?
I'm thinking of using cyclon batteries (6V), with a TPS reg. Also, I have some lm10 around and thinking of making a voltage threshold indicator with them. What do you think?
To those who use A123 batteries: Do you have these connected directly on the board?
I know this has already been discussed before, but the thread is terrifyingly long and using the search function hasn't helped.
So, how exactly do you implement the power supplying with batteries?
I'm thinking of using cyclon batteries (6V), with a TPS reg. Also, I have some lm10 around and thinking of making a voltage threshold indicator with them. What do you think?
To those who use A123 batteries: Do you have these connected directly on the board?