Actions
Forum Thread Details
  • Replies 32 replies
  • Subscribers 59 subscribers
  • Views 4540 views
  • Users 0 members are here
Related

Cubieboard2 A20

Former Member

Arrived in the post today..

 

imageimage

 

I also got a prototype board to make getting at the GPIO pins a bit easier

imageimage

 

Physically it's a bit bigger than the BBB

image

 

In the box you get a usb to minature barrel connector power lead and a combined sata + power lead that's only really suitable for 2.5" drives due to the lack of 12v

image

 

It comes with a version of Android pre-installed on it's 4G nand flash that allows you to have something up and running a few minutes after opening the box.

 

You can't really do a lot with the Android image, so I quickly replaced it with one of the debian images from cubieboard.org

 

Not sure if it's just down to the A20 being fairly new and the drivers not having caught up yet or what, but the display resolution seems to be fixed at 1280x720 which my 20" 1600x1200 monitor really doesn't seem to like. So initial start up was somewhat frustrating. The cubieboard logo flashes on the screen for a second or two and then the screen blanks.  Connecting it to a 1920x1080 gives better results, but seems to have a large overscan by default in linux text modes.

 

As you'll see in the photos, I've soldered on some relatively heavy power leads, partly due to some concern that the rather flimsy power lead was causing the display problems due to low-ish voltage and partly to make it easier to do some current measurements.

 

With nothing connected, current peaks at around 360mA during boot and then settles to ~200mA when idle. This is reasonably impressive considering it's running the performance cpu governor and so isn't benefiting from power savings in the way the BBB does.

 

Connecting ethernet raises the idle current to ~250mA

 

Adding a CPU intensive task adds approx 100mA per core, peaking at around 460mA

 

With a 500Gb 2.5" drive plugged in and active it's possible to get up to about 1A if you're stressing everything simultaneously.

 

 

First impressions are that that it's a decent board. A better, or at least more common, power connector would have been appreciated as it initially left me no option but to connect to a PC's usb port that likely wasn't capable of supplying the 5v @ 2A that's silkscreened on the board.

 

The debian image I'm using feels a little sluggish, but that's fairly normal. I'll reserve further judgement until I get something installed with a bit less baggage.

 

One slightly disappointing piece is that there's no way to supply power apart from the barrel connector, or soldering on a connector to some unpopulated pads directly below it.  Other boards (RPi, BBB) can have power supplied via their GPIO connectors, but it doesn't seem so simple here.

 

Price wise, I was about 80 GBP delivered. So we're obviously not in RPi / BBB territory, but it does sit in a reasonable place between the BBB and Sabre-Lite.  You get dual-core, 1GB ram and SATA on top of the BBB, while being 2 cores, gigabit network and PCIe short on the Sabre-Lite. The Sabre-Lite arriving at around 155 GBP makes the Cubieboard an interesting compromise.  As the A20 uses an A7 series core which is feature compatible with A15, it also gives an easy path to future upgrades.

  • in reply to Former Member

    This is interesting: http://blog.lemoneerlabs.com/post/BBB-webcams

     

    In terms of USB bandwidth and processing video, it looks like the BBB is able to read and process the video stream, if it comes from a camera that has MJPEG compression on-the-fly.  Choice of camera is obviously important here, but this blog, at least, indicates that it is feasible on the BBB.  This blog lists a Logitech C920 as having H.264 compression, which sound exactly right for me!

     

    But ,clearly, I've still got a steep hill to climb if I go this route!

     

    I've still got to establish whether I can reliably store the resultant video stream to a file (with ffmpeg, I assume), but whether that's on a SATA disk on the Cubieboard2, or SDCard on the BBB is probably acedemic at this stage.

  • in reply to Former Member

    Hi Douglas,

     

    I don't know what the use-case is, but in general you'll get much better results if your camera is H.264. The MJPEG is good for video stills (e.g. a snapshot every second), but H.264 is better for motion video (and saves a lot of disk space).

    The BBB (or any Linux platform) can handle any of these streams, since it is just network traffic.

     

    EDIT: Sorry I thought Ethernet was being used. If USB, then a driver that runs on the platfom is needed.

  • in reply to shabaz

    If USB, then a driver that runs on the platfom is needed

    By that, do you mean V4L2, or a BBB-specific USB driver?

  • in reply to Former Member

    Hi Douglas,

     

    Some webcams will be supported in Linux, and a driver may already be compiled and available on the platform, or it may need to be compiled. However, I think not all webcams are supported in Linux because the manufacturer may not have made a driver available for Linux, compiled for the target device (e.g. ARM).

  • in reply to shabaz

    As long as the driver is in source form then it should be possible to compile it for any linux distro. The problem usually appears when your kernel is 3.11.4 and the vendor driver only supports 2.6.24 or vice versa.

    Supplying binary drivers for linux is difficult, since you'd need to supply one for every possible distro and kernel version.  The likes of nvidia sidestep that problem by providing a driver that's mostly binary but that comes with an adaption layer that you compile against your kernel. This mostly reduces the problem to needing three versions for x86, x86_64 and Arm.

     

    Whether cheap webcams go to those extremes is uncertain.

  • in reply to shabaz

    So.... I don't need V4L2 then, if the webcam I'm using is already supported in Linux?  Or do you mean that there are different 'flavours' of V4L2 for different types of webcam?  Or have I completely misundestood what V4L2 is, and what it's used for (which wouldn't surprise me!)?

     

    Having scoured the internet for months on end on this subject, it seems to me that V4L2 is the minimum requirement to read a video from USB, but I've yet to find a website that states what it actually is, whether or not it is always required, and how you build a version of it for the specific SBC and camera that you are using.

     

    All the websites I've visited about Linux - and in particular, about video capture - seems to be aimed at people who already know what they're talking about, but I've yet to find one that describes the process to a newbie.

  • in reply to Former Member

    Douglas Ponsford wrote:

     

    If USB, then a driver that runs on the platfom is needed

    By that, do you mean V4L2, or a BBB-specific USB driver?

    A linux driver specific to the USB webcam.  You can get some idea of what's easily available here http://linuxtv.org/wiki/index.php/Webcam_Devices the problem of course is that it's sometimes difficult to work out which driver goes with any given webcam as they don't tend to tell you which chip is inside on the outside of the box.  You can find out by plugging it in and reading the vendor and device ID's, but you've spent the money by that point !

  • in reply to Former Member

    Douglas Ponsford wrote:

     

    This blog lists a Logitech C920 as having H.264 compression, which sound exactly right for me!

    Something that produces h.264 directly in the camera is ideal, much less bandwidth required for a given resolution and the bonus is that you don't have any processing to do, just save to a file.

     

    I've still got to establish whether I can reliably store the resultant video stream to a file (with ffmpeg, I assume), but whether that's on a SATA disk on the Cubieboard2, or SDCard on the BBB is probably acedemic at this stage.

    You don't have to use ffmpeg, as long as the camera driver gives you a normal v4l2 style /dev/video0 interface then you have a choice of many applications.

     

    When thinking about SDcards, take into account that they can be quite slow and that a lot of SBC's don't support the high speed SDcard modes.  So you could find yourself being able to deal with your multiple h264 streams over USB, but unable to save them to SDcard fast enough.

    Very simplistic tests show that the SATA interface on the Cubieboard is fairly good, better than the Sabre-Lite for example. As with anything, one piece of the puzzle is not enough, you want everything your use case needs to be good as the overall application is only as good as the weakest link.

  • in reply to Former Member

    OK, I think that's where my confusion about V4L2 has been coming from.  V4L2 is not a particular piece of code as such, nor an application, it's a standard for reading video streams from USB devices, and there can be many incarnations, or flavours, of a V4L2-compliant driver.

     

    So, in layman's terms:

    "V4L2" means "Any Linux driver that is specific to the USB webcam",

    in the same way as:

    "Hoover" means "Any cleaning device that sucks dust out of carpets by use of a vacuum".

     

    Does that sum it up?

     

    So, if I have an H.264 stream coming in, made available in the /dev/videoN interface by the V4L2-compliant Linux driver, then - as you say - I can just write that byte-stream to a file, and the 'saving video to a file' bit is already done for me.

     

    But, presumably, if I also wanted to simultaneously display the incoming video stream on a monitor (LCD in my case), I'd still need to use ffmpeg to decode the H.264 stream for writing out the live video to a display device?

     

     

    Your comments about the SATA Vs. SDCard are also a very good point.  Having a ready-made H.264 video stream means that CPU performance is less of an issue, so the BBB is then a good choice because of it's support and price.  But that SATA spec-point in particular makes me think the CB2 is still the one to go for - thanks for pointing that out!

  • in reply to Former Member

    Douglas Ponsford wrote:

     

    So, in layman's terms:

    "V4L2" means "Any Linux driver that is specific to the USB webcam",

    in the same way as:

    "Hoover" means "Any cleaning device that sucks dust out of carpets by use of a vacuum".

     

    Does that sum it up?

    Think of V4L2 as more along the lines of a generic "video capture" driver.  It doesn't need to be a USB webcam, it could be a composite video capture device, a digital-tv tuner, a satellite-tv receiver etc.  It could also use USB, firewire, PCI or any number of other connection methods.

     

    The Hoover analogy works quite well, less bothered about 'how', focus more on accomplishing the task.

     

    V4L2 is the plumbing that provides a standard API for the applications to use.

     

    So, if I have an H.264 stream coming in, made available in the /dev/videoN interface by the V4L2-compliant Linux driver, then - as you say - I can just write that byte-stream to a file, and the 'saving video to a file' bit is already done for me.

    It's a bit more complex, but maybe not much. You need to tell V4L2 what resolution you want from the source, fps and such like. Then when you save the stream you probably want a container format like avi, mp4 etc. but most of that is trivial stuff that the application (ffmpeg, vlc, mplayer) can take care of for you.

     

    But, presumably, if I also wanted to simultaneously display the incoming video stream on a monitor (LCD in my case), I'd still need to use ffmpeg to decode the H.264 stream for writing out the live video to a display device?

    Yep, you'd need something to do it. I'd maybe suggest taking a look at VLC which has all sorts of options like streaming over ethernet. It may be that you can take care of some things easier with a particular app, or use a combination of different ones to get your end result.

     

    How you get from A to B probably also depends on what OS you use, choice of applications may well be different on Android vs Debian for example.