Emil's Projects & Reviews: Malahit Software Defined Radio

Malahit Software Defined Radio 23rd December 2020

The Malahit (Malachite) SDR is a very compact radio hosted in an aluminium case only 100×74×27mm in size.

The version I've bought is manufactured in China but the design originated from Russia. The schematic is almost identical to the original except some PCB connectors (J5 & J7). The RF front-end is minimal, just a wideband pre-amp (BGA614) and some LC Π filters (0-12MHz-30MHz-60MHz-120MHz-250MHz-1GHz-2GHz) to separate the huge frequency range. An optional board with better filtration and another narrower pre-amp for the HF bands can be connected via J7 and is inserted in front of the antenna connector. On this chinese clone the V_bat signal is missing so you need to connect it from elsewhere (and there isn't sufficient space inside the case for another PCB anyways).
A translated manual is also available.

A few things that I dislike on this SDR:

the touchscreen is resistive, imprecise and it struggles to register presses
the encoder wheels often skip increments (badly written software)
the 22MHz oscillator frequency drifts especially after power on
the speaker is on the back so you cannot lay the SDR on a desk because the sound will be completely muffled

You can see here the convoluted way the encoders are read: File: encoders.c

uint8_t       encoder_1or2, encoders_conf;
uint32_t      encoder_mode[2];
int32_t       encoder_val[2];
const int8_t  encoder_deltas[16] =
    { 0, -1, 1, 0, 1, 0, 0, -1, -1, 0, 0, 1, 0, 1, -1, 0 };

// the encoders function is called from EXTI_Int 0-3

int
encoders( int bit_enc )
{
  int           PC_b1b0;
  int           PC_b3b2;
  int           delta;
  int           result;

  switch ( encoder_1or2 )
  {
    case 0:
      PC_b1b0 = GPIOC->IDR & 3;
      if( encoders_conf & 1 )
      {
	delta = PC_b1b0 + 4 * encoder_mode[0];
	encoder_mode[0] = PC_b1b0;
	result = encoder_val[0] + encoder_deltas[delta];
	encoder_val[0] = result;
      }
      else
      {
	delta = PC_b1b0 + 4 * encoder_mode[0];
	encoder_mode[0] = PC_b1b0;
	result = encoder_val[0] - encoder_deltas[delta];
	encoder_val[0] = result;
      }
      return result;
    case 1:
      PC_b3b2 = ( GPIOC->IDR >> 2 ) & 3;
      if( encoders_conf & 2 )
      {
	delta = PC_b3b2 + 4 * encoder_mode[1];
	encoder_mode[1] = PC_b3b2;
	result = encoder_val[1] + encoder_deltas[delta];
	encoder_val[1] = result;
      }
      else
      {
	delta = PC_b3b2 + 4 * encoder_mode[1];
	encoder_mode[1] = PC_b3b2;
	result = encoder_val[1] - encoder_deltas[delta];
	encoder_val[1] = result;
      }
      return result;
  }
}

// horrendous coding from now on:
// every 6 SysTick interrupts process_encoders is called
// this is some kind of averaging over the last 4 values

uint32_t encoder_last4[8];
uint32_t encoder_update[2];
uint32_t last_4_pos[2];
int      encoder_sgn_dbl[2];
int      encoder_rem[2];

void
process_encoders( void )
{
  int idx;
  if( encoder_1or2 )
  {
    idx = last_4_pos[1] + 4;
    encoder_sgn_dbl[1] += 2 * encoder_val[1];
    encoder_last4[idx] += abs( encoder_val[1] );
    encoder_update[1]++;
    if( encoder_update[1] )
    {
      encoder_update[1] = 0;
      last_4_pos[1]++;
      last_4_pos[1] &= 3;
      encoder_last4[4 + last_4_pos[1]] = 0;
    }
    encoder_val[1] = 0;
  }
  else
  {
    idx = last_4_pos[0] + 0;
    encoder_sgn_dbl[0] += 2 * encoder_val[0];
    encoder_last4[idx] += abs( encoder_val[0] );
    encoder_update[0]++;
    if( encoder_update[0] )
    {
      encoder_update[0] = 0;
      last_4_pos[0]++;
      last_4_pos[0] &= 3;
      encoder_last4[0 + last_4_pos[0]] = 0;
    }
    encoder_val[0] = 0;
  }
}

int 
i_read_encoders(uint32_t *average, signed int divider, int encoder_nr)
{
  uint32_t *last4; 
  unsigned int v1, v2; 
  int enc; 
  int result; 

  last4 = &encoder_last4[4 * encoder_nr];
  v2 = 0xf00 * (encoder_update[encoder_nr] + 3);
  v1 = 80000 * (*last4 + last4[1] + last4[2] + last4[3]);
  enc = encoder_sgn_dbl[encoder_nr] + encoder_rem[encoder_nr];
  encoder_sgn_dbl[encoder_nr] = 0;
  *average = v1 / v2;
  result = enc / divider;
  encoder_rem[encoder_nr] = enc % divider;
  return result;
}

uint32_t encoder_clicks[10] = { 20, 30, 10, 20, 5, 15, 2, 10, 1, 6 }; 
uint32_t var_is_4 = 4;

// finally when the code wants to read an encoder value it calls read_encoders
 
int
read_encoders(int *clicks, int encoder_nr)
{
  int result; 
  signed int select; 
  uint32_t average; 

  result = i_read_encoders(&average, var_is_4, encoder_nr);
  if ( average > 0x1D )
    select = 0;
  else if ( average > 0x13 )
    select = 1;
  else if ( average > 0xE )
    select = 2;
  else if ( average > 9 )
    select = 3;
  else
  {
    if ( average <= 5 )
    {
      *clicks = 1;
      return result;
    }
    select = 4;
  }
  *clicks = encoder_clicks[2 * select];
  return result;
}

// all of the above to read two encoders ...

Instead of generating only 2 interrupts (one per encoder), all 4 EXTI lines trigger one and call the 'encoders' function. Then the code makes use of a step table (encoder_deltas) to change the number of steps. Two bits in encoders_conf (a value which is also saved in FRAM) reverse the direction of each encoder if needed.

Encoder A/B Line Captures
anti-clockwise	clockwise
falling edges	rising edges

After hooking a scope to the encoder outputs I was surprised how clean the signal was. There was no noise at all on the contacts. Rising edges were as calculated and the falling edges perfectly sharp (less than 100ns). This leaves just the software to blame.

The proper way to read an encoder is to generate an interrupt on the falling edge of one input (for steps) and then in the interrupt read the other input value (and that gives you the direction).

I have replaced the encoders code with a cleaner version: encoders_fixed.c and my encoders ~~behave better now~~ work exactly as they should ~~they still don't register all the clicks.~~ and don't miss any clicks. The hardware debouncing RC constant is given by the port pull-up resistor (40K) and the 1nF capacitor and that gives only 30us (way too low, should be in the ms range).

I've fixed another bug that was driving me crazy: sometimes the radio was waking up by itself (and completely draining the battery). This was happening after about 10 seconds of turning the radio off. I was looking for missing or to weak pull-ups but it was something in the firmware.

The watchdog IWDG is enabled and in the main loop you have to write to it more often than 10 seconds or your CPU will reset.
When you shutdown the radio there is no way to disable the watchdog once it has been started but you can freeze its counter when entering standby mode.

In main():

program bit IWDG_FZ_SDBY in FLASH->OPTSR to freeze watchdog counter in standby
program BOR bits in FLASH->OPTSR for V_BOR2 (2.3V)
program bit WDGLSD1 in DBGMCU->APB4FZ1 to stop watchdog in debug mode

The shutdown steps are:

save all the relevant variables in FRAM
play "73" in Morse code
reprogram the IWDG to 500ms and also request a reset by setting the SYSRESETREQ bit in SCB->AIRCR
after the reset (whichever of the above happens first) the watchdog is disabled
before the main loop check the battery voltage to see if early low power mode is needed

In low power mode:

disable all peripheral clocks and interrupts
enable the wakeup interrupt (PC13) as the only source for power on
program PWR->CPUCR and select Standby (not Stop) for D1,D2,D3 domains in DEEPSLEEP mode
set the DEEPSLEEP bin in SCB->SCR and end with 'wait for interrupt' __wfi()

All of the above works fine except when you put the chip in debug mode. In the debug session the watchdog is disabled but when the CPU goes into standby mode then the IWDG_FZ_SDBY bit has no effect, the watchdog is still enabled (this is a bug in silicon) and it will wake the radio up after 10 seconds. Resetting the chip or disconnecting the STLinkv2 wires doesn't help. The chip stays in this mode until you power it down (disconnect the battery).

There is a long discussion on the STM32 forum with people not being able to freeze the watchdog in shutdown or standby modes. From there I've got the suggestion of resetting the MCU debug control register before entering DEEPSLEEP mode and that worked. I have changed the 'low_power_mode' function and inserted one instruction before its end:

  DBGMCU->CR = 0; // workaround: add this instruction before entering DEEPSLEEP
  SCB->SCR |= 4;
  __dsb();
  __isb();
  __wfi();

Another way to make sure your watchdog is always stopped is to put a flag in the backup memory and then after the reset but before enabling the watchdog, test that flag and enter DEEPSLEEP if required.

The code never resets the backup domain and that survives CPU resets and even firmware updates. The only way to reset the backup domain is by removing the battery (the voltage on V_bat) or by setting bit 16 in RCC->BDCR register to set all backup registers to default. The firmware doesn't write to the RTC->CR register and bit 10 in this register is the wakeup timer interrupt enable. If this bit happened to be set then you will get a wake-up signal every RTC->WUTR ticks and this could also wake up the radio.

I've re-written the RTC code. I disable all the RTC interrupts and also use a more recent default date for the calendar. rtc_fixed.c

There are 2 versions of the NAU8822 audio CODEC chip (A and L). The difference between them is that the 'L' has an extra bit in the PLL registers to select the PLL output frequency divided by 2 instead of only 4 in the 'A' chip.

NAU8822A/L Master Clock

The master clock MCLK has to be exactly 256 times higher than the sampling rate. The PLL inside the NAU8822 only locks between 90-100MHz. The maximum sampling rates when using the PLL are:

100MHz / 4 / 256 = 97.6kHz for the 'A' chip
100MHz / 2 / 256 = 195.3kHz for the 'L' chip

The only way to increase the sampling rate is by not using the onboard PLL and provide the MCLK from the STM32 PLLs (which has plenty). For a 160kHz sampling rate you need a 40.96MHz clock. You can get that if you program the fractional PLL2 in the STM32: 22MHz / 2 * 69 / 9 and a fracn2 of 209 to 81.92MHz and with another division by 2 in the SAI1 peripheral you can get exactly the desired MCLK. Now the question is how well is the PCB track laid and shielded to carry a 40MHz clock and also will the ADCs and DACs in the older NAU8822A work with an almost 4 times higher sampling rate.

The waterfall bandwidth can be selected between 160kHz, 80kHz and 40kHz so I presume the master clock is adjusted accordingly. If you experience audio quality problems with the NAU8822A chip you can just reduce the displayed bandwidth. Alternatively the NAU8822L chip can be purchased from Aliexpress for very little (I can confirm that the linked seller sent me the 'L' version as listed). Replacing it (QFN32 package) is quite an easy task using just a hot air rework station.

Even with the above annoyances I think it is an excellent deal to get a portable SDR in an aluminum case for just 82$ delivered.

You can use this STM32CubeMX project file as a starting point you you want to write your own software for the platform.

I've written a linux screen emulator Malahit-screen which can be used to produce PNG snapshots of how text will look like on a 480×320 RGB screen.

To obtain the flash binary file first remove the RAM fill region (starting with line ':020000043002C8') and the reset address (the line before last) which are not part of the image. If you don't remove the RAM region your converted binary file will also contain the gap between the end of the flash and the start of SRAM2 and this will make the size of your converted file hundreds of Mbytes.

For conversion, the easiest way is to use objcopy:

    objcopy --gap-fill=0xff -I ihex FW_xxxxx.hex -O binary FW_xxxxx.bin

To program a new firmware in DFU mode:

connect the USB cable and turn radio off
press and hold the encoder button (the one opposite to the power switch)
turn the radio on and then release the encoder button (the screen will stay black)
in linux you can check that the CPU is in DFU mode with 'lsusb' command

Convert iHEX file to binary (ihex2bin) then use:

    dfu-util -R -a 0 -s 0x8000000 -D FW_xxxxx.bin

or convert to DFU (hex2dfu - C source code) then use:

    dfu-util -R -a 0 -D FW_xxxxx.dfu

I prefer to use the SWD port directly. For this you need a STLinkv2 programmer. The SWD connector on the board misses the 3V3 power rail but you can get that from the common anode dual LED (near TP4056 charger which is not soldered). The 3V3 is needed to detect the V_target presence. If you use a STLinkv2 clone (the USB stick shaped one) you won't have the Reset signal available (the one labeled RST is from the SWIM interface). Reset is available on port PB0 (pin18 of STM32F103) inside the programmer. Without Reset you'll have some trouble halting the STM32H7.

Start openocd:

    openocd -f interface/stlink-v2.cfg -f target/stm32h7x.cfg

open a telnet console:

    telnet localhost 4444

and then issue the following commands:

    halt
    flash read_bank 0 backup.bin 0 0x100000 (if you want to save your current firmware)
    flash erase_address 0x8000000 0x100000
    flash write_bank 0 firmware.bin 0
    reset

to program your new firmware.

The firmware for this radio (version 1_10a at end of Jan 2021) needs to be first activated.

The registration code is an 8 byte hash of the CPU signature ID (12 bytes).
This hash is then stored at (word) locations 0x7E & 0x7F in the SPI F-RAM (FM25W256) and compared every time the radio is powered on.

Starting with version 1_10b all the ID hashes (actually a hash of the hash) issued by the author are stored in firmware (just a little under 1000 at the time of the writing).
The activation code algorithm remains the same, but the radio (deliberately) malfunctions if your code is not in that list.
This means the author has to generate new firmware images every few days after new registrations.

This leaves users with 3 choises:

Purchase an activation code from the author and wait a few days
Stay with version FW_1_10a.hex (google for it) and generate your own code bellow
Patch the flash image if you have the know-how:
This involves patching the code to "find" your hash in that list.
There are also 6 regions which are checksumed but the code verification is not enabled for now.
I can't do the patch for you because I'm not allowed to distribute other people's firmware (modified or not).

To unlock (activate) your Malahit SDR firmware please enter the CPU ID code
Use this format xxxx-xxxx-xxxx-xxxx-xxxx-xxxx (where x are hex nibbles)

Tags: malahit, sdr.

Emil's Projects & Reviews

OpenHardware & OpenSource

Comments On This Entry

Add A Comment

Tags

Archive

Your Name
Your EMail
Your Comment