Wednesday, May 22, 2013

LCD character screen and photo resolution

It seems every day that my list of issues on my google code issue tracker are always increasing, or at least never decreasing. But I got a few knocked off or at least reduced in severity over the last couple days.

To reduce power consumption I used my DMM to study which parts of the system used the most power, and to validate the power savings mode on the camera. What I found:

  • Entire system was using 280 mA at the start of my fixes.
  • The power LED was using almost 13 mA, so replacing the resistor in series with the LED brought that down to 3 mA. Further savings might be made by flashing the LED instead.
  • The IR LEDs were always on, using about 140 mA of power. I replaced the photocell with a 1K resistor which made the system think it was always light, and turned the IR LEDs permanently off.
  • The power savings mode was not initially working, but a delay in the code fixed that. During power savings, the camera uses 50 mA, and during normal mode it uses 70 mA. 
  • The XBee uses 70 mA. There is some sort of cyclic power savings mode that might be applicable for my application, but the effort in implementing it does not yet justify it. 
Overall I managed to reduce my power consumption to about 40% of its original, which should extend the battery life nicely. 

Another feature I wanted to implement is a higher resolution photo mode. This was actually quite trivial, and just consisted of another command sent to the camera during startup. However I had a small bug to sort out: the files became longer than 2^16 bytes, meaning I could not use a 'word' to store the location of file I was currently reading. 

Adding an 16x2 LCD character screen was also remarkably easy with the LiquidCrystal library. The sample code was easy to implement, and now I can operate my camera basestation without needing a computer which is a huge bonus. The LCD character screen takes care of providing user feedback and indicating which photo is currently being captured, and how long is left in the transferring process.

Later I will add a couple photos and video of the system in action: I turned a couple plant pots around and I'm hoping to capture the plants turning back towards the sun over the course of the day. It will be a good test of how the battery is holding up as well.

Sunday, May 19, 2013

Issue trackers and Arduino serial buffer sizes

This week I started using the issue tracker that came with Google Code, and I really like it. Its a much better way of keeping track of my outstanding tasks than my whiteboard or keeping them in my head.

One of the main issues I identified was extending the battery life of the wireless unit. Currently I can take about 300 photos, which at 30 FPS means 10 seconds of time lapse video. Not great. I thought of a couple ideas that could help me here:

  1. Power savings mode when the camera is waiting between frames
  2. Faster data transmission so the camera is in power savings mode for longer
  3. Hardware modifications like disabling the IR LEDs

Power savings mode was fairly trivial to implement, it was just 2 commands I sent over serial to turn on or off the camera's power savings mode. Next I worked on the transmission speed. My first thought was to decrease the "interval time", or time between successive frames, but this started causing data transmission errors. So instead I worked on increasing the buffer size, so that more data was transmitted at once. However, the microcontroller only appears to have a serial buffer of 64 bytes, so when I tried to get more data than 56 bytes per frame, I was running into problems (due to the 5 extra bytes before the frame starts). What I ended up doing was removing the delays in my code, and implementing a loop to poll the receive buffer. In case of transmission errors, I also added a timeout, and flag that was set upon an unexpected frame size, which caused the erroneous frame to be resent. At the end, it was something like this:


// loop continuously until the data is ready
while(!Serial.available()){
  delay(1);   // 1 ms delay
  timeout++; // timeout counter
  if (timeout > TIMEOUT_MAX){ // if 1000 ms pass before data received, assume erroneous data
    i = 5;  // satisfy exit condition
    ResendFlag = 1;  // ensure data is resent since erroneous
    break;
  }
}
// if we get here, data is available so process it


This had some pretty good results, my transmit time was reduced by almost half. Now I'm running an endurance test to see if it actually improves my power consumption, and if so by how much.


Friday, May 17, 2013

A summary of progress and next steps

Over the last week or so I've made some pretty good progress on the time lapse camera. From a fully charged device, I can shoot a 327 frame video (see below), which lasts about 14 seconds.



After the break I'll summarize progress so far, as well as the next steps I plan on doing. My philosophy is to finish each section completely before moving onto a new task, limiting the complexity of potential bugs and problems.

Wednesday, May 15, 2013

Box for the outdoor unit

Bought a plastic box today at one of my local retailers and turned it into a custom case for my outdoor unit. This version isn't waterproof (a quick google search told me it would take some more in-depth engineering than I wanted to do for my first version), but it is a great proof-of-concept.



I cut holes in the plastic using a dremel tool. Most of the holes were in a removable side panel, making things easy, though the hold for the camera was in the box top. I learned a few lessons: when I routed the hole for the battery charging cable, I didn't think of how I would mount the circuit board and connector to the side-panel. In the end I found a piece of wood that was the right thickness to fit between the box and circuit, and used to 8-32 bolts to hold everything in place. Definitely will need a better solution for a water-proof model, as these are 2 unnecessary holes in the case. The rest of the build was quite straightforward, and took around 3 hours. After the break are some more photos and details.

Tuesday, May 14, 2013

Code Updates and a Time Lapse Video

Got my first time lapse video captured and online. Images were transmitted wirelessly using XBee radios from the battery-powered unit to the Arduino basestation. I copied the files to my computer, and converted them to jpg files using the converter in the code repository. Then, using Time Lapse Assembler, I made the 100 images into a 7 second movie at 15 FPS. The video is shown below:



Next steps will be on the hardware side:

  1. Making a waterproof case for the unit that properly secures all the wires
  2. Adding a potentiometer and LCD screen for some user controls and feedback over operation