Welcome, Guest. Please Login.
Linuxslate.com Forums

<=== Back to the Linuxslate.com Homepage

Newest Forum Posts

Dec 3rd, 2020, 5:19pm
News: Welcome to the linuxslate.com forums. May 2020: Forum registration has been disabled due to recent advancements in bypassing captcha's and the resulting increase in spam on the forums. Registration may be re-enabled at a later date. In the meantime, if you would like to register, please email "john" at this domain, and I will manually create an account for you. Registration is for legitimate and relevant discussion only. Misused accounts will be deleted without warning.


1  Original Projects and Builds / Other Builds and Projects / Re: Poor Man's version of the Monster GO DJ
 on: Nov 20th, 2020, 7:04pm 
Started by Administrator | Post by Administrator
Finally -- As promised -- The demonstration video:
 
 

 
Reply Reply Quote Quote Notify of replies Notify of replies  

2  Original Projects and Builds / Other Builds and Projects / Re: Poor Man's version of the Monster GO DJ
 on: Oct 24th, 2020, 9:34am 
Started by Administrator | Post by Administrator
I used my Poor Man's GO DJ for an actual gig last night.
 
I was hired to DJ for a small car show in my local area, so I decided to take my PM GO DJ along as a back up.  The Stanton SCS.4DJ was my primary Player/Mixer.  Early in the evening, I got a request from the wife of the venue owner for Thriller by Michael Jackson.  I was certain I had loaded up Thriller, as well as a hand full of other Halloween classics on both the thumb drive I use with the Stanton, and the SD cards in the PM GO DJ .  However, I was unable to find Thriller on the USB drive I had in the Stanton.  I verified that Thriller was on the SD cards in the PM GO DJ.  Since the Stanton does not have an SD card slot (add that to my list of complaints), I couldn't simply swap or add media.
 
I figured this was a good enough excuse to actually try live DJ'ing on the PM GO DJ in front of a live audience.  It took a moment of down time to switch over, but the PM GO DJ connected to the amp I was using, and Played the request flawlessly.  I stayed with the PM GO DJ for several tracks before switching back to the Stanton SCS.4DJ.
 
Despite the previously mentioned limitations in the Media Players used in my PM GO DJ, it was actually quite usable.  Here are some more observations.
 

  • The font on the PM GO DJ Media players is much larger than the tiny font on the small Stanton display.
  • The Stanton Browse list does not retain the directory structure of the media, so you cannot use the media's directory structure to organize your tracks.  The media players in the PM GO DJ do retain the directory structure.  While I generally just have folders for artists, one could also use folders basically as crates, or any other structure you would like (such as a directory for "Halloween Songs").  Of course you can create playlists on the Stanton, but that would be tedious using the Stanton interface itself, or would require using other software on a PC.  Simply using the directory structure for crates or playlists may not be sophisticated, but it is simple and easy.
  • Quickly moving through large numbers of tracks is actually just as easy or easier than on the Stanton. Quickly browsing the browse list on the Stanton using the jog wheel is not smooth, and suffers from lag.  You either have to scroll slowly enough for it to keep up, or risk significant overshoot.  As mentioned, the Media Players used for the PM GO DJ are fast and direct if you just keep mashing the >> or << buttons.
  • The combination of the Media Players not stopping at the end of the track, and the Fader not totally silencing the opposite (faded away from) player leads to the next track playing in the background if you forget to stop it.  I think I did this for over half the tracks I played using the PM GO DJ.  I should state that the level of the undesired track is very low, and I don't know if it was noticeable to the audience or not when it happened.
  • While the PM GO DJ has 2 mic inputs (as opposed the the Stanton's single mic input), they do not pass through, so they can only be used for recording.  A live mic input is really needed, and it would be nice if it had equalization.

 
I'm still planning on doing a video demonstration. Check back for a link soon.
Reply Reply Quote Quote Notify of replies Notify of replies  

3  Original Projects and Builds / Other Builds and Projects / Re: Malachite DSP - SDR  Radio Receiver
 on: Sep 16th, 2020, 9:06pm 
Started by Administrator | Post by Administrator
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.
  •  Spelling of the Word Standard.  The word "Standard" is spelled wrong in the Low Battery cut-off menu item (is: "Standart", should be: "Standard").

 
Lastly, a word about open source.  This is a Linux website, so one may anticipate that I will ask that the firmware source code may 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.
 
Reply Reply Quote Quote Notify of replies Notify of replies  

4  Original Projects and Builds / Other Builds and Projects / Re: Malachite DSP - SDR  Radio Receiver
 on: Sep 16th, 2020, 8:35pm 
Started by Administrator | Post by Administrator
Bugs and Issues with the Re: Malachite DSP - SDR Receiver
 
I've got quite a bit of experience with these radios now.  I own 2, and have used at least 3 different versions of the firmware.
 
Based on this experience, I have compiled a list of bugs/issues/and general complaints about these radios.
 
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 anyplace -- especially here in the West -- are going to be Chinese clones.  Like it or not, the Chinese define the majority of the hardware today.
 
Lastly, I don't have a good outdoor SW antenna, so what is below is based mostly on use with just a whip antenna or a truck mounted 2m/70cm Ham antenna with broadband Rx.
 
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.
  •  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.
  •  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.
Reply Reply Quote Quote Notify of replies Notify of replies  

5  Original Projects and Builds / Other Builds and Projects / Re: Poor Man's version of the Monster GO DJ
 on: Sep 14th, 2020, 1:59pm 
Started by Administrator | Post by Administrator
Here's a pretty much final picture:
 

 
 
Current Status/Notes:
 

  • It runs from the internal LiPo battery.  I went with the separate boost converter to go from battery voltage to the +5V.  The charger/display board handles charging and battery level only. Battery life seems to be pretty good.  As mentioned, it draws less than 0.25A.  With a 5000mah battery, it will last longer than any party I will ever get invited to.
  • The issues with the cue switches was due to a short from soldering in very tight spaces.  2 soldering/wiring issues have been corrected.
  • I have not fixed the issue of the fader not completely silencing the opposite channel. Since the fader (and the headphone cue/live mixer) are just wired as resistors in the line-level audio instead of actual stage gain controls, they are not going to fully cut off the audio.   More engineering is needed.  I am not sure how much more effort I want to put into this project.
  • I turns out that the fader (linear potentiometer) board was not wired like I though it was.  Basically, both sides are wired in parallel on that board. The result of this was that it was not actually playing in stereo. I had to de-solder and re-work the board to make it 2 electrically independent pots.
  • If you look closely, you can see that I re-taped one of the membrane keyboards, and that the other is sill coming up near the center.  I'll re-glue this when I have the time and patience to do so.
  • Labels are not installed.  I have made some labels with Libre Office.  Again, I'll print, cut, and apply them when I have the time and patience to do so.

Reply Reply Quote Quote Notify of replies Notify of replies  

6  Original Projects and Builds / Other Builds and Projects / Re: Poor Man's version of the Monster GO DJ
 on: Sep 11th, 2020, 9:06am 
Started by Administrator | Post by Administrator
First Power Up!
 
It Works!

 

 
A few things to note:
 
1.  Note wires on left side.  It is currently powered from +5VDC from my bench supply. The battery is not installed, and as you can see, the battery meter board is not in the circuit.
2.  Film is still on, knobs not installed.
3.  It basically works/sounds pretty good, but it does have a few issues.
4.  The sound effects board was not working at all.  After hours of troubleshooting, I finally discovered that the problem was due to my bench power supply.  I was very conservative in setting the PS current limit -- Just in case.  With each of the tone/op amp boards having lots of filtering, it was presenting a large initial load on the PS.  The current limiting was apparently causing the voltage to come up in a way that hung the sound effects board.  Nominal (steady state) current is almost exactly 0.25A, but in rush is over 0.5A.  With the PS current limit set higher, everything powers up OK, and it does play the sound effects.
5.  There was an issue with the Cue/Live switches due to a short resulting from the close soldering on the tiny toggle switch contacts.  This was fixed, but I'm still not sure if something is wrong with the Cue switches/cue bus wiring or not.  More testing will be done to determine if there is still a wiring problem or not.
6.  Generally, control ranges are pretty good.  One significant problem is that the fader does not fully fade out the opposite player when fully faded to the other side.  I don't have a solution for this at the moment.  It is fundamental to the way the fader pot is made, and a relatively high impedance downstream of the fader.  It's more of a problem because the player modules do not stop at the end of a track -- they go on to the next track, so unless the gain for that side is turned down, or the player is stopped, the next track will be heard faintly in the background.  More thought is necessary on this issue.
7.  I will experiment with different options for power/battery/battery board configurations.  Hopefully I'll make a decision on the configuration today.
8.  It seems at least acceptable from a noise/interference point of view.  I may line the bottom panel with grounded aluminum tape just for shielding "best practices".
9.  The effects keyboards are not sticking to the chassis.  I will remove them, add 3M outdoor permanent double sided tape, and re-attach them.
 
Once I get the power system configured as it will be, and I have installed knobs and removed the protective film, I plan to do a video showing how it works.
Reply Reply Quote Quote Notify of replies Notify of replies  

7  Mobile Linux Devices / General News / Re: Wouxun KG-UV9D(plus) Programming on Linux
 on: Sep 9th, 2020, 9:26am 
Started by Administrator | Post by Administrator
Note:
 
The Wouxun KG-UV9D and KG-UV9D(plus) (as well as other Wouxun models) are now listed as supported radios under CHRIP.
 
"CHIRP is a free, open-source tool for programming your amateur radio. It supports a large number of manufacturers and models, as well as provides a way to interface with multiple data sources and formats."
 
While I have not tried it yet, running the Wouxun software under WINE may not be necessary any more.
 
Download the most recent CHIRP from https://chirp.danplanet.com/projects/chirp/wiki/Home
 
Reply Reply Quote Quote Notify of replies Notify of replies  

8  Original Projects and Builds / Other Builds and Projects / Re: Malachite DSP - SDR  Radio Receiver
 on: Sep 9th, 2020, 9:09am 
Started by Administrator | Post by Administrator
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 works with 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.
 
Again, the correct frequency will be displayed, but I have not gotten much else to work.  More may work if the receivers is tuned to a frequency with valid digital (packet) communications.
 
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 to join this forum.
Reply Reply Quote Quote Notify of replies Notify of replies  

9  Original Projects and Builds / Other Builds and Projects / Re: Malachite DSP - SDR  Radio Receiver
 on: Sep 9th, 2020, 8:07am 
Started by Administrator | Post by Administrator
Updated Instruction Manual
 
Here is a new English Language translation of the Instruction manual for current firmwares of the Malachite (Малахит 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
 
Reply Reply Quote Quote Notify of replies Notify of replies  

10  Original Projects and Builds / Other Builds and Projects / Re: Malachite DSP - SDR  Radio Receiver
 on: Sep 3rd, 2020, 9:24am 
Started by Administrator | Post by Administrator
Malachite-DSP SDR
 
Troubleshooting and Recovery of a failed FW installation:

 
Radio Won't Power On:
 
NOTE:  The newer firmwares - at least 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.  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 picture1:
 

 
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:
 

 
 
 
1Source: Schematic Diagram, Page 3:https://yadi.sk/d/4ZgsrswxYClG1Q
Reply Reply Quote Quote Notify of replies Notify of replies