A little treat when ordering the latest Raspberry Pi was to add a camera module to it, at a price of £7 for the Noir (Not French, just meaning No Infrared filter) it was easy to justify getting even if there was not a set purpose to it.
For the price the Pi Noir camera was generous on the specs, with a 2592 x 1944, 5 Megapixel sensor it seemed capable of capturing high detail images. However, the 5Mp tagline applies to still images only, with video capped at a still respectful 1920 x 1080p.
The difference between the Noir and standard camera module is the lack of an IR filter on the lens, resulting in some washed out colours in daylight but still acceptable in a surveillance capacity, but has the ability to capture images in darkness with help of separate Infrared lighting.
Using the camera module on the Pi is pretty straight forward, connecting is done via a ribbon cable plugged into a dedicated port on the Pi board.
When running a website from a home server, viewing it locally will make it seem that the site is responding lightning fast and there are no issues. But what about the outsiders wanting a look at your content, are they getting the same performance? Chances are they are not, as a visitor’s machine needs to negotiate the internet and its equivalent of back streets and country roads to get to the home server’s location.
Where a home server can differentiate greatly from hosted solutions is the speed and relative location on the net. Visitors who view a website relies on the upstream connection at the server end to receive the content, and when this is via domestic internet connection the upstream can much smaller than the heavily advertised downstream connection. So it’s worth checking the theoretical upload speed to establish what kind of service and content can be served.
In terms of location, hosting companies are as close to the internet backbone as feasibly possible to get the best speeds and lower latency. The backbone of the net is handled by major operation companies that handle the bulk of all internet traffic between countries and continents, these in turn have datacentres where the traffic from countries are trunked to the different internet providers and down to the end user. As data makes its way from the backbone to the end user, it can hop between different servers as it meanders towards the final destination. For each hop the networking equipment has to read where to send it on, and route it on the right path. This all takes time, even though it is measured in milliseconds, an extended number of hops and the volume of data packets needed may produce a noticeable wait for a user to see the desired page.
All home user’s computers need deal with negotiating its way through the service providers’ local infrastructure to get to most sites, but when visiting a site hosted on a home server, data may need to navigate another service providers’ network to reach the site. This is where visitors may experience slower loading times compared to mainstream sites.
So how to tell if your home hosted website will be speedy when out in the wild? There’s a few different ways to check:
With the cooler outdoor temperatures, a bug in my original code for the temperature display has cropped up:
The DS18B20 returns temperatures with up to three decimal places, with the decimal point omitted, therefore a temperature of 10oC would be shown as 10000 by the sensor. To deal with this and for the display to show the temp to one decimal, I used this code:
About fifteen years ago I did Electronics as a course in college, and at the time my younger self didn’t fall in love with the topic, set down to a culmination of issues.
Now with time at hand and a rejuvenation I felt when getting to grips with the Raspberry Pi I thought it time to get involved again. I must stress that this time these are baby steps, and the Raspberry Pi helps me as it does most of the work for you, with any electronics added considered to be more of a peripheral rather than a self-sustained product.
Nothing grand to start with, but as a first project I thought to combine a 20×4 LCD display with two DS18B20 temperature sensors to monitor indoor and outdoor temperatures. This would replace a cheap display I had been using but was sceptical on its accuracy.
Getting the basics right involved making the device blend in to the current setup without the usual mass of wires protrude. From the last round of the seam ably endless cable management war I used a shoebox base as a stand for the webserver and network switch, with the box hiding the various power bricks and extra cable, with most coming from the Xbox 360. Still having the shoebox lid I thought it would be good to use as a modular part to house the Pi and display.
I’m between jobs at the moment, so to give my idle hands something to do I have started looking at using electronics with the Raspberry Pi.
To begin the journey, I decided to power a LCD text display, using this excellent Arduino article as a guide. As I was starting out I purchased everything needed in one order from RS Components, however they didn’t stock any displays with a HDD44780 controller.
Research revealed that a display with a ST7066U controller is compatible with being Pi powered. But be aware that although they have the same number of pins at 16, the layout may be different. I found out the hard way!
As this was the first time I connected the jumpers one at a time, and connecting the pins I thought would light the backlight, instead caused one of the chips on the LCD to get hot to the touch. Luckily I found that out quickly enough to avoid any permanent damage. Also, thanks to ordering from RS each component has a datasheet available, and so was able to connect up the correct pins.
Lesson learned, establish the correct pin out on components before connecting up, other than that a ST7066U controlled LCD display can be controlled by a Pi the same as a HDD44780 controller.
A while ago I worked on a simple CCTV system for work, which involved using software to capture images every second then batch convert them to video every five minutes. It was crude but did the job.
I also dabbled in the past with time lapse videos, however this was a more manual process with images capturing to a folder, then personally loading them into Windows Movie Maker to create the video. With the tedium of creating the videos, the software I used for capturing (YAWCam) would hang after a few weeks constant running, not to mention without upkeep, the hundreds of thousands of image files populating the hard drive.
As a project it was time to combine the learnings from these and create an automated time lapse video creator, a program that would capture images, then create a 5-minute video that contains the days’ footage, and finish by deleting the temporary images to leave just the days video.
For a while I have been looking for simple CCTV solution, where video is captured on a long loop, so when the storage is full the earliest dated footage is deleted to make way for new. And of course, footage is available for immediate review.
Many newer IP cameras, including my Trendnet TV-IP572W comes equipped with a microSD slot for recording on a rotating basis. However, this has two main caveats, firstly the investment in a microSD card to be used solely for this purpose and of a high enough capacity to record enough footage, especially with the introduction of HD capture. Secondly is accessing the footage, as it is effectively held on the IP camera it is the gateway to the data. In my experience this process is slow, with having to download each video file manually and slow transfer speeds.
Imagine wanting to view an event that could have happened over a span of a few hours, and with video captured in segments of 5 minutes at most, the whole process can become tedious very quickly.
Therefore, I came up with another solution, one that uses my server’s hard disks for video storage to save on money while allowing larger video retention than a micro SD card. Also the ability to automatically delete older files to make way for new. This method uses Samba settings of an IP camera to save video to a Windows Server, and on the server itself, employing Disk Quota management to effectively trick the camera into thinking it only has a certain amount of disk space, to allow the cyclic video retention and prevent the footage taking up a whole drive on the server.
With the untimely demise of the Gigabyte Brix, I needed to find another solution for a small machine that would handle all web traffic to my sites. My fingers got burnt by using Gigabyte so this time I decided to track down an Intel marketed machine, they were the first to pioneer the net-top device and so commanded a premium over other manufacturers.
Price always at the forefront, I picked up an Intel NUC5CPYH, at £120 for a barebones system it featured an Intel Celeron 2.16Ghz processor at the helm, with the same single DDR3L slot and support for a 2.5 inch HDD/SDD as the Brix, which I recovered from the deceased system.
Let’s hope three servers is a charm, as its time for a new server. But this time I’m moving away from the HP Microserver. Why? Well the new server is destined to be a dedicated web server for my sites, ever concerned with security and protecting my network I thought it wise to separate the public facing websites physically from my data, adding an extra layer of security.
The choice was to go for a NUC based machine or Nettop, their small footprint allows them to be placed out of the way, plus they are in keeping with my low power requirements and often fan-less design keeps them quiet. As it’s to be a web server only, the restrictions on a device this size such as space for multiple hard drives, graphics performance and upgradability are not an issue.