I have flashed another Debian Wheezy image on my BBB. It comes with
preinstalled opencv (version 2.3.1) but with very old cv bindings. I posted
this in googlegroups as a solution which i mention or i dont see as a
solution because i just avoided the problem. I am able to stream a video
with both cameras. Whichever resolution i set the Logitech camera to, it
converts to the one shown below;
root@beaglebone:~/Project/py_servo_facetracker# v4l2-ctl -V
Format Video Capture:
Width/Height : 160/120
Pixel Format : 'YUYV'
Field : None
Bytes per Line: 320
Size Image : 38400
Colorspace : SRGB
root@beaglebone:~/Project/py_servo_facetracker#
The other webcam is set to a 1280x720 resolution with the pixel format set
as YUYV.
I am suspecting it has something to do with the opencv itself when it grabs
frames from the webcam. Is there a way i can set opencv to maintain the
camera resolution i set it to?
On Wed, May 25, 2016 at 5:51 PM, Tinashe Mudavanhu <[email protected]>
wrote:
> Silva,
>
> There has to be way. Dereck Molloy
> https://www.youtube.com/watch?v=8QouvYMfmQo was able to get a video
> stream then its possible to video stream with BBB. I don't have much time
> to look for another development board because the Project is due next week.
>
> On Wed, May 25, 2016 at 5:48 PM, Tinashe Mudavanhu <[email protected]>
> wrote:
>
>> Hi,
>>
>> The same is happening on the other webcam i have (not sure if its openCV
>> changing resolution). I bought it on AliExpress and has the following
>> discription; HD 1.3 megapixel 960p 2.8-12mm varifocal lens Aptina AR0130
>> android external usb camera module with IR cut ELP-USB130W01MT-FV
>> <http://www.aliexpress.com/item/HD-1-3-megapixel-2-8-12mm-varifocal-lens-android-external-usb-camera-module-with-IR/32295825258.html>.
>> The supplier can be found on http://www.elpcctv.com.
>>
>> Since there are no errors, what could be the problem? Is there some
>> dependencies i have to install?
>>
>> I tested with your framebrabber.c code and was getting this (see below)
>> with the Logitech webcam,
>>
>> root@beaglebone:~# time ./framegrabber -f mjpeg -H 480 -W 640 -c 1000 -I
>> 30
>> Startup took 0.010000 seconds
>> Captured 1000 frames in 0.220000 seconds
>> Shutdown took 0.000000 seconds
>>
>>
>> real 0m42.068s
>> user 0m0.025s
>> sys 0m0.223s
>>
>> The no name webcam was giving the following results;
>> root@beaglebone:~# time ./framegrabber -f mjpeg -H 480 -W 640 -c 1000 -I
>> 30
>> Startup took 0.020000 seconds
>> Captured 1000 frames in 0.260000 seconds
>> Shutdown took 0.000000 seconds
>>
>>
>> real 2m10.965s
>> user 0m0.033s
>> sys 0m0.262s
>> root@beaglebone:~#
>>
>>
>>
>> On Wed, May 25, 2016 at 5:23 PM, Matthew Witherwax <[email protected]>
>> wrote:
>>
>>> There are no actual errors in the output you posted.
>>>
>>> Do you have access to any other webcams? I have tested this with the
>>> Logitech C920, the Logitech C270, and the PS3Eye. Without access to your
>>> webcam, it is hard for me to look into what is going on.
>>>
>>>
>>> On Wednesday, May 25, 2016 at 8:57:55 AM UTC-5, Tinashe Mudavanhu wrote:
>>>
>>>> The timeout error resurfaced again, i followed you blog post on
>>>> http://blog.lemoneerlabs.com/3rdParty/Darling_BBB_30fps_DRAFT.html but
>>>> got the following errors in compiling libjpeg-turbo ;
>>>>
>>>> root@beaglebone:~/libjpeg-turbo-1.3.0/build# make
>>>> make all-recursive
>>>> make[1]: Entering directory `/root/libjpeg-turbo-1.3.0/build'
>>>> Making all in java
>>>> make[2]: Entering directory `/root/libjpeg-turbo-1.3.0/build/java'
>>>> make[2]: Nothing to be done for `all'.
>>>> make[2]: Leaving directory `/root/libjpeg-turbo-1.3.0/build/java'
>>>> Making all in simd
>>>> make[2]: Entering directory `/root/libjpeg-turbo-1.3.0/build/simd'
>>>> make all-am
>>>> make[3]: Entering directory `/root/libjpeg-turbo-1.3.0/build/simd'
>>>> make[3]: Nothing to be done for `all-am'.
>>>> make[3]: Leaving directory `/root/libjpeg-turbo-1.3.0/build/simd'
>>>> make[2]: Leaving directory `/root/libjpeg-turbo-1.3.0/build/simd'
>>>> Making all in md5
>>>> make[2]: Entering directory `/root/libjpeg-turbo-1.3.0/build/md5'
>>>> make[2]: Nothing to be done for `all'.
>>>> make[2]: Leaving directory `/root/libjpeg-turbo-1.3.0/build/md5'
>>>> make[2]: Entering directory `/root/libjpeg-turbo-1.3.0/build'
>>>> make[2]: Leaving directory `/root/libjpeg-turbo-1.3.0/build'
>>>> make[1]: Leaving directory `/root/libjpeg-turbo-1.3.0/build'
>>>> root@beaglebone:~/libjpeg-turbo-1.3.0/build#
>>>>
>>>>
>>>> Before compiling libjpeg-turbo i tested my code to see what will be
>>>> happening on the resolution and frame rate. I am working with a Logitech
>>>> QuickCam E3500 which has support for both YUVY and MJPEG. I set the
>>>> resolution to 320x240 with a 30fps frame rate but after running the code,
>>>> got select timeout errors and the resolution had changed to 640x480 YUVY
>>>> with a 15fps frame rate;
>>>>
>>>> root@beaglebone:~/libjpeg-turbo-1.3.0/build# v4l2-ctl -V
>>>> Format Video Capture:
>>>> Width/Height : 640/480
>>>> Pixel Format : 'YUYV'
>>>> Field : None
>>>> Bytes per Line: 1280
>>>> Size Image : 614400
>>>> Colorspace : SRGB
>>>> root@beaglebone:~/libjpeg-turbo-1.3.0/build#
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, May 24, 2016 at 1:22 AM, Tinashe Mudavanhu <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Matthew,
>>>>>
>>>>> I'm a rookie in this linux/opencv area i wouldn't really know what it
>>>>> means, only learning from you. I posted a question
>>>>> https://groups.google.com/forum/#!category-topic/beagleboard/debian/VFuvveM_8Gc
>>>>> looking for a solution because it always happened when i plugged in the
>>>>> webcam on BBB. Running the command i previously mentioned ended my woes.
>>>>>
>>>>> On Tue, May 24, 2016 at 1:04 AM, Matthew Witherwax <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> The issue causing the select time out detailed in my article has to
>>>>>> do with how much data is being sent over the USB and how it is sent.
>>>>>> Reducing the frame rate reduces the load on the USB. Looking at the
>>>>>> articles you linked, one says it solved an issue but not the select
>>>>>> timeout, and the other shows an error message that says it could not
>>>>>> allocate memory. Neither one of these are the cause of the select
>>>>>> timeout
>>>>>> I addressed.
>>>>>>
>>>>>> The select timeout occurs when the select times out. Looks like in
>>>>>> the cases in your links a previous call to allocate memory failed
>>>>>> followed
>>>>>> by select failing. I have never had an issue with memory allocation. All
>>>>>> my
>>>>>> troubles had to do with too much data on the USB. You might want to
>>>>>> confirm
>>>>>> what your actual problem is.
>>>>>> ------------------------------
>>>>>> From: Tinashe Mudavanhu
>>>>>> Sent: 5/23/2016 4:58 PM
>>>>>> To: [email protected]
>>>>>> Subject: Re: [beagleboard] Re: VGA camera capture
>>>>>>
>>>>>> Hi Matthew,
>>>>>>
>>>>>> I looked into the article as i went through your discussion but did
>>>>>> not try the framegrabber.c, will test it though. I finally got a solution
>>>>>> to the problem from links listed below. It kind of made sense to me (lack
>>>>>> of memory in ARM systems) because running the same code on my PC worked
>>>>>> perfectly well. Running this command `sysctl vm.overcommit_memory=1`
>>>>>> worked
>>>>>> for me after a long struggle. What i'm not really sure are the
>>>>>> implications
>>>>>> (being it on Hardware or Software) if there comes a state when large size
>>>>>> memory is really needed.
>>>>>>
>>>>>>
>>>>>> [1]: https://www.raspberrypi.org/forums/viewtopic.php?f=31&t=17773
>>>>>> [2]:
>>>>>> https://tequals0.wordpress.com/2014/03/24/libv4l2-error-allocation-conversion-buffer-using-opencv-on-a-pi/
>>>>>>
>>>>>> On Mon, May 23, 2016 at 10:25 PM, Matthew Witherwax <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Hi Tinashe,
>>>>>>>
>>>>>>> Please see my article here
>>>>>>> http://blog.lemoneerlabs.com/post/BBB-webcams
>>>>>>> There is a version of framegrabber.c linked to it that allows you to
>>>>>>> specify the frame rate with the command line parameter -I. If reducing
>>>>>>> the
>>>>>>> frame rate works for you, then the code for framegrabber should provide
>>>>>>> a
>>>>>>> starting point for accomplishing the same thing in your own program.
>>>>>>>
>>>>>>> On Mon, May 23, 2016 at 2:43 PM, Tinashe Mudavanhu <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Firstly i would like to say i came across your discussion looking
>>>>>>>> for select timeout error solution but as i went through it i didnt
>>>>>>>> notice
>>>>>>>> if you found a solution, but if you have it now, i would appreciate
>>>>>>>> it. The
>>>>>>>> select timeout error still seems to be in existence even on BBB Rev C
>>>>>>>> with
>>>>>>>> kernel 3.8.13-bone79. I am working on an Iris recognition system that
>>>>>>>> initially has to track eyes in a live video stream (from there captures
>>>>>>>> cropped eye images that will be processed). I have installed different
>>>>>>>> OpenCV versions, 2.4.9, 2.4.11 and 3.0.0 and in all of them i am
>>>>>>>> getting
>>>>>>>> the same error. I am working with a Logitech, Inc. QuickCam E 3500
>>>>>>>> webcam.
>>>>>>>> I am accessing the BBB Desktop using Tightvnc client on my PC running
>>>>>>>> Ubuntu 14.04 LTS.
>>>>>>>>
>>>>>>>> What is surprising is that it is capable of video streaming with
>>>>>>>> opencv installed by apt-get (apt-get install python-opencv) but the
>>>>>>>> limitation with this version is that it has very old cv bindings and
>>>>>>>> documentation on some functions for Histogram equalisation is not
>>>>>>>> available
>>>>>>>> online. I am stuck, i need your help.
>>>>>>>>
>>>>>>>> On Tuesday, 10 September 2013 16:50:46 UTC+2, Matthew Witherwax
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Getting another BBB or raspberry pi probably wont help, but a U2
>>>>>>>>> from HardKernel here
>>>>>>>>> http://www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G135341370451
>>>>>>>>> probably would. You can use the BBB to do all IO and use the
>>>>>>>>> processing
>>>>>>>>> power of the U2 to handle compute intensive tasks. That is actually
>>>>>>>>> my end
>>>>>>>>> goal. The cpu use I stated earlier was without showing the image.
>>>>>>>>> Displaying the image will increase cpu use.
>>>>>>>>>
>>>>>>>>> I am also working on a tracking application with the webcam
>>>>>>>>> mounted on a servo. For my purposes, I do not need to see the image
>>>>>>>>> on the
>>>>>>>>> BBB and can push it over wifi to my laptop if I want to view it.
>>>>>>>>>
>>>>>>>>> As far as cv code, what are you looking for? I have posted a tool
>>>>>>>>> on my blog here http://blog.lemoneerlabs.com/post/shades-of-red
>>>>>>>>> to help you find HSV values from images to allow you to to find
>>>>>>>>> values to
>>>>>>>>> threshold target colors. I will post another one on using HSV ranges
>>>>>>>>> to
>>>>>>>>> threshold an image to isolate things like a red colored ball. I have
>>>>>>>>> been
>>>>>>>>> implementing OpenCV code using python right now for experimentation,
>>>>>>>>> but
>>>>>>>>> you should be able to translate it to C++ or your language of choice.
>>>>>>>>>
>>>>>>>>> The command v4l2-ctl --list-formats-ext will tell you the pixel
>>>>>>>>> formats and resolutions supported by your camera.
>>>>>>>>>
>>>>>>>>> Hope this helps,
>>>>>>>>>
>>>>>>>>> Matthew Witherwax
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Sep 10, 2013 at 8:48 AM, James Richins <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> Matthew,
>>>>>>>>>>
>>>>>>>>>> It does remind of something on Derek Molloy's site in that he
>>>>>>>>>> adds coding to deal with the h264 codec for taking stills with
>>>>>>>>>> opencv. I
>>>>>>>>>> hesitated at the idea. Interestingly even using an additional bbb or
>>>>>>>>>> raspberry pi might not even help. I'm looking at camera tracking
>>>>>>>>>> objects/object recognition and servo control.
>>>>>>>>>> I might find that by not displaying the video on the monitor,
>>>>>>>>>> that the tracking and servo control can work less than 100% CPU.
>>>>>>>>>> I have yet to implement the cv code for that, it's a real
>>>>>>>>>> struggle to find good code. And not get errors. I have managed servo
>>>>>>>>>> control through python and manual entering numbers so its ultimately
>>>>>>>>>> possible.
>>>>>>>>>> I'm not sure if my camera does anything other than yuyv. I'd be
>>>>>>>>>> interested in connecting an Ethernet cam to the Ethernet port and
>>>>>>>>>> read
>>>>>>>>>> camera data from there, but you'd probably run into the same problem.
>>>>>>>>>> Ethernet cam to pc processing cv code, wifi to beaglebone servo
>>>>>>>>>> control
>>>>>>>>>> might be good. But its probably a slow process and too complicated
>>>>>>>>>> for me.
>>>>>>>>>>
>>>>>>>>>> Anyway good luck with your project.
>>>>>>>>>>
>>>>>>>>>> James
>>>>>>>>>>
>>>>>>>>>> On 10 Sep 2013, at 13:57, Matthew Witherwax <[email protected]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> James,
>>>>>>>>>>
>>>>>>>>>> I have not done any cpu testing other than while saving single
>>>>>>>>>> frames. In MJPEG format, capturing a single frame at 1920x1080 30
>>>>>>>>>> fps and
>>>>>>>>>> saving it was taking about 6% cpu. Doing the same in YUYV at a
>>>>>>>>>> reduced
>>>>>>>>>> resolution and converting to jpeg was taking about 70%. I would not
>>>>>>>>>> rush
>>>>>>>>>> out to buy a h264 camera. First, I am not sure OpenCV decodes h264
>>>>>>>>>> streams. Second, if it did, I am not sure you would see much
>>>>>>>>>> improvement
>>>>>>>>>> because of the need to decode the h264 stream. If the BBB does this
>>>>>>>>>> in
>>>>>>>>>> hardware is likely wont be bad, but if it is a software
>>>>>>>>>> implementation we
>>>>>>>>>> are just shifting the burden. I am currently working through several
>>>>>>>>>> tradeoffs. YUYV should give the truest image free of compression
>>>>>>>>>> artifacts, but will be larger and require more resources to capture
>>>>>>>>>> and
>>>>>>>>>> process. MJPEG may suffer from compression artifacts, but images
>>>>>>>>>> can be
>>>>>>>>>> captured more quickly and at higher resolutions. One has to decide
>>>>>>>>>> what
>>>>>>>>>> combination of frame rate, resolution, and fidelity are required. I
>>>>>>>>>> am
>>>>>>>>>> currently working through the permutations to see what suits my
>>>>>>>>>> application.
>>>>>>>>>>
>>>>>>>>>> An option I have open is to send the captured images over a wifi
>>>>>>>>>> link to a computer that runs all the OpenCV code and pipes back the
>>>>>>>>>> data I
>>>>>>>>>> am after. This leaves the BBB mostly free to do other work. I will
>>>>>>>>>> update
>>>>>>>>>> as I progress.
>>>>>>>>>>
>>>>>>>>>> Matthew Witherwax
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Sep 10, 2013 at 7:35 AM, James Richins <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Did you register anything on CPU usage. I know running moustache
>>>>>>>>>>> placing cv code it will run at 100% CPU on a standard webcam. Is pre
>>>>>>>>>>> processing less cpu intensive or will cv code always push the bb to
>>>>>>>>>>> the max?
>>>>>>>>>>> I didn't think I'd rush to buy a h264 hardware encoding cam if
>>>>>>>>>>> its the software and running at 320 is just as efficient as
>>>>>>>>>>> preencoded hd
>>>>>>>>>>> video.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 10 Sep 2013, at 13:16, Matthew Witherwax <[email protected]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> João,
>>>>>>>>>>>
>>>>>>>>>>> 1. Glad to hear you are making progress. My blog is at
>>>>>>>>>>> blog.lemoneerlabs.com. Unfortunately I have yet to post my
>>>>>>>>>>> write up on the USB cameras, but I will get it done soon. I can
>>>>>>>>>>> tell you
>>>>>>>>>>> with the Logitech C920 it is possible to capture 1920x1080 frames
>>>>>>>>>>> with the
>>>>>>>>>>> FPS set to 30 in both MJPEG and YUYV format.
>>>>>>>>>>>
>>>>>>>>>>> 2. v4l2grab sets the format to YUYV before grabbing the
>>>>>>>>>>> frames. It then converts the captured frame to a jpeg and saves
>>>>>>>>>>> it. I
>>>>>>>>>>> will post a version to my blog this week that uses MJPEG instead.
>>>>>>>>>>> Typical
>>>>>>>>>>> MJPEG implementations encode each video frame as a jpeg. The code
>>>>>>>>>>> I wrote
>>>>>>>>>>> puts the webcam in MJPEG mode for capture and saves the returned
>>>>>>>>>>> frame. In
>>>>>>>>>>> the case of the Logitech C920, the returned frame is a jpeg image.
>>>>>>>>>>> It
>>>>>>>>>>> seems by going this route the camera actually creates the jpeg
>>>>>>>>>>> sparing the
>>>>>>>>>>> BBB from having to do it. In addition, the jpeg is considerably
>>>>>>>>>>> smaller
>>>>>>>>>>> than the YUYV frame resulting in less load on the USB. I would
>>>>>>>>>>> appreciate
>>>>>>>>>>> you testing the output when I post the code as it is entirely
>>>>>>>>>>> possible that
>>>>>>>>>>> not all cameras handle MJPG the same, and the result might not be a
>>>>>>>>>>> valid
>>>>>>>>>>> jpeg.
>>>>>>>>>>>
>>>>>>>>>>> 3. 13.2 MB/s is the limit I was able to reach through testing.
>>>>>>>>>>> You should note the webcam I tested with for that number only did
>>>>>>>>>>> bulk
>>>>>>>>>>> transfers which guarantee delivery. It may be slightly higher for
>>>>>>>>>>> isochronous transfers as frames can (and seem to) get dropped. I
>>>>>>>>>>> am not
>>>>>>>>>>> sure why that is the limit. It maybe a hardware issue or a USB
>>>>>>>>>>> driver
>>>>>>>>>>> implementation issue. During further testing on several laptops,
>>>>>>>>>>> the newer
>>>>>>>>>>> ones could reach a higher throughput even though all had a USB 2
>>>>>>>>>>> bus which
>>>>>>>>>>> would lead me to believe it is hardware related, but it is a
>>>>>>>>>>> question for
>>>>>>>>>>> the hardware guys.
>>>>>>>>>>>
>>>>>>>>>>> 4. I will post my code this week. Please test it with your
>>>>>>>>>>> MJPEG capable cameras, and let me know the results.
>>>>>>>>>>>
>>>>>>>>>>> 5. The UVC implementation in Linux does not support still image
>>>>>>>>>>> capture. This means tools like v4l2grab set the camera to record
>>>>>>>>>>> in a mode
>>>>>>>>>>> that uses no compression or intra-frame compression (
>>>>>>>>>>> http://en.wikipedia.org/wiki/Intra-frame) and then grab frames
>>>>>>>>>>> from the stream. This is why the format and frame rate affect the
>>>>>>>>>>> capture. The stream has to be open and the data pulled before we
>>>>>>>>>>> can grab
>>>>>>>>>>> an image.
>>>>>>>>>>>
>>>>>>>>>>> 6. Possibly, see 3.
>>>>>>>>>>>
>>>>>>>>>>> 7. For my purposes, I have not tested plug-and-play so I cannot
>>>>>>>>>>> say much about it.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Sep 9, 2013 at 1:15 PM, João M. S. Silva <
>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Thanks Matthew, Don.
>>>>>>>>>>>>
>>>>>>>>>>>> Here is my follow up:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Matthew, what is you blog address?
>>>>>>>>>>>>
>>>>>>>>>>>> 2. I compiled v4l2grab and used the -I switch to adjust the
>>>>>>>>>>>> fps. I found out that with the Logitech camera I can capture
>>>>>>>>>>>> 640x480 at up
>>>>>>>>>>>> to 6 fps. With -I 7 or above, it hangs. With another cheap camera,
>>>>>>>>>>>> even -I
>>>>>>>>>>>> 1 hangs!
>>>>>>>>>>>>
>>>>>>>>>>>> 3. Is 13.2 MB/s somehow BBB's limit? Why?
>>>>>>>>>>>>
>>>>>>>>>>>> 4. My cheap cameras are YUYV capable and one of them is MJPEG
>>>>>>>>>>>> capable. The Logitech is both YUYV and MJPEG capable.
>>>>>>>>>>>>
>>>>>>>>>>>> 5. As I've read elsewhere UVC does not allow to get still
>>>>>>>>>>>> images, so video performance issues affect still image capturing,
>>>>>>>>>>>> right? is
>>>>>>>>>>>> there a way to capture pure still images (bandwidth limitations
>>>>>>>>>>>> should be
>>>>>>>>>>>> irrelevant in that case)?
>>>>>>>>>>>>
>>>>>>>>>>>> 6. Overall, this is an issue from the BBB, right? All of this
>>>>>>>>>>>> works in my laptop and in BBXM. Is it a bug from the BBB USB
>>>>>>>>>>>> implementation?
>>>>>>>>>>>>
>>>>>>>>>>>> 7. I also found BBB's USB is not really plug-and-play.
>>>>>>>>>>>> Sometimes devices don't get recognized and a reboot is needed.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> For more options, visit http://beagleboard.org/discuss
>>>>>>>>>>>> ---
>>>>>>>>>>>> You received this message because you are subscribed to a topic
>>>>>>>>>>>> in the Google Groups "BeagleBoard" group.
>>>>>>>>>>>> To unsubscribe from this topic, visit
>>>>>>>>>>>> https://groups.google.com/d/topic/beagleboard/2NO62mGcSvA/unsubscribe
>>>>>>>>>>>> .
>>>>>>>>>>>> To unsubscribe from this group and all its topics, send an
>>>>>>>>>>>> email to [email protected].
>>>>>>>>>>>> For more options, visit
>>>>>>>>>>>> https://groups.google.com/groups/opt_out.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> For more options, visit http://beagleboard.org/discuss
>>>>>>>>>>> ---
>>>>>>>>>>> You received this message because you are subscribed to a topic
>>>>>>>>>>> in the Google Groups "BeagleBoard" group.
>>>>>>>>>>> To unsubscribe from this topic, visit
>>>>>>>>>>> https://groups.google.com/d/topic/beagleboard/2NO62mGcSvA/unsubscribe
>>>>>>>>>>> .
>>>>>>>>>>> To unsubscribe from this group and all its topics, send an email
>>>>>>>>>>> to [email protected].
>>>>>>>>>>> For more options, visit https://groups.google.com/groups/opt_out
>>>>>>>>>>> .
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> For more options, visit http://beagleboard.org/discuss
>>>>>>>>>>> ---
>>>>>>>>>>> You received this message because you are subscribed to a topic
>>>>>>>>>>> in the Google Groups "BeagleBoard" group.
>>>>>>>>>>> To unsubscribe from this topic, visit
>>>>>>>>>>> https://groups.google.com/d/topic/beagleboard/2NO62mGcSvA/unsubscribe
>>>>>>>>>>> .
>>>>>>>>>>> To unsubscribe from this group and all its topics, send an email
>>>>>>>>>>> to [email protected].
>>>>>>>>>>> For more options, visit https://groups.google.com/groups/opt_out
>>>>>>>>>>> .
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> For more options, visit http://beagleboard.org/discuss
>>>>>>>>>> ---
>>>>>>>>>> You received this message because you are subscribed to a topic
>>>>>>>>>> in the Google Groups "BeagleBoard" group.
>>>>>>>>>> To unsubscribe from this topic, visit
>>>>>>>>>> https://groups.google.com/d/topic/beagleboard/2NO62mGcSvA/unsubscribe
>>>>>>>>>> .
>>>>>>>>>> To unsubscribe from this group and all its topics, send an email
>>>>>>>>>> to [email protected].
>>>>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> For more options, visit http://beagleboard.org/discuss
>>>>>>>>>> ---
>>>>>>>>>> You received this message because you are subscribed to a topic
>>>>>>>>>> in the Google Groups "BeagleBoard" group.
>>>>>>>>>> To unsubscribe from this topic, visit
>>>>>>>>>> https://groups.google.com/d/topic/beagleboard/2NO62mGcSvA/unsubscribe
>>>>>>>>>> .
>>>>>>>>>> To unsubscribe from this group and all its topics, send an email
>>>>>>>>>> to [email protected].
>>>>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>> For more options, visit http://beagleboard.org/discuss
>>>>>>>> ---
>>>>>>>> You received this message because you are subscribed to a topic in
>>>>>>>> the Google Groups "BeagleBoard" group.
>>>>>>>> To unsubscribe from this topic, visit
>>>>>>>> https://groups.google.com/d/topic/beagleboard/2NO62mGcSvA/unsubscribe
>>>>>>>> .
>>>>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>>>>> [email protected].
>>>>>>>> To view this discussion on the web visit
>>>>>>>> https://groups.google.com/d/msgid/beagleboard/ecbcf781-d04a-4a40-b6d3-1a33e5e26267%40googlegroups.com
>>>>>>>> <https://groups.google.com/d/msgid/beagleboard/ecbcf781-d04a-4a40-b6d3-1a33e5e26267%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>>> .
>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> For more options, visit http://beagleboard.org/discuss
>>>>>>> ---
>>>>>>> You received this message because you are subscribed to a topic in
>>>>>>> the Google Groups "BeagleBoard" group.
>>>>>>> To unsubscribe from this topic, visit
>>>>>>> https://groups.google.com/d/topic/beagleboard/2NO62mGcSvA/unsubscribe
>>>>>>> .
>>>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>>>>
>>>>>>
>>>>>> [The entire original message is not included.]
>>>>>>
>>>>>> --
>>>>>> For more options, visit http://beagleboard.org/discuss
>>>>>> ---
>>>>>> You received this message because you are subscribed to a topic in
>>>>>> the Google Groups "BeagleBoard" group.
>>>>>> To unsubscribe from this topic, visit
>>>>>> https://groups.google.com/d/topic/beagleboard/2NO62mGcSvA/unsubscribe
>>>>>> .
>>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>>> [email protected].
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/beagleboard/57438c64.87c30d0a.b3918.2ced%40mx.google.com
>>>>>> <https://groups.google.com/d/msgid/beagleboard/57438c64.87c30d0a.b3918.2ced%40mx.google.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "BeagleBoard" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/beagleboard/2NO62mGcSvA/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/a0d097f6-2657-436a-9551-f8c6d4fb48c2%40googlegroups.com
>>> <https://groups.google.com/d/msgid/beagleboard/a0d097f6-2657-436a-9551-f8c6d4fb48c2%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/CADw4j_sBa9Yt5NxOttd5RKMLjsMLk4szoqUj0yXM0-7GVXnv_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
