Asymmetric / noisy / non-interruptive user fuses.

Joulescope model

JS220

UI version

1.0.48

Your idea

With the understanding that it would break the physical analogy and with the purpose of the user fuses being hardware protection, it would be lovely if the user fuses could be specified to work only on currents in a single direction, protecting the downstream hardware from unintended application of reverse polarity power.

An enhanced version of this request would see the cutoff be different for positive currents and negative ones.

Likely much more niche and likely requiring an extensive rework of the fuse system, windowed fuses for either excursions ("Current dwelling outside of this area for a prolonged period of time is bad") or for problem detection ("Something goes wrong when we draw current in this range for a prolonged period of time"). However, we completely understand that this is likely not a need for most of your customers.

As a comment on the GUI itself. It would be useful if a fuse trip could optionally focus the Joulescope window, optionally display a dialogue box that needs to be explicitly dismissed and optionally change/blink the background color of the graph. Currently it is relatively easy to miss the fuse trip if one's attention is divided among many tasks, the meter window is minimized and the device LED is not squarely facing the user. For us it signals the DUT failure, between which there will be considerable time. It is not feasible to solely monitor for the trip. On a trip event we need to gather up whatever data the experiment has yielded and reset the setup. This does not excuse lack of diligence on the part of the experimenter, but more noticeable trips would reduce the downtime. Such a notice would be even more appreciated in case of a windowed fuse being implemented, as this would start detecting problems quite often.

Finally, such fuses could just signal a fault and not cause a circuit break, bringing a problem to the experimenter's attention without interrupting the experiment.

Thank you for the wonderful device that has already seen extensive use as a debugging aid. Not the intended use for it, but we greatly appreciate what we managed to accomplish with it all the same. We realize that just about all of this is not a priority, but wanted to offer the suggestions we have for your consideration.

Does your idea concern a specific OS?

Linux Ubuntu amd64 (PC)

Hi @remy-luisant! Great to hear that the fuse feature is helping your development efforts.

The ability to specify a fuse direction makes sense. We would have bidirectional (default), positive, negative. You can get an asymmetric response by using the first user fuse to specify positive and the second fuse to specify negative. Do you need more fuse channels than this?

I can understand wanting to have an extreme, impossible-to-miss method of presenting fuse engaged within the UI. We could change the background Widget color to blinking red, for example. Modern OS's really frown upon bringing windows to the front automatically. A more reliable way is to launch a separate notification process that has a window that will be at the front by default. We could potentially add configurable notifications to the UI or as a UI plugin (plugins are not yet available but coming).

However, if you are monitoring custom conditions and then performing custom actions, perhaps using a custom Python script rather than the UI would be more effective. Do you need / want the Joulescope UI while you are performing this test? If you are just using it to capture Joulescope and monitor the fuse state, you can easily do that from a Python script. You can also automate all of your other test setup through Python to completely tear down and restart the test on this condition.

The nice thing about a Python script (or a UI plugin when it is available) is that you can monitor the Joulescope streaming current samples for whatever condition you want. If you can mathematically describe the windowed fuse or problem detection mathematically, you can detect it on the host computer. It will have some delay (on the order of 100 milliseconds) compared to being implemented on the sensor-side FPGA, but this does not seem like an issue for your case. You can then use Python to take whatever action you want.

What do you think?

Sadly, the reason why we are not providing PRs to give back to the community or writing Python scripts for our own use is that the number of the people on the team who know Python is not a number that is safe to be used as a divisor. The delay would be immaterial, but this is simply not a task we can do. We can make do just fine, but reporting what would help us might make your product better, if there is enough demand and if there is a good business case for it.

Windowed fuses would demand about 7 windows, with individual enables. Two or three per charge direction, to detect desirable ranges and to trip outside of them, with the last one for localizing a specific problem. The usual case would be running with the set of 6 for test runs. When a problem is detected we would switch to the last window, to focus on that specific problem, and not any of the others that also do not fit in the known-good ranges, all this without disturbing the 6 good window settings for when we need to resume hunting for new problems.

We have a case for fuses with polarity, but never more than one at a time, situations like "the battery should not be (dis)charging right now". The two user fuses used in a compound way are perfectly fine for this. The need for fuses only goes up dramatically if windowing is available.

Playing a sound on a fuse trip might be an idea, possibly with spaced repetition. If the JS device has a buzzer, that would be a good case for it as well.

Thank you!

Python is really easy to pick up. I created a baseline detector example. It uses the new WindowThresholdDetector.

Since you are using Ubuntu, I recommend using a virtual environment:

python3 -m venv ~/venv/joulescope
. ~/venv/joulescope/bin/activate
python3 -m pip install pyjoulescope_driver

You should then be able to clone the pyjoulescope_examples repo and then:

python3 ./bin/detector.py

Whenever you open a terminal to run this script, you will need to repeat the . ~/venv/joulescope/bin/activate command to activate the virtual environment.

Does this make sense and get you started with using Python?

Neither the JS110 nor the JS220 includes a buzzer. However, you can easily play a sound from your PC. One way in Python is with the playsound package.

If you prefer C over Python, you can also use our C API. Take a look at the documentation and the jsdrv source code.

jetperch / pyjoulescope_ui