Full Kits out of stock


It has been some times since i have posted, also it would seems i have missed some of the toroid cores finishing, while waiting for more the full kits are out of stock, sorry.

I hope i can get some in 1-2 days time, will update quantity in PayPal accordingly when possible.


STM32F746 clock out

After being down with a nasty bug for few days nothing much has been done on the mcHF Pro front, except doing small CPU pin allocations daily.

To continue the minimalist tradition of the mcHF i decided to reserve the MCO1 and MCO2 pins for clocking out external HW. For those who don’t know, the internal CPU PLL can be routed to two GPIOs and get away without two extra oscillators. Final result is reduced cost and better frequency stability (lower drift), as it is easy to oven/stabilize one chip than three.


The mcHF used only one of those, so only the Codec was clocked from the CPU PLL. On the new design i can clock the Codec again and something else. Still no idea, need to carefully check the frequency range that could be used – but maybe the quadrature upconverter or the FPGA.

For those who would like a peek at the preliminary schematics and the FPGA code, i did setup the GitHub, here.

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 wsprnet.org, 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…

mcHF Pro – something in the works

Well, i have tried to start on this project last summer. Even bought expensive F429 development board from DigiKey. Still too much stuff in my personal life and around the mcHF project kept me away.

Now after spending four mounts on the v 0.5 update of the mcHF boards and another month on the new 3D casing, i think is time to seriously get back to this new idea.

What is about the idea – reflecting on the mcHF development in the last two years, all problems that needed addressing were exclusively related to analogue parts of the design. In my view is imperative to sort those problems by removing as much as possible of those(i mean analogue modules).

Why new project, instead of modification of the existing mcHF ? As the mcHF project is more or less mature, hardware is finalized and the firmware complex enough to allow major changes, i believe the best option is to start from scratch.

So where do i start ? First i can re-use parts of the code that was done on the F429 development board – those are mainly two controls that emulate analogue S-meter and spectrum display. I have super loop and OS version. I think i have settled on using FreeRTOS in the new radio, so i had to port the OS version of the controls on a new CPU – the STMF42F746.


I have a clear idea what the new block diagram would look like. I would love to use the AD9957 quadrature upconverter. It could be connected to a 16bit port of the F7 and using a timer, samples could be sent to it via 2-3 ARM instructions, without much overload on the CPU.


Most of the rest would be re-use of the mcHF user input/ouput. The one thing i am not sure is the RX path. Ideally i would love to use ADC/FPGA and sample 0-70 Mhz range, then simply downconvert in the FPGA, but my only starting point is old USRP1 that needs a bit of dusting off.

That is why i have decided to make a first alpha proto board with the F7, LCD, SDRAM and AD9957 for now and see how it goes. Anyway it happens that the F7 discovery board is not suitable for expansion, so i kinda have to do it.


Yes, the SMT32F7 is no joke, thirteen pages of just GPIO options. Well actually it is not that scary – after connecting the LCD in 24 bit mode, SDRAM in 32 bit mode and the AD9957 on full 16 bit port, not much left for anything else, even on the LQFP208 package. Did somebody complained about 5 mil pitch CPU soldering ? Nothing to fear, now we have 208 pin package, but if you miss the 100 pin, the AD part comes in the same footprint as the F4 in the mcHF! Well it has also a thermal pad in the middle.


Final point on the source code, so far it is only a custom compilation of the F7 discovery cube release by ST. I am using the System Workbench from ST, this is using Eclipse and do not support project files, but rather workspace directory. So it is a mad 500 MB of libs and documents that need serious sorting before it could be uploaded on the GitHub. The other problem here is that at this moment it nicely loads onto the F7 discovery board, but once i move to the Alpha board, it will not work on the discovery. And to use conditional compiling in hundreds of files, just to have 1% available on the depreciated board is too much work. So bare with me on this one.

Next, complete schematics and start on the PCB…

mcHF new enclosure ready!


It has been some time since i have started on the new enclosure. Finally i was able to finish it off. It is fully modular, it could be made using different fabrication techniques – CNC machining, 3D printing or mixed. For example as a quick start all parts could be 3D printed, then eventually some panels could be machined and replaced on the ready assembly. Top holder panel that holds two small heatsinks could be machined from aluminium as a whole as well.

Files and documentation are available on the Download page or here as a single zip archive.

A quick glance of the new enclosure video:


mcHF shielding plate


I still haven’t been able to finish the files for the new mcHF enclosure. I keep on getting new ideas for improvements and see small errors. But as a matter of urgency i have uploaded the shielding plate files here.

Those files are compatible with v 0.5 of the boards and i believe would be ok for v 0.4 as well. For old school OMs who prefer to make the plate by hand, here the detailed drawing with dimensions:

shielding_plate(click for larger view)