[Ktechlab-devel] New guy <--

[Glen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Well, I was thinking that before a half million components are made, the
simulation engine should be as generalized as possible. The more general
it is, the more flexible the component libraries can be, imo.

I've been through the feature requests and I have a few of my own.
Spectrum analyzer, transformers (air core, ironcore, pot, toroidal,
etc), with configurable primaries and secondaries, etc., etc. But before
new components are added, a new way of adding them seems worthwhile.
Basically I'm just looking to start a discussion on how people would
like to see it organized.

G.


Alan Grimes wrote:
> Glen wrote:
> 
>> Hi there all. I just discovered ktechlab yesterday as an option to
>> install into a Ubuntu system.
> 
>> This looks like... it has a TON of promise. I love the real-time
>> oscilloscope and the simple way of dragging a component and hooking it up.
> 
> It's more of a chart recorder than a 'scope but it is fairly useful....
> 
>> I've been reading the archives and I'm glad it's been resurrected from
>> the dead. I *also* want to get vacuum tube / valve diodes, triodes, and
>> pentodes implemented ;) I'm pursuing simulation of analog audio circuits
> 
> I'm working on a class AB1 2A3 push-pull design. I've selected a design
> based on the voltage gain and driver stage in Morgan Jones' Crystal
> Palace amp.
> 
> Open problems in the design is the input stage... I want to support both
> balanced and single ended input and there's also the problem of feedback
> because I'll be pushing the output stage into AB1, I need to use
> feedback to moderate the distortion...
> 
> 
> 
>> The rest of the EDA stuff on GNU/Linux systems, like gEDA, are a nasty pain
>> to use.
> 
> ;)
> 
>> I've got some C++ background mostly in QT3, a bit of OGL, and I'm a
>> professional tech doc writer for a living who is very impatient with
>> software so I tend to simplify the interfaces I write to the bare
>> minimum while remaining complete. I'd love to contribute; this is a
>> sweet-looking project.
> 
> Welcome aboard.
> 
>> So the question is, what should I do and where should I start?
> 
> here's the biggest bug I'm seeing on my machine...
> 
> I have this simulation of my father's Harman Kardon 430 (from 1974)...
> The amp works (even though it doesn't seem to for the first few
> minutes... the real amp takes about 30 seconds for the input
> differential amp to un-clamp... =\
> 
> the problem is when I go to save it and load it, the entire circuit is
> messed up. 2/3rds of the connectors are gone, there are a lot of
> dangling junctions.... Undo/redo creates a similar effect. The problem
> must be in the document heirarchy, It's all based on QT's DOM/XML engine.
> 
> On the simulation engine, an important issue is that temperature is
> currently a constant. Temperature is an important variable in solid
> state circuitry, my harman kardon sim, for example, can't simulate the
> thermal diodes that are used to throttle the power stage. My idea was to
> implement heatsink domains so that all components in that domain are
> simulated at a temperature based on the total power dissipation in that
> domain scaled by the heatsink coeficient...
> 
> In classic electronics, the issue is how emissive the cathode is... This
> is an issue as the device warms up...
> 
>> Incidentally, would there be any plans to implement free-rotation, so
>> that the diodes in my bridge rectifier can actually be placed in the way
>> they are normally drawn on a schem? gschem doesn't do it and I think
>> qucs doesn't either.
> 
> The most important issue right now is to implement multiple winding
> inductors, IE transformers... That's a serious deficiency at present...
> 
> [later]
> 
>> Is there any direction / ideas for what direction the simulator should
>> go?
> 
> I've made some proclamations, but those are only directed at people who
> don't have their own ideas. ;)
> 
>> I have my own ideas, especially now since I've probed the code a
>> little bit, but what's really better for the project?
> 
> Lay them on us!
> 
> What's best for the project is that you get hooked on tweaking stuff....
> 
> 
>> What would people like to see it do beyond what it does now?
> 
> me need triode. ;)
> 
> Seriously, we need to implement a components database. The worst will be
> configurable devices that might have variable numbers of grids (with
> variable densities), and inductors with variable numbers of coils with
> variable numbers of turns...
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJE5qxLstl3vProOARAkqzAJ91pSyXGWNlsaLXrig6wAbENTa94gCcDmGP
H/3HBgM1dkMYOjZ9fgXvEJU=
=YBOL
-----END PGP SIGNATURE-----