Throughout the project the main issue / limitation was down to the CPU. The Raspberry Pi runs on an ARM1176JZF-S30 (armv6k) 700 MHz Processor (which can dynamically increase up to 1 GHz). The software used to record video and audio from the webcam however, appeared to use most of the CPU when storing to the SD card
Snapshot of the top command when storing A snapshot (Figure 12) shows the ‘top’ command running on the Raspberry Pi. This shows the top CPU processes as well as other information such as the CPU % and the memory usage. Running the program recording the webcam stream to the SD card results in the CPU running at typically 100%, with only three processes running in this figure the CPU usage is at 100% (90.7% used on user mode and 9.3% used by system). FFMPEG is taking up 56.2% of that, it appears when ffmpeg is running using so much of the CPU it has issues recording both visual and audio data from the webcam, which results in an ALSA buffer xrun error being shown in the terminal. When streaming the webcam video over the network the ffmpeg appears to take up a fraction of the resources it is using for video and audio
Snapshot of the top command when streaming A snapshot (Figure 13) shows the top command again, this time it is similarly running at 100% CPU usage (98.1% by user and 1.9% by system), however this time the ffmpeg process appears to only be using a fraction of the CPU usage it was when storing to the SD card, reducing from 56.2% to 3.9%. It would appear attempting to capture visual and audio data using the Raspberry Pi will struggle due to the CPU and result in the ALSA buffer xrun errors, although it will still record with these during play back of the video file it will appear to skip a frame when each of the errors occurs.
Several other packages were tested such as MEncoder and guvcview, MEncoder attempts to do the same as ffmpeg does but similarly frame drops still occurred, a lower video quality was created, and had issues with the webcam used for this project. Guvcview appears more preferred for graphical interface rather than over a command line interface resulting in little use for this project. Removing audio from the data logging appeared to allow ffmpeg to run fine when storing it to the SD card. It would definitely appear that it is a limitation of the CPU, and appears to be attempting to record too much data which is causing random skipping of frames. Although the error exists the output file is not corrupt and still usable, at a cost of a few frames based on the length of the recording.
Similarly with the previous problem, when FFMPEG ends the streaming and storing it to the SD card it can take some time to finish encoding the audio, which resulted in the need to implement code to kill the previous process when starting a new process if it was still running. The time for encoding the audio is typically instant or a few seconds and can vary by the length of the video or the amount of audio information stored, however in some tests this was taking over ten minutes to fully encode and end the process. During which would not allow the user to start a new stream as the process is already running, implementation of this code will kill the previous ffmpeg process (meaning the audio in the file may be corrupt or not complete) and allow the new process to start. This could again be a limitation caused by the lack of processing power to allow the encoding of the file.
5Conclusion
5.1Conclusion
The goal of this project was to create a functional data logger using the Raspberry Pi, which would involve developing of software to make this possible. The data logger would allow the data to be stored locally as well as the possibility of it being sent across the network/internet. The project would make use of both USB and GPIO sensors to allow logging and allow control of the device through GPIO.
The author believes the goal has been met with this project, the final product is a functioning data logger allowing recording of temperature, optical data as well as streaming, storing and single image capture from the webcam. Users have the ability to control the device through the GPIO buttons and receive feedback on their actions via the GPIO LEDs.
The project includes the development of two items of software, an installer and the logger. This software allows a user to set up their own data logger, the logger allows remote access to control it or be controlled via buttons on the GPIO, this will run commands allowing the stream to start, method to change, and single image capture. The data logging makes use of the online service COSM to create real-time graphs using the sensor data. The user can make use of the user guides and installation guides created for this software to assist them in using it.
The project mainly went according to plan creating the data logger; however a few issues were encountered. Although the storing to SD card with audio does not work as intended due to the limitation, removal of audio would allow a fully functioning data logger with no errors caused by audio or CPU limitations. This project has successfully allowed for a low cost data logger to be produced with the ability to be used in the real world with various different uses and the ability to extend on the data loggers functionality such as portability and additional sensors.
5.2Future Work
The work done so far in this project has allowed for development of a functioning data logger however this can be extended in various areas to improve the data logger.
5.2.1Portability
The first major improvement would be portability; this was initially one of the planned goals for this project however due to time this was unable to be researched sufficiently and implemented, to extend the data logger to include portability this would involve the purchasing of a 5V regulated output external battery pack which is compatible with the Raspberry Pi, eLinux contains a list of verified peripherals which includes working external battery packs of which its users have tested and commented on28. TeckNet iEP392 Dual-Port 12,000 mAh External Power Bank appears to be the most favoured choice for external battery packs, with reported use of up to 16.5 hours before requiring a recharge, although this would be reduced due to the amount of power being used to stream/save webcam footage it would still allow quite a few hours of portable data logging which could be useful for outdoor trips. To allow portability it would also include purchasing a USB WiFi adapter to allow EEML to connect to COSM for graphing as well as network streaming if required, these typically require more power than a standard Raspberry Pi USB port provides so may be required to use an externally powered USB hub, alternatively the EW-7811Un from Edimax works without the need for an externally powered USB hub and should work with the webcam in one USB port and this adapter in the other, the EW-7811Un also appears to be the only WiFi adapter that is instantly recognized by the Raspbian Wheezy operating system (as of 2012-09-18 version) so should be a simple installation just editing the SSID and key29.
5.2.2Sensors
Another area for extension is sensors, although currently the Gertboard only has a two channel analogue to digital converter, this can be resolved by making use of MCP3004 or MCP3008 analogue to digital converters, allowing 4 channel and 8 channel respectively. This would allow for addition sensors (two to six) to be used with the data logger. Each sensor would simply need a new function to retrieve the data then make use of it (print it, store it then send it to COSM), there are various sensors available on the market such as sound, proximity, location/GPS, movement, touch, humidity, radiation, pressure, biometric, infrared, weather, and countless others. There are hundreds if not thousands of sensors available to implement onto the data logger which would increase the usefulness of the data logger as it has the ability to record even more relevant data than before, it would also increase the gap between this and any other data logger as they typically stick to very few different sensors.
5.2.3Audio feedback
The product can be extended to include some form of output possibly via audio feedback such as a buzzer, this could be used for various situations such as warnings to the user, for example if the temperature is very low, if the proximity to something is very close and the users speed is enough to impact, if there’s any errors with the program such as faulty sensor data. It would also be used to give audio feedback to button presses and an action taken, such as beginning to record rather than relying solely on the green and red LEDs, i.e. if the data logger is in a place that is hard to see the user may not know if they have successfully enabled recording or not without the ability to see the data logger.
5.2.4Recording software
Another improvement is the webcam recording software, currently the FFMPEG software makes use of the full CPU which in turn limits its ability to successfully record both visual and audio data in the case it is storing it to the SD card, this can cause an issue when recording from the webcam and in turn an error appears. The only similar software to this that’s Raspbian Wheezy / Raspberry Pi friendly appears to be MEncoder which has issues with the webcam used within this project, further research could be done into how to reduce the CPU load that ffmpeg requires to possibly fixing the issue, if it is possible.