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_vKbt2evb%2B14UcvX55ax%3Dy4KqrCcLT%2BOJgs4iGDOoRGFw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
