You've already forked ivan-torvalds-GuitarPedal
forked from AllSpiceMirrors/torvalds-GuitarPedal
Test #1
Reference in New Issue
Block a user
No description provided.
Delete Branch "archived"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Test
This is the re-done base board from the 1590A project, but organized differently: with the 1590A you had to have the audio jacks side-mounted and the resulting 'base board' was the size of the whole enclosure and also dealt with the stomp switch. In contrast, in a new bigger 125B enclosure it makes a bit more sense to top-mount the jacks, and the base board thus becomes just the 'jacks' board that only deals with power and audio jacks. The jacks board still deals with the signal switching, but it is now a 'soft switch' controlled by a logic-level signal. I did explore that option in the 1590A project, but now it's an integral part of the design. This only contains this 'jacks' board with some very basic power supply reverse polarity protection, the high-impedance input signal buffering, and the MOSFET switching logic for the output. Note that you can choose to ignore the MOSFET switching, and do the pass-through entirely on the effect board (for example by just having the digital effect be the NULL effect with the resulting slight delay). But an actual "true bypass" mode is not supported by this design: it's not only not very interesting from an analog circuit design standpoint (which is why I'm doing this all), it also would require passing off the raw signal handling entirely to the other boards. But I do expect the JFET buffer and the MOSFET switching to be quite good based on previous experiments - it looks like complete overkill for a guitar pedal. Famous last words: I've only built a single LS844-based JFET buffer so far, and while that one showed excellent results, maybe I happened to be lucky. The effect is expected to be handled by the Electrosmith Daisy Seed board: https://electro-smith.com/products/daisy-seed and the result is at least initially designed to be compatible with the Hothouse pedal kit by Cleveland Music Co: https://clevelandmusicco.com/hothouse-diy-digital-signal-processing-platform-kit/ so none of this is in any way novel or interesting except as my continual journey to learn electronics. As part of that, the implementation is quite different from the Hothouse pedal. Part of it is in the switching logic, which the Hothouse does not do, instead always going through the Daisy Seed (with the resulting 5.2ms latency even with effects disabled). And part of it is in the analog circuits, where the Hothouse pedal uses a regular (sane) op-amp based buffering, while this uses discrete components. I actually would like to learn the mixed signal side too, so one possible longer-term plan is to actually integrate the STM32 and the PCM3060 from the Daisy Seed onto the main board itself. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>This does the +VA net a bit differently: by using a common collector series follower transistor I can use much bigger resistors in the lowpass filter because the current through the resistor is just the tiny base current. In fact, let's just make it the main filtering stage, and share the resulting +VA rail for both the input stage and the output bias. They both need on the order of one mA of current, so assuming a DC current gain (whether you call it h_{FE} or Beta) of roughly one hundred, we can easily use a couple of 2k2 resistors and make it a 2nd order filter. (The original used a single 220 Ohm resistor, so this increases that by a factor of twenty, but then the h_{FE} will more than make up for it) Of course, the small viltage drop over the resistors will now be almost entirely dwarfed by the V_{BE} voltage drop of the transistor. But if it gives us a nice stable analog voltage rail, it should be worth the small voltage drop. I use a MOSFET for reverse polarity protection because I don't like the voltage drop of a simple diode, but that's because the voltage drop there would be just a negative. Here there's a _reason_ for a voltage drop. Of course, I don't know how much it really helps with noise, but it looks good in simulation, and I'm willing to at least do a test board for this. I'm just using the BC846 BJT I already have around. It's a very average cheap general-purpose transistor, I have no idea if this is any good. Live and learn. That's still the point of the whole project, after all. While doing random trials, this also ends up DC-coupling the input side. I probably shouldn't do two independent changes like this, but I'm too lazy to do two separate boards. Talking about separate boards: I wish KiCad had some good way to share common circuits (some kind of "combination symbol" concept or something) so that you could do explicitly different boards without having to either do duplicate boards, or like this, just change an existing one. I guess I could use different git branches for trial runs like this, but with all the random noise that any small change makes, merging things when they work would probably be a nightmare. Anyway, just random musings when doing random testing with things that may or may not be a good idea. In another news: when laying out this change, the resulting board is just a single layer. The bottom copper layer is all ground. Not that it matters, but I like how clean it looks. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>I'm not loving how KiCad does 'projects', but I made it worse by just dealing with this all wrong. To me, a "project" is the whole thing, so when I've split things up into multiple pieces, they are all part of one big project. But that's not how KiCad thinks of things. To KiCad, a project is just a single PCB, and while there are plugins to deal with that (from a quick look, KiKit would be a great idea), I'm not quite ready go there. So my "project" is a collection of several KiCad projects, and then I used global symbol and footprint libraries that I just pointed at the directory they all share. That seemed like the simplest solution to the disconnect in what "project" means. But simple or not, it turns out to be a horrible model because the disconnect means that now your (to you) project-specific libraries end up being in the global KiCad setup, and makes it all painful to move between machines etc. It's also nasty because KiCad only understands about it's own local project root ("${KIPRJMOD}"), and to get to the "real" project root I then had to use "../symbol" to go up to the top-level symbol. And that then causes more problems if you want to have a different directory hierarchy and have sub-projects that are deeper in the hierarchy. In other words, there's just a bad impedance match between the KiCad notion of "project" and the actual real project notion. This improves on the situation by making the libraries local to the KiCad project, and then just pointing them at the global project libraries individually. Sadly, while that takes care of loading symbols and footprints - because they have their per-project path configuration, it doesn't solve the simulation file paths. I can't find any per-project path for loading simulation files, and the whole "${KIPRJMOD}/.." approach has the same issue with nested hierarchies. The best I could do is to introduce a per-project 'TOPLEVEL' text schematic variable, which then does work in simulation path, and I can use "$(TOPLEVEL}/symbol" for those. There might be better ways to do this, but this seems to work for now. Now you have to make each subproject have those pointers, but it should mean that I can have hierarchical projects, and this "my project" vs "kicad project" thing is at least a bit more explicit and should travel between machines as part of the whole git tree better. Maybe some day kicad will support this kind of higher-level project view natively (while googling this I found that I'm definitely not the first person to have wanted kicad to better support multiple pcb's), but for now I think this is at least better than my previous (dis)organization. Also make the pointer to external spice library directory be a symlink rather than more explicit ".." hackery. I wish I could just put those external spice files all directly in the git tree, but for some unfathomable reasons some manufacturers limit sharing of their spice files even when they are public and used to support the hardware they sell. Cray-cray, but I suspect some people were dropped on their head a few too many times as babies. Maybe they were too ugly and their mothers recoiled in horror? Anti-moral of the story: don't be ugly. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>I didn't have a plain PNP BJT for some reason, and the dual transistor packages I do have were a bit inconvenient when I wanted to use one transistor on the signal path and another on the power path. So add another transistor to the list of transistors in my library. And since I had looked at a high-h_{FE} version of the BC846 NPN BJT that I already have, I decided to just go for it and add both a NPN and PNP version. The BC847C is a higher-h_{FE} grade of the BC847 series, which in turn is similar to the BC846 but with lower V_{CEO} (45V vs 65V - irrelevant for my use). The BC857C is then the PNP version of that. Do I need the higher DC gain? No. I had looked at it due to my use of the BC846 in that analog rail filter trial using the common collector series follower setup. But they are pennies, so why not? Also add in the spice model for the NMB2227A, which was missing. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>.. and fix up the LED simulation a bit too. I simulate LEDs with the built-in diode model, but with N ("emission coefficient") set to 3, which gets me a forward voltage around 2V. But I think I should change RS ("series resistance") instead (or in addition to). See https://led-ld.nichia.co.jp/api/data/spec/tech/SP-QR-C2-210932-2-E_The%20SPICE%20Model%20of%20LEDs.pdf which talks much more about this. I guess I don't care that much, I just wanted the current simulation for the power LED to be in roughly the right ballpark. The inductor change is the relatively important thing here. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>This is a long time coming, but it was triggered by jlcpcb not stocking the MMBF5103, and all the alternatives looked worse. So I guess sanity has to prevail, and I should use an opamp rather than a discrete JFET input stage. I looked at the J201 - which I have tested and works, but has a potentially very low V_{GSOFF} that will cause clipping. And the MMBFJ309L looked good in simulation and had better parameter values, but I've never tested it, so it seemed a bit risky particularly since the intended market seems to be for much higher frequency circuits. I even looked at the JFE150, which is another silly-expensive thing sold to audio markets. I guess that tracks. In the end, a plain simple opamp is definitely the sane choice. To rebias the incoming signal, this uses the MICBIAS from the TAC5112, which is typically 2.75V (but can be programmed to 2.5V or turned off entirely etc). It's there, it's almost what it is meant for, so let's use it. The OPA365 looks fine, and does rail-to-rail input and output and can do single supplies down to 2.2V, but rather than put even more on the 3.3V rail (and limiting the voltage swing), this just uses the 5V USB VBUS power supply. This does have some minimal caps for filtering (replacing the old +VA supply to the JFET) but the OPA365 also claims good PSRR. This all does seem like the right thing to do, but I'm still a bit sad since the discrete JFET was just more interesting. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.