Malachite DSP - SDR Radio Receiver

[admin]

Originally posted: Fri Jul 24 2020 15:35:41 GMT-0400 (Eastern Daylight Time)

Linked below is an English Translation of the Manual for the

Malachite (or Malahit) 50KHz-200MHz DSP SDR Radio Receiver

http://linuxslate.com/Instructions_Malakhit-DSP_en.pdf
[PDF, ~1.8M]

This Manual was manually translated from the original Russian by linuxslate.com with extensive help from Google Translate. Also includes Minor Formatting and English Grammar Cleanup.

PLEASE NOTE:  This Manual is for older, test versions of the firmware.  This version is found on many clones, such as those offered by Chinese vendors.  The test firwares are restricted to 50KHz-200MHz and lack many of the features described in the manual.  The official firmware requires an activation code.

(Other Key Words:  50KHz-250MHz, HAM, Shortwave, STM32H743, MSI001)

UPDATE: Link Fixed.

UPDATE: An un-translated line was found in the Firmware update section.  This has been corrected.  Link Remains the same.

UPDATE: The version of the manual linked above is the original version, and remains valid for the test version (unregistered) firmware as ships on most Chinese versions of this receiver.  Translated updated manuals for the official (registration required) firmwares can be found in subsequent posts in this thread.

Please scroll down for the latest version of the English language manual.

[admin]

Originally Posted: Sat Aug 29 2020 18:00:20 GMT-0400 (Eastern Daylight Time)

I finally got mine!

I purchased one of the Chinese (Test Firmware only) versions on Aliexpress (Receiver only -- No case, battery, etc.).  When the order was somehow misdirected, the seller, BestTools Store, promptly re-sent the order by Federal Express.  I had it just a few days later.


I was very anxious to use mine as a portable receiver, so I stopped working on my other project, and hurriedly built a case out of some very brittle clear plastic.  It didn't turn out very pretty, but it does work.  At least I have one in a completed and usable form.  In the case is a single 18650 battery, and a small, and very old speaker.



I do not recommend running these units on a single 18650.  Battery life is limited, and it is a bit aggressive in charging for a single cell. Portable phone chargers make great locally available donors for an appropriate battery, or use 2 18650's in parallel.  When using two 18650's: 1) Make sure they are at a similar state of charge when you first connect them, and 2) Use at least fairly good quality ones -- preferably with a protection board.  Apparently this receiver will run them flat, and then not charge them again.

-----

So the next question is:  How do you install the firmware using Linux?  Well, I haven't tried it yet, but I think it is actually very easy.  There is a command line tool called dfu-tool that should work fine.  I also installed the Windows version of DfuSe Demo on wine, but I don't think that is the correct answer.  After I use my Malahit for a few more days, I will try backing up the firmware, and going through the process of installing the latest version of the firmware, and registering it.

I'd recommend installing dfu-tool, and waiting for a instructional post which will follow shortly.

dfu-tool is easily installed on most modern distributions with apt:

Code: Select all

sudo apt install dfu-util

(Note that dfu-tool is part of dfu-util, the latter being the package name)

EDIT: I still think dfu-tool/dfu-util would work, but as safer options, I found some other ways to update the firmware via platforms other than Windows:
EDIT:Instructions posted for installing or updating the firmware using dfu-util. See post #4.


Option 1:

From the official ST Website:

STM32CubeProgrammer (STM32CubeProg) is an all-in-one multi-OS software tool for programming STM32 products.

https://www.st.com/en/development-tools ... eprog.html

STM32CubeProg is essentially a Cross platform Java app that does USB DFU programming, and much more.

Option 2:

I installed StmDfuUsb for Android. StmDfuUsb can flash files in DFU or HEX format (among others).

https://play.google.com/store/apps/deta ... .stmdfuusb

I installed it on a large Chinese tablet that has full size USB ports.  If your android device does not have full size USB ports, you will need an OTG cable or adapter.  This should also work on ChromeOS devices. I already used StmDfuUsb to succesfully reset my Malahit SDR from DFU mode.

This seems very simple, and as long as it works, it may be the preferred solution.

[admin]

Originally posted: Mon Aug 31 2020 11:03:54 GMT-0400 (Eastern Daylight Time)


A few more notes to make this a more complete thread for these radios:

Links:

Official Tread on CQHam.ru forums:
http://www.cqham.ru/forum/showthread.php?41449
(Russian language only -- use Chrome's built-in translation.)

User rx9cim is the thread owner, and the developer of the software.
The original post is at the top of each page, and contains links for the firmware and email addresses to register your device.


Official Documents and firmware are on the following Yandex Disk page:  (Yandex Disk is the Russian equivalent of Google Drive)

https://yadi.sk/d/4ZgsrswxYClG1Q

Notes:

rx9cim just released a new version of the firmware that apparently fixes a significant memory corruption bug.  So as of this post, everyone should be on 1.0e.

The newer firmwares require you to press the power button three times within 5 sec to turn the unit on.  This is to prevent accidental depletion of the batteries.  There is discussion of making this an option within the "Hard" menu.  I support it being optional.

To contribute to this thread or to ask a question, please register by sending an email to "john" at this domain, which is "linuxslate.com". Registration is for legitimate and relevant discussion only. Misused accounts will be deleted without warning.

[admin]

Originally posted: Tue Sep 01 2020 13:59:46 GMT-0400 (Eastern Daylight Time)



Specific things that do not work with the test firmware as shipped on most Chinese copies:

This is from a translated post by rx9cim [With my own translation clean up and additions]

---

In the Chinese [versions], without activation, there will be only a test firmware, which is quite a receiver, but it does not know how to do a lot of things and has a lot of differences from the firmware that requires activation:
1) the frequency range is limited
2) there is no stereo fm reception [Also no RDS]
3) there is no frequency error correction
4) there is no usb connections [Except charging -- Radio control and audio interfaces appear, but do not work]
5) a stick or a hole in the middle of the spectrum
6) there is no support for a shield with a power supply
7) there is no normal msi001 gain control, which will cause problems when working on large antennas
8) an inconvenient interface
9) a brake interface - low fps and a long response to controls
10) no normal selection of the frequency step
11) no normal aru  [AGC?]
12) no frequency input function [No Direct frequency entry]
13) there is no display off function to minimize interference [Display timeout does work]
14) high consumption in the off state - 10mA
15) no visual spectrum and waterfall settings - there are many settings
16) there are clicks during restructuring
17) no telegraph decoder [No CW (Morse Code) Decoder.]
18) the number of memory cells is less and in them not all settings are saved
19) the interference from the display is much larger
This is the first thing I remembered.
As a result, the difference is colossal.

---

I will say that even with the Test (unregistered) firmware, it is a usable shortwave/VHF multi mode radio, but performance is not as good as commercial receivers due to the interference and AGC issues mentioned above.

I have been using mine to listen to aircraft radio, and using only a long piece of wire soldered to an SMA connector, I was able to pick up CB "Power Stations" (users running illegal power) from Miami on CB Channel 6 (27.025 MHz).

[admin]

Originally posted: Wed Sep 02 2020 22:47:05 GMT-0400 (Eastern Daylight Time)


Major Update.  I am now a "Malachite Pro!".

How to Upgrade (Install Firmware on) the Malachite-DSP using Linux:

WARNING:  A failed Firmware upgrade or installation will leave your radio in an unusable ("bricked") state.  While most of the time it should be recoverable, additional skills and equipment may be needed to recover a bricked Malachite-DSP SDR.  It may be impossible to recover the functionality of the unit. Proceed at your own risk. I am telling the reader what I did.  I am not telling the reader to do anything.
WARNING:  Lithium Polymer batteries are dangerous if shorted.  If the radio needs to be hard power cycled, and the radio does not have a battery connector or switch, it may be necessary to de-solder the battery leads.  Caution must be taken to make sure the battery leads are not shorted.

What is needed:

• A Malachite-DSP SDR -- For most people this will mean a Chinese copy.
• The firmware file to be installed.  For these instructions, I am assuming the DfeSe (.dfu) version of the Firmware file.  As of this writing, the official Firmwares are located here:
  https://yadi.sk/d/4ZgsrswxYClG1Q/
• A computer running Linux
• The dfu-utils package for your Linux distribution.  On Ubuntu and similar distributions, this is easily installed by typing:

  Code: Select all

  sudo apt install dfu-utils

• An USB cable appropriate for your radio.  If you have a radio with the "Y" version processor, you will need an STm32 boot loader or programming cable.  More on this in a subsequent post.  WARNING: The firmware will let you put the SDR in DFU mode even if the processor does not have DFU mode. In this case, the radio will be unusable until the battery is disconnected and reconnected.  It is essential that you visually verify you processor type before continuing.  Determining processor version is detailed on page 18 of the instruction manual. UPDATE: Reference the picture in the next post.  The Green circle indicates the processor revision letter.
• An activation code.  There are links in previous posts as to were to purchase these codes if you do not have one for the particular radio.  Only the test firmwares, which are very limited in functionality, can be used without a code.
• A screw driver and soldering iron -- just in case.

Loading the firmware:

• Put the Malachite-DSP SDR in DFU mode per the instructions on page 20 of the manual.
• Verify the SDR is connected and in DFU mode:

  Code: Select all

  dfu-util -l

• With the Malachite-DSP SDR connected to the computer via the USB cable, update the FW with the following command:

  Code: Select all

  dfu-util -a 0 -i 0 -D [path-to-FW-file.dfu]

• Replace [path-to-FW-file.dfu] with the path to the firmware file you wish to install.  e.g. Downloads/FW_1_0d/1,0d.dfu.  Do not include the brackets.
• dfu-util should display the progress.  Loading a full firmware takes several minutes.  Note that dfu-util refers to writing the file to the device as "Downloading".
• Recover the unit into normal mode.  There are several ways to do this:
  1.  Disconnect and reconnect the battery.
  2.  Try:  dfu-tool attach
  3.  Use the android app StmDfuUsb to leave DFU mode.  Note: I was not successful flashing with StmDfuUsb.
• If this is the first time you have installed an official firmware, or you had to recover a bricked Malachite-DSP SDR, you will probably have to enter the activation code.  Make sure you retain your code in case it is needed for a future recovery.

Troubleshooting and Recovery of a failed FW installation:

• Troubleshooting and Recovery will follow in a subsequent post.

[admin]

Originally posted: Thu Sep 03 2020 10:24:45 GMT-0400 (Eastern Daylight Time)

Malachite-DSP SDR

Troubleshooting and Recovery of a failed FW installation:

Radio Won't Power On:

NOTE:   Firmware versions 1.0d and1.0e require 3 presses of the power button to turn on.

A radio that won't power up may have been accidentally put in DFU mode.  To check this, connect the radio to a PC via USB.  A radio in DFU mode will appear with the USB vendor:product of 0483:DF11.  It can be verified to be in DFU mode with the Linux command:

Code: Select all

dfu-util -l 

I have not been successful recovering the radio to the application (normal) mode with the command:

Code: Select all

dfu-tool attach

But it is worth the try.  I have gotten mine out of DFU mode using the android app StmDfuUsb.  If your Android device does not have a full size USB connector, you will need an OTG adapter or cable.


Radio Still Won't Power On:

In most cases, a radio that is not powering up will be recovered by a "hard power cycle" -- in other words disconnecting and then reconnecting the battery.  If the battery is directly soldered to the motherboard, then de-soldering and re-soldering is needed.  I recommend adding a connector, or a battery disconnect switch.  Note that the test firmwares have a constant 10mA drain.  This may drain a single 18650 in a matter of days to the point where it will no longer charge.  If you are building your own case, or you plan to stick with the test firmware, I strongly suggest a battery disconnect switch.

WARNING:  Lithium Polymer batteries are dangerous if shorted.  If the radio needs to be hard power cycled, and the radio does not have a battery connector or switch, it may be necessary to de-solder the battery leads.  Caution must be taken to make sure the battery leads are not shorted.


Radio Will not Power On After Hard Power Cycle, or is Known to have no Firmware or a Failed Firmware Load:

If the radio cannot boot, then it cannot be put into DFU mode as described in the manual.  In this case, the radio must be put in DFU mode my soldering across JP1 and JP3 as described in the manual.

Note that the jumper positions are not marked on the Chinese boards. They are indicated by the Red circles in the following picture[sup]1[/sup]:



This will put the board in DFU mode, and the firmware can be loaded as described in my previous post.

Once the FW has been loaded, both jumpers must be removed (de-soldered).  This is easily done with fine solder wick/solder braid.

After this, the radio should boot.  If a full firmware flash was forced, or it is the first time a non-test version firmware is loaded, the device must be registered. The registration screen is shown below:




¹Source: Schematic Diagram, Page 3:https://yadi.sk/d/4ZgsrswxYClG1Q

[admin]

Originally posted: Wed Sep 09 2020 09:07:35 GMT-0400 (Eastern Daylight Time)


Updated Instruction Manual

Here is a new English Language translation of the Instruction manual for current firmwares of the Malachite ([ch1052][ch1072][ch1083][ch1072][ch1093][ch1080][ch1090] or Malahit) SDR Radio Receiver:

http://linuxslate.com/Instructions_Mala ... P_en_2.pdf

This is a recent quick translation and is thus subject to errors and omissions. It will be revised as necessary.  Help with corrections is requested.  Please email john at the domain of this website with corrections or to join this forum.

The manual above is for the newer firmwares that require registration.  If you have one of the earlier test firmwares (as shipped on many "clone" units), the older manual is still available here:

http://linuxslate.com/Instructions_Malakhit-DSP_en.pdf

[admin]

Originally posted: Wed Sep 09 2020 10:09:58 GMT-0400 (Eastern Daylight Time)


Using the Malachite-DSP with a computer running Linux

Upgrading the firware via a Linux computer is covered in previous posts in this thread.

But the Malachite-DSP also supports CAT and IQ connections to a host PC.

Today, there are lots of sophisticated HAM radio apps for Linux, and the Malachite-DSP is partially recognized by several of them.

The Malachite-DSP "borrows" the CAT (Rig Control) profile of a Kenwood TS-480.  When the Malachite-DSP is connected to the Linux computer via USB, it creates several serial ports such as:

Code: Select all

/dev/ttyACM0  /dev/ttyACM1

Note that these can move or change depending on other devices connected, or if the Malachite-DSP disconnected and re-connected.

Note:  You may need to add permissions to the serial port to your Linux account.  The typical way that this is done is to add yourself to the "dialout" group as follows:

Code: Select all

sudo addgroup "$USERNAME" dialout

Do this if you get permissions error accessing /dev/ttyACM0 (for example).  You must log out and then log back in to get the permissions of the new group.

It also appears as an audio source (recording) device, although I have not actually been able to get any audio over the Linux audio source.

Here's some basic info to connect it to Grig and JTDX:

Grig - From the Grig man page:  Grig is a simple Ham Radio control (CAT) program based on the Ham Radio Control  Libraries.
If one does:

Code: Select all

grig -l

We see that the
Kenwood TS-480 is supported as model (-m) 228, but listed as untested.

Code: Select all

228  Kenwood          TS-480                 0.9.5  Untested

So to start grig and connect to the radio, we start grig with the command:

Code: Select all

grig -m 228 -r /dev/ttyACM0 -s 19200

With this, Grig starts, and correctly displays the frequency tuned on the Malachite-DSP, along with the mode, etc.; however, I have not gotten it to do much more. I cannot tune the Malachite-DSP from grig, and the S-meter does not seem to work.

The same is basically the case with JTDX.  In File --> Settings --> Radio tab, we again Select Kenwood TS-480, /dev/ttyACM0, and 19200 for the baud rate under the CAT side.  Other settings are set to default.  Since the Malachite-DSP is not a transmitter, we can ignore the PTT side of the settings dialog.

Under the Settings --> Audio tab, we again can select the Makahit audio device, but as mentioned, I have not gotten the audio over USB to work.  If the radio is connected to the computer's audio input (analog), then the appropriate input device should be chosen.

UPDATE: I still have not gotten The Malachite SDR's USB audio to work with newer Linux distributions. There are various references to getting similar USB audio devices working by building a custom kernel, but as of right now, it does not seem to work without doing so. Without the Linux Software being able to hear/decode the audio, there really isn't much functionality.  I will keep trying and update this post when I have better news.


It is hoped the above will help users get started connecting this device to a PC running Linux.  Please email john at the domain of this website (linuxslate.com) to join this forum.

[admin]

Originally posted: Wed Sep 16 2020 21:35:19 GMT-0400 (Eastern Daylight Time)



Bugs and Issues with the Re: Malachite DSP - SDR Receiver

First, I think this is a really cool project. It's far more capable than commercial projects in the same price range and size. You can buy a basic board with screen for less than US$100 (probably without case/battery/speaker at that price).  Complete units, with a registered version of the software can be had for about US$200.  I don't know of another self contained portable radio -- commercial or otherwise -- that includes a color display with spectrum analyzer at that price.

I should also note that both of the radios I own are Chinese clones, not ones actually made from the files or boards sold by the developers, however, it appears to me that the Chinese stuck pretty close to the original circuit design.  In any case, the vast majority of these sold are going to be Chinese clones.  Like it or not, the Chinese define the majority of the hardware today.

Bugs/Criticisms, ranked very loosely in most serious to nits:

•  Ghost Frequencies and Reflections: There seem to be a lot of "Ghost" or phantom frequencies where no actual external signal is present, but a strong or overpowering signal is indicated on the Spectrum Analyzer, and nearby frequencies cannot be tuned.  Signals are often reflected across the range of the spectrum display. The worst seems to be at 60MHz, and all even (at least) harmonics - e.g. 120MHz, 240MHz, etc.  These appear with no antenna connected, appear on both radios, and across different firmwares.  An RF Explorer verifies that there is no actual strong signal at the affected frequencies. This is due to both internal clocks and signals, and due to the RF issues that follow.  Software Defined radios often have a clock shift function to move internal clocks and signals should they interfere with a desired signal.
  [highlight]FW_1_0f greatly improved this.[/highlight]
•  Lack of RF AGC.  The unit has settings under the Audio Panel for AGC, but this is an Audio level (AF Gain) AGC only.  It does not prevent strong RF signals from over powering the receiver.  For example, I use mine to listen to aircraft radio (VHF AM). If I set the RF gains high enough to receive the tower, an aircraft flying near me totally saturates the receiver, and is illegible. RF AGC is a pretty basic function, and should be included in such a device.  It should be possible to implement RF AGC in the MSI001 totally in software -- in other words, in a future firmware.
•  Too many settings for various RF Gains.  Related to the above, what this unit does have is at least 5 RF Gain settings.  While access to these settings should be available to users wanting to explore the full capabilities of the MSI001, it is too complicated for a user that just wants to tune a frequency and listen, just like they would on a Tecsun or Grunding, etc.  While it is possible to get similar performance to commercial radios, it takes a lot of time messing with these settings to make the Malachite radio perform adequately. At the minimum, they should default to optimal settings for each frequency range and mode. [highlight]FW_1_10a has clarified the nomenclature of some settings[/highlight]
•  Use of the term "Bands" for memories.  "Bands" are defined groups or ranges of frequencies.  While not 100% the same every place, they are generally agreed upon world wide.  The AM broadcast band is from 560KHz to 1.6Mhz.  The short wave "band" is generally considered to be from either the beginning or end of the AM broadcast band up through 30MHz.  Within that range, there are Ham bands, which again may vary in specifics from country to country, but generally use the same terminology (such as 120m band, 40m band, etc.) The FM broadcast band is from 88 to 108MHz FM, and while station assignments and perhaps the exact edges of the band may vary from country to country, something close is generally followed world-wide. The aircraft band is accepted as 108-137MHz world wide.  This radio should not use that term for the Settings panel that allows the user to access memories that have no association with the more common use of the term "band".  "MEM" (Memory), would be a fine label for that button.
•  Saving All settings when a frequency is stored to a "Band".  All current settings are saved when a memory position is pressed and held. In general, this is a good idea, but certain settings should not be saved.  For example, Hi-Z or 50 Ohm depends on where the radio is being used, not the frequency tuned.  What if I want to use the radio in either a building (home), or hand-held, but I would like to listen to aircraft frequencies in both cases?  I must now save each frequency twice -- once with the appropriate settings (of which as mentioned there are a lot of) for a (perhaps very high gain) roof mounted antenna, and then again for handheld use with just a whip.  The antenna Hi-Z/50ohm setting, and probably some of the others, should not be saved with the frequency.

To Be Continued in a subsequent post.

[admin]

Originally posted: Wed Sep 16 2020 22:06:15 GMT-0400 (Eastern Daylight Time)

Continuing my list of Bugs/Criticisms with the Malachite DSP SDR receiver:

•  Squelch is poorly implemented. Squelch is another basic function that has been correctly implemented in receivers since the vacuum tube days.  In the Malachite DSP SDR receiver, it seems to cause loud clicks and scratchy sounds if set near the signal level.  There is an NR threshold setting that may be an attempt to mitigate this, but it again, is another setting that other receivers don't have or seem to need, and it also does not actually seem to help.  
  Work is needed on the implementation of squelch.  It should have some hysteresis to eliminate rapidly turning on and off, and the squelch enabling or muting the audio should not cause a noise of it's own.  Even better would be a way to adjust the squelch while looking at the spectrum display, with an indication of the threshold level.  This would allow the user to set the squelch at the desired level above the noise floor.
•  Touch screen response time/Settings Panels switching:  The unit feels a little show in touchscren response.  While current firmwares support going from one panel to the other with out exiting the first panel, it takes a second or so to do so.  In the meantime the user does not know if his touch has been "registered" or not. Even going from one item in a given panel to another seems a tiny bit "laggy". I realize that this is not a gaming PC, but I am pretty sure that the STM32H7 is capable of better than it is now.  Just a little software optimization is necessary with respect to displaying the menus/settings panels.
•  Encoder Wheels:  I should mention that what follows is from 2 different radios, with different encoders, and different physical layouts of the encoder knobs.  There is not a 1 to 1 correlation between "clicks" or detents, and what is registered on the display.  When tuning, it will often skip one or more steps.  In some cases, it is necessary to position the wheel between detents to tune a desired frequency.  For example, if I am tuned to 118.000MHz, and I would like to set it to 118.200MHz, and the interval is set to 100KHz, it should take exactly 2 detents to get there.  I do understand how these wheels work, and I understand that Encoders with different numbers of detents (and different qualities) are sold.  I think that given the open hardware nature of this project, there needs to be additional software settings to allow matching of the particular encoders to the software, just as there is currently an encoder reversing option.  Essentially a encoder gain or sensitivity setting.
•  Excessive encoder clicks to move from one group of memories to the next in the "Band" panel.  It takes many clicks to move to the next, or previous panels.  Ideally, this would be a continuous smooth horizontal scroll, and could also be accomplished by dragging with a finger on screen;  However, I am not asking for this.  As I mentioned I realize that this is not a gaming PC, or a phone, but it should be possible to make going from one group to the next a little easier/quicker.
•  Power on, Power off.  There has been quite a bit of discussion on the Russian CQHam forums about turn on and turn off.  IMHO, both the 3 presses to turn on, and the Morse code when turned off are obnoxious. Mobile phone designers were faced with this issue many years ago, and have universally settled on a long press to turn on.  Neither the pre-built Chinese radio I have, nor the one in the case I made, are prone to being accidentally activated.
  EDIT:  FW_1_0f has returned to a single quick press to turn the radio on.
•  Spelling of the Word Standard.  The word "Standard" is spelled wrong in the Low Battery cut-off menu item (is: "Standart", should be: "Standard").
  Fixed in FW_1_1a

Lastly, a word about open source.  This is a Linux website, so one may anticipate that I will ask that the firmware source code be made publicly available;  However, I am also aware of reality, and I understand that George and the other developers did a lot of really cool work, and are not making any money from the Chinese clones.  My Linux brethren may disown me, but I had no problem at all sending George the US$55 for an activation code.

That said, I do think that this project, at some point, would benefit tremendously from releasing the firmware under an open source license.  If they do not do so, this project will always remain far behind projects such as the HackRF One.

Another alternative is that someone will either come up with a new, and independent firmware or will disassemble the current firmware.  I will note that the tools to de-compile STM32 code are readily available, and quite capable.

Perhaps the developers will see fit to release the source code publicly after a short time.  While I am not a "pro" programmer, I have worked on similar projects before (Namely OpenLRSNG). If the project was open source, I could probably provide at least some help instead of just complaining.