Hi all
I have connected the Buffalo III to the Airport Express N version by the i2s interface from the AEN.
The problem is that the lock is unstable no matter what bandwidth I choose for the filter.
I have tried different grounding including twisting the ground wire around the serial clock wire.
The cables are very short and I have tried to isolate the clock from other wires.
At it best the lock LED blinks a couple of times during the beginning and then it becomes stable for 5 minutes then it starts to loose lock a couple of times.
I have tried to leave it play all night long but no changes, it still loosing lock in the morning.
The internal DAC (CS4344) in the AEN does not have any problems at all, it just plays while the BIII drops out. (Runs on the same i2s bus at the same time)
Then I was thinking of noise from the switch mode supply of the AEN so off it went and I supplied the AEN from a lab supply.
No change at all.
The I was looking at the serial clock and there was some overshoot ringing so I applied a variable resistor to find the best value for a clean square.
About 68 Ohm seems to be a pretty good value so I went for a fixed resistor and this did help on the locking problem but it did not eliminate it totally, so i am asking you guys what is wrong with the clock signal showed in the pictures.
One picture is without resistor on the serial clock.
The two others is with 68 and 87 Ohm on the serial clock.
I am out of ideas and need some input for other tests.
Thanks and best regards
Chris
I have connected the Buffalo III to the Airport Express N version by the i2s interface from the AEN.
The problem is that the lock is unstable no matter what bandwidth I choose for the filter.
I have tried different grounding including twisting the ground wire around the serial clock wire.
The cables are very short and I have tried to isolate the clock from other wires.
At it best the lock LED blinks a couple of times during the beginning and then it becomes stable for 5 minutes then it starts to loose lock a couple of times.
I have tried to leave it play all night long but no changes, it still loosing lock in the morning.
The internal DAC (CS4344) in the AEN does not have any problems at all, it just plays while the BIII drops out. (Runs on the same i2s bus at the same time)
Then I was thinking of noise from the switch mode supply of the AEN so off it went and I supplied the AEN from a lab supply.
No change at all.
The I was looking at the serial clock and there was some overshoot ringing so I applied a variable resistor to find the best value for a clean square.
About 68 Ohm seems to be a pretty good value so I went for a fixed resistor and this did help on the locking problem but it did not eliminate it totally, so i am asking you guys what is wrong with the clock signal showed in the pictures.
One picture is without resistor on the serial clock.
The two others is with 68 and 87 Ohm on the serial clock.
I am out of ideas and need some input for other tests.
Thanks and best regards
Chris
Attachments
Maybe try a MC resistor in series to slow the rise time? I have seen 100 ohm used for that.
Last edited:
Can you post a picture of your wiring?
Also, what are you using to power the Buffalo (and settings etc)?
Also, what are you using to power the Buffalo (and settings etc)?
Hi
Thank you for the replies.
Today I have tried with this :
MPZ1608D101B TDK | Mouser
Instead of the 68 Ohm resistor and in serial with the resistor and it did not make any difference.
However the result was the same without the 68 Ohm resistor, so the TDK did help compare to no damping at all.
It seems like the locking problems in the beginning is better with the TDK but it loose lock several times over a minute test.
The first picture is the TDK and the 68 Ohm in serial.
The other picture is the TDK alone.
Any thoughts ?
Best regards
Chris
Thank you for the replies.
Today I have tried with this :
MPZ1608D101B TDK | Mouser
Instead of the 68 Ohm resistor and in serial with the resistor and it did not make any difference.
However the result was the same without the 68 Ohm resistor, so the TDK did help compare to no damping at all.
It seems like the locking problems in the beginning is better with the TDK but it loose lock several times over a minute test.
The first picture is the TDK and the 68 Ohm in serial.
The other picture is the TDK alone.
Any thoughts ?
Best regards
Chris
Attachments
Regarding the wiring then here is some pictures.
I have tried to remove the other wires so only GND and SCLK was connected.
The white power supply is for the AE and the black is for the DAC.
All the dip switches is set to ON and it make no difference how I set the filter bandwidth.
The SW2-5 S/pdif auto detect dip does not do any difference.
I have been reading that the best sound is with the SW1-5,6,7 set to default so the goal is to get it to work with this settings.
I have some 2mm coax cable will it make any difference do you think ?
I really appreciate all you help.
Thanks
Chris
I have tried to remove the other wires so only GND and SCLK was connected.
The white power supply is for the AE and the black is for the DAC.
All the dip switches is set to ON and it make no difference how I set the filter bandwidth.
The SW2-5 S/pdif auto detect dip does not do any difference.
I have been reading that the best sound is with the SW1-5,6,7 set to default so the goal is to get it to work with this settings.
I have some 2mm coax cable will it make any difference do you think ?
I really appreciate all you help.
Thanks
Chris
Attachments
Last edited:
Sounds like a cool project.
Often this sort of problem is because of an intermittent clock or one with extreme phase noise. Such a problem can be hard to spot with a scope. I have seen this situation occur when a bit clock is generated by PLL or other other such clock multiplier or divider.
Most synchronous type DACs like the CS4344 won't lose lock on such a clock, but instead will pass along the error as noise.
You know the DAC itself is fine because it locks well from the signal generator.
Often this sort of problem is because of an intermittent clock or one with extreme phase noise. Such a problem can be hard to spot with a scope. I have seen this situation occur when a bit clock is generated by PLL or other other such clock multiplier or divider.
Most synchronous type DACs like the CS4344 won't lose lock on such a clock, but instead will pass along the error as noise.
You know the DAC itself is fine because it locks well from the signal generator.
Which firmware version are you using? If its the old firmware you may need to reverse the switches (on = 1 vs on = 0)
Hi Russ
Thanks for your feedback.
The board is brand new, Brian did send it a couple of weeks ago.
I would like to achieve my goal with the Buffalo being a intergrated part of my iMac / Itunes setup and the problem is that my iMac is located far away from the stereo.
So a Buffalo DAC with its own IP address would be kind of cool 🙂
If these problems is created in the processor of the AE then I am not sure how to solve the problem.
What about Ian´s FIFO reclocker, would this be a solution ?
As I understand then it remove the original clock and then send the I2S signal to the DAC with it´s own new clock.
Thanks
Chris
Thanks for your feedback.
The board is brand new, Brian did send it a couple of weeks ago.
I would like to achieve my goal with the Buffalo being a intergrated part of my iMac / Itunes setup and the problem is that my iMac is located far away from the stereo.
So a Buffalo DAC with its own IP address would be kind of cool 🙂
If these problems is created in the processor of the AE then I am not sure how to solve the problem.
What about Ian´s FIFO reclocker, would this be a solution ?
As I understand then it remove the original clock and then send the I2S signal to the DAC with it´s own new clock.
Thanks
Chris
Hi Russ,
Merry Christmas!
cringvig, try moving the i2s wires as far away from anything else as possible. Or move the cable around and see if it affects the locking.
Merry Christmas!
cringvig, try moving the i2s wires as far away from anything else as possible. Or move the cable around and see if it affects the locking.
Hi All
Thanks for your replies.
I have tried to move things and wires around with no luck.
Last night i had the DAC connected to the M2tech evo with the i2s output and was just a cutted ethernet cable and it worked perfectly.
So in this case the wires did not make a problem.
The AE does only have internal i2s or toslink out so it is not possible to test with s/pdif.
What about the FIFO reclocker ?
Chris
Thanks for your replies.
I have tried to move things and wires around with no luck.
Last night i had the DAC connected to the M2tech evo with the i2s output and was just a cutted ethernet cable and it worked perfectly.
So in this case the wires did not make a problem.
The AE does only have internal i2s or toslink out so it is not possible to test with s/pdif.
What about the FIFO reclocker ?
Chris
Toslink is SPDIF 🙂 So if you can find the signal to the transmitter you can use that. Use a voltage divider to get it close to consumer level. Something like 221R series and 75R to GND.
OK got it 🙂
Maybe I am wrong but I have always been thinking that i2s is to prefer when availible instead of SPDIF as it is the native DAC input ?
Chris
Maybe I am wrong but I have always been thinking that i2s is to prefer when availible instead of SPDIF as it is the native DAC input ?
Chris
Depends on who you believe. 😉
In any case it also depends on what actually works - and how the source is designed. 🙂
You can do I2S as badly or worse than SPDIF, and in any case the ES9018 does not handle SPDIF like most SPDF receivers do at all. It handles it far better and asynchronously.
In any case it also depends on what actually works - and how the source is designed. 🙂
You can do I2S as badly or worse than SPDIF, and in any case the ES9018 does not handle SPDIF like most SPDF receivers do at all. It handles it far better and asynchronously.
Hi Russ
I have found the spdif out from the AE and with the divider you suggested the voltage is about 0.6V
I connected to the Buffalo DAC but it would not lock.
Tried the same wires on another DAC and it did lock right away with no drop outs.
Then I had the scope on at the same time and saw that the voltage is pull down to 0.3V.
Hmm... tried the i2s again and it will not lock and the voltage is pulled down from 3.2V to 0.5V when connected to the Buffalo DAC.
When I removed the wires from the DAC the signal is 3.3V and 2.8Mhz.
What has happent here ?
Both SPDIF and i2s is pulled down when connected to the Buffalo DAC
Chris
I have found the spdif out from the AE and with the divider you suggested the voltage is about 0.6V
I connected to the Buffalo DAC but it would not lock.
Tried the same wires on another DAC and it did lock right away with no drop outs.
Then I had the scope on at the same time and saw that the voltage is pull down to 0.3V.
Hmm... tried the i2s again and it will not lock and the voltage is pulled down from 3.2V to 0.5V when connected to the Buffalo DAC.
When I removed the wires from the DAC the signal is 3.3V and 2.8Mhz.
What has happent here ?
Both SPDIF and i2s is pulled down when connected to the Buffalo DAC
Chris
Hi Russ
Thank you for quick reply.
Yes I did remember the jumper and it make no difference.
I think something must have happend to the Buffalo board but I have no clue as I do not have the schematics.
On the picture the yellow channel is directly from the signal generator and the blue one is from the signal generator to the Buffalo DAC.
I have been re-soldering all the junctions I have made myself.
I really need some advise what to check.
Thanks
Chris
Thank you for quick reply.
Yes I did remember the jumper and it make no difference.
I think something must have happend to the Buffalo board but I have no clue as I do not have the schematics.
On the picture the yellow channel is directly from the signal generator and the blue one is from the signal generator to the Buffalo DAC.
I have been re-soldering all the junctions I have made myself.
I really need some advise what to check.
Thanks
Chris
Attachments
At what exact points are you measuring?
Does the same thing occur for all inputs?
If anything failed it would be one of the input multiplexors.
Does the same thing occur for all inputs?
If anything failed it would be one of the input multiplexors.
- Status
- Not open for further replies.