Thursday, 2 August 2018

MRF300AN 71.5 MHz amplifier

Overall view of test setup

Output spectrum at 40 watts 50v supply

Device test jig
Thermal image of amplifier output matching at 250 watt level

I am currently working on an amplifier for the 71.5 MHz band based
on the new NXP MRF300AN plastic LDMOS power transistor. The
first picture shows the overall setup. The next is the amplifier
transmitting a QPSK signal at 40 watts output and the final a close
up of the test jig.

The idea of the test jig is that the device can be matched for optimum
performance ( IMD / Efficiency or some other criterion) then the device
can be removed and replaced by the SMA jig and the input and output
match measured using a VNA. This can then be used in a program such
as QUCS to design a suitable matching network, possibly for broadband
operation.

I also have a temporary licence for AWR microwave office which allows me
to try the NXP large signal model for this device.

Eventually I may use the amplifier to experiment with Digital Pre-distortion
but that is sometime in the future.

Results so far, with about 300 mW drive I have managed to obtain a CW
output of slightly over 200 watts with a supply of 6 amps at 50 volts
which is well in excess of what is required.As can be seen from the
thermal image of the amplifier the main hot spots are the live end of
the supply choke and the end of the output inductor connected to
the tuning capacitors. The hot line at the left is heat from the losses in
the RG58 cable I am using to connect to the Bird power meter.

The MRF300AN operates from 1.8 MHz to 250 MHz and has a claimed output
of 330 watts. The devices cost £30 each. The output patch leads in my
setup get quite hot as does the LPF (located is the die-cast box connected
to the bird power meter) so I am loosing power there.

While these devices are designed to cope with a 65:1 VSWR at any phase
I have managed to blow one up. That was down to my impatience of
using it with an inadequate heatsink.

The amplifier is more than adequate for it's intended use and that was
for a very clean amplifier for the UK experimental 71.5 MHz band.
We are limited to 100 watts ERP so the amplifier need not operate
above 25 watts. I originally ran the device at 30 volts but the performance
was poor at that level. At 30v I was not able to achieve more than 15 watts
of acceptable output. Increasing the supply to the full 50 volts made
a significant improvement.

A number issues were discovered, the main one being that careful
level settings have to be made. The test waveform was QPSK
generated from an HP ESG signal generator which fed a broadband
class A amplifier based on an old  CA5800. At various stages in
the test I manage to introduce IMD due to the signal generator,
the driver amp and the the Spectrum analyser which gave
a false indication of the actual level of the shoulders the amplifier
was producing.
  
It has been an interesting journey so far and I have learned a lot ........

Thursday, 17 May 2018

My Lime Mini has a box


Just a quick post. I finally put one of my Lime Minis into a box.  The box is a
Hammond 1455C802 with just over 1 cm removed from it's length.
The ends are plastic so are easy to drill. I am planning to add a small 3 cm
5v fan to the top if it is needed.

As I posted on my Twitter account I finally managed to get a very nice DVB-S2
signal out of the Mini and as I thought the issue was with my code rather than
the Mini. The lesson learned is it is vital to run the TX calibration routine every
time you change the transmitter parameters.

The next job is to revisit my GPU accelerated Linux DPD code. The USB3
interface of the Lime gives enough bandwidth to process the oversampled
full duplex signals required to carry out Digital Pre Distortion. If you
want more information please look at previous blog entries. 

Sunday, 28 January 2018

DVB-S2X First Light

Initial DVB-S2X decoding has now been added to the soft modem.
With almost 100 different modulation formats I have little hope of  implementing
them all but it is a start.

Back to S2 again


Monday, 22 January 2018

DVB-S2 Short Frames added





The receiver code now supports DVB-S2 short frames 16200 bits vs the usual 64800.

I am just starting to test some DVB-S2X extensions. I have not yet added VL-SNR
support.

Monday, 15 January 2018

Crude GUI added to DVB-S2 Receiver

A quick update on the project. I have added a MER status line to the GUI.
The carrier tracking has been improved. However I am still limited to
symbol rates below 2 MS/s. This is due to the overhead of the adaptive equaliser.
I have plans to accelerate that part of the code. The equaliser is quite agressive
as it needs to track the symbol rate error, reducing that error will reduce the
equaliser CPU overhead. Also moving the equaliser onto the GPU and
equalising 128 frames in parallel should hide the processor overhead too.

The problem at the moment is how to take the single thread CPU code and
move it to the multi-processor GPU.

Friday, 24 November 2017

CUDA DVB-S2 decoder marches on.

No pictures this time as videos of the receiver in action don't prove much.
I have now implemented version 2 of the LDPC decoder based on a
research paper I found Gronroos   I now appear to be getting a throughput
in excess of 300 MBits/s. There are still some issues, the new decoder uses
8 bit metrics and it is a challenge to get them not to underflow on weak
signals. I have used the CUDA intrinsic SIMD instructions which use saturated
8 bit maths, this is a deviation from the original paper but seems to work.

The decoder works on the bases of handling 128 codewords in
parallel which causes two problems, firstly the latency and secondly the fact
the 128 codewords have to use the same FEC. This is not an issue with
TV broadcasting but does cause some issues with the requirements of
Phase 4 Ground. Another problem is that the new algorithm uses Min-Sum
rather Sum-Product to do the decoding which looses some performance.
I did find another paper that applies a correction to Min-Sum to
get back some of the performance.

The next improvement I made was to use a table lookup approach to detect
BCH code words in error. This has resulted in a 5x increase in speed
of the BCH error detector. The bad code words are then further processed
using the Berlekamp and Massey algorithm and up to 12 errors corrected
per code word. The syndromes are calculated on the CPU.
I calculate the odd order syndromes by using log/alog tables of one of the
base polynomials. The even order syndromes are calculated by multiplying
the required odd order syndromes, for example s2 = GMULT(s1,s1)
(where GMULT is a multiply over the Galois field). I am thinking of
splitting the batches of 128 codewords up into sets of 64 or maybe 32
then processing them in separate CPU threads. I am not sure whether
the overhead of creating the threads will be greater than the concurrency
I can achieve (only experiment will tell).

I have a lot more things to play with like using pinned memory for
device to host transfers and CUDA callbacks.

I am now decoding DVB-S2 at 800 KSymbols/sec, the limiting factor is no
longer the LDPC but the Kalman based adaptive equaliser I am using in
the front of the modem. Currently it uses floating point so can probably be sped up.
After equaliser training on the preamble I hope to switch to the far lesser
demanding LMS method but as yet that doesn't work.

So lots more interesting stuff to play with. I have had no formal education
in any of this I have just learnt it from articles I have found on the internet.
So please excuse any mistakes I make.

For any of you that read this blog that are not Radio Amateurs, part of the ethos
of the Amateur Radio movement is the concept of self training in radio
communications. I hope I meet that challenge, in this my personal journey.

So till next time ....

Monday, 16 October 2017

Work progresses on my software decoder

Here is another quick video of my work on using CUDA to do DVB-S2 demodulation.
I have now reached the dizzy heights of 500 Kilo Symbols per second in real time
with 20 iterations of the LDPC decoder still a long way to go and a lot to learn about
programming in CUDA.