The VideoBrick-Teammembers, are quite busy with other projects at the moment. Thats why the VideoBrick will be put in suspend mode. And the date for the 2nd VideoBrick Hackathon will be rescheduled to August.

keep fingers crossed that it will be a successful restart :=)

This way I also want to mention that contributers to this project are very welcome to join our efforts.

If you are interessted in participating to the VideoBrick-Project and you think you’ve got the right skill set don’t hesitate to send  an Email to georg ( a t ) otelo.or.at

Kicad now offers Lengthmatching, De-Skewing and Differentialpair routing … check it out.

very handy 😉

We are all quite busy, with our day jobs – so sometimes a project is not progressing as fast as we wish. In order to take the next steps, lets define them and set a date for the next Hackathon.

It will take place at the Otelo Vöcklabruck during Friday 24th April and Saturday 25th April from 10:00AM. We would like to invite everyone willing to hack and join our Videobrick project and learn about technics related with linux programming and hardware hacking.

As basic capture works we now can set our agenda for the next steps:

• modify two alpha-prototypes (DE-Line hack)
• adapt an existing kernel-driver to receiver I2S-Audio
• make the videocapture more stable.
• implement a alpha-prototype of a streaming application.

Once we have completed this steps we can think about moving to the Beta-Phase, which includes a redesign of the PCB (this time in KiCad) and trying to motiviate more developers from the community.

With the help of Karl we now have the foundation to design the Beta-Prototypes of the VideoBrick in KiCad.

As you can see not much routing has been done – this is mainly because the Beta-Prototypes most likely will use the CSI0 instead of the CSI1 camera interface – with this switch we will loose the support for 24-Bit RGB 4:4:4 but we will gain more flexibility when it comes to YUV colorspaces – (4:2:2 and 4:2:0) this is particularly important as the software support for this YUVs spaces is much more common. thanks Karl.

first version of the files can be found at our github

today i taught i give it a try to use the DE Line for HSYNCing

DE – stands for Datavalid and it is basically a controll line which is
high whenever there is valid pixel data.

I modified the Board and removed the connection from ADV7611_HSYNC to
CSI1_HSYNC and made a new connection by connecting ADV7611_DE to CSI1_HSYNC.

Actually I don’t use direct connections but 33 Ohm Series resistors –
but if you don’t have those resistors lying around you can use straight
wires I guess (as long as you dont make shorts)

and yes it worked …

I am not sure what went wrong in first place but this is a sollution we
can continue working …
As modifying the HOR_START Register from the CSI1 Perihperal didn’t show
any difference, i suspect that there is something strange with CSI1 –
maybe there is a BUG in Silicon of the CSI1 Peripheral.

But there is probably more to this issue – maybe the
registers are not set correctly.

Attached see a Grayscale sample (for some reason the v4l2-capture tool
makes sometimes problems) – captured via gstreamer-1.2.4

(UPDATE) if you zoom in the following picture you can see a one Pixel wide frame – that shows that really every pixel of the 1280×720 input is captured

and here is the mod of the board:

With the help of jemk’s H.264 encoder, we are now able to capture and encode first test videos – If you want to have a look the test video:

Two issues are clearly visable:

1. There is still a issue with the V_SYNC H_SYNC as our Image is offseted by ~200-300 pixels
2. The framerate is somehow mixed up and/or we are loosing complete frames in this process

Many many thanks to jemk this way – he just recently added support for P-Frames and NV16 Colorspace to his encoder.

Here are some images of VideoBricks thermal performance

After capturing 720p50 for about 15min – the ADV7611 heats up to ~47 degress Celsius with an enviroment temperature of about 22 degrees.

The LDO (3v3 to 1v8) heats up to around 62 degrees  – which is a bit hot for my taste, but not really critical – the LDO is really tiny, it is a TPS72018DRVT so maybe we will swap the LDO to something with a bigger package as we have enough room to do so.

On the backside of the LIME we can monitor the temp (58 degrees C) of the Allwinner A10 while captureing (note in this setup the H264 encoder is not running), so in the final test the produced heat of the CPU might be higher.

Last but not least lets have a look at the Powermanagment Chip (48 degrees C) of the Olimex Lime – I have to choose an angle in order to have a look at it because it is under the VideoBrick-Shield.

The standard OS of A10-Lime is Debian Wheezy, which doesn’t provide gstreamer-1.0 in its default repositories.

But fortunatly gstreamer-1.0 is part of the Wheezy-Backports.

so you have to add the following line to /etc/apt/sources.lists

deb http://http.debian.net/debian wheezy-backports main

 

and run

$ sudo apt-get update

 

unfortunatly though – there seem to be some issue with the liborc libraries – so I cam up with this workaround – i downloaded the files manually and installed them with dpkg.

$ wget http://ftp.at.debian.org/debian/pool/main/o/orc/liborc-0.4-0_0.4.19-1~bpo70+1_armhf.deb
$ wget http://ftp.at.debian.org/debian/pool/main/o/orc/liborc-0.4-dev_0.4.19-1~bpo70+1_armhf.deb
$ sudo dpkg -i --force-all liborc-0.4-0_0.4.19-1~bpo70+1_armhf.deb
$ sudo dpkg -i --force-all liborc-0.4-dev_0.4.19-1~bpo70+1_armhf.deb

after that i just installed gstreamer1.0-tools and the plugins

$ sudo apt-get install gstreamer1.0-tools gstreamer1.0-plugins-base gstreamer1.0-plugins-good

after playing around more with the v4l2-driver I could reconstruct an RGB-image. This proves that all signallines from the VideoBrick to the A10 are working:

Red-Channel:

Green-Channel:

Blue-Channel:

I opened all these 3 Images in GIMP (as individual Layers) and converted them to grayscale using the Menu Colors->Components->Recompose. This way I could recreate the orignial image:

Which is working – unfourtunatly though the RGB-Format used in V4L2 – is one byte R, one byte G, one byte B – but with this driver i get a planar output of Image-R, Image-G, Image-B. I still have to figure out what common color space the the ADV7611 provides that can be used with the Allwinner CSI-Perihperal and V4L2.

The next test was to force the ADV7611 into YUV4:2:2 16Bit output mode – this way i could receive a Grayscale Image (because the Luma-Channel (Y) equals basically the grayscale information):

As you might notice there are still issues with the offset of the image …

As for testing I also switchted to gstreamer-1.0 – making the gst-plugin-cedar (H264 Encoder) currently unavailable because this is a gst-0.10 plugin.

you can capture grayscale Images using the Source from the github: https://github.com/videobrick/vb_software/tree/master/vb_module

$ sudo ./loadmodules

loads the needed modules

$ ./stillcapture

captures the Grayscale image…

I assembled two more VideoBrick Prototypes – unfourunatly I mounted the LDO the wrong way around which caused all kinds of wired behaviour including exhibiting the ADV7611 to 2,1 V instead of 1,8 V core voltage – to figure out this issue I had to desoldered one of the ADV7611. Somehow it seemed that the ADV7611 survived this mistake because i could correct the LDOs on both boards and both of them are working now (one with changed ADV7611 the other with the ADV7611 soldered in first place)

and by patching the sun4i_csi1.ko Kernel Module I could get the output to look like this in 720p50:

The patch was to force the CSI1 periheral of the Allwinner A10 into 24-Bit RGB/YUV444 Input mode (see for more details in the User manual of the Allwinner A10 which can be found on linux-sunxi.org)

the file sun4i_csi_reg.c was patched in the following way:

/* configure */
void bsp_csi_configure(struct csi_dev *dev,__csi_conf_t *mode)
{
    u32 t;
    W(dev->regs+CSI_REG_CONF, //mode->input_fmt << 20 | /* [21:20] */
                              4 << 20 | /* 24Bit YUV or RGB input */    
                              mode->output_fmt<< 16 | /* [18:16] */
                              mode->field_sel << 10 | /* [11:10] */
                              mode->seq       << 8  | /* [9:8] */
                              mode->vref      << 2  | /* [2] */
                              mode->href      << 1  | /* [1] */
                              mode->clock     << 0    /* [0] */
      );

  t = R(dev->regs+CSI_REG_CONF);

}

Happy new year to all readers of this blog. btw. 🙂