Is there a way to deskew or adjust the latency when using multiple Joulescopes?

I’d like to time align at least 3 scopes (maybe 4 or 5) to within 2 us, but I see a spread of 2.3 ms between 3 JS220s. Assuming the first one is 0, the second would be 2.022 ms, and the third 2.334 ms.
This is measured with a common signal going to all 3 with equal length wires to the common signal.

Hi @Jeremy ,

A single USB root hub only supports 3 Joulescopes at a time, at least at full sample rate. If you want more, your host computer has to have multiple USB root hubs. Some customers add PCIe USB cards, which each function as another USB root hub.

The Joulescope UI’s Waveform widget only supports 4 Joulescopes at a time. You can add multiple Waveform widgets and configure them for different Joulescopes.

We have significantly improved time alignment between Joulescopes recently. Please be sure you are running UI 1.2.5 and that all devices have FPGA 1.3.2.

Ensure that your host computer has a good NTP time source and is synchronized. You should leave your host computer on so that it stabilizes. You can consider buying your own local NTP time server for improved accuracy. I use the TimeMachines TM 2500C, but any NTP time server should work. Having a PPS output is very useful for quantifying the JS220 time alignment accuracy, which I discuss at the below.

Connect all the Joulescopes you plan on using to the host computer. Start the Joulescope UI, and allow them to run for a while to synchronize time. The oscillator on each JS220 is only accurate to ±25 ppm. Correcting for this variation takes a while. You will usually get to about 100 µs alignment in 10 minutes. Best alignment takes an hour or more.


How to Quantify Time Synchronization

We do have a developer tool that we use to quantify time alignment. You can also use it to quantify the time alignment you get from your setup. You will need a pulse-per-second (PPS) source. The most cost effective PPS source is a GPS / GNSS module. Wire the PPS to IN0 on each Joulescope.

In the Joulescope UI, click the Device Control icon on the sidebard, and set each JS220’s GPIO Voltage to 3.3 V. Click the Settings icon on the sidebar, select UI and check developer. You may want to create and activate a new View using ViewManage. Select WidgetsTimesync. To see the full time convergence cycle, close the Joulescope UI, unplug and replug the USB cable to each Joulescope, and then start the Joulescope UI again. After a while, you will see something like this:

This shows 25 µs alignment in about 15 minutes. I regularly see around 10 µs alignment after 1 hour convergence time. Is this good enough for your needs? Acheiving 2 µs time alignment would require a PPS signal with additional JS220 FPGA support. While we have considered adding this, it is not implemented today.

Here is a picture of the test setup:

The large time offset (252 ms shown in the image above) between the PPS signal and computer time bothered me. I have noticed this before, but I could never explain it. I was primarily focused on peak-to-peak variation rather than absolute accuracy.

I spent more time investigating, and the issue is with Windows. Windows needs some additional configuration to keep accurate time:

For a quick check of the Window host computer’s time accuracy, use time.is.

You can also use the command:

w32tm /stripchart /computer:time.windows.com

If you have a local NTP server, change time.windows.com to the IP address or name of your NTP server.

I will capture time synchronization data overnight (UTC-4) and post the results tomorrow morning.

Here are the results that I collected with:

  • Three Joulescope JS220’s with UI 1.2.5 and FPGA 1.3.2
  • Windows 11 with settings recommended by “Configuration systems for high accuracy”. However, I ended up setting HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config\FrequencyCorrectRate to 4 (2 was recommended). The JS220 prefers slow host frequency corrections over absolute correctness.
  • TimeMachines TM 2500C as a local NTP server on the same ethernet switch as the host computer.

Timesync widget

Peak-to-Peak deviation (post-processed)

Discussion of Results

Time alignment after convergence was always better than 100 µs. Other than one excursion, time alignment was better than 40 µs. The average p2p value was 12.5 µs.

The initial convergence to about -160 µs was the host computer converging to the TimeMachines TM 2500C NTP time. Note that this was AFTER allowing the host computer to run for an hour. Based on this single measurement, it took about 3 hours for the host computer to converge to NTP time.

The converged results of the JS220 lagging NTP time was expected. Due to how the JS220 uses USB communications, the delay from device to host (USB IN) is highly variable, which makes the normal round-trip NTP approach challenging. However, the delay from host to device (USB OUT0, is relatively quick and consistent. The JS220 uses this path exclusively, which means the JS220 will always be delayed from the host computer time.

JS220 time alignment to 100 µs is achievable using a local GPS-based NTP time server. We do not yet have metrics using standard internet-based time servers, including time.windows.com and time.nist.gov.

How to improve time synchronization

With the JS220, the only available improvement is to directly support a PPS signal from a GPS/GNSS module. With this signal and the existing time alignment, the JS220 could acheive ± 1 µs time alignment to UTC time. However, we would have to figure out how to make setup easy and reliable.

We can continue to improve future Joulescope products. For improved time alignment, future Joulescope products can consider:

  • Use a higher precision oscillator. The JS220’s ±25 ppm oscillator can be upgraded to ± 2.5 ppm for a reasonable component cost increase.
  • Share the same clock between host side and sensor side. This can help isolate sensor-host communication delays. Consider performing time synchronization on the host side and generating a PPS signal to the sensor-side.
  • Improve the USB communication path to quickly send device to host (USB IN) timesync requests. The future Joulescope protocol can use a partial length USB frame to terminate the USB host-side transaction immediately for better timestamping.

Hi Matt,

Thanks! This looks like it would be a significant improvement. I’ll try it out as soon as I get some time for it.
If the precision oscillator improvement can be done as a component change, I would be interested in the details. I can rework SMTs down to 0201s and expect any rework like that would be at my own risk and would probably void any NIST-traceable calibration.

1 Like

Hi @Jeremy - While you can swap the oscillator, the FPGA algorithm will still assume ±25 ppm, so you will not see any performance improvement.

If the process above gets time alignment accurate enough for you, great!

If you still want higher accuracy and are willing to wire up a PPS signal from a GPS/GNSS module, let me know. We can work to schedule and implement the PPS feature. I wanted the PPS time sync feature in the 1.3.0 FPGA release, but we were seeing problems. However, I now suspect these issues were unrelated to PPS that we fixed in FPGA 1.3.1 and 1.3.2. Combined with the improved Windows time accuracy discussed above, adding PPS support may not be as far away as I thought.