Monthly Archives: May 2016

Screen grabber back online


It has been an year since my 4m WSPR screen grabber actually worked. Now after freeing my old SSL server machine and installing all needed proggies – WSJT-X, Dimension4, ShareX the sidebar imagine link actually works and is updated every 1 minute.

I was reluctant to use anything else, as this machine is fanless, the whole case is extruded aluminium and has SSD, so absolutely no noise.

LCD troubles

I think have mentioned before that I have special service jig that allows me to test every single LCD before posting it with the kit. It is very useful idea, as it saves money and hassle in the long run.

The usual QC fail on every batch i get is in the range of 10-20 %. And the most common fault is the famous ‘White Screen’ problem. I haven’t done any detailed analysis, but i would say is either badly soldered flat cable/mode jumpers or simply faulty controller chip.


But testing my latest batch i got more than 55% failed LCDs. And the ‘fault’ was not the usual ‘White Screen’ but something i call ‘Broken TV’, something you would get on old school analogue TV without an antenna connected.


It was really concerning, so after speaking with the manufacturer, it would seem there are four different revisions of the ILI9325 controller chip, named by them as A,B,C and D. There is a differences between them, not a detailed list of those, but one important thing would be the maximum communication speed. It would appear that version A is the slowest (not being able to handle higher clocks) and D is the fastest.

So using the version of the source code and latest driver source code for the controller from the manufacturer i was able to make those LCDs, that have the new revision controllers work.

You can find the updated firmware binary on my Downloads page, and source code fork is on my GitHub account.


Investigation into the DDC concept

The concept of Digital Down Conversion (DDC) is not new to me. I had been early adopter of the USRP1, and had it running OpenBTS for non ham related R&D projects. The magic of emulating GSM network is orders of magnitude more complex than sampling the full HF spectrum and then presenting a 192k stream to the PC for a software defined receiver program.

But my friend Bri(G0MJI) recently brought my attention to an interesting board called Red Pitaya.


There is nothing extraordinary about it, it is the usual ADC, connected to FPGA with some emulated logic to implement down conversion, with DDS/NCO etc. This one has ARM core cpu inside as well, so it can run Linux on chip, which is a money saver. What was amazing about is that a user called Pavel have managed to create multiband, parallel WSPR receiver – fully contained on board. You need only antenna, power and Ethernet connection!


It is a computing intensive task so active cooling is a must! And it actually happens that this board is quite amazing at WSRP. After maybe week of using it on air I was curious how good/worse is this DDC concept against traditional setup of HF transceiver and a PC.

Although looking at the WSRP spot database it would seems the board performs exceptionally, there is still doubt how sensitive and protected against overloading is an ADC input open to everything from 0 to 60 Mhz. Yes, the ADC on board seems to be clocked at 125 Mhz.

My test setup was the board itself, submitting to, and old Sony Laptop running Ubuntu 14.04 and latest WSJT-X. So the decoder versions on the Red Pitaya and the laptop are compiled from the same source code – the latest K9AN C decoder. Also same antenna is used to feed the mcHF and the RP board, via mini-circuits signal spliter.


The board during day time actually samples and submit eight ham bands, but my setup did the comparison only on 40m as it was not practical to have 8 laptops and transceivers. Here the six consequential screenshots, where on the left you can see spots submitted from the Red Pitaya and on the right local decodes from the mcHF/WSJT-X combination.

Screenshot from 2016-05-17 17_46_55screen 1(click to open high res)

Screenshot from 2016-05-17 17_48_21

screen 2(click to open high res)

Screenshot from 2016-05-17 17_51_02

screen 3(click to open high res)

Screenshot from 2016-05-17 17_52_27

screen 4(click to open high res)

Screenshot from 2016-05-17 17_54_35

screen 5(click to open high res)

Screenshot from 2016-05-17 17_56_24

screen 6(click to open high res)

So it would seems there is no visible performance problem compared to conventional setup. This could, off course, be attributed to the resilience of the WSPR protocol. But this board demonstrates very extreme case – fully open input of the ADC, directly connected to external antenna. Practical transceiver designs that use the DDC architecture (eg IC-7300, etc..) implement wide range of modules to prevent this – switchable BPFs, pre-amps, digitally controlled attenuators, etc.

So apart from ginormous power consumption, high speed clocks, difficult to route multi-layer PCBs and big chips – the DDC architecture is a clear winner!

AD9957 is a bad boy!

It looks like the AD9957 needs four power supplies. So the digital and analog rails are split and there is a pair for 3.3V and pair for 1.8V.


Usual solution is to use single dual regulator with bunch of T filters. Like this guy who made a DAB radio transmitter using this same chip. But it would seem the current requirement is bit weird so this power scheme is not very good option


So after spending some time i think i will start with 150 mA dual regulator (tested in old design) with only one T filter, and use extra 700 mA regulator for the demanding 1.8V DVDD.

ddsAnyway, both could be switched off via Inhibit pin, so the quadrature upconveter could be off if not needed in RX mode and save more than 800 mA. There is also a need to complete the signal part of the module, to follow…