Recently, the USB2 interface consistency of several SDR products was measured with a high-bandwidth oscilloscope. Since there is only one probe, all items cannot be measured. But the most important USB eye diagram (signal quality) item has been included.
testing scenarios:
The parts to be tested include:
1. Original RTL-SDR 2. Homemade RTL-SDR 3. HackRF 4. Radio compass v0.8
Test Results:
1. The original RTL-SDR can see the eye diagram, but the jitter is large and the amplitude is too high, which leads to the failure of the eye diagram test
2. The eye diagram of the self-made RTL-SDR waveform is worse than the original one.
3. HackRF cannot enter conformance test mode, so nothing can be tested
4. After the radio compass is connected to the xhsett software of the usb association, many devices will appear. I guess it should be the external interface of the hub chip, 4 rtlsdr, and 1 cp2102 chip.
The 0x424 below should be the usb hub chip, and you can use it as a device to see the eye diagram (the accurate method should be to measure the upstream of the hub, but it is almost the same).
The above 0xbda should be rtl2832u chips of rtlsdr, but although they can also enter the test mode, they cannot see the eye diagram.
The 0x10c4 highlighted in the figure below should be the cp2102 chip, which does not support the conformance test mode.
The eye pattern of the hub chip of Radio Compass v0.8 is very good, which should be related to the impedance control I did in this version.
However, the rtlsdr connected to the hub cannot be tested. This should be caused by the test method, because after passing the hub, it cannot be tested as a device. You should see a waveform.
I later connected a USB cable to the radio compass, and still used the device to test the hub chip and found that the eye diagram has deteriorated a lot.
In the following two pictures, the left one is without the extension cable, and the right one is the radio compass v0.8 with the extension cable
Later, I still want to compare and test the same hub chip, the difference between the test mode selection device and hub upstream
When testing the hub upstream, select one of the downstream devices
I tested it several times and found that sometimes the eye diagram can pass and sometimes it can't, and after many experiments, I found that the results are not repeated. I suspect it's not a hardware wiring issue, but something random. Later, I used the same downstream device, with all software settings and environment unchanged, pressed single on the oscilloscope, and watched the waveforms at different times, and found that it was indeed up and down.
This should be the reason, resulting in low repeatability of the results when testing the hub upstream.
Not only that, when I used the compass as a device again, and compared the eye diagrams with or without an extension cable, I found that the waveform would also change randomly.
The best waveform when connected to an extension cable barely passes the test:
Therefore, we uniformly use the best waveform under the same test scenario as the standard. The following is the radio compass v0.8 without an extension cable, measured on the hub upstream, on 5 sub-devices (4 rtlsdr and 1 cp2102) Best eye diagram:
I also tested the radio compass v0.7 to see how much the eye diagram of the version without impedance control would deteriorate.
On the left is v0.8, on the right is v0.7. Not controlling the impedance is worse, but not as serious as the problem caused by the usb extension cable.
I also tested the radio compass v0.7 with the hub upstream (all tests of v0.7 without extension cables)
The above pictures are rtlsdr1~4 from left to right, and the last picture is cp2102. Among them, rtlsdr3 is pressed to the template.
So the conclusion is:
1. Not controlling the impedance will indeed deteriorate the eye diagram (the deterioration of v0.7 is not only the impedance, but also the rtlsdr is discrete and has the influence of the connector), but I think the impact of the impedance problem is not as great as that of the extension cable.
2. Sometimes the code pattern may be wrong when testing the usb. It needs to be tested several times until a suitable code pattern can be observed, and the test is valid.
If there is a chance to test the LimeSDR of the usb3 interface later, please look forward to it.