To answer your first question, I don’t recall any instance where we have needed to suggest that a customer uses a ferrite core to establish or maintain a connection. So, we haven’t had a need to use ferrite cores on our cables. We have found that connectivity problems for USB can be fixed by ensuring that the following recommendations are followed:
* Using our high quality cables
* Using a host device that can supply enough current to our PicoScope and Data Loggers
* Checking that the driver is able to enumerate correctly to establish communication with the Pico USB peripheral and complete the setup procedure.
* Avoiding simple mistakes such as; not installing our software with the device connected via USB, and not trying to run a second instance of PicoScope 6 (checking that a previously run PicoScope 6 has been shut down correctly, when problems arise, along with other recommendations made in our PicoScope self help guide, found here: https://www.picotech.com/download/manua ... uide-1.pdf
To answer your second question, you can indeed add a ferrite core to one of our cables without any detrimental effect to the USB signal, but this may not be as simple as just snapping on any core, because how effective the core will be depends upon what you’re trying to reject and what core you’re using to reject it.
It is possible (but in most cases unlikely) that you could encounter some significant interference, but this could originate from a large variety of potential sources, at widely different frequencies and bandwidths. Also, there are different cores that can be used, for different frequencies and ranges (you’d have to use the right type of core, and try and match the resistance region of the cores impedance curve to the bandwidth and location of the unwanted signal, which, even if you have the manufacturers specification, can sometimes be difficult, as shown here: http://www.allaboutcircuits.com/technic ... ite-beads/
). If you add to this the fact that not every application and environment that a user will want to capture data in will necessarily be the same, you can see that this can easily become more hit and miss, than effective countermeasure. An easier way of doing this would obviously be to use cores that can reject unwanted signals over a wider frequency range to catch more potential sources if you’re using the core only as preventative measure. The broader band width approach may not be as effective as matching the interference bandwidth to the rejection bandwidth of the core, but then it may be all you need!