Sunday, 31 August 2014

August update

Not a lot to report, I finally managed to get the Verilog code to compile
into something other than a piece of wire, unfortunately the design was
too big to fit on the FPGA I am using so I am looking how to simplify it.

I have my talk for the BATC convention on the 6/7th of September
completed. It is a update of the current software situation and some
speculation of what might be in any possible DATV-Express 2.

We are always looking to fill a need in the hobby, if there is no need
then we won't need to develop anything.

I am giving a simpler talk and a demonstration to the Worthing Club on
the 17th of September.

There is an up and coming article in the next QST magazine  by Art WA8RMC
and Ken W6HHC is giving a talk at the TAPR DCC on the 6/7th of Sept.

There is a lot going on in the world of DATV at the moment and it is
difficult to track all the new developments.

I am hoping to do some networking at the BATC convention, find out what
others are doing and see where we can help, we don't want to duplicate what
others are doing.

If you attend any of my talks please say hello.

Tuesday, 29 July 2014

Winter projects stacking up

Diversity Receiver?
This is my winter project. I have been wanting to build a diversity SDR for quite
some time and finally I have the bits to make one.

To the left is a development board for an AD9253 quad 125 MS/sec 14 bit ADC.
The middle is an interposer board to adapt between the connectors used on the
ADC board and the FMC connector on the FPGA board. This board requires a
minor modification (to do with the framing clock signal). On the right is a Xilinx
SP601 evaluation board. The plan is to have a simple bit of code on the FPGA
to stitch together all the ICs, frame the data and send it over 1Gbit Ethernet to the
P.C for processing. The limiting factor is the 1Gbit Ethernet (of course).

Using Xilinx FPGA tools is new to me, (in the past I have used Altera) but I have
managed to write and deploy a simple program to the board. Xilinx have a different
way of doing things but the principals are the same.

Of course the FPGA board wants 5V and the AD9253 board 6V.

It will only be a 4 channel diversity receiver but that is a start but once I have verified
that it  works at HF I plan to add VHF / UHF / SHF down converters to it.

Sunday, 20 July 2014

Parallel Processing CUDA OpenGL UHD USRP2

For a bit of light relief the last few days I have been immersed in
CUDA and OpenGL programming. My initial goal is to use the
USRP2 I have to digitise a large piece of spectrum and display
it inside the window of a Qt5 application. I will be using CUDA to
do the parallel processing and OpenGL to display the results.

So far I have managed to create an OpenGL widget that displays a
window in a Qt application, grab samples using UHD, process
them using the CUDA library and write some simple kernel code.
I need to learn a bit more about using OpenGL before I go any further
as I want to display the results as a waterfall and getting CUDA to
talk to OpenGL via the GLWidget does not look too easy to do.
Getting CUDA to share buffers with OpenGL is not difficult but adding
the extra complexity of the GLWidget means I start to stray off the
beaten path.

The biggest problem has been installing the CUDA toolkit and more
especially the correct NVIDIA driver. The one that Ubuntu wants me
to install is not the right one. It has to be the latest one on the NVIDIA
website for CUDA 6.0 to work. I am using a GTX680 card for the GPUs.
I have also been looking at OpenCL but as I am using an NVIDIA card
I thought it better to use CUDA for the moment.

I bought the GTX680 a few years ago and for the same price I could get
something much more powerful now.

I notice it is not going to be long before Ubuntu 12.04 LTS is no longer
supported at which point I will have to consider upgrading. I have heard
upgrades never go smoothly so I am not looking forward to it.

I will post some more about Odroid in the next epistle.  

Friday, 11 July 2014

FFTs and optimisation

Changing the FFT from FFTW to av_fft made little or no difference
on the CPU load when running DVB-T. However optimising the
RS encoder has taken a few percent off the CPU load.

I am using the Valgrind tools to profile the program, the highest CPU load
varies between the iFFT the RS encoder and the interleaver. Currently
the interleaver is the biggest CPU drain and I can't find any obvious way
to optimise it.

I have been able to get 2 MHz wide DVB-T to work on the Odroid U3+
but I had to reduce the oversampling which has caused a small amount
of aliasing to appear in the output spectrum. Work continues.

Tuesday, 8 July 2014

Odroid U3+

Odroid U3+

Not a very good picture but what you are seeing is an Odroid U3+ in it's
case sitting on a tangle of wires which is my desktop. The Odroid is made
by Hardkernel, it is a Quadcore ARM device as used in Galaxy Smartphones.
It is a lot faster that other ARM devices I have been experimenting with and
is well supported with an inhouse magazine and hardware accelerators for the
graphics.

Currently with DATV-Express there are 2 main development strands. Firstly
I am adding support on the PC platform for analogue video capture and encoding
in software using libavcodec.

On the ARM platform I am trying to get the code fast enough to handle low
bandwidth DVB-T. I have moved from using fftw to do the iFFT to
av_fft which can be found in libavcodec. The new iFFT uses single precision
maths and on the ARM platform has special modules that use the NEON SIMD
instructions available on later ARM devices. The combination of these two
features means the code should run a lot faster.

Thanks to a suggestion by Ron W6RZ (who has ported my DVB-S2
implementation to GNURadio) I have managed to optimize part of the S2 code
to knock around 5% off the CPU load. I am sure further optimizations can be found.

Finally I have been reading a book on OpenCL called "Heterogeneous Computing
with OpenCL" One of the chapters gives an example of using it to do real-time
graphics processing and it has sent my mind racing as to the possibilities.

OpenCL for those that don't know is a framework based on the C language that
allows you to harness both CPUS and GPUS (graphics cards) in a parallel
processing environment. So far I have installed the Intel OpenCL SDK and
compiled and run a few pieces of example code. I have a NVIDIA card on my
Linux machine and the NVIDIA drivers now include the bits needed to work
with OpenCL.

What I am thinking of doing is taking the video capture code I have already
written for DATV-Express, run that on the CPUs to capture up to 4 video
channels. Then pass the video frames to the GPUs for manipulation and then
back to the CPUS for MPEG compression using libavcodec. The resultant
transport stream would then be sent to DATV-Express. I can then get rid of the
old Analogue video mixer / effects unit I have. The video mixer cost me
about the same amount as a dedicated PC would.  

Till next time!

Wednesday, 11 June 2014

DATV-Express Yahoo Group

There is now a DATV-Express Yahoo group open to all.
I hope it will be a place that people can share their
experiences of DATV-Express both good and bad.

We would also like to hear from people that are experimenting
with 3rd party software such as FFMPEG, OpenCaster or
GnuRadio, also those using Linux to receive Amateur DTV.

In the next release of the DATV-Express software 2.03
we will have implemented a UDP socket interface.
This will allow people to send a UDP Transport Stream
either via the loopback address or via Ethernet to / from
DATV-Express.

I hope you will find this facility useful and will do great things
with it.

Saturday, 17 May 2014

Solar power PI based Broadband-Hamnet node

The title pretty much says it all. The Realtek RT5370 WiFi dongle is at the
end of a 10m powered USB2 cable. Attached to it is a high gain omni
(10dBi, a figure I don't believe). There is about 1v drop up the cable so
I am feeding 8V up to the WiFi dongle via the modified USB2 cable where a 5V
regulator then provides the correct voltage to power both the dongle and the 4 port
USB2 FE1.1s hub chip which is in the end of the 'active' cable. 

This is a bit of fun as I am not expecting to be able to MESH with anyone
other than with my Linksys WRT54GL but .....