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.
From 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
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.
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.
Linear 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%.
I decided, in the first instance, to use an MP2307 based DC-DC unit. They can be had very cheaply at retailers like banggood.com, 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!
One 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!
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 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.
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.
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.
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.
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.
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.
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.The 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!
The 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.
Thanks 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…
— Colin Riley (@domipheus) August 8, 2014
- Espresso Image courtesy of Suat Eman / FreeDigitalPhotos.net -
This is Part 2 of a series of blogs regarding the development of a wall-mounted server based on the Raspberry Pi, featuring WiFi and a colour touchscreen. Part 1 can be found here.
The enclosure I’m using, a re-purposed room thermostat casing, places some very tight constraints on the dimensions of the Raspberry Pi and PiTFT board.The plastic used in the case is quite sturdy, and is at least 2mm in thickness. Therefore the real inner depth of the case is about 12mm. As for the width of the Pi, we need to shave at least 4mm from the side. The Pi itself is 86mm wide, same with the PiTFT board, so we will need to find a way of making it closer to 82mm.
The board interconnect that comes with the PiTFT is a tall terminal connector. It is immediately ruled out for use, as it increases the depth of the assembly to well over an inch. Without using that, and bending the pins to grip the I/O on the PiTFT, the depth from SD card housing to top of the TFT is just over 20mm. Still far too much.
The main space-wasters on the Pi are easy to identify. The composite out, audio out, USB, HDMI, and the camera and display interfaces all can be removed. The tallest of these, the Composite out, measures over 11mm alone. The only one we need to use is USB, and we can add terminals to enable an off-board connector for that. All the others need to go.
The composite, audio and USB jacks were relatively easy to remove. Solder sucker & solder wick with some wiggling did the trick. The HDMI socket was another matter entirely. There were some components near the socket I didn’t want to destroy, and one of the soldered through-hole supports wouldn’t budge. Butchery was resorted to, using cutters to chip away at the metal surround and later the plastic. The connector itself is surface mount, and came off fairly easily after that. Once destroyed, the through hole-support gave in and came out with more wiggling. I apologise to all who were involved in designing the Pi for the following image.
Some PCB pads came off at the HDMI socket, but I was not concerned, as this was destructive change anyway. The camera and display interface connectors I simply cut away with pliers, again, a few pads came off.
C6 is the large silver capacitor near the micro usb socket. This is the last item in the way on the top of the board, and as you can see from the Raspberry Pi schematic, is just a smoothing capactor for the power. It can be safely removed and if needed, put off-board in seperate power circuitry. I’ve identified D17, a protection diode on the opposite side of the PCB, as we will come back to this later. The board ends up incredibly bare and on the top side it’s only a few millimeters tall.
After this I put a 90 degree set of terminal pins in the USB location so we can put the socket off-board. If we knew everything was going to work at this point the easiest thing to do would be to solder the PiTFT board directly to the GPIO pins of the PI. However, I wanted to remove the Pi from the TFT board to adjust things in future, so had to come up with a solution without using standard terminal connectors, which are too tall. I decided to try taking a DIP socket and using that, as they are only 3mm tall. The first two pins are not required, so sawing a 24-pin socket in half, inverting it for a flush fit and filing down worked exceptionally well.
The PiTFT is round the opposite way as the Pi, as you can see, it’s simply the adafruit logo mask and there are no important traces to avoid. I just dived right in, marked a line with a stanley knife and got out the hacksaw. After some effort and sanding with a rotary tool it came out pretty well.
The PCBs now fit well into the case in terms of width and length, but depth is still a problem. We need to hit 12mm at minimum. The only thing to now do is relocate the SD card socket from the bottom of the board to the space on top where the Display Interface used to be, on top of the logo to the left of the SoC.
Desoldering the SD card holder was a bit more nasty than I’d imagined. I only have an iron, solder sucker and some wick. Ideally I’d have the correct tools, but for this I resorted to the ‘pull enamelled wire through the joint as it is molten’ trick, which worked in this case. If you use this method watch out as the pins themselves can come out from the plastic housing very easily.
After it was removed, I used 0.2mm enamelled copper wire soldered to the existing pads, through the hole in the board to the front side and soldered direct to the holder. It wasn’t very well done, I tried to keep the lengths of wire of a similar length but it shouldn’t matter too much. The main thing is making sure you have a good clean solder joint and you remove the enamel at the right places. Scraping with side cutters and tinning with too much solder (so much that you waste some) usually does the trick.
An interesting thing to note is that the card detect and write protect switches do not seem to have an effect at runtime. The schematic shows the write protect pins are unconnected, so that’s expected. The card detect pins are connected to the SoC. My plan was just to short the pads on the underside to save soldering 2 wires that don’t really matter. There are two very small SMD components where the SD card holder now sits (C1 & C5), I made tiny holes in the underside plastic of the holder so it can be mounted flush on the PCB without those components being damaged.
Additionally, I removed D17. This protection diode will be mounted off-board when the power system is looked at along with (potentially) C6 that we removed earlier. Note D17 and C6 technically are not needed to run the board, they are for protection, so I can still test via the microUSB socket as in the picture below.
At the moment i’m measuring just over 10mm to the end of the terminal pins on the underside of the RPi board. Of course there are some surface mount components also on the back, but they don’t change depth much. The D17 diode was the biggest one, and we moved it off-board. I’m going to grind the back of the GPIO pins off a bit just to save some more space, but I think there is no need to go further than 10mm. There is still space between the Pi and PiTFT boards for the USB terminal connector to carry a socket off-board, and also something I’m looking at is heat dissipation from the SoC and whether I need to increase the surface area for some better passive cooling.
The final dimensions of the unit assembled is 80mm x 56mm x 10.5mm.
As for the Pi On The Wall project, the next steps are to sort the casing out with the tactile switches matching the switches on the PiTFT, and also affixing the USB socket in the case so a mini USB WiFi stick is flush with the exterior. After that, I’ll be running some power consumption tests and heat dissipation tests. I want this to be extremely low power, and will experiment with replacing the regulators, turning off services, possibly even running the whole board off 3.3v instead of 5v, which is said to be possible.
If you have got to this point in the post, I hope you found it interesting. If you have any questions, please either comment here or message me directly on twitter @domipheus.
Update: Thanks for all the feedback! Here is a taste of things to come in the case fitting:
I’ve been working away at an idea I had that seemed too good to sit on, so jumped at it. It’s easier to explain the purpose in an image:
I’ve been meaning to set up my Raspberry Pi to monitor the Heatmiser WiFi thermostat I use, as well as being a small home server. I have a standard wall mount plate free in the hall of our house, the sort of thing the above would mount into and be wired direct to mains for 24/7 operation. I thought it would be cool to take a cheap thermostat, gut it, and replace it’s internals with Pi goodness – throwing in a colour touchscreen for good measure.
The Pi On The Wall was born.
I discovered a cheap thermostat on Amazon which had mains power to 5v built in. The power unit may need to be replaced which is something I’ll write about later, but as you can see there is not much space in here for a Raspberry Pi and associated TFT screen, WiFi stick, SD card, etc.
There will be quite a bit of customization going on. The Pi board itself doesnt fit in here for length, let alone it plus the standard PiTFT mount for depth.
I’m quite progressed with this project as I type this, and will post a few updates shortly.
Spoilers: In total, the current depth of the Pi + TFT is currently 14mm. This is after some serious hacking at the board itself. It’s not pretty, but it’s working. There are some fun hacks in here to share!
Still working on my bench power supply, and wanted to move from my 16×2 retro LCD to something a bit more funky, and found these which use the Samsung S6D02A1 chip.
At the time of writing, you can get these from a UK warehouse for £3.30 shipped for a single unit. That’s awesome. However, the comments were quite bad and many people had issues with them – no matter how it was wired an Arduino wouldn’t drive it.
After lots of trial and error and searching all over, I discovered the secret hack: put 1K resistors between all I/O pins, and Vcc is +5v. Basically, I/O is 3.3v – the SD card on the back has resistors by the looks of it, but not the TFT. It’s cheap.
I needed to monitor my boilers activity as I thought something may not be quite right about its activity – gas usage is fairly high and our thermostat is fairly low – only 18 degrees C.
Our thermostat is programmed to become active twice a day, in the morning, and then in the late afternoon to evening. During this time the thermostat switches a wire to live (230v) to signal heat requested to the boiler, which is an older and not very efficient model.
I decided to build a quick and dirty datalogger based on an Arduino Nano and an SD card interface. There are various examples on the official Arduino portal about creating an SD card datalogger in this configuration. I realised however for my data to mean anything I’d need to have reliable timekeeping, which means I need to integrate a Real Time Clock (RTC) into the design.
I bought an SD card interface off ebay for £2 shipped which operates over SPI. I also bought an RTC for £4 shipped. It uses the popular DS1307 chip and is marketed as “Tiny RTC”. It operates over I2C and has a rechargable LIR2032 battery with charge circuit. There have been issues with this board, mainly due to people fitting the board with CR2032 batteries which is not a good thing to do. Ensure you use a LIR2032!
Using already existing SD and RTC libraries, the code was easy to get running quickly. I simply analogRead 4 inputs and log the raw values. An interesting point is that, every second, I open a file on the SD card, append to it, and close it. This is not efficient and probably not good for the SD card either, but for me I wanted to be able to power off and grab the data off the SD card quickly and reliably so opening/closing and not buffering is the best bet in my view. My schematics and firmware are available on github.
As for sensors, I had 3 10K thermistors and a 10K LDR. The LDR is placed over the burner on LED of the boiler, one thermistor for ambient, and the other two reading the flow and return pipes to the radiators via some good quality thermal paste for heat conductivity.
The little board to the far right is simply a sensor breakout board with 4 10K resistors and +5V, GND, sense and then the sensor connectors. 3 of the sensor connectors are disconnected in the image. The sense values of the thermistors were quite disappointing resolution wise when I reviewed the logs, but they did the job.
The datalogger ran for several days unattended and I was happy to find a log file for each day saved to the SD card for me to analyze. I created a small c# application that gave me instant stats on the days boiler running, and also output a smaller selection of datapoints as to plot an easy to view chart of activity.
An average day resulted in the following:
Burn: 06:41:38->07:28:41, Duration: 00:47:03
Burn: 07:32:54->07:38:52, Duration: 00:05:58
Burn: 07:43:15->07:48:27, Duration: 00:05:12
Burn: 07:52:47->07:57:23, Duration: 00:04:36
Burn: 08:01:27->08:05:17, Duration: 00:03:50
Burn: 08:09:15->08:12:31, Duration: 00:03:16
Burn: 08:16:03->08:18:57, Duration: 00:02:54
Burn: 08:22:30->08:25:15, Duration: 00:02:45
Burn: 08:28:53->08:31:31, Duration: 00:02:38
Burn: 08:35:11->08:37:43, Duration: 00:02:32
Burn: 08:41:23->08:43:52, Duration: 00:02:29
Burn: 15:31:23->15:53:45, Duration: 00:22:22
Burn: 15:58:05->16:03:44, Duration: 00:05:39
Burn: 16:08:15->16:13:22, Duration: 00:05:07
Burn: 16:17:55->16:22:32, Duration: 00:04:37
Burn: 16:27:01->16:31:23, Duration: 00:04:22
Burn: 16:35:41->16:39:25, Duration: 00:03:44
Burn: 16:43:34->16:46:46, Duration: 00:03:12
Burn: 16:50:51->16:53:47, Duration: 00:02:56
Burn: 18:11:29->18:15:25, Duration: 00:03:56
Burn: 18:20:41->18:22:55, Duration: 00:02:14
Burn: 18:31:10->18:33:12, Duration: 00:02:02
Burn: 18:48:38->18:50:36, Duration: 00:01:58
Burn: 19:51:10->20:09:02, Duration: 00:17:52
Burn: 20:13:25->20:18:05, Duration: 00:04:40
Burn: 20:22:37->20:23:30, Duration: 00:00:53
Time boiler burning: 02:48:47
Num of boiler fireups:26
Shortest time on: 00:00:53 at 20:22:37
So instantly I see a problem, which is oscillation of the boiler firing up for a short period and then turning off, only to turn on a short time later. It turns out our ‘fancy’ hall thermostat, despite looking the business is fairly poor in terms of features. It’s switching differential is so small it’s acting like it simply adheres to the following:
if TEMP > SET_TEMP then boiler_off() else boiler_on()
There does seem to be around 0.5C of differential but it’s not enough. If I could adjust this on the thermostat it would make things much better.
So I’m looking at a new thermostat and think Ive got a winner for that, which I may post up about next month.
While I was at it, I wanted to test the idea that keeping your boiler switched on 24/7 actually is more economic. So I tried it. This is on a day fairly similar in terms of outside temperature as the last graph.
Burn: 01:56:53->02:15:20, Duration: 00:18:27
Burn: 02:19:44->02:20:57, Duration: 00:01:13
Burn: 04:28:06->04:46:18, Duration: 00:18:12
Burn: 06:41:03->07:19:44, Duration: 00:38:41
Burn: 09:20:03->09:38:32, Duration: 00:18:29
Burn: 12:19:15->12:39:08, Duration: 00:19:53
Burn: 14:32:28->14:50:43, Duration: 00:18:15
Burn: 16:28:57->16:48:10, Duration: 00:19:13
Burn: 16:52:34->16:55:47, Duration: 00:03:13
Burn: 18:10:55->18:14:17, Duration: 00:03:22
Burn: 18:23:24->18:25:27, Duration: 00:02:03
Burn: 18:28:16->18:46:09, Duration: 00:17:53
Burn: 18:50:26->18:55:25, Duration: 00:04:59
Burn: 18:59:56->19:04:08, Duration: 00:04:12
Burn: 21:58:52->22:18:50, Duration: 00:19:58
Burn: 22:23:19->22:23:26, Duration: 00:00:07
Time boiler burning: 03:28:10
Num of boiler fireups:16
I think it’s quite clear cut that for my boiler it is not more economic, the boiler running for an additional 40 minutes during the whole day. Interesting though there are much less oscillation events, and therefore less boiler fireups.
Hope this post is of use to someone. The full schematic and firmware for the datalogger is available over at github. Let me know if you use any of it!
Update: Something is going funky between 10 and 11am each day, which you can see on the graphs as a spike in flow temp and a drastic drop in return. I don’t have a clue what it is. The boiler isn’t on, could be something to do with my unvented hot water cylinder.
Before I wrote my first program, I built pysical things. Lego helecopters with improvised rotors driven by the motor of a broken RC car and a 9v battery. I collected circuit boards, opened anything I could (with no concern for my own safety) and ‘repaired’ things that had obvious issues with it, like dodgy contacts/wiring/soldering. I think I was about 9 or 10 years old at this point. I also had various electronics kits, the ones that had little spring contacts for wiring things up, and came with big thick 200-page manuals full of schematics.
Then we got a computer at home, and it all, kinda, stopped.
I’ve always wanted to get back into electronics. I know and remember the ‘trivial basics’ but never got into it seriously, computers and software took my attention away.
But, then I found Dave Jones and the EEVblog, and it’s all come back to me. I’m building an electronics lab at home, and already have my first project in progress: a bench power supply, which i’m told is one of several ‘musts’ for building when starting your own lab – which is good!
I’ll be posting updates on the lab and also the power supply as the come!
So… all previous posts have really been about me making some games in my spare time. There have been no real updates in a very long time, and thats because basically: the game failed massively.
I’d have hoped there would be enough sales to pay for the web hosting for leaderboards, replays, and the SSL certificate. Over a year I couldn’t even pay for the SSL certificate! So yeah, it really didn’t work. So instead, i’m simply going to use this to post things that interest me, current projects, etc. It’s quite a change, as I’m not going to start with software, which is what I’ve been doing for a very long time.
Also, I’m not paying much attention to the quality of posts, more making sure the content is interesting. Hopefully, that is.
There has been much discussion over the past view days about the game modes planned for Gears of Glory: Apex Ace, especially given the ‘never seen before‘ time-shifted multiplayer of a racing game featured during this weeks Apple iPhone 5 keynote.
I’m not going to go into detail of what I think about the feature, or what past games had interactive ghosts/replays and how the affected gameplay. This post is about what Gears of Glory: Apex Ace offers.
The open beta releasing super-soon comes with several race modes:
Season Tier time-trial
In this mode, players race all of the season circuits. As they race, setting best laps and finding better lines to rise in the leaderboards, opponents appear alongside the players own best lap replay.
This is the first part of the Dynamic Opponent System at work – the opponent you face is usually the person directly above you in the leaderboards. As you progress, new opponents appear – and this happens on the fly.
So regardless of where you are, the singleplayer element revolves around racing other player laps, which have been raced at any time, and means you are always competing.
This mode is very simple – when you view the Season Tier leaderboards, you can browse the ranking, and race any lap on the boards. Any. If your friend is above you in the standings and you just can’t find the time to beat them via the season time-trial, race directly against them and check out where they find time on the lap. If your friend is below you, view his lap and offer advice of where he can improve.
This mode is very difficult, and successful players receive many trophies (the XP/score unit in the game). It is exactly as the Player race, apart from the fact the replay you are racing against is not a ghost but an interactive, collidable, entity.
To beat their lap, you need to find and maintain space to overtake. You can jostle, however, the game does not let you influence the lap time of the other player. If you try to ram, or jostle to an unacceptable level, you will crash and be left with a bad lap. Because of the trophy reward associated with this, only players around or above your current ranking can be raced. You cannot play the system by challenging the player last on the boards.
The three modes above is what’s shipping in the open beta. The next game mode is something I am quite excited about, and extends the dynamic opponents system.
In this mode, it is set out similar to racing games players already understand – circuits raced in a calendar style, progressing to different classes of car and larger, more challenging circuits. However, Gears of Glory: Apex Ace does not have different classes of car – only different classes of racers.
As you race, your position in the rankings is again measured. A grid of opponents is created, dynamically, from other players on the leaderboards around your position. Depending on the difficulty you play at, these players may be far ahead of you in the standings, or directly around you. You race a series of laps, but not in a time trial fashion – this is your standard, lap-bound, first to the finish race. You must maintain competitive, consistent lap times to progress. As you progress, the field around you changes to reflect your standings, making you compete against a different class of racer.
There is no AI at all in this mode. There is no AI in the game at all. If you see another racecar in Gears of Glory: Apex Ace, it is another player. That player does not need to be online for you to race their laps. Their best laps are all stored and retrieved from the OnlineServices.
I’ll keep everyone up to date on the progress for this mode, I obviously think it’s great
Now, I need help from you. If you can find another racer that has a feature similar to this championship mode description, please tell me, I want to know! I’ve not seen any, but there are so many games out there.
So there we have it. The race modes of Gears of Glory: Apex Ace. If you have any questions, feel free to comment, either here or on facebook. You can contact me directly instead if you’d like, at @domipheus.