Needing more than a spark test?

[WobblyHand]

I didn't look at what happened with mine, but would agree.
Something is still in a mess. You should not be dealing with 32-bit anything. It was called LTspice64.exe for a reason!
LTspice64.exe is 56.3MB.

My entire .wine folder is 16,667 items totalling 2GB on disk. That gives one some perspective on the other OS that runs this stuff.
Within that, the LTC program folder is 113.4MB as installed.
The parts library in that is 6881 items using 55.6MB.

Chase this down, because it does not make sense!
1.1GB is carrying something "else" with it, possibly stuff you would not want.

Beats me what is going on. Seems like there's an awful lot of crap that was necessary. Can't find any notes out there about something like this. I have wine 5.0 installed. Something is badly configured, probably the packagers defaults. Nonetheless, I have a copy of LTspice updated to Oct 2021, which is pretty good. At least the library is up to date, which is better than my previous installation. Wish there wasn't so much baggage needed! My LTC folder is the same size as yours = 113MB. .wine folder is 11,875 items, totalling 164MB.

Look and feel seems pretty dated. But it is a darned good simulator, so I'll keep it for a bit. Now I have to hunt down my old files...

 

[graham-xrf]

@WobblyHand : LTSpice has added it's graphical input, and little tools to edit values, invoke runs, etc. Underneath, it still is the Spice engine. They have added some "commands" of their own that can live in the the netlist. There are expansive explanations on the internet about it's history, the differences between it, and other "Spices", and which tool can incorporate it. A long time ago, other simulation tools have also sought to leverage matrix solutions for electric networks. There are even EDA schematic tools that can add in various Spices to provide simulation feature to their suite.
I have seen a Python script that can take a LTSpice circuit, and have the circuit be drawn KiCad EDA suite.

More commonly, the expansive open source SPICE simulator is ngspice, which is invoked by tools like Qucs, gEDA, and KiCad.
LTSpice was offered free as a switched-mode power supply design aid, with example circuits already loaded into the library, all using the company's products. Of course, for it to do that, it would also work as a general purpose electrical network simulator, and there were decades of available Spice models. The hard way was to make the simulator fight through simulating equivalent sub-circuits, but of course, the huge speed was gained by using math function generated outputs from models, bypassing the sub-circuits

For most of us, even though we are not as often into switch-mode PSU circuits, we can use LTSpice to at least get a design checked out enough to risk purchase of parts, and a prototype. It is just serendipity that Linear Technology joined with Analog Devices, and so we get all the transistors and op-amps from both companies provioded in the LTSpice library

 

[WobblyHand]

I've used Pspice, Orcad, KiCad, gEDA, TI's TINA, LTspice and a few others. Of all of them, I found Pspice easiest to use, especially adding or creating new models. Of course, Pspice went away, consumed by Orcad, who was in turn eaten by Cadence. Every generation of the program got harder and harder to use and exceedingly more expensive. Cadence made it excruciatingly painful to work with them. You had to prove you had your maintenance contract was current, before you could even look in their online reference materials. Basically a paywall to even see the documentation. Their web site was awful and designed to waste your time. Miserable, wretched company.

Gave it up for a while. Finally found some little company that was called 5spice who had a spice program for a minor amount of money. Used that for quite a few years. If I had a question on the tool, I could send an email and get a coherent answer within a day. Unfortunately, I think the gentleman stopped supporting the product in 2018. Was a pity, as it was a very good value.

So LTspice, is a relative breath of fresh air. It works, and isn't too hard to use. If you need help, you can actually send a message to them and get a thoughtful answer, without waving around a paid multiple $1000 maintenance contract number. As you noted, Analog Devices purchased Linear Technology, and just last year they bought Maxim. So hopefully there will be even more parts added to the library. One can add "foreign" models to the program without a horrible fuss. So, LTspice is really quite good. My only (minor) complaint are the fonts, which make it harder for these aging eyes to see.

Sorry for the sidetrack. Back to circuits and housings and machining.
Edit: changed a company name.

 

[homebrewed]

I've found it is pretty easy to use third-party SPICE models in LTspice. I got a model for the LMC662 so I could simulate the analog portion of the PocketGeiger and results look OK to me. Of course, the accuracy of your results depends on the quality of the model. I haven't tried a noise simulation so have nothing to say there.

Also, not all ADI amplifiers are in the LTspice library. Not too surprising, considering how many devices they offer. It will be interesting to see if program updates start to include Maxim parts. I have a particular interest in that regard because I worked for Maxim up to October, 2016. I worked in their failure analysis lab and got to work on a huge variety of devices -- analog, digital, RF, A/D, D/A, you name it. Prior to that, I worked in the Tektronix FA lab.

 

[WobblyHand]

@graham-xrf tried modeling your circuit. The second pulse param setting. Seems to be taking forever. Do you happen to know what you changed to get things to speed up? A configuration setting, or an initial condition? The sim is using quite a few cores, but I can't interpret how much longer to completion. It's been many minutes, so I thought I'd ask. I initially ran it with the shorter pulse, but cancelled the sim. The pulse shape looks wrong, so I must have interpreted something incorrectly.

Hadn't seen that offset ground done that way before. Did you change ground? Sometimes that messes up spice. Kind of just copied the schematic without much thought so see if I could get something out of it. Going to require a bit more finesse than that, I can see!

It's a convergence/initial condition problem. Tried a 10G to ground on the Iph side of the cap, but that isn't doing it. Nor is adding cshunt=1e-15.
Gee, it's only been a year since I last simulated, forgetting things already .

Kind of confused why the Pseudo-transient analysis is showing 132ms, so far, when I have the directive .tran 0 20u 0 20n. Dang, hard to get back doing this stuff! Going to have to try some simpler stuff first! I need to get the pulse to work right, it isn't as expected.

Fixed the issue. This version of spice does not like your schematic. I changed the ground symbol to Vb, because it really is a bias voltage, and connected Vss to GND. When I did that, the circuit converged. Prior to that, I could even get a DC operating point. I get a pulse now. One thing concerns me is the DC operating point of the capacitive input to the first stage is a ridiculous 76kV. This is due to the 2mA current source across a 40Meg resistor. Guess this is part of your diode model, to get the right characteristics.

 

[homebrewed]

Good tip on getting the PocketGeiger from Sparkfun. Looking at the Sparkfun schematic, it appears nearly the same as the schematic I posted, with the first two amplifiers. (Same part number! Same basic idea.) It is nice that they showed the resistors in series for the first stage, so it would reduce the capacitance. The schematics differ in the output drive, being a comparator. Actually there are two comparators, each with a different threshold. One is filtered (the signal) with a fat cap across the comparator output (which isn't great practice) and the other without a cap (noise detections?).

What are you doing after the first two amplifiers?

FYI, the comparators on the PocketGeiger are open-collector devices. So the capacitor on the output really is a poor man's pulse stretcher. It took me awhile to figure that one out. Then it was a moment....

 

[homebrewed]

@graham-xrf tried modeling your circuit. The second pulse param setting. Seems to be taking forever. Do you happen to know what you changed to get things to speed up? A configuration setting, or an initial condition? The sim is using quite a few cores, but I can't interpret how much longer to completion. It's been many minutes, so I thought I'd ask. I initially ran it with the shorter pulse, but cancelled the sim. The pulse shape looks wrong, so I must have interpreted something incorrectly.

Hadn't seen that offset ground done that way before. Did you change ground? Sometimes that messes up spice. Kind of just copied the schematic without much thought so see if I could get something out of it. Going to require a bit more finesse than that, I can see!

It's a convergence/initial condition problem. Tried a 10G to ground on the Iph side of the cap, but that isn't doing it. Nor is adding cshunt=1e-15.
Gee, it's only been a year since I last simulated, forgetting things already .

Kind of confused why the Pseudo-transient analysis is showing 132ms, so far, when I have the directive .tran 0 20u 0 20n. Dang, hard to get back doing this stuff! Going to have to try some simpler stuff first! I need to get the pulse to work right, it isn't as expected.

Not sure why your transient analysis is going out to 132ms either. I'd guess you have some other time-related parameter that's messing up the simulation time.

Regarding convergence, using an opamp to generate Vcc/2 just throws more stuff at the simulator to solve. For quick & dirty I just use another voltage source. Not to say that this approach will solve your problem, but it's worth trying.

 

[WobblyHand]

Not sure why your transient analysis is going out to 132ms either. I'd guess you have some other time-related parameter that's messing up the simulation time.

Regarding convergence, using an opamp to generate Vcc/2 just throws more stuff at the simulator to solve. For quick & dirty I just use another voltage source. Not to say that this approach will solve your problem, but it's worth trying.

Was the misuse of "ground". @graham-xrf had a tricky circuit whose ground symbol was attached to 0.4V. My copy of spice didn't like it! Caused all sorts of convergence issues. Clues were the OPamp nodes were having singularity issues. I just redid the circuit in a more conventional way and called this new voltage Vb and attached it to the nodes. Then all was fine. Equivalent circuit that spice thought was ok. I get a pulse of roughly 60 mV for a 500pA exponential pulse similar to what Graham posted. This was an exercise to get me back in the saddle.

I too, usually start out with a voltage source. However, I have found when you do the real thing, with an op amp, you can run into surprises. My radar frontend had this issue. Had to simulate it so I could fix it. Turns out it was a bad choice of op amp (TLV2461) for a simple voltage follower reference. Used a better op amp, an AD8031 and it was a significantly better source. Couldn't get the TLV2461 to behave well in circuit. Sim showed it had issues. Sim'd the AD8031 and with minor changes it was much better. Real circuit works in practice, so I called that one a win.

 

[graham-xrf]

@graham-xrf tried modeling your circuit. The second pulse param setting. Seems to be taking forever. Do you happen to know what you changed to get things to speed up? A configuration setting, or an initial condition? The sim is using quite a few cores, but I can't interpret how much longer to completion. It's been many minutes, so I thought I'd ask. I initially ran it with the shorter pulse, but cancelled the sim. The pulse shape looks wrong, so I must have interpreted something incorrectly.

Hadn't seen that offset ground done that way before. Did you change ground? Sometimes that messes up spice. Kind of just copied the schematic without much thought so see if I could get something out of it. Going to require a bit more finesse than that, I can see!

It's a convergence/initial condition problem. Tried a 10G to ground on the Iph side of the cap, but that isn't doing it. Nor is adding cshunt=1e-15.
Gee, it's only been a year since I last simulated, forgetting things already .

Kind of confused why the Pseudo-transient analysis is showing 132ms, so far, when I have the directive .tran 0 20u 0 20n. Dang, hard to get back doing this stuff! Going to have to try some simpler stuff first! I need to get the pulse to work right, it isn't as expected.

Fixed the issue. This version of spice does not like your schematic. I changed the ground symbol to Vb, because it really is a bias voltage, and connected Vss to GND. When I did that, the circuit converged. Prior to that, I could even get a DC operating point. I get a pulse now. One thing concerns me is the DC operating point of the capacitive input to the first stage is a ridiculous 76kV. This is due to the 2mA current source across a 40Meg resistor. Guess this is part of your diode model, to get the right characteristics.

The thing about modeling circuits is that, like all apps that have to deliver real numbers, it requires meticulous attention to the handling of numbers, care in avoiding divide-by-zeros, and variable time-step convergence traps. Calculations (like ours) that span 12, or even 15 orders of magnitude, and have to use real numbers in the network matrices, without the benefit of human convenience compressions (like dBs), are a case in point. My most recent photon stimulation input circuit is only 20 pico

I have at least a couple that run into never-never land, probably calculating with tiny time steps in a futile attempt to get an answer to "converge", which it won't because the resolution is below the tolerance. I find that when I abort the calculation, there are my results anyway, Spice was banging about near zero!

Here's a tip:
For the session, use Tools -> Control Panel , and open the "Compression" tab.
Set the Absolute Voltage tolerance from 1e-005 to 4e-008
Set the Absolute Current tolerance from 1e-009 to 5e-011
In my experience, the thing suddenly starts zipping along at some speit stopped getting stalled.
It pisses me off that those settings are not remembered between program invocations.

These fixes are somewhat gross, and not thought out. At least one I thought was stuck - did finally produce an answer.
Just because I am in a hurry, I don't do too much diagnosing why a particular SPICE run gets in a tangle.
I divide and conquer. I don't put the whole circuit in, having to recalculate waveforms of previous designed sections. Instead, I conjure up little math-derived substitution circuits.

When it is oscillating! I start it, I wait for 10 seconds, watching the time step, get impatient, press Esc, and put the probe on the output to discover it's oscillating like a multivibrator.

I will post some working (and problematic) simulations soon. They are .asc files. I am not sure is HM accepts those. If not, we send as .txt and rename them.

 

[WobblyHand]

The thing about modeling circuits is that, like all apps that have to deliver real numbers, it requires meticulous attention to the handling of numbers, care in avoiding divide-by-zeros, and variable time-step convergence traps. Calculations (like ours) that span 12, or even 15 orders of magnitude, and have to use real numbers in the network matrices, without the benefit of human convenience compressions (like dBs), are a case in point. My most recent photon stimulation input circuit is only 20 pico

I have at least a couple that run into never-never land, probably calculating with tiny time steps in a futile attempt to get an answer to "converge", which it won't because the resolution is below the tolerance. I find that when I abort the calculation, there are my results anyway, Spice was banging about near zero!

Here's a tip:
For the session, use Tools -> Control Panel , and open the "Compression" tab.
Set the Absolute Voltage tolerance from 1e-005 to 4e-008
Set the Absolute Current tolerance from 1e-009 to 5e-011
In my experience, the thing suddenly starts zipping along at some speit stopped getting stalled.
It pisses me off that those settings are not remembered between program invocations.

These fixes are somewhat gross, and not thought out. At least one I thought was stuck - did finally produce an answer.
Just because I am in a hurry, I don't do too much diagnosing why a particular SPICE run gets in a tangle.
I divide and conquer. I don't put the whole circuit in, having to recalculate waveforms of previous designed sections. Instead, I conjure up little math-derived substitution circuits.

When it is oscillating! I start it, I wait for 10 seconds, watching the time step, get impatient, press Esc, and put the probe on the output to discover it's oscillating like a multivibrator.

I will post some working (and problematic) simulations soon. They are .asc files. I am not sure is HM accepts those. If not, we send as .txt and rename them.

My copy of LTspice seems quirky. The help file didn't install correctly. I have the index and table of contents, but if I click or double click, the page is blank.

If I set the resistor to 1Meg the simulation goes into simulate every ps mode. But 1.0001Meg doesn't do that, nor 999.9k, they simulate in a second. Got some bizarre saturation effects, but they went away when I changed the voltage divider ratio. I have my bias for the LTC6269 at about 1.65V. Seems to work ok.