Emil's Projects & Reviews

OpenHardware & OpenSource

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 Vbat 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.

Malahit SDR - PCB

A few things that I dislike on this SDR:

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.


Screen Captures (FW_1_10c)

Portable SDR aluminium case
Narrow FM
Wide FM
Retro Scale
Edit Station
Load Preset
Hard Menu
Visual Menu
Audio Menu
Mode Menu


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:

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.


Radio Firmware

In main() inside the main program loop there is this:

 GPIOA_MODER &= 0xF3F3FFFF;

which makes PA13 (SwDIO) and PA9 (OTG_FS_VBUS) inputs, effectively interrupting any ongoing debug session.
I don't know if this was deliberate or just a programming mistake.
To be able to debug and breakpoint the firmware I've replaced it with:

 GPIOA_MODER &= 0xFFF3FFFF;


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():

The shutdown steps are:

In low power mode:

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.

This bug has now been fixed in the original firmware since version 1.10c rev2


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 Vbat) 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


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

Malahit - Splash Screens

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:

Convert between iHEX and binary formats (ihex2bin / bin2ihex / stm2ihex / stm2ihex.exe / C source code ) then use:

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

or convert to DFU (hex2dfu / hex2dfu.exe / 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 Vtarget 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.cfg -f target/stm32h7x.cfg -c "reset_config connect_assert_srst"

open a telnet console:

    telnet localhost 4444 

and then issue the following commands:

    reset 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.

Starting with version 1_10c activation codes are not used any more.
You have to send your CPU ID to the author and he will include a hash of that number in the new released firmware (1600 registrations by now).

This leaves users with 3 choises:

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

- - - - -

Tags: malahit, sdr.

Comments On This Entry

Georgy Submitted at 14:35:48 on 29 December 2020
I am author of this project. Delete this material for unlock code - only the developers of this project are entitled to this, but not you.
Jim Submitted at 15:48:19 on 3 January 2021
Hi, I have this same radio, but have had no luck with the dfu files in the links on Linuxslate. Every time I try tp convert the FW_1_0f.hex file the F
DfuFileMgr says it is an incorrect file to convert to DFU file. None of the dfu files from the site will load with DfuSeDemo. It complains that the files are the wrong type. Any ideas? I do get the radio in dfu mode using the holding the volume encoder while powering on the radio.
Emil Submitted at 18:34:17 on 3 January 2021
Remove everything from this line :020000043002C8 to :00000001FF (excluding) which is the last line of the hex file .
This should not even be there, it is only initializing RAM and a record which points to the start address.
Then use any utility to convert this back to DFU.
Ivan Submitted at 14:34:37 on 6 January 2021
I have Malahit activated. Can I see and read the activation code using STM32CubeProgrammer ?
Emil Submitted at 14:54:00 on 6 January 2021
No you can't. You need to write a program to dump the F-RAM and flash it to the STM32H7. A much easier way is to hook a StLinkV2 to the SWD connector and read the CPU ID, then use this page to generate the activation code again.
Dan Submitted at 23:07:25 on 6 January 2021
Firstly thank you very much for such valuable information!!!
I was curious and tried to find out the hash algorithm used to generate the unlock code. Is implemented in the firmware a hash algorithm from scratch?
Emil Submitted at 00:21:19 on 7 January 2021
I've called it "hash" but it is really a non-linear function implemented in firmware. It is not very complex but it is not trivial either.
Jim Submitted at 23:53:23 on 8 January 2021
Emil, That worked great. Thank you.
Nemesys76 Submitted at 06:54:18 on 13 January 2021
I have created a keygen, it gives the same results as yours.
I have a question for you, I'm sure you will understand with a few details.
00000025000000E6000000BC...

The question concerns the first E6 on the list.
From the firmware it would seem that the total sum is put in its place (byte1-> 12 + 1 + 12). Do you agree?
Emil Submitted at 17:58:34 on 13 January 2021
If I have wanted to give a keygen away I would have done so.
Instead I provide a page where people can upgrade their SDR firmware at no cost.
If you want to know more feel free to investigate by yourself.
Ernest Submitted at 07:26:39 on 14 January 2021
I would like to thank you for this page. Thank you very, very much.
Ivan Submitted at 12:21:11 on 25 January 2021
That worked great. Thank you.
Earl Submitted at 22:57:36 on 29 January 2021
Is there a way to find out the CPU ID other than using the STLink programmer?
Emil Submitted at 02:16:44 on 30 January 2021
It is prompted on the screen for you in the full version firmware if you haven't already unlocked it.

Obviously the CPU can read its own ID so you could write a program to dump it as ASCII via the USB connector (CDC class) and you can flash that in DFU mode.
Noname Submitted at 20:02:04 on 5 February 2021
If everyone just hacks a cheap China clone and is able to upgrade free of charge how do expect the development of this project to continue? The first comment on here is legit from George. From what I've seen online the legit malachite is a great piece of kit and anyone bypassing the purchase of the orginal upgrade firmware is only contributing to the demise of future upgrades. I intend to purchase the original Russian version of this sdr as soon as feasible. Its a shame that not everyone sees the bigger picture.
Dan Submitted at 07:54:58 on 12 February 2021
Recently a new SW version 1_10b has been released and it looks like this SW is invalidating some keys. Furthermore you are not able to remove the stored key so that you can enter a new one.
Axel Dörner Submitted at 10:24:09 on 12 February 2021
I have just installed FW1_10b. Since then, the audio output has been spinning. It beeps all the time and the BEEP LVL changes on its own. I cannot change the BEEP LVL.
With FW1_10a everything worked fine
Axel Dörner Submitted at 12:39:27 on 12 February 2021
Georgy changed the algorithm that always compares ids between old and new with the purpose that for 1.10a cannot work if the activation code is old. He's too arrogant and arrogant.
Emil Submitted at 15:52:47 on 12 February 2021
I wouldn't bother with new firmware images for at least 6 months from now. As long as a new firmware doesn't have a "must-have" new feature I don't care.
FW1_10a is good enough for me.
Gustav Submitted at 09:40:00 on 13 February 2021
Thank you for your update about FW_1_10b. There are a lot of people who paid and were scammed by chinese sellers who said it was upgraded by using a legit key from the author so that buyers would not wait or mess with the firmware when the radio would arrive. They now basically have a brick in their hands. I'm aware you can't distribute a patched firmware but I think we would be thankful if you could explain how to.
I see that 3 addresses are changed when the author updates the firmware with new hashes.
Klaus Submitted at 12:17:09 on 13 February 2021
>>They now basically have a brick in their hands.
Gustav, you should be able to flash 1_10a - BUT only via ST-Link.
read this (linuxslate)
there is a manual-pdf, at the end there is a step by step instruction.
Dont ask me, it is a mess...
My Malahit is ordered, so I have no experience and practice.
If You like to waste Your time, read the forum CQHAM.RU
Emil Submitted at 17:06:21 on 13 February 2021
It is entertaining to read all the problems people have with the 1.10b firmware. Most of these come when people (who purchased a license) are updating their radios via DFU.

I don't think the author realized that the iHEX files he distributes contain "holes" which are just small regions of FFs. If those regions are larger than a page then the DFU upgrade would not touch those pages and they will retain what was previously programmed. The flash content is verified twice: the first half then the entire 1MB. If the untouched pages don't contain FFs then the CRC will obviously fail. The CRC code verification is disabled in version 10.b but I expect it will be enabled in future versions.
Gustav Submitted at 17:59:59 on 13 February 2021
>> Klaus, thank you for your suggestion. I'll order the ST-Link so I can hopefully restore it. I've also read their forum and it is quite hilarious how people are having issues while updating for the reason that Emil explained - I guess.
Author says the update process is the same and it doesn't have any issue but I trust in what Emil says more. He also says to use STM32CubeProg for this update.
I still do believe that Emil will save us all, he seems to have more knowledge than the author himself.
Friedrich Submitted at 18:34:06 on 13 February 2021
On Facebook group called "China Malahit / Malachite Users" you can see how people feel ripped off by sellers who obviously don't reply. We just innocently bought the activated radio because we didn't want to spend our time flashing a firmware, contacting the Author, then waiting for a code. Instead of fighting against bad sellers the Author decided to go against radio enthusiasts. It is such a pity that this project is taking this bad turn. Please Emil, help us if you can.
Emil Submitted at 19:08:14 on 13 February 2021
STM32CubeProg erases the entire flash before programming. That's the reason it is recommended over dfu-util.
This is a non-issue for version 1.10b because the code verification is disabled for now so you can still use dfu-util without erasing the entire flash.

Friedrich, I have explained clearly what your options are. If the re-seller payed the author for the code then your activation code should already be inside the new firmware. Alternatively you can use openocd to dump your CPU ID: 'mdb 0x1FF1E800 12' and email that to the author if you think it was a legit purchase. In fact the CPU ID is displayed on the second boot screen in version 1.10b so you don't need to use any tool. If it wasn't legit then just stay with version 1.10a.

Even the "bricked" radios are always recoverable. A STlinkV2 clone costs less than 5$ on ebay / aliexpress. If you want to stick to DFU mode then just tie the Boot0 pin to high to force the CPU jump into the bootloader after a reset (and desolder Boot0 after you've flashed it).
Emil Submitted at 07:02:29 on 14 February 2021
Against my initial will of not to look at this new firmware, I've spent a few hours disassembling the code out of curiosity and the brouhaha around this subject.

I have found out that it's not too hard to patch and make future firmware images fully functional.
I've decided against sharing this because I don't want to piss Georgy even more than I already have and I also don't want to do this for every single version from now on.
Lutz Submitted at 12:30:43 on 16 February 2021
Maybe someone is interested. I'm already working on an alternative firmware for the malachite platform. There is much potential which is not used at the time.
Tony Submitted at 15:13:36 on 16 February 2021
Lutz, it would be great and I'm more excited as you say that there is much potential that is not used yet in the official firmware. Is there a way to keep in touch with you? Congrats for your project!
Emil Submitted at 16:51:16 on 16 February 2021
Lutz, I think that's a very good idea. I have always thought that the firmware should have been open source but that's the author's choice.

One can compare this with a very similar project, the mcHF transceiver. It uses same family of processors (STM32F4, STM32F7) and a similar screen and layout but it covers only the short wave bands. It also transmits up to 15W and it costs 3 times more. The firmware for that radio (and its clones RS-918) is now open source under GPLv3 UHSDR Project and it covers multiple hardware platforms (mcHF, OVI40, MiniTRX, TRX Eagle).
Lutz Submitted at 18:18:21 on 16 February 2021
OM Frank, DD4WH spent already a lot of time and work on his Teensy convolution SDR, which is also based on an STM32 and a msi001. No need for reinventing the wheel. (On GitHub).
Jan Submitted at 19:43:39 on 16 February 2021
I purchased 1 activated malahit and 1 not activated and only the two first strings of the cpu-code where different, the next 4 strings where the same.When I updated the activated one with the 1-01b fw it was not working ok anymore the freq was 10kc off so I got back to 1-0f and again up to 1-01a and it's ok again
Jan Submitted at 21:03:27 on 16 February 2021
Lutz, I'm using the Malahit as a receiver on a QSK switch because it's better receiving as my ic7300, so I'm intersested in your open source option
Jan Submitted at 10:18:35 on 18 February 2021
Back to fw 1.0f because using fw 1.10a and switch on of a few times the frequentie is not acurate an more it's +10 kc off, this is by the official activate as by the not official activate one.
Emil Submitted at 02:15:00 on 19 February 2021
Is everyone having problems operating the encoders on this radio? I think I have found the culprit: badly written software. I'll make a try with a test application to see if I can read the encoders without any misses or skips.
Andreas Submitted at 17:11:00 on 19 February 2021
Hallo,
I can cofirm, the encoders don't work well. Some times there are two steps turning only one. We had to change the 22 MHz clocks also. It seems like the receiver (PLL) has some trouble closed to 400 MHz.
I and some friends too would appreciate another firmware without restrictions very much. We would like to give some motivation to the programmers. We look forward hoping things will improve....
sad Submitted at 22:24:37 on 21 February 2021
Thanks for the .ioc file!
What did you use to get the c code? retDec?
Emil Submitted at 02:53:16 on 22 February 2021
The .ioc is updated.
IDA + ARM decompiler and then manual editing. The decompiler is just informative, you can't rely on it to produce working code. Assembly is still king.
Synce Submitted at 08:04:33 on 22 February 2021
Hello, I follow the work of Emil and my other friends with great interest.
Hdi Submitted at 18:26:00 on 24 February 2021
Hello, how to download the FW 1.1a?
Thank you ! :)
Emil Submitted at 19:09:21 on 24 February 2021
Search, I cannot distribute other's people firmware.
Axel Dörner Submitted at 02:29:26 on 26 February 2021
Malahit DSP uses a sampling rate of 160ksps for NAU8822LYG.
Malahit China uses NAU8822AYG chip to cause a "cracking" sound at some point due to the low sampling rate.
Please help with modifications. Thank you very much.
Emil Submitted at 03:55:20 on 26 February 2021
What is the difference between these 2 markings? I cannot find anything in the datasheet. My radio has the NAU8822AYG and I don't hear any "cracking" as you describe. Maybe my hearing is not what is used to be ;-)

The maximum sampling rate for the NAU8822 is 48KHz with 24bit and that's better than CD quality (which is 44.1KHz with 16bit samples). So what are you talking about?
gmtii Submitted at 13:40:41 on 26 February 2021
wfm and spectrum/waterfall needs >>48khz, so Malahit uses default sr of 160khz. The codec A version does not support that SR as datasheet so it is working overspecs. Some chinese clones uses that A cheaper version with some cracking noises, so it's recommened to use the low power and 192khz L codec version.
Emil Submitted at 20:31:58 on 26 February 2021
gmtii, thanks for the clarification.
Matthew D. Submitted at 21:21:52 on 26 February 2021
Thanks for all the help guys. As a new chinrseium owner I am waiting for some improved firmware. Until then I will remain on TEST firmware.
Scott-land Submitted at 17:12:33 on 27 February 2021
Hopefully an open source firmware gets developed for this little radio, George is making a new DDC version anyway
Dan Submitted at 13:24:53 on 28 February 2021
I am trying to understand the internals of the SW using radare2 but I am having really hard time with this tool. I would like to try IDA for ARM but it looks like it is very expensive tool for a personal use. Is there any trial?? I would like to try your patches. I guess I need to disassembly & decompile de firmware, right?
Emil Submitted at 15:23:10 on 28 February 2021
It is a complicated process to apply C patches to an existing binary. IDA will only help you with disassembly and yes it is very expensive. A free alternative is ghidra (and it also includes a decompiler).
Jan Submitted at 18:45:20 on 28 February 2021
#Dan do a search for freeware in the support webpage from IDA
you will get version 7
Matthew D. Submitted at 08:07:33 on 2 March 2021
Does anyone know if the 250mhz to 400mhz gap in the Malachite SDR is a
hardware limit or a firmware limit? I ask because it is not illegal to listen there in the USA where I live.
Emil Submitted at 16:55:57 on 2 March 2021
It is a hardware limitation of the PLL in the MSi001 chip. The gap is actually a little smaller, only 263MHz-390MHz

For details see 'msi001_set_tuner' function in any linux kernel source tree (file drivers/media/tuners/msi001.c)
Matthew D. Submitted at 22:12:28 on 2 March 2021
Thanks Emil, I was afraid of that.
Dan Submitted at 02:02:43 on 3 March 2021
I'd like to develop custom firmware for Malahit to scan and decode all the VOR radials it finds (it's an old aircraft navigation system) and display them on the screen. I have a great deal of experience with embedded real-time systems but have never used this particular STM32 platform or its tools. Would love to get some pointers for a quick start from this esteemed forum. Is there some starter code on github that will work, or am I looking at decompiling?
Emil Submitted at 02:42:19 on 3 March 2021
I don't see how decompiling will help you in any way. All you need is the schematic.

For a quick start I would recommend STM32CubeMX (I've done the pin-out for it in the above mentioned ioc file). It produces bloated code compared to bare bone CMSIS but you can worry about that later (or not at all because you have 1MB of flash).

You need to start writing drivers for the screen (ILI9488), the touch panel, MSi001, NAU8822. Smaller tasks are encoders, battery (ADC), charger, deep-sleep mode and FRAM (if you want to use it).

Lutz announced that he started an open firmware for this platform but there is nothing on github yet. I am not planning to take part in the open code effort.

I have embedded platforms experience too (STM32 family in particular) and I appreciate the effort to a good full week of programming until you get a working prototype.
Tim Submitted at 17:37:07 on 4 March 2021
For development start with UHSDR Project.
=> Same Function
=> Same CPU

Needed Adaptions:
- Adapt Codec
- Adapt MSI001
- Adapt UI

This would not be a big deal...
gmtii Submitted at 20:57:01 on 4 March 2021
Here we have some Msi001 code
George Submitted at 18:12:08 on 7 March 2021
Emil, Thanks for the great work! I have two units for special projects. I stopped upgrading FW at version 1.10A.

It seems worthwhile to note that CN Malachites have many hardware problems that cannot be fixed with firmware. This includes abundant noise generation due to poor crystal oscillator, incorrect capacitor in MSi001 circuit, numerous birdies, poor sensitivity, noise pickup from touch screen and more. For about the same money an SDRplay RSP1A performs much better with much lower noise floor.

Even so, an open source firmware solution would be welcomed. There are some applications where the above problems can be mitigated.
Emil Submitted at 19:07:40 on 7 March 2021
Not all clones from china are equal. I've seen at least 4 different models being sold (one of them having the I/Q lines reversed). I'm pretty happy with the one pictured above and I have several quality radios to compare it with (ICOM-746, Tecsun PL-880, Tecsun PL-380, XHData D-808, Tecsun R-9700DX, Tecsun R-9012, Degen DE321).

From the problems you've listed above it is just the 22MHz oscillator which is of lesser quality as it drifts and probably has high noise figure too. That's not to hard to replace though.
Matthew Davies Submitted at 05:56:08 on 9 March 2021
I'm curious if the thicker case, larger knob clones are a quality model.
George Submitted at 17:51:23 on 12 March 2021
Matthew, One of my units is as you describe. It has 4 layer PCB, not like others. However, it has problems with pre-amp not working (actually acts as attenuator). The large knobs are reversed (top/bottom) from other models. Large knobs makes skipping even more pronounced. In addition it has same big crystal noise and drift, incorrect MSi001 capacitor which gives humps in spectrum - like all other ones. The speakers are open in the back (no grill), which can lead to damage. But otherwise it looks nice.

It works well on AM FM and on the lower ham bands (1-30 MHz) where RF sensitivity is not issue, but above 30 MHz it is very poor. Would not recommend it. May sell this one for lower ham use, when project is finished.
Matthew Davies Submitted at 23:39:59 on 12 March 2021
Thank you George. Your information helps.
Malahite Fan Submitted at 00:24:29 on 17 March 2021
>> I'm not allowed to distribute other people's firmware (modified or not).

However, you could create a *.bps (differential patch) with Flips (can be found on GitHub). Take original firmware 1.10a and create a patch to your improved firmware. The created bps file was very small. You could distribute it without the original firmware, it only contains your changes. I would be very interested in the improved encoder version.
Emil Submitted at 21:32:13 on 17 March 2021
I've created the patch for 1.10b and I have no intention to duplicate the work for an older firmware. For 1.10b onward I cannot distribute a diff because the firmware is constantly changing. Every time new registered users are added functions and tables change position.
Not_So_Anonymous Submitted at 04:49:05 on 18 March 2021
Well, I did the "honorable" thing and paid Georgy for the code AFTER verifying that the radio worked with the demo code. (I bought exactly the same radio that Emil shows in this thread.) ** Sadly the audio turns on and off (what Axel called "spinning") with the Beep Level changing from 2 to 15 in sync with the audio pulsing on and off. The radio is unusable. SADLY Georgy has removed all versions except 1.10b so I try what worked for Axel and the rest of you....i.e. version 1.10a. Any idea how I can get that version ?
jaap Submitted at 10:21:18 on 18 March 2021
Search facebook China Malahit / Malachite Users group ........ announcements
Not_So_Anonymous Submitted at 16:25:32 on 18 March 2021
Thanks.....that did the trick jaap ! BTW, (while awaiting an answer here) I did try the "Reciever_msi001.hex" which is the ONLY other firmware at Georgiy's website. Alas, it locked up the device. ** I then soldered on jumper 1, did the transfer of v1.10a, removed the jumper and it came right up. MORE TO THE POINT, I did NOT have to put in a code and it now receives without the audio spinning, studder and above 400MHz...Again, many thanks to the group here and on facebook !!!
Matthew Davies Submitted at 05:48:27 on 19 March 2021
Couldn't find 1.10A for myself. Does using it require soldering a jumper?
jaap Submitted at 09:31:37 on 19 March 2021
I was able to update my radio that came with fw 1.0f to fw 1.10a without jumper wire and disconnect battery. search "Malachite DPS software update-Hamfiles" there you will find a lot of info.
Matthew Davies Submitted at 22:47:54 on 19 March 2021
I think that means your radio came pre-updated. You might have issues when you try to update past 1.10B. I myself have a virgin TEST firmware in mine so I must solder and run cryptic loading software. Oh joy. It's not too tough, just unnecessarily complex for what's being done in 2021.
Dan McLaughlin Submitted at 18:22:39 on 20 March 2021
I am so confused all i am trying to get is the serial number so i can upgrade the firmware. The is no place that gives a simple answer .
Axel Dörner Submitted at 19:56:23 on 20 March 2021
@Matthew Davies, Dan McLaughlin, ...
visit : www.facebook.com/groups/2673986352928589
All of your problems will be answered.
Matthew Davies Submitted at 00:55:43 on 21 March 2021
Axel Dorner: "This Content Isn't Available Right Now."
Frans Submitted at 11:47:02 on 22 March 2021
I bought a registered Malachite in China. He came in, but didn't work. Black screen after looking around I have flared him with the last firmware.
Now he is no longer able to use rods badly on the encoders and a line on the screen. The Chinese supplier knows nothing. Does anyone know?
Not_So_Anonymous Submitted at 12:49:56 on 22 March 2021
Anyone else not able to get the clock running ? i.e. It simply doesn't run even if I manage to get past saving the values. Alas, I can't even save the settings past a turn off and on ! It simply reverts back to "01.01.2000 00:00"
Jan Submitted at 21:15:56 on 22 March 2021
#Not_So_Anonymous
Check if the battery is full(LG), if not no battery and no clock setting save
Jan Submitted at 21:57:24 on 22 March 2021
#Dan McLaughlin,
You have to update a new FW 101a or 101b to get the nr. than you go to the Russian MaLachhte site and ask for the registration code
Jan Submitted at 22:10:46 on 22 March 2021
#Frans,
Try to send it back to the seller or ask your money back, when you payed with PayPal no problem atall.
Not_So_Anonymous Submitted at 04:30:42 on 23 March 2021
Jan.....not sure what "(LG)" means....the battery is functioning at over 4 volts...and I can run the radio from the USB port at 4.14 volts... The clock does not run, which is perhaps part of the problem.
Roger Submitted at 09:49:21 on 23 March 2021
Like you said, my unit's encoders often skip the steps. the FW is 1.10a. If you can develop a patch, that can flash it in, that will help a lot users.
You will own the patch and can distribute it as you want.
Does this make sense?
Emil Submitted at 14:32:24 on 23 March 2021
Patching a binary file is a lot of work (a few hours). I've done this for 1.10b and I have no incentive to do the same for an older version. Also the encoders work well now only in the main screen, for obscure modes like the clock setting it is still very bad. You should complain to the author who has the C sources about this and not expect me to do it at the binary level.
wollo Submitted at 17:09:05 on 23 March 2021
hi,where can i download 1_10a ,i can not find in google?
Emil Submitted at 18:11:30 on 23 March 2021
Read this page again and google exactly what I have suggested.
Jan Submitted at 18:12:41 on 23 March 2021
#Not_So_Anonymous,
(LG) I ment to say, the battery colour should be light green, when he is fully loaded.
73 Jan
Not_So_Anonymous Submitted at 00:55:11 on 25 March 2021
Jan, sorry if you missed this earlier: the battery is working and is fully charged....and yet the clock does not function, nor do the timers....i.e. the battery does not appear to be the problem.
Dan Submitted at 10:49:14 on 27 March 2021
Emil, have you experimented at all with computer control of this radio? I have been partially successful in getting it to work but don't fully understand the command format. Any recommendations?
Emil Submitted at 18:03:05 on 27 March 2021
I know nothing about remote control. One thing is sure, it's not over USB because it has no descriptors and it doesn't even enumerate.
If there is such thing then it must be over UART7 and on my model the J6 connector (from the schematic) is missing and I won't solder tiny wires on PE7 and PE8 just for that.
Remote control should be implemented as a virtual COM over USB. Hopefully an open source version will do this in the future.
Jerry C Submitted at 00:40:49 on 31 March 2021
I had the same problem as Alex Dörner with 1.10b. I've installed 1.10a and now my radio works fine again. I did email my radio ID and release code to malahit_sdr@rambler.ru a ten days ago, as per my instruction manual, but I guess that it takes a while to incorporate all the new IDs into the code table?
Emil Submitted at 06:12:44 on 31 March 2021
From what I've read in other forums it only takes 1-2 days max to include a new ID and the firmware is on this yandex disk
Have you also paid George or you only asked him kindly to include your ID in the list ? ;-)
Markie_V Submitted at 18:46:01 on 2 April 2021
I love the research you've done and so well documented,
all I did was to make BIN files for comparison (1.10b firmware)
I try to find where I should patch, but then I reread your website and saw your screen emulator...
Atlantis Submitted at 17:21:56 on 3 April 2021
Does anyone know why the CAT connection is so unstable/unreliable? Using hamlib "Kenwood TS-480" doesn't work (FW_version doesn't matter). OmniRig "Kenwood TS-480" works somewhat better, however, at least 20% of the sent frequency changes have no effect. Likely they do not reach the Malahit, ot the Malachit's CAT hangs somehow. But why? And how to fix this? Any idea?
Atlantis Submitted at 05:35:06 on 6 April 2021
Can you please give me the labels/numbers for the the port pull-up resistor (40K) and the 1nF capacitor on the board? Must be somethng like R23 or C74. I like to try to enlarge the capacitor. Thanks for your great work!
Emil Submitted at 06:53:05 on 6 April 2021
The pull-up is internal to the CPU. The encoder capacitors in the above picture are: C67,C70,C61,C63. The easiest way is to solder additional capacitors on top of the existing ones.
Keep in mind that, at least for the version pictured above, the encoder signals are excellent. It is only the software to blame. The author also choosed to have one big loop and interrupts instead of threads driven by interrupts.
Atlantis Submitted at 17:03:05 on 6 April 2021
Latest news regarding the CAT problems: I contacted the developer of the hamlib database, and today he developed for me a hamlib CAT driver for the Malachite DSP SDR. It took him/us 5 hours to fix all the bugs the Malachite CAT is generating. It turned out that despite what is said in other forums, tha Malachite CAT is NOT really compatible with the Kenwood TS-480 data protocol. However, now there is a good-working hamlib driver for the Malachite CAT interface. Just in case you do not know what hamlib is: hamlib is the "driver package" where several ham radio software is based upon (such as wsjtx, fldigi, etc.). The new hamlib CAT driver for the Malachite is already available via the hamlib master repository (at sourforge or via GIT). To get it, at the moment one has to compile hamlib (and wsjtx) by ones own, but the driver will be included in all future releases of the named ham radio software.
Max Submitted at 06:37:49 on 13 April 2021
Wow, excellent job!
Just a little round-up:
- buyed a chinese version
- installed version 1.10a
- purchase an activation code
- enter the code at first run.
But how I get your code updates for encoder and strting bug?
Do you have a patched firmware?
Sorry but I do not understand this point.
VH Submitted at 14:24:53 on 14 April 2021
I understand how to decompile with IDA. I am still learning, but did have already some success with FW of some devices (non Malachite related), where I was able to patch a branch...
What I did not understand from this thread is: how to patch the FW with posted *.c files with encoder and watchdog fixes?

Am I missing something or did you release this info basically for Georgy?

If I had to apply them, I would consider:
1) Compiling them (not sure if that would even work with the stand alone *.c files)
2) Find the respective subroutines in the decompiled source code (very time consuming
3) Patch the compiled code in some free memory space
4) Patch a JMP in the original subroutines to the new replacement subroutines

It would interest me to understand if that was your process to apply the fix.
Emil Submitted at 14:30:28 on 14 April 2021
Basically, yes, it's for Georgy if he wants to apply it for new versions and for enthusiasts who want to apply those patches manually.
Atlantis Submitted at 14:34:18 on 14 April 2021
Emil, I tried to enlarge the capacitors buffering the encoders, but it did not improve the bad behaviour of the encoders. Therefore, in addition to what Max said also from me the question: Could you please describe in more detail what EXACTLY we must do to modify the 1.10a firmware so that your encoder fix is included? (If you like you can also answer me via email.)
Emil Submitted at 16:49:21 on 14 April 2021
It is a very manual and time consuming process. That is the reason I don't want to redo it for an older version. You have to link your generated code to existing addresses in the code. I've created dummy functions, compiled the C code and then with some Perl scripts applied relocations to the real addresses. At the same time you have to be careful not to overflow the existing space for the functions you want to change.
Matthew Davies Submitted at 22:39:06 on 14 April 2021
I've asked this on the FB page with no response so one last time. Has anyone heard of a future firmware with more than just another money making method? Features?

Markie_V Submitted at 16:46:05 on 16 April 2021
We should really hope that Georgy will consider Emil's encoder code, this will do SO! much justice for this radio, from almost crap to fine control...

I also would like to see some more consist control, why is it enough to set LCD dimming to 0 for disable LCD dimming and for LCD sleep I have a separate button for time and a button to enable/disable?
And please a bit more consist in the use of capitals
www.knappemeid.nl/screen_setting.jpg
Emil Submitted at 21:06:55 on 16 April 2021
Why do you complain about firmware issues on this page? Especially UI issues which can only be changed by the person who has the source code (which is the author).
Markie_V Submitted at 06:40:30 on 17 April 2021
Sorry, If I wrote it wrong, this was not! addressed to you but more for Georgy in the hope he will use your encoder code.
This as a compliment to you.
Geert Submitted at 10:07:59 on 17 April 2021
Please also allow me to congratulate you with your excellent work you have done on this SDR receiver.
The only thing i don't understand or find on your site is how to calculate the unlock code from the CPU ID.
Yes, i know the unlock code is generated via your webpage, but what is the underlying algorithm?
Again, many thanks for your work!
Emil Submitted at 15:15:05 on 17 April 2021
The algorithm is not public, there is no reason to release this. In fact more than 200 IPs so far tried a "GET" on my Perl CGI script in the hope they'll get this. If you want it reverse it as I did.
wolle Submitted at 16:22:31 on 17 April 2021
I have installed 1.10A on my china clone and entered the code displayed (this is the cpu id) after sturtup here on this website to get the unlock code,and it freaking works.
Matthias Submitted at 20:12:59 on 17 April 2021
How do you debrick this Chinese Malahit clone? I tried disconnecting the battery and connecting JP1 and JP3 but no success. What am I missing?
Emil Submitted at 23:17:41 on 17 April 2021
JP3 will disconnect your 3.3V supply, leave that alone! You only need JP1 to force the CPU in DFU mode and of course the battery needs to stay connected. First check if you have at least 3.7V on your battery (if not try to revive it with an external charger or replace it with a new one).

Alternatively you can use the SwD connector with a STLinkV2 without the need to solder any jumper.
Heinz B. Submitted at 17:20:26 on 18 April 2021
Many thanks for the possibility to use firmware 1.10A Emil!
Max Submitted at 20:33:04 on 22 April 2021
Great job indeed!!
Thank you for your efforts!
Frank Submitted at 20:01:10 on 25 April 2021
Thanks a million, Emil!! I, too, was a Chinese-clone-buyer. Can now use FW 1.10a - will upgrade soon to latest beyond by sending due contribution to the Russian OMs who made it possible - but at last, for tonight,I can enjoy the radio as advertised by the sellers from CHN.
Dennis Submitted at 10:10:43 on 6 May 2021
Hello, after upgrade from 1.0c to 1.10b the Noise filter needs some milliseconds to reduce the noise. Does anyone have a hint here for me ?
jimmyanag Submitted at 03:58:56 on 8 May 2021
Hi everybody,i noticed that msi001chip has a high impentance input for hf frequences,why it is not used so we can put a ferrite antenna? I asked Georgie and told me that on next fwbhe will include an option to activate this input,register 0 bit 11 i think, have anybody an idea for a schematic diagram for this?thanks
Matthew Davies Submitted at 20:57:52 on 8 May 2021
Is that the tiny little white flush mount thing next to the main SMA jack?
If so we could connect it to another seperate SMA jack for a whip. I hope someone knows what to call that thing.
Eric Novell Submitted at 18:11:32 on 11 May 2021
You mean that white jack that has the word "SPK" next to it? It stands for "Spectrum Phase Konnector." Its used to hook up to the spectrum analyzer so you can check out the signal phase. No, its a speaker connector.
Marcio Submitted at 16:14:17 on 15 May 2021
Hi Everyone!

How can I find out the CPU ID of my Malahit clone? It comes with FW 1.0a, and I've flashed it to the FW 1.10a. It can't show me the CPUID on the initial screen in any of the above-mentioned FW versions.

Is there any way to get the CPUID other than in the initial screen?
Brandon Submitted at 12:44:59 on 16 May 2021
Marcio

Easiest method would be to upgrade to 1.10b to get the cpuid. It will display it each time the radio starts up
Genesis2k Submitted at 19:39:12 on 18 May 2021
Is there a recommendation for replacing the 22MHz oscillator with a more stable TCXO? Anyone did a modification to increase drift stability?
jimmyanag Submitted at 20:01:23 on 18 May 2021
Genesis2k
I have done it with a gold TCXO from Rojon,it is perfect now and i have an fcorrect 0 in all frequencies
UserAZERTY0 Submitted at 08:15:03 on 20 May 2021
Hi jimmyanag, could you share before/after photos of your mod ?
Max
Geert Submitted at 10:33:43 on 20 May 2021
Hi Jimmyanag, which exact component did you use and where can we get it ?

kind regards
Geert
Matthias Submitted at 16:55:07 on 20 May 2021
The F Correct (frequency correction) option in the Hardware menu has no unit. The manual does not mention that either. What frequency unit is the displayed adjustment actually made in (Hz, kHz) ?
Matthias Submitted at 17:20:01 on 20 May 2021
You wrote:
JP3 will disconnect your 3.3V supply, leave that alone! You only need JP1 to force the CPU in DFU mode and of course the battery needs to stay connected. First check if you have at least 3.7V on your battery (if not try to revive it with an external charger or replace it with a new one).

Alternatively you can use the SwD connector with a STLinkV2 without the need to solder any jumper.

A couple of questions:
- What does JP1 get connected to so as to force the CPU into DFU mode?
- The SWD connector lacks pins and the STLinkV2 comes only with female connection cables. What kind of connector would need to be added / soldered to the board?
Emil Submitted at 21:58:44 on 20 May 2021
JP1 is a jumper. You short it temporarily with a wire or a solder blob. It pulls the Boot0 pin to 3.3V.

Typically you use Dupont wires to connect to a 0.1" pin header which you can solder on the PCB. You can also only insert the pin header and keep it pressed with your hand while you program the CPU if you don't want to solder it permanently.
Matthias Submitted at 10:00:20 on 21 May 2021
So I shorted JP1 with a solder blob. But my device did not go into DFU mode. In the Windows device manager, it is listed as a USB device named DFU in FS Mode.
The DfuSeDemo software does not detect it as a DFU device. The STM32CubeProgrammer detects it but this software cannot flash dfu files. What do I need to do?
Emil Submitted at 16:46:51 on 21 May 2021
Your device is in DFU mode. I can't help you with windows software because I'm not using any. Maybe others can give you advice. What I use in linux is listed in the article. There is a windows version of dfu-util.
eric novell Submitted at 09:40:54 on 22 May 2021
Matthias - If it shows up as "DFU in FS Mode", what you do is start the STM3CubeProgrammer. Change your setting to "USB". You should see your DFU device listed. Click on the left side icon with an arrow pointing down. Click "Browse" and select the firmware HEX file and not the DFU file. Click "Start Programm" and it should upload the HEX bin file to your radio. You will need to unplug the power and plug it back in to restart it. I just did it yesterday so I know it works.
eric novell Submitted at 09:44:51 on 22 May 2021
I forgot to mention you need to remove the solder blob before you plug power back in so you can boot up normally. You should also put a check mark in the "verify programming" so it can verify the upload was not corrupted. You don't need to convert the original HEX file to a DFU file.
eric novell Submitted at 09:53:09 on 22 May 2021
Matthis: BTW, if you didn't know, you don't need to bridge the jumper to get into DFU mode. You only need to bridge it if you never loaded a firmware or if the firmware is corrupted. After you installed the firmware, all you need to do is turn off the unit, plug in the USB cable to your computer, hold the volume button down, turn on the unit and let go of the volume button. It should be in DFU mode and you should see the "DFU in FS Mode" in your device manager if you followed the sequence carefully. This is all documented in the manual.
Matthias Submitted at 11:16:01 on 24 May 2021
I did this, it worked partially, but now it seems I have a hardware issue or deficiency:
[...]
Emil Submitted at 16:39:49 on 24 May 2021
I'm sorry but I don't want to transform this page in a help desk forum. If you need basic help go to the facebook group. There are already too many comments so I will only keep the ones that I deem relevant.
UserAZERTY0 Submitted at 20:21:17 on 25 May 2021
Just received mine, board rev 1.03.
Has NAU8822L instead of Emil's NAU8822A (rev 1.02).
Works “nicely” in v1.0a (with the bugs pinpointed by Emil), will upgrade (thanks to Emil!).
Otherwise I find the speaker really cheap, there should be enough room to put a better one (especially larger that best covers the container holes).
Maybe same thing with the battery, will see the real charge first.
If somebody has clues on how to put a TCXO, I would be thankful!
UserAZERTY0 Submitted at 21:20:58 on 25 May 2021
Upgrade completed.
There was a glue drop on JP1 (epoxy?)
Anyway, volume pressed at startup switched it to DFU mode...
@Emil: sounds like with frequency encoder it’s perfect, but with the volume one, sometimes 2 increments are needed for 1 point increase/decrease (still better than with previous firmware!)
Jan Submitted at 06:34:54 on 29 May 2021
On the RU Malachit site you can DL FW_1_10c
eric novell Submitted at 06:55:02 on 31 May 2021
I'm sure Emil already reverse engineered their HEX file with IDA and looked at their new spaghetti code to determine 160Khz vs 40Khz modes during startup. At least they cleaned up their hash to make it easier to read.
Emil Submitted at 16:58:01 on 31 May 2021
You are wrong ... I haven't even d/l the new firmware yet. I know you are all impatient but this is not high priority for me. I will look at it and patch it sometime in the future but don't hold your breath.
eric novell Submitted at 01:43:26 on 1 June 2021
I'm just messing with you. The new HEX file isn't that much different. They are playing games with the code, but in reality, if you know what you are doing, its an easy patch to fix.
Nunzio Submitted at 13:44:56 on 2 June 2021
Hi I bought the Chinese malahite receiver with activation.
But maybe you don't realize that having provided the free code several (Chinese) people have speculated on the code by charging it as original including me.
I could easily update until the possibility of unlocking this receiver was put online obviously the creator took the countermeasures and now because of you I find myself a receiver that cannot be updated unless I spend more money to have activation thanks.
Emil Submitted at 16:58:52 on 2 June 2021
... and the moral of the story is?
> thanks.
You're welcome.
Jan Submitted at 17:30:18 on 2 June 2021
#Nunzio you're blaming the wrong person, you should blame the person who sold you the Radio

The person who sold me the radio as upgraded one, kept his promiss

In the FW 1.10c, this are the new extra settings

Audio - ANF - Pseuo Stereo :
Visual - Retro scale :
Hard - User Func - Audio out - PGA Gain - PGA BST :
Emil Submitted at 23:33:23 on 2 June 2021
I had a quick look at the new 1.10c firmware.
Protection wise, there is not much new, they've added a separate verification for the payed IDs and a CRC of the spash screen which is read back from the LCD memory. From 1MB total flash space, 307KB is occupied by the new uncompressed splash screen (see above) and another 21KB with the list of the registered IDs. What a waste of space. I'll remove all of these when I'll patch this FW.
Dan Submitted at 07:33:38 on 6 June 2021
@Emil. If almost 400KB is "rubbish" how big is actually the application?
Kenwald Submitted at 17:37:13 on 10 June 2021
Emil wrote....
(1600 registrations by now)
1600x50=80000 $
Not bad this bussines!
Emil Submitted at 19:52:23 on 10 June 2021
On the other hand my code generator has been used until now about 2800 times and from these 1000 were unique IP addresses. So unless people just like to generate hex numbers as a hobby ...
rx9cim Submitted at 20:16:50 on 10 June 2021
@Kenwald: Aha, if it was true, it was very good.
And if that were so, then on our YouTube channels you would see more expensive decorations, and not what is there.
Main part of this it is code for my own receivers and whose made receivers itself (in Russia mainly).

It is strange that about techical problems is discuss here, not in other place like facebook group or russian forum. About encoders problem i known not so many time ago, and i will decide it in next FW.
Algorithm of Emil is have the right to live, but it is
Does not counteract bounce of contacts, we test something like in our old projects. Who have deal with encoders, those must think what is Gray code.
Emil Submitted at 19:57:54 on 11 June 2021
Maybe because most of the world doesn't speak russian (or even read the russian alphabet)?
I don't do social media either. Facebook along many others are blocked and DNS holed at router level in my home.

For me, and many other clone users, the encoder code from above works much better than what's in the original firmware.
rx9cim Submitted at 16:07:44 on 13 June 2021
With optical encoders your algorithm must work normally.
But with mechanical encoders it will bi problem with bounce, interrupt work very fast, it will on each front of bounce. I early tested some algorithm as your.
Daniel Submitted at 06:08:34 on 14 June 2021
 Hi! I have the original DSP 2. I considered that it does not have the latest firmware, so I upgraded to 1.10c.
Unfortunately after the upgrade the Malahit doesn't start (boot) anymore, The screen image does not appear . LED flashes red -green !!
rx9cim Submitted at 12:27:13 on 14 June 2021
FW for Model2 is not in the repository because there is no update yet.
FW for Model1 and Model2 are different.
Lima Submitted at 12:30:59 on 15 June 2021
Thanks for sharing your info about this SDR, it's a shame you can't provide the key for 1.10c, but I understand.
jaap Submitted at 19:39:20 on 15 June 2021
thank you Emil for your effort .. it works great.
Jan Submitted at 20:21:47 on 16 June 2021
I wanted to do an update but the screen stayed black,I opened the receiver disconnected the battery and put the power on and made the update thanks Emil it works great and you can now see the FW nr in the start screen.
eric Submitted at 18:14:13 on 17 June 2021
Hypothetically speaking, if you can create the hash code from your CPU ID and know how the has is stored in these registration tables. Can you find an existing valid hash code and replace it would your own hash code? It would seem to be an easy task to a search and replace with a hex editor.

They only way to block this would be to create a new hash code algorithm or hash the hash with another hash of the hash of the hash.
rx9cim Submitted at 20:44:20 on 17 June 2021
Eric, you really think that if something will go too far - we not to do else :)?
it is a futile fight, it only takes time from both sides, a game of catch-up.
Emil Submitted at 23:02:07 on 17 June 2021
@eric There are multiple checks protecting the integrity of the code and table hash. Usually 32 bit CRC with random polynoms and another special check which I didn't bother understand. You change 1 byte of that hash table and the firmware hangs in an infinite while loop.
eric Submitted at 05:41:46 on 18 June 2021
@Emil I understand what you mean. I see some of their checks with IDA.
Honestly, I don't care about the updated firmware. I'm just more annoyed about the bad code for the encoders. Move the encoder one way, it jumps two steps. Move the other way, it jumps three or four steps back. I just play with the radio and the code for my own amusement. It gives me a lot of practice with IDA PRO
Jan Submitted at 14:09:31 on 18 June 2021
@Daniel you can found your FW on the malahit DL website
disk.yandex.com/d/4ZgsrswxYClG1Q
rx9cim Submitted at 17:04:25 on 18 June 2021
We decide problem with Daniel.
I load FW especially.
Emil, i see your articles - what is your country and main work? Ofcoarse if it is not private.
Emil Submitted at 17:50:00 on 18 June 2021
I am quite a private person but I can share that I'm an electronics design engineer (from somewhere in Europe). Articles on this page are not related to my work though.
rx9cim Submitted at 20:40:12 on 18 June 2021
Thank you for info!
It is clear that I am from Russia :), even the region is clear.
I am an engineer, including electronics.
Our team is all engineers, at least in electronics, but some also have their own skills and specialization.
UserAZERTY0 Submitted at 22:15:17 on 18 June 2021
Made the speaker mod with Visaton K40SQ (best I found that could just fit in).
Had to add little pads on the front as the dome goes by 1mm beyond the front.
Was a bit tricky to put back the screen cable, works nicely.
For additional batteries, I foresee to put 3 x 2000mAh (1 speaker side - like original, 2 screen side).
Btw I feel that the main chip gets a bit hot... but not much space now to add a heat sink due to the new speaker (or a home made one based on aluminum can).
OH2LVZ Submitted at 14:30:57 on 23 June 2021
Giyorgi, could you consider using Reddit as the international platform for communication? I do not speak russian and I am also not on Facebook due to political reasons.

This Emil's site is very nice, but also quite well hidden in the internet. Reddit is a well known and somewhat neutral platform and I think it would be a good way for you to communicate with your fans and customers. There is already a group for the Malachite SDR and I am sure the redditors would appreciate if you could update the official policy of firmware upgrades also there.

reddit.com/r/MalahitSDR
Jan Submitted at 19:26:44 on 28 June 2021
Emil I'm using Cubeprogrammer in W 10, is it possible to leave the hex files in???
Emil Submitted at 21:17:37 on 28 June 2021
STM32CubeProgrammer can use both bin and hex files so you won't need them. Also it's trivial to convert from bin to hex (as described above).
Guy named Bob Submitted at 06:10:10 on 30 June 2021
I recently purchased a unit on ebay that was fully registered. When I got the unit, I was trying to get more information on how to use it. I saw there was a Firmware update to 1.10f. I had version 1.10b and like any other piece of hardware you keep the firmware updated. So, I updated it. Then it was asking for the key. I emailed the seller and said that he only supports 1.10b. I found 1.10b on the net. Installed it and it asked for a code. Seller sent me a code. Code doesn't work. I am guessing a need a more updated 1.10b firmware, where can I get the latest revision of it? Does anyone have any links?
Emil Submitted at 15:03:22 on 30 June 2021
There is no such version as 1.10f, the latest is 1.10c. You have probably "updated" to an older version 1.0f. I guess your unit is not registered with the authors so the latest version you can use is 1.10a. No, we don't provide any firmware links.
Jan Submitted at 21:05:52 on 30 June 2021
Thank's for the hint Emil but I will use DfuFileMgr
Massimo Submitted at 18:33:15 on 3 July 2021
I can't update to latest firmware version.
I convert bin file to dfu, set the radio in dfu mode, connect to pc then choose the right file and press upgrade.
The software says it did everything (green bar) but when I leave dfu mode I always have the previous version.
Emil Submitted at 07:12:24 on 4 July 2021
Your DFU conversion must be flawed. You need to specify the start address which is at 0x8000000 otherwise the processor will try to upgrade the wrong region (probably at 0). Using the above utilities do this to obtain your DFU file:
	stm2ihex.exe file.bin
	hex2dfu.exe file.hex
Also you can use the binary file directly as expained above.
rx9cim Submitted at 15:26:22 on 4 July 2021
OH2LVZ - thank you for info! But i am have not time for it.
I created some groups in telegram, and also for English language users - t.me/MALAHITEAM_EN
kiki Submitted at 10:39:02 on 11 July 2021
I would like to congratulate you for this work it allows us to better know this small apparatus, the fact of being able to use the complete version 1.10a is a significant plus which can help us in our future purchase of the other versions. SDR developers shouldn't worry about your work since you made it possible to use only one version which for my part allowed me to decide to buy the official version directly from the developer, their concern should rather be oriented towards the resellers who invade the net with poor quality clones and unofficial codes sold as legal.
Thomas Submitted at 17:12:25 on 29 July 2021
@Emil Thank you for your helpful information. I have the same problem as @Massimo. You write that the start address must be 0x8000000. I am not a programmer. Therefore my question: How do I do that?
Emil Submitted at 04:07:27 on 30 July 2021
If you use the above 'stm2ihex' you don't have to do anything because the default starting address is 0x8000000.
Emil Submitted at 23:37:57 on 4 August 2021
The author fixed the synchronous AM detector in the latest firmware 1.10c rev2 (I haven't checked this personally).
Jan Submitted at 16:22:49 on 6 August 2021
Your suggestion using the stm32cubeprogrammer works, no need to convert the bin files.
Jan Submitted at 14:30:56 on 8 August 2021
Dave N9EWO did post a review (Ver 9.7) on the www with some comments over the FW_1_10c update from July 26, 2021
Ron Submitted at 09:12:52 on 9 August 2021
I have a clone i think but it works "fine" exept the frequency readout is wrong, i can not find a way to adjust.
I listen to a local repeater on 430.350 ik have to tune to 430.359
Is there a "simple" way to adjust this ?
I can't find anything on the internet about this.
I'm not smart enough with the software adjustment etc.
Emil Submitted at 17:17:01 on 9 August 2021
The 22MHz oscillators on the clones are known to be of low quality. You can't do anything in software about this since that's the clock for both MSI001 and MCU.
Replace your 22MHz oscillator with a bigger can, something like this they tend to be more precise or even better get a TCXO
mvs sarma Submitted at 13:30:56 on 24 August 2021
Is it possible to get a schematic of the malahit sdr radio clone for general study and appreciation?
Emil Submitted at 15:16:38 on 3 September 2021
Except the extension connector the schematic is identical to the original.
Ferenc Koller Submitted at 04:19:01 on 8 October 2021
Welcome everyone!

Has anyone built an optional panel for the DSP1 radio?
If yes, which PCB version (many in circulation)
I am interested in the change ..

Regards HA5BDC / Francis
Radio Submitted at 00:10:17 on 21 October 2021
I recently received a Chinese clone which has version 110c - works very well. Email me for a copy of the dfu if you're interested.
Emil Submitted at 15:57:18 on 21 October 2021
The firmware that you are offering originated from me ;-)
Frankie Submitted at 20:24:23 on 22 October 2021
Hi, one hardware update question: Malachit clone still works fine here, but unfortunately, had to disassemble it because a nut went loose inside and while putting it back together, I have broken off the turn-on knob (by my own incompetence - it snapped off the board together with a bit of its copper lead...). In the months since then, I can still turn it on and off by the small switch at the bottom that´s connected to the battery but could I still update it now to 10c version 2? IIRC, updating (did it esrlier this year) at the end required three times pushing the start button...there is no workaround to this, is it? If there isn´t, wouldn´t mind the wait for the upgraded Russian hardware version 2.
All best!
Ivan Submitted at 07:35:13 on 23 October 2021
V 1/10d drive.google.com/file/d/1DzcSxZnbba7BSJ__irdDsPfmGQSOwnGt/view?usp=sharing "https"
jaap Submitted at 10:57:01 on 23 October 2021
@ Ivan Thank you !
jaap Submitted at 11:13:55 on 23 October 2021

the new display noise reduction function in HARD menu works very well
Jan Submitted at 20:58:08 on 23 October 2021
The verion nr is back again on the old place r-o side
cez Submitted at 08:22:40 on 24 October 2021
@Ivan
whats the difference between this version and official one?
thanks
Jan Submitted at 20:18:00 on 24 October 2021
@cez
Is it possible that it is the official one????
What do you think.
Ivan Submitted at 10:35:06 on 25 October 2021
Firmware 1.10d: Fixed bug indicating firmware version. Now the version is indicated on the splash screen in the lower right corner added the function of reducing the noise from the display in the HARD menu WTF replaced with WF, so that it looks like an obscene English expression. changed the control of encoders - now, being in the menu, the frequency encoder is used for control; added a step of 9 kHz in SSB; added the ability to select a color gamut in the Visual menu; excluded the Sleeptime parameter for controlling the backlight; excluded a delay when switching between menus; fixed minor errors
Cez Submitted at 11:53:49 on 25 October 2021
@Ivan, thanks
thought it is a "vitaminized" version :)
marco Submitted at 13:20:38 on 25 October 2021
Hi, I have flashed the fw 1.10a found on google on my clone, but it didn't ask any activation code..why?
It seems to works but I don't understand why the Malahit don't ask for any activation code
陈红云 Submitted at 15:30:05 on 25 October 2021
3c00-3700-0251-3030-3732-3838
cez Submitted at 20:29:20 on 26 October 2021
@Jan
honestly speaking, I have no idea. Might try updating my 1.10a to the above, but not sure if it wont brick the unit and will be able to return to 1.10a if something goes wrong.

Add A Comment

Your Name
Your EMail
Your Comment

Your submission will be ignored if any field is left blank or if you include clickable links (URLs without the "http://" start are fine). English only please. Your email address will not be displayed.