Another system was the one produced by Philips / Schuco. I had one as a child and I hated it. It was such a pain to remove those springs and insert anything into them. It came with a plastic tool to assist with this, but that barely worked. And I also remember it not being much fun. A schematic, a few words, but not much on how things actually work.
This FM radio module for example. Every electronics kit had to have a few radio experiments. They often were the highlight of the whole thing. Philips' take on it was to use this TDA 7000. It integrates everything for a superhet, the input stage, the mixer, the LO, IF, demodulator. All you need is a few additional components and an audio amplifier to make it sing. Almost guaranteed, low frustration risk, instant gratification. But boring.
Philips / Schuco had a whole stack of sets and supplemental sets. FM radio, fiber optics, digital electronics, feedback control systems...
Philips/Schuco vs Kosmos is like Playmobil vs Lego. Playmobil is nice, if your play style does not focus on constructing things, but more on story telling and social interaction. I never did that, I'm autistic. I take things apart and put them back together. I construct things, I design, I engineer. And when you sell electronics kits, don't you want to appeal to those kinds of minds?
👍1
Kosmos meanwhile offered this. Using an NE612 for the LO and mixer and a TBA 120S as an IF amplifier and demodulator. Still integrated, but more modular, more educational on what makes up a superhet.
I gotta rant a bit about package management on Linux. A problem you think would be solved by $current_year.
My lab setup runs on *buntu 24.04 because I'm a lazy butt and I don't want to spend time updating all my machines all the time. I got the KiCad 9 PPA, which pulls in its own version of ngspice.
There's also Qucs-S which I want to give a shot as an LTSpice replacement, and it's not in the vanilla package tree. Someone maintains a PPA for it. But it also pulls in a version of ngspice, which collides with the one by KiCAD. The fuck?
Who maintains a PPA with a fork of a package that your software depends on and doesn't change the default installation paths for those files?
Why is there no snap of KiCad or Qucs-S? The solutions are there, USE THEM.
Now I gotta compile Qucs-S from source and run it out of some folder like it's 1996.
At this point I might as well go back to Gentoo. There I could at least whip up an ebuild within minutes >.<
My lab setup runs on *buntu 24.04 because I'm a lazy butt and I don't want to spend time updating all my machines all the time. I got the KiCad 9 PPA, which pulls in its own version of ngspice.
There's also Qucs-S which I want to give a shot as an LTSpice replacement, and it's not in the vanilla package tree. Someone maintains a PPA for it. But it also pulls in a version of ngspice, which collides with the one by KiCAD. The fuck?
Who maintains a PPA with a fork of a package that your software depends on and doesn't change the default installation paths for those files?
Why is there no snap of KiCad or Qucs-S? The solutions are there, USE THEM.
Now I gotta compile Qucs-S from source and run it out of some folder like it's 1996.
At this point I might as well go back to Gentoo. There I could at least whip up an ebuild within minutes >.<
Also, what's up with the spice integration in KiCad anyways? It seems nice enough to not be just an afterthought, but where are the spice models? It doesn't ship with anything, not even the most generic jelly bean parts. Do they really expect me to dig up everything on my own? Never heard of "batteries included"? Maybe I missed some magic kicad-spice-models package. The closest I could find is this inofficial git
https://github.com/kicad-spice-library/KiCad-Spice-Library
https://github.com/kicad-spice-library/KiCad-Spice-Library
This brings me to something I need to figure out:
I got a heterogeneous bunch of Linux boxes and a whole spectrum of weird and odd software. Stuff pulled from git, random tar ball sources, binaries, the odd .deb file, and a bunch of wine prefixes and python venvs. Maintaining that is a nightmare. Especially so across all my systems.
So far I have an ad-hoc mix of local installations and things on my central nas. But, as I said, it's a nightmare.
I need to streamline it. Maybe keep everything central on the nas, and use rsync to pull it onto my laptop for mobile use.
But that leaves me with the problem of differences in the host OS. Maybe I could make a chroot with a minimal debian or ubuntu I build against. My skin crawls at the thought of X11 or desktop integration.
Before you mention docker: No. I want no abstraction layer between me and the files.
I'll look into nix.
I got a heterogeneous bunch of Linux boxes and a whole spectrum of weird and odd software. Stuff pulled from git, random tar ball sources, binaries, the odd .deb file, and a bunch of wine prefixes and python venvs. Maintaining that is a nightmare. Especially so across all my systems.
So far I have an ad-hoc mix of local installations and things on my central nas. But, as I said, it's a nightmare.
I need to streamline it. Maybe keep everything central on the nas, and use rsync to pull it onto my laptop for mobile use.
But that leaves me with the problem of differences in the host OS. Maybe I could make a chroot with a minimal debian or ubuntu I build against. My skin crawls at the thought of X11 or desktop integration.
Before you mention docker: No. I want no abstraction layer between me and the files.
I'll look into nix.
It's $current_year, WHY ON EARTH do you not implement a theming engine? It took KiCad ages to finally do it. Now I'm being teleported back to ye olden days with Qucs-S. No, this is even worse, because the only customizable elements are the background and grid. You cannot set the foreground color. The heck.
sighs
sighs