My HTPC was starting to feel a bit old (Asus S1-AT5NM10E that I bought in 2011) so I decided that it was time to get something new. I decided that I might as well run Steam OS on it so I can play games from the comfort of my couch.

The fan noise from my HTPC has always annoyed me, it has two tiny fans that I think are 40mm, they are RPM controlled but I still find them too loud. So the next one would have to be passive since it’s running 24/7 in my living room. I looked around for Mini-ITX boards with integrated CPUs that were as new as possible and the choice fell between the Pentium J2900 and Celeron J1900. Both of these are actually Atom processors (Silvermont) despite their names.

I went for the ASRock Q1900DC-ITX since it had an integrated power supply so I didn’t have to get a picoPSU or something like that. The difference in clock speed versus the J2900 wasn’t high enough to justify the extra cost in my opinion.

Hardware setup

I ordered the case from a different store than the rest of the things, and that store is apparently closed until 16/2, so there’s not really much to show about the build, but I will post an update when I get the case.

• ASRock Q1900DC-ITX (2GHz quad-core)
• 8GB Corsair 1333MHz CL9
• 120GB PNY Optima SSD
• Deltaco universal laptop charger

Total cost for this was 2672 SEK (approx. $325 USD), obviously excluding the 360 controller and the case I don’t have yet. You can save a bit by going down in RAM size to 4GB, but Linux is good at utilizing RAM for cache so I chose 8GB.

There’s not much to show here, just pop in the RAM and connect the cables.

Software installation

Just follow the official instructions for “Custom Installation” and everything should install automatically.

The first time it boots it will show you the desktop (yes, it looks broken, more on this later) while it’s updating the Steam client, just wait and when it’s done it will automatically reboot. After the reboot it started a clonezilla backup, after it was finished I had to select reboot in the menu manually.

After that reboot is where the interesting part starts. I had major issues in getting the graphics to work, when I booted everything just went black. I tried changing the default display manager to gdm3 to be able to at least log in to the desktop. This worked, sort of, but for some reason it didn’t pick the correct resolution and I couldn’t see the entire workspace, I had colorful flickering to the right and bottom of my screen. It also complained about hardware acceleration so I was most likely stuck in software rendering mode.

This went on for a while with me testing out different possible solutions, like manual Xorg.conf, different kernel parameters and so on. Then I checked the kernel version, and saw that Steam OS is running 3.10, which to me (used to Arch, running 3.18) felt like a really outdated version. So I decided to just add the Debian unstable repo and get a new kernel from there, even though I wasn’t sure it’d help.

I won’t list how to add a Debian repo here since the information is already available all over the net, you can pretty much follow this guide but replace wheezy with unstable where appropriate. Make sure that you set the priorities in /etc/apt/preferences so that it only uses packages from the unstable repo if you explicitly specify it. Since you won’t be able to access the desktop everything has to be done from the VTY, press Ctrl+Alt+F2 to get to it. If it doesn’t work for you you could try booting to recovery shell, hold Esc after powering on and select the second entry from the top in the Grub menu that appears, this should boot you straight in to a shell with root access.

After that you just run sudo apt-get install -t unstable linux-image-amd64 and the new kernel (3.16 right now) should be downloaded and installed. Reboot either by Ctrl+Alt+Del or sudo init 6. Steam should now start in full screen with proper hardware acceleration and everything.

One problem I noticed with the new kernel is that the kernel module for the network adapter wouldn’t load automatically, so you won’t be able to get past the network configuration part of the setup wizard. I don’t know why this happens but it’s really easy to fix, switch to VTY using Ctrl+Alt+F2 and log in using the desktop account, run sudo modprobe r8169 and the NIC should be instantly detected and working. This will however only work until you reboot, so for a permanent fix you also have to run sudo sh -c 'echo r8169 >> /etc/modules' so that it’s loaded on each boot. After you have done this you just switch back to the Steam setup wizard with Ctrl+Alt+F7.

Benchmarks

I like graphs and numbers, so I’ve decided to run a few benchmarks to see how the performance of this system is, and what you can expect from it if you’re interesting in building a similar one yourself.

I decided to stream The Witcher 2 for about 15 minutes while measuring network, CPU and RAM usage. I changed the bandwidth limit to unlimited even though it says that it increases latency, I also set “Client options” to “Beautiful”, but I’m not even sure what that does.

I had major issues when I had SLI enabled, the Steam client crashed when I started the game, and I was stuck on a black screen. So I disabled SLI for this test, so no Ubersampling (SSAA) enabled. Everything else is on max, but motion blur is disabled since I hate it with a passion.

By looking at the network graph (showing Mbit/s) we can see that there’s a pretty large amount of data being sent, but nothing the gigabit switch can’t handle. I noticed that it never went above 100 Mbit/s so I measured the throughput with iperf just to be sure, and it did show 944 Mbit/s.

You can actually see in the graph that I was in a part where there were a lot of cinematics, with less changes in the image than normal. The beginning and the end is where I pretty much just run around all the time, making it peak at about 90 Mbit/s. The red spikes you see in the upload is caused by me pressing F8 to save a screenshot and stats dump to the host.

The next image shows the CPU usage % of each core, I graphed this just in case one of the cores were close to maxed out. Luckily this wasn’t the case, and it seems to be distributing things over all 4 cores. You can see where I save screenshots/stats in this graph as well.

Low load on all 4 cores

This last graph shows the CPU load average, the RAM usage in % and the temperature of the hottest core in degrees Celsius. The temperature is really good considering that I have no fan anywhere near the board, this might change when I put it inside a case. RAM usage is so ridiculously low that I regret logging it in % instead of MB, I think it’s around 300-400 MB (excluding buffers and cache).

The J1900 handles it like a breeze

I have uploaded the script that I wrote to generate these graphs to GitHub, for those of you who might be interested, it’s available here. You can also download my rrd database from here, if you for some reason would like to graph something else from it.

Stay tuned for the coming update where I’ll be mounting everything in a case, probably around February 18-20. If there’s anything else you’d like me to test just leave a comment and I’ll try to make it happen.

I used to host my own WordPress blog, but since I hardly ever post anything it felt a bit overkill. Keeping it updated was also quite a pain, I hate running out-of-date software but I also hate updating things manually.

So I’ve decided to move to GitHub Pages. It uses Jekyll to generate static pages, and you write posts using Markdown syntax. Everything is kept in a public git repo.

I still want people to be able to comment on posts even though everything is static html pages, so I added Disqus for that. It dynamically loads comments into the DOM using JavaScript. It will also allow me to move to a different blog platform in the future and still keep all comments (provided that I use Disqus on the new site as well of course).

I’m kind of hoping that this update will inspire me to become more active, and post more. Even if I don’t have many readers it can still function as my personal project log, or something like that.

I’m planning on adding Spektrum satellite support to the APM (specifically the PPM encoder on the APM2.5) so the first step in the process is to take a look at the actual communication.

From what I’ve already read online at different places I know that it’s a regular serial data stream at 115200/8-N-1, however some of the other info I found regarding the actual protocol didn’t seem very consistent.

I will be testing both an official Spektrum DSM2 sat and an OrangeRX R100. I don’t have an actual Spektrum transmitter, I’m using a DM8 module with a few modifications to make it fit my Hitec Aurora 9. This also means that I can’t really configure anything in the module like frame rates or other fancy stuff.

My measurements were quite interesting, since the protocol looked different on the two satellites. Below is one frame from the R100, looking pretty much as I expected from reading online, with a 0x03 0x02 header followed by 2 bytes for each channel (7 channels total).

This frame was sent every 22ms as expected, since it follows the same frame rate as regular old-school PPM.

However when I connected the official Spektrum sat I noticed that it was sending the data differently. The first thing I noticed was that the header differed, on this one it was 0x00 0x00, but it was followed by 7 channels just like the R100.

Then I zoomed in on the next frame and saw that 5 channels showed up as just 0xFFFF.

The reason for this becomes apparent when you zoom out and see that there’s only 11ms between the frames. This is because the satellite is reporting 9 channels, and you can only fit 7 channels in a single frame. So the satellite sends channel 1-7 in the first frame and 8-9 in the second one, at double the normal frame rate. I fear that this could possibly cause some problems when implementing support in the APM, but more on this in a later post.

It didn’t take that long to figure out why the two satellites behaved differently though. The OrangeRX sat had been used with a 6 channel OrangeRX R610 receiver, and the Spektrum one with a 9 channel AR9000.

So the satellite uses different reporting modes depending on the type of receiver it was connected to when the binding occured. I verified this by re-binding the satellites with the respective receivers and measure that the reporting mode actually did change.