Standard, platform independent simulations for DIYAudio - Page 3 - diyAudio
Go Back   Home > Forums > Design & Build > Software Tools

Software Tools SPICE, PCB CAD, speaker design and measurement software, calculators

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 6th February 2014, 02:45 PM   #21
diyAudio Member
 
keantoken's Avatar
 
Join Date: Aug 2006
Location: Texas
Blog Entries: 2
Quote:
Originally Posted by spookydd View Post
Be careful though, the part's name could become a bit too long and that's a lot of noise on a schematic.

ltspice has a built-in few extra parameters in the models for things like vce0 and other such things, plut one that we could easily use without making a long part name that shows up on the schematics, it's the manufacturer name. How about using that?
These are exactly my thoughts. I already don't like the use of suffixes as they are. The model names should match the part exactly; schematics are not just for simulation, they are for publication as well. One of the great things about a standardized setup like this is that we can cut out lots of redundant intermediary steps which slow down the process of, say, importing a netlist to a PCB editor and having everything go right the first time, even having the PCB program choose all the correct transistors and pads automatically.

The only reason we are using suffixes in the first place is because the standard model sets are terrible and we have to make the good models stand out somehow, so neither us nor the simulator confuse it for a faulty model.

That's one of the very reasons this project is needed. There's no point in having faulty models in a simulation library - that is totally unacceptable. With those completely out of the way, we no longer need to work around them.

We need to put that behind us. We need to replace the discrete model libraries of LTSpice from the outset with a library of properly vetted models. We will need to keep a "dirty" library alongside in case there is no model, but it has to be heavily isolated, and shouldn't touch the project unless specifically included by the user.

There is also a way that we could seamlessly import schematics using the dirty models. The "ako" parameter in a .model statement makes it a copy of another transistor. For instance:

.model BC560C ako:BC560C_C

BC560_C -> BC560C

.model Q2SC5200 ako:2SC5200_K
.model FJP5200 ako:FJP5200

2SC5200_k -> Q2SC5200 = FJP5200

This is how I switch models over to my kean.bjt library when someone sends me a simulation. You could write a whole list of these to a modelimport.lib file and then put '.inc modelimport.lib' on the schematic of a non-standardized simulation. Again, this would remove all the steps of clicking and changing each model, and is something anyone could do.

It is important to consider that LTSpice as well as being a simulation is also a structured simulation program. It has its own system. The problem is, the discrete models are faulty most of the time so even if the system works well, the result will be garbage. We need to take advantage of LTSpice's built-in system rather than trying to subvert it. This will make simulation more intuitive with less need to reach into the engine to start the car.

About the mfg model parameter. This parameter might be used by some PCB or BOM programs, so ideally it would reflect the actual manufacturer. Is there another parameter we can use? What about inline comments? For instance:

.model Fake NPN(params) * demonstration model by keantoken

Where the * tells the simulator everything after that is a comment. So here we go: let's make a standard format for models that again, suits our needs. Taking advantage of SPICE syntax, we can format models in a human-readable way that allows us to put comments inline with the model:

.model Fake NPN (
+ * Fake demonstration model by keantoken of DIYAudio
+ * human-readable SPICE model with infotext
+ * Version 1
+ Hfe=100 Re=80m )

This way, the comments are inside the model and are unlikely to be separated from it. We can add all the info we need and leave the SPICE parameters alone so they can do the job they were intended for.
  Reply With Quote
Old 6th February 2014, 03:22 PM   #22
diyAudio Member
 
Join Date: Apr 2012
Location: Florida & France
Quote:
Originally Posted by keantoken View Post
intermediary steps which slow down the process of, say, importing a netlist to a PCB editor and having everything go right the first time, even having the PCB program choose all the correct transistors and pads automatically.
I didn't think about pcb programs, as it's not so easy to have everything well integrated. But that would be nice. I use eagle. Perhaps a good script could help integration. I tried that new eagle ltspice integration and it really didn't provide anything useful, it's broken.

Quote:
Originally Posted by keantoken View Post
of LTSpice from the outset with a library of properly vetted models. We will need to keep a "dirty" library alongside in case there is no model, but it has to be heavily isolated, and shouldn't touch the project unless specifically included by the user.
That would be nice. I've been fussing about having to search and switch models all the time. There is one issue with ltspice that bothers me: it can only give models for insertion from its own databases and when I used .include or .lib, those models in those libraries don't come up as available to put in schematics. And when we add models to the main libraries and have to embed them into the schematics for sharing, we get a bunch of warnings for duplicate models.

Quote:
Originally Posted by keantoken View Post
There is also a way that we could seamlessly import schematics using the dirty models. The "ako" parameter in a .model statement makes it a copy of another transistor. For instance:

.model BC560C ako:BC560C_C

BC560_C -> BC560C
I didn't even know this existed, but obviously there is still a lot about lyspice that I don't know about. This could be good and it would simplify things.

One question comes to mind though, as I just mentioned above, when we send out a schematic for someone else to simulate, the models should be embedded so that simulation runs the same everywhere. So how can this be handled?

Quote:
Originally Posted by keantoken View Post
About the mfg model parameter. This parameter might be used by some PCB or BOM programs, so ideally it would reflect the actual manufacturer. Is there
One other thing I didn't know and think about, but sure, when integrating with a pcb program, this needs to work.

Quote:
Originally Posted by keantoken View Post
go: let's make a standard format for models that again, suits our needs. Taking advantage of SPICE syntax, we can format models in a human-readable way that allows us to put comments inline with the model:

.model Fake NPN (
+ * Fake demonstration model by keantoken of DIYAudio
+ * human-readable SPICE model with infotext
+ * Version 1
+ Hfe=100 Re=80m )

This way, the comments are inside the model and are unlikely to be separated from it. We can add all the info we need and leave the SPICE parameters alone so they can do the job they were intended for.
Ok, the comments are probably the way to go and would leave the mfg param do its job. However when I embed models into a schematic for sharing, I don't like the multiple lines of comments and a model spanning too many lines, as those really blow up the visual size of the schematic on the screen. When hitting the space bar to view a whole schematic, and the models are using up a lot of space, then we see a smaller schematic and too much noise from models.

I have been reducing the font size on some models embedded in schematics so they would not bother me as much when hitting the space bar to see all.

This is good, a serious discussion with many opinions considered and something really nice can come out of it.
  Reply With Quote
Old 6th February 2014, 04:00 PM   #23
diyAudio Member
 
keantoken's Avatar
 
Join Date: Aug 2006
Location: Texas
Blog Entries: 2
I think you could put the model library inline with the netlist, and provide everything necessary along with the file. The problem however is that when the user tries to change or modify the schematic, the default simulator action is to use it's own faulty libraries and whatever the other user has put in it. We can't expect anyone to have studied all the models they've gathered for correctness, or to NOT have downloaded all the messed up model libraries from manufacturers. Years of simulations on DIYAudio have shown us this.

Many people seem to be comfortable with running simulations with the first models they can find and if it gives the wrong output, "it's the simulator's fault, or "simulation is a flawed concept".

When you are working and sharing with others and intended to get a real, practical result, all these problems just blow up and it wastes your time and everyone else's. Everyone is afraid of sharing their simulations because they don't want to go through the tedious process of getting the simulation ready. So many people don't even know HOW to do that. Even those who DO know how, forget something the first time and then have to do it again. No one wants to suffer the embarrassment or inconvenience of this process. Really, LTSpice should have this function built in, and I consider this a capital design flaw.

Imagine a world where sharing a simulation is as easy as clicking a button, choosing the simulation, and uploading the file. No preparation needed. No embarassment. It works every time because the simulator is set up to make portable simulations by default, and break portability only by explicit user directive.

People don't miss what they don't see, and this is one of those things. The trick will be making the kit so seamless and convenient, that all the previous SPICE users will want to switch to it. Portable standardized SPICE simulations should be the norm, not the exception. As it is, LTSpice already has many inconvenient aspects, and I don't think it should be hard to improve on that.
  Reply With Quote
Old 6th February 2014, 04:07 PM   #24
diyAudio Member
 
keantoken's Avatar
 
Join Date: Aug 2006
Location: Texas
Blog Entries: 2
My idea was to replace standard.bjt with our library so it would be working with the simulator. This is what my model shows when I add it to the standard.bjt.

As far as adding this to the schematic of a simulation, yeah, it will get in the way. If you add it to the netlist manually however, I don't think it will show up on the schematic. Still, it won't be selectable from the GUI. You'll have to change the BJT name manually in order to use it.
Attached Images
File Type: png Model_Selector.png (8.7 KB, 155 views)

Last edited by keantoken; 6th February 2014 at 04:10 PM.
  Reply With Quote
Old 6th February 2014, 04:17 PM   #25
diyAudio Member
 
Join Date: Apr 2012
Location: Florida & France
The best way would be to do that then, change that standard.bjt, so all and only the model we want show up and are usable by the gui and when those who share the simulations are also using the same bjt file, then all should be well.

This is coming together.

I can't wait to also see some oddities being solved on the mac version, so we can do everything without needing windoze.

One thing that I also thought that should be available with the database and management system for models, is a model request system, so when we need one that's not in the "good" database, we can post a model request and hopefully what we need will be quickly found and made right.
  Reply With Quote
Old 6th February 2014, 04:32 PM   #26
diyAudio Member
 
keantoken's Avatar
 
Join Date: Aug 2006
Location: Texas
Blog Entries: 2
Model requests could be handled like feature requests in a VCS like Git. VCS provides all the functionality for keeping track of versions, tracking features, bugfixes, and so on. The important thing is to make it easy to submit requests and bugs, and that all the submissions go to a central place such as a Git server where everyone can see them.

I wonder if it would be possible to get the Mac version to work on Linux, since they are very similar. That begs the question though, if there is a Mac version, where is the Linux version?
  Reply With Quote
Old 6th February 2014, 04:42 PM   #27
diyAudio Member
 
Join Date: Apr 2012
Location: Florida & France
Quote:
Originally Posted by keantoken View Post
I wonder if it would be possible to get the Mac version to work on Linux, since they are very similar. That begs the question though, if there is a Mac version, where is the Linux version?
From what I understand, this mac version is not a wine "bottled" version that still has windoze underpinnings, and it's supposed to be native.

This would logically mean that its unix based underpinnings are very similar to linux's, however the gui doesn't look and feel at all like an X11 based one, it really does feel like the real mac, which is the way it should be, so it may be using gui libraries that are mac specific and that's not usable on linux.

Perhaps asking the guy who writes it? (is that Mike? as I understand it...)

There may be a linux version already, or in the works though...

Using wine isn't a good solution and it's only good temporarily.
  Reply With Quote
Old 22nd February 2014, 04:26 PM   #28
diyAudio Member
 
Join Date: Apr 2012
Location: Florida & France
Is there anything I can do to help get this model repository come to life?
  Reply With Quote
Old 22nd February 2014, 04:27 PM   #29
diyAudio Member
 
Join Date: Apr 2012
Location: Florida & France
There is one model I was trying to find, perhaps I'm hoping for something that's not available. I would like a bridge rectifier, such as the BYW62 for example. I couldn't find anything, not even similar.
  Reply With Quote
Old 23rd February 2014, 11:22 AM   #30
diyAudio Member
 
keantoken's Avatar
 
Join Date: Aug 2006
Location: Texas
Blog Entries: 2
I asked to split this thread, so now it has it's own place.

The most basic step we can make that gets this running immediately is to make a zip file with a structure that mimics the LTSpice directory tree. Then the user simply unzips it over a new LTSpice installation, and it replaces all the relevant files. Instant installation. For instance:

Code:
/lib/					Obviously, for libraries, symbols, models, subcircuits...
	/lib/sym/
		Signal.asy		full-featured signal generator - triangle, sweep, square, etc.
		Tnpn, Tpnp, Tnmos, etc.	Crude but effective real-time thermal models.
		Reworked symbols for basic components so that "standard" simulations stand out and can't mix with unstandard ones.
	/lib/cmp/
		standard.bjt and others (with our good models, and set to read-only)
	/lib/sub/
		subcircuits for Signal.asy, thermal semiconductor models, etc.
		
/templates/				Template schematics containing all the relevant coding done for drop-in usage.
	Linear.asc			Basically ampsim5.asc; THD, noise, SNR, slew rate, and so on.
From here we can basically fill it full of stuff as long as it all works together and is portable and platform-independent.
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Voltage independent power load egberttheone Power Supplies 15 23rd February 2012 06:44 PM
Parallel woofers - independent filter? Aleph 5 Multi-Way 18 16th August 2011 03:57 PM
Foam or rubber, environment independent? buggsson Car Audio 3 10th December 2008 01:06 AM
Independent (floating) supplies akis Power Supplies 15 7th September 2008 01:25 PM
Independent Bias Adjust for Each Tube? TubeHead Johnny Tubes / Valves 4 24th February 2008 01:57 PM


New To Site? Need Help?

All times are GMT. The time now is 07:14 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2