When trying to play a video I recieved the error “an error has occurred with the media player digikam” and on the terminal “xine is asking to seek behind the end of the data stream”

To resolve this I installed mplayer thumbs for the thumbnails and xine-ui to play the vids.

However not far into it I discovered a problem, and quite a big one at that!! Turns out there is a long standing bug and kinda makes Propel suck.

Time to try Doctrine then…

Very similar to Propel in what it does, but generates quite a different class structure. Auto complete does not work because of the ‘magic’ methods it defines, and the way it chains commands together confuses my IDE (and me) about which object has been returned after each successive command.

However, it handles the situation that Peopel failed at quite gracefully and looks like it is much more flexible and powerful when it comes to complex SQL.

Its just a shame I’m having to spend ages referring to the manual and searching Google when autocomplete would have instantly showed me the command I needed. Yet another mountain added to the learning curve, but despite that it looks like Doctrine wins for its bug free (so far) and powerful SQL methods.

A couple of resources I found:

http://redotheweb.com/2008/07/08/comparing-propel-doctrine-and-sfpropelfinder/

http://codeutopia.net/blog/2008/03/02/doctrine-vs-propel/

This seems to be the way to download and deploy symfony, and I’m sure I’m going to want to do it again so I took notes, here they are:

cd PROJECT DIR
mkdir -p lib/vendor
cd lib/vendor/
curl -O http://www.symfony-project.org/get/symfony-1.2.8.zip || wget http://www.symfony-project.org/get/symfony-1.2.8.zip
unzip symfony-1.2.8.zip
mv symfony-1.2.8 symfony
rm symfony-1.2.8.zip
cd ../..
php lib/vendor/symfony/data/bin/check_configuration.php
#nano /etc/php.ini

Thats pretty standard as far as I can tell, you may want to update the version numbers at some point and I’ve had to fall back to curl as my hosting company doesnt include wget. This first block can most likley be ran as a script to get symfony setup. The following blocks of commands will probably need a bit more thought and changing some paramaters and config files. There are here for me only as a cheat sheet really.

Next creating the project, frontend and configuring the database:

php lib/vendor/symfony/data/bin/symfony generate:project NAME
php symfony generate:app --escaping-strategy=on --csrf-secret=SECRET frontend
php symfony configure:database "mysql:host=localhost;dbname=DBNAME" DBUSER DBPASS
#edit schema or build it
php symfony propel:build-schema
#edit test data or dump it
php symfony propel:data-dump > data/fixtures/test.yml

Now to build everything + an app and a module

php symfony propel:build-all --no-confirmation
php symfony cache:clear
php symfony propel:data-load
php symfony propel:generate-module --with-show --non-verbose-templates APPNAME MODULE-NAME MODEL-NAME
php symfony propel:generate-admin APP MODEL-NAME --module=MODULE-NAME

I’ll also list any useful sites I come across while learning symfony

• Check if your symfony application is ready for deployment

dpkg -l | awk '/^rc/ {print $2}' | xargs sudo dpkg --purge

See the source article for an explanation of how it works.

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!