Creation Factory

From morning until dawn - and entire day described in seconds

2012-01-27T16:08:00.000-08:00

Time lapse video sequences can render exciting results, for the visual impact these provide. While simply being a sequence of frames more separated in time than in a conventional video, once played back at the rate the human vision considers smooth (30 frames per second) these provide a view of the world that a human cannot easily perceive directly, given the comparatively fast rate at which he summarizes and retains information. For instance a cloud in its pass has very complex yet slow changes in shape and trajectory. These are very hard for average humans to perceive, memorize and mentally reconstruct as an animated sequence of events. In general, slow changing processes are inherently hard for humans to characterize in its dynamic nature.

As such it is not surprising that a video containing nothing more than a reproduction of the real world can be appreciated by humans as being somewhat surreal, when simply the only difference is the rate at which information is sampled and later reproduced.

The first video contains about 20 hours of footage shrunk to 32 seconds. It reveals one angle of the Almada city at the south of Lisbon, where part of the 25 de Abril bridge and the Cristo Rei can be seen. It is a typical winter day in Portugal, where the fog floods the morning and a passing of dense clouds fulfills the entire afternoon. This typical day is however solitary in a atypical winter month padded with bright sunny days and mild temperatures.

The second video taken during the 27th January 2012, reveals a clear night transition to a bright winter day in the city of Almada, just south of Lisbon the capital city of Portugal. At the bottom right, the horizon is cut by a huge rectangular crane belonging to a long time decomissioned shipyard.Its name was Lisnave and would once be an important maritime reference for large ships and oil rigs which would stop by for major repairing and overhauling.

LENA - Now featuring dose measurement

2011-12-21T10:12:00.000-08:00

The DOSE feature discussed in the previous post is now done. Taking into account the GM tube characteristics, a realistic measure of radiation dose in uSv/hour is now being calculated, based on the single event rate. From the information obtained on the internet regarding the SI-39G tube, the value of 0.00049 uSv per pulse was taken into account for the calculation of the dose.

Additionally, another mode usually found in most Geiger counters and dosimeters is the CPM (Counts Per Minute) mode. It provides a relative measure (that is of course GM tube dependent) of the radiation exposure, based on the ammount of particles detected by the tube. In this case these can be either Beta particles with more penetrating energy, and Gamma photons. Alpha particles cannot be detected by this particular tube (the SI-39G).

All the calculations are performed on the User Interface module (the cream colored box). No firmware changes had to be performed on the probe module (where an Atmel ATTiny85 is used). Only on the PIC18F2455 responsible for controlling the UI module.

The video below shows the new set of features in operation:

To enrich the feature set of the device, battery voltage measurement was also added. As the PIC also has an ADC converter, monitoring the voltage was just a mather of adding a resistive voltage divider, and a 5.1 V Zener diode for protecting the ADC input in case of excess voltage (given the designed voltage divider, in excess of 18 Volts).

LENA - The Geiger Counter that was finally made portable!

2011-12-16T10:26:00.000-08:00

With the Geiger Muller tube module having been posted in a previous post, namely here, another important development was missing. While fully functional at that time as a sensor device which could readily be interfaced with via I2C, or having the pulses be directly picked up via a dedicated TTL signal, by itself the device could not be carried on the field and be expected to operate without additional hardware.

This is where the user interface module I am presenting here comes into play. Having been baptized after my daughter's name (shortname for Helena), it is also acronym for a more elaborate name: "Lightweight Energy and Nuclides Analyser". Since the beginning I have looked forward to adopt a modular approach and allow the probe element and its intrinsic electronics to be decoupled from the user interface, data presentation and power supply/management part. This would allow different types of sensing elements to be used. For example instead of a Geiger tube, a semiconductor based device. In this case both the detector element and the associated electronics are inherently different.

As such the idea was to build a battery powered compact device, featuring a display, control buttons and audio amplification for the pulses. This device would couple with the Geiger tube
module through a connector for carrying the I2C bus signals, single event pulse and power.

For the solution I looked forward to select an appropriate microcontroller. I considered a few basic requirements:

* Low power consumption;
* I2C master capable (at least 100 KHz);
* Plenty of I/O pins for the display and remaining elements (LED's, buttons);
* Analog pins to monitor battery voltage;
* Moderate RAM, EEPROM and Flash resources, to enable complex applications and measurement data to be retained;
* Reasonable cost;
* Compatibility with available tools.

Having some familiarity with Microchip PIC devices, I have analysed the specs of several models, with special emphasis to the PIC18 family, and found the PIC18F2455 to be an adequate choice. This device
has a broad range of features and in spite of not being part of the XLP family (eXtreme Low Power), it still has a reasonably low power consumption (which of course still depends on several factors including user options). Besides I2C support through its MSSP peripheral, it also supports serial communications, and with greater relevance, has integrated USB capability. This provides great flexibility for interfacing with the PC.

In respect to the display, instead of spending money on a new one, I found that I had a couple of HDLO-2416 originally manufactured by HP. I had these for years stored in a box, and finally found an interesting application for these. Each one has a 4-character dot-matrix, based on LED technology. Given its age (roughly 20 years) power consumption is not its best characteristic (modern LED's are more efficient). But as I didn't want to spend more money and was more interested in having a working prototype, I moved forward with this display solution. Additionally, the adoption of an exotic luminescent display sounded interesting, giving it somewhat of a vintage look (where the edge of looking for retro designs would be to use Nixie tubes :) ).

For the enclosure I went for the dirtiest, cheapest, easy to find solution. A simple plastic box used in household electrical installations:

Aesthetical aspects aside, it would do the job, allowing all the components to be fitted inside with just about enough room to also acomodate the battery.

In the case of the Geiger tube, a regular can was used. Given its metal composition, it is well suited to provide electromagnetic shielding, preventing incorrect readings.

To finalize the description of the device, here is a video showing it during operation. It illustrates the implemented functions to date. These are the following:

* Single event count - CNT;
* Delay between events (in multiples of 16 ms - to be improved) - LPSE;
* Watchdog timer ticks (multiples of 16 ms) - TICK
* Firmware version display - VER

The DOSE option is also visible in the video. It is just a placeholder for the future functionality, which will provide a measure of exposure to radiation in microSieverts/hour.

Future developments may include the implementation of a semiconductor probe, based on a photodiode or maybe a solar array shielded behind aluminium foil. While it is tipically
a challenge to use semiconductors to consistently detect single events, several key benefits exist, including the ability to quantitatively measure the energy of each particle and the
mechanical robustness, which is easier to be made higher than the Geiger tube.

In terms of overall battery consumption, figures aren't particularly exciting. On average we have about 110 mA of current drain from a 9 Volt batery. This gives about 4 hours of autonomy in the best case. Screen blanking is being performed after every 4 seconds of inactivity from the user or lack of events. Still with display blanked, consumption will not drop below 100 mA.One of the culprits is for sure the Geiger tube electronics.The HV power supply is completely unoptimized, given the fact that it was tweaked to reach the 400 Volts. Originally it would provide 300 Volts, having in this case a much lower consumption of about 8 mA (about 50 mA with 400 Volt output).

So some hardware improvements to provide better battery life are still expected, along with firmware changes that can also help increase battery life (e.g. change internal clock speed, better manage I2C communications and write operations to the display, dim the panel leds through PWM). So by carefully implementing these changes it is likely that an interesting drop in power consumption would be achieved.Comparing the current figures with those of a modern Geiger counter such as the Gamma-Scout (http://www.gammascout.com/), I would see my design as the pre-history of the low power consumption. Most of the models of this manufacturer have a battery life of 10 years. Typical power consumption is around 10 microamperes (!!) So trying to compete with these guys is out of question :)

Me and my employer in the Elektor magazine!

2011-11-27T15:01:00.000-08:00

In late september (the 29th to be more exact) PDMFC's online store Microsensus was officially launched. This event gathered a lot of people from the portuguese microelectronics community. And is needless to say it was a success. It was an opportunity to expose our work to many relevant people, from universities to SME's and large companies. The event also captured the media attention, in particular the portuguese version of the Elektor magazine. I had the chance to talk about the products and what motivated PDMFC to enroll in the hardware business.

As it was published, it felt good to see my face and the rest of the team printed in the pages of a magazine that for me and many people in the electronics world is legendary for its articles and its role at stimulating young minds towards creativity through the use of technological artifacts.

Looking back to the pre-blog era

2011-11-26T17:14:00.000-08:00

I guess back in 2002 the blog concept wasn't yet broadly disseminated. Recently I thought of taking a peek to a long unattended website I have created almost a decade ago. This web site, which you can readily access here:

http://clientes.netvisao.pt/teixelui/

has a few interesting projects which pretty much remind me of how I am consistent as a person, even after 10 years. This helps me understand that a person tends to have a reasonably stable mindset, regardless of how life worsens in complexity, challenges, problems, pain, isolated events of joy, etc.

The sense of loss is many times compensated by other gifts. Wouldn't there be a catch, as so many times is the case, these would be two vectors that cancel each other. Life, however isn't black and white. A good thing sometimes conceals a price to pay. So many times greater than simply denying it.

In life, taking the default option tends to have a costly outcome. Failing the be more actively involved in the decision process is most of the time a regretful scenario.

Anyway, after 10 years you can't help putting your life in perspective and realizing
how precious time is when compared to some many pointless things that come and go, and one way or another cause you to consume some of that precious time.

I2C Geiger Counter

2011-10-26T15:02:00.000-07:00

With nuke plants operating under questionable technical safety, natural events threatening humans and their dangerous energy production artifacts, and other humans disseminating fear through nuclear sovereignty upon the rest of the world, we came a long way from the happy ignorance of distant decades.

As such, in an attempt to further increase the sense of paranoia we readily accept to live in, I took some time to design and build another sensor, in this case a low level radiation detector. Having modularity in mind, I though of creating the device in such way to serve its purpose in more than one context. In order to keep it modular, I have put all the components necessary for it to operate in a stand-alone fashion, and communicate through a standard bus with other modules. Given its adequation to the solution, I have selected the I2C bus. The necessary elements for autonomous operation would have to be:

Geiger Tube - bought a russian made SI-39G. Known to detect at least hard gamma radiation;

HV power supply - the tube requires about 400 V DC, and very small current supply. In this case I have used a modified camera flash circuit. Originally would output 300 V. I had to tweak it to generate an extra 100 V without exceding the component ratings;

Pulse stretching and amplification electronics - the pulse output by GM tube is too short for the human ear to identify (less than a microsecond). At the same time, the pulse signal must be conditioned to be properly handled by digital electronics;

Pulse counting and I2C interface - a simple 8-bit microcontroller such as the ATMEL ATTiny85 is enough to handle the job. Additionally it also outputs a short tone (about 4 ms long), every time a disintegration is detected (e.g. gamma photon). This tone can then be amplified and fed to a speaker through external electronics;

Linear regulator - Unlike the rest of the circuitry in the module, which is powered at 5 Volts, the HV power supply only requires 3 Volts. As such a linear regulator had to be added (in this case a LM317 adjusted to produce 3 Volts);

The big thing about this modular design is that I can either use the sensor in my other project, the AMIRO robot (link), or attach it to a still-to-be-implemented UI module, made up by a display, speaker, and microcontroller to receive the data, convert event counts to microsieverts (radiation dose unit), and possibly log the data and make it available via USB. Pretty good! The only issue, having time to materialize the ideas. In this case I can at least say almost half the implementation effort is done, 100 % of the hardware design is done, 30 % of the firmware (which accounts for the full ATTiny85 routines), and a few drafts of the mechanical layout are done in my sketchbook. One step at a time, as after all this is a hobby to be kept as a pleasing activity, out of the race track. And of course the longer the ignorance about the radiation, the better the bliss :)

About the testing of this module, it has only been done in respect to the background radiation (that is the radiation that is all around us, coming from several sources such as the trace amounts of radon gas that is in the air, Potassium 40 from our bodies, from the soil, and of course from the outer space). An average of 6 or 7 counts per minute is obtained, which converting to microsieverts (using the tube datasheet) accounts for about 0.100 microsieverts per hour, which is consistent with the expected background radiation for our location and altitude.

Tests with other sources have not yet been carried out, given its scarcity (fortunately :) ). Yet to be tested are common things known to emmit slightly more radiation than background, such as Brazil nuts, granite, bananas, thorium gas mantles (a bit hard to find these days), americium smoke detectors (practically discontinued in the EU), etc. Some of these materials do not release quite many gamma photons, making radioactivity harder to detect. A pancake detector would in this case be far more efficient at detecting a broader range of charged particles.

Baby monitor

2011-10-09T05:18:00.000-07:00

While preparing to be a father for the first time, I have found most baby products to be more expensive than would otherwise be desirable, given its ephemeral usefulness. Considering the full blown economical crisis that we face today, spending copious ammounts of money in things that soon become useless, seems a little too light headed and perhaps irresponsible.

Either essential or non essential products tend to be more expensive than it is reasonable to pay for. As such it is my belief that the consumer must be clever and refrain from indulging the will to buy every fancy baby product that sellers expose.

One thing I found is that quality products are incredibly overpriced if bought locally on a pharmacy or baby shop (e.g. a mere breast pump, sterilizer, pacifier, etc) when compared to large online sellers (but here it not specific to baby products).

Another case are the products which are easily replaceable by general purpose alternatives. One such example is a non-contact thermometer. While being quite convenient and fast to use, baby non-contact thermometers are technically the same (but more limited in the temperature range) than a general purpose non-contact thermometer (these are sometimes even more precise). While first considering buying a baby thermometer, I found that besides being equally effective, a general purpose equivalent would cost me about half the money, and I could use it for a myriad of other applications than for checking the baby temperature. While having the look of a work tool, it didn't really bother me, as it does the job equally well.

But the case I want to focus on is about baby monitors. While technically simple devices, these tend to cost way more money than an intelligent human being is tipically willing to pay. Even CTCSS walkie talkies are usually more powerful than these devices, and sometimes provide the same function, for less money.

In a first approach, I checked the feasibility of building a baby monitor from scratch, but soon found it to be too laborious, even though I would probably not spend much money in parts. I also considered buying the CTCSS walkie talkies, but while being less expensive I considered that I would not give future use to these, so this option was also discarded.

I have taken a look at the stuff I had in lying around at home, and found that I had at least two of the three parts of the puzzle already. One thing is an all band communications scanner I bought a few years ago for listening to all sorts of analog transmissions:

Another thing was a pair of wireless headphones from Sony, which featured quite a reasonable quality, but which I rarely used:

The headphones transmitter had a pretty good range, and I found that I could tune the scanner to either of its two transmitting frequencies: 863.520 MHz or 864.520 MHz. I could listen in perfection selecting wideband FM. Only the stereo signal didn't seem to be encoded the same way as regular broadcasting stations. So I had to listen in mono, but no problem for monitoring the baby anyway.

The only part of the puzzle left was how to connect microphones, as the transmitter only had line level inputs (0.7 Vrms), and the electret microphones signal would be well below this level to be properly heard.

So I had to build a pre-amplifier. I first tested on a breadboard some single transistor approaches, but soon realized that the quality would be below what I would be interested in.

So I looked at the popular LM358 opamp chip, which seemed to potentially provide more than enough gain for this purpose. And besides this, each package contains two amplifiers, easily allowing a stereo pre-amplifier to be built, without having to add an extra opamp for the other channel.

The following schematic describes the device:

And after testing on breadboard the finished circuit, mounted on veroboard, and placed in a nice appropriate enclosure.

First I used random electret microphones I had in my "junk repository", but inevitably found that even the most similar parts, have quite distinguishable characteristics. So for a stereo setup this should be avoided. As such I went to the cheapest place I could eventually get microphones: a chinese store. After a bit of searching in the electronics section, I found PC microphones that seemed to be quite suitable:

Costing 2 euros each, I thought it would be worth it. Took two of these and went home to test against my circuit. One would provide excelent results and the other had lousy sensitivity. This really made me even more aware of what to expect from quality control in cheap chinese products. Curiously the package had the indication "We have passed ISO9001 certification". Whatever...
Anyway, I went back to the store and replaced the bad microphone with another one I selected randomly from the stack (crossing fingers to be more lucky this time). And in fact this time I was lucky (I dont know what the odds are, but perhaps 50/50 ?). Both microphones had apparently equal performance (as far as my hearing can tell), and the final result was very good (true immersive stereo sound when heard from the sony headphones).

All in all, ignoring that the first two parts of the puzzle I already had (which by the way were not all that cheap - 50 euros the sony headphones, and about 100 euros the all band scanner), mounting the pre-amplifier was cheap (around 15 euros and one day of labour). In my case what mathers is that I saved money, as otherwise would be throwing 50 to 70 euros to something that would later become useless. This however can also be used connected to a computer or other device with audio inputs, and provide excelent sound sensitivity (similar to human hearing) for recording a conversation, music performance, etc.

Now that we are talking about electronics engineering projects, I take the opportunity to refer to a company developing great devices, aimed not only to hobbyists but to integrators. Microsensus solutions, given its use of wireless technology fits greatly into applications such as people monitoring. One of the products (the Tiny family) even has the baby monitoring as one of the design motivations:

AMIRO - more enhancements.

2011-08-17T17:02:00.000-07:00

After a few months of posting abstinence here are some fresh new things to show this summer. The android application has been dramatically improved with new features and better visual layout. Additionally a portable video screen have been build, in this case sporting a 4.3" tft panel, a 1.2 GHz analog video receiver (originally used in a fixed manner), a LiPo battery, and a custom made battery voltage warning circuit (yes, LiPo batteries are particularly susceptible to damage under deep discharge situations).

What this video shows is the control console for steering the amiro autonomous rover.
It is made up by a color video receiver, and the control and telemetry module, which in this case is implemented on top of an android phone. The phone communicates via wifi with the drone, sending driving commands, and receiving status information and telemetry from sensors and other parameters. We can manually steer the car, control the throttle and pan the camera about its horizontal and vertical axis. We can also control the lighting, by varying the slider, which will give us either visible or infrared light.

The white projected square on the left side of the image is from one the infrared sensors used to determine obstacle distance. In the current version of the software, these are only being used for showing the user the distance of the obstacle to which is pointing. In future versions of amiro it is expected that these, together with the sonar sensor will be used for preventing collisions on erroneous user input.

The range of the car is limited to the wifi maximum distance, which in open space is roughly 100 meters.

The video transmitter, while operating in the 1.2 GHz band has a similar range.

The android application displays in realtime the telemetry data. It includes:

* Speed;
* Distance covered;
* Left and right infrared sensor measured distance;
* Sonar measured distance;
* Air temperature;
* Main and control battery data such as:
* voltage and
* capacity

The interface also enables the distance counter to be reset on demand, and the steering to be trimmed.

Controlling Amiro (the name I have baptized the car) from an Android phone (HTC Desire)

2011-03-13T13:19:00.000-07:00

While the Java PC application is useful for testing and controlling the robotic car while sitting in a chair, for on the field fun a more practical solution had to adopted. So using a popular platform that Android is, I decided to port the (Java Swing) application I already had, to run on any Android phone with a accelerometers and a Wifi connection. As the car behaves like an access point, all it is necessary is to associate the phone to it, and run the application.

Just about as fun as it is to drive it, coding the client in Android was quick an fun experience.
The interface had to contain just the essential elements. While the target hardware has abundant resolution (480x800), like in any mobile platform, screen real estate is always a concern. As such I had to economize on the components to be displayed. The result was a relatively simple UI:

It shows the data from the different active sensors (speed, 3 obstacle range values, temperature and battery status). One slider controls the throttle (the vertical one), and another slider controls the intensity of the LED headlights (also enabling the switching between white and UV LEDs).

The video below shows the car in action, this time controlled by the Android phone:

Merry Christmas

2010-12-25T15:23:00.000-08:00

Christmas is a great time for parents and kids to experience engineering with the inspiring cheerfulness of eating turkey, cakes, and looking at the fireplace while it's snowing outside. Offering the right gifts is a good way of bringing up the excitement that building artifacts can cause. While, of course, not all infants have the same thirst for scientific knowledge, for those which we find to have potential, the choice of technical gifts is not to be disregarded. While in my personal view, reminding myself as a toddler brings the memories of how vibrant and exciting it was to receive a chemistry kit, a microscope, an electronic device ready to be disassembled, etc, in the mind of a modern kid this might not be quite so satisfying. A Gormiti castle, a bunch of Ben Ten toys or any other sounding brands will certainly trigger more "processes" in a toddler's cognition.

A discussion about how today's television and toy industry affects children and youths is of little impact, but it is a fact that it is now in the hands of the parents and educators, to control the degree of exposure of their offspring to these elements, as the sole regulating factor seems to be profit generation alone.

Like with many other aspects of our world, let's hope some sense will grow out in the desert and guide those who deserve.

And of course Happy Holidays and fruitful engineering. Don't worry letting your kid become an engineer :)

Quadrature Encoder

2010-12-05T14:07:00.000-08:00

One of the essential things an autonomous rover must have (which mine didn't had) is one or more quadrature encoders. In fact even some non-autonomous vehicles have these devices. Most regular cars these days feature this type of sensor as part of the ABS system (see http://en.wikipedia.org/wiki/Anti-lock_braking_system). Very reliable and high-resolution sensors can be found in these (featuring 90 steps or more).

For this autonomous rover I found that 16 steps would be the bare minimum, and easy to implement with common components.

As I didn't want to modify the RC car itself (drill holes, cut parts, etc), I looked for a solution that would minimize the impact on the car. As such I found that a good option would be to use the inner ring of the wheel as a surface for sticking an encoder band. This band has 16 steps, and looks like this:

Once glued to the wheel we had this:

On the other hand putting the sensors (two IR emmiter/sensor combos are necessary) would not be an easy task as well. As I have chosen the CNY70 (these are approximately 8 mm cubes), room for
the entire thing would be limited. Anyway I managed to fit the two sensors in one of the suspension ball link support holes. The result was this:

Another view with the wheel fitted in:

With a bit of effort, I managed to place the two sensors on a small PCB, and carefully aligned these with the encoder band and ensuring that a 90 degree displacement would be obtained (this is fundamental for proper detection).

There was obviously no room for more components or even for a conector to the main board. As such
I soldered thin wires from the sensor board to the analog interface board, which is the following:

The quadrature decoding board was mounted on the main fixture like most other electronics.

The role of this board is to receive the analog signal from the sensors, run it through an LM358 setup as a level comparator, clean the resulting square waves from impurities by passing it through a schmitt-trigger gate, and finally provide the signals to the decoding logic, taken care by an Atmel Attiny45. The contained firmware results from the work of Adriaan Swanepoel, which can be found here: http://www.auv.co.za/blog/attiny45quadraturedecoder. This microcontroller counts the pulses from the encoder, and allows the count to be obtained through I2C, via its slave interface. This is a very handy solution, as it offloads any of the other computational modules of the robot from the quadrature decoding. The main logic only has to poll the count on a regular basis, and perform whatever calculations are necessary with the data (speed, odometry, etc).

A hand made schematic diagram describes the solution:

Like with any non-trivial design before the veroboard version of the hardware, I put together the entire circuit on breadboard, and tested against the remaining hardware (autonomous vehicle):

A few aspects are worth mentioning: First I had no trouble building the FW project with AVR Studio 4. To program the Attiny45 I used the simplest possible programmer:

To build it you just have to link the following pins:

Parallel Port	Attiny45
1 (/STROBE)	7 (SCK)
2 (D0)	5 (MOSI)
3 (D1)	8 (VCC)
11 (BUSY)	6 (MISO)
16 (/INIT)	1 (RESET)
18 (GND)	4 (GND)

It is recommended to put a 1 KOhm resistor between the MOSI (Pin 5) and PPort pin 2, and another 1 KOhm resistor between SCK (Pin 7) and PPort pin 1. This will offer a certain degree of protection to both devices.

To actually flash the device I used "avrdude" under linux. It's a nifty little piece of software that allows programming with just about any type of hardware.

At first I could not communicate at all with the Attiny45. Using the I2C master routines from the PIC, I tried to issue the appropriate commands to the expected default address (0x3E). After googlig a bit and reading some forums, I found that certain I2C slaves expect the address shifted left by 1 bit. I tried this, and by analysing the SCL and SDA lines on the oscilloscope, I found that the device would react. Write commands such as reset (0x01) would apparently be successful. But the read command would fail most of the times. Without having deep knowledge about AVR architecture I started to consider all possible options. By looking at the fuse settings I found that the Attiny45 was running at 1 MHz:


avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF

Among other things lfuse maintains the clock divider bit (CKDIV8).This divides the 8 MHz clock by 8, slowing the device down to the speed I verified.

Well, given the fact that my I2C master was clocking out at 100 KHz, it was clear that a 1 MHz clock was not going to be enough to support a bit banging I2C slave device. Without hesitation I
put the device in the programmer and changed the fuse setting:


$ avrdude -v -p t45 -c dapa -P /dev/parport0 -U lfuse:w:0xE2:m

Put the Attiny45 back in the circuit and..Eureka! It was working flawlessly. Signals on the oscilloscope also looked more solid, without gaps in the clocks and responses.

After a few tests it was time to assemble everything in veroboard and add to the car. Final tests revealed the encoder to be pretty accurate, with Fonera software calibrated for measuring speed and distance in metric units. A very happy ending.

Now remotely controlled via IP

2010-10-24T16:12:00.000-07:00

After some hobby time spenditure, the result meets the expectations. While it is a functional and simple (and a good fallback solution), controlling the car via a regular RC radio is not the most interesting scenario. Having a device that is mostly digital, being controlled by an analog receiver isn't quite the nicest thing one would want to showcase. With that in mind, and taking into account that all the necessary hardware was already there and working, I have decided to take a little bit of time implementing the necessary components to be able to control the car from a remote peer in a wifi network. As such all I had was to:

Select the transport: TCP or UDP;
Design the protocol for carrying the control messages;
Design and implement the server application (running in OpenWrt linux);
Design and implement the client application (running in Windows or desktop linux);

(1) For the first point I have chosen UDP. In this type of use case, a connection oriented transport would not be optimal, compromising the realtime requirements of the communication. Occasional packet loss, in this scenario, can be well handled by the receiver, which includes timeouts to handle loss of communication, by taking the appropriate measures. As the data flow doesn't have to be acknowledged, the power consumption of the car can be further reduced.

(2) In the second point, a very simple protocol for carrying the control messages have been defined. Each packet has the following:

CSEQ - (2 bytes) a field containing a sequential number for each message. It helps keep track of message order and rate of packet loss;
CODE - (2 bytes) describes the type of the message (can be CONTROL, STATUS, or KEEP_ALIVE);
LENGTH - (2 bytes) indicates the size in bytes of the payload (the field that follows);
DATA - (0 - 18 bytes) the data itself;
CHKSUM - (2 bytes) a simple 16 bit check sum of the entire packet.

The DATA packet of a CONTROL message has the following structure:

CHANNELS - (16 bytes) each channel is a 2 byte value which corresponds to the pulse width to be applied to the corresponding servo;
BUTTONS - (2 bytes) each button in the joystick is represented by one bit, which contains its status.

(3) For the third point, implementing a C application to handle the incoming control UDP packets wasn't such a big challenge. All I had was to use the OpenWrt kamikaze toolchain, and compile the code with appropriate gcc cross compiler. The application would use the previously implemented library for handling the serial communication with the PIC based servo control and acquisition board (Droids MuIn). Configure it to run as a service and wouldn't have to bother launching it while booting up the Fonera.

(4) For the client I have given preference to implementing it in Java. The only challenge however was that Java doesn't natively support Joystick devices, so I had to find a library to take care of that. After a bit of searching I have found JXInput (http://www.hardcode.de/jxinput/), which seemed to be a decent library, with reasonable documentation and examples. All I had to do was using this library in my application (in the form of a Jar), and have the necessary windows dll in my application folder. This dll establishes the bridge (through JNI) to the Windows Joystick (or any other HID) API. Here is a screenshot of my application:

It connects to the car, passing steering commands from the joystick device. The user can select the joystick to use, and enter the IP address and port of the car.

A few photos of the car, during a maintenance task. In the aileron is the battery pack for the control electronics (the Fonera and the MuIn):

A bottom view of the sensor and control block (the heart of the robot), with all the necessary components:

Now controlling the "beast" is as simple as playing a videogame :)

Don't need the big 41 MHz antenna anymore, great! It's now easier to get under the table and say...watch under the skirt :)

Booster circuitry up and running

2010-10-07T12:44:00.000-07:00

Running digital equipment has the drawback of requiring tight voltage ranges in order to operate. In the case of my robot, I had the need for powering the Fonera 2100 from a pack of 4 AA batteries. While the batteries can deliver 4.8 Volts once fully charged (which is barely sufficient to power this wireless appliance directly), once the voltage drops further, the Fonera ceasses to operate. In this situation the batteries still have remaining energy that is not possible to use.

This type of problem calls for a voltage booster or charge pump device. These prodigious devices can take a given input voltage, and produce an output voltage that
can be lower, equal, or greater than the input voltage. They can even behave like voltage regulators, ensuring a steady output voltage.

I have chosen a simple to install voltage booster, already assembled in a tiny PCB. I went for the Pololu Adjustable Boost Regulator:

This device is based on a Semtech SC4501 (2 Amp, 2 MHz Boost Switching Regulator with Soft-Start).It can accept an input voltage between 1.5 and 16 Volts, and produce an adjustable output (via a potentiometer) between 2.5 and 9.5 Volts. With the average output currents of the Fonera of 0.5 A, this booster operates at around 80% efficiency.

While testing the device, I had the "surprise" of verifying that the input current once the fonera had completely booted, had raised to 2.1 Amps.
Without reading the input voltage, I was confused because the Fonera would only draw a maximum of 1 Amp. Then I checked the voltage at the battery pack, and these were measuring 3.3 Volts (without load these would normally be steady at around 4.8 Volts). The Booster output voltage was a steady 6.5 Volts like initially adjusted without load. With this I realized the booster was actually doing its job right, making it's best to maintain the output voltage constant. The batteries on the other hand were nearly depleted. This had the consequence of demanding massive input currents to compensate for the voltage drop. The 2 Amp limit of the booster means that in these circumstances the booster can barely handle the load. Fortunately this is the borderline case, to which the booster is only exposed for a small ammount of time (after this the batteries can be declared dead and must be replaced). On the other hand this booster has a thermal shutdown and current limiting feature, protecting the hardware from damage.

As a curiosity on charge pumps and ultracapacitors, here is a link to an interesting 9 Volt battery based on a 2.3 Volt ultracapacitor:

http://hackaday.com/2005/12/06/supercap-9v-battery/

Drastic Improvement: new Mobile Platform

2010-10-05T12:11:00.000-07:00

After a lot of stress tests with the original platform, it was time for something better. The original platform was no more than a toy RC car (entirely made of plastic) with some hobby RC parts on top of if, such as refurbished steering system (with a real servo) and a home made ESC (Electronic Speed Controller) for the original toy car motor. During a demonstration with my 4 year old nephew, showing him how fast the roving robot would go in an open area, suddenly something happened: it started running full speed, totally out of control, both forward and backward (in my mind I immediately tought one of the ESC FET's had fried). I rushed to grab it, and suddenly smoke started coming out of the motor. Worried about the LiPo battery, with the motor still running and smoking, I centered all effort in disconnecting the battery. My nephew started to cry with the stange situation. After making sure no fire would occur, I had a confused infant to comfort.

Obviously, the motor was completely fried. The home brew ESC had at least the two FET's burned (I hadn't spent more time doing a thorough diagnosis so far). Other than this there was fortunately no more damage. In spite of the full throttle collisions against the wall, everything else survived the event.

Given the accumulated ammount of effort dedicated to this robotic vehicle, I decided to instead of trying to repair the current version of the car, to move to a more decent roving platform.

After some searching in the robot and hobby RC markets, I found a reasonable solution, with all the conditions to ensure durability and stability: an electric hobby RC car - the HPI Maverick Strada XB. With 4 Wheel Drive, a 200 A Brushed Motor ESC, 540 size brushed motor, and 7.2 Volt 1800 mAh NiMh battery, this solution meets the conditions to perform better in demanding terrains:

Besides being cheaper than equivalent platforms for robots, it comes complete, whith everything necessary to run: steering servo, ESC, motor, and a radio transmitter and receiver (the later being redundant, given the fact that I already had another transmitter/receiver kit).

The integration with the existing robot core module (the board with all the electronics, including sensors, computer, camera, and digital/analog I/O controller) was relatively smooth, with the exception of the modifications needed for adapting to the lower main battery voltage: 7.2 Volts instead of 11.1 Volts.

Given the ammount of necessary changes, I took the opportunity to improve the computer (Fonera) power supply. Instead of powering it directly from a pack of 4 AA batteries, I added support for another 4 batteries to optionally connect in parallel, and booster circuitry to extract more energy from the batteries (the Fonera would not like when the voltage would drop below 5 volts), ensuring the correct voltage supply for as long as possible.

With all the mechanical changes required to adapt to the new frame, the final result is the following:

In spite of the aesthetics not being the high point of this project, I have to say that in my opinion it looks a lot better than before.

The AA battery packs are located in the replacement aileron. In spite of not being the optimal location considering the center of mass, it was the only adequate location, considering the fact that the sensors and camera could not have the corresponding field of view compromised.

Power pack!

2010-07-01T14:18:00.000-07:00

While the rear wheel traction motor provides plenty of power for normal operation, the curiosity of obtaining some extra power through a different propulsion method is appealing. Since I had some parts from a unfinished airplane project, the materialization of another exclusive idea became real: to build a special trailer for the car, with a single purpose - to push the car even faster, with the help of a propeller instead of traction wheels. Featuring a 9x6E propeller, a 150 Watt brushless motor, an 18 A ESC, and a 1300 mAh LiPo battery, this trailer provides the closest one can ever get from raw rocket power, with controller propulsion.

The following video demonstrates the car in action, with wheel traction and with propeller exclusively.

The module features a small pcb just for preventing the +5 volts power provided by the propeller ESC from being fed to the car's circuitry. As these devices use linear regulators, there is the risk of damage due to reverse current to one of the regulators.

Sensors are never too many

2010-06-02T15:01:00.000-07:00

While it is important to design a autonomous rover capable of performing even under the worst conditions and with the least available information from the surrounding environment, if we can provide good information, it will certainly lead to better results as long as we have a good software implementation behind it.

As such a sweeping sonar as single sensor is not enough for proper navigation, even at the smallest speeds and using the best navigation algorithms. In order to compensate the sensorial weakness, in this step I have added two infrared distance sensors. I have chosen the Sharp 2Y0A21 (http://document.sharpsma.com/files/gp2y0a21yk_e.pdf), which can measure distances from 10 to 80 cm. While not being as powerful as the sonar (15 to 600 cm), it is a useful reference for dodging obstacles in realtime.

I have added one servo to each of the two IR sensors, allowing the angle to be adjusted, and to point the sensors to the back while maneuvering in reverse.

System override

2010-05-04T13:43:00.000-07:00

Unlike some other domains, with robot software bugs can have expensive outcomes. In order to avoid unpleasant mishaps, I have decided to implement a hardware solution for preventing software originated problems that could cause a calm, boring robot to become a runaway beast hitting hard against walls, people, animals and anything that is in its way. To achieve this I have built a PWM control source multiplexer:

This board enables the user to select through an RC radio channel, the source of control. Up to 4 servo channels can be multiplexed, from 2 different control origins. In my setup, I can select if the input of 4 channels should come from the 41 MHz RC receiver, or from the MuIn (PIC18F2520) board.

In case the robot starts doing something that is not correct, the user can immediately toggle the source of control, and prevent a crash from occurring.

The solution simply consists of a salvaged servo control circuit, and two TTL 74 series IC's.

One is a 74LS157, which is a 4 bit 2 input multiplexer. The second one is a 74LS14, which is an hex inverter, with schmitt trigger inputs. It is intended to help clean the signals from the control pin, in order to avoid intermittent operation. As the TTL multiplexer cannot directly understand the PWM signal from the RC transmitter's channel dedicated to switching the source of control, it is necessary to have a circuit capable of getting the PWM signal and output 0 or 5 volts, depending on the length of the input signal. As I had (mechanically) broken servos, I took advantage of the control circuit of one, for doing this translation. In order to ensure a steady output (the output signal is a waveform between DC and a pulse width modulated signal that powers the motor) I have added a 22uF capacitor, sufficient to smooth out the signal. The schmitt trigger gates help to provide a clean signal to the multiplexer.

Almost autonomous

2010-05-02T15:57:00.000-07:00

With all the hardware prepared (except the quadrature encoder on the wheels, which is still to be implemented and installed), all conditions were met in order to be able to write some code and make the car finally move on its own.

I have first added the sonar module (the previously mentioned SRF02). This implied making a small aluminium support to fixate the sonar to the servo, while still being able to slightly adjust the tilt:

After installing it, made a quick check and read the ranging data directly through the MuIn original Windows application:

Every thing was fine. It was time to add more code to the MuIn PIC, implenting useful functions for the robot. A singe command returning both range data and the servo position would be useful, so I implemented it. It essentially consists of the following structure:

'@'

'F'

'S'

I2C addr

servo nr

'#'

Each element is 8 bytes long. The PIC responds with the following answer format:

'@'

'F'

'S'

I2C addr

servo nr

Range HB

Range LB

Servo HB

Servo LB

'#'

Checksum

This allows a measurement to be taken, while the servo is sweeping.

A small video of the car in action:

More stuff on the pipe

2010-04-25T15:55:00.000-07:00

The good work goes on, and the objective of achieving a fully autonomous rover is closing in. In this article I present 3 hardware additions:

First I found that the 1300 mAh LiPo battery could not be enough for long endurance roving activities. So I decided to add a pack of 4 NiMh AA batteries (2500 mAh each) dedicated to the Fonera. With this extra power, control and communications autonomy is guaranteed even if the powertrain pack becomes depleted. Additionally the efficiency is improved, because considering the fonera input voltage (5 V), and the voltage of the main pack (11.1 V), a regulator would be necessary, to properly drop the voltage. A linear regulator would not be a very efficient solution, and a switching regulator, in spite of being more efficient, is more complex and expensive. So with this separate pack, which provides around 4.8 V when fully charged, is enough for the Fonera (in fact the Fonera can be powered to a minimum of 3.5 V thanks to its internal low dropout regulator).

As I already had more than one power source, and several distinct systems onboard, in order to avoid the clutter of connecting and disconnecting sockets every time I wanted to turn the components on or off, I decided to add a control panel with 4 different switches:

The function of each is:

* MAIN - cuts the power to all systems;
* CAM - turns the camera on or off;
* CTRL - turns the Fonera (the control computer) on or off;
* ESC - turns the ESC (Electronic Speed Controller - it controls the speed of the powertrain motor) on or off;

A LED under each switch indicates if there is current in each circuit, and if its turned on or off.

The switches provide a way of quickly turning the devices off in case of malfunction.

The last item is a turret for mounting a sonar ranging sensor (an SRF02). At the top, a microservo is mounted. It will provide azimuth variation for the sensor, allowing the area relevant for navigation to be swept continuously.

In order to minimize the computational load and I/O for the host machine (Fonera), the PIC 18F2520 had it's original firmware (which is opensource - see http://www.robot-italy.net/roboforum/showthread.php?t=1600) modified to accomodate the ability to automatically put the servo sweeping continuously. The host in the case only has to use a sonar command that will return both the range in cm, and the angle of the servo (in us of control pulse witdth - it ranges between 850 and 2350 us for approximately 110º of amplitude). The original sonar commands were modified to provide the position of the servo associated to the sonar. Another command was added, for reporting the position of all the 8 servos that can be connected to the MuIn.

The next step will be to mount the sonar on the turret, and once this is done we have the minimum hardware for implementing autonomous control of the vehicle.

On the Fonera the control software is written in C, and is programmed like any linux application. So far I have only implemented a small application used mostly for testing the MuIn functionality (servo control, ADC channels, I2C, EEPROM, etc):

Cognition on Wheels

2010-03-25T17:06:00.000-07:00

Last, but absolutely not the least, is adding intelligence to the beast. Considering the budget constraints and simplicity of integration I decided by using a Fonera 2100 router as the workhorse for processing data. Equipped with a single chip Atheros solution, the integrated 32-bit MIPS R4000-class processor runs at 183.5 MHz, and is tipically enough for most network processing that is required. Additionally the IEEE 802.11b / 802.11g WiFi interface provides the means for remote communication with the vehicle. For local communication it features both an Ethernet interface, and a 3.3 V serial port.

On the other hand I also needed a way of controlling the servos (other than manually through the RC radio)from the Fonera itself. So I considered several serial and I2C servo control solutions, and found this. Besides having 8 servo outputs, it also features 5 analog inputs (10 bits), I2C bus, 2 PWM outputs for controlling motors, and a TTL serial port. This is all thanks to the PIC18F2520 in which it is based. This is essentially all the I/O I need for getting the robot car doing something useful.

Here is a picture of the car already with the fonera (just the bare PCB), and the Droid MuIn board (the multi I/O card I was talking about):

I also had to get a solution for powering the control systems (the Fonera and the MuIn) from the salvaged 10 V lead acid battery (at least for now). So I added the following switching power regulator from a car lighter cell phone charger:

The Fonera communicates via serial port with the MuIn. I had to make a small cable connecting both modules with each other:

The Fonera GPIO pins could be useful. Made a small circuit to buffer and translate levels from 3.3 V to 5 V for these GPIO lines. It might be useful in the future:

Let there be light!

2010-03-11T14:18:00.000-08:00

One of the most pleasant situations is when can execute an idea without using any of your budget. It occured to me that having some onboard lightsource could be useful for the car, specially if you plan on doing night driving. Well I took a look at my repository of electronic junk, and found a pcb with 9 white leds from a broken flashlight, and a bunch of broken 9g microservos.

So I thought, well...if I could get the leds to be turned on and off through a free channel on my radio, it would be sweet.. And then took a look at one of the servos, and thought: I remove the motor, replace the encoder pot with a set of resistors, connect the leds in series with a small value resistor, and it should do the trick.

And so I did it: first analysed the servo operation in its original form. Connected the motor to an oscilloscope, and verified that a PWM signal that varies in duty cycle is fed to the motor. The further you move the stick, the more the duty cycle approaches 100%. Without surprise the peak voltage would be 5 V at the motor terminals (the same voltage that powers the servo).

Measured the pot resistance, which was 2 KOhm. Measured the current consumed by the leds while being fed with 3.1 V (minimum voltage for enough luminosity). It would draw 60 mA.

Then all I had to do was applying Ohm's law to find the appropriate resistor to drop the voltage, given the current that we know the LEDs consume. Found that the ideal value was 52 Ohms (V=RI <=> R = V/I <=> R = 3.1 / 0.060 = 51.66 ~ 52 Ohms).

I did't had this value (the closest resistor is 51 Ohms), so I used the closest resistor I could find at hand. Found a 47 Ohm, which in spite of being slightly smaller, it shouldn't harm the leds as I was being conservative with the voltage in the first place (these were being used in a flashlight powered by 3 AAA batteries - meaning that the voltage could be up to 4.5 V). The typical voltage to which white LEDs are rated is 4 volts.

With a bit of experimentation found an appropriate value for the resistors replacing the pot. One 2 K resistor between pin 1 and pin 3 of the pot terminal, and a 1 K resistor between pin 1 and pin 2.

By doing this I trick the servo controller into thinking that the motor is always in the same position, while the user commands it to go to a different position. This causes the controller to continuously provide current to the motor, in an attempt to reach the desired position. Here instead of the motor we put the LEDs. The result is the LEDs being constantly lit while the stick is in a given region, and off in the remaining positions (because a negative voltage is fed to the LEDs - if a motor would be present instead, it would cause it to move in a different direction).

A little bit of soldering, and it was done! This way I had the cheapest possible RC headlight without spending a single cent.

And finally, after putting heatshrink around the PCB, the work was done:

Intelligence on wheels

2010-03-03T15:20:00.000-08:00

Robotic vehicles are not a novelty. Initial attempts to create autonomous roving machines date back to the 1970's, with examples such as Stanford cart in 1961 and Shakey, Moravec in 1979. These were simple machines. Digital computers were not yet miniaturized to the point of enabling interesting computing power onboard a vehicle, regardless of its practical size. Even so, the state of the art of the technology at that time proved sufficient to allow the mankind to explore new fronteers of a universe never before crossed by human artifacts. Two such examples were the NASA Voyager I and II missions. Having passed the 30 year mark in space, these prodigious machines still beam back health reports to earth, and should continue to be up and running until the energy generated by the plutonium based RTG (Radioisotope Thermovoltaic Generator)is insufficient to power the essential electronic systems onboard (of which one of the most important ones is the radio transmitter). This should occur anywhere in the next 10 years.

Today we have the result of tremendous technological improvements since the time the Voyager spacecrafts had been created. However, achieving the same degree of reliability is a milestone not always achieved in every case, regardless of how much extra knowledge the humanity have been gifted with.

While trustworthiness is not necessarily a consequence of innovation, it must be in the agenda, as long as the outcome is intended to be a dependable solution.

Anyway, the focus of this post is more on innovation itself rather than discussing trustworthiness and reliability. I am presenting a small part of what one day will be with us everywhere.

We are surrounded by automatic machines in our daily lifes. Even where it's less obvious. The small capsule called elevator, that takes us from one floor to another is one such example. While it doesn't look like a robot, it is a very autonomous machine. Equipped with clever microcontrollers, elevators are capable of making logical decisions, while multiple users request its attention. It's a simple example of a machine that in its current state of evolution is driven by an electronic computer, has sensors, and is capable of triggering actions (e.g.: activate a motor) based on a predefined plan, or in response to external input (e.g.: pressing a button). It can be enabled with useful optimizations such as having the ability to position itself automatically in different floors, depending on the selective demand at diferent times of the day, within a building.

Robots are intended to be useful for the human being, not to replace him. Through automatic machines we moved from one point to another in our ability to produce more and better artifacts, and to provide better services to people.

In this blog post I am presenting you with a machine that, while functional, is still the first step for achieving a helper robot, the hopefully will be the base platform for making very interesting household applications for machines this size.

I started from buying a cheap supermarket toy RC car. It called my attention the fact that besides its low cost, it was large (1:10 scale), had very nice looking wheels, and featured a 850 mAh 10 Volt lead acid battery (so most likely it also had a motor rated for 10 Volts or more):

Of course the lead acid battery would not be very interesting as my future power solution, but we'll return on that later on. I decided to buy this car for the features managed to discriminate.

After fully charging the lead acid battery, I tested the car, still in its original form. I noticed that it really had nice torque and plenty of raw power. However, it lacked the ability to harness the beast. Like with most toy R/C cars, it's circuitry only allows zero or full throttle to be applied, both in forward and reverse directions. This, of course besides being very limited, also translates to prematurely worn and damaged gears. On the other hand the steering was also very poor. It was also zero or full travel in both directions. Of course we cannot expect proportional controls for a 25 Euro car! Well, I tested the car for, say, 1.5 minutes, and the battery soon started to gradually drop the delivered power. I was admired, either the battery had very poor quality or the motor was an animal.

I decided to start the transformation. I had a few spare hobby R/C parts such as a few microservos, a Art-tech 41 MHz 6 ch. receiver used in model helicopters and planes and a 11.1 V 1300 mAh battery (the stock battery from my Falcon 3D heli).

I started by removing all the crap out of the car, until I got this:

Here is the circuit board with the receiver and motor control. Here I had already removed the two SPDT relays used for reverse. Take a look at the big resistor (feer):

The original steering motor:

It hardly had torque to turn the wheels, specially after 1 minute of battery use.

The transmission motor yes, had quite a punch. I measured it's current while connected to the fully charged battery, it draws 1.5 A free running, and 13 A under full load (zero RPM on the shaft). So it consumed 130 Watts of power. The output power should therefore be around 100 Watts, assuming it's a reasonably efficient brushed motor.

I still needed a brushed motor ESC and better servo for the steering. I searched the web for DIY ESC solutions, and found this, which seemed interesting:

http://www.designsoft.com.au/ahome/rc/PIC-ESC/ESC.html

It featured design variations for both cars and planes. It seemed exactly what I needed, and I calculated that it shouldn't be hard to build and expensive. I had the option of choosing the relay or the H-bridge reverse. As I still had the two SPDT relays from the original circuit, I decided to try this version, as it would be slightly cheaper. Already in an advanced stage of the assembly:

And the top view, with the two white relays:

After building the hardware it was time to program the PIC:

I had to build a small board with the ICSD socket for the PIC, as the ICD 3 is not provided with one:

Mounted the 41 MHz radio and the LIPO battery. Both fitted nicely into the original
battery compartment:

Mounted the 43 g standard servo (it has 6.5 kg of torque). Replaced the original links with ball links. Adapted the steering bar in order to attach the servo arm through a ball link:

After a few more assembly iterations, mounted a virgin pcd board to be used as a plate for scientific instruments, and attached a gymballed support for a 1.2 GHz wireless camera. The gymball was assembled manually with aluminium. It uses two microservos to provide pitch and yaw for the camera. This is the result:

A detail view of the camera, which is also powered from the LIPO battery, through a regulator board I have also assembled (located in the bottom of the virgin pcb). It provides +5 V and +9 V necessary for the camera (camera and transmitter respectively):

The car is then controlled by a standard PPM 6 ch transmitter (41 MHz):

After the assembly, it was time for a test drive! Turned on the camera, connected the 1.2 GHz analog video receiver to a home made patch antenna, and time to hit the road..errmm...the wooden pavement..

As the car moved away from the place where I was controlling it, signal weakening and multipath interference became apparent. Some servos glitch violently under signal interference...dumb radio... The ESC on the other hand doesn't react because it properly filters occasional glitches.

Ion Motor

2010-01-14T14:57:00.000-08:00

Ion motors are very cool stuff. So cool that Nasa decided to invest research effort in this subject since the early 1960's when the physicist Harold R. Kaufman achieved the first design. In spite of the small ammount of thrust (when compared to conventional rockets), ion motors are capable of a very large exhaust speed, being equivalent to ten times the exhaust speed of a high quality rocket (the later can only achieve between 3-4 km/s). This means that ion motors are capable of continuously accellerating an object up to the exhaust speed (considering the space environment, where drag is practically absent). The time for exhaust speed to be reached depend of the mass being moved.

Even though a full size ion motor is large, complex and will only work efficiently in a vacuum environment, we are able to get a glimpse of the ion propulsion without spending too much money. With a simple high frequency HV power supply (can be built from a CRT television flyback transformer) we are able to provide the power for the ion motor, which in essence is just a ground plane (made of aluminium foil), a paper disk, and a copper wire frame (shaped as a cross with the tips bent in the same direction). This is placed on top of a base structure, through a pin pointing upwards, which maintains the paper disk standing with the least possible drag.

The disk is connected to the HV output of the transformer. In the particular design that is shown on the video, the frequency of the HV signal is of about 94 KHz. The voltage is estimated to be around 15 KV between the positive and the ground plane. An exact measure could not be obtained, as a device capable of reading in this voltage range was not available. However a spark will form when a gap of around 15 mm is reached. This allows us the obtain the indicated estimate.

In the video we see that the disk will slowly spin up until it reaches its terminal velocity. In a vacuum environment it would continue to spin up until the drag at the joint would become the limiting factor. However this particular design would not work at all because it depends on the air to produce the ions that are necessary for the propulsion. The ion motor designed by Nasa has its own source of propellant gas for ion production.

In the following photo you can see the ion spray coming out of the pin. A large spurious excursion can be seen at the bottom of the pin:

After a bit of testing the ozone smell is noticeable. The HV discharge causes oxigen to split into single atoms, and to recombine as ozone.

A slighly refurbished disk (essentially just the frame) can be seen spinning in this photo. The ring that is visible corresponds to the plasma from the ion spray at the tips of the frame:

Another view of the pin that attaches to the center of the disk. The corona discharge is clearly visible:

Home Built Hovercraft

2009-11-14T05:04:00.000-08:00

While not being the most efficient means of transportation, hovercrafts impress by the ability to operate both in land and water.The inherent maneuverability is also an interesting characteristic. While the driving is entirely different from a vehicle with wheels, hovercrafts are able to change direction very quickly, given the fast rudder response (usually located in the rear, and close to the propulsion source).

Building a full scale hovercraft would not meet my available budget, time and ambition. Given the fact that I had some extra RC parts from the model helicopter (servos, ESC and battery), I decided to buy an airplane brushless motor plus propeller, and build an hovercraft with household parts (essentially a plastic food container, some cardboard and plastic bag). With the help of my friend hot glue I put all the stuff together, resulting in a high performance RC hovercraft.

Here is a detail of the brushless motor and propeller:

With the two rudder fins, turn response is improved at the cost of a slight increase in drag:

The parts list used for assembling the hovercraft were:

One EK5-0086 1000 RPM/Volt 45 g brushless motor;
One 7x6E propeller;
One 18A brushless ESC (originally belonging to the Art-tech Falcon 3D helicopter);
One 1300 mAh 11.1V 3s1p LiPo batery (from the same Art-tech helicopter as well);
One 41 MHz PPM receiver (compatible with the Art-tech E-fly 100C transmitter);
One 9g micro-servo;
One 165x240x65 mm plastic food container;
Some cardboard;
0.8mm wire;
5 mm thickness 400 mm height wooden pole;
Plastic ties;
Bolts, nuts and washers;
0.1 mm thick plastic bag.

Tools:

Soldering iron (mostly for heat-cutting the plastic);
Carboard cutter;
Scissors;
Screwdrivers;
Pliers;
Ruler;
Caliper;
Pencil.

The skirt was simply made of plastic bag with help of hot glue to attach it to the bottom of the hovercraft.

Cardboard was used to make the air cushion internal separator and duct:

This part is still to be perfectioned, as the lift performance is not the best (the skirt practically does not raise from the ground, and hardly moves in less regular surfaces).

The following video shows the hovercraft in action, performing several 180 degree turns and spins:

Another video shows the same hovercraft equipped with an onboard camera, providing a first person view of the drive:

Remote controlled flight

2009-05-31T11:09:00.000-07:00

In my adventurous quest at being able to fly with my feet on the ground, I begin to understand the true fun of this hobby and how it stimulates the mind to understand the physics behind flight, and in the particular case of the helicopter how stable hovering and forward flight is possible.

Even though I have a flight stabilization unit onboard, I have diminuished its authority to almost zero so that most of the effort is left for the pilot behind the cyclic.

Flight simulator software greatly helps in ensuring that minimum training be taken before wrecking the real aircraft. It allows basic orientation skills and familiarization with the remote control to be achieved.

However, for full flying skills to be achieved, the simulator does not replace the real helicopter. Even the best simulator only offers a limited imitation of the behaviour of the real scenario. There are many more variables wich are very hard to simulate, and we find these in a real flight. Often a representation of our R/C model is not available, so we are forced to use a machine with closest similarity to our model. Sometimes it is no good enough.

Another aspect is the field of vision: in the simulation we are limited to a field of view of roughly 70º (depending on our distance to the screen, and its size and shape). In the real world, the field of view is of 180º (or more). So much more neck movement is necessary to keep track of the aircraft.

In the simulator there aren't many factors of distraction (unless you keep your IM client running in the background :)). In the real world there may be several elements of distraction, including people and animals (specially dogs).

Once the first steps of simulator training are completed (and we are comfortable with the transmitter, the control gymbals and orientation - make sure you can properly fly nose in and nose out without trouble), it is time for flying the real deal. A calm windless day and a place with a lot of space (more than 20 m x 20 m) and soft ground are essential for having the least ammount of surprises. At this stage training gear is essential if you don't want to break your blades all the time.

Safety cannot be disregarded and you must make sure there are no people walking around in your flying field. If you bring company along with you, make sure they are at least 10 feet behind you and stationary. It is never too much to remind that RC helicopter is the most dangerous model aircraft activity. Imagine these as airbourne lawn mowers. The spinning blades can easily chop off a finger or seriously cut a leg, not to mention the damage it can cause to the face.

While this blog post is not indented to be a exhaustive beginner manual for helicopter flight (you can find a lot of good documentation in the web regarding this), it is worth mentioning that the first training step is to achieve proper hovering skills. Do the best effort to maintain a steady position while hovering at one or two feet off the ground. When you first take off, you will notice the helicopter drifting to the left (or right in case of counter-clockwise rotating rotor head) even with the cyclic properly trimmed. This is the tail rotor propulsion, which is specially noticeable at low altitude. During takeoff you must compensate by applying some right cyclic.

The next move is the transition to forward flight. Here you must make sure you have a lot more available space, as you will easily achieve high speeds. In forward flight the helicopter behaviour is much more similar to that of an airplane. The cyclic behaves much closer to the ailerons and elevators of an airplane, and the anti-torque (or tail pitch) similarly to the rudder. While forward flight is somewhat easier, mistakes can however be much more costly. One aspect to consider is the distance: the further the helicopter is from the pilot, the harder it is to properly identify its attitude. Orientation mistakes become much more likely, so a lot of concentration is necessary to make sure the mistakes do not take place.

Here is a video I have taken with my onboard camera, showing some forward flight and a nice 60 feet climb:

Getting airborne (on a scale sort of way)

2009-04-05T09:16:00.000-07:00

The ability to fly have been a long envied feature of birds. Since the early days of the history of mankind, there have been the ambition to fly like a bird. The same way the conquest for new lands and the seas have been seeked and achieved by people (both for political reasons and for the bare survival), the skies have also been one of the goals of humanity. While many have envisioned and prototyped flying machines (going back to the time of Leonardo Da Vinci), only during the the 20'th century this dream was fully achieved, with the Wright Brothers having created in 1903 the first controlled powered flight. The war effort strongly stimulated the development of this new, efficient way for people to move, control, watch and dominate the territories.

Techonology envolved so fast during the 20th century that besides huge improvements having taken place with the airplanes and other flying vehicles, the industry also found feasibility and a market for flying machines that would not have useful functionality at sight. The combination of aeronautics with radio technology gave birth to products developed to fulfill the sheer fun of flight, but in a small scale, with the feet on the ground, safely behind a remote control.

While these small machines were great for people to better understand the dynamics of flight and how the control surfaces influence the behaviour of aircraft, still there was no solid purpose other than entertaining the model flight enthusiast.

Today, while model aviation is still present as a hobby crossing many different ages, its industry have also boosted the development of new ideas in the field of robotics. With complex computing machines becoming small and light, it becomes possible to put a lot of autonomous behavior on board of a model aircraft.

With the combination of techonologies in the form of packaged miniature devices, it becomes possible to have all the essential flight instruments in a small unmanned airplane or helicopter that can stabilize, fly by itself and follow a plan previously uploaded by the pilot.

A network of sensors allows useful information to be collected and transmitted in realtime, turning a unmanned aircraft into a potentially useful machine.

Conventional unmanned aircraft require the pilot to have visual contact with it, at a distance close enough do discern its attitude, heading, relative speed and altitude. The limited ability of the human vision to recognize these parameters, after some training make navigation from an external point of view possible. Training enables the human brain to acquire the ability to steer the aircraft the same way as if the person would be onboard the aircraft. The pilot have to mentally translate the action to be taken, into appropriate radio control input. The kind of input a person has to provide is conditional to the orientation of the airplane or helicopter relative to the individual. A trained pilot has all this reasoning mechanized in his brain, so that the response is immediate and he doesn't have to "think" about each control input. The timing is critical, and a unexpected delay most likely will cause a crash.

In the particular case of a remote controlled helicopter, input is particularly time critical. It is commonly said that "an helicopter is a machine that doesn't want to fly". In order to keep an helicopter hovering or in forward flight, constant pilot input is usually necessary, as model helicopters are inherently unstable (given its small weight, the lightest air turbulence will impact its stability, and the lightweight nature of the main rotor prevents the inertia from being strong enough to keep the helicopter level during a significant ammount of time).

Today some flight stabilization solutions designed for model aircraft exist and are available on the market for the enthusiasts of r/c airplanes and helicopters. Two main types of solutions exist:

Optical system, based on four far infrared sensors (4 thermopile sensors placed at 90º angle from each other) - this system relies on the thermal contrast between the ground and the sky to keep the helicopter level against this reference. It has a very fast response, but it has the disadvantage of being useless in closed spaces.
Gyroscope based - most r/c helicopters today have a piezoelectric gyroscope. These are however limited to providing yaw rate or heading hold functionality to help the pilot maintain a steady tail, irrespective of the direction of the wind. A 3-axis gyro provides the additional degrees of freedom enabling not only yaw stabilization, but also swashplate or cyclic stabilization. Besides controlling the tail servo, it also controls the two or three (in the case of a CCPM helicopter) cyclic servos. This enables the helicopter to be precisely level without constant input from the pilot. Some of these devices also feature an optical sensor (similar to that of an optical mouse) that also provides position hold up to 5 meter altitude. This enables the helicopter to be completely steady in the air, without the pilot having to touch any of the control gymbals.

The first solution is usually the cheapest (around 50 euros), being the second usually 6 to 10 times more expensive.

In my experience as a r/c flight enthusiast, I've decided to acquire a small (400 class) electric helicopter. I've chosen a Art-tech Falcon 3D. My budget was limited, and the offered functionality and degree of reliability seemed reasonable for the low price, so I decided to buy it.

At the beginning, given the lack of simulator experience I've failed to perform successful flights and soon made some expenses with new main rotor blades. While the training gear is helpful, it still doesn't prevent all of the crash situations. A bad choice of take-off space also makes things harder.

I've decided to play safe and get the stabilization gear:

After acquiring some flight expertise I went for the acquisition of a flight camera:

Here is a flight session with the onboard camera:

Carjacking - shortening the path for justice

2008-10-05T11:09:00.000-07:00

As automobiles become more sophisticated, direct theft by tampering with the ignition system becomes a nearly impossible task. This narrows down the choices left for the criminals, who end up adopting the only choice where successful access to the vehicle is guaranteed: threatening the occupant(s) with a weapon in exchange for the car.

In general the criminals can get away with this type of crime if they are efficient and careful, leaving the victim with few evidence to help in the investigation and tracking of the vehicle.

However, once again we can put technology on our side, and in an attempt to be resourceful enough, take advantage of two broadly available devices: a cell phone and a GPS module. These devices
are becoming cheap enough to have dedicated in a discrete location inside the car for a single purpose: on demand location.

By being able to query the location of the car just by sending an SMS message to it and get a reply with the corresponding GPS coordinates, this could be a useful tool in the police work, as real time location would always be possible.

Following this idea, I've decided to attempt a simple implementation of one such system which I have designated "Vechicle Finder". Having as a platform a Nokia smartphone and a Bluetooth GPS device (both sitting on a board for convenient fixation of the apparatus), I have developed a Java application which reads the GPS coordinates and sends it as an SMS to the originator of the request SMS:

Upon receiving an SMS containing a special command and some optional parameters, this onboard device will reply with another SMS containing the following data:

Latitude;
Longitude;
Altitude;
Heading;
Speed;
Precision;
Number of satellites in view;
Timestamp.

By default only one sample of data is returned by the application, but depending on the value specified in the request, a bundle of successive messages can be transmitted automatically.

The meanders of OBD-II protocols

2008-09-07T11:05:00.000-07:00

As we travel through the history of automotive technology back and forth, we realize that at the heart of the machines that enable us to go from point A to point B faster than our legs, are a number of components that essentially haven't changed too much: engines still burn fossil fuels and the vast majority are based on pistons that transform the explosive energy of the fuel combustion into movement.

Only a large number of gradual improvements have taken place here and there, defining the milestones that fill the many stages of automotive evolution.

However, electronics and digital technology have envolved in a much faster and radical way. The first computers have very few resemblances to a computer from the modern days. In a few decades the speed and capacity of computing devices have grown thousands of times. Computers play a vital role in peoples lifes today, both personally and professionally.

Cars haven't envolved with the same rithm and pattern. The most important lines of evolution in car design and technology have been centered in improving the user experience (better handling, comfort, performance, design) , safety (as the number of people driving cars have been increasing, the rate of disasters with casualties have also increased over the years), fuel efficiency and low emissions (many regulations have started being imposed by the governments
in an attempt to force the industry to reduce the gas emissions that are known to contribute
to the greenhouse effect).

With all the requirements that are placed in the development of better cars, the use of modern electronics could not be disregarded, as it is at base of a large number of improvements that could not be achieved by any other means:

Fuel efficiency and low emissions: by adding an ECU (Engine Control Unit), precise control over the ignition timings and fuel injection have been made possible. The ECU, a specialized computer that receives information from many sensors mounted in different parts of the powertrain, ajusts the optimal fuel mix and ignition timing dinamically, varying the parameters as the conditions change (air temperature, engine temperature, air pressure, engine RPM, etc). As the engine ages, the parameters are also changed in order to obtain the best performance given the altered engine characteristics. By ensuring the optimal fuel mix it also decreases greenhouse gas emissions, as it ensures a correct burn that minimizes the more nocive substances at the exhaust.
Safety: the braking system is one of the most important items in a car's safety, which can play a vital role in preventing a crash or reducing the speed to minimize the effects of an unavoidable This is not trivial, as the natural instincts in a critical situation not always match the optimal result. In many cases it can be catastrophic, as applying excessive break pressure can cause the weels to block, thus increasing wheel slippage, preventing the car from stopping at a safe distance. Modern electronics allowed a layer of control to be put inbetween, causing the brakes response to be always optimal, regardless of user input. crash. However its efficiency have been dependent upon the proper skills of the driver in assessing the correct pressure to apply in order to achieve the right result.
This system, called ABS (from the german expression Antiblockier-Bremssystem, which means Anti-locking System) have been a large improvement in reducing accidents specially in slippery terrains. The ABS relies on a small computer that has sensors which pickup the acceleration, speed at the wheels and brake pedal pressure, acting on the brakes hidraulic system, causing the user control to be partially overriden by this system, whenever necessary.
Another important system is the one which governs Airbags inflation. By monitoring the car speed and information at the special impact sensor (a heavy duty accelerometer), in the event of a crash it should be deployed, as the decelleration is high enough to contribute to injure the occupants.
User experience: digital technology is present today in other aspects of a car, such as onboard navigation systems (GPS), car stereo/dvd, automatic air conditioning, etc.

On the technical backstage, it soon became a requirement that the critical electronics inside a vehicle (e.g.: upon an ECU failure the engine will stop running) should be monitorable and allow some sort of diagnostics link so that technicians could better track the problems without too much guessing. The way the car components could be linked to an external device for diagnosis (i.e.: a computer or some type of dedicated terminal) would vary according to each manufacturer. So in the early 90's there were several protocols, such as ALDL, OBD-I, K-Line protocol, etc.

But around early 1996, there have been some pressure over the industry to create a standard that would allow a single equipment to at least read a minimal ammount of important data from any vehicle no mater what make or model.

OBD-II is still quite generic in definition, as manufacturers usually implement a particular subset of the specification, specially at the type of bus(es) that is(are) used.

A complete device should be capable of recognizing the bus in use, switch to it and begin the proper handshaking.

Commercially available devices that allow a connection between the OBD-II bus from a car and the computer are usually expensive, even though material costs are low (manufacturers and resellers still benefit from the lack of competition in this market, and a reasonable sustained demand).

For those who are skilled with the soldering iron, the DIY alternative is quite advantageous. While a commercial OBD-II <-> RS-232 can cost up to 200 €, the DIY solution will cost as low as 60 € (30 € for the necessary microcontroller, 20 € for the J1962 connector - the one that attaches to the socket in the dashboard, and 10 € for the remaining components). About 7 hours of effort and you're done (yes, the microcontroller and the connector are expensive, and
the effort is not neglectable: the microcontroller you pay more because it's bundled with a
commercial firmware, and the connector is supplied by a car accessories reseller).

Decoding ACARS transmissions

2008-03-22T11:39:00.000-07:00

Just as with other radio related hobbies, this is quite an interesting one:

Using an appropriate air band receiver (or any receiver capable of tuning frequencies between 108 and 137 MHz in AM);

and a home built 1/4 wavelength antenna (approx 2 dB gain):

With an adequate ACARS decoder software (which decodes signals using the soundcard), information transmitted through this protocol can be seen, as long as you are tuned to the right frequency. For example in Europe the frequency would be 131.725 MHz:


ACARS mode: 2  Aircraft reg: .######
Message label: 10  Block id: 8  Msg. no: M80A
Flight id: ######
Message content:-
FTX01.LGWKOGT
COULD YOU ADVISE THE
FOOTY SCORES. TA

Combining this hobby with the actual airplane spotting can be very fun, making it ideal for a relaxing weekend, when no more activities seem to exist :)

Long-haul WiFi - new developments

2008-03-15T18:52:00.000-07:00

Returning to the WiFi topic, here is the new antenna development that I had promissed in the early post, once the dual "cantenna" design was finished.

The dual cantenna is quite efficient, as I realized by connecting it to reasonably distant access points (in excess of 200 meters, with many obstacles between, including houses). By verifying the antenna efficiency was the expected, I assumed that in better conditions the range could be far greater, by establishing a link between two antennas of this type or other type of optimal configurations.

However, I knew I could push it a little further, so I decided to buy a 12 euro 45 cm dish from a regular satellite TV system, and the materials to build a biquad feed. I installed the dish on top of the tripod used for the cantennas, and attached the biquad feed (built according to these instructions) to it:

Instead of using the SMC repeater I've used before, I decided to get my hands on two foneras with a fresh new version of OpenWRT and do a slighlty different setup: one of the devices would connect as client to the remote network, having the dish antenna attached to it. The second device, linked to the first through the Ethernet port, would be configured as Access Point and provide DHCP to the clients on the local WiFi network. The first fonera could additionally do NAT and have a few firewall features activated.

So far the efficiency tests have not revealed far superior results, most likely because of the low quality coaxial cable (RG-58) used for the connection between the antenna and the fonera.

This type of design could be ideal for building small weather stations where power is a significant constraint and some data needs to be periodically transmitted. Other application could be for surveillance cameras where the location of the camera could turn impratical the use of a wired link.

Water Fuel Cell - DC voltage results

2008-01-07T15:54:00.000-08:00

Today I performed some tests measuring gas production with DC voltage. The tests were performed in order to obtain aproximately the same consumed power, namely 22 Watts.

DC test performed:

High frequency test (100 KHz) at same voltage:

The DC test shows a clear increase in efficiency (almost 25%) relative to the pulsed electrolysis.
Still to compare these results with low pulse frequencies (it is likely that power losses are quite high at 100 KHz).

Water Fuel Cell - more results

2008-01-06T15:29:00.000-08:00

For one measurement taken without the inductor coil, we have the following values:

Water Fuel Cell - measured results

2008-01-04T10:21:00.000-08:00

I performed two consecutive runs without changing the conditions. The data obtained is as follows:

Considering that it consistently took 4 minutes to produce 80 ml of H2 + O2, this
gives a rate of 1.2 litres/hour of H2 + O2.

Water Fuel Cell - back to business

2008-01-04T09:14:00.000-08:00

After reparing the WFC and adding extra safety measures, here is the entire setup producing hydrogen at 12 Volts DC and 1.94 Amps. Next I will provide a grid with measured values, including gas volume:

Water Fuel Cell - cleaning the mess and repairing the electrolyser

2008-01-03T13:59:00.000-08:00

After yesterday's mishap, and of realizing how lucky I was to still be in one piece, it is time to take a deep breath and after looking into what went wrong, follow all the safety measures to prevent one such event from ever happening again.

I started by getting a new lid for the electrolyser and putting a new seal rubber in it, this time with two clamps instead of one. Now only the clamps are used for holding the lid. The original ring around the lid was discarded. By itself this doesn't provide extra protection against an explosion, apart from the slight probability of the lid popping out in one piece instead of fragmenting into several pieces (today I still found fragments of the lid in distant corners of the room).

Considering that there is not much to be done in therms of safety with the electrolyser itself, I am starting to employ more effort in building two cascaded bubblers, with two main features: be long enough to maximize the distance between gas input and output (allowing for a large water barrier in case of a back-flash) and each bubbler be made from a material which will not fragment into many pieces in case of an explosion, or the lid be allowed to pop-off in this case. The major problem with the electrolyser lid lies in its acrylic nature, which when broken will fragment into many sharp pieces. When propagating at the speed of sound these fragments will cause damage to whatever is in the way.

Here is a picture of the refurbished electrolyser:

Safety goggles is also an extremely important item to wear during the elecrolyser operation:

Supersonic fragments will most certainly rip an eye off, in case you be in the path of the explosion.

Water Fuel Cell - HUGE ELECTROLYSER EXPLOSION

2008-01-02T14:27:00.000-08:00

Sometimes mistakes can be the death of the artist. In this case I got closer to it than desirable: after building a tiny bubbler for testing sustained combustion I hooked it up to the electrolyser (aka: Water Fuel Cell) - one tube going from the electrolyser to the bubbler and another tube from the bubbler to the gas exit, where combustion would be tested.

The bubbler was working fine, air tight as necessary. After approaching the output from a flame, small explosions along the tube would occur, without affecting the WFC.

But after pressing the tube and letting some pressure build-up, as it was released close to the flame, the gas immediately exploded, propagating to the WFC. The entire process occured instantly, blowing-up the thick polycarbonate lid from the WFC, and scattering fragments all over the room (some could be found 4 meters away from the point of explosion). A lamp that was just overhead was partially damaged by the blast, and the ceiling was slightly bruised by one of the fragments.

Conclusion: bubbler design is a critical part of the system. A good bubbler will provide proper separation of water between the input and the output, in order to ensure that the fireball from the explosion will not advance through the liquid, reaching the tube that leads to the WFC, where the greatest concentration of hydrogen and oxygen can usually be found. It is also important that the volume of gas the bubbler will allow to be formed be minimal, in order to ensure the effects of an explosion inside it be under control. A good solution can be the combination of small gas volume with a mechanism of pressure limiting in case of explosion. Added to that there should be a minimum of two cascaded bubblers, further limiting the effects of an explosion. It is worth to remind that the hydrogen combustion is about 1000 times faster than propane gas, so even at atmospheric pressure the violence of such an explosion is a lot greater.

Picture of the hazardous bubbler used:

Electrolyser after explosion (water removed before the photo):

Damage to the ceiling:

Fragments of the lid:

Water Fuel Cell - inductive load added

2008-01-01T16:14:00.000-08:00

Just as refered by several people doing this type of research, adding and inductive element to the load would create a resonant LC circuit, with the WFC as a capacitor. I used as an inductive load the secondary coil from a 220 V / 12 V transformer which was added in series with the WFC. The most notable effect was the suppression of the high frequency signals at the WFC, along with a voltage dropout of nearly 5 volts. The curious thing however is the fact that the gas production doesn't seem to be affected for the same input voltage/current conditions. As the transformer becomes hot after a couple of minutes of operation, this shows that there is less energy going to the WFC.

This sample video shows the cell in operation under these conditions:

Water Fuel Cell - fixes and more tests

2007-12-29T09:34:00.000-08:00

The container is now air tight. This allowed me to start doing some electrolyser efficiency tests. By attaching a small hose between the container and a small flask containing some water I could see how fast the bubbles would form, by varying pulse width and frequencies (both the carrier signal width/frequency and also the gating signal width/frequency).

From the tests carried out so far I could not see a relationship between frequency/pulse width and the ammount of gas formed. I could only see that as the current increases, the more gas is produced (i.e.: the rate at which the bubbles appear in the water flask is greater). And the current increase depends on the pulse width alone (or not entirely - considering that the WFC behaves like a capacitor, current will also depend on the frequency).

The experiment setup, including the water flask, where the gas output goes:

The bubbles containing H2 and O2 mixed-up:

Water Fuel Cell - more improvements

2007-12-24T08:46:00.001-08:00

While the air leak problem have not yet been solved, other problems are now fixed, and some improvements have been made. The control circuit have been verified, and it was found that the 7805 regulator that was being used, didn't had the GND pin connected (oops, minor mishap). In spite of that the two 555 timers would work, as the regulator would let the input voltage pass through. The output signals were not however perfect square waves. As the GND was hooked up, the MOSFET would no longer switch from cutoff (the 4 volts output from the second 555 would not be enough to activate the transistor). So the 7805 was replaced by a 78L09 and the circuit started performing normally, delivering a clean signal to the cell and smaller heat buildup in the MOSFET.

Another change was the addition of a small piezoelectric speaker to the container of the cell. This causes the soundwaves to propagate inside the water, eventually contributing to frequency stimulated breakdown of the water molecule. At a later point comparative results from using and not using this element will be analised in order to assess if it plays a role in turning the electrolysis process more efficient.

The speaker is connected in parallel with the load (the Water Fuel Cell), and it can be heard while at audible frequencies:

Starting to bust water into its basic elements

2007-12-17T14:34:00.000-08:00

The basic electrolyser design is finally finished. After a lot of steel cutting and drilling, I've finally finished the first prototype of the machine which will tell wether or not pulsed electrolysis of the water, through special frequency and pulse duration control, can by itself be the key to making the process several times more efficient than conventional DC electrolysis.

For now there are a few issues to resolve, namely:

Make the seal on the top cover air tight - even though the container was bought under the premise that it would be air tight, in practice is was verified that it was not;

Control circuit FET transistor is heating up too much under a 4 Amps load - must check if the gate voltage is being enough to cause it to switch from cutoff to saturation and not somewhere in between. According to the device datasheet, it dissipates up to 150 Watts of power. In this case it has to dissipate around 40-50 Watts of power (10 to 12 Volts at 4 Amps), which is probably too much for the 25 cm^2 heat sink installed.

This is the complete setup (electrolyser + control unit + DC power supply):

4 Amp run (12 V):

No load applied:

Typical signal applied to the cell (10 ms/div, 5 V/div):

Water - alternate fuel source and a panacea for mankind?

2007-12-06T14:04:00.000-08:00

When it comes the time to pay after filling up the tank, you dearly wish your car could run on anything cheaper than stinky old gasoline (or diesel). Wouldn't an entire global economy depend on this precious product, and you could establish a parallel with other things like drugs, where the desperate sense of necessity leads to the unavoidable obligation of paying a large sum of money just to obtain a given ammount of it.

It's a sad fact, however, that in this business the whole world is an addict, and just like with a junky, the side effects of this condition are starting to show up.

And where drugs exist, dealers, cartels, entire webs of traffic make up the building blocks of this entire business. In the oil world, the same entities exist, with different names and covered in the umbrella of legitimacy.

If it wouldn't be legal the entire world would stop: people could not run their cars to go to work, airplanes wouldn't take off, ships could not carry goods across oceans, and so on.

Now imagine a world like ours, where oil dependency would have seriously compromised the health and survival of its population, by letting polluant agents released by oil combustion damage and destroy the existing natural resources. Until one day a man finds that using a not very complicated process, water could be splitted in hydrogen and oxygen, just like with electrolysis, but requiring a very small ammount of energy in an equation where the profit margin, i.e.: the hydrogen obtained in return, would be many times greater than the energy spent in the process. With this invention this man would have killed the oil industry, simply because 70% of the earth's crust is covered by water, whereas oil certainly only makes up a tiny fraction of this value, and falling. And as if this wouldn't be enough, instead of the many toxic gases released by the conventional fuel combustion, hydrogen combustion only releases...water vapour. But the oil industry could not disappear. The relationship between oil companies and governments, and ultimately between governments and other nations would be complex, and oil would be the glue holding things together. And like with so many other things in life there would be a consistency that we wish we would not see: the nations holding the greatest share this product would happen to be those with the greatest deal of conflicts, internal, or with the rest of the world.

Oil could well be the only narrow stream of understanding, or the very reason why they could have the arrogancy of turning against the entire western world. In one way or another making oil obsolete would not leave the world serene like with any other useless invention. Liken anyone or anything threatening a multi-billion dollar industry there would have to be a price to pay, or a long fight before this miracle of mankind could see the light of day. In this hypothetic world, the mastermind behind the magic key to salvation would no longer sleep at night with the same serenity as before. And not without reason. After all the entire nation would watch his steps, and secretly conspire against his existence, in an attempt to suppress any threath against the value of oil in the global economy, where his country would have a lot to benefit from. But as a self ensured man he would be, nothing prevented him from patenting his invention, and going ahead with his plans. Indifferent to any declared threats, went ahead with his plans, convincing investors to finance his project. One day, the man shows dead. Forensic diagnosis declares the cause of death as natural and no murder hypothesis is put on the table. The man was healthy, without
record of health issues. However no other option is considered, and investigation finishes short after the occurence.

What about if I told you this world is the real world we are living in, and that this man in fact existed, and was called Stanley Meyer? You probably wouldn't believe the story, like many scientists don't and I personally am scheptical about believing it entirely. It's not because the world is sick (because it is) nor because brilliant inventors are persecuted until they give up on their findings (if there is an unofficial yet governamental inconvenience that the invention be successful, they are persecuted), or because this would be a brilliant solution to stop the pollution caused by oil (as it would), but because it seems a bit farfetched as with simple technology a single person would be capable of doing better then what years of research and development from the automotive industry haven't achieved. Without mentioning that this would be in violation of the laws of physics currently accepted.

However, giving the benefit of doubt and following the enthusiasm driven by the fact that quite a considerable amount of people claim to have already surpassed the laws of Faraday with their homebrew apparatus (by producing several times more hydrogen than would be expected from the energy that is put into the system), I decided to pick up the patent from Stanley Meyer, and attempt to build the device myself, in order to be able to see with my own eyes if there is a confirmation of this idea, or if instead this is no more than a hoax or product of a urban myth, grown in the mind of this complex person.

So here are a few images of the unfinished prototype, which include the control device, wich powers the electrolysis cell with a pulsed current (this includes variable frequency, duty cicle, and variable gate frequency and duty cycle), and a glass flask for single cell cell test run (the definitive design will be put inside a larger stainless steel container with a set of 6 cells, and capacity for a total of 9 cells):

Each cell is made of two stainless steel tubes (304 grade), arranged in a coaxial configuration where the inner tube (15 mm in diameter) and the outer tube (18 mm) and spaced by approximately 1 mm. This 1 mm thick region is where the electric field is formed, and where the water splitting process takes place.

Cell in activity:

Signal applied to the cell:

"Long-Haul" point-to-point WiFi links

2007-06-10T17:36:00.000-07:00

I start this blog with a great, not so new idea, that I decided to reimplement and see working with my own eyes. The principles behind it are not new at all and go back to the early days of RADAR technology (1930's), in a time where microwave radio research was taking place to improve the accuracy of this type of equipment. The need for guiding radio waves through a low loss medium and to be able to selectively pickup signals coming from a particular direction (in this case echoes from the emitted pulses) led to the design of different types of microwave antennas. These antennas had to be both compact (in order to fit into small airplane compartments) and efficient (output most of the signal from the transmitter in a particular direction and receive with exceptional gain the signal returning from that same direction).

At the time, these technologies were mostly closed under military secrecy, both because there was no justified civilian application for it and because of the war context in which these researches were taking place.

Later, microwave radio applications became widespread, both in civilian aviation, weather forecast, telecommunications and in the domestic life - microwave ovens. Necessarily most of the products of these early researches became public, including the antenna designs.

Today we are buried in microwave technology: ovens, satellite TV, GPS, GSM/UMTS/CDMA cell phones, DECT phones, garage door openers, Bluetooth, WLAN. All of these technologies have the particular feature of transmitting and/or receiving signals at small or very small radio wavelenghts - WLAN for example, transmits signals at a wavelength of about 12,4 cm. Comparatively the radio signal from an FM radio has a wavelength of 277.59 cm.

This means that a microwave antenna to be efficient doesn't have to be huge, like it would happen with FM radio antenna.

With microwaves, a moderately low power directed signal can travel a long distance and be detected at the other end with a compact antenna, as long as it is accurately pointed towards the emitting station. Thanks to this, a user with a satellite TV antenna can pickup a signal coming from a satellite 36000 km away that is transmitting only 70 watts of power (about as much as regular light bulb) with exceptional quality. Comparatively ground TV UHF transmitters require several hundreds of thousands of watts for a few hudreds of km of coverage (a moderately muscled car produces about 100 kw of power). So we could compare the costs of a UHF transmitting station with the fuel consumption of a few sports cars running together 24 h/day at top speed.

In spite of low energy consumption and very large signal coverage, transmission sattelites are of course, not cheap to deploy and maintain.

But, for us in our domestic endeavours, some things can come cheap in microwave technologies. WLAN is already common place everywhere, being a very convenient way of bringing network connectivity to computers and other devices, where mounting cables might be impractical and expensive. The performance of this type of LAN thechnology have also improved over time, so that in many cases is an interesting replacement to regular wired LAN technology.

Even though WLAN is very interesting as a local network technology, it becomes even more interesting if we take the challenge of making it a little less local. This is where the radio antenna principles from the 1930's come into place. Regular WLAN hardware, such as Access Points, Client adaptors, Routers and Repeaters all have small omnidirectional antennas with a gain rarely exceeding 2 dB. Most of these devices however, provide an RP-SMA plug, allowing the user to upgrade to a better antenna. But, by searching the market for alternate antennas, we see that these are in general expensive, sometimes too expensive for the expected benefit - for example a Linksys HGA7S with an announced gain of 7 dB, can cost up to 65 €. This is above the price of many AP's and client adapters.

The challenge I've decided to undertake was to build a much better solution for a much lower cost. This tourned out easier than otherwise expected.

Antenna design:

Based on this procedure, two equal waveguide antennas were built, using common materials. The total cost with materials did not exceed 30 €, and the resulting antenna set had an expected gain between 10 and 12 dB. A few objects such as the tripod and the tin cans were reused, representing a null cost. The most expensive parts were the alluminium foil and the coaxial connectors used. The RG-58 cable was not expensive but the choice was not optimal. LMR-200 cable would have been a better choice, as it features smaller insertion loss in the 2.4 GHz band. As the length of the cable is small (1 m) in this case the impact is not very substancial.

The "cantennas" were attached to a tripod from a telescope, even though a regular camera tripod could be used with this design (A 12 € tripod from a chinese store should do the trick):

Using small wood ribbons, four platforms were made in order to support the antennas and allow individual azimuth adjustment:

These were fixated simply with nuts, bolts and washers. Hot glue was used for the nuts that hold to the telescope tripod. If the antennas were to be attached to a regular camera tripod, the platform at the bottom could be discarded, as the nut would directly fit into the tripod screw.

Copper wire was used for fastening each can to each individual wooden support. Other materials can also be used as long as these provide adequate grip for the can.

The 31 mm antenna header as mounted in each antenna, soldered directly to the N-type connector. This value should be measured from the connector insulator to the top of the wire. It is best to cut the wire above the required length and after it is soldered to the connector the size be adjusted to the required 31 mm:

For improving the can performance, some aluminium foil was used to extend its length to 185 mm. Additionally alluminium funnels were added to each antenna. These provide about 3 dB extra gain to each one. Both the aluminium cillinders and funnels were hot glued to the cans:

In my prototype, I found convenient a Wireless Repeater. This model (an SMC WEBT-G) only had one RP-SMA connector, so I added a new one and removed the internal butterfly antenna:

The old 1.5 dB external antenna and the 2 dB butterfly antenna (the coaxial cable from the butterfly antenna was reused for the additional connector):

Experimental Results:

From the limited tests performed so far, the results seem exceptional from the point of view of a person who never played with antennas better than 2 dB of gain. Aiming the antena to a block of buildings roughly 200 m away with several obstacles in the path provided 45 % of signal strength for some of the AP's located at those buildings. Given the fact that there is no line of sight path between stations, it is quite a satisfactory achievement.

In a later iteration more tests are expected to be executed, including range tests in a line of sight path between two antennas of the same type. Other people having built this type of antenna have reported to achieve a link between stations 3 km apart, without any kind of amplification (just the 100 mW or less of output power from the AP/client adapter).

Future projects:

create a WiFi dish antenna with an expected gain of 30 dB, using an old satellite TV dish and a biquad antenna as the header;
modify the funnel antenna by adding parasite elements to further improve performance;
create a standalone biquad antenna and test its performance.