Archive - 2016

Something old, something new: building a NAS with a few older parts
New project: modifying Logitech C920 webcam for PCB inspection
Badge Computer gets battery and mounted
Memory controller work continues….workaround 4MB SRAM add-on
Cirrus Logic CS4335 DAC problems finally identified and fixed.
left-justified DAC problems continue
Trying to debug my design for an Audio DAC Cirrus Logic CS4334
J68 is now booting from User Flash Memory on the BEMICRO MAX10 FPGA board
Still debugging the attachment of User Flash Memory to the J68….
LCD Test image and pixel-level detail

Something old, something new: building a NAS with a few older parts


About eight years ago, I bought a Dell XPS 420 pictured above. This was an Intel Core 2 Quad Q9550 running at 2.83ghz. With 8GB of ram. Despite running reliably for over 8 years, the main problem was that the case was a piece of crap. The ventilation on it was horrible, and the (2) supported hard drive slots were just ran too hot. I modded the case adding multiple 120mm fans for an improvement, but this case was never going to support more than a couple drives. Never mind, also, that the motherboard was a BTX format. You’ve read right, BTX. Not ATX. Not microatx. Not ITX. BTX. As in the supposed next gen motherboard format. It didn’t pan out. Despite being (8) years old, this processor still ran like a champ, though, and due to previously virtualizing the physical Windows 10 machine with VMware Workstation, I had no other use for the hardware.

Now enter These guys are my heros. I feel at home with other people storing tens to hundreds of terabytes. at home. for no reason other than to do it! I was in heaven! This was my inspiration.

Here were my goals:

  • Use my existing processor and 8GB ram. There’s nothing wrong with them, plus this processor can be OC’d, if necessary.
  • Build something with reasonable performance and obvious bottlenecks removed.
  • Make sure that the solution that I implement can be upgraded at a later date. Don’t spend money that will simply be thrown away.

Here’s what I ended up with:

PCPartPicker part list / Price breakdown by merchant

Type Item Price
CPU Intel Core 2 Quad Q9550 2.83Ghz Quad-Core Processor Purchased For $0.00
CPU Cooler Cooler Master Hyper 212 EVO 82.9 CFM Sleeve Bearing CPU Cooler $24.88 @ OutletPC
Motherboard Intel DQ45CB Micro ATX LGA775 Motherboard Purchased For $22.50
Memory Wintec Value 4GB (2 x 2GB) DDR2-800 Memory Purchased For $0.00
Memory Wintec Value 4GB (2 x 2GB) DDR2-800 Memory Purchased For $0.00
Storage PNY CS1311 120GB 2.5″ Solid State Drive $39.99 @ Best Buy
Case Cooler Master Storm Scout 2 (Black) ATX Mid Tower Case $96.99 @ Best Buy
Power Supply Antec 550W 80+ Gold Certified Fully-Modular ATX Power Supply $89.99 @ SuperBiiz
Other SAS9211-8I 8PORT Int 6GB Sata+sas Pcie 2.0 $99.35 @ Amazon
Other iStarUSA BPN-DE340SS-RED Red Color 3×5.25 to 4×3.5 SAS / SATA Trayless Hot-Swap Cage $91.00
Prices include shipping, taxes, rebates, and discounts
Total (before mail-in rebates) $474.70
Mail-in rebates -$10.00
Total $464.70
Generated by PCPartPicker 2016-11-30 17:28 EST-0500

Rationale for new parts:

CPU Cooler: Pretty popular one, and could easily dissipate the 95W from that processor. I might overclock, so that cooler gives me headroom.

Motherboard: It was $22.50 shipped, supported my processor, supported my DDR2-800 RAM, had (5) onboard SATA II’s which should support most hard drives just fine. I don’t think new compatible motherboards are made any longer for this processor. Onboard video is nice because then I can use the PCI-e 2.0 x16 slot for the SATA card below. Gigabit LAN. This part would be thrown away (along with the CPU and RAM) once I decide to upgrade.

Storage: PNY1311. This is basically the cheapest SSD that still got decent reviews. It was about $40 for the 120gb model. I’m planning on running linux. I think my current install takes around 9gb. I’ll have plenty of room. Besides, I’m not actually copying any large amounts of data to or fro on it. I don’t want to use a spinning drive for the OS boot device.

Case: Although I’m not a big fan of the shape, it has a few things going for it. It has a nice carry handle at the top. It has plenty of venting including room for (9) fans — (3) included with the purchase. It has a side window. The INTERNAL hard drive slots number about 7. The hard drive slots face OUT of the case which makes AMCs very good. The (3) external slots are very useful for the drive cage below. Supports both 2.0 USB on the front panel AND 3.0. This is perfect — 2.0 for now, 3.0 for later!

Trayless hot-swap cage: This is very nice feature. I bought the 4-banger instead of the 5-banger because the 4 inserts better than the 5. It’s great to add, move, change a drive without taking the case side off. It fits because it has specific support for rails in between the three external slots. The other versions will likely require you to mod your case! Pay attention to the slots cuts into the sides of certain units.

Power Supply: 550W should be sufficient. The processor takes 95W. I wanted to add plenty of headroom for powering drives. Fully modular is really nice for cable management.

LSI 9211-8i SATA card: This card supposedly has great Linux support, and many people in the datahoarding community recommended it. I sent an email recently about support and got emailed a useful answer back within 5 minutes!! This card supports (8) SATA ports at 6.0gbps each. I’m willing to bet this interface is faster than the on board ports!


  • (4) hot-swap trayless drive bays available with easy in/out. I’m a little worried about the small 80mm fan on the back of this. I’m going to monitor temps on these drives.
  • Physical support for about (10) drives. I’m using one of the bays for the OS boot drive SSD.
  • Proper power supply. Those drives might take as much as 250 watts PEAK on startup.
  • I think a 2.83ghz quad-core (non HT though!) should be beefy enough for a NAS box. We’ll see!
  • 8GB of RAM should also be sufficient for a mostly headless Ubuntu install.
  • While this is the physical SETUP, what’s the logical one going to be? I’m not sure. I think Ubuntu 16.04 LTS, SnapRaid, mergerfs, with rclone/crypt going to Amazon Clone Drive.

Wish list for next upgrade

  • USB 3.0 for fast flash drive access. I might buy a PCIe 2.0 x1 card for this soon!
  • Modern hyperthreaded processor. I have to learn where the bottlenecks for this current/new system would be!
  • Maybe dual gigabit with some bonding capability. Yes, I’d have to upgrade the switch too. Not sure how cost effective this is. I can see how 125MB/s isn’t going to cut it if I end up striping somehow.
  • ECC RAM for sure. Again, how much does that increase my overall costs?
  • I’d love to have most/all drives be external drive cages. Support for 10-12 drives externally!

Please feel free to comment below. Especially if you have ideas for how to provision this box. My LSI card comes in a couple days.

UPDATE Dec 2016

I had major compatibility problems with the DQ45CB motherboard and the LSI 9211-8i card. The main problem was that the mobo detected the LSI card as a video card, and shut off the needed onboard video. When I added a PCIe x1 video card, then Ubuntu started throwing a bunch of errors. And Windows 10 wouldn’t even boot. After days of fighting to resolve the various conflicts, I simply ended up buying some new stuff. More expensive, yes, but simpler with a better end result. I ended up adding:

  • Intel E3-1275v5 processor at 3.6ghz. Quad Core / 8 Threads. Supports ECC RAM
  • Supermicro motherboard x11ssh-F-O. Supports ECC, 8 onboard SATA ports, plenty of PCIe slots, USB 3.0, and everything else you’d expect
  • 32GB of DDR4 ECC. It’s the slowest DDR available, but this is what’s supported with the CPU/mobo combination
  • A couple WD 4TB Gold drives, and a couple WD 8TB Gold drives. These are probably the best drives in the world for my application, have long 5-year warranties, high MTBFs, and I’m really hoping I get the ROI I think I’m paying for.

This is now probably more than just a NAS. It could easily host a few VMs, with processor time to spare.


  • Windows 10. Ubuntu 16.04 LTS isn’t directly supported by my motherboard, and again, I’m taking the path of least resistance. Windows 10 is fine and supports my preferred pooling solution.
  • StableBit DrivePool. Really sweet software, and it’s driving my OS choice. mergerfs on Linux seems to still have many issues to work out, and StableBit (despite being ~$56 commercial) just seems more reliable with tons of configuration features to really dial in what I need. Love it so far.
  • rclone with encrypted Amazon Cloud Drive for backup. This is my current backup solution, although it’s lacking in many ways. ACD will accept my full 150mbps pipe, which just kicks butt for fast uploading. It’s free. I still have to come up with versioning and better backup support. rclone is fantastic, but it just lacks some key features that I’d like to layer on top.
  • SnapRaid for my hashing, silent bit corruption detection, and repair needs. This software seems plenty mature, and it essentially works but I’m simply not happy with how it’s working with the rest of my setup. Maybe my setup needs to stabilize a bit before SnapRaid will make sense?


New project: modifying Logitech C920 webcam for PCB inspection



I’ve recently spent some time modifying a Logitech C920 webcam for PCB inspection and soldering. Head over to the page for project pictures, links to the various components, tricky gotchas I found during the project, and more!

Modifying Logitech C920 webcam


Badge Computer gets battery and mounted


I needed a safe way to transport the badge computer for my trip to/from Hackers on Planet Earth, and so I put this together in typical hacker fashion.

I used  small piece of plywood to mount the components. Trying to find hardware that would work and be safe was pretty tricky, but I decided that this blue painters tape does the job nicely.

You’ll see there’s a couple additions:

  • a 3800mah 7.2v NIMH cell, used for powering this via battery, making it truly portable
  • I’m using a couple of low drop out voltage regulators: LD1117V33 for the 3.3v one, and L4940V5 for the 5.0v one.
  • a FPC extension cable that allows the screen to be remotely connected to the interface board

As many of you probably know, when you use a voltage regulator, you need to account for the drop out voltage. This voltage is the smallest allowable difference allowed between the INPUT voltage (in my case +7.2v) and the desired OUTPUT voltage (which is either +5.0v or +3.3v). Otherwise the voltage regulator fails to regulate.

See wikipedia : and

Normal voltage regulators would not work here, because as the NIMH discharges, the voltage continuously drops from a nominal 1.2V(with this battery, in practice a little higher, about 1.36V) per cell, and then drops to 1.0V per cell when it’s exhausted. We are using a 6-cell pack, so this translates to a starting voltage of about 8.2V, and a finishing voltage around 6V.


If we used a normal 5V voltage regulator like the 7805, whose dropout voltage is as high as 2V, then as soon as we got to 5+2=7V, then we’d fail to have +5V that we could count on. This leaves plenty of battery left, but unusable given those parts.

The L4940V5 low drop out regulator I chose only has a worst-case 900mv dropout. So this gives us until 5.9V. The battery dies at 6V, so this works out perfectly. Now the actual drop out voltage is dependent on the current being pulled through it, with higher currents increasing the dropout voltage. In our case, we don’t need maximum current, which means we won’t be”paying” with the maximum drop out voltage either. The actual dropout voltage is probably closer to 200mv than 900mv.


Memory controller work continues….workaround 4MB SRAM add-on


SO here’s a couple hundred dollars of SRAM parts ordered to add on to the FPGA. It goes like this: the memory controller isn’t fully integrated yet into the J68 soft-core, so I’ve decided to whack on 4 megabytes of 10-12ns SRAM. SRAM is expensive! About $24 for good quality ISSI ram.

What you see in the center of the image above are three (80) pin card edge MEC6-140 connectors that are designed to mate with the FPGA board. I needed something to mount the SRAM chip (48-pin TSOP I) on and something to mount these 80-pin connectors on. It turns out my closest match are these Schmartboard PCBs, which I’ve wanted to check out for the longest time.

It turns out that I really don’t care for these Schmartboards, partially because I don’t have the right 0.4mm tip required for the pitches, but there’s other reasons. These likely deserve their own review which I will do in a separate post.

It turns out that when you are creating memory boards, you’ve got to deal with a lot of pins. How many? 16 data bits wide, 21 bits of address, plus 5 control pins, oh yeah (2) power and (2) ground as well. So that’s a solid 46 pins you’re using. The 80-pin connector has about (60) usable data pins, so at least the FPGA can support this application.

I do love the fact that the memory I’m using are 10-12ns chips. Really fast access times. Here’s a link to the digi-key part.

Here’s what $75 in memory chips looks like:



Of course you’ve got to create a pinout and hope you get everything right.

Below you’ll see a half-finished board with the 80-pin connector on the right, and the SRAM soldered to the board underneath the wires.


I’ve just recently completed the entire board, more photos to come on this.

While a couple initial writes and reads functioned, some reads or writes are failing. I need to write a small state machine that loops through all addresses, and then reads them back to check for errors.

Cirrus Logic CS4335 DAC problems finally identified and fixed.

I had some assistance in fixing this problem. My always helpful friend Brian from Canada as well as some help from Steve @ the Audacity forums contributed to solving the problem. They filled in some blanks for me, and encouraged me to LOOK at the data to see the problem.

This is the “Quit thinking and look” solution found in this book called “Debugging Rules”. Absolutely love this book!! Amazon link.

  • I used Signal Tap II on the Altera FPGA as an internal logic analyzer to see both address values and ROM data values, so that I could correlate them with the serial data going outbound. This was an invaluable tool. There are also tutorials on youtube. Here’s an example of the data I was able to get: (CLICK FOR FULL SIZE)


  • I was also able to use my new mixed signal scope to capture the waveforms. The data is 8khz sample rate and 16-bit audio. Check out how nicely spaced these samples are — exactly 125ms apart!


  • The data coming out of Audacity’s Export Audio (Header: RAW, Encoding: Signed 16-bit PCM) was the opposite endianness that the DAC was expecting. I switched the bytes from 0xABCD to 0xCDAB and that fixed it.
  • My overall electronic design in Verilog for this was just ugly. And initially did not work — I wasn’t putting the right data on the serial pin at the right time. The right Verilog was ridiculously simple once I distilled it down properly.
  • I’ll post the Verilog with data files once I clean them up a bit. Feel free to email me (contact info above at menu) to nudge me if I haven’t done this yet.
  • I used SRECORD to convert the output of Audacity into a .MIF to load into a virtual ROM on the altera. I could have byte-swapped during the conversion, but currently do it on the FPGA. Either way is easy enough.
  • The initial 700hz tone that I have been fighting with for awhile finally came out alright tonight. It really was music to my ears.

Voice_011 (as a .wav file download or use Embedded Player below)


Voice_012 (as an .wav file download, or use Embedded Player below)

  • I added a little more interesting sound below:


UPDATE March 2017: You can download the entire Altera project directory here. The important files are the *_top.v file(contains the important serializer logic), dac_clocks(generates 256khz and 1.024mhz clocks from 50mhz onboard), and dacrom(loads the .MIF that contains the audio data). There might be other red-herring or unrelated (prior failed implementations) files in .rar, but I’m including them for completeness.

left-justified DAC problems continue

Here you see the analog sound waveform coming out of the DAC at the top in yellow.

I think I’m getting closer……I switched from the I2S DAC to a left-justified DAC just because the LJ one is a little simpler to design around….the MSB for the DATA is lined up with the LRCLK transition……

The digital channels below are the input to the DAC:

D3 is the serial data

D2 is SCLK


D0 is the MCLK


Latest audio clip:

Trying to debug my design for an Audio DAC Cirrus Logic CS4334

I purchased a CS4334 to eventually use as an Audio DAC for the badge computer. I’ve never worked with DACs before, and my knowledge of audio is somewhat limited.

This audio DAC is a Cirrus Logic CS4334 with datasheet available here.

This chip is the I2S variant, specifically not the LEFT justified or RIGHT justified one. Each variant has slightly different timing requirements. The I2S specification is located here.

The audio data is a simple 700hz tone for 4 seconds with sample rate of 8000hz, and using signed 8-bit export. The audio file is here. 8k_signed8bit_straight700hz4s <— rename the .txt to .aiff. Use “Import Raw” feature of audacity, specify 8000 sample rate, signed 8-bit pcm. I generate an altera .mif using srecord, and here’s the resulting .MIF —–> 8ksigned_700_4s.

Here’s the output that I’m hearing. There are (8) chunks of sound as far as I can tell.

There IS my 700hz sample found in one of those eight chunks. It’s the “purest” sounding chunk of sound. You’ll know it as soon as you hear. LINK if the player below doesn’t work for you.

Any help to what the heck I’m doing wrong here would be appreciated!!

Here’s my verilog:

dac_clocks dac_clocks_inst (
.areset ( 1'b0 ),
.inclk0 ( SYS_CLK ),
.c0 ( SCLK ),
.c1 ( LRCLK ),
.c2 ( MCLK ),
.locked ( USER_LED[1] )

reg [7:0] sendbyte;
wire [7:0] romout;
reg [13:0] address;

reg SDATA;
wire SCLK; //128khz
wire MCLK; //1.024mhz
wire LRCLK; //8000hz to match the sample rate

assign PMOD_B[0] = SDATA;
assign PMOD_B[1] = SCLK;
assign PMOD_B[2] = LRCLK;
assign PMOD_B[3] = MCLK;

//setup the edge detection for LRCLK

always @(posedge MCLK)

assign LRCLKfalledge=LRCLK_OLD & !LRCLK;
assign LRCLKriseedge=!LRCLK_OLD & LRCLK;

dacrom dacrom_inst (
.address ( address ),
.clock ( MCLK ),
.q ( romout )

/*this is to satisfy "In I2S mode, the MSB of the left channel is valid on the second rising
edge of BCLK[my SCLK] after the falling edge of LRCLK. Similarly, the MSB of the right channel is valid on the
second rising edge of BCLK after the rising edge of LRCLK"

reg [7:0] twocycledelay;
always @(posedge LRCLKfalledge or negedge SCLK)
if (LRCLKfalledge) twocycledelay <= 8'b0;

if (!SCLK) begin
twocycledelay <= twocycledelay + 8'b1;

if (twocycledelay == 8'd2) begin

sendbyte <= romout;
//counter <= 3'b0; //reset the bitcounter because we have a new byte

//else counter <= counter + 3'b1; //send next bit if we're not resetting



always@(posedge LRCLKfalledge) //when it's true that there's a falling edge, read the next byte
address <= address + 14'b1;
if (address == 14'd32000) address <= 14'b0; //data in rom is 32000 bytes deep

reg [2:0] counter;

//send data MSB first. is it already two's complement from audacity?
always@(negedge SCLK) //put the data on the falling edge so that the receiver can read it on rising.

SDATA <= sendbyte[3'd7-counter];
counter <= counter + 3'b1;

J68 is now booting from User Flash Memory on the BEMICRO MAX10 FPGA board

I’ve been struggling for quite a few nights and weekends over the last month or so.

I’ve now successfully attached the J68 to the built-in User Flash Memory. This means that the 16KB (actually about ~13KB) of the ROM monitor VUBUG is now out of the pre-initialized m9k’s configured as a ROM, and now into FLASH. Which is non-volatile, and will survive a reboot. The most important part of this is that it frees up our valuable high-speed on-chip m9k’s.

The solution involved waiting for rd_ena (read enable) to go high, and combining that with the address that makes it a ROM READ, and then passing that to the Altera IP Flash avalon-mm bus interface. Since the latency is a fixed-cycle delay, then I just shift that read-enable pulse to become the “data is ready pulse”, aka data_ack and feed that back to the J68.

I had some more complicated solutions including a state machine, but this way is clearly superior. I had created some bolt-on hardware to help troubleshoot the problem. While it helped initially, when I had the problem fixed, some symptoms in the add-on hardware hid the fact that it was actually working….

The SDRAM controller works in simulation when connected to the J68, and hopefully will be tested on hardware very soon. This puts the ROM code in FLASH, and the RAM on the 8MB memory chip where it belongs. This will give us what we need for future development, including the GPU!

Still debugging the attachment of User Flash Memory to the J68….

So if I take my working UFM avalon-mm Master controller (which if you recall, connects to the Altera Flash Memory IP core), and attempt to attach it to the J68, the J68 no longer boots the ROM monitor code.

Since it’s not booting, I really don’t have many indications as to why. I decided that writing a ROM bus sniffer that records ROM memory requests and responses, including how long it took to satisfy that request, was worth the trouble.

In the image below, you’ll see four 32-bit columns of data on the left. Each row is a separate request.

They are:

  • A 32-bit counter that increments once a master clock cycle. Right now, I’m just running at 33.333mhz, but this J68 works upwards to 100mhz. This is recorded at the time of the request — at the time rd_ena goes high.
  • The ROM memory address being requested (first column on the left in BLUE)
  • The 32-bit counter at the time data_ack goes high, which means the request has been handled
  • The actual 16-bit data value. Ignore the 0xFAFA — that’s just padding. (rightmost column in BLUE)


Note that the requests are being handled the next clock cycle, right now, with the M9k’s serving up the ROM file. So you see 0x3A request, 0x3B response. 0x40 request, 0x41 response, and so on. The flash will not be as quick, and there should be something like (5) cycles between them.

My plan is to attach my newly working debugger to the new J68 solution with the UFM, and compare it. I think the problem will be obvious once I see what is happening…..

LCD Test image and pixel-level detail

So I’ve managed to get a semi-working test pattern image up on the LCD.

Here are a couple shots:


If we zoom in about 10 times, we can see how the LCD really works, on an individual pixel level:


Pretty challenging to get a decent image out of this, but here you can see the individual LEDs that make up the TFT screen that we’re using….. Interesting that the roughly-purple color comes from Blue and Red mixed…. except they aren’t mixed, just very close together.


Here’s an idealized image…..looks pretty similar to mine!


I actually don’t think that the colors above in my test image are right….there seem to be documentation problems for the pinouts on the BEMICROMAX10…….