You mean USB Jitter?
What does it lead to if audio devices work without problems?
In any case, it does not affect jitter in A/D and D/A conversion.
Did not tried with ADAU, but made sometime experiments with TI ISOUSB211 - 4-5m w/o any problems with UAC2 Audio device.
With 2 signal conditioners (TUSB217) - maximum was 12.2m. But it was on the edge - on 13m it already worked poorly and on 13.5 it didn’t work at all.
Disclaimer: VERY depends of a cable, and if the device is USB-powered - of it current consumption.
How the project went? can we buy some yet?
This still needs a bit more testing.
I have made 5th version until now.
and test and test and test...
I also ordered a 3D printed case from JLCPCB.
Recent changes include
1. Use type B terminals on inputs and type A terminals on outputs for general use
2. Using the LTC6655 voltage reference and increasing the capacitor on the SET pin to 4700uF to improve the 1/f noise of the LT3045 powering the TCXO;
The LTC6655 is an option since the LT3045 works without soldering the 6655 chip. I think the increased capacitor on the SET pin is enough to reduce the 1/f noise.
Attachments
ah great, i keep following
if you plan to sell these you can definitely reserve one for me
what you guys think of these? https://www.lcsc.com/datasheet/lcsc_datasheet_2304140030_Nexperia-PCMF1USB3SZ_C552015.pdf
could we stack more than one after each other?
im currently looking into building a small pcb that can split power and data, integrate resistance between ground input and output (like the ifi idefender) and possibly using these filters, in the end i kinda wanna combine this small pcb with a isolator
if you plan to sell these you can definitely reserve one for me
what you guys think of these? https://www.lcsc.com/datasheet/lcsc_datasheet_2304140030_Nexperia-PCMF1USB3SZ_C552015.pdf
could we stack more than one after each other?
im currently looking into building a small pcb that can split power and data, integrate resistance between ground input and output (like the ifi idefender) and possibly using these filters, in the end i kinda wanna combine this small pcb with a isolator
It is a device that combines a common mode choke and an ESD diode.ah great, i keep following
if you plan to sell these you can definitely reserve one for me
what you guys think of these? https://www.lcsc.com/datasheet/lcsc_datasheet_2304140030_Nexperia-PCMF1USB3SZ_C552015.pdf
could we stack more than one after each other?
im currently looking into building a small pcb that can split power and data, integrate resistance between ground input and output (like the ifi idefender) and possibly using these filters, in the end i kinda wanna combine this small pcb with a isolator
It seems wiser to use only common mode choke elements.
I must be missing something I think? Why bother this much about jitter on an asynchronous transport?? Contrary to eg SPDIF there is no clocking information in the UAC2 data. Other than keeping galvanic isolation and noise polution down, I don't think anything else matters for a USB isolator.
What am I missing?
Guys,
Remember how this works with audio. The HOST sends the preamble:select info(basically who it's sending too and which endpoint#)data. All of these are sent the same way no matter what protocol is in question. The DEVICE side trains the PLL on the preamble and then samples x# of times (usually multiples for FS, single for HS) and determines the bit value. The less JITTER there is in the USB stream is going to make that DATA (samples in our case) more bit true. The higher the sample rate the larger the DATA packet is. DoP is the worst because of it's flag thing. I tested really expensive USB cables that would put silence to DoP DSD frames because of errors.
Isosynchrous is not error correcting and with my Tektronix plug in and 1G differential probe I have see a bunch of errors when testing cables.
Again the USB JITTER has nothing to do with audio related JITTER errors. But it does have to do with data integrity.
Remember how this works with audio. The HOST sends the preamble:select info(basically who it's sending too and which endpoint#)data. All of these are sent the same way no matter what protocol is in question. The DEVICE side trains the PLL on the preamble and then samples x# of times (usually multiples for FS, single for HS) and determines the bit value. The less JITTER there is in the USB stream is going to make that DATA (samples in our case) more bit true. The higher the sample rate the larger the DATA packet is. DoP is the worst because of it's flag thing. I tested really expensive USB cables that would put silence to DoP DSD frames because of errors.
Isosynchrous is not error correcting and with my Tektronix plug in and 1G differential probe I have see a bunch of errors when testing cables.
Again the USB JITTER has nothing to do with audio related JITTER errors. But it does have to do with data integrity.