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…

28 thoughts on “mcHF Pro – something in the works

  1. Jesper Kraakman

    Hi chris,

    This all looks really interesting, and I really do like
    the ADC –> FPGA –> MCU configuration rather than rf –> mixer –> filter –> opamps –> audio ADC.
    Not saying its bad, but directly sampling is a little more modern + much more bandwidth.
    I can’t wait until the alpha boards arive.

    Jesper Kraakman

    1. m0nka Post author

      Hi Jesper,

      Yes, it is the next logical step. Also allows for much more experimentation. I am still working
      on the board, just haven’t been upto updating the blog lately.


  2. Dirk Handzic

    Hi Chris,
    a very intresting project! I have designed a number of industrial control boards around the STM32F families up to F429 with graphics display and external SDRAM. Please be aware of that the SDRAM needs length matching of the bus lines, you are probably already aware of it, I just mention it in case.
    The new STM32F769 has 512MB of RAM on chip which allows for 480×272 LCD without external SDRAM.

    If you decide to go with external SDRAM and need someone with a layout tool which can handle length matching, I have Mentor Graphics PADS with this feature.

    Dirk SA4DHT

    1. m0nka Post author

      Hi Dirk,

      Thanks for the useful info. I am aware about matching on those high speed busses, i have done matching only on USB pairs and
      in the latest RF board revision (in the mixer clocks lines). Also haven’t done multilayer board yet, but will give it a go.
      Will drop you a mail for sure if i need help. Thanks for the offer!


  3. Darren Taylor


    I have many years of software and hardware development under my belt with a good portion on the project management side. Although I am told by all of the software developers ‘a good coder stays, the bad ones move to management’ I would be willing to offer my assistance in areas you might appreciate a hand.

    I spent many years prior to hardware and software development as an electronics component buyer and expediter for a large American assembly and board fabrication shop. I still have many contacts in the hardware supply chain that may be of use down the road.

    Anyway, please let me know if my skills could be of use to you as the project progresses. My skill sets are broad and at times even deep ;)! Mostly, I know a little bit about a lot of things! I am happy to help should there be a need.


    1. m0nka Post author

      Hi Darren,

      Thanks for the offer! I have been a away for a while from the projects, but when i am back full time,
      i will post my progress, so you can jump in anytime – via suggestions, contributions via GitHub or
      anything really. It is no rush or pressure for dead lines, sometimes i got distracted by interesting stuff –
      like wearable tech/Red Pitaya/rPi being able to run OpenBTS, or just making another antenna…


  4. Vadim

    Hello Chris,

    Did you finalize vendor/model for the future FPGA, if there is going to be FPGA in first place 🙂
    I really hope you will use one.
    There is probably no way around it anyway.

    I would like also offer my help with FPGA programming if you will need any.

    Vadim AA6MU

    1. m0nka Post author

      Hello Vadim,

      Yes, i have decided to base the RX path on the good old USRP1. It is open source, i have the hardware here. It uses Altera Cyclone 1 in 208 pin LQFP package. But because it uses two pairs of ADCs and two pairs of DACs and some extra GPIOs for daughter board expansion, it needs such huge package. I have managed to compile with just one ADC (using the conditional configuration) and removed extra GPIOs. Now it fits nicely into 144 pin LQFP package and in theory it should work with some newer ADC (like LTC2229). The other good thing about the USRP1 is that the full firmware for the USB chip is available, so control implementation, data flow and serial programming of the FPGA configuration is pretty clear from the schematics and code. Off course the bad side is the 12 bit ADCs used by the code. Although allocating of extra pins to expand to 14 or 16 bits would be easy, i have no idea how touching the internal buses in the FPGA will affect the actual logic that does the downconversion math, it is way above my pay grade 🙁 I would certainly appreciate some help on that. Oh and the FPGA project compiles just fine with some old version of the free Altera studio.

      I will need to start slowly uploading the projects and schematics to GitHub, even nothing is fully complete. It would make it easier to spot bad design decisions and error early on in the project. On my list…

      73, Chris

      1. Vadim

        Hey Chris,

        Got it. I agree, it’s way easier to incorporate already working block into your new design.

        Regarding code on the FPGA:
        From the first glance I didn’t find any evidence of hardcoded 12-bit size for the word from ADC thru the all code. In fact – code was written for 16 bits thru and thru.
        I would say only one module and some word lengths should be altered to accommodate different ADC sample size, all internal math is coded for 16bits words inside already.

        I’m going to pick up some nice 16bit ADC, maybe older sibling of Icom7300 ADC and try to redo the code to pull stream from it. I should have Cyclone IV dev board somewhere in the garage already.

        Will be patiently waiting for your alpha boards to come online.

        Vadim AA6MU

        1. m0nka Post author

          Hi Vadim,

          Thanks for looking into the code and confirming that! It means i haven’t wasted a week trying to use this code. Please drop me a mail,
          we can talk more. I wish i could speed up with the boards, but had too many things on the side this last week, almost no progress on the
          new project.

          73, Chris

  5. Renan Mert Ozel

    Hello Chris,

    I hope this is not a too late response to your post but I am quite confident that ChibiOS/RT deserves your attention if you have decided to use an RTOS in your new project. I have some experience on FreeRTOS and ST HAL and I feel that your development and the final code may be more efficient if you use ChibiOS/RT.

    Although FreeRTOS’ market penetration is quite high with respect to other non-commercial RTOSes, there are a few important things to be considered.

    ChibiOS/RT is well integrated with its own HAL, i.e., ChibiOS/HAL. Yes, it’s implementation is quite basic so you may hit to it’s limits but it is every way better than still buggy ST HAL.

    FreeRTOS uses dynamic heap allocation. In ChibiOS/RT, you may use static, dynamic, or both.

    Use of operating system abstraction layer (OSAL) makes HAL drivers to be RTOS aware even without bound to a specific OS.

    ChibiOS/RT transparently utilities DMA whenever possible.

    The design of ChibiOS/RT is clear and efficient. In my applications, I found that resource (memory and processor load) performance is consistently better than FreeRTOS.

    Documentation is well written and you may receive quite immediate response from the author or from the community if you get stuck somewhere.

    73, Mert

    1. m0nka Post author

      Hello Mert,

      Thanks for your very detailed comment. To be honest i have only two reason for selecting FreeRTOS. 1. i have used it in old project and because of that i know it inside out, this sometimes makes my life easier 2. There was ready example project from ST that compiled straight away, so it only needed to add my drivers.

      Not sure if you have checked my mcHF source code, but all drivers are coded in a way to be easily FreeRTOS ‘insert-able’, although i am using a super loop instead an OS. It is more or less the way i do coding in the last 10 years, even on non embedded devices.

      So for me is not what OS is best, i might not need OS at all. I even think i will skip the HAL eventually, and have pure assembler drivers. This is something i wanted to do for the mcHF, but time was short,then development overtaken by Clint, etc..

      73, Chris

  6. Kees Talen

    Yes, but then you hit the stumbling block …….new firmware. I came the the conclusion long ago that the hardware is relatively easy, the firmware is not.

    73 Kees K5BCQ

  7. Kees Talen

    I like the idea of a small, low cost 5W DSP Transceiver and believe the path to it may be the use of the STM32F746 Discovery board. …..the entire board is $50 and it looks like it has the right items integrated on-board and sufficient I/O. 216MHz ARM microcontroller, 64Mb SRAM, 128Mb EEPROM, a pretty good touch screen LCD, a great multi stereo Wolfson CODEC, a USB port for re-programming with on-board programmer, etc. You add the RF Filters, 5W Amp, I/Q circuitry, and tuner on a much simpler second board.

    Sooner or later someone will incorporate this whole board into a nice SDR Transceiver.

    1. m0nka Post author

      Hi Kees,

      Such simpler second board already exist and it is called mcHF RF board. And it doesn’t get any simpler, unless you want very little functionality, then the Softrock Ensemble RXTX will do.


  8. Steve C.

    Did you have a list of requirements in mind? (Besides eliminating some of the analog bits where possible.) Like expansion options for oddball bands, etc.?

    When I first looked at mcHF, one of the compelling thoughts I had was that it would be fun to be able to hook up a keyboard, and do self-contained digital comms without a clunky laptop and cables. In reality, there isn’t enough display space, and I suspect CPU cycles may be a real problem (I really don’t know this, just an observation).

    Just thoughts. I will be watching for beta boards. I was late discovering mcHF, and wish I had come across it far earlier.

    1. m0nka Post author

      Hello Steve,

      At certain point i had standalone WSPR working. I had also external USB keyboard working, but never managed to finish the PSK31 implementation. In theory you can fit lots of digital modes but why ? Rpi small computer running all digital modes – 10-15 GBP. SSB capable radio, minimum 500 GBP, even second hand.

      I would rather fix other things that i was not able in the mcHF – more LPFs, ideally one per band. Improve the PA. Have more PCB real estate and have linear signal distribution of RF signals, not modules sitting on top of each other (bottom/top layer).

      Off course the STM32F7 is more powerful, i will have large SDRAM, and large 5 inch screen, it would be possible to have digital mode implemented at later date. I will try to keep both USB ports (GPIO allowing off course). Right now i have only 59 pins left, i still need to attach a FPGA somehow.

      73, Chris

      1. Steve C.

        The incentive for integrated digital modes was equipment portability with a minimum of “stuff”. Finding RF-quiet places and using minimum of power to communicate with others is the idea (I live in a major city, that’s why). Less equipment, less cables, less batteries to worry about, that’s the thinking.

        Of course, with today’s $50 multicore ARM boards and affordable displays, one could always get creative with packaging and still have a simple, portable, durable setup…

        I’m mostly curious about what your vision is for this. You packed an amazing amount of componentry in the mcHF’s form factor, and yet the discrete component pads remained big enough to make it practical and buildable by hand. That’s quite an accomplishment. But, that necessary “stacking” of modules had a price, too.

        1. m0nka Post author


          I am quite open to ideas, i haven’t set on anything yet, except maybe the larger LCD. The whole fun is with designing, experimenting and building it. When finished as product – i totally loose interest in it, hehe.


      1. Thomas, DL8EBD

        thx Chris, that sounds great.
        I ordered a mcHF full kit last Monday from you, but if you start with a first run of the PRO version I would like to be one of the first “beta tester” – I can hardly wait for the PRO !! 🙂

        Thomas, DL8EBD

        1. m0nka Post author

          Hi Thomas,

          Sure, as fast as i have the board made, will offer to beta testers. Thanks for your support!


    1. Reto Meyer

      Hallo Chris,

      Nice new project. If you need other beta testers, I’m very interesting in this project. Otherwise I also can wait if the project is available for public.

      Vy 73


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.