Main Course
Here's a circuit:
- and here's its SPICE model:
***
.INCLUDE la-components.mod
Rsrc 1 0 100E3
Rin 1 2 1E3
Rfeed1 2 3 10E3
Q1 3 0 4 BC109
Q2 3 0 4 BC179
Rfeed2 3 4 10E3
Xopamp 0 2 5 6 4 TL071
Rload 0 4 10E3
Vcc 5 0 15
Vee 6 0 -15
Vsrc 1 0 SIN(0V .1VPEAK 1KHZ)
.TRAN 10US 1000US
***
The .INCLUDE is as it sounds, the contents of that file are included in this model. After that it's describing a graph with two kinds of nodes: those associated with a component and connection nodes (i.e. common terminals/points/buses/PCB tracks...). Although the components kind-of contain arcs, they're hidden behind the component's connectors. The component's connectors are identified by their position in the space-separated data. On the schematic the nodes are marked in red.
Taking the first line:
Rsrc 1 0 100E3
This is interpreted via :
(a Resistor) <name> <node1connection> <node2connection> <value>
Rsrc is a 100k resistor connected between nodes 1 and 0
(Node/bus 0 is always ground)
Taking the first of the transistors:
Q1 3 0 4 BC109
a transistor of type BC109 called Q1 has its collector connected to node 3, base to node 0, emitter to node 4
The .TRAN line is used to run a simulation (a transient analysis), sampling every 10uS for 1000uS. I've not really figured out this side of things properly, couldn't get a straight .DC based transfer chart. But the sine wave will do for now.
Anyhow I can't go looking at a graph model for long without wondering how it could go on the Web. While there are no doubt loads of ways of doing it, the circuit definition can be transcribed into Turtle fairly directly. Bnodes could be used for the connection buses, but it's just as easy to name them. So making things up as I go along -
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix spice: <http://purl.org/stuff/spice/> .
@prefix u: <http://purl.org/stuff/units/> .
@prefix d: <http://purl.org/stuff/devices/> .
@base <http://hyperdata.org/circuits/logamp/> .
<http://hyperdata.org/circuits/logamp> a spice:Circuit ;
dc:title "Log Amp" ;
dc:description "a modified log function amplifier" ;
spice:components ( <Rsrc> <Rin> <Rfeed1> ... <N0> <N1> ...) .
# Rsrc 1 0 100E3
<Rsrc> a spice:Resistor ;
rdfs:label "Rsrc" ;
spice:terminal1 <N1> ;
spice:terminal2 <N0> ;
u:ohms "100000" .
...
that seems ok, now for a transistor:
# Q1 3 0 4 BC109
<Q1> a spice:BJT ;
rdfs:label "Q1" ;
spice:terminal1 <N3> ;
spice:terminal2 <N0> ;
spice:terminal2 <N4> ;
spice:device d:BC109 .
that'll do.
Doing a .INCLUDE in general could really do with something from RDF core (ping RDF WG), but here it's providing other SPICE definitions of the components so it seems reasonable to be more explicit:
d:BC109 rdfs:isDefinedBy <http://hyperdata.org/circuits/logamp/components#BC109> .
which given that SPICE supports subcircuits (which is how TL071 is defined) provides a nice composition mechanism.
I reckon it should be straightforward to write a transformer from SPICE syntax to Turtle. Going the other way, the usual SPARQLing shouldn't be rocket science.
All seems doable. Homework. Rainy day.
Starter
I want to play with analog electronics again, stuff I used to do before the Web came along and ate up my cycles. My motivation now is mostly driven by the price of recording studio equipment. If, for example, I just want to invert the phase of a signal, I'd need to pay say $50+ for a passive DI box or $100+ for a pre-amp. This is a bit demoralising when the components are available for pennies (though hardware like connectors and cases can cost a lot more). Then of course there's the circuit hacking angle, it really is good fun. A project that's a permanent fixture in this space is the distortion pedal (like ghard's Big Muff) - the circuits aren't complicated, but getting a good sound is the Holy Grail, so this is what I'm going to play with first.
I did buy a bunch of components a while back, but haven't got much in the way of prototyping/test gear. A cheapo USB ADC will hopefully do for a makeshift oscilloscope for now, and I've just ordered the parts to put together a simple PSU (along with *lots* of oddments). But feeling a bit impatient, I thought I'd have a quick look what software was available these days for circuit simulation.
I don't know if I'm missing something, but things hardly seem to have progressed at all in the last couple of decades (but then again analog electronics hasn't really changed). The de facto standard is SPICE, and there are quite a few tools open source available for using it (ah, things weren't open source back in the day, that's progress). I won't bother linking to the individual bits, if you look for 'spice' in Synaptics a bunch show up, and they all seem to come under the umbrella of gEDA. Anyhow, after an hour or so's fiddling I was able to draw a little circuit using gschem, but I haven't yet managed to get it to generate a working netlist file (which specifies the inter-component connections for SPICE). I think I just need to sit down and check/add all the component attributes. But that's a bit tedious so I've just been playing with a SPICE file manually. Praise be to text formats.
The first problem here was finding simulation definitions of the components I want to use. The little circuit I want to test includes a common op-amp (TL071) and a pair of transistors, one NPN (BC 109), one PNP (BC 179). Took a lot of searching, and although (allegedly) many of the manufacturers do provide SPICE modules for their components, I eventually found what I needed on hobbiest sites. (Making the component module files doesn't look too difficult, it'd mostly mean copying values from a spec sheet into a SPICE definition - again, sounds tedious).
There is GUI adapter for running simulations, gspiceui (which I must have another look at now I've got a working model), but with the amount of trial and error I was having to do I settled back into the command-line tools. For future ref. it goes like this:
ngspice <filename>
This loads in the file and starts up an interactive shell. Took me a long time to figure out what to do next, but here are a couple of bits that worked for me. Once in the shell:
ngspice 1 -> run
Runs the simulation (the .TRANS bit). Then:
ngspice 2 -> plot V(1) V(4)
Produces a plot like this:
Red is the input (voltage on node 1), blue the output (voltage on node 4).
Certainly looks like distortion...wonder what it sounds like...
Pudding
Finding stuff and looking up references in this space is still fairly Paleolithic, so there's one application of exposing this kind of material as linked (wired!) data. But there are probably stacks of other more inspiring apps. Going totally blue sky, a globally distributed circuit could be rather cool. In the digital realm you for example could have a global computer that's built from just a few simulated gates on each of a million interconnected PCs. Bit like an extremely dumbed-down Web service/agent kind of thing.
In the analog realm it could get very wacky. Host your own local circuit subsystem, connect it to anyone else's. I guess you'd want to connect your inputs to other folks' outputs and offer outputs of your own. As long as you are limited to connecting your inputs to the rest of the world (or more versatile, I can only connect my output to your input if I have the appropriate rights) then subsystems should play nicely with each other. I see no reason why for control and audio signals you couldn't do this in real-time using existing streaming audio protocols (codec'ing locally to PCM for the instantaneous values).
This is pretty much what I assume some of the net-based recording systems that are around are doing. I must confess I've never looked into these, trying to mimic traditional recording/mixing stuff that way seems a bit of a non-starter because of the latency issues. But flipping it to a messier, slightly bonkers [insert pun about bipolar transistors] global analog synth kind of idea, then it starts to sound more fun.
FOAF Profile
Feed
Google Plus
Twitter
Facebook
LinkedIn
Flickr
YouTube
slideshare
del.icio.us
GoodReads