Yes, Paul did the original as a Java Applet. I did the port to run in the x-compile to allow it to run in the browser. After that we cooperated on it for a while. I stepped back a few years ago to focus on other things, but he's kept up with improvements. Kudos.
I posted that rather quickly, so a bit more information for those who are interested (inspired by some of the comments on the thread).
I found Paul's sim by chance and really liked it because it was the first electronics sim that I had seen that was properly interactive and visual in its approach. I thought it was a great tool for building intuition about circuits. However, at a certain point it became clear that Java in the browser was on its way out, and this really needed to become a plug-in free experience if it was going to continue to be useful.
This was about the time that V8 was coming along and revoluationizing the performance of JS. Originally there was no license attached to the project, so I asked Paul if he was OK in me trying to port it to run on JS using the GWT framework. He was fine, but said he'd done old experiments with some of his other sims and found that JS wasn't performant enough, but with the strides in JS performance I was more optimistic.
I took the Jave code and commented just about everything out to get a minimal implementation of the standard LRC circuit just to see the performance. Once I was comfortable with that working I started adding every feature and every component back. Most of the work was replacing the Java graphics primitives with the equivalents from GWT.
Once the initial version JS version was out I did quite a lot of work mostly on UI features, especially the 'scopes. They were rather weak in the original and still not as good as I would really like, but much improved.
I have thought about monetizing and extending with EDA features, socials, etc. but its never been enough of a priority to do it. I kind of like its simplicity as it is.
It has been used a lot in education and a couple of teachers have contributed to the code to support their uses in classrooms.
It's kind-of amazing that it still has a very distinctive niche that nobody else has really gone after in quite the same way. I think a lot of that is because Paul's original vision and work on the Java version was so good.
Yeah, I got the joke. I was (and still am) tempted to downvote though because puns and pun chains are low effort and reddit-esque. "What you posted didn't register at first", "I'll have to think about that for a bit", "Why can't we post flip flop puns? This community is too gated", etc.
Personally I don't mind some "reddit esque" (or whatever you want to call them) comments here and there. The level of those present on HN is low anyway. They could/should be less in some cases, but they don't bother much as the majority is still mostly insightful comments or interesting discussions. Imagine a completely sterile online community without any communication side-tracked, even if it's just a tiny bit, from the informational topic. That just wouldn't feel right to me. The equivalent of a "everyone got a stick up their lower half" workplace. Yuck.
I'm not even sure what it is I am saying. Maybe I'm advocating for a more laissez faire internet, the responsible use of censoring powers, or maybe it's a silent cry to get me banned from HN...
edit: I didn't get the "JK". You got me there. Well played.
I am interested in simulators, especially in simulators of analogue circuits. Do you have any recommendations on where to start reading about algorithms that lie at the core of simulators?
Also, how was the experience developing such product with JS?
From a software developer perspective: lots and lots and lots of automated tests, each of which builds a circuit, runs a simulation, and makes sure we don't see any behavior regression. More lines of code in tests than in the core simulation engine or device models!
I have been using the falstad sim for years in the developement of analog synthesizer stuff. There are some circuits that work in practise that do not work in practise (e.g. relaxation oscillators with a schmitt-trigger inverter). The model oscillates, but it is not really controlable.
Outside of that most simpler stuff (e.g. analog math using opamps, discrete stuff) works perfectly fine. I love it for education and quick "sanity check" simulations.
As /u/compumike mentioned the core spice algorithm is an LU decomposition and solve of a large matrix. Not sure what a good resource these days would be; it's been many years since I worked on this.
The JS experience wasn't great. We used emscripten and the tooling barely worked for the simulator core. The rest of the app wasn't bad, but we used polymer / webcomponents which was a big mistake IMO
Library curation is a massive amount of work. Pretty much the reason I end up using falstad instead of a SPICE is because I end up spending all day tracking down and debugging issues with simulation models.
I'm super stoked that hardware / EE is getting so much more focus and interest from software engineers. It really feels like there is so much room for improvement / optimization in that space and for so many years, it was like this black box that nobody wanted to look inside.
In my opinion, the next step is to figure out a good way to combine something like gnu octave with nice modern GUIs.
Old tools were inaccessible to use because there's nothing to look at with a text-based tool, and inaccessible for engineers to develop because programming was so arcane. Look at Berkeley spice written in C. It's a lot of old-school parsing and implementing matrix methods.
The new stuff that's more accessible to use is more accessible for a software engineer to develop, but it's arguably even less accessible to other engineers and scientists to add their contributions. This creates an issue where the tools remain as good-looking toys that never get any serious technical chops.
Splitting the implementation is the way to go, but neither side would be happy about the interface. There's also the issue of platform because good engineering tools only run locally.
I don't know what the answer is, but it's not Python. We already have python, and yet, there isn't an explosion of collaboration to make great tools for the physical sciences and engineering. It's too much of a compromise for both sides.
> I don't know what the answer is, but it's not Python. We already have python, and yet, there isn't an explosion of collaboration to make great tools for the physical sciences and engineering. It's too much of a compromise for both sides.
I would argue that python is actually ideally suited as a solution for many if not most things, just because there isn't large adoption in a subgenre of engineering, doesn't mean it isn't the right solution.
The primitives are there, its easy to comprehend, and there is a large amount of adoption in the scientific community outside EE.
I see lots of stuff that used to be done in things like matlab or mathmatica being done in python directly these days. At least at one of the places that I worked at, where we were a huge matlab shop for doing model design / algorithm simulation, has migrated most of their stuff to python.
Things like antenna design, RF simulation and a number of other things have a lot of of folks writing python code.
Are any of those examples successful open-source projects with both the computation and the GUI written in Python? I don't know of anything in any field like that.
I think you misunderstood me. The choice of tools for front and backend have to be independent. The only really successful projects implemented in one language are all in C++, and that's difficult for everyone to approach.
I may be confused as to what you mean by GUI in this context. If you are talking about a data exploration GUI... many, many scientists and physical science engineers use Jupyter/JupyterLab as a frontend for data exploration. This largely replaces the need for something like matlab.
If you are talking about practical implementation of those models, I have seen many non open source projects use those backends (things like pandas, sklearn, etc.) with things like django or flask as a frontend.
Circuit simulators are awesome, but they never go the next step such that they work with actual purchasable components. The user always has to read datasheets and translate everything into spice parameters.
Also, they typically don't allow the user to specify maximum power for every component and check that the voltages and currents are within safe limits.
This "next step" is really on the vendor/manufacturer instead of simulator developers. It won't be addressed, either, because it's extra development and cost for the vendor to bare when a lot of low cost/generic applications won't benefit from having simulation files. Additionally, it's a lot more work for the vendor to characterize and also guarantee that their products are close in value after years of production. Some datasheets are very sparse not by mistake - they promise you exactly as much as the datasheet, no more no less (for reputable vendors anyway).
The Micro-Cap simulator has the smoke test feature, for example. It's now abandoned and free for download.
It depends on the circuits. Some are highly dependent on certain characteristics of the part that might differ between different series of the actual part.
With time you gain the experience to know which circuits are problematic and which are easy-going.
If you buy modern power electronic semiconductors, you can usually find so m spice models from the manufacturer (though they do indeed typically not model thermals).
Spice models are not easy to find, in my experience. Given some random transistor on Digikey, I'd say the odds are less than 20% that I can find the corresponding spice model.
I sometimes wanted an OCR-like tool to transform an image of a schematic into one importable to Spice or other tools. That would save a lot of time entering it. Although I wonder if there is still a time for such a specialized tool since soon GPT-4.X may be able to explain and simulate circuit schematics.
I used this app in college back when it was a Java Applet - it helped me greatly in overcoming gaps in my intuition about analog circuits, even though the models used are relatively simple.
I've used this so many times on professional projects, if I'm in a computer without any other sims.
It's not accurate enough to 100% rely on, but it's good enough for simple stuff that I could do without a sim, but prefer to have at least some kind of review on my work before I actually send off for board.
Absolutely amazing! I feel like this could be nicely packaged into a proper product, along with a teacher's guide and then sold to schools. I feel like a lot of people have given up on fundamental electronics as there's just so much other stuff to spend time on, stuff like this could make it a tiny bit more approachable again.
This website is just amazing... Had I had this in the early 00s when I was studying electronics... Transistor circuits just make sense. And the number of already-setup examples is great.
Can anyone point me to a browser physics workbench. Like I was to b stack things, give measurements to cuboids etc for quick visualization with realistic physics sim in 3D
Yeah - ChatGPT4 & Alpha's circuit design remains atrocious on all levels that it is possible to be atrocious on like substance, lack of this circuitjs-like interactivity, UX (ascii diagrams? Really?). I'd like to see sources like circuitjs, CircuitHub, or Octopart produce a plugin for it (and find some way to monetize / justify it)
I just used it about 43 hours ago to get an understanding of a circuit idea I had ([1] being the secondary of [0], so that the abstracted switch (some bidirectional transistor approach of still-unclear nature; suffering so much ripple (+- half input voltage) requires this rippling to be low-loss) in the center can turn on with no voltage across it), which was to use loose coupling between the inductors of the phases of a modified 3L-FC buck [3] (running in divide-by-two mode as a switched capacitor converter; plans are 5 phases at 6.7 MHz for the half-bridges and 27 MHz for the resonant inductors), that has been modified by splitting the flying capacitor into two series capacitors and placing an auxiliary switch in series with an inductor between the center of the flying capacitor and the output of the 3L-FC (in a buck, that would go through an inductor and then to an output smoothing capacitor; I only aim for a 2:1 DC/DC transformer so output voltage will be a little below half the input voltage (difference is due to resistive losses in the half bridges that mostly cover up the ripple losses of the flying capacitor)).
This auxiliary switch was initially meant to block only half the output voltage and use the inductor as an LC resonance with the output capacitances of the half bridges to flip them around after they just calmly turned off.
The calm turn off is fading over input/output currents of the converter to other phase(s) of the converter; this is to virtually eliminate any (inherent) need for filter capacitors at the input and output of the converter by ensuring the phase currents, when added up, result in a time-invariant current for the converter as a whole (like how 3-phase grid supply theoretically (i.e., with active power factor correction) doesn't need the (mains-side) smoothing capacitors in a computer power supply, because a the (virtual) resistor the grid operator prefers to see has constant power draw from the grid).
The issue was that the auxiliary switch still suffered from hard-turn-on (i.e., no ZVS-on for it) which turns out to be somewhat of a problem when the goal is to take in e.g. up-to 60kV (+20% peaks/surges on top of 50kV nominal) from an MVDC line, and convert it down to something a "just" 1.6 MW induction motor with it's inverter can comfortably handle (e.g. situation in a Siemens Vectron MS, except that those only go up to 25kV AC): the first stage would take in 60kV, output 30kV, and that switch would have to block +- 15kV.
At the expense of the auxiliary switch seeing up-to full output voltage, sightly coupling the inductors across phases should allow the coupled fraction of the full current of the phase who's auxiliary switch is currently on to fully charge/discharge the much smaller output capacitance of the auxiliary switches in the other phases while the entire current in itself charges/discharges it's own [phase's] half bridges.
I'm sorry the switches in the falstad links aren't automated; the modified 3L-FC switches between which of the two controls is on, and briefly activates the center switch while both control inputs are off.
The weakly-coupled transformer has one activate the switch when the red graph gets closest to the 0V center line, and deactivate it when the yellow current in the same scope has completed the sine-half-wave/crosses the 0A center line the first time (again) after the switch was activated. The result should be that the green voltage across the simulated output capacitance of the half bridges on the right scope transitions quickly to the other polarity while the switch is active, and then stays there with only mild ripple until the switch is activated again. I believe in the 5-phase converter it would be activated not the first time afterwards the red goes back to (almost) zero, but the one second time, so the (with-switch-active) current half-waves are distributed round-robin.
I love this tool because you can export links or export circuits as text files.
Clock circuit I made that uses faster and slower buttons to adjust the speed: https://tinyurl.com/2nvlulfl
8-bit binary multiplier (LSB on top): https://burlette.net/multiplier.txt