Back again after a long wait…

I recognise that it’s been a while since I last wrote anything here, but I’ve been keeping myself busy and haven’t been inclined towards writing. However, I have been working on a few things which seem rather relevant to the scope of this blog. I’ve found quite some use out of the NAS that I mentioned in my last post, I’ve been working on electronics experiments and have further built up my Raspberry Pi collection with a new addition.

Synology DS416 – Performance Benchmarking

In order to get some sort of understanding of the performance of my Synology NAS, which I have connected through its two 1GbE ports to an 8-port Netgear GS108E switch, I decided to use IOmeter to pit it against the data storage drive I have in my computer, a 3TB 7.2K Seagate SATA disk. As artificial as the results from IOmeter can be, it still gives a good idea of what the speeds are like against the SATA disk on which I put most of my non-OS files. Using a maximum disk size of 1,048,576 sectors (or 512MB) and leaving the tests running for 20 minutes each, I got the following results, where Z: corresponds to an iSCSI volume on the NAS and D: corresponds to the SATA disk:

4KiB; 50% read, 50% write; 50% random

Z: 692 IOPS, 2.84MBPS, 23ms latency

D: 185 IOPS, 0.76MBPS, 86ms latency

64KiB; 0% read, 100% write; 0% random

Z: 552 IOPS, 36.15MBPS, 29ms latency

D: 849 IOPS, 55.62MBPS, 18ms latency

64KiB; 100% read, 0% write; 0% random

Z: 1787 IOPS, 112.33MBPS, 8.9ms latency

D: 939 IOPS, 62.91 MBPS, 16.6ms latency

In the 4KiB test, which would appear to be the most representative of real-world tasks involving using the storage as a standard drive (although I would expect more reads and more random data to be passed through in that circumstance), the NAS clearly had the advantage, with three times the IOPS, three times the data throughput and a third of the latency. The NAS is not as good in the 64KiB write-only test, possibly as a consequence of the RAID penalty applied since the four disks in the array are set up in RAID 5, but the NAS takes the lead again in the 64KiB read-only test, both of which might represent me writing or reading in a manner befitting the drives’ purposes as archival drives. The read-only performance of the NAS also lines up with the maximum network read throughput that I’ve seen.

I’ve also installed a Windows 7 VM on a separate 1TB iSCSI volume on the NAS which I’ve used with VMware Workstation to provide me with some ability to play Windows games without having to reboot my system. There have been some issues with stuttering, which would be a deal-breaker in action games but has been sufficient for the strategy and WRPG titles that I have been using it for, like Hearts of Iron III and Planescape: Torment.

Electronics experiments – a new collection of gear to try out!

The electronics experiments that I had been doing before with my Raspberry Pi had gone on the backburner for a long time. However, with Robot Wars back on the BBC recently and my younger brother interested in building a robot, I’ve decided to get back into the world of electronics experiments with the idea of getting enough knowledge to build a basic robot, at which point I can get my brother involved with various tasks. To that end, I’ve stocked up on a whole new list of components. At the moment, most of these are limited to things I can stick on a breadboard instead of motors and so on, but the components I’ve picked up include MCP23017 I/O expanders to complement the MCP23008 that I already have, an alphanumeric LCD display, a few AY-3-8910 sound chips, along with piezoelectric speakers, LM386 amplifiers and audio jacks and a few crystal oscillators for the sound chips. I’m also expecting a delivery of SN76489 sound chips within the month.

So far, I haven’t got too far; I’ve done some experiments to illustrate that the MCP23017 chips and LM386 amplifiers work, but I’ll need to learn how to solder before I can test the alphanumeric LCD and the AY-3-8910 sound chip will require some time to understand before I can get it tested.

Anyway, here’s a basic schematic using the LM386 amplifier:

LM386 Amplifier_bb

Pin 5 on the LM386 IC is connected to a voltage source between 4V and 12V, while pin 4 is connected to ground. Pins 2 and 3 of the LM386 are hooked up to the ground and the positive line of the input from the audio jack respectively. Pins 1 and 8 can be hooked up to a capacitor with a maximum value of 10kΩ to increase the gain, but I decided to go without and use the internal gain of 20 just to test that the IC worked. Then, pin 6 is connected to the positive terminal of a piezoelectric speaker, which produces sound, although the datasheet recommends using various capacitors in order to smooth out the sound and reduce noise. Pin 7 of the LM386 provides a bypass for sound without amplification, but this goes unused in this circuit.

A new Raspberry Pi and plenty of toys for it

The Raspberry Pi Zero, since its launch, has been one of the most desirable and difficult to find models of the single-board computer. I’ve been interested in having one for the novelty of such a small, yet capable computer, but the propensity for it to be sold out has put me off. However, the Raspberry Pi Foundation recently announced the Pi Zero W, a variant of the Pi Zero with on-board Wi-Fi and Bluetooth in the same form factor, although with a price of $10 rather than $5. Since adding Wi-Fi and Bluetooth capacity to a standard Pi Zero would generally increase the cost more than the extra $5 equivalent premium that the Pi Zero W has over the Pi Zero on its own and require awkward USB extenders, this appealed to me and I decided to pick one up along with the official case.

Along with the new Pi Zero, I’ve also picked up the standard and NoIR camera modules, a Sense HAT and a Gertduino add-on board to provide the capacity of an Arduino Uno to my Raspberry Pis, especially the older Model B boards that I rarely use any more. As with the electronic components, I’ve only tested these enough to verify that they work, but I’m looking forward to using them when I find the time.

With respect to the Raspberry Pis that I already have, I’ve recently installed RetroPie on a spare microSD card for my Pi 3 Model B. I’ve been impressed by the performance of the Pi when it comes to emulation; even PlayStation games have been smooth on the system, while older systems like the SNES and Mega Drive have worked excellently. I took the system for a spin with some of my friends in a retro gaming night; let’s just say that my Tekken skills could do with a bit of an improvement! Installation of RetroPie is very simple and very accessible as well; after copying the OS image onto the microSD card, everything else on the system is straightforward and it’s possible to copy ROMs and disk/disc images on with a USB drive without any particular effort.


A Raspberry Pi Electronics Experiment – TMP36 Temperature Sensor Trials and Failures

I mentioned in my last post that I had received a Raspberry Pi electronics starter kit from SK Pang Electronics as a gift for Christmas, and between studying for exams, I have been experimenting with the components in the kit. Apart from ensuring that the components I received actually work, I still haven’t got much past the “flashing LEDs in sequence” experiments. I think I need a few more components to really experiment properly – transistors, capacitors, et cetera – but I have had a bit of fun with the components that I did receive.

Not everything has been entirely fun, though. One component, the TMP36 temperature sensor which I received with the kit, led to a struggle for me to find out how it worked. On the face of it, this should be – and if you test it without the full circuit that I first tried it with, is – one of the easier components to deduce the operation of. My temperature sensor is in a three-pin TO-92 package, with one pin accepting an input voltage between 2.7 and 5.5V, another connecting to ground and a third which has a linear output voltage with 500mV representing 0ºC and a difference in voltage of 10mV for every degree Celsius up or down from 0ºC. So far, so simple. The problem is that I made things rather difficult for myself.

The Raspberry Pi, unlike a dedicated electronics-kit microcontroller like the Arduino platform, doesn’t have any analogue input or output. In order to get analogue input or output on a Raspberry Pi, you need either an analogue-to-digital converter for input or a digital-to-analogue converter for output. This wasn’t a big deal; both the MCP3002 ADC and the MCP4802 DAC came with the SK Pang starter kit and I had just successfully tested the 10kΩ Trimpot that came with the kit with the ADC. My self-inflicted problems occurred when I thought (ultimately correctly) that the three-pin package of the temperature sensor looked like it would be an adequate drop-in replacement for the Trimpot. So, I plugged in the temperature sensor based on the schematics in front of me and tried running the program to read in and translate the readings from the ADC.

As I started the program, I noted that I was getting a reading. So far, so good, I thought. Then, I decided to press on the temperature sensor to try adjusting the reading. At this moment, I noticed that the sensor was alarmingly hot. Disconnecting the sensor as quickly as I could reason, I thought to myself, “Oh crud, I’ve just ruined the sensor before I could even try it properly!” Taking action based on the directions given for TMP36 sensor use on the internet, I allowed the sensor to cool before plugging it back in – the right way around, this time – and tried the ADC translation program again.

I was still getting a reading, but this time, I was more wary; I did not know whether this signified that the correct reading was being read or not. With the aid of an Adafruit tutorial written precisely to aid people using the TMP36 with the Raspberry Pi, I decided to modify the ADC translation program to give converted values in the form of temperature readings. Another problem seemed to ensue – the readings I was being given were far too low for the room I was in. I attempted to find a solution on the internet, by reading forum posts, tutorials and datasheets, but little of this made sense to me.

Eventually, though, at least one of the sources gave me the idea to use a multimeter on the temperature sensor to test whether the output voltage on the middle pin was reasonable. I plugged the TMP36 directly into the 3.3V supply on the Raspberry Pi and tested the voltage over the input and output. It was showing as approximately 3.3V, so there wasn’t a short voltage on the temperature sensor itself. I then tested the output voltage on the middle pin, and this showed a reading much closer to the 20-22ºC I was expecting from my room at the time. As far as I could tell, the temperature sensor wasn’t damaged from the brief overheating that it had experienced. However, at this point, I had other things to do and had to leave my experimentation.

Eventually, though, I got back to experimenting with the TMP36 again, and tried plugging it into the ADC again. It was still giving the same low readings, and I still didn’t understand completely if the sensor, the ADC or the program I was running was at fault. I was at a loss to understand what was going on, so I shelved the temperature sensor experiments and tried understanding the code for the other components so that I could try my own experiments.

Some more looking on the internet pointed me more towards the answer I was looking for, though. The datasheet for the TMP36 suggests the use of a 0.1μF bypass capacitor on the input to smooth out the input voltage, but this didn’t really sound like the issue I was having – more it seemed like there was a low voltage going into the ADC. A forum post gave me an idea – try using a multimeter to test the voltage going across the TMP36 when it was plugged in with the ADC, and the output voltage from the sensor with the full circuit going. So, I did, and again, the temperature sensor had 3.3V going across it and about 740mV output voltage from the middle pin. I was perplexed, and tried testing the voltages across the ADC itself.

It was at this moment that one little sentence from the forum post gave me the answer – the problems with using the MCP3002 for reading in the voltage from the temperature sensor were linked to input impedance over the ADC rather than any problems with the temperature sensor. The ADC was working correctly in terms of reading in the value, and the temperature sensor was also working correctly, but because there was an impedance on the ADC – the voltage going across the ADC is 3.3V, but the voltage between the input pin and the channel read pin is, at least on my MCP3002, 2.58V – there were incorrect readings. A bit of modification to the ADC translation program, and I had the sort of readings that I expected both on the output voltage of the temperature sensor and the screen where the results were being printed.

Rather a long-winded set of tests for a simple problem, eh? I suppose much of the problem lies in my putting the cart before the horse and trying experiments with my only knowledge of electronics being my long-faded memories of secondary school physics. In any case, the problem was found, and a problem in my own lack of experience was also found, which I can start rectifying soon enough.