Linuxslate.com Forums

Linuxslate.com Forums
http://linuxslate.com/cgi-bin/forum/YaBB.pl
Original Projects and Builds >> Other Builds and Projects >> Malachite DSP - SDR Radio Receiver
http://linuxslate.com/cgi-bin/forum/YaBB.pl?num=1595619341

Message started by Administrator on Jul 24^th, 2020, 2:35pm

Title: Malachite DSP - SDR Radio Receiver
Post by Administrator on Jul 24^th, 2020, 2:35pm

Linked below is an English Translation of the Manual for the

Malachite ([ch1052][ch1072][ch1083][ch1072][ch1093][ch1080][ch1090] 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.

Title: Re: Malachite DSP - SDR Radio Receiver
Post by Administrator on Aug 29^th, 2020, 5:00pm

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 (https://www.aliexpress.com/store/3403008), 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 (http://linuxslate.com/cgi-bin/forum/YaBB.pl?num=1589145424), 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.

http://linuxslate.com/Malahit_1_crop.jpg

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 (http://manpages.ubuntu.com/manpages/xenial/man1/dfu-tool.1.html) 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:
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 (http://linuxslate.com/cgi-bin/forum/YaBB.pl?num=1595619341/4#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/stm32cubeprog.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/details?id=com.yatrim.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.

Title: Re: Malachite DSP - SDR Radio Receiver
Post by Administrator on Aug 31^st, 2020, 10:03am

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.

Title: Re: Malachite DSP - SDR Radio Receiver
Post by Administrator on Sep 1^st, 2020, 12:59pm

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

Title: Re: Malachite DSP - SDR Radio Receiver
Post by Administrator on Sep 2^nd, 2020, 9:47pm

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:
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 (http://linuxslate.com/Instructions_Malakhit-DSP_en.pdf). 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:
dfu-util -l
With the Malachite-DSP SDR connected to the computer via the USB cable, update the FW with the following command:

Code:
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.

Title: Re: Malachite DSP - SDR Radio Receiver
Post by Administrator on Sep 3^rd, 2020, 9:24am

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:

dfu-util -l

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

Code:

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 (http://linuxslate.com/Instructions_Malakhit-DSP_en.pdf). 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¹:

http://linuxslate.com/Malachite_jumpers.png

This will put the board in DFU mode, and the firmware can be loaded as described in my previous post (http://linuxslate.com/cgi-bin/forum/YaBB.pl?num=1595619341/4#4).

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:

http://linuxslate.com/Malachite_Activation.png

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

Title: Re: Malachite DSP - SDR Radio Receiver
Post by Administrator on Sep 9^th, 2020, 8:07am

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_Malakhit-DSP_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

Title: Re: Malachite DSP - SDR Radio Receiver
Post by Administrator on Sep 9^th, 2020, 9:09am

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:

/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:

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:

grig -l

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

Code:

228 Kenwood TS-480 0.9.5 Untested

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

Code:

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.

Title: Re: Malachite DSP - SDR Radio Receiver
Post by Administrator on Sep 16^th, 2020, 8:35pm

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 (http://rfexplorer.com/) 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.
FW_1_0f greatly improved this.
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. FW_1_10a has clarified the nomenclature of some settings
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.

Title: Re: Malachite DSP - SDR Radio Receiver
Post by Administrator on Sep 16^th, 2020, 9:06pm

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 (https://en.wikipedia.org/wiki/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 (https://openlrsng.org/)). If the project was open source, I could probably provide at least some help instead of just complaining.

Title: Re: Malachite DSP - SDR Radio Receiver
Post by Administrator on Dec 4^th, 2020, 5:06pm

It's been a while since I've updated this thread, but I haven't lost interest in my Malachite SDR. Here's a few Headlines:

I Sold One of my Malachite DSP SDR's at the Melbourne Florida Hamfest.
New Home-Made Case for my Remaining Receiver
How to Add a separate Standby/Wake Switch to Chinese Malachite DSP SDR Boards
New Firmware Released

I Sold One of my Malachite DSP SDR's at the Melbourne Florida Hamfest.

As will become obvious from the remainder of this post, the one I sold was the one that came built into a basic metal case. I currently have only the one that I originally purchased as just a bare board.

New Home-Made Case for my Remaining Receiver

I have built a new case for my Chinese made bare-board Malachite DSP SDR. The case I had was hastily made from a clear, brittle plastic. It was poorly designed, not very nice looking, and it was developing cracks in several locations. I have made a new one out of Lexan. Pictures and basic plans for the new case are shown below:

http://linuxslate.com/Malachite Case Design_2.jpg
Note: The Link to the actual plans is below. The picture above is only for reference.

http://linuxslate.com/Malachite_Case.jpg
Note: Back Panel is not shown in the picture above.

This design is much thinner than my previous case and contains a front-firing speaker.

http://linuxslate.com/Malachite_Case_Design_2.pdf

A few notes about the plans:
1. All measurements should be considered approximate. Measure your own board, and make dimension changes as needed.
2. The screen is extremely delicate. Do not attempt to force it into a case. I added foam weather stripping around the screen cutout.
3. Due to the layout of the Chinese boards, both the bottom (base) as well as the top (antenna) side need to be removable for board access.

The drawings above are being provided as Open Source. If someone could convert them to files appropriate for a laser cutter or other automated production, it would be much appreciate. Please provide the drawings in a standard non-proprietary format. I will post them here also as Open Source, and I will credit the name or organization that converted them. Please register by sending an email to "john" at this domain, or simply attach the files.

How to Add a Separate Standby/Wake Switch to Chinese Malachite DSP SDR Boards

The Power/Wake/Standby button on most Chinese boards is a tiny SMT push button. Given the frequent use of this button, and the difficulty in making a homemade case that allows it to be operated in a convenient manner, it is in many cases desirable or necessary to wire up a parallel separate push button.

Note: It is strongly suggested that readers reference the schematic prior to attempting the modification detailed here. The Schematic can be found at: https://yadi.sk/d/4ZgsrswxYClG1Q Select the file [Scheme, BOM.rar].

As seen in the lower left of Page 3 of the schematic, The button Is connected via a simple debounce/filter circuit from the +3.3V CPU power to the CPU Wakeup pin (Pin 7). While removing the existing SMT switch, and simply soldering leads to the original switch pads is an obvious possibility, I chose not to do this for several reasons:

Desoldering/Soldering access to the original switch is made difficult by it's proximity to (almost underneath) the screen. I did not consider removing the screen due to the potential for damage.
Destructively removing the switch could result in damage to the pads and lifted traces.
I would like to leave the board with as little modification as possible.
For my case design, it was desirable to have the leads exit from the component side of the board, not the screen side.

So the best solution was to find R39, R44, and R45, as well as any close connection to the 3.3V_CPU line.

In the picture below, I have circled the common point of R44 and R45. I soldered a lead to the end of R45. (Top end in picture).

The smaller circle shows the +3.3V side of what I believe is C83. I soldered the other lead there. (Left end of component as shown in the picture.)

I simply attached short leads to a small JST connector. The other side of the JST connector is soldered directly to the separate switch. This allows the board to be easily removed.

Note: While there is no signal on the leads, it is best practice, especially in an RF device to keep any leads as short as possible.

http://linuxslate.com/Malahit_3_switch.jpg

New Firmware Released

I save the most important for last. Our friends over in Russia have released firmware FW_1_0f. Note that as of this post, it is released only in .hex format. He did not provide a DFU file. The release notes mention significant fixes to some of the issues I have pointed out in previous posts. Once I get my Radio installed in it's new case, I will attempt to load this version "f" firmware, and I will amend the previous posts as appropriate.

As always, get the official firmware files from:
https://yadi.sk/d/4ZgsrswxYClG1Q
Reminder: Registration is required for all firmwares other than the test firmware. Instructions for registering can be found here:
http://www.cqham.ru/forum/showthread.php?41449 (NOTE: Russian Language. Use Chrome's translate function, or other online translator.)

That's all the News Headlines for now. Happy listening!

Title: Re: Malachite DSP - SDR Radio Receiver
Post by Administrator on Dec 5^th, 2020, 12:08pm

Firmware 1_0f Update and Quick Look report.

My Malachite DSP SDR Radio is in it's new case. I like the style and layout of my new case very much. Unfortunately, I had a lot of stupid mistakes while making it, and the paint didn't come out as nicely as I would like, but it is functional. Even when compared to the factory built (Chinese) unit I had, mine is more functional, and very nice to hold and use.

In addition to the new case, a firmware update has also helped make mine far more functional. I have to say it directly:
The Malachite SDR has never been better.

Loading FW_1_0f

As of this writing, FW_1_0f is only available as a .hex file. I used the official STM DfuSe v3.0.6 Demo DfuFileMgr.exe under WINE
to convert the .hex file to .dfu. Yes, there are Linux utilities that will do this, but using DfuFileManager was a quick, easy, GUI way to do it.

After that, I installed the DFU file as described in Reply #4 (http://linuxslate.com/cgi-bin/forum/YaBB.pl?num=1595619341/4#4) of this thread.

Quick Look Review of FW_1_0f

Here's a few quick observations after playing with FW_1_0f for just a few minutes:

They have removed the press 3 times to turn on function of the STBY/Wake switch. Even a quick press of the button will turn on the radio. I think a long press is the correct answer (like almost everything else) but for now, we are back to a quick press. It still must be long pressed to turn off the radio.
I like the new "Retro Look" tuning dial for the FM broadcast band (Shown Below). This display replaces one of the WB FM Mux spectrum displays. It makes the radio much more user friendly for just casual FM tuning/listening.
Some of the "Ghost" signals/interference is gone. While in just the few minutes I played with it, I cannot say that all of the phantom interference and reflections are gone, it seems to be a significant improvement. The Radio is now far more useful for general listening. Note that this was my first and most significant complaint, and I will amend my bug list in Reply #8 (http://linuxslate.com/cgi-bin/forum/YaBB.pl?num=1595619341/8#8).
My first complaint on my 2nd page of bugs (http://linuxslate.com/cgi-bin/forum/YaBB.pl?num=1595619341/9#9) was about scratchy sounding squelch. It may be a by product of fixing the above, but it seems that there is some improvement.
Various other fixes as mentioned in the Change Log (https://yadi.sk/d/4ZgsrswxYClG1Q/%D0%9F%D1%80%D0%BE%D1%88%D0%B8%D0%B2%D0%BA%D0%B8(FIRMWARE)).

http://linuxslate.com/Malahit_1_0f_SS.jpg
New Retro Look FM Tuning scale

Title: Re: Malachite DSP - SDR Radio Receiver
Post by Administrator on Jan 13^th, 2021, 5:46pm

There is a new firmware out, and George and the other developers are listening!

FW 1.10a is available at the usual location (https://yadi.sk/d/4ZgsrswxYClG1Q). Be sure to check the Change Log (Contains both Russian and English).

I won't have time to load this firmware for several days, but it seems like they continue to improve the Malachite SDR, and have fixed more of the issues that I mentioned in my "Bugs and Criticisms" List (Post #8 (http://linuxslate.com/cgi-bin/forum/YaBB.pl?num=1595619341/0#9) and Post #9 (http://linuxslate.com/cgi-bin/forum/YaBB.pl?num=1595619341/0#9) of this thread.)

I won't post the change log here, but among the updates are fixes/improvements to some of the things I have mentioned:
-- Spelling of the word "Standard" in the HARDware menu.
-- Settings for the sensitivity of the encoders.

There is also a new Splash screen, and updates in the "Retro" Broadcast FM display for auto search, and easier moving between stations.

If you have tried FW_1_10a, and would like to comment, please register by emailing "john" at this domain, and I will create an account for you.

Title: Re: Malachite DSP - SDR Radio Receiver
Post by Administrator on Jan 17^th, 2021, 3:22pm

Firmware 1_10a Quick Look report.

Refer to the Change Log (https://yadi.sk/d/4ZgsrswxYClG1Q/%D0%9F%D1%80%D0%BE%D1%88%D0%B8%D0%B2%D0%BA%D0%B8(FIRMWARE)).

Observations:

There is not a setting for the sensitivity of the encoder wheels as previously reported. That was based on a miss-reading of the translated Russian in the change log. Other than putting the encoder wheel direction options on a single button, there is no noticeable change in encoder operation. I have no idea what the Note referring to "wheelbarrow" is supposed to mean.
The Auto Scan feature for FM tuning would be a great idea, except it doesn't work. We have many strong stations in the area, but in trying with both a whip antenna and my outside wire antenna, numerous scans found exactly zero stations. There is now a function to change the color of the FM "Retro" scale. It's nicely implemented with little "preview" icons. I'm not sure if that was in 1_0f or not.
The bandwidth shadow now reflects the currently set audio bandwidth. I don't remember this working before, but I may have just not noticed it in previous firmwares.
Yes the spelling of "Standard" is correct, but with the nomenclature as-is, it is still not going to be intuitive as to what that setting does without reading it in the manual.
They have improved the nomenclature for some of the RF Gain Settings in the "HARD" menu. There is a PREAMP Enabled/Disabled setting, and a PRE Gain setting. Does the PRE Grain setting adjust the gain of the Preamp? if so (as one would think), then why are those 2 settings not near one another?
One of the Gain settings (the one closest to the Preamp button) has been changed to "ATT", but I am still confused. Does the Preamp attenuate the signal?! Maybe I need to read (translate) an updated manual, but it is still far from user-friendly. The HARD menu should be updated so that the order of the functions having to do with RF gains/attenuation follow the flow of the signal left to right. The other buttons should be moved to accommodate this.

A picture is worth 1000 words, so here is a picture that shows the concept of what I am thinking of. Note that this is a 5 minute drawing for illustration only, not the exact implementation. I tried to be consistent in capitalization (Ahem), and to suggest alternative nomenclature in some places. I did not refer to the schematic or MSI001 datasheet while making this drawing. Blocks may not be in the right order.

http://linuxslate.com/Malachite Suggestion.jpg

The signal path line could be animated to show the Preamp being in the circuit or not, Alternatively, a red "X" could simply be drawn to show the path that is not active. What is important is the button order. The signal path line would be completely optional.

Title: Re: Malachite DSP - SDR Radio Receiver
Post by Rod on Jan 18^th, 2021, 6:56am

Thanks for the great information you have shared.

Using the above information, I was able to upgrade from (the supplied) 1.0c to 1.10a.

It's a great little device, and getting better with firmware upgrades.

Title: Re: Malachite DSP - SDR Radio Receiver
Post by Administrator on Mar 12^th, 2021, 10:35pm

Firmware version 1_10b has been posted to the Yandex Disk site. As usual, it can be found in the Firmwares folder:
https://yadi.sk/d/4ZgsrswxYClG1Q/[ch1055][ch1088][ch1086][ch1096][ch1080][ch1074][ch1082][ch1080](FIRMWARE) (https://yadi.sk/d/4ZgsrswxYClG1Q/%D0%9F%D1%80%D0%BE%D1%88%D0%B8%D0%B2%D0%BA%D0%B8(FIRMWARE))

The strange thing is that all of the older firmwares have been removed.

Apparently, the authors have gone to some sort of time-limited code to unlock the firmware. I'm not sure how this works because the Malachite SDR does not retain the time if the battery is disconnected.

I am also interpreting this to mean that there are codes or code generators out there someplace for the older versions of the firmware. As I predicted in post #9, it is not going to be possible to stop people from unlocking/copying/modifying the firmware. I really wish George and company would put their efforts into making this a great platform instead of playing a game with the hackers.

George (rx9cim) does say that the new firmware should not pose any problem for people who have already registered a previous firmware.

Please don't ask me how to hack the codes or where to find them. I don't know how to hack the codes, and I am not going to look for them on the internet.

To be honest, It is not worth the effort for this radio. It is easier to buy a Raspberry Pi and a USB SDR stick and install Gqx for Raspberry OS (https://gqrx.dk/download/gqrx-sdr-for-the-raspberry-pi). You then have a more flexible and expandable portable platform that is fully (or at least mostly) open source.

In fact, I was considering building a table radio around another Malachite SDR, but even before this latest firmware shenanigans (I hope shenanigans translates to Russian -- I do know a stronger Russian term, if needed), I had already decided on going with a Raspberry Pi 3 and a USB SDR stick. It would give me Shortwave, aircraft, and everything else I can do on a Malachite SDR, but it would also be a media player and Internet Radio player. Adding things like ADS-B (aircraft location) should also be possible.

Title: Re: Malachite DSP - SDR Radio Receiver
Post by Administrator on Apr 7^th, 2021, 1:32pm

Here are the change log notes for 1.10b and 1.10c. Note that 1.10c is "Under Development", and not yet available on the Yandex Disk site (https://disk.yandex.com/d/4ZgsrswxYClG1Q).
The 1.10c change log is translated by Yandex Translate.

1.10b:

- fixed error in the S-meter readings for frequencies above 30MHz;

- the panorama scale injection has been changed - now instead of x1, x2, x4, 160kHz, 80kHz, 40kHz are shown;

- in SSB the 100kHz step is excluded and the 25Hz step is added;

- the touchscreen sensitivity is lowered again :);

- added synchronous AM detector;

- the frequency at which the low-pass filter 500000 is turned on is increased to 540,000, for better suppression of signals above the frequency of 500 kHz;

- added Auto Notch filter to the Audio menu;

- stretched grunginess adjustment;

- added DSB mode - as a kind of SSB;

- added CW mode - as a kind of SSB;

1.10c: (~~under development~~) UPDATE: As of 08 June 2021 it appears that 1.10C is now available. FW 1.10B has been moved to the "NOT USE SPECIAL" folder.

- improved graphical display of the spectrum

- improved algorithm optimization, improved display speed

- added the ability to determine the type of activation - by one or three clicks. If PD15 (pin 7 of the RESERVED field) is open, the activation is performed by one click.; if this pin is closed to a common wire, then switching on by three clicks

- improved the HARD menu

- changed the battery indication - the voltage is indicated on top of the picture

- added the ability to control user equipment using a discrete signal-PD14 (pin 8 of the RESERVED field)

- a button for switching the audio output has been added to the HARD menu. It duplicates the switching of the audio output. Made at the request of users.

- added SAM-U and SAM-L modes

Title: Re: Malachite DSP - SDR Radio Receiver
Post by Administrator on Aug 18^th, 2022, 9:08pm

You may have noticed that I am not updating this thread much anymore.

Firmware development seems to have slowed or stopped, and I've moved on to another (albeit still closed-source) SDR.

In fact I have not even loaded the latest FW on my Malachite.

There has been some new developments on the Malachite Hardware side. The Chinese seem to be getting more adventurous with modifications to the original design. Several units are mounting some of the controls off-board, as I did with the with the power switches in my re-built.

A new version that I just found out about seems to mount the Malachite Board as a daughter card on top of a new Back Board that hosts the encoders, switches and connectors. This model includes round stereo speakers on either side of the display, two knobs on top of the unit, and usually seems to come in a blue anodized case. It is sold as a "Malachite DSP SDR V4".

A similar but different design has narrow speakers on either side of the display and is usually black. This version (also referred to as "V4 Version") has two small thumb-wheel knobs on the right side.

Both of the above models also include a actual power (battery disconnect) switch like I implemented on mine.

Another unit that has been around for a while, essentially uses a printed circuit board for the front and rear, and has a single speaker on the left like mine. It also moves some of the controls to a separate side mounted board.

The versions above all include shielding around the RF portions of the board. I strongly recommend against buying any version that does not clearly show that it includes these shields.

So what did I move on to? Please see my thread on the Ailunce HS2/Radioddity QR20/Q900 SDR Transceiver (http://linuxslate.com/cgi-bin/forum/YaBB.pl?num=1653673530).

Title: Re: Malachite DSP - SDR Radio Receiver
Post by Administrator on Apr 6^th, 2023, 10:00am

New Firmware and other updates to my Malachite DSP - SDR Radio Receiver

Contents:

1. Firmware FW_1_10d.d
2. Battery Issues

FW_1_10d.d

As mentioned previously, It seems Firmware Development for this radio has slowed or stopped. If one follows the links provided in previous posts, and clicks on the "[ch1055][ch1088][ch1086][ch1096][ch1080][ch1074][ch1082][ch1080](FIRMWARE)", one will end up getting only a text file. This text file contains a link to a Google Drive location, and in that location, one will find a file "Malahit_FW_1_10d.rar" (Not FW_1_10c) and an update Change Log. Inside the RAR file is only the file Malahit_FW_1_10d.hex.

Being the brave soul that I am -- and willing to risk my radio for all users everywhere, I downloaded and installed this Malahit_FW_1_10d.

What did I do specifically? (Detailed instructions) -- Assumes Linux, but should be similar on other platforms:

Follow the maze of links and Yandex and Google Drive directories until you have a local copy of Malahit_FW_1_10d.rar
Here is a link to the relevant Google Drive as of the date of this post: https://drive.google.com/drive/u/1/folders/1OSoUMOVRloHKc-OYGKLIlNRtheimGgPV. Note that I am not responsible for the link or it's contents.
Right click on Malahit_FW_1_10d.rar, and select Extract Here. This will result in a single file Malahit_FW_1_10d.hex
Since I have been successful in the past flashing DFU formatted firmwares, I converted Malahit_FW_1_10d.hex to DFU format. This is optional if you have a reliable way to flash .hex files.
To convert the file to DFU format, I used the Windows version of the official STM DfuFileManager (part of DfuSe v3.0.6).
Put the radio in DFU mode by 1.) Turning the Radio off. 2.) Press and hold the Volume (top) encoder wheel. 3.)Press the On (Standy/Wake) button.
The Radio screen will be off (No display).
Connect the Radio to the PC with an USB A-to-C cable.
Verify the radio is in DFU mode with the command
dfu-util -l
You should see one or 2 lines with something like:
Found DFU: [0483:df11] ver=0200, devnum=8, cfg=1, intf=0, path="1-1.6", alt=1, name="@Option Bytes /0x5200201C/01*128 e", serial="xxxxxxxxxxxx"
Note that the path, and serial number will be specific to what USB port you use, and your specific radio.
Flash the firmware with
dfu-util -a 0 -i 0 -D Downloads/Malahit_FW_1_10d.dfu'
Note that the path must be correct for the location of your firmware file.
dfu-util will show the progress of the load. There should be 3 separate sections sent, with only the middle one taking any significant time.
Don't worry about a 4th segment, and a message about "Not Writable". This message is normal.
Disconnect power from the Radio (This is much easier if you have a battery disconnect switch -- See previous posts about getting the radio out of DFU mode.)
Power up the radio. You should see the newer, more colorful start up screen, and it should display 1.10d in the lower right.

I'll post comments on this latest (last?) firmware after I have had more time with it.

Battery Issues

I had another problem with my Malachite DSP - SDR Radio Receiver.

These radios drain the battery over time unless the radio has a hardware battery disconnect switch. The drain is much worse on the "Test" or Unregistered firmwares, but it is present on all FW versions. Over time, this will drain the battery, and there is no low voltage cut-off. Draining a Lithium Ion/Lithium Polymer battery below ~3.3VDC is very bad for the battery, and possibly dangerous.

I noticed that my Malachite DSP - SDR Radio was not holding a charge very well at all. I opened the case, and was amazed to find a VERY puffed battery.

There is also the possibility that these radios (at least the Chinese clones) are over charging the batteries or charging them at too high a rate.

I replaced the battery (4000mah) with a 8000mah battery. Note that at a given charge rate specification (e.g. "1C"), an 8000mah battery can be charged at twice the current of a 4000mah. So in general, a lager capacity battery is going to be more tolerant of "hard" charging than a smaller battery.

Suggestions:

As with everything - Never charge a LiPo battery unattended.
Encased, Round cells (e.g. 18650) are safer than bare rectangular cells, but check all LiPo batteries for leakage/dimensional changes or heating periodically.
Install a battery cut-off switch if your Malachite DSP does not have one.
Remember to use the cut-off switch (turn it OFF) if the radio is not used for any period of time (even a few days).
If building your own (or modifying) one of these radios, use high capacity, good quality cells.

I would also like to note that a very similar battery arrangement in My "Poor Man's Go DJ (http://linuxslate.com/cgi-bin/forum/YaBB.pl?num=1589145424)" has not puffed at all despite being subject to a much higher load, and much more frequent use. This is what leads me to believe that the Malachite DSP - SDR Radio is charging the battery in a way that is not good for it.