A New Computer

This month I gave up on waiting and ordered the remaining parts for a new PC. The build process was as easy as expected. Having learnt my lesson of having to maintain a system over many years; I took my time when routing the cables around the case. The result is one of the tidiest case layouts I’ve ever put together. Less obstacles means cleaner airflow inside the case and less noise.

PWM fans are a must have item. This new pc has 9 fans in total all connected up. It is quieter than my old system with 5 fans. The difference is having fan headers on the motherboard to support additional fans with a PWM signal to control the fan speed. Slower fans means less noise. When they spin up under load I can hear them more but at idle I hardly know the system is on.

Now the negative. Why must everything be covered in LED’s? My motherboard can put on a light show in all the colours of the rainbow, why? I intend to be looking at the screen not inside the case. I’ve not colour matched my components, I chose the best specifications instead. The obsession people now have with the look of their pc internals is staggering. Manufacturers are now adding features just to make them look better. I don’t need my RAM slots to be illuminated. How much additional cost is this adding to my motherboard? LED’s don’t cost a lot but the time and effort that must go into routing the traces around the PCB won’t be insignificant. Luckily I can turn the main lighting off in the BIOS. I just have to contend with the remaining illuminated buttons and status indicators scattered about the board. I wish it had a stealth mode with them all off until it actually had the need to display an error message.

There still needs to be some tweaking done to the system to get it settled in but it’s an upgrade that should last me 5+ years all being well.

New Projects

This month I have started a couple of new projects. It began as one but soon split. The primary project was to make use of a 128x64 I2C OLED display. It has been sitting on the side for a few months after an impulse purchase. It soon became apparent that I needed a way to generate static images for the screen. Although there were programs out there that would convert a bitmap image into the hex code I needed, many were for Windows. So I decided to have a go at converting it myself.

So new to my GitHub repo are:
DN2015-001 – An interface for the SSD1306 OLED Display Driver
DN2015-002 – A bitmap to hex converter for use wwith DN2015-001

Both projects are under development at the moment. How much they develop will depend on how my experimentation with the OLED display goes.

Damn You ISR!

I am sat here on a Sunday evening trying to debug embedded C/C++. For the most part all has been going well and the code has been behaving as expected. I have however run into one of my least favourite problems, the interrupt service routine (ISR). I have a couple of ISR's and they are presenting an unexpected start-up condition. The flow of the main body of the code is fine. I just can't understand why I am getting the current output.

All these problems take me back to a traffic light program I wrote at University. That worked fine for most of the sequence only to be tripped up by an ISR along the way and ending up in a stuck state. Not what you want from a set of traffic lights, especially if you find yourself stuck in the queue behind the red light.
Luckily there wasn't a green light & green man situation with the pedestrians finding themselves in the role of Frogger.

Only one solution for this situation; single malt.

SPI Bus Problem Solved


This image is the result of a week of pulling my hair out. It is a simple read of a register on a device connected to a micro controller over an SPI bus. The protocol was simple, the code driving it was simple, but until today it refused to work. I had checked the connections, the component values, changed some of the hardware but wasn't having much luck.

The time came to get it onto the oscilloscope. I treated myself to a Rigol DS1054Z a few months ago and it has proved its worth already. Having access to a 4 channel scope with protocol decoding has allowed me monitor the bus and find my fault. The scope revealed that the SPI MISO line was signalling the same as the SPI Clock. It turned out I had a tiny solder bridge between some header pins on a break out board, never would have thought to look there. After removing the solder bridge I now have a working SPI bus. Now time to do something with it.

The Big SSD Research Post



This article was written at the end of 2014. Most of the content will remain relevant in the future but there may be aspects which become outdated as hardware and usage practices evolve.

I have purchased an Intel 730 Series 480GB SSD with the intention of using it in my Fedora desktop machine. There are many articles online that discus how to configure an SSD, what to put on it, which partition structure to use, which mount options etc. I wanted to set the drive up to get the best out of it and my system as a whole. What follows are the results of my research and the decisions I have made based upon it. The writing style is based on my own note taking and primarily for my own reference. It is my hope that it posting it here that it may be of use to others.

What do I put on my SSD?

There are many posts/articles online asking this question and the answers to them vary. What became apparent immediately was the age of some of the discussions. Information from 3-4 years ago based the decisions on drive size (32-128GB).

An SSD with a limited amount of capacity is often set-up along side a traditional HDD.

A typical partition layout for a smaller SSD & HDD:


/boot & / are the main operating system and program partitions/directory structure. SSD's are sometimes referred to as 'boot drives' as by having the OS and applications on it would allow the system to boot and respond faster.

Swap wouldn't be placed on the SSD as if you were frequently using the swap space you would be putting additional wear onto the SSD.

/var contains log files from the syslog daemon. Frequently wrting small amounts of log data increases SSD wear. /tmp in much the same way has small temporary data that increases wear. /home is occasionaly placed on the SSD depending on the space required by the user. The HDD would be used for music, photos, large files and other user generated data.

SSD's have been increasing in size over time and the space limitation isn't such an important factor. What does remain in the considerations of the amount of data being written to an SSD.
Continue reading "The Big SSD Research Post"

A New Keyboard

Corsair K70 Keyboard Image

Over the last couple of weeks I have been using my new keyboard, a Corsair K70 (Cherry MX Blue Switches, Red Backlighting). I had been eyeing up a mechanical keyboard for some time; putting off the purchase due to cost. Finally one of my considered options appeared on offer and I finally parted with some cash.

My past couple of keyboards have been from Logitech. The MX3100 Cordless Desktop had served me well from around 2004 until the present. I dabbled with a K270 in 2012 but the spongy feel soon caused me to swap back.

The K70 is solid, it doesn't flex or slide across the desk. The back light will take a little getting used to but can be turned off. The MX Blue switches themselves feel lighter to the touch than I was perhaps expecting. This is no bad thing. The clickyness did worry me slightly as I had originally intended to get the MX Brown switches. The click is noticeable but hardly a problem.

Based on some reviews of the Cherry MX switches I purchased some o'rings to fit to the keys (to stop them bottoming out noisily). The sound of the keys bottoming out didn't really bother me. When trying a few keys with the o'rings fitted I found that I didn't like the reduction in key travel and removed them.

On the whole I like the K70. If I get a decade or more usage out of it like the MX3100 I will be very happy indeed.

Device Menus (User/Configuration/Service)

During experimentation with my I2C board (dn2012-000) and an Arduino board, I decided that I wanted to code in a service/configuration menu to allow me to change settings and read the memory locations without having to reload the sketch. This had me thinking about menus in general and how they are implemented on different devices.

How are menus implemented on existing devices? What methods are used?

My day job working in Medical Engineering means I have plenty of opportunities to work with products from different manufacturers. Devices range in cost from the cheaper (replace rather than repair) items to the very expensive (needing maintenance/servicing over many years). The devices can be the latest the manufacturer has to offer or the ones that refuse to fail as they were built to last. Device menus are implemented in a few distinct ways.

Approaches to menu implementation

1. No menu options. The device has no changeable settings. Fixed HW/SW.
1a. No menu options. Switch or button operation to toggle modes, features. Fixed SW.

2. User accessible menu options during normal operation. Changes reset on reboot, power cycle. [Features such as Volume, screen brightness, alarm triggers]

3. User accessible menu options during normal operation. Changes preserved across reboot, power cycle. [Features such as Volume, screen brightness, alarm triggers]

4. As approach 3 but requiring user to input a code to change or save a setting.
[Used for setting default alarm triggers]

5. As approach 4 but requires user to enter multiple codes to enter different levels of nested menus. [First code for configuration options, second code for service menu]

6. Configuration/Service menu is not accessible via normal operating mode. Unit needs to be put into service mode. [Prevents accidental changes of settings]
6a. Combination of button/switch presses during power up.
6b. Change/removal of physical switch/jumper. Can be hidden/internal.
6c. Hardware dongle or key.

7. Data Port. Another device (Laptop/RS232/USB/Other) is connected to a data port to access settings. [Less complex user interface needed on product, can be used to take log data from device.]
7a. Manufacturer provided cable/programmer [Usually for non-standard ports/protocols]
7b1. Terminal Access (RS232/USB) - Standard Serial Console tools
7b2. Terminal Access (RS232/USB) - Manufacturer Application
7c1. LAN/WIFI – Access Web Interface
7c2. LAN/WIFI – Manufacturer Application
7d. Memory Card/USB Stick to upload/download settings file.

8. Multiple of any of the above approaches.

Assessment of Approaches

Creating the different menu methods requires different amounts of hardware/software to implement. Having a code to change settings needs a way to input the code and process it.

Whichever method is used depends on several factors:

  • What does the menu needs to access? (user settings, configuration, logs, service functions)
  • Who needs to access the menu? (End User, Developer, Service Personnel, Company Representative)
  • How often is access needed? (Easy access for common tasks of a few more steps for occasional options)
  • Where is access needed? (On-site, during use, on a workbench)
  • Disassembly / Tools required?

The method used will ultimately depend on which is the best fit for the product. If the user interface is sufficiently complex anyway adding extra menu options is software only. A basic user interface might encode options as numbers on LCD/7-Segment displays or just go for a data port approach.

Which Approach will I use?

My needs are simple. I am working with a serial data connection, led and 2 buttons (one is for resetting the Arduino board). My approach will use a held button and board reset to enter the service/configuration mode. The same serial console used to read data during normal operation will be used to show the menu. No additional hardware required. I have no need for codes to protect changes as the project doesn't warrant the additional security that brings. The need to enter service mode and connect with a serial terminal should be sufficient to prevent accidental changes.

The intent is to have the serial console output human readable text. This might change if the program exceeds the capacity of the chip. In this case I might resort to an external application to provide the human readable side by processing the raw serial data.

Cooling Things Down

Summer is approaching and the weather is getting slowly warmer. This brings with it the annual problem of having a computer in the bedroom kicking out heat and making it too warm. Another issue that had been causing me some bother for a few years is the power settings on my graphics card, a Radeon HD6850, when running Linux. I use the open source radeon driver as keeps improving overtime and has enough of the performance of the closed source official driver for my needs. The one thing that has been lacking in my particular case has been the dynamic adjustment (radeon.dpm) of the card to keep it running cool. I have been forced to manually set the card to a low power state each time I reboot the machine. Failing to do this means the card boots up running full speed and quite happy to warm the place up. The downside is that I am always in the low power state and any tasks that might make use of a bit of extra power never get it unless its specifically enabled.

Today was time for a bit of research and a test. I had a Radeon 7850 in my other machine and decided to swap them over. It means that I have a weaker card for gaming on Windows but I don't play that many games and out of the two machines it is the one next due an upgrade. So has it made a difference? The simple answer is yes. I found that after rebooting the Linux machine with the HD7850 that it had automatically switched to using the dynamic adjustments and all was working well, one problem solved.

The heat output was the thing I really wanted to improve and I am pleased to also report a successful change (results below). I am happy with a slight decrease in temperatures along side the enabling dynamic adjustment. I continued to experiment and discovered that it can get even better. I have 2 24" Dell monitors and these can both kick out a bit of heat. Whilst I like a dual screen setup I often switch to just one (mainly to boot the Windows machine on the other). Driving just a single monitor I have noticed a further drop in temperatures (results below). This apparent temperature drop with a single monitor was not noticed when using the HD6850.

Test Conditions:
- Ambient Temperature: 22C
- System settled on normal desktop, no user activity.
- 2 connected displays @ 1920x1200

Before (HD6850 in Low Power Mode):
- GPU Temp: 65.0C
- CPU Temp: 41.4C

After (HD7850 radeon.dpm=1 balanced profile dual display):
- GPU Temp: 47.0C
- CPU Temp: 37.1C

After (HD7850 radeon.dpm=1 balanced profile single display):
- GPU Temp: 39.0C
- CPU Temp: 36.0C

An upgrade to some slightly newer, better driver supported hardware can result in a gpu temperature drop of around 18-26C (depending on setup). It might not make a huge improvement in room temperature alone, but it is a step in the right direction.

Fixed: Fedora 16 Printing

During my upgrade from Fedora 15 to 16 several things broke, this is nothing new there were alot of major graphical components updated. Those issues were resolved in the week following the F16 release. What I had not expected to break was my network printing setup. In all the years I used Gentoo and upgraded over and over I never had many issues and when I did it was usually my fault.

This time nothing much was apparent aside from printing not working on either the host or client machines. First point of failure was the lack of a running CUPS service on each machine. Ok, so it was stopped during the upgrade and not restarted, annoying but not the end of the world. Still no joy. In the end I found I my previously set sharing settings had changed. With all the other changes in config files being highlighted allowing for manual updates this had slipped through the net. Sharing my printer again in the settings and bingo, everything works as before and auto detects. It has only taken a few minutes of fiddling around to fix but it has been finding those few minutes and being in the right mood to fix it. Hopefully the next upgrade will go a little more smoothly.

Fedora 15 – Initial Thoughts

I took the plunge a few days ago and updated my machines to Fedora 15. The results have been mixed. My netbook and laptop were the first to be upgrades with Intel and Nvidia graphics respectively. Both upgraded fine and the Gnome 3 experience was ok, if a little strange. The problems started with my server with an AMD/ATI graphics. The screen was tearing in places and the smooth experience I was getting on the netbook and laptop had been lost. I still have not fully resolved this problem and it proving difficult to use gnome 3 without it.

The one thing I am finding an issue with in Gnome 3 is the change in panel functionality. I previously minimised some applications like my RSS client to run as a minimised icon. Whilst there is a sort of similar function present I think apps need to be updated to take advantage of it.

Another problem presented itself in the form of a reboot leading to the a message saying the lan cable was unplugged. Rebooting again didn't solve the issue. I had to shut the machine down completely and cold boot before the network stated working again. At least one problem is solved. I will review again once a few more bugs are fixed.