You Got A 3D Printer, Now What?

Given the incredibly low prices on some of the models currently on the market, it’s more than likely a number of Hackaday readers have come out of the holiday season with a shiny new desktop 3D printer. It’s even possible some of you have already made the realization that 3D printing is a bit harder than you imagined. Sure the newer generation of 3D printers make it easier than ever, but it’s still not the same “click and forget” experience of printing on paper, for instance.

In light of this, I thought it might be nice to start off the new year with some advice for those who’ve suddenly found themselves lost in a forest of PLA. Some of this information may seem obvious to those of us who’ve spent years huddled over a print bed, but as with many technical pursuits, we tend to take for granted the knowledge gained from experience. For my own part, the challenges I faced years ago with my first wooden 3D printer were wholly different than what I imagined. I assumed that the real challenge would be getting the machine assembled and running, but the time it took to build the machine was nothing in comparison to the hours and hours of trial and error it took before I gained the confidence to really utilize the technology.

Of course, everyone’s experience is bound to be different, and we’d love to hear about yours in the comments. Grand successes, crushing defeats, and everything in between. It’s all part of the learning process, and all valuable information for those who are just starting out.

Continue reading “You Got A 3D Printer, Now What?”

The 348,296th Article About Cryptocurrency

The public has latched onto the recent market events with an intense curiosity brought about by a greed for instant riches. In the last year alone, the value of Bitcoin has risen by 1,731%. We’re talking gold rush V2.0, baby. Money talks, and with a resounding $615 billion held up in cryptocurrencies, it is clear why this is assuredly not the first cryptocurrency article you have read — maybe even today. An unfortunate side effect of mass interest in a subject is the wildfire-like spread of misinformation. So, what exactly is a blockchain, and what can you still do now that everyone has finally jumped on the cryptocurrency bandwagon?

Continue reading “The 348,296th Article About Cryptocurrency”

Henrietta Lacks And Immortal Cell Lines

In early 1951, a woman named Henrietta Lacks visited the “colored ward” at Johns Hopkins hospital for a painful lump she found on her cervix. She was seen by Dr. Howard W. Jones, who indeed found a tumor growing on the surface of her cervix. He took a tissue sample, which confirmed Henrietta’s worst fears: She had cancer.

The treatment at the time was to irradiate the tumor with radium tubes placed in and around the cervix. The hope was that this would kill the cancerous cells while preserving the healthy tissue. Unbeknownst to Henrietta, a biopsy was taken during her radium procedure. Slivers of her tumor and of healthy cervix cells were cut away. The cancer cells were used as part of a research project. Then something amazing happened: the cancerous cells grew and continued to grow outside of her body.

As Henrietta herself lay dying, the HeLa immortal cell line was born. This cell line has been used in nearly every aspect of medical research since the polio vaccine. Millions owe their lives to it. Yet, Henrietta and her family never gave consent for any of this. Her family was not informed or compensated. In fact, until recently, they didn’t fully grasp exactly how Henrietta’s cells were being used.

Continue reading “Henrietta Lacks And Immortal Cell Lines”

Entropy And The Arduino: When Clock Jitter Is Useful

What do you do, when you need a random number in your programming? The chances are that you reach for your environment’s function to do the job, usually something like rand() or similar. This returns the required number, and you go happily on your way.

A shift register configured as a pseudo-random number generator.
A shift register configured as a pseudo-random
number generator. [by KCAuXy4p CC0 1.0]
Except of course the reality isn’t quite that simple, and as many of you will know it all comes down to the level of randomness that you require. The simplest way to generate a random number in software is through a pseudo-random number generator, or PRNG. If you prefer to think in hardware terms, the most elementary PRNG is a shift register with a feedback loop from two of its cells through an XOR gate. While it provides a steady stream of bits it suffers from the fatal flaw that the stream is an endlessly repeating sequence rather than truly random. A PRNG is random enough to provide a level of chance in a computer game, but that predictability would make it entirely unsuitable to be used in cryptographic security for a financial transaction.

There is a handy way to deal with the PRNG predictability problem, and it lies in ensuring that its random number generation starts at a random point. Imagine the  shift register in the previous paragraph being initialised with a random number rather than a string of zeros. This random point is referred to as the seed, and if a PRNG algorithm can be started with a seed derived from a truly unpredictable source, then its output becomes no longer predictable.

Selecting Unpredictable Seeds

Computer systems that use a PRNG will therefore often have some form of seed() function alongside their rand() function. Sometimes this will take a number as an argument allowing the user to provide their own random number, at other times they will take a random number from some source of their own. The Sinclair 8-bit home computers for example took their seed from a count of the number of TV frames since switch-on.

The not-very-random result of a thousand analogRead() calls.
The not-very-random result of a thousand analogRead() calls.

The Arduino Uno has a random() function that returns a random number from a PRNG, and as you might expect it also has a randomSeed() function to ensure that the PRNG is seeded with something that will underpin its randomness. All well and good, you might think, but sadly the Atmel processor on which it depends has no hardware entropy source from which to derive that seed. The user is left to search for a random number of their own, and sadly as we were alerted by a Twitter conversation between @scanlime and @cybergibbons, this is the point at which matters start to go awry. The documentation for randomSeed() suggests reading the random noise on an unused pin via analogRead(), and using that figure does not return anything like the required level of entropy. A very quick test using the Arduino Graph example yields a stream of readings from a pin, and aggregating several thousand of them into a spreadsheet shows an extremely narrow distribution. Clearly a better source is called for.

Noisy Hardware or a Jittery Clock

As a slightly old-school electronic engineer, my thoughts turn straight to a piece of hardware. Source a nice and noisy germanium diode, give it a couple of op-amps to amplify and filter the noise before feeding it to that Arduino pin. Maybe you were thinking about radioactive decay and Geiger counters at that point, or even bouncing balls. Unfortunately though, even if they scratch the urge to make an interesting piece of engineering, these pieces of hardware run the risk of becoming overcomplex and perhaps a bit messy.

The significantly more random result of a thousand Arduino Entropy Library calls.
The significantly more random result of a thousand Arduino Entropy Library calls.

The best of the suggestions in the Twitter thread brings us to the Arduino Entropy Library, which uses jitter in the microcontroller clock to generate truly random numbers that can be used as seeds. Lifting code from the library’s random number example gave us a continuous stream of numbers, and taking a thousand of them for the same spreadsheet treatment shows a much more even distribution. The library performs as it should, though it should be noted that it’s not a particularly fast way to generate a random number.

So should you ever need a truly random number in your Arduino sketch rather than one that appears random enough for some purposes, you now know that you can safely disregard the documentation for a random seed and use the entropy library instead. Of course this comes at the expense of adding an extra library to the overhead of your sketch, but if space is at a premium you still have the option of some form of hardware noise generator. Meanwhile perhaps it is time for the Arduino folks to re-appraise their documentation.

The subject of entropy and generating random numbers is one that has appeared on these pages many times. [Voja Antonic] made a in-depth study using uninitialized RAM as an entropy source for microcontrollers. If you have an insatiable appetite for understanding Linux entropy, we point you at [Elliot Williams]’ comprehensive examination of the subject.

[Arduino image: DustyDingo Public domain]

First Light: The Story Of The Laser

Lasers are such a fundamental piece of technology today that we hardly notice them. So cheap that they can be given away as toys and so versatile that they make everything from DVD players to corneal surgery a reality, lasers are one of the building blocks of the modern world. Yet lasers were once the exclusive province of physicists, laboring over expansive and expensive experimental setups that seemed more the stuff of science fiction than workhouse tool of communications and so many other fields. The laser has been wildly successful, and the story of its development is an intriguing tale of observation, perseverance, and the importance of keeping good notes.

Continue reading “First Light: The Story Of The Laser”

Let’s Talk Intel, Meltdown, And Spectre

This week we’ve seen a tsunami of news stories about a vulnerability in Intel processors. We’re certain that by now you’ve heard of (and are maybe tired of hearing about) Meltdown and Spectre. However, as a Hackaday reader, you are likely the person who others turn to when they need to get the gist of news like this. Since this has bubbled up in watered-down versions to the highest levels of mass media, let’s take a look at what Meltdown and Spectre are, and also see what’s happening in the other two rings of this three-ring circus.

Meltdown and Spectre in a Nutshell

These two attacks are similar. Meltdown is specific to Intel processors and kernel fixes (basically workarounds implemented by operating systems) will result in a 5%-30% speed penalty depending on how the CPU is being used. Spectre is not limited to Intel, but also affects AMD and ARM processors and kernel fixes are not expected to come with a speed penalty.

Friend of Hackaday and security researcher extraordinaire Joe Fitz has written a superb layman’s explanation of these types of attacks. His use of the term “layman” may be a little more high level than normal — this is something you need to read.

The attack exploits something called branch prediction. To boost speed, these processors keep a cache of past branch behavior in memory and use that to predict future branching operations. Branch predictors load data into memory before checking to see if you have permissions to access that data. Obviously you don’t, so that memory will not be made available for you to read. The exploit uses a clever guessing game to look at other files also returned by the predictor to which you do have access. If you’re clever enough, you can reconstruct the restricted data by iterating on this trick many many times.

For the most comprehensive info, you can read the PDF whitepapers on Meltdown and Spectre.

Update: Check Alan Hightower’s explanation of the Meltdown exploit left as a comment below. Quite good for helping deliver better understanding of how this works.

Frustration from Kernel Developers

These vulnerabilities are in silicon — they can’t be easily fixed with a microcode update which is how CPU manufacturers usually workaround silicon errata (although this appears to be an architectural flaw and not errata per se). An Intel “fix” would amount to a product recall. They’ve already said they won’t be doing a recall, but how would that work anyway? What’s the lead time on spinning up the fabs to replace all the Intel chips in use — yikes!

So the fixes fall on the operating systems at the kernel level. Intel should be (and probably is behind the scenes) bowing down to the kernel developers who are saving their bacon. It is understandably frustrating to have to spend time and resources patching these vulnerabilities, which displaces planned feature updates and improvements. Linus Torvalds has been throwing shade at Intel — anecdotal evidence of this frustration:

“I think somebody inside of Intel needs to really take a long hard look at their CPU’s, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.”

That’s the tamest part of his message posted on the Linux Kernel Mailing List.

Stock Sales Kerfuffle is Just a Distraction

The first thing I did on hearing about these vulnerabilities on Tuesday was to check Intel’s stock price and I was surprised it hadn’t fallen much. In fact, peak to peak it’s only seen about an 8% drop this week and has recovered some from that low.

Of course, it came out that back in November Intel’s CEO Bryan Krzanich sold off his Intel stock to the tune of $24 Million, bringing him down to his contractual minimum of shares. He likely knew about Meltdown when arranging that sale. Resist the urge to flame on this decision. Whether it’s legal or not, hating on this guy is just a distraction.

What’s more interesting to me is this: Intel is too big to fail. What are we all going to do, stop using Intel and start using something else? You can’t just pull the chip and put a new one in, in the case of desktop computers you need a new motherboard plus all the supporting stuff like memory. For servers, laptops, and mobile devices you need to replace the entire piece of equipment. Intel has a huge market share, and silicon has a long production cycle. Branch prediction has been commonplace in consumer CPUs going back to 1995 when the Pentium Pro brought it to the x86 architecture. This is a piece of the foundation that will be yanked out and replaced with new designs that provide the same speed benefits without the same risks — but that will take time to make it into the real world.

CPUs are infrastructure and this is the loudest bell to date tolling to signal how important their design is to society. It’s time to take a hard look at what open silicon design would bring to the table. You can’t say this would have been prevented with Open design. You can say that the path to new processors without these issues would be a shorter one if there were more than two companies producing all of the world’s processors — both of which have been affected by these vulnerabilities.

Teaching Alexa To 3D Print

Sometimes a gadget like Alexa or Google Home is a solution looking for a problem. Then the problem you’ve been looking for hits you square in the face. I’ve confessed before that I have an oscilloscope problem. I also have a microcontroller development board habit. It appears now I have too many 3D printers. I recently finished building my latest one, an Anet A8 I picked up on Black Friday. While calibrating it, I found myself juggling a screwdriver, a pair of pliers, and trying to operate the thing all at one time. I realized I had to come up with a better way.

I don’t know if it qualifies as an addiction yet, but I also have an Alexa in every room (although I call it “Computer” because I’m a Star Trek fan) and a Google Home device almost everywhere. Why can’t I get one of these assistants to operate my printer for me? What are assistants for, after all, other than telling Dad jokes?

You’d think adding voice control to a 3D printer would a bit difficult. With the right tools, it is actually pretty easy. Luckily those tools aren’t anything special… if you want a set up like mine, where Alexa controls your 3D printer, read on.

Continue reading “Teaching Alexa To 3D Print”