Hi there,
we are trying to replace our multichannel capturing devices (like the keysight 6705 power analyzer) with Joulescopes, for reasons related to sampling frequency and capture length.
Has anyone done this?
The obvious approach would be a master JS to issue trigger output and slave JScopes that would get that trigger input and start capturing.
Any suggestions on this?
Many thanks in advance.
Thanos
Hi @Thanos! Thanks for considering expanding your tests to include multiple Joulescopes.
As you mentioned, you can use event-based alignment, using Python scripts to process the data. We have an example gpi_region.py.
UTC synchronization is available now, and the Joulescope UI supports up to 4 JS220’s (but a single USB root hub only supports 3). The JS220 synchronization accuracy is already good to ±100 µs (typical) and will improve further improve soon (Sep 2024?).
Timekeeping is a fascinating topic. The more accuracy you need, the more complicated it gets.
Timekeeping and time alignment can also mean several different things for test instruments, including:
With event-based alignment, some source generates start and stop signals for each region of interest. The most common approach is to set a general-purpose output to high (1) at the start and low (0) at the end. This signal can be generated by:
All Joulescopes support event-based delimiting inputs. As you mentioned, you can use a general-purpose input (GPI) (including the JS220’s Trigger input) to denote the start and the end of a region of interest. We have an example for using this:
gpi_region.py
You can use this script directly or create a custom script. You can also record sample data to a JLS file and post-process the JLS file to get the same analysis.
Joulescopes use analog-to-digital converters (ADC) to convert the analog current and voltage to digital values that you see on your host computer. The JS110 and JS220 capture at 2 million samples per second (Msps). The JS220 then downsamples on-instrument to 1 Msps without any loss of signal bandwidth.
This sampling is performed at a constant rate as determined by an oscillator on the Joulescopes. The JS220 has a free-running 16 MHz ± 25 ppm oscillator. This free-running oscillator will differ slightly for each JS220 (± 25 ppm) and has no direct mapping to UTC (wall-clock) time.
Joulescopes have had host-side time synchronization for a couple of years now. When samples arrive, the host records the UTC time. A relatively simple algorithm maps between sample number and UTC time. The accuracy of this method is limited to about 10 milliseconds. The JS110 will never be better than this.
We designed the JS220 for improved UTC synchronization. Starting in December last year, we added sensor-side time synchronization. This method works over USB to time align the sensor and the host computer, much like NTP. This approach achieves a typical accuracy of about ±100 µs.
We are actively working to improve this. We already have an unreleased version that improves accuracy to about ±20 µs, still only using UTC synchronization over USB. This improvement comes from a better time synchronization algorithm. It also eliminates the “jumping” that occurs when zoomed into samples while still streaming. The benefit of this approach is that it “just works” with no additional wiring or signals. However, the host computer UTC synchronization, typically performed using NTP or PTP, limits the Joulescope UTC synchronization accuracy.
We planned to have already released this feature, but we are waiting for another improvement, PPS input! The JS220 sensor side will support a pulse-per-second (PPS) input on any general-purpose input, defaulting to the Trigger. Nearly all GPS / GNSS modules now produce a PPS output with at least ±200 ns accuracy. With a PPS input, JS220’s should be accurate to better than ±2 µs, assuming that the host computer uses NTP to be within 200 milliseconds of UTC.
We have PPS “working” in development now, but we continue to find strange behaviors, perhaps due to our existing PPS source. A Time Machines 2500C arrives tomorrow, and we will add some lab-grade equipment once we can figure out what that is…
Unfortunately, we are not able to commit to a date yet. We were hoping for June/July 2024, but that has already passed, and we are still not in release testing. My best estimate at this point is by the end of September 2024.
The joulescope_driver and Python packages pyjoulescope_driver and joulescope have always supported multiple simultaneous Joulescopes.
The Joulescope UI 1.0.48 and newer includes multiple, simultaneous Joulescope support [newsletter announcement]. This UI feature is available in 1.1.x, and it allows you to view the time-aligned signals from multiple Joulescopes. Also see the Multiple Instrument Support section of the Joulescope UI User’s Guide.
The time alignment accuracy depends upon the time alignment method in (2).
Neither the JS110 nor the JS220 can discipline (tune) their free-running oscillators to an external clock.
Some test equipment has an external clock input, usually 10 MHz. Neither the JS110 or JS220 support this.
The more you learn about timekeeping, the more you realize how much we take for granted in our daily lives. For a great intro, check out The Science of Timekeeping. I have A Brief History of Time Keeping by Chad Orzel on my summer reading list, but sadly it still sits unopened.
So, does this help?
Is event-based time alignment what you want, or do you really want UTC synchronization? If you want UTC synchronization, how accurate are your timing alignment requirements?
Hey there Matt,
thanks for the extensive reply, that’s a lot of information. Let me digest all this and come back
BR,
Thanos