SoylentNews

And so I managed to do a few things with my FPGAs. With the EBAZ4205 Xilinx Zynq 7010 I managed to replicate most of the stuff that was done here, which kinda says that my board is working and has no issues, only problem is that it is very hard to use any significant number of I/O pins on the board because the pin headers are 2mm instead of the usual 2.54 mm and that will require me to build a custom breakout board with the necessary connectors. It was not originally intended as a dev board so I have to jump through some hoops to get it to work. I may attempt to replicate my efforts described below on this much more powerful board later on.

The Sipeed Tang Nano 9k is a lot easier to use, and it marks the serious beginning of my FPGA experiments. I found a nice book Designing Video Game Hardware With Verilog by Steven Hugg. It uses a simulated FPGA system at 8 Bit Workshop though, so I'm going to try adapting things to run on real FPGA hardware. By chapter 10 there is a discussion on how to generate video signals in Verilog, and I managed to write my own version of the code that actually works on my FPGA and a 4.3" 480×272 40-pin RGB screen that I managed to get for about $6. I got it to generate the test pattern described in that chapter as well as the basic SMPTE colour bar test pattern, which says that my timings might be slightly off because there are a few artefacts noticeable. It's working well enough though. I'd had to study Ken Shirriff's own efforts at FPGA video generation as well as the samples given by Sipeed to figure it all out. The same principles should suffice to generate VGA output from the looks of things, once I can build an interface for it. It should also be possible to use the Tang Nano's HDMI interface but I haven't found any clear examples or good documentation on how to use that just yet.

The process of adapting the book to a real FPGA should be instructive. There is a simple racing game in chapter 19, and that is going to require input controllers of some kind. I have a classic Atari joystick that I successfully interfaced with an Arduino a few years back so I know it works, so it should not be too hard to interface it to the FPGA and so implement the game with it. I could also try to get a Nintendo Entertainment System controller, which doesn't look too hard to interface either.

Rather than using Sipeed's proprietary IDE I have been trying to make use of the OSS CAD Suite, which has support for the Tang Nano 9k. It is, unfortunately poorly documented: I haven't figured out how to use the simulation tools yet, and I'll probably need to do that before long. I don't think I want to have to break out a logic analyser to do debugging again!

As I mentioned in the last journal entry I'd ordered a bunch of FPGA boards from Chinese suppliers. The Spartan-6 board I at first tried to order failed delivery: it had come in during the Chinese New Year week and the online market [Lazada] that I used to buy timed it out, and all the other sellers there seemed totally unresponsive. So I wound up getting a couple of different boards. First was an even more powerful Xilinx Zynq 7010-based board, an EBAZ4205. The thing however has proved to be a little more complicated to program for: I now need to download Xilinx's new Vivado suite which is even bigger than ISE had been (16 gigabyte download), and I apparently need to swap a couple of very tiny surface mount resistors to get the thing to boot from the SD card or receive programming from the JTAG pins rather than using the onboard NAND flash. Looks like I'll have to figure out how to wire a switch into that circuit so that I don't have to desolder the tiny 0402 resistor every time, so this is going to take work to get the board into a state that's usable for development. It was originally designed as the controller for a Bitcoin mining rig, which after the bottom seems to have fallen out of that, the boards are now going for very cheap. I got mine for about $30 including shipping. Apparently on Taobao you can even get them for around $5, though I'm wary about trying to buy from there, and most likely shipping to me may cost even more than $25, what I've seen it's usually closer to $50. There are other annoyances with the board, most notably the pin headers are at 2 mm instead of the far more standard 2.54 mm, meaning I'm going to have to jump through some hoops to get I/O out to the board.

I also managed to get a Sipeed Tang Nano 9k, which is a Chinese FPGA. With only 8640 LUTs it's fairly small (the Zynq has 28k LUTs by comparison and the Spartan-6 I planned to buy had 14,576) but what's interesting about it is that you don't have to use Sipeed's official development tools (which have annoying requirements even worse than Xilinx's confusing rigmarole when I downloaded ISE): there is an open toolchain for it. I got them and got as far as the blinky LEDs that are the canonical hardware hello world. Seems like I'm going to get started by experimenting with this little board first. It seems to be powerful enough to do some interesting things though and it was also VERY cheap (slightly less than $20 including shipping).

It's irritating that the major players in the FPGA scene, AMD's Xilinx and Intel's Altera, are both stuck to using their proprietary development tools. It's as though GCC didn't have support for the x86 architecture, and you had to use only their proprietary compilers to program for them. The open dev tools that support the Tang Nano only seem to support the Lattice FPGAs as well. There's also a board available for those, the Colorlight, which was originally intended as a controller for large LED video panels. They're a bit more pricey though, at something like $60, maybe I'll invest in those next time.

In other news I'd also built a flash EEPROM burner hat for the Arduino Mega, but it's only marginally faster than the original one I made based on the Pro Mini and three shift registers. I think that the issue is now more software, as the overhead of the rather simplistic code I use to drive the buses, and the inefficient serial communications which send every byte written back to the system along with an acknowledgement is part of the reason. I'll probably fork the code and change things slightly so that instead of acknowledging every byte it should compute the CRC of every 4k flash sector and send that one back instead. I don't want to have to wait half an hour or so to burn every small change I make to my projects' firmware. It may be worth investing in a real honest to goodness TL866 programmer if it can be substantially faster than my hacked together burner.

So I decided to try getting back into electronics yet again, and thought of trying to build some computers of my own using old hardware. I found a seller that provided alleged 68000's and 6502s for fairly cheap, and I have doubts that some of these are authentic. In particular the 6502 I got had apparent MOS Technology markings with an unlikely date code of 1311 (2011? MOS Technology went out of business in 2001, and they doubtless stopped making NMOS 6502s long before then!). It was less than $2 so I'm not out a lot. Maybe I'll get one of those W65C02s if I really want to try my hand with it, but they're kinda pricey at around $15. As for the 68000, it at least has a plausible date code of 9436. It's going to be a bit before I can try to give these a spin with all the extra circuitry I'll need to build to see if they work. I also managed to get a few alleged 68010s in 68-pin PLCC, of probably less questionable provenance, but I'll likely need to have a board fabricated to use 'em. There are a lot of fake chips floating around for the unwary.

I'd also gotten some GAL22V10s from the same online seller. Lattice stopped making those in 2011, but the ones I got seem to be authentic, or at least working properly, as I built a GAL programmer based on Afterburner (though I used an Arduino Pro Mini instead of an Arduino Uno). I used it to make a BCD to 7-segment decoder and it worked correctly. I also built a flash chip programmer for a bunch of SST39SF040 chips that I'd gotten, and it does seem to work, although flashing is rather slow, and I'm not sure if the bottleneck is the serial port, the chip itself, the Arduino and its support circuitry (there aren't enough pins to drive the address bus so we have to use three 74HC595 shift registers to get all address pin signals out), or the software. It took about 20 minutes to do a burn. I'll investigate it later on, and maybe make a new one with the Arduino Mega that I should have soon enough: that should have more than enough pins to do the trick without any support circuitry.

And now I'm trying to do experiments with CPLDs, which might be more useful in making more compact glue logic for the microprocessors. I got a Xilinx XC9572XL breakout board as well as a few bare XC9572XL's in PLCC44 (all for about the equivalent of $20), and wound up on a merry chase for a method to program these chips via the JTAG interface. It turns out that for some other reason I don't recall, I long ago bought an FT232H USB breakout board that could be used for this purpose, but it was not immediately obvious what pins went where. I eventually found a reference that the mentioned that the FT232H's AD0 pin should go to JTAG TCK, AD1 to TDI, AD2 to TDO, and AD3 to TMS, and that sufficed to work with xc3sprog. I eventually got Xilinx's ISE to run on Linux and wrote some basic VHDL to flash the LEDs on the board in response to a push-button. ISE is of course obsolete and it was a bit of a challenge to get it working on a modern Linux distro, but I have no choice since the Vivado system that they'd have us use today doesn't work with the XC9572XL which is also obsolete. It's 5V tolerant so it should be ideal to do double duty as a level translator to bridge old parts and new, and it may even be capable enough to turn into a peripheral chip for adding I²C and SPI buses to the system. Now I want to try using the same technique to program the PLCC XC9572XLs, but of course the PLCC44 to DIP socket I got only exposes 40 pins, and natch, pin 41 is one of the Vcc pins. I paid the equivalent of $10 for that. Looking around more carefully I found someone else selling two such sockets for about $3.50, with all the pins exposed... They should be here any day now and then I can try to program a bare chip on a breadboard then, and perhaps wire wrap one of them into a standalone programmer.

All this stuff with ISE made me think it might be interesting to get into FPGA programming too, and I found a Xilinx Spartan-6 board for the equivalent of about $35 that might be suitable for learning the ropes. Should be here in a few days. Everything is kludge but that's how it generally is.

Note: there appears to be a bug in ReHash's Unicode handling. It doesn't like Unicode smileys. I attempted to include a few in here but posting resulted in "no such article". It's weird.

And so I've managed to get my hands on a few FIDO2 keys, and have begun using them to provide two-factor authentication for my systems. I'm trying to figure out how to use them to provide an extra layer of security for my local systems, though a lot of such support seems to be experimental as of now. PAM has had support for FIDO2 for a while, so that's something I'm thinking of setting up. There's a project to help provide FIDO2 support for encrypted volumes, though the project appears to support only Arch for now. I'll see what I can do about getting Debian/Ubuntu support for it too, but adding this to my laptop's encrypted volume looks like something that will need to be done after I am able to make a full backup. Seems like a small hacking project I can try though. Password managers don't yet seem to have much support, but that seems to be changing, and I'll see about contributing to those efforts too. FIDO2 support for SSH is already in the mainline branch from what I can see, but I'll wait for it to filter to the distro packages.

What seems to be a bit more concerning is how few online services have support for this. Google seems to have some pretty good support for it, and a good thing too, since my GMail accounts are the "password reset central" for many of my other accounts. Namecheap seems to have good support as well. There are some very strange omissions though. First of all is Amazon. They don't support FIDO2 but supposedly support TOTP two-factor auth, but the only backup authentication they provide if the TOTP authenticator is lost is via SMS. That means entrusting to my mobile phone provider the security of my account, so forget it. I'd rather get a list of backup codes that I'd keep in a safe place the way most other TOTP implementations out there do. PayPal also has no support for FIDO2 and they have a similarly broken implementation of TOTP which also uses SMS as the only backup method. And Amazon and PayPal are both board members of the FIDO alliance and had a hand in the drafting of the standards. I get that these are relatively new standards but it still seems rather inexcusable for them not to provide proper 2FA support when these are exactly the sorts of high-value accounts that would benefit the most from 2FA. Hopefully they can get on the ball soon, but I'm not holding my breath.

And so here's the first prototype of my RNG hat based on the Lampert circuit: Tiamat Version 0.0, named for the ancient Babylonian goddess of chaos. Yeah, I know it's very crude. The protoboard I'm using there is this one. I had Elecrow (a Shenzhen-based electronics manufacturer) build those protoboards for me, mainly because the Github project recommended them, but their service, shall we say, leaves something to be desired. They made me wait more than two weeks for the boards, mainly because they broke many of the boards on their first attempt and somehow misplaced the boards they made on the second attempt, and it was the third try before they finally got things right. Anyway that left me with nearly a hundred of these protoboards (the original order called for 60, but they included the remaining unbroken boards from the first run), at a cost to me of $5 for the boards and $20 for shipping. Maybe I was just unlucky.

This Electronic Eel protoboard let me solder most of the surface mount components easily enough, with the exception of the TLV3202, which I stupidly ordered in MSOP8 (0.65 mm lead pitch), too fine for the board. I should have checked the package type before ordering it, as it appears to also be available in SOIC8, or maybe I should have just gotten a TLV3201 in SOT23-5 since the circuit really uses only one comparator stage. So I had to use an adapter, and it was rather hard to get it properly mounted (though I'd done that before). The protoboard actually has a ground plane so it was not too hard to get all of the ground connections done properly, though one needs to be careful with through hole components because the outer edge of the holes links to the ground plane. Anyway, I eventually succeeded in building it. Just tested it and it seems to work well enough. The raw circuit makes something like 6.8 bits of entropy per byte without debiasing, just as in my earlier breadboard tests, so only fairly modest debiasing is sufficient to provide reasonably good randomness.

Now I'm learning how to use KiCad and we'll see about making a real custom circuit board for this. It's a fairly small circuit so I'm kinda hesitant to order another production run from Elecrow or some other PCB manufacturing company since it's only around 33 mm × 33 mm, so for a 100 mm × 100 mm panel each one would have nine boards, so a ten-panel run would get me ninety boards, way too many for my purposes... Maybe I'll have them make several other boards on the same panel, perhaps more of the Electronic Eel protoboards, or something similarly useful. Might cost a bit more but my costs are already dominated by shipping. I really wish there were a local manufacturer so I'd not have to pay so much for shipping. I'll have to make very sure about the board dimensions and holes this time because I probably won't be able to cut these boards if they don't fit in the case.

While I wait for the TLV3202s to arrive I've noticed that something odd has been happening to the Wi-Fi with my laptop. Since I live in a concrete house with four storeys Wi-Fi was something of a challenge to let it get around to everywhere it needs to go. I'm currently using a TP-Link Archer C7 as my main router, which is on the third floor, and unfortunately, it isn't powerful enough to transmit signal all the way to the second floor where I usually work. So I got a TP-Link RE450 range extender and put it in a spot near the stairwell to the third floor where it can get reasonable signal from the main router and transmit cleanly to the rest of the floor. So now I get 2.4 GHz and 5 GHz 802.11ac signal to all the places where I need it. It's worked fine this way since 2015 and I haven't gotten any firmware upgrades from TP-Link since.

Now, my laptop (A 2017-era System76 Galago Pro, given the designation galp2) has been running Pop OS 18.04 (System76's Ubuntu derivative) on my Galago Pro for some time, and it used to have no trouble connecting to the Wi-Fi setup I have at all. Until one day I noticed that it was failing to connect to the range extender and insisting on connecting to the main router, for which even the 2.4 GHz 802.11n signal is very weak on the second floor. Networking is very very slow that way of course. My laptop was the only device for which this was happening: my phone and tablet, and the gadgets used by my family all worked as they always have.

And so I updated to Pop OS 19.10 by going upstairs and connecting to the Wi-Fi router from there, but that didn't improve matters when I tried going downstairs again. I tried to diagnose the issue further by digging into the innards of wpa_supplicant but all I could find out was that for some reason it couldn't authenticate against the range extender ("RSN: failed to configure GTK"), and kept fiddling with the router and range extender config to no avail. Google was not very helpful here at all.

I tried to boot with the 5.0.0 kernel which was still provided as an option, and bam, Wi-Fi connectivity to the range extender was restored. So since I don't have the time or energy to go around chasing a solution that will get the 5.3.0 kernel's Intel Wi-Fi drivers to talk to the range extender properly again, I tried to get it to boot the old kernel by default. I wound up fiddling with the grub config, only to later figure out that 19.10 doesn't use grub anymore, but UEFI boot. Hopefully there'll be a kernel update which fixes the issue, but until then I'll be stuck on 5.0.0.

Just as I've begun experimenting on Aaron Logue's circuit, some further research has shown that such circuits using the base-emitter junctions of transistors in that way are not stable in the long run. After about three months of being electrically stressed in a configuration like that, the oxide in the emitter-base junction of the transistor will begin to degrade, and the circuit will begin to be less and less effective at producing randomness. Rob Seward has a variant circuit that tries to compensate for this effect, but the fact is, the manufacturers of 2N3904s and other transistors which are (ab)used in this way can't make any kind of assurance that their components will remain stable in the long term. This kind of makes me a little bit concerned, because there are many commercial hardware RNGs out there (e.g. ChaosKey, OneRNG, and many others) that use transistor junctions in exactly the same way as the Logue circuit, and if this is true, they will all become unreliable when used for extended periods.

I did some further research and found that noise from Zener diodes is another good way to produce randomness, and Zener diodes at least are intended to be biased in that way, so they should be more stable. The big problem is that while the transistor B-E junction circuits need at least 12 volt supplies, the Zener circuits need even higher voltages, because it seems that the 12 volt Zeners are those which produce most noise. The circuit from betrusted.io is of this type, however, it uses a load of really weird surface mount devices. The power supply in particular uses a TPS61158, which annoyingly comes only in a ridiculously tiny WSON package with no exposed leads that is basically impossible to solder by hand. I'm not investing in a heat gun or other specialised equipment just for that...

Fortunately, I did find a few more designs out there, one of which was actually described in a conference paper. The bill of materials there looks like it uses only stuff I can realistically work with given the equipment that I am likely to have. The TPS61040 it calls for is available in SOT23, which is comparable in size to the ATECC508a (SOIC8). Soldering that by hand is possible: I've done it a few times. There are a few more components out there that I couldn't find in the electronics stores we've got here though, like the 1N759 Zeners that it uses, so I had to order those online.

And so at first I tried to go to RS Online, which I've used before to get some components (as well as my first Raspberry Pi) but they didn't have a lot of the key components I needed. So next I tried to go to DigiKey. They had everything I needed, but they wanted something like $16 to ship the stuff internationally. For a bill of materials that isn't much more than that, it's a pain. But then someone from corporate HQ in Denver is coming by to my part of the world to meet with us in a couple weeks so I asked them to ship it to the company address in Denver instead. $4 shipping, not too bad. But then a few hours later they suddenly tell me that they failed to authorise my payment with PayPal. When I asked what the hell was going on their clueless customer service kept giving me cryptic and unhelpful one-sentence replies to all of my questions, so I told them screw you, cancel my order. And I wound up at Mouser. Seems they would ship it all to me for free if I bought $40 or more from them, so I got a few more items to fill it up and now I'm waiting for my order to get here, which it should by around next week.

In the meantime, I tried to build something like the circuit from that above paper, which they call the Lampert circuit (shown on page 8 of that PDF). I was able to get LM358s from my friendly neighbourhood electronics shops, but I substituted a different 12V 0.5W Zener for the 1N759, a 1N5242. I don't have any diodes equivalent to the MBR0530 (D5) so I substituted a 1N4148. I also don't have a TLV3202 comparator (more's the pity I forgot to order it!), so I substituted an LM319. With a laptop power supply brick to feed 19V into the circuit, it seems to actually work. I've tried feeding the random circuit into an Arduino first and it does seem to be generating good random data based on some of the simple statistical tests I've applied. It mostly passes the FIPS tests and ent, but the random data it produced crashed the OPERM5 test from Diehard (this is known to be unstable though). Longer term testing for the design is warranted, but I'll wait until I get the rest of the components before I start soldering anything.

I'll get all the rest of the components within the next few weeks and then we'll see about building the boost converter into the circuit as well, and then I can build a new RNG hat.

The next circuit I've begun experimenting on is Aaron Logue's circuit. The annoying thing about this and many other circuits of its type based on PN junction breakdown noise is the requirement for a 12V supply, which I've been using a power brick and a 7812 regulator to obtain. Because at one point I had a brain fart, I managed to fry my Orange Pi Zero. I missed one stupid wire that connected the 12V supply I was using to the 5V rails on the breadboard... to which the Orange Pi was also connected, and then the magic smoke left my poor Orange Pi... $20 up in smoke. Rest in peace.

So I ordered a new Orange Pi Zero, which I received today, and resumed my experiments as soon as I managed to solder the GPIO headers onto it. This time making VERY sure that there were no stray wires to the breadboard that would send higher voltages to the 5V supply rails, I hooked the OPi up to the breadboard again, and damn if it didn't give a lot of very good randomness. It's far more effective than the LM393 circuit that is used by the XR232-USB, as it only requires a single level of von Neumann debiasing to obtain randomness that is good enough for all the statistical tests I've been using to validate its performance.

The only problem is that I now need a place to get 12V. Either I use a boost converter to get 12V out of the 5V that I can get off the OPi, or keep using the 12V supply brick from my experiments but also use it to power the OPi with a 12V to 5V buck converter. I thought the latter would be easier, but the problem is that the trusty old 7805 linear converter I use for my TTL circuits will melt if I attempt to down-convert 12V to 5V at 500 mA, unless I use a heat sink that is probably going to be too big to fit inside the case. So I also managed to get a few small 12V to 5V switching converters (smaller than a TO-220 package), but alas the ones I got can't handle the current drawn by the OPi either. Seems that a buck converter that can actually handle the OPi's current draw might be rather larger than can fit as well.

So now I have to find a small boost converter that can boost 5V to 12V. The rated current needed here is far more modest (of the order of µA), so such a module might be smaller, but one that might suit is hard to find. I have a boost converter module based on the LM2577 but it is much too big to fit in the case. The circuits involving the MAX232 that I've used before to get 18V are also too large. I've found one possible boost converter module that might suit but it is a bit more expensive, but we'll see how this goes.

One of the things I noticed about the CPU of the Orange Pi Zero is that it tends to run very hot, and it would frequently hit 60°C+ during my tests of the random number generator circuit. So I put my tests to a halt, and I bought heat sinks for it, which just arrived today, installed them, and tried to run the generator. I noticed that the program I have sampling the GPIO pin ran much, much faster with the heat sinks (>40 kbps), but also it failed the FIPS 180-2 tests consistently. Now that says quite a lot. Seems what's been happening is that before I got the heat sinks, CPU speed throttling has been fortuitously preventing the OPi from sampling the RNG circuit at a rate higher than the maximum noise bandwidth available from the circuit (I estimate it to be at around 8 to 12 kHz or so), but with the thermal issues addressed by the heat sinks, the OPi was then able to sample it at a rate above that, and so the random bits became far more biased. I did a few more changes to the code to add delays to GPIO sampling, and the quality of the random bits generated increased substantially. So yeah, I think that was it.

I think that was also the reason why the RNG circuit experienced such catastrophic failure before as well. The room upstairs with my router and all of the other home server equipment is air conditioned, and so there were less thermal issues up there than downstairs where I conducted the other tests, where there is no air conditioning. The kernel was throttling the CPU down to a rate at which it was only capable of sampling the random circuit somewhat below the available noise bandwidth when I had the OPi downstairs, but upstairs where the CPU was being cooled by air conditioning, it wasn't being throttled as much, and so the RNG tests were coming up heavily biased as a result. Such are the vagaries of life.

So now it looks like I'm going to have to enforce stricter sampling of the random number circuit or use stronger unbiasing algorithms, like perhaps getting 1024 bits from the circuit and using SHA-256 or some other suitable hash algorithm to generate 256 less biased random bits from there. I'd prefer to avoid using such complex methods to unbias the circuit though.

I'm going to try to find some other promising circuit designs as well. The one described here sounds like it might work very well, but that requires me to construct a PCB and solder several surface mount devices. Seems I can manage that somehow, given that I managed to successfully solder an SOIC8 IC (an ATECC508a) onto a breakout board, but of course it will take much longer. The other circuit I've done experiments on, which involves driving the base-emitter junction of a transistor above breakdown voltage, requires a 12V+ supply. Maybe what I can do here is provide power to the whole board from a 12V power supply brick regulated down to 5V using a simple 7805-based regulator circuit, as it seems putting 5V on the GPIO header's power pins will power the whole board (at least according to this). That will save the 5V to 12V boost converter circuit which would otherwise take up a large amount of expansion board real estate.

And so after another disastrous attempt at soldering together a hat for my Orange Pi Zero I decided to find out whether the fault was in my hands or in my tools. There are two electronics shops I go to around here for simple components, tools, and such, and I decided to look at the other place for a new soldering iron tip. They had one last in stock, and when I tried to use it, it worked like a damn charm. The old soldering tips the other store sold me would only heat on the sides of the iron, the tip was not hot enough to melt the lead. Probably those tips are truly rated for a more powerful soldering iron than the cheap 30W one I have, despite the store people telling me that it was for a 30 W. One of these days I'll shell out the US$20 equivalent for what looks like a reasonably decent soldering kit that one of the online stores I've seen is selling. I'm not blowing hundreds of dollars on a serious soldering station though.

And so with my better soldering tip I set out to build a hat with a true random number generator based on Julien Thomas's XR232-USB. I first built a mock-up of the XR232-USB circuit on a breadboard with an actual ATTiny85 using Mr. Thomas's firmware and an FTDI cable, and it indeed produces very good random numbers based on rngtest's FIPS 140-2 and Dieharder, though it is slow, at about 400-500 bits per second at most.

Then I soldered together the LM393 circuit as on the XR232, sending the digital noise from the LM393's pin 1 (going to pin 3 of the ATTiny85 in the XR232 circuit diagram) with a 4.7kΩ pullup resistor to one of the GPIO pins on the Orange Pi Zero. I wrote a small C program to read the GPIO pin and do some simple debiasing using the same algorithms (as far as I could tell) that Mr. Thomas used in his firmware. I'm getting an average rate of 16 kilobits/second from the random circuit using the GPIO pin. I suppose that's the most I can expect from the hardware. It's still much faster than XR232-USB, which seems to top out at 400-500 bits/second. The random stream seems comparable in quality to that of XR232-USB in general. However, when I plugged the OPi into my wired network, using a network cable close to my Wi-Fi router, the performance of the random circuit dropped like a stone, with more than 99% of FIPS 140-2 tests failed. Repeating the test such that the OPi was again far away from the router (but connecting to it wirelessly), produced much better results, with around 1% failure rate as before. I'm guessing it must have been getting scads of interference as it was quite literally sitting on top of the router.

I suppose I'll have to figure out some way to shield the random circuit from such interference. Possibly the copper tape which I bought but hasn't yet arrived will help, or maybe I can do some experiments with aluminium foil. I've never actually had to actually deal with EMF shielding for my circuits that much before. A simple Google search about it yields a lot of results from literal tin foil hat conspiracy theorist types (some of whom seem to try to cover their houses in EMF shielding), in between serious results about electromagnetic shielding for electronics.

Once I'm able to figure out how best to shield the circuit from my own Wi-Fi router's interference, I'll start working on a module to make a /dev/hwrng device for this so it can feed the Linux kernel randomness pool.