The same principle applies as before, there is a magnet on the wheel that passes the sensor each revolution allowing the speed to be calculated. However the hall affect sensor is quite different from a reed switch. The reed switch is either on or off depending on whether it’s been activated by a magnetic field. The hall effect sensor gives an analogue output measuring the strength and polarity of a magnetic field. This required a rewrite of the software, including a calibration function, and I also added some goodies while I was there.

I used my strip board Arduino SD card writer for the main board for this project. I designed it with this project in mind so it already has three connectors to allow the hall effect sensor to be connected.

Calibration only needs to be done once, unless any of the hardware is changed or replace, and is performed by holding down the button whilst powering up the device. The magnet must be away from the sensor during this process. This takes a reading and stores the value to the ATmegas EEPROM. This is our baseline value, and as the wheel rotates and the magnet passes the sensor the current reading will stray from this baseline value, and we log the milliseconds taken since the last rotation to the memory card. There is a bit more maths and logic involved to try and reduce false readings, but I won’t go into details here.

If the card is not present or failed to initialise the LED will flash constantly signifying a problem. Once the system is initialised the LED will flash once every time the magnet passes the sensor, and will also be logging this information to the card.

Before the card is removed the button must be held down until the LED is constantly lit, this flushes (writes) any data that has not yet been written to the card, much like un-mounting/ejecting your USB stick or memory cards before removing them from the computer.

The other goodies I mentioned is a race and driver selector. Pressing the button will mark the end of the current race and the beginning of the next race. The number of times the button is pressed in succession indicates which driver will be racing next. When reading the data into the computer this allows the data to be split into separate graphs for each race and they can also labelled with who was racing. An example follows of the results of me testing this functionality…

The graphs have been omitted, but this data table would be accompanied by four graphs, one for each race.

Time for a road test….

I mounted the device to the car, wired it up and power it on, and it initialised fine. I had a spin up and down the road and came back, pressed the button to start a new race with another driver number and had another spin, I did this several times with various different driver numbers and then flushed the buffer to the card. I took the card out and put it in my computer expecting to see quite a few different race graphs. I was only shown two races and graphs, one looked a complete mess and the other didn’t really have much data on it at all. Here is the messy graph…

Not a lot of use, and I’m fairly sure it wasn’t doing 700 mph. After a bit of an investigation I found the cause was electromagnetic interference from the car’s motor or speed controller interfering with the readings from the sensor, also possibly interfering with the data being written to the card. I tried mounting the board in a grounded tin but that did not seem to help much. What seem to help most was moving the board away from the cars electronics and also twisting the hall effect sensors output signal wire with the ground wire. I also shortened the wires as much as possible.

Finally I got a sensible graph of me doing top speed, and here it is…

The points that look like they’re in the wrong place, being much lower than the points around them are because a reading is missed every time a sector is written to the SD card. I’m sure this anomaly can probably be hidden in the software somehow, but are not overly concerned with this at the moment.

Still a fair bit of work to do, but a definite improvement on the first version which was unable to measure my top speed. Occasionally I seem to get no, or random data on the card and also my average speed calculation is far from accurate, but all things that I think have relatively easy solutions.

I guess I need to find some other drivers now and we can do some time trials and compare results

I have made an SD card module for my Arduino before, so this is really about getting the ATmega chip powered up and running and interfacing to the module, for more information about the SD card project and the software involved see my SD card and Arduino post.

At this stage it is pretty generic, all that it consists of is a power supply (5 V regulator, protective diode and resettable fuse, and a couple of smoothing capacitors), a 16 MHz crystal with two capacitors, and the ATmega168 chip whith a 10 KΩ pull up resistor on the reset pin, I chose not to have a reset button but this could easily be added. This seems quite a nice layout and could be a good starting point for many different projects. Most of the chips Digital I/O pins are accessible, and so are all of the analogue input pins.

One thing the development board does give you is a USB port, allowing easy programming of the chip. To programme this chip I simply pop the chip out of its socket and place it back in the development board, upload the programme and then pop the chip back into my board.

Here I have added a pushbutton and LED with 330 Ω resistor to digital I/O pin zero and one respectively.  You pretty much always need some sort of input and output, these were very useful during debugging, and essential for communication between the running programme and the user. The pushbutton does not need a pull up resistor as the ATmega168 has internal pull up resistors that can and will be enabled in my code.  I have also added three connectors to allow external access to ground and 5 V, and also analogue input zero.

This next stage shows the connector to mount my SD card socket onto. It is actually half a chip socket that I have cut up, bent the pins slightly and tinned. There are also three voltage dividers used to drop the 5 V output logic from the ATmega down to the 3.3 V required for the SD card.

I ran into a bit of a problem at this point, in my haste to build this circuit and as I had also made an SD card module for my Arduino before I didn’t test this part when building the prototype. This was a big mistake! What I had done was used the same voltage divider method to drop the 5 V supply voltage down to 3.3 V to supply the SD card, however it turns out that this is not a good thing to do, it is fine for the logic but not the supply. The voltage isn’t particularly stable, as when the internal resistance of the card changes it upsets the ratio of the resistance in the divider.

After muttering some obscenities and returning to the prototyping board I found a 22 µF or greater capacitor across ground and 3.3 V helped slightly, allowing the MMC library to initialise, but failing at the second hurdle now with the microfat library failing to initialise.  I somehow needed a very stable 3.3 V supply. I didn’t really really want another voltage regulator on my circuit, then I remembered our good old friend the zener diode! Using a 3.3 V reverse biased zener as the lower side of the voltage divider and a smaller resistor above (47 Ω) I was able to achieve a steady voltage, and the card initialised perfectly.

So here it is now with the card holder and card attached, all working and tested. It is probably a bit hard to follow the wiring from the photographs, so I have also included schematic. This is a nice compact but minimal package, with a lot of the input pins available for reading data and a card to log that data to. I can imagine many uses for this, and there is even a little bit of space on the board for a fewer additional components should they be required.

I wanted it to wobble about in a random fashion, so I mounted it on a spring and attached the spring to a motor. I powered up both the laser and the motor and let the show begin! It wasn’t bad for the initial test, but before long it seemed to get into a repetitive loop drawing just a figure of eight or other mundane but curvy shapes.

To add some extra randomness to it I programmed the Arduino to randomly turn on and off the motor, which seemed to do the job quite nicely and is shown in the video above. It does not look as good on video as it does in real life, this is due to limitations caused by the relatively slow frame rate of the camera. Oh how I wish I could justify buying a high speed camera

The next step will be to make it a bit smoother, hopefully quieter, and get it displaying on a wall outside during the night. Stay tuned to see how that goes!

I was running my Arduino on battery, trying to prototype a simple vehicle, and after being distracted for some time came back to find a very flat battery, even though none of the motors were doing anything.

After recharging the battery, the first thing I did was grab my multimeter and measure how much current my circuit was drawing whilst in its idle state. It came in at about 45mA, and considering my battery only has a capacity of 170mAh, this gives an idle battery life of about 3.5 hours.

To reduce this current drain slightly, I found that by disabling the h-bridge that I was not using, by pulling the enable pin low, I could save on 15mA. As this is a dual h-bridge, if I disabled the other one I could save on another 15mA, but as this was the one I was using I had to wire that enable pin to an output of the Arduino, so it could enable it as and when it needed it.

This got the overall quiescent current down to about 15mA, which gives a much better battery life of about 11 hours, however I wondered how this would compare to my transistor h-bridge.

So for a quick test I rebuilt my transistor h-bridge, and measured the current drawn whilst it was doing nothing, and it barely registered, good enough to call 0mA.

So for battery-powered applications, the transistors may be preferable. I have looked at a couple of other motor driver chips, and they all seem to use a small quiescent supply current, one I saw used about half that of this chip.

I still had my hall effect controlled CD-ROM draw set up so I thought I would replace the four transistor h-bridge with the new chip, and be able to drive another motor at the same time. This second motor also came from a CD-ROM drive where I also found a two-way switch used to detect whether the draw was open or closed, I glued a bit of plastic to one of the cogs and attached the switch so that it would be activated by the piece of plastic allowing me to detect which way the motor was turning. I intended to change the direction of the motor when this happened to make it go back and forth.

The driving of the motors worked perfectly, however the fluctuating supply voltage caused by the starting and stopping of the motors interfered with the hall effect sensor.

I am fairly interested in solving this problem, but there are other things I want to be doing at the moment and I have dismantled the project. I did briefly try connecting the supply voltage directly to an analogue input, so I could detect a drop in the voltage and use this to compensate for the change in the hall effect input voltage, but this did not work. I also tried using  various capacities to smooth the supply, but again no luck as I think the fluctuations last for too long.

I am sure there will be a time when I run into this situation again but until then I am not going to worry, but feel free to propose a solution or make any suggestions and I may well give it a go.

The motor on its own worked reasonably well connected straight between an output pin and ground, however it wasn’t particularly powerful as the output pin can only source a limited current, and I could also only turn it in one direction, without physically swapping the cables over. After a bit of research and discovered what was required to control the DC motor in both directions, and this is called a h-bridge.

I found this this schematic for a basic h-bridge made from 4 transistors. The instructions seemed pretty specific as to what transistors to use, and also showed the use of 2 NPN and 2 PNP type transistors in the diagram. I can’t remember the difference between NPN and PNP, but I will be looking it up shortly, however I assumed the difference was big enough to require the use of both types to build an h-bridge.

I only had a few NPN transistors (BC109’s & BC107’s) available and decided to see if it would work using them, and it did, with very pleasing results. So it seems I got lucky, or it doesn’t really matter what sort of transistors you use! Please let me know if you know either way

An h-bridge is also available in IC form, surprisingly known as a motor driver or steper motor driver. I have ordered a L293D driver chip, that can either drive a single stepper motor, or act as a dual h-bridge and drive two DC motors.

Next I needed an input to use to decide when and in which direction to turn the motor, I decided to try out one of my new hall effect sensors and make the tray move in or out to maintain a set distance between the sensor and a magnet. The wiring of this was relatively simple, and is shown below. The Arduino code is slightly more complicated, and quite a mess at the moment to be honest, but it works. As always just give me a shout if you want to see a code behind it, hopefully I will have tidied it up a bit by then!

NOTE: I think I am probably missing some flyback diodes from this circuit, but I am unsure as to where exactly to fit them, and haven’t really given it much thought as nothing has blown up! (Not yet anyway!)

— EDIT —

Right, this article shows where the diodes should go, and also looks like an excellent introduction to h-bridges. I believe most driver IC chips would have the flyback diodes built in, so again the preferred solution should you have one to hand.

Here is the latest circuit with diodes included.

“What good is that?” I hear you say, “how are you going to read the speed when it’s going past you at 30 miles per hour!?”

Well I intend to log the speed to a SD card, so that it can be reviewed on a computer by the means of some pretty graphs and statistics. A display could be added to the car to show the maximum speed achieved or something, but I’m going to concentrate on logging to card to begin with.

My first thought was GPS, this would allow a top-down route to be plotted on a map, and also allow speeds to be calculated. The problem with this is that GPS has a resolution of about 10 metres, which means any stops, starts, curves and turns within 10 metres wouldn’t be picked up and speed calculation won’t be very accurate.

My second thought was to make a localised GPS using three or more transmitters around the race area to allow a receiver on the car to triangulate its position. This would also allow plotting of the route on a map. Although this doesn’t seem impossible it may be quite complicated and seemingly expensive. I will put this on the back burner and will hopefully revisit it soon.

My third thought (okay it was my first, but I skipped it to think about the other two methods) is to simply measure how fast one of the wheels turns round. As the car is a rear wheel drive I decided to use one of the front wheels as this would give a better indication of speed rather than measuring how fast I can burn rubber! I thought a reed switch and magnet would probably do the trick.

So there it is, a magnet mounted to the inside of the wheel, and a reed switch inside that big blob of blue tack. I connected the reed switch to the Arduino development board and also plugged in my SD card reader/writer that I made earlier. I was originally going to get the Arduino to do all the calculations and work out the speed to log to the memory card, but then I decided I would just log the milliseconds to the card each time the reed switch was activated.

My first test was just spinning the wheel by hand to see if it was all working, and this is the data I got back (after a bit of processing)

Beautiful

Probably not very well calibrated yet, I did measure the diameter of the wheel and do my best to get the calculations accurate, and this should be good enough for testing. Once I have a finished product I will calibrate more accurately.

Right then, time to get the show on the road, literally. I managed to get the Arduino, SD card writer, and prototyping board with an indicaor LED and start stop button on to the car, as well as a 9v battery, which I soon removed as I wired the Arduino straight to the car’s battery.

I drove around slowly in circles to begin with, everything seemed okay and nothing fell off so I thought I would knock it up a notch, I did flat out straight up the road, paused briefly and turned round, then did flat out straight back down the road. Then I went and did a few laps around a little triangle of trees at the end of the road. Here are the results…

All looks promising at first glance, but wait a minute, we never seem to get above 25 MPH, in fact those two peaks in the graph between 55 and 85 seconds where I went flat out up and down the road should be up somewhere between 30 and 40 MPH. On closer inspection it looks like above 25 MPH the reed switch fails to register every revolution of the wheel. I thought to begin with that at higher speeds the magnet might go past the reed switch too fast to activate it, but if this was the case you wouldn’t see any readings at all when I was above 25 MPH. It actually looks like the magnet has been passed to recently to be able to trigger the switch again, rather than is going past too fast to trigger it at all.

Perhaps some residual charge/field in the switch hasn’t depleted and is stopping it activating every other revolution at high speeds. Perhaps a lower or higher pull up resistor would help, or maybe pulling down would be better. I am just clutching at straws here, can you tell?

What I have discovered now is something called a hall effect sensor, which measures magnetic field and will give an analogue output rather than a simple on or off that the reed switch does. Also there is no moving parts and I think it is much more sensitive and probably reacts a lot quicker. Unfortunately I can’t source these from my local electronic shop and I’m having to place an order for them along with some other bits and bobs so it might take me a little while to get my order together.

I think this was quite a successful prototype and have great expectations for the hall effect sensors. I will be sure to post how that goes when I get them…. And here it is!

I found the pin outs to the SD card here, and a good schematic, along with the required libraries on this thread.

I could not get the raw read and write library to work, along with many others on the above thread. It looked like it was working, but after a reset there was no sign of the data on the card, So I tried the other library that was posted on that thread, uFat, which actually sounded much better as it allowed reading and writing to a file on the fat file system, which then could be read in my laptop or any computer with a card reader. This worked straight away, so I was happy to get my soldering iron out and wire it up permanently…

There is not much to it, the pins practically wire straight from the SD card into the Arduino, however the SD card runs on 3.3v and the outputs from the Arduino are 5v, not a problem with a few resisters 5v can be dropped down to 3.3v. I got the card slot out of an old card reader, attached pins to it from the headers of an old motherboard, and the strip board I just had laying around with junk soldered to it which I just removed.

Another quick test and something didn’t seem quite right, it would only work once between reset, so I got my multimeter and checked all my connections, everything seemed fine, I gave a bit of a scrape between the strips of the strip board and tried again, this time it worked perfectly. I guess there must have been a strand of wire or solder where there shouldn’t have!

Time to hide that ugly strip board, and soldering…

And there it is, a nice little module that I can plug in whenever I need it