It’s a hack, but it’ll work. You’ll need either:
- Windows, running the git-bash app (highly recommended). Download it here: Git – Downloads
It’s a hack, but it’ll work. You’ll need either:
Bitcoin-Core version 12.0.0 shipped with a new heavily optimized elliptic curve math library. Prior to the release, there were whispers that the new library would significantly speed up the blockchain sync – a sync which was taking me 12-24 hours to complete. Excited for the potential speed up, I decided to benchmark the sync and talk about it on reddit live. Needless to say I was amazed at the difference. Thanks to the core developers for this!
These are good questions, so I wrote a small bash script that gives us some data about the sync time of the new release candidate, whose new optimized library for elliptic curve operations has been rumored to give up to a “700%” increase in the speed of verifying transactions. Disclaimer: it’s not wonderfully modular or well thought out; I did it quickly just to see how the performance was.
So let’s benchmark bitcoin-core with the new libsecp256k1 to see this speedup ourselves. Here is a script for making a log and getting a birds eye view of the sync process. Spoilers: it was really, really fast.
This is the kind of thing I always thought about doing, but never did. It’s a simple thing to do, however it just takes time to write up a useful albeit simple script to give you the data you want. Not only that, but previously, when syncs were taking days to complete, this sort of test would eat up my machine.
Since I have been involved with bitcoin, I have known the user base to be (I love you guys) …well, prone to getting carried about with the fear of an impending doom of the BTC — especially if the inevitable doom will be brought upon by some physical limitations of the client, its capacity, and scalability.
In fact, back in 2012-2013, the total size of the blockchain was really all the rage, and the buzzword of the times was “blockchain pruning”. This involved lot of media focus on this problem, as well as efforts by developers and theorists alike to put forth a concerted effort to find a method for reduction of the very scary, problematic growth rate of the block chain!
That’s right everyone was talking about the block chain being too large on disk already, and growing too fast. How bloody ironic, eh. I won’t say it. Don’t even say it!
Over time I have built up a thick skin for these sorts of mobs of fear and uncertainty. I just keep using my coins and really tend to take the doomsday scenarios with less than a grain of salt, because I have seen bitcoin overcome obstacle after obstacle, so many times that it becomes almost illogical to be anything but calm through it all, and feel as though we are in good hands with the devlopers (we are).
But node sync time has been a subtle concern to me for many months – not because I read it on www.scary-bitcoin-news.ninja, but because I noticed this sync time change over a long period of time and become a real hassle to me and running my node as a casual.
In early 2013, it took “pretty damn long” to bootstrap a new node. But I was able to run a full node that year, all year, on a mid level laptop, that I would wipe and re sync every few months. But by the end of 2014 I was no longer running the laptop node and noticed long sync times on my main high performance monster of a desktop. I felt it took so much longer in fact, that I considered not even running the node, which would have really sucked for me, and put a big damper in the way I got used to used bitcoin. By the end of 2015 I was just trying to avoid a fresh node sync at all costs, which is hard as a man who re-installs his OS every few months. The sync would, on either of my computers, take between 36 and 96 hours for me, depending on how uninterrupted I could run the process and the state of my internet service, and other variables.
It dawned on me at some point that if I was dreading a sync, I couldn’t have been the only one. And so I did consider whether node sync time was a real deterrent to running a node.
However I decided to go for it because I thought if the figures I heard are true, and this library gives a significant speedup, it might require less than a day. And when I inquired in the IRC channel, I was told “could be as fast as 4 hours.” Hot damn – this I had to so. So I finally did it. Result: Sp happy! It finished in a blazing 4 hrs, 4 minutes, and 4 seconds! Sweet victory for node operators and bitcoin as a whole!
This did truly make me very happy as it served my purposes and the community as a whole in no small part. I was stoked, and to such a degree that had to spread the joy around the community, encouraging others to take note of the speedy sync time by benching it themselves. I made a reddit post, and put the code on github, along with the data from my 4 hour full bootstrapping of bitcoin core.
Well anyway, I enjoyed this little treat from the devs, and hope y’all do as well. Thanks guys! Long live the core!
Of all the circuits I’ve ever designed purely by guessing, this one has the highest performance/expectations ratio. I took the LM386, basically combined two of the diagrams in the data sheet, and added a transistor preamp stage and some high quality capacitors. And dude. I like the way this thing sounds. A lot. First picture time, then full schematics.
The power amplifier section (left above) is nothing more than a combination of the first two schematics given in the LM386 data sheet. And yeah yeah the sloppy soldering… I told you it was on the fly.
The way the 386 works is not like a normal op amp. If that is messing with your mind, it does with mine as well. But this is life. It is a cool chip anyway. The way this works is that 10u cap AC shorts an internal 1.35k gain setting resistor. So I added the cap, as well as a switch so I can go between high and low gain settings.
The switch you see there is from radio shack. It is used to switch between the gain of 20 and gain of 200 settings; it is placed right in series with the 10u capacitor which amounts to an amp with two settings. You either have decent clean-ish, or absolutely saturated, raunchy, but good distortion. But it’s not because of the LM386 alone – the little preamp has a lot to do with the sound and overdrive in this design. This 386 is seeing a well-groomed guitar signal.
That’s the preamp, on the near side. The image below is a spice model of the transistor premap circuit. And if you don’t know what spice is PLEASE learn spice. You must learn spice.
This little preamp was adapted from some ideas I had seen online. But I this combination of common source followed by follower is a bit uncommon (a lot of times you see common base instead – this is called the cascode amp). I just like the way this one works for no particular reason, just many. It is sometimes difficult to bias (as transistors can often be…) but I’ll show you how to take the guesswork out of it using LTSpice.
With JFET’s, my strategy is to set the drain currents the way I want them first, and for that I like to use spice. It is a sensitive issue. Here are some plots of the performance of this preamp driven with a 10k sine of 100 mV (if you want the spice files, just contact me).
The capacitors paired with resistors have RC time constants that determine the transfer curve or frequency response of this preamp. Whenever you build one of these, you want to put some thought into those RC constants. Here’s how to obtain the desired transfer curve from RC elements in an amplifier like this, while making sure your transistors are in their safe operating regions.
Realize it is a common source amplifier followed by a common drain (source follower). So the second transistor is actually never going to give us a gain more than 1. The first transistor’s gain is set by the size of R4, the drain resistor of J2. Higher R4 means more gain in the common source stage. So, because C4 looks like a short to high frequency, this gives us our high frequency rolloff:
The low frequency -3dB point is determined by the input capacitance. You want a nice big cap to get that bass! Audible tones are as low as 20 Hz, and tactile sense goes even lower. Keep the bass…but you don’t want any DC. So you get a pretty big cap, but just make sure it is not electrolytic. Not for your signal path. Metal film, ceramic disk, whatever. Anything but electrolytic in the signal path. And I don’t know if its mysticism or not, which there is a LOT of in audio as we all know…but I have noticed this input cap is a pretty big deal, so you may want to buy some nice ones. These were $10 on ebay for 8 of them. I used two in the amplifier here. Anyway, let’s see the gain now:
Not a crazy high gain. I’d like there to be more. Then I could use the LM386 as an output and not have to rail it to get some drive. Hmmm. The gain itself is set by the drain resistor of J2 (which I have stupidly labeled R4 ; sorry). I want more gain, so I need to increase R4. But the most important part of this transistor design process is keeping an eye on your drain currents. You can do this either with the data sheet and the equation
Id = Idss*(1-Vgs/Vp)^2
Well they don’t look completely ideal, but as long as I don’t use too high of a supply voltage, I’ll stay in that linear region. , but what you really want is the drain currents (shown above) to be in the flat region at the supply voltage you choose. If you look at 9V there, I seem to be in the correct region of operation for my transistor. But in the case of a guitar amp…you can certainly push the limits because hey – it’s just a little distortion. Sounds fun, right?
Let’s increase the gain. How do we do that? We recall from the common source link, that drain resistor sets my gain. Ok lets make it 850 ohm. That won’t change much right?
Holy moly, we have a pretty distorted waveform and we can see why. Look at my drain currents now. Not only are they small, but they’re “much less linear.”
Bypassing the supply (skip if not a noob)
This is one of those things that is basically automatic for this kind of circuit, yet if you’re a noobie, nobody really mentions it. So I will.
• You must put 100 nF caps to ground as close as possible to the pins on your 8 pin op amps or anything similar. If you’re still learning, think about what effect that would have. What frequencies see a short to ground? The idea is for your supply to be nice clean DC, because your supply will mess with your…well, everything, as we have seen. We do not want it to fluctuate much, at any frequency.
• You want to place some big electrolytic caps between the node where you connect the battery to ground. That is the very least you can do. If you just pick big capacitors, you’re fine…I think I used 220uF here or something really high. I was sloppy here because I could. Sometimes, though, you’ll want to make a little RC network that charges up and take a little time. This is especially true if you’re using CMOS. JFETs can really take a beating, but not all transistors can handle a big impulse.
Connect the preamp to the LM386 schematic
• Feed the preamp into the LM386. And see that I have a 10k resistor in my spice diagram? That is not really in the final circuit – it’s just for the simulation, to act like the 386, which is (like an op amp or “op ampish thing” supposed to have a massive input impedance.
AC couple the output
• Put a capacitor at the output of the LM386 between your amplifier and your speaker. Just experiment with different sizes. Remember that caps block DC. You don’t wanna hear any sudden DC in your speaker. It’s nasty. This is called AC coupling and is a great idea in many cases.
Don’t load it down too hard – its just a chip
• This little chip is awesome, and can drive a 3 ohm speaker. But don’t push it. It does start to oscillate driving 3 ohms, for one. And it’s not too big of a deal if you blow the chip because its cheap but you can start a fire perhaps if you let the battery get super hot or the chip starts on fire. I find it unlikely, but yeah. Stay above 4 ohms for the best sound anway. I was really happy with a 6 ohm load in fact.
Have fun, be safe, ask any questions if you need help, and respect electronics! It’s not the safest hobby on earth. Disclaimer disclaimer disclaimer!!