Thinktank

Seems I’ve coined a new term tonight… “faceborg”.  Okay… seems others have come up with the same idea before me, as pointed out by others.  Not sure what to call the MySpace users… I’m sure someone will come up with a succinct term for them. 😉

Ever since social networking sites such as MySpace and FaceBook have come on the scene, the internet veterans have been under increasing pressure to join up with these sites.  Me?  I don’t see the point.  They don’t appear to offer anything new.  From what I can tell, they are centred around allowing someone to create their own identity.

The misconception out there among the non-technical people, is that you need to be part of one of these sites to have an online identity.  This is simply not true.  You can achieve much the same thing, through the use of traditional media such as email, IRC, and modern media such as blogs.

The one big “advantage” I keep hearing, is that it makes it easy to find others.  Again… you don’t need these social networking sites for that.  There are two ways you can achieve what these sites give you:

Keep your identity consistent.  If you like being known by a certain nickname, then use that nickname.  You can also put your real name up there too if you wish, and anything else that identifies you.

In my case, there are three identifying keywords that will locate me in many search engines: my full real name, my nickname, and my radio callsign.

The major thing that social networking sites offer however, is friendship lists.  Guess what… good ol’e HTML provides that already.  And blogs these days offer XFN.  You simply link to your friends’ blogs/webpages… and voila… your friendship is instantly publicised.  Many search engines also track links between sites — so they will also pick up on these links.

What are the advantages in having your own blog/site?  Well, you can have all the bells and whistles you like.  Want to post videos?  No worries, there are tools for doing exactly that, and embedding them in your blog posts.  The other big advantage, is you’re totally in control — you own the content, and you’re responsible for it.

How about messaging?  Well… you can add that to your blog… there are facilities that can accept such addons.  Or there’s a plethora of tools already out there… such as IRC, XMPP, MSN Messenger (dare I mention it), and of course, plain old email.

To those who are already on these social networking sites.  Great… you’re happy where you are… this is fine.  However, don’t be disappointed if the rest of us, who may likewise be happy with where we are on the web, don’t come rushing to join you.

Atomic MPC forum user, freakonaleash, asked an interesting question regarding sending faxes over IP. This got me thinking.

We’ve got solutions for an internal LAN such as Hylafax for an intranet-based fax-over-IP solution. But nothing exists that could be considered similar to Voice-over-IP. I can’t use the internet for instance, to send a fax overseas — and sometimes just like the telephone, one needs to fax a document.

There’s also the situation of inexperienced people. People like my grandparents, wouldn’t have a clue how to use a computer to send an email, or maintain a PC. Linux distributions have gotten to the point where I’d be quite comfortable setting up a minimalist Gentoo or Ubuntu installation on an old PIII box — to allow basic email and web browsing, but I still need to be around to keep it updated and maintained. Even if I were to go throw Windows XP on the same machine — I’d still have to maintain it.

Email offers some very useful options for such people — e.g. the ability to send letters and other correspondence and have it arrive at the other end within a day or so. (and that’s if the mail servers are having a bad day!) These days, one can buy a hardware device that provides VoIP capability, one can purchase devices that offer limited web-browsing capability without the need of a full-blown desktop computer, why not an internet appliance for sending and receiving email?

Well, I don’t see the need for a whole new protocol. SMTP and POP3/IMAP will do just fine for the actual FoIP capability. The issue is the interface to these protocols. I’m thinking an internet facimile would offer the following:

• Ethernet interface for connection to the internet via a router.
• Internal ADSL and/or PSTN modem for stand-alone internet access without other hardware, and standard fax capability
• LCD Display and keyboard for reading/composing mail and user interface (touchscreen)
• Onboard scanner and printer
• Handset/headset jack for voice communications (either VoIP or standard land-line)

The idea, is that someone who doesn’t have a proper understanding of computers, could send a message over the internet using this device. They would simply hit the “Compose” button, fill in the recipient’s fax number (standard fax) or email address (FoIP), a subject for the message and cover letter, then scan in whatever attached pages they wish to add (these would appear as PDF, JPEG or PNG attachments). Some models may include USB ports and card readers, to allow attaching arbitrary files from USB drives and flash cards. Once they’re happy, they get the option of either sending it right then and there, or storing it to send in a batch run.

For privacy, perhaps something like PGP could be incorporated, thus allowing messages to be encrypted. There’s scope for this device to act as an internet router, networked printer/scanner, and VoIP ATA box too, which could be add-on features.

In essence though, the box could just sit in the corner… and say, overnight, connect to the internet, download any new messages, send any unsent messages out.

I might look into something like this, as it seems in the open source world, we have pretty much all the necessary pieces — just a matter of piling the right software on a standard PC and we’ll have a proof-of-concept prototype.

Update: Seems I should have read this page first… we were thinking on the same wavelength afterall. I’ll leave the post here, since I think my (and Brian Lozier’s) argument is still valid with respect to the overheads in various templating engines…

It has always fascinated me, with large-scale PHP projects, how people seem to flock to overly complicated templating engines. I’ve worked on a couple of such projects, and it got me thinking about why we do it.

My first real contact with a site that uses templating engines was the Asperger Services Australia site. Originally, it was a static-HTML site done in FrontPage, but after looking at a number of CMS systems, we finally chose TikiWiki to run the site. TikiWiki utilises the Smarty templating engine — a behemoth weighing in at just over 1MB.

Smarty wields a lot of power, able to do numerous transformations with strings — but it’s a big package, and takes quite a while to master. It also seems to occupy a lot of memory, and requires write access to directories to store “compiled” templates.

This year, we built a web application called Teamworker. Our implementation was written in PHP using MySQL, and basically it was a ground-up re-write of an internal QUT webapp of the same name (many QUT students probably know it well). For this project, we wound up using the bTemplate engine, a far simpler engine than Smarty, it uses simple string replacement of XML-like tags. It has quite a few limitations however — for instance, one cannot have two loops of the same name — it’ll substitute one, but not the other. It isn’t difficult to pick up, but some aspects of its syntax are … awkward.

I dare say if I look hard enough, there’s probably some poor sadistic sod trying to do it with XML and XSLTs. Yes, they have their place, but they’re massive overkill. If your data is already in XML to begin with (i.e. Gentoo’s site) then sure, go for it, but otherwise it seems to be (to me anyway) a really messy way to do things.

PHP, believe it or not, actually is a templating engine. It has all the features one needs. All the code I need goes inside tags like this: <?php ?>, and outside of these, I can have just about anything I want. I can also use conditional statements inside PHP tags, to control what gets displayed outside… e.g. suppose I define the variable $logged_in, a boolean, and the string $user… a webapp might have:

... random HTML code...
<?php if ($logged_in) { ?>
Hello <?= htmlentities($user) ?>.
<a href="profile.php">Profile</a>
<a href="logout.php">Logout</a>
<?php } else { ?>
Hello guest. Please <a href="login.php">log in</a>
<?php } ?>
... more code ...


Voila… done. To whistle up this template, a script only needs to initialise $logged_in and $user, then include("template_file.php");, and it’ll appear as they expect.

However, this requires that your templates be structured a particular way. You’re more-or-less generating things on-the-fly, rather than constructing everything in a buffer, then sending it later. This can lead to display code getting mixed up with computation code, which isn’t terrific. So in these situations, PHP needs a little helping hand. Enter, the 8-line templating engine.

PHP since version 4 supports output buffering. These allow the programmer to control when and how, data is released to the browser. In addition, it is also possible to fetch the rendered output from the buffer as a string then clear the slate. This gives us great power to create a very simple but flexible templating engine, in 8 lines of PHP code:

function doTemplate($templateFile, $data) {
extract($data);
ob_start();
include($templateFile);
$_out = ob_get_contents();
ob_end_clean();
return $_out;
}

It’s crude, but it works. A site can then be easily put together using this method. No files need to get written at runtime, there’s no special syntax required. The idea is the template files are just very trivial PHP scripts — one uses as few functions as possible to achieve the desired page output. So built-in functions such as if, foreach and similar constructs, and maybe the odd include(). A site might use an overall template like the following:

<html>
<head>
<title><?= htmlentities($page_title) ?></title>
</head>
<body>
<h1><?= htmlentities($page_title) ?></h1>
<hr />
Navigation: <?php foreach($navlinks as $link) { ?>
<a href="<= $link["target"]; ?>"><?= htmlentities($link["title"]) ?></a>
<?php } ?>
... other header stuff ...
<?= $content ?>
... rest of page

They may, for instance, have some form widgets. Suppose they wanted all these boolean values to use radio buttons with some sort of tick/cross image beside them? They can define the HTML code for them in one place…

<input type="radio" value="no" name="<?= $name ?>" id="<?= $name ?>_no" /><label for="<?= $name ?>_no"><img src="/images/cross.png" alt="No" /></label>
<input type="radio" value="yes" name="<?= $name ?>" id="<?= $name ?>_yes" /><label for="<?= $name ?>_yes"><img src="/images/tick.png" alt="Yes" /></label>

Then use that widget repeatedly in a document by simply defining some place holders (using <?= $placeholder_name >) and generating the page…

$my_page["show_email"] = doTemplate("templates/yesno.tpl.php",array( "name" => "show_email" ));
$my_page["subscribe_annouce"] = doTemplate("templates/yesno.tpl.php",array( "name" => "subscribe_announce" ));
//
// ... other definitions ...
//
$page_content = doTemplate("templates/register.tpl.php", $my_page);
echo doTemplate("templates/overall.tpl.php", array(
"page_title" => "Register for our forum!",
"content" => $page_content,
"navlinks" => $navigation // <-- This may be a global array that's manipulated in various places as needed.
));

Already, that works in much the way bTemplate does, but doesn’t have nearly as many limitations. There are some manipulations that it can’t do as easily as Smarty does them, such as inline manipulations of text, but then again, it’s a heck of a lot more lightweight. Sure, RAM is cheap these days… but still, why waste the resources if you don’t have to? What I’ve done above, could be viewed as wasteful — even the very act of using PHP in the eyes of some, but sometimes we don’t get a say in that matter, we work with the tools we have at hand. (Heck, I’ve been known to use C and Busybox ash to construct webapps — which works surprisingly well too.) But even in this age of cheap computing power, I think striving for minimalism is still worthwhile.

This is an idea I’ve had for some time now, but only recently started doing anything about it. Anyway…

The problem:

As many of you may know, I study at university. Often the lectures and tutorials are on late at night. Thus, I frequently find myself making my way from or two university in the dark. Many of the areas I walk through are dimly lit, with sparse street lighting and quite a few road crossings. Often the footpath is an uneven surface, and therefore one needs a torch of some kind to see any hazards underfoot. The same torch does improve one’s visibility — but only for those in the torch’s beam.

Headlamps are really nifty torches… freeing both hands. The problem one has though, is that the small compact ones aren’t much good for distance vision, and the big bulky ones chew batteries like they’re going out of fashion. Then there’s the fussing over whether they’re pointed up or down, adjusting head straps…etc. They’re great when camping, and even for walking home of an evening, but the balance between light intensity and battery drain is a big problem, especially when only a limited supply of batteries is on hand. Seldom does one need a high-power beam all the time, but they’re useful to have.

Bike tail-lights are useful for improving one’s visibility to vehicles coming from behind, but they aren’t much help if they’re approaching side-on. And none of these lights will turn themselves off if there’s sufficient ambient light.

My idea:

These problems got me thinking about how I could solve the problem. Does it really need to be solved? Well, it isn’t a big one, so I guess not… but for the sake of it, I’ll try and solve it anyway. LED technology has vastly improved in the last few years, to the point now where they’re talking of using them in street lighting and car headlights (PDF; IEEE Explore subscription required). The big advantage is the high efficiency and low heat of LEDs. A few high-power LEDs should last as long, if not, longer than the incandescent bulb that my present headlamp uses.

My idea revolves around mounting 3 sets of LEDs on a hard hat of some description. Why a hard hat? Well, they’re a rigid structure that I can easily drill holes into and mount components on. Using a full-brim hard hat (rare in Brisbane), it’ll also keep the sun off during the day, thus serving a fourth purpose.

This headlamp would use 3 different LED banks:

• High-Beam LED: Single 1W high-power White LED — mounted above the rim facing forward in the distance.
• Low-Beam LEDs: Three high-intensity 5mm White LEDs — mounted under the rim facing downward.
• Rim LEDs: Twelve high-intensity 5mm Red or Yellow LEDs — mounted around the rim of the hard hat facing outwards.

The high-beam LED would provide the distance lamp… acting like any high-power torch. It’d be focussed slightly below the horizon. The low-beam LEDs would be directed downwards so that they light up an area just in front of the wearer, allowing them to see what they’re doing. The Rim LEDs would be divided into two groups of 6 that flash alternately to warn approaching vehicles at any angle.

Mounted on the top of the hard hat, would be a light-dependant resistor (cadmium-sulfide cell) that detects ambient light, and just underneath, a PCB containing the controller logic for the automatic switching. Then down the side under the rim, would be the switches and threshold pot for controlling the whole circuit.

Each of the functions can be in one of three states, controlled by the user: on, automatic, or off

Controller Circuit:

The key to this headlamp design is the controller circuit. I ended up trying three different circuits before settling on this design. By far, the most simple circuit was based on a IRF630B N-channel power MOSFET.

In this configuration, the CdS cell and potentiometer were wired in a resistor-divider configuration, such that the voltage rose as the light level dropped. This drove the MOSFET’s gate pin, causing it to sink current whenever the light levels were low.

I soon discovered this circuit was no good for high-current devices such as my existing incandescent headlamp. Because the bulb was such a heavy load, it put a heavy strain on the batteries, causing the voltage potential to drop significantly. This in turn, shifted the threshold point on the voltage divider, causing the MOSFET to turn off again, causing the batteries to rise up again… ad nauseum, until the batteries were flat or the user got frustrated and switched to manual modes.
Addition of a relay helped… the ciruit was slightly more stable, increasingly so as large amounts of capacitance were added across the relay, slowing response times. It still was possible to get the whole system into a battery-guzzling oscillating state.

In the end, I turned to the humble 74HC14 Hex Inverting Schmitt Trigger. By turning my voltage divider up-side-down (so voltage rose with light level) I found I could gain the effect I needed. Due to the hysteresis provided by the Schmitt Triggers, the light doesn’t turn off until it gets significantly lighter than the threshold point, and doesn’t turn off until it gets significantly darker. This provided the stability I needed.

The final design (click image on right, or see SVG or Kicad .sch versions) works as follows. The CdS cell and pot provide the means for detecting the light level. Adjusting the pot will make the circuit more or less sensitive to light. This drives the first Schmitt-Triggered inverter.

The output of this inverter is passed through a BC547C NPN transistor which in turn, drives a small reed relay. This relay is the main switching workhorse, providing a switched 6v rail which hooks to small toggle switches for the low and high-beam LEDs.

For the Rim LEDs, the same schmitt trigger IC could be used to make the oscillators. The Phillips 74HC14 datasheet describes how. I didn’t care much about frequency, so long as it flickered just fast enough to be noticable. To get the alternate flashing action — I set one inverter up as an oscillator, and used it to drive a second inverter. The outputs of both drive individual BC547C transistors, which act as current sinks from the Rim LEDs.

The following two photos show my testing of the circuit on a breadboard.

Bill of Materials

The following is the list of parts for this headlamp, and where I purchased them. Some components can be exchanged to suit one’s needs. At the moment, I haven’t yet bought the 1W LED and power supply which would form the high-beam LED.

Assembly

Construction of this headlamp will require drilling holes into the shell of the hard hat. So once complete, I wouldn’t go using it on a construction site. To mount the rim LEDs, I found the best way to do it was to use a 3mm drill to make the hole, then use a screwdriver to widen the hole so it was just big enough to accomodate the LED. The LED was then forced into the hole, plugging it — friction holds it in place.

The switches were small enough to mount using double-sided tape just inside the hard hat. A small piece of PCB was used to mount the potentiometer, allowing it to be fastened to the underside of the rim using a nylon nut & bolt.

The low-beam LEDs were mounted onto a small PCB with the current-limiting resistor, and fixed to the front of the hard hat using masking tape (yeah, dodgy I know) — some cardboard prevents the light from shining into the wearer’s eyes.

The main PCB and battery pack were fitted inside the shell of the hard hat — two 25mm long bolts hold the battery pack in place, while one 12mm bolt holds the PCB in place. The actual components are placed on the PCB according to the PCB board design shown to the right (click for larger image).

Final Product (almost)

Well, I haven’t bought the high-beam LED yet, that’s for later. The end result however, works great. I first used it at Riverfire 2007 and found it very convenient. At the time I had lost the LDR, so had to buy one yesterday, which I fitted last night. The unit now automatically switches off if the light levels are sufficient. As far as appearance, it doesn’t look that different to an ordinary hard hat, until you switch the LEDs on. These show the hard hat, before modifications, after, and what it looks like in action.

Safety & commercial considerations

It’s worth noting that although this hard hat would’ve been manufactured to meet AS/NZS 1801. I’ve destroyed this rating by drilling holes and inserting electronics. This project might still survive the double impact tests needed — but it’s never been tested, and isn’t intended to. I just wanted a hat that shaded me by day, and lit my path by night.

If this idea prooves popular, I could see it being adapted into a removable brim that sits over a hard hat/cap. The actual electronics cost over $60 … so embedding it into a hard hat on a commercial basis is not economic, since hard hats have a limited lifespan and need to be replaced every few years. So the headlamp would need to be detachable.

Update: 22nd November

Well, having used it now for two months, the idea has worked great. One set of 4×AA batteries lasts about 2 months, with moderate usage — and even then everything still worked, just the light was getting a little dim. I’ve since added the high-beam 1W LED (the supply for it wound up costing about $40, but anyway) and extended the brim so that it provides additional shade during the day.

The photo on the left shows what it looks like now. There has been one minor technical problem, in that the relay occasionally sticks — I’m investigating whether I replace this with something solid-state such as a P-channel power MOSFET which should do the job nicely. The only other one is the odd social problem — of people asking if you’re expecting a disaster, but once they’re used to seeing me wear it, this usually isn’t an issue. 😉

Update 2009-06-05: I did get around to making a P-MOSFET version. See the schematic in PDF or gschem. The circuit can theoretically use any P-MOSFET rated at 1A current for Q1… this one uses the IRF9540N available from Jaycar (which is overkill). I use BC547Cs for Q2 and Q3. CONN1 connects to the adjustment pot (use a 2M? one), CONN2 connects to the LDR. R1 and R2 may be omitted, but are present to allow the circuit to operate if either the pot or LDR connections are broken. CONN3 and CONN4 connect to your low and high beam LED banks. CONN5 connect to the two warning LED banks. R4 and C1 control the rate of oscillation… any value can be used, see the NXP 74HC14 datasheet for details on how to calculate these.