The Boat PC – a marine based Raspberry Pi project


In late 2015 I was doing my usual head-scratching about what gifts to get various family members for the holiday season. My wife mentioned making something electronic for my father-in-laws boat, and after a few hours of collecting thoughts came up with an idea:

  • A Raspberry Pi computer, which could be powered off the boats 12v batteries.
  • This computer would have sensors which made sense on a boat. Certainly GPS.
  • I’d have some software which collated the sensor data and displayed it nicely.
  • This could plug into the onboard TV using HDMI.
  • It would all be put into a suitable enclosure.

Excellent – a plan. I expected the hardware part to be easy, the enclosure part fairly straightforward, and the software part to be an absolute disaster. I started searching for an already-existing project to take care of the software side of things.

That’s when I came upon a project called OpenPlotter. It’s a fully-featured linux distribution for Raspberry Pi, specifically for use on a boat, and includes the relevant software for calibrating, collating and transforming data from various sensors into a form that can be used practically. I’ve got to be honest here – OpenPlotter is solid, does exactly what it advertises, and very simple for someone familiar with RPi/Linux to set up and use.

After firmly deciding on OpenPlotter for the software, and knowing I’d be using an old Raspberry Pi 2 I had collecting dust, I looked at what hardware OpenPlotter supported. The list is fairly long, and gave me ideas I had not thought of previously – for example using a USB DVB-T television dongle as an AIS receiver with Software Defined Radio (SDR), allowing real-time data of nearby ships to be displayed. MarineTraffic uses this AIS data, but of course on a boat you can’t rely on an internet connection to pull data from – it’s much better to get the data directly from the VHF signals.

In addition to AIS and GPS, I’d add an Inertial Measurement Unit (IMU – basically an accelerometer, gyroscope and magnetometer in one) in the form of an InvenSense MPU-9150, and also a USB to RS422 converter. RS422 is specified as part of the protocol standard for NMEA 0183, which in turn is the communication specification used in marine electronics. Supporting input and output of direct NMEA using RS422 would allow for some extendibility, for example depth sensors that are already present can feed data into OpenPlotter using this port.

After going and purchasing all of these sensors, I realised that actually using the TV inside the boat isn’t going to be useful, as it’s not visible from the helm. Thankfully, OpenPlotter allows for headless operation, and will automatically set up a WiFi hotspot so you can connect a phone/tablet to the Raspberry Pi and control it using VNC or other software.

The Build

So, to clarify, all the hardware gubbins required:

  • Raspberry Pi 2
  • Invensense MPU9150 board
  • RTL2832U DVB-T USB
  • USB to RS422 Converter
  • USB GPS module
  • USB wifi module

Of course, we need some associated utility to make this into an actual device;

  • 12V to 5V power converter
  • Power switch & connector
  • Status LED
  • Enclosure

When I’ve done projects in the past (the biggest one being PiOnTheWall from years ago), I spend a significant amount searching for the right enclosure to put the hardware in. It’s not just a case of going and getting something that’s big enough to fit the contents, you need to know how thick the sides are, what kind of plastic is it, are there PCB standoffs included, are there vent holes?

After several days, I came up with the following which I got off ebay.


I knew already the RTL2832U SDR dongle could run quite hot – so ventilation holes were a must. It’s the hottest part of this hardare, easily 60C+, whilst the Broadcom SOC of the Raspberry Pi will have to be working fairly hard to hit 45C. I did not plan to heatsink anything, and in the end it works fine without them. I did make a concious choice though to have the SDR board at the highest point in the enclosure, closest to the vents.

The design was simple – switch and status LED at the front, RS422, SDR antenna, Power In and Raspberry Pi Mini USB/HDMI/Audio out at the back. I removed all plastic covers from any USB devices, as they just bloated the inside, and I knew removing USB connectors would be a requirement. Laying out the components, I found one which worked well.


The Raspberry pi would be put on metal standoffs – I used some spares I had from various PC motherboards and cases. I just drilled straight though the bottom of the plastic case with a bit size such that the thread would drive into the plastic.

In my previous Raspberry Pi project I butchered the board, and I’m pleased to say the only thing I had to do in this instance was make the fixing holes on the PCB slightly larger to accommodate the screws for standoffs.



The GPS and Wifi modules remained as dongles, simply connected into one dual header on the Raspberry Pi. To aid fitting all the boards into the enclosure, the male USB connector of the RTL2832U SDR dongle was placed on a ribbon cable. Additionally, the miniUSB cable for the RS422 converter was made small enough to fit in the limited space available. These two boards were physically fixed to the rear panel via bolts, and in the SDR boards case, a little shelf made from spare plastic.



I’m not very good at making good panel openings, so sadly my HDMI and microUSB ports are very poor. At least they are at the back, where nobody should be able to see them 😉

Internally, all that was left was to connect the 12V->5V DC-DC converter to the Pi, put a power switch inline with the input 12v Power jack, attach the LED to 3v3 (there is a resistor in the LED leg heat-shrink), and fix the rest of it down with the same standoffs. It ended up looking fairly neat and tidy.


For those wondering, I connected the 5V output from the DC-DC converter direct to the 5V rail of the Pi. It bypasses some input protection which exists on the miniUSB power input. For me this is okay, I hoped it would allow the SDR USB dongle to draw more power than is ‘technically’ allowed from the onboard USB ports. I knew that was an issue back in the Raspberry Pi 1 days, and couldn’t remember if that was still the case with RPi 2.

The final rear panel:


The front of the enclosure, unit powered and closed.


You will notice the USB socket on the front; I thought it could be useful to trickle charge phones or the tablet that would connect through WiFi to offer controls. I connected the unit to an HDMI monitor to do first-time OpenPlotter setup, making sure the sensors worked, and then switched it into headless mode, with VNC and NMEA 0183 output over it’s own ad-hoc WiFi hotspot.

Testing on the boat!

One thing that I could not test at home and needed to do on the boat was calibrate and test the AIS Receiver. There was a long gap between the hardware being “complete” in summer 2016, and testing it on-board in spring 2017.

AIS runs off VHF frequencies of around 162MHz, a wavelength of 1.85 meters. The boat has a marine antenna already which will work fine, but when I brought the device for testing did not have the correct connector to interface with the SDR dongle.


Because of this, I made a quick and dirty 1-wire, quarter wavelength antenna. I used a good quality coax, with one end exposing only the inner core to a length of 46 centimeters. I then hooked this around a bit of the boat outside. It wouldn’t get long range, but hoped I’d get some ship signatures in the marina – and it did! After following the calibration instructions on the OpenPlotter guide, I rebooted and after a few minutes the tablet (now connected to the RPi using wifi) displayed the following:


We used an Android app called SailTracker which takes the collated NMEA datastream and displays the data in an appropriate format. There are several paid apps that come complete with nautical maps, which is neat.


And that’s it! All installed, wired into the 12v, and also now using the VHF antenna at the top of the mast. I’m quite proud with how this one turned out, and I’m very impressed with the OpenPlotter distribution for allowing this project to work as well as it did.

What I’d change

There are 3 things I’d change if I was to do this again:

  1. Changing the front panel LED to RGB, and have it a real status LED rather than power. For example,
    • solid blue: OS booting,
    • flashing green: OpenPlotter starting services,
    • solid green: WiFi hotspot up,
    • red would be an error condition.
  2. Mounting the SDR dongle further in, allowing me to wire up the antenna input from the onboard mini MCX to a PL259 VHF connector on the rear panel. This would have eliminated some of the external complexity of needing various converters.
  3. I’d have a large cover over the microUSB/HDMI/audio raspberry pi connectors, as they are really only needed for debug, and it would have stopped me from making the messy cuts I did 🙂

Thanks for reading. If you have any questions or queries feel free to contact me at @domipheus.

Pi On The Wall – wall mounted home server – Part 4: Putting it together

This is part 4 of the Pi On The Wall build log, concerning modifications to the enclosure and how everything comes together into its final form factor. Part 3 was about power consumption, and optimizing it for low-power and ultimately low-temperature running. Previous parts can be found at Part 2 and Part 1.

41zJZupMBKLThe choice to use a standard (for the UK, anyway) footprint for the Pi On The Wall was made very early on. Ease of mounting to the wall (compatibility with existing wall-fixtures) and a wide range of cheap thermostats to choose from for simply utilising their outer shell.

thecaseAfter removing the guts of the £12 wall thermostat I purchased, the inside was what you’d expect – mounting posts for the PCB, guides for the LCD panel, and a PSU block behind it.

Internally, all I was planning on doing was removing as much of the PCB and LCD supports as possible – there was quite a few and they really restricted the usable space inside the case. A hobby drill and knife were enough to completely re-engineer the inside to suit my needs for maximum possible space (whilst still keeping some of the LCD guides, for the new panel). The following image shows the sort of supports that existed.

front_rear_unmodified On the rear panel, I removed the PSU block and smoothed the pcb supports whilst removing a notch for the flush USB connector.

case_modificationThe front panel ended up looking as follows after installation of the front TFT, after many hours of making sure it was perfectly straight, and holding it down with glue.

front_screen_buttonguidesNote the hole bottom right, for the PIR sensor/lens. It was countersunk to make it ‘neat’ and I messed it up. Which it why there is now a grommet on the opposite side, as the hole is too large for the sensor.

Also of note are the red straw tubes hot-glued into locations around the buttons. The straws are actually cut from the one provided with a can of WD-40, as I didn’t have anything else the correct size. The reason for these straws are made clear with the next image.

button_pcb_guidesThey form the guide for the small off-cut of PCB from the original thermostat which housed the tactile switches for the front buttons. The top one is flush with the PiTFT circuit board giving it a good fit.

frontpcb_wiringThe traces on that board were cut and the switches were directly connected to the 4 GPIO buttons on the PiTFT. There is not much else on this half of the enclosure, the main components (minus the actual panel itself) are laid out below.

raw_front_pcbsThe PIR motion sensor module was rather annoying in that it took 5v input and provided a 4.4v logic level signal when movement was detected. This is voltage divided through to 3v3 for a Pi GPIO input and is designed to switch on the back light of the PiTFT when movement is detected in front of the unit and works well. You can see some foam underneath the tactile switches, there is some on the other side as well when the case is fully closed to keep the pressure correct for the panel buttons. The PIR unit itself was deconstructed for ease of positioning the components, with 0.2mm enamelled wire being used to connect the sensor to the control board, as normal wire was too thick to also allow for the USB connector to fit snug above it.

heatsink_clampSomething I failed to write up well was the heatsink I designed for the Pi On The Wall. It needed to be incredibly low-profile due to the fact the PiTFT board was only 4mm above the Broadcom SoC. Using some very thin metal I cut out a strip which I moulded into a clip-like shape, which would clip either side of the PCB and provide some feedback into the top of the SoC whilst giving enough clearance to other components on the board.

heatsink_sinkAfter that some copper wire was soldered to the metal and arranged so the top of the SoC conducted thermally with the copper, with the help of some paste. The wires were routed to what would be the top side of the board, where the case has ventilation holes. I cut a small aluminium heatsink into two strips and then soldered the wire to those sinks, very poorly. Aluminium does not solder well and I only managed a very weak bond using the oil+scrape method. Soldering a heatsink really is as stupid as it sounds.

Amazingly, however, the heatsink works. It averaged 2 degrees Celsius of a saving over a days worth of burn-in testing. On a very hot day (for UK standards) the SoC was reporting after several hours of burn in that it was 42 degrees Celsius. This was using the ondemand governor with a 350-500MHz working range. I actually don’t think underclocking from 700 to 500 made a massive difference, but I’ve kept it at that value.

BujMHAACcAE0g93The last item is the power supply block. The AC-DC adaptor I choose fit nicely into the case and had enough room to fit the MP2307 5v->3v3 converter, as well as some required capacitors. The capacitors I eventually settled on are different from part 3, as I went from a phone charger 5v rail to this and it had different characteristics. A switch is included to hard-restart the Pi when required. 200uF is provided on the 5v rail mainly to allow for USB hot plugging, which the Pi is spectacularly terrible at.

power_sch_latest powerpsu_cableFinally, I made a video which goes into further detail about how the components all fit together. This was released a few weeks ago, but compliments this part of the build log well, so it is below.

The last part will be on the software running on the PiOnTheWall. Thanks very much for reading, I hope it was interesting!

As always, you can reach me on twitter @domipheus.

Pi On The Wall – wall mounted home server – Part 3: Reducing Power Consumption

If you missed Part 1 and Part 2, it’s probably best you at least read Part 1 to understand the scope of the project. Part 2 discusses how the hardware is modified to fit into a restrictive enclosure, measuring only 10mm deep.

PiOnTheWallFrom the start, I wanted to stretch the boundaries of the Pi On The Wall, and therefore, Raspberry Pi power consumption. It seemed like a rather fun exercise. This post describes what I did in reducing power consumption fairly drastically, given what can be done in this limited power space.

For those who want a jist of what follows: <tldr> I reduced power requirements of the Raspberry Pi with PiTFT and WiFi drastically. Had to plan for high inrush currents in the designs. Choose switching regulators wisely given voltage and load characteristics. Efficiency varies drastically! Espressos are expensive! </tldr>

Power outline – the situation as stands.

The major consumers of power are as follows

Pi model A: 300mA (source: RPi Wiki )

PiTFT: 100mA (source: Adafruit website )

Edimax Wifi dongle: unknown for sure. This uses the Realtek RTL8188CUS chipset. The only datasheet I could find for it was from a third party which suggested maximum 600mA at 3.3v. It did not provide minimum and typical current ratings, sadly. That’s nearly 400mA at 5v – Whoa.

So we are looking at around 400mA + wifi. Looking around, it seemed to be the WifF would cost about 100mA in active use, not the 400mA from the datasheet, so we’re looking at 700mA for the whole unit.

Since we are space constrained, the power supply situation is a sticky problem for me. The more power required, the more heat given off by the supply, so I want consumption to be low, and efficiency high. My original hope was that I could use the power supply provided with the thermostat casing, as it outputs 5v. Sadly, after testing it with an adjustable current load, it became clear the supply would not be suitable. At just below 200mA draw, the supply would give up, sending the voltage down to millivolts. In fact, even with 150mA, the voltage dropped by 600mV, so using it for the Pi isn’t very feasible.

From looking at various threads about power consumption online, I came to the figure of having this run at 250mA. I’d like this number at idle with the PiTFT backlight on, but peak will probably be higher. Nothing very scientific in how I came up with that number –it’s just a rough guess of what seemed reasonable to achieve.

Lowering Power

The first thing that jumps out at you when researching Raspberry Pi power consumption is the 3v3 linear voltage regulator, marked RG2. That component takes the 5v power input and outputs a stable 3v3 rail which powers most of the devices on the board.

rg2Linear regulators are inefficient, and the power difference between the input and output is dissipated as heat. As I stated earlier, heat is something I want to stay clear from, and when it’s generated by an inefficient component that is not acceptable. We will change this component, swapping in a more efficient, switching regulator. However, we need to be very careful about which switching regulator we choose – efficiency at the given input, output and load of the various switching chips can vary drastically, sometimes falling below that of a linear regulator! Do not use those LM2596/LM2598 devices you see everywhere, efficiency at the characteristics we use is a poor 77%.

lm2598_effI decided, in the first instance, to use an MP2307 based DC-DC unit. They can be had very cheaply at retailers like, and as you can see by the datasheet, efficiency is very good at the values we require (over 90%). That cheap unit has L at 10uH, too!

mp2307_effOne thing to note about these cheap DC-DC converters is that they usually have a wide variable output range, and a terrible single turn pot as the adjustment pin. I spent at least 15 minutes attempting to get as close to 3.3v as possible. In the end, I settled for 3.34v. It would have been quicker soldering a 10-turn pot on here, but sadly I’m too constrained for space to have this luxury.

We will detach the stock 3v3 regulator from the circuit, and power the Pi using the GPIO 5v and 3v3 pins. Note: these pins bypass any protection circuitry on your Raspberry Pi. You’ve been warned!

Software Tips

We can also do some tuning in software. The tvservice, which operates the HDMI out of the raspberry pi, consumes power. Switching this off is simple, and can be done on startup.

Many people on the Raspberry Pi forums have indicated that underclocking the Broadcom SoC achieves nothing in terms of power saving. Despite this, as I’m going for a low-temperature solution, I’m still going to enable the OnDemand cpufreq governor, and set it to operate between 300-500MHz rather than flat out 700MHz. This basically makes the CPU clock down when idle, and ramp back up when under load. It’s a fairly common feature these days, and I must admit was surprised I had to enable it! Instructions for doing this can be found here and here. I installed cpufrequtils with apt-get and used that.

The GPU should handle itself and when idle (which, should be pretty much all the time) be very low power.

The measuring setup

To measure the power consumption, I’m going to measure voltage and current on the 5v line which powers the Pi and also any replacement switching regulators we connect.

Something which may catch folk out here is that first instincts may make you put your multimeter reading current onto the mA range. This has a large effect on the voltage into the Pi, due to Burden Voltage. Dave Jones of EEVblog has a good video on this, as well as Martin Lorton. All of my meters are budget ones (Vichy VC99) and the burden voltage of the mA range meant the Pi would not even boot. On the Amps range it booted fine, with a much smaller Burden Voltage, but still enough resolution to see a reasonable figure. A good compromise for this is to find a decent 0.1 Ohm precision resistor, which can be had fairly cheaply – then you simply measure the voltage across this resistor and read it off the meter like 20.5mV == 205mA. I like this method as it also shows you instantly the burden voltage in your circuit and you can adjust to reverse any ill effects of it. I just live with it in these tests as it is small enough not to cause issue. I confirmed my results using this method as well as simply using the multimeter current measurement.

The setup looks like the following diagram.current_measurement_setup

Power Measurements

The measurements I found were an average over a few test runs. The current measurement was taken using my Vichy VC99 meter that should be accurate enough, but I’ve not used precision measurement techniques or equipment so the figures should really be taken as a decent ballpark figure. Multimeter set to its maximum mode – so it captures and always displays the maximum reading it had during the test run. We need to know the maximum, because the Pi is very fragile with sudden voltage drops and it will fail to boot if the power it demands is unavailable. Current readings are always taken from the main 5v line into everything unless specified otherwise. The main source of the 5v rail to remain close to the final setup is an HTC TCB250 5V 1A charger.

The test is as follows: The PiOnTheWall is booted to X, PiTFT backlight on, USB wifi enabled and configured to connect to an access point 7 meters away and through several walls.

setup_stock_376Test 1: Stock setup

The Pi booted and successfully completed the test with a maximum reading of 376mA.

This seemed promising already. It’s far lower than expected considering I was expecting 200mA alone for the WiFi and PiTFT.

Test 2: TV service off

The Pi booted and successfully completed the test with a maximum reading of 356mA.

That was a decent saving for doing pretty much nothing. All you need to do is add ‘/opt/vc/bin/tvservice –off’ to your init. This figure seems consistent with that observed by Dave Akerman.

Test 3: Replace 3v3 regulator with an MP2307 switching unit.

I simply desoldered the two bottom legs of the regulator off the board, keeping the tab on. This is in case I ever need it again, so it’s an easy change to revert.

The Pi booted and successfully completed the test with a maximum reading of 325mA.

This is disappointing, however, not unexpected. The biggest power draws, the WiFi and PiTFT take up 200mA alone, leaving just 156mA for the Pi (from test 2). If we assume the efficiency of the linear regulator is 70%, the maximum we could really get down to is in the 110mA area. But the MP2307 unit itself isn’t 100% efficient either, so if we consider it to be around 90% efficient (which is conservative, but still a great figure) we get a theoretical 121mA, which is very close when the 200mA is added back on to our 325mA figure.

Test 4: Power the whole setup – Pi, PiTFT, Wifi from a single 3v3 source, tying the 5v rail to 3v3.

This is supposedly doable – I’d read about it in the forums, and also via Dave Akermans blog mentioned above. If we look at the Schematic, we can see the +5v rail goes into the 3v3 regulator, which then becomes the main power rail, but +5v also goes to some pins on the Broadcom SoC, and the USB Power. The WiFi chipset datasheet indicated it ran from 3v3, however, I don’t know how that is delivered, so whether the USB +V pin being 3v3 would translate to an operating chipset is unknown. The Pins on the Broadcom SoC where 5v is present seems to mostly be sense pins for battery powered devices, and so hoped these were not actually used correctly, and that any significant voltage on them such as 3v3 would allow for boot.

pischematic_battery5vNote that for these tests, the mA current readings are on the 5v input before any 3v3 converters.

The first attempt at the test was conclusive.

The Pi failed to boot fully.

The initial linux boot sequence looked promising at 3v3. The backlight of the PiTFT module was, of course, less bright – but still very useable even under my bright bench light. After several attempts at booting the culprit was clear – the WiFi stick initialization. As soon as the WiFi was initialized and it’s activity light came on, the PiTFT screen failed and went white. The Pi Itself continued to boot as I was able to SSH in after a short delay, so the WiFi worked, it’s simply something else was happening.

Inrush Current

When this happened, my first instinct was Inrush Current causing issues. Inrush current is the high draw which occurs when something first switches on, caps charging, etc. It’s well known that the Raspberry Pi does not cope well with this, and there are many mods that exist to make the Pi cope well with hot-plugging of USB devices. There is an article here which discusses inrush current and controlling motors, and indicated further filter capacitors on the input power would solve this issue. Remembering from Part 2, we removed the 220uF input capacitor, so there is certainly a lack of capacitance on the power inputs. In line with the article I link to, I fitted a 0.1uF ceramic, and some 1000uF Electrolytic capacitors I found in my junk bin to the power input. After I did this, it booted to X.

junkcapsThe Pi booted and successfully completed the test with a maximum reading of 254mA.

This seemed a huge jump, then I realized why: the LED backlight of the PiTFT. They were rated at 80mA, but on measuring them individually at 3.3v they were drawing only 22mA @ 3.3v! The brightness drop isn’t really a problem for me, so this is a welcome decrease in consumption. I’m not an expert at this, so it’s probably going to have a damaging effect on the LEDs life, but I’ll take that risk.

A problem remained, however – the PiOnTheWall was unstable. When I opened the web browser and pointed it to BBC news the PiTFT died like before. Damn. Additionally, there was a considerable flickering of the backlight of the screen. I initially thought it was synced to the activity light of the WiFi, but it wasn’t. Then I thought about it being activity on the SD card. I discovered this document on SD card stability which suggested a 22uF tantalum capacitor between pins 3 and 4 of the SD card. The Pi schematic didn’t show capacitance of this level in the SD card interface, so I added it. Thankfully I had a single 22uF tant left, albeit a slightly larger voltage one than I wanted. It still fits in the assembly, so soldered it direct to the SD card socket.

sd_tantBut sadly, the flickering remained!

Then I remembered there was a regulator on the PiTFT itself, as it was powered from the 5v GPIO. The TFT panel requires 3v3. I looked up the datasheet for the regulator and saw it would output around 2.8v for 3.3v in. This is actually still within the minimum spec of the raw TFT panel used in the PiTFT, but to make sure, I removed the regulator and bypassed the in/out pads on the board. The flicker remained. Ugh.

pitft_reg(Top tip: Keep the off cuts of through hole components for making jumpers like above!)

At this point I ordered some high quality ESR caps to use, but it still didn’t stop the backlight flicker. The quality caps did however make the device stable – I was able to load BBC news in the browser on the device fine. The backlight flicker pretty much ruled this solution out though.

Test 5: Power Pi & PiTFT from 3v3, Wifi from 5v

The Pi booted successfully and completed the test with a maximum reading of 269mA.newcapsThe flickering with this setup was drastically reduced – barely noticeable. The amount of capacitance on the input power could be reduced and it was still stable, loading web page in the browser well – the PiTFT screen remained on and active throughout. I think we have a winner!

caps_3v3The final input schematic contains several capacitors and they are rated for 6v. Interestingly I don’t need any on the 5v line that the WiFi is connected to, but this may change with other 5v power sources. I always needed to keep the 5v line, as my motion sensor runs off a very odd 4v4 – I couldn’t easily find any 3v3 PIR units that are small enough for my enclosure. Note, that the additional capacitors will fit in the enclosure fine, in the existing area where the old useless power supply was along with AC-DC converter.


I hit my power target. I’d expected around 250mA typical, in reality, I’m getting lower than that. I get around 270 peak, but during normal use, with the backlight on, and downloading a file over the WiFi it draws around 220mA. Idle, with the backlight off, with WiFi connected (but no traffic) we are at 140mA.

I don’t expect this device to be doing much; but when it is the backlight will no doubt be off. The backlight is controlled by a small motion sensor which automatically turns it off with no motion. With the WiFi active, it consumes around 200mA at 5v. A single watt of power, at a reasonable load. In fact, throughout these tests, the HTC adaptor was really only providing around 4.8V, so it’s even less than this!

Okay, when looking at the numbers this saving may seem a bit silly given the effort that went in to achieve it. But I’m confident this will achieve a cooler overall setup in terms of temperature and efficiency. As it’s inset into the wall, I don’t want a ‘phone charger’ type setup getting warm. I intend to power this device with a mains AC to 5V converter, and then a 5v to 3v3 switching DC-DC converter. As I said earlier, there are a variety of DC-DC converters for this purpose, and I ordered a variety in with different efficiencies to test. I may write another post looking at the efficiency of these units as they really do vary! For now I just used the MP2307 as it was easiest to procure and its datasheet suggested >90% efficiency.

To finish off, lets calculate how much it will cost to power this at a generous typical of 0.8W. If I assume a mains to DC voltage efficiency of 65% (i.e, the mains adapter used to produce the 5V and 3v3, which nobody ever takes into consideration in figures), we’re around 1.23W. For a year, that’s 1.23 * 24 * 365 = 10.78KWh.

Given 2013’s average KWh unit of electricity cost in the UK of 13.52p, it will cost £1.46 to power the Pi On The Wall. For a whole year. Around $2.45 USD.

tldr_costThanks for reading, I hope it was interesting. As always, you can reach me on twitter @domipheus and the flickr album is full (230+ high res images) of build progress shots. If you liked the article, please consider sharing it on social media of your choice!

To be continued… Part 4 will be putting it all together, temperature, and preparing the case! A teaser of what’s to come is below

– Espresso Image courtesy of Suat Eman / –