Thanks for the help, makes total sense. I guess I'll have to continue investigating why sync mode is problematic.
Regards
I hate to keep adding to the thread but am still looking to get sync mode working with a standard stereo set up. Changed out the clock u.fl connection to a double shielded version and routed it away from the DAC chip. Seems a little improved, it plays , and if I set the filter to brickwall there is very little noise breakthrough, on other filters the noise is pretty severe. Does this point to any particular issue causing the problem?
Thanks in advance for any pointers anyone can give.
Thanks in advance for any pointers anyone can give.
Hey Martin,
one possible thing to check is the 33 (or 20) Ohm resistors, that terminate the masterclock lanes on Cronus. The suspects in my case were R8 and R9 on a Cronus v1.3.
I've had similar problem, where the async mode worked fine, but when I started using the sync mode, it would loose the lock after a couple of minutes.
The scope showed the sawtooth pattern at the output of the clock, but when measured at the side of R9, it was all fuzzy, not the solid line. And this was happening on one of my Cronuses, the other worked fine in the same environment. So I've reflowed all the IC's, all the other components, even exchanged all the IC's with the working Cronus, but still no good.
Then I've noticed that on the faulty one the termination resistors were 20 Ohm, while on the working one they were 33. So I've removed those 20 Ohm ones, and put some 33 Ohm, and now it's working fine.
Other thing I did was to reflow the masterclock u.fl connector, maybe that helped also, but it's hard to say now.
Thanks,
Fedor
one possible thing to check is the 33 (or 20) Ohm resistors, that terminate the masterclock lanes on Cronus. The suspects in my case were R8 and R9 on a Cronus v1.3.
I've had similar problem, where the async mode worked fine, but when I started using the sync mode, it would loose the lock after a couple of minutes.
The scope showed the sawtooth pattern at the output of the clock, but when measured at the side of R9, it was all fuzzy, not the solid line. And this was happening on one of my Cronuses, the other worked fine in the same environment. So I've reflowed all the IC's, all the other components, even exchanged all the IC's with the working Cronus, but still no good.
Then I've noticed that on the faulty one the termination resistors were 20 Ohm, while on the working one they were 33. So I've removed those 20 Ohm ones, and put some 33 Ohm, and now it's working fine.
Other thing I did was to reflow the masterclock u.fl connector, maybe that helped also, but it's hard to say now.
Thanks,
Fedor
Hi Fedor,
Many thanks for your suggestions, I will check the termination resistors. I am also looking at the Arduino as being a possible issue. I use it to control the firmware by pulling down the port expander GPIO pins, as well as using it to sense the frequency that the Amanero is receiving by sensing the relevant Amanero pins. This seems to work fine in async mode, but putting a scope on the Amanero pins, there is a very large amount of HF noise (in the high MHz range) so I am thinking that this noise is getting into the DAC via the GPIO pins or the grounding.
Initial test yesterday seemed to show that without the Arduino connected sync mode would run with only the occasional 'click'.
The other thing I am looking into is how the digital grounds are connected.
Regards
Many thanks for your suggestions, I will check the termination resistors. I am also looking at the Arduino as being a possible issue. I use it to control the firmware by pulling down the port expander GPIO pins, as well as using it to sense the frequency that the Amanero is receiving by sensing the relevant Amanero pins. This seems to work fine in async mode, but putting a scope on the Amanero pins, there is a very large amount of HF noise (in the high MHz range) so I am thinking that this noise is getting into the DAC via the GPIO pins or the grounding.
Initial test yesterday seemed to show that without the Arduino connected sync mode would run with only the occasional 'click'.
The other thing I am looking into is how the digital grounds are connected.
Regards
More experimenting - with the DAC operating without the Arduino connected or powered on and with the switching all via SW1 and SW2, and with no USB connected into the Amanero, the noise is still there (all be it at a lower level). Since async has no issue, I need to look more closely at the Cronus. I did have a prior one with bad joints to the potato chip, I wonder if this one may have issues?
If I scope the clock outputs from the Rhea modules, they look very stable (although with my 100Mhz scope it doesn't show the square wave properly. If I then probe the MCK output on the board, it's all over the place, and full of noise - I would expect the MCK output to look stable just like the Rhea module output. Anyway time to take out the Cronus and have a really good check over.
If I scope the clock outputs from the Rhea modules, they look very stable (although with my 100Mhz scope it doesn't show the square wave properly. If I then probe the MCK output on the board, it's all over the place, and full of noise - I would expect the MCK output to look stable just like the Rhea module output. Anyway time to take out the Cronus and have a really good check over.
20 or 33ohm termination resistors are fine - actually even 0 ohm is fine because there is termination on the B3SE side.
I would carefully inspect for dry joints - it is possible.
I would especially check around the clock buffer and the FF.
Very sorry you are having issues - I moved your posts to a new thread so we can concentrate on them here.
I would also just double check your supplies during operation. I have seen supplies sag when I did not expect them too.
Also you could check the MCK signals at the input side of the clock buffer and at the DAC. I would also do that for all the other audio signal. Check them before the termination resistors - and at the DAC.
Cheers!
Russ
I would carefully inspect for dry joints - it is possible.
I would especially check around the clock buffer and the FF.
Very sorry you are having issues - I moved your posts to a new thread so we can concentrate on them here.
I would also just double check your supplies during operation. I have seen supplies sag when I did not expect them too.
Also you could check the MCK signals at the input side of the clock buffer and at the DAC. I would also do that for all the other audio signal. Check them before the termination resistors - and at the DAC.
Cheers!
Russ
Hi Russ,
OK, a little more information (hopefully useful).
Disconnected and powered off the Arduino to take it out of the equation, so just have the Cronus / Amanero stack and the DAC. With it powered up the clock signals look nice and stable at the crystals, and up to the Potato chip. After the chip really jittery and unstable.
Then kept the same hook up but took the power off on the DAC by removing all the Tridents. - Still the same outcome, jittery clock signal all the way after the Potato chip.
Next unplugged the u.fl connector for the MCK on the DAC, with it unplugged the clock signal looks really clean and stable all through the Potato chip and the 20 ohm resistors all the way to the output on the Cronus. Seems like the master clock signal is getting affected when plugged in to the DAC.
OK, a little more information (hopefully useful).
Disconnected and powered off the Arduino to take it out of the equation, so just have the Cronus / Amanero stack and the DAC. With it powered up the clock signals look nice and stable at the crystals, and up to the Potato chip. After the chip really jittery and unstable.
Then kept the same hook up but took the power off on the DAC by removing all the Tridents. - Still the same outcome, jittery clock signal all the way after the Potato chip.
Next unplugged the u.fl connector for the MCK on the DAC, with it unplugged the clock signal looks really clean and stable all through the Potato chip and the 20 ohm resistors all the way to the output on the Cronus. Seems like the master clock signal is getting affected when plugged in to the DAC.
Russ,
Thanks for the guidance, a temporary hook up with a single wire seems to have done the trick! - The connection is too long at the moment so there is an occasional very slight 'click' but I am sure with a hard wired short connection it will be fine.
Why would a single unshielded wire be superior to the u.fl? My only thought as a relative novice to digital stuff is that since there were multiple u.fl connections between the Cronus and the DAC it could be a ground loop issue? If that's the case would it be better to use unshielded wire connections for D1, D2 etc and a single shielded u.fl for the MCK? or perhaps use shielded connections but have the shields on all but one connected only at the source?
Regards
Thanks for the guidance, a temporary hook up with a single wire seems to have done the trick! - The connection is too long at the moment so there is an occasional very slight 'click' but I am sure with a hard wired short connection it will be fine.
Why would a single unshielded wire be superior to the u.fl? My only thought as a relative novice to digital stuff is that since there were multiple u.fl connections between the Cronus and the DAC it could be a ground loop issue? If that's the case would it be better to use unshielded wire connections for D1, D2 etc and a single shielded u.fl for the MCK? or perhaps use shielded connections but have the shields on all but one connected only at the source?
Regards
I have found that in some cases (not all) uFL can be finicky - I am not sure if it's the cables or the connectors - or some other reason like cable capacitance. I also have found that if I only ground one end of the uFL cable I sometimes get better results than when I ground both (probably because of local HF ground loop). I have cut awaysthe ground shield around one end of the cable to achieve a single ground point in tests.
All in all - I suggest simple hookup wire is often the best solution. Honestly - except in extreme cases - you not really at risk of picking up EMI as much as transmitting it with unshielded wires. And in this case - it's far more important to have a clean signal then to worry about the small emissions.
So my suggestions is - if you are seeing flaky behavior using uFL - use hookup wire. You won't be doing any harm.
Cheers!
Russ
All in all - I suggest simple hookup wire is often the best solution. Honestly - except in extreme cases - you not really at risk of picking up EMI as much as transmitting it with unshielded wires. And in this case - it's far more important to have a clean signal then to worry about the small emissions.
So my suggestions is - if you are seeing flaky behavior using uFL - use hookup wire. You won't be doing any harm.
Cheers!
Russ
Last edited:
Well, I guess the problem is still here Hooked up the MCK with a shorter better quality wire (the older long one was a Arduino hook up wire) and the noise is back. Put the Arduino wire back in and it less pronounced but still there.
I still have D1, D2 etc connected via u.fl connectors, tomorrow I will try plain wire for those and see what happens. Running out of ideas here.
Hooked up the MCK with a shorter better quality wire (the older long one was a Arduino hook up wire) and the noise is back. Put the Arduino wire back in and it less pronounced but still there. I still have D1, D2 etc connected via u.fl connectors, tomorrow I will try plain wire for those and see what happens. Running out of ideas here.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.