Welcome, Guest. Please Login.
Linuxslate.com Forums

<=== Back to the Linuxslate.com Homepage

Newest Forum Posts

Jun 27th, 2022, 3:13pm
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: 7591 Amp Build (from Rowe/AMI R-4359)
 on: Jun 7th, 2022, 1:44pm 
Started by Administrator | Post by Administrator
Glow Test !!
Due to [Insert pretty much every excuse possible], progress has been slow, but last night was the night for a tube glow test and photo opportunity.

The pedantic always need to provide notes to a picture:
  • This is about as close to what it will actually look like when finished as we are going to see for a while.
  • The High Voltage Power Supply is not present/not connected, so this does not constitute a full load test.  In all honesty, at this point doing a full load test is somewhat NVA (No Value Added).  See below for more discussion of further testing.
  • Tubes are running at 6.1VDC filament voltage.  Slow start is implemented, and it takes about 30 sec to ramp up to that steady state voltage.  It may actually be a little too soft.
  • The 12AX7's were not installed for this picture, but driver tube glow was verified before this picture was taken.  Filament voltage was tested at the driver tube heater pins while the power tubes were installed.
  • Note masking tape under the Output Transformers.  They are only installed for this photo (which also serves as a fit check), so I wanted to protect the chassis from being scratched.  The tape will be removed when the OPT's are installed "For Flight".  Nothing is connected to the OPT's at this point.
  • Obviously the display bezel is not installed.  Again, no point in risking scratches at this point.

Lights and Displays  (Left to Right):
  • Amber LED -- Power -- Specifically indicates presence of 12VDC Low Voltage Power
  • Red LED -- Bias Fail.  Obviously, this light would not be on for normal operation, but in this case it is accurately showing Failure of the Bias Power Supplies because they are not installed yet.  A failure of either or both (Logic OR) Bias Supplies will interrupt the 12VDC source to the HV Power Supply.
  • The DAC OLED Display can be seen at the upper left of the display cut-out area.  The dashes show no digital input (No bit rate to display), and the line just under that indicates that the DAC volume is all of the way up, or almost all of the way up.
  • Below that is a Blue LED indicating Input #1 (Analog Input #1) is selected.
  • The VFD is showing time since power on since the clock is not set, and there is no signal present to make it go to Spectrum Display mode.

All-up and Thermal Testing
The largest load/largest heat producer is the High Voltage Power Supply, so this test does not represent any significant load to the Main (12VDC) supply.  
The HV power supply was not installed because (1) This test is much safer without it, especially since the HV PS cage has not been fabricated yet. (2) I have not drilled and tapped the "real" HV PS heat sink yet.  More testing with the temporary heat sinks would not have provided much additional meaningful data.
As expected, just running the Power Tube heaters did not produce any significant temperature rise in either the 12VDC supply, or the 6.1VDC Filament supply after running for about 5 minutes.
The unit was audibly quiet (No PS wine) during this test.
No more playing Mr. Machinist -- No more renders or doodling in Libre Office Draw -- No More cutting the displays off of DAC's and then wiring them back again. No more putting it off --  It's time to actually build a Tube Amplifier.
Reply Reply Quote Quote Notify of replies Notify of replies  

2  Linuxslate.com Reviews & Commentary / Review Discussions / Re: Aliunce HS2/Radiodity Q20/Q900 SDR Transceiver
 on: Jun 4th, 2022, 1:49pm 
Started by Administrator | Post by Administrator
What Works and What Doesn't -- SDR Transceivers known as:
Aliunce HS2,  Radiodity Q20, or simply unbranded "Q900".

What Doesn't Work
Call me pessimistic if you want, but I feel it is appropriate to warn potential consumers of the limitations of this device.  What works will be listed last so that we leave on a good note.  These lists are in random order for now, but I'll clean them up as I continue to work with the radio.  Check back as this review is currently a live document.
  • The GPS module installed in mine works, but only displays basic GPS info in extremely small text on a dedicated screen.  I thought that at the very least, there would be a way to set the radios internal time from the GPS time, but there does not seem to be any way to do that.  It also displays GPS speed, but it is so small as to be completely impractical while driving.
  • The radio copies the communications protocol from a Yaesu FT-817, but it does not work if connected to CHIRP, and Yaesu FT-817 is selected.  The Radios memories cannot be read or written.  The provided BT app does not include any way to select/edit/read/or write the radios channel memories.  In other words, I have no user friendly way to program/edit/name channel memories at this time.

What Does Work
There is some good news.  In fact, quite a bit of it.  This radio has great potential if they continue to provide firmware updates, and information for the developer community.
  • It is solidly constructed, and with the exception of the mentioned lack of environmental protection, it should withstand even those bad things that happen to nice radios.
  • It has good receive and is very usable out of the box at least for casual Short Wave listening without messing with dozens of SDR parameters.  It include features such as live CW decoding.

What works with Linux?
  • JTDX on Linux works with the same settings as shown in the manual for the Windows version.

Reply Reply Quote Quote Notify of replies Notify of replies  

3  Linuxslate.com Reviews & Commentary / Review Discussions / Re: Aliunce HS2/Radiodity Q20/Q900 SDR Transceiver
 on: May 27th, 2022, 1:17pm 
Started by Administrator | Post by Administrator
First Impressions and Mini Review -- SDR Transceivers known as:
Aliunce HS2,  Radiodity Q20, or simply unbranded "Q900".

Many years ago, when I took my Ham Radio License Test, I vowed to not buy a shack full of HF equipment.  I'd stick with handhelds only.  Never the less, I've caught myself slowing down and checking prices when I would walk by one of those big, fancy Yeasu, Icom, or Kenwood HF rigs at hamfests -- Maybe someday, I thought.
I was pretty good at sticking to my vow.  I only bought HT's such as the HamGeek FB-8 reviewed here.  I also bought lots of SW receivers;  Including a Grundig RF 250 I recently repaired.  Lots of information is Here about the Malachite SDR Receiver.
But when the true "Do everything" SDR came along, I couldn't help myself.  I am now the owner of a "Q900" (No other branding) SDR Transceiver.  
Unboxing and First Impressions:
The radio arrived from China in about 2 weeks.  Inside a simple cardboard box, was the included carry case, and in that was the Radio, Power Cord, Microphone a good quality USB-C cable, and a USB Drive.
They might as well have just left out the so-called carry case.  While it does provide foam protection for shipping, it is useless otherwise -- at least for this radio.  It is too small for a Ham Radio "Go Box" or field day set-up.  Even the above included items don't really fit right, let alone other things one would want in a "Go Box", such as cables, connectors, and other accessories.  I plan to use a small backpack or shoulder pack, and set up a proper Man Pack or Go Pack.
The included microphone appears small and cheap, but it is actually fully adequate.  It is *not* like those tiny ones they sell to plug into an HT.  It's about half way between one of those and a proper CB or Mobile Mic.
Other reviewers complained about the very minimal coaxial power plug and un-fused lead that is included.  I agree that a proper power cord would be better, but when one considers that cigarette lighter plugs generally contain a fuse, I don't think that the lack of a fuse in the cable is a big deal.  If actually wiring the radio into a mobile installation, the fuse should be installed a the beginning of the run (which should start at or very near the vehicle's battery.)  The short cable included is not intended to fulfill that purpose.  What they should have done is simply include the (fused) cigarette lighter plug.  An inline fuse is absolutely essential if one is going to use the included wire to make a harness for use with a Lithium Polymer battery.  I would advise using an XT60 connector on the other end, so that the radio can be powered from standard hobby Lithium-Ion (LiPo) batteries.  In this manner the radio retains portability while transmitting at closer to it's full power.
The radio arrived with the internal battery charged to about 70%, which is the condition the battery should be in for shipping.
I also got the GPS module with mine.  It was offered for free, so this was the that closed the deal for me.  The GPS module came pre-installed, but it does not include a GPS antenna.  It turns out that I have an GPS antenna from the Android Automotive Head Unit Reviewed Here, so at least for the time-being, I can use that antenna for testing.
When the unit arrived and I took it out of the so-called "carry case" a small screw and a nut fell into the case.  It turns out that all of the screws that attach the So-239 antenna socket to the chassis were loose, and one was missing.  Using a pair of forceps, I was able to re-install the screw and nut in it's place, and tighten the other 3.  Yes, a drop of Loctite blue was probably called for, so I may end up doing this job again.
The fact that the screw fell out is unremarkable, but the fact that the nut escaped from the inside illustrates that this radio is not at all sealed from the outside environment.  Despite advertising showing the radio covered in drops of water, it is not at all environmentally sealed.  No Environmental rating (IP) is stated in the specifications.  The circuit boards are not conformal coated. In this reviewers' opinion, the pictures showing the radio being used in unprotected environments are false and misleading.  If the radio is used for field operations, it should be protected in a water proof bag or "dry bag".  As mentioned, the included box is too small to actually enclose the Q900 and need accessories, and it is also not waterproof against submersion, but I will give it credit for at least some environmental protection against minor splashing, and better than nothing against a humid environment.
Reply Reply Quote Quote Notify of replies Notify of replies  

4  Linuxslate.com Reviews & Commentary / Review Discussions / Aliunce HS2/Radiodity Q20/Q900 SDR Transceiver
 on: May 27th, 2022, 12:45pm 
Started by Administrator | Post by Administrator
I am creating this thread for discussion of a family of radios known by various names, including:
Aliunce HS2,  Radiodity Q20, or simply unbranded "Q900".  It is probably sold (or will be sold) under other names as well.
The radio seems to be sold with a blue or black enclosure, and green or red LEDs for the keyboard back light.

SDR Transceiver.  Photo from Aliexpress Vendor Advertisement.
In addition to what seems to be the same radio sold under different names (and perhaps with slightly different firmwares), there does seem to be different versions of the radio itself.
There appears to have been an older version with separate connectors for the HF and VHF/UHF antennas.  Other rear-panel connections are re-arranged accordingly.  The older version also seems to lack the Ethernet (RJ45) connector.

It is my impression that versions with 2 SO-259 connectors represent an older iteration of this radio.
In this thread, I will provide the following:
  • A review of this radio
  • Information on using this radio with a Linux Host PC/Linux Ham Radio Software.
  • Tips, Tricks, and Hacks

To join in the discussion, please email John at this domain.  I am happy to create accounts for legitimate users (not bots).
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: May 21st, 2022, 1:59pm 
Started by Administrator | Post by Administrator
So this project is finished (or is it?), but I still have a few updates:
1.  I continue to use the Poor Man's GO DJ to DJ local car shows and other events.  I prefer it over the Real Go DJ for the reasons mentioned.  Most importantly it stays on the table.  The Real Go DJ has no rubber feet, and very little weight.  It tends to move around on the table when used, or pulled by the cables.
2.  I use the Real Go DJ as a bedroom audio player, and a compact back up for events.
3.  I have made a simple modification to the power system in my Poor Man's  GO DJ so that the batteries remain connected to the charger module.  The main power switch isolates the rest of the circuit.  Some may say this is how it should have been in the first place -- and I'll take that.  The load of the 2 media players was never allowing the battery to charge.  I ran the unit on batteries last evening for almost an hour.  I have a major event coming up in a few hours, (supposedly televised on 3 local TV stations), so perhaps making a change like this wasn't smart either, but we'll see how it works.  It sure wasn't working acceptably the other way.
More updates if/as needed.
Reply Reply Quote Quote Notify of replies Notify of replies  

6  Original Projects and Builds / Other Builds and Projects / Re: Telepresence Robot Build - With Code!
 on: May 18th, 2022, 12:14pm 
Started by Administrator | Post by Administrator
There is an effort here at Linuxslate.com to make this project work more like a commercial product.
What does "Work more like a commercial product" mean?
  • There should not be any special requirements or access needed at the site where the Robot is in operation.
  • There should not be any special requirements or access needed at the site where the User is located.
  • At least "Common sense" security should be implemented.  More specifically:
    • Unauthorized 3rd parties should not be able to control the robot, even if they are on the same network as the Robot or the Operator.
    • Unauthorized 3rd parties should not be able to view video from the robot even if they are on the same network as the Robot or the Operator.
    • Unauthorized 3rd parties should not be able capture passwords or keys at any point in the communications path.

  • A helper at the remote location should be able to connect the Robot to their network without special access to, or administrative knowledge of the network at the Robot location.
  • The interface for configuring the Robot for the network (Network name and password) should be similar to registering other devices on the network.
  • It should not require possession of cables or other special hardware.
  • We are maintaining the requirement that no special software is need on the User's device.  Control remains through a simple web interface.  We call this the "If you can shop, you can drive" approach.  This means that if the users Laptop, Tablet, or Phone can access the internet, and the have access to sites like Amazon or eBay, it should be able to control the Robot without additional network access, privileges or configuration.

Implementing the above has proven a challenge, and we are definitely moving forward in a 3 steps forward 2 steps back fashion.
  • In "a number of items -for- a number of items" trade, I have acquired a Raspberry Pi Zero W.  This will replace *both* the ESPDuino and the OpenWRT router on the Robot.  
  • The new method requires the use of a central (3rd point) server. As for any server configuration, the server may require special network settings.  For now, we are using a newer OpenWRT Router as a small and simple server.
  • We currently have secure video routed from the robot to the server, and viewable by the user.  However, it is not configured to meet all of the above requirements.  We have learned a lot about implementing mjpg-streamer and stunnel4 on the Raspberry Pi.
  • As of right now, the server is making an HTTPS request for the video channel to the Raspberry Pi  Since this won't work over a typical network firewall, some additional work is needed. If the Robot initiates the secure tunnel, then the Server should still be able to initiate an HTTPS request through that tunnel to the Robot requesting the video stream.  I'm going to be pretty good at configuring stunnel4 by the time this is over.  
  • There are several solutions out there for headless connection of a Raspberry Pi to a local network.  We are attempting to use one that first creates a connection to a Bluetooth phone or tablet, and then utilizes an app running on the phone or tablet to allow the network settings to be entered.  In this case, the tablet that is used for the Telepresence conferencing software can be used. This provides a convenient eye-level interface, and also eliminates the need for an assistant at the robot location to install software on a phone or other device.  The problems we are encountering here include the fact that the required Python script is written for older versions of Python, as well as getting all of the Python extensions installed for both WiFi and Bluetooth.
  • The Raspberry Pi does not have any analog input pins.  This means we will need additional hardware to implement the battery voltage monitor.  The requirement for battery voltage will be put on hold for now, and I will order a Raspberry Pi compatible A to D converter board at some point in the future.
  • The Raspberry Pi does have 4 PWM compatible pins for motor control.  The actual robot drive software will be ported from Arduino C to a script on the robot (Probably some Python Code).
  • The Javascript that provided the Driver User Interface was extracted from the Adruino C code, and works unmodified on the OpenWRT router.  While the interface works, there is no GCI behind it to actually communicate with the robot.  The "Meat" of the actual robot control software on both the Robot (Raspberry Pi) and the Server is still ahead of us.
  • I will solder header pins to the Raspberry Pi Zero W (Essentially converting it to a Raspberry Pi Zero WH) and build a harness to go from the Rasberry Pi to the existing motor control board on the Robot.  The ESPDuino and it's daughter card will be removed.  Since the +5VDC is provided by the daughter card, a separate Buck converter will be needed to provide +5VDC at sufficient current for the Raspberry Pi Zero and the motor control board.
Reply Reply Quote Quote Notify of replies Notify of replies  

7  Linuxslate.com Reviews & Commentary / Review Discussions / VTech VSP861 SIP VoIP Phone on Callcentric
 on: Apr 22nd, 2022, 9:55pm 
Started by Administrator | Post by Administrator
I've been a subscriber to Callcentric VoIP Phone Service for well over a decade.  Callcentric.com has always been a reliable and capable Internet Phone company.  Callcentric has worked well with Soft Phones, Handheld WiFi Phones, and Ethernet Desk Phones. This article from 14 years ago reviews an inexpensive IP Phone I was using on Callcentric back then.
To be honest, I don't even remember why I stopped using that phone, but at some point I went through the unnecessarily complex task of setting up the TFTP server arrangement necessary for installing a SIP firmware and configuration files on a Cisco 7940.  That phone had seen previous service in an commercial environment, and was in rough shape when I got it.  An additional decade of service later, including occasional incidences such as the handset falling onto a tile floor, or the whole unit falling off the desk while attempting to reconfigure Ethernet cables eventually took it's toll.  The Cisco 7940 still worked, but it was physically disintegrating.
After a failed attempt to go through the same nonsensical process of configuring a Cisco 8945, I gave up, and purchased a "Standard" Internet SIP phone.  I may write an article on my efforts to get the Cisco 8945 working with Callcentric at a later time.
To get to the point, I ended up with a VTech VSP861.  This post will detail getting the VTech VSP861 working with Callcentric.com SIP service.

VTech VSP861  Photo credit: Manufactures website.
Why I choose the VTech VSP861 and General Observations:
VTech has made cool products for decades.  Yes, it is true that they are best known for educational toys, but IMHO, this isn't a bad thing.  I've always admired the innovation VTech put into children's toys.  I think VTech would be a cool place to work, and they have probably inspired thousands of young people to become Engineers, Coders, or Designers.
If you read my other reviews, however, you will probably also come to the realization that I am not naive. A product made by a toy company will probably be a toy, and the VSP861 does suffer a little from somewhat toy-like quality.  The display is adequate, but not excellent.  It's bright, and has adequate viewing angle for any desk or wall installation. Similarly, the keys are adequate, but retain just a bit of a "toy" feeling. The touchscreen is true capacitive, and just the fact that it has a touchscreen puts it ahead of many similar products.  The unit has a clean and modern design that looks attractive and professional on any desk, but there is still that very slight whisper of "I'm made by a toy company, and not Cisco" that can be perceived in every aspect, including the screen, the overall construction, and the software.
My biggest specific complaint in this regard is that the touchscreen is extremely prone to fingerprints. While this is not particularly noticeable when the screen is awake (backlight on), it's very noticeable in a bright office when the backlight is dimmed. Remember what I said above about looking "attractive and professional on any desk"? If you have any hopes of maintaining that, keep a capacitive pen or screen wipe close by or just use the directional buttons to navigate the screen.
VTech VSP861 is a very standard SIP VoIP phone.  It has both local (on screen) settings, and a web interface.  I was pretty sure that there would not be any problem getting the VTech VSP861 working with Callcentric.  This turned out to be true, and it was registered to Callcentric within minutes.  Within another few minutes, I was able to import a CSV file with hundreds of contacts.  Those contacts can be clicked on in the browser and the phone will call them without any other configuration.  I was also able to set up a simple dial plan so that the preceding 1 is not needed when dialing a domestic (US) number.
Many of the phones features are configurable from the web or local interfaces, and there are user and admin accounts, but if your job title is "Certified Sadist Administrator" don't expect the level of control over the user that you would get with something like the Cisco Unified Communications Manager.
The VTech VSP861 advertises "HD Audio", and it does support high quality CODECs.  Sound quality in the handset is very good, and the speaker phone has deep tone and plenty of power.  Another place the "I'm made by a toy company" quality sneaks out is in the 10 included ring tones.  One ring tone can be uploaded (replaces ring tone #10) for each line.  I definitely need to find a good quality "Classic Phone" ring tone and get it in the right format.
Setting up the VTech VSP861 for Callcentric is so easy that I don't feel any need to detail it here.  Just follow the Callcentric settings for other VTech phones, such as the VSP736 detailed here.  The one thing I will clarify is that your Callentric VoIP account number (1777xxxxxxx) goes in both the "User identifier" and "Authentication name".  Your Callcentric user name (the one you use to log into the Callcentric webstite) is not programmed into the phone.
Reply Reply Quote Quote Notify of replies Notify of replies  

8  Linuxslate.com Reviews & Commentary / Review Discussions / Re: HamGeek FB-8 Chinese Ham Handheld HT Radio Rev
 on: Mar 31st, 2022, 3:04pm 
Started by Administrator | Post by Administrator
HamGeek FB-8 Chinese Ham Handheld HT Radio Review
Google is currently providing an incorrect link to this review which is making this thread appear in reverse order, and mixed in with other articles here on the Linuxslate.com Forums.  The correct URL for the tread dedicated to the HamGeek FB-8 is:  http://linuxslate.com/cgi-bin/forum/YaBB.pl?num=1647740157
Part 7: More about USB Charging
Especially in light of the fact that most other Ham HT's do not include USB charging, many readers may be tempted to think that there is a technical issue with USB charging.  After all, most HT's have 2 cell (7.4 volt) batteries.  How do you charge a 7.4V (8.4V fully charged) battery from 5V?!
In fact there's a reason why Ham HT's usually use 2 cell (2S, or 2 Series) Lithium Ion/Lithium Polymer batteries while mobile phones typically contain a single cell battery (3.7V nominal).  The higher voltage is needed to efficiently produce 5W of RF output.  But USB is only 5VDC -- It's impossible to charge a 2S battery from 5V.  In order for a Ham HT to be charged from USB, a voltage boost circuit must be employed.  I made one to replace the 12VDC "wall wart" for my Wouxun charger, and they are a commonly available accessory.  The USB-C connector on the side of the HamGeek FB-8 simply means that there is a boost converter inside the FB-8.  Given the current capability of USB-C, and most modern USB power supplies, there is plenty of power available to overcome the small inefficiency of the boost converter.  Charging my  Wouxun KG-UV9D(Plus) is not any slower with my home-made boost cable than it is from the provided "wall-wart", and charging the HamGeek FB-8 is not any slower using USB-C than using the provided drop-in charger.
Part 8: Conclusion
With a little runtime on this radio, I can provide some overall thoughts on this radio.  Clearly, it's main benefits are the low cost, and the fact that it has integrated USB-C Charging.  Not having to worry about carrying chargers, battery eliminators, etc. is a huge benefit.  On the ham bands, it puts out the same power as most HT's and communicating via simplex or via local repeaters seems to work fine.  The wide receive is an added benefit, although this is clearly an ancillary function, and it's performance cannot be relied on.
The HamGeek FB-8 makes a good solution as an emergency preparedness radio, or a "keep in the car" radio[1] for the Ham that already has several "more serious" radios.  It is also an inexpensive solution for a newly licensed ham that may now want to invest in expensive radios and dozens of accessories.
While frequencies over an extended range can be entered from the keyboard, it is not fully functional on all bands as a receiver, let alone transmitter.  In addition to the fact that it may not work reliably for other uses, it is also illegal to use it for non-ham purposes.  No radio -- let alone a $50 one -- is a real solution for Marine, FRS, GMRS, Air, etc.
So to answer the question posed at the beginning of this review: Will the HamGeek FB-8 become my Every Day Carry handheld radio?  The ability to charge it via a standard USB-C cable offsets its many deficiencies. It's an adequate HT to jump into a conversation on the local repeater, or to listen in on nearby Air or Marine activity.  Without the ability to program frequencies from a PC or event to name channels from the radio itself, I will just use it mostly in VFO mode, entering frequencies one at a time from a paper list or a file on my phone.  I don't actually carry an HT with me every place, but -- Yes -- The HamGeek FB-8 will likely be the HT I reach for most -- at least until the next "New Thing" arrives on my doorstep.  Perhaps the folks at HamGeek would like to send me a  HamGeek Q900 All-Band SDR.  That would get a Review on my YouTube Channel  
[1] Normal precautions for storing Li-Ion batteries should be observed.  Do not store such batteries where they may experience high temperatures.
Part 9: Owners Manual
Upload/Link soon.
Reply Reply Quote Quote Notify of replies Notify of replies  

9  Mobile Linux Devices / General News / Remote Control of a Yamaha 02R96 Mixer w TouchDAW
 on: Mar 29th, 2022, 9:08pm 
Started by Administrator | Post by Administrator
Remote Control of a Yamaha 02R96 Digital Mixing Console Mixer with TouchDAW
The Yamaha 02R96 Digital Mixing Console, while long since discontinued, it was an advanced and capable studio mixer.  Due to it's availability on the second hand market, it is now finding it's way into the hands of DJ's, bands, and community playhouses where it serves as a live mixing console.

Yamaha 02R96 Digital Mixing Console.  Photo credit: Yamaha USA.
The Yamaha 02R96 can be remotely controlled with Yamaha's proprietary Studio Manager software, however, Studio Manager is not maintained for this mixer anymore, and only had Windows and Mac Versions.
Remote (and preferably wireless) remote control of the Yamaha 02R96 from current non-Windows devices would be hugely beneficial to the Yamaha 02R96 in it's 2nd career as a live mixer. Can the Yamaha 02R96 be controlled from an Android Tablet or ChromeOS laptop?  (NOTE:  Android and Chrome OS are based on Linux.  All Android Phones and Tablets are Linuxslates.)
While research continues, the preliminary answer is "Yes".  Read on to find out what we have done and how we did it.
More Backround:
TouchDAW is an Android app (also runs on Chrome OS) that allows control of Digital Audio Workstations (DAW) and other MIDI devices.
Note:  What is detailed here worked on a  Yamaha 02v96, but should work on similar products such as the Yamaha 01v96, Yamaha 02R, and possibly the Yamaha 01v.
These devices have a USB Host port, however the communications for remote control over this port uses Yamaha's proprietary protocols.  The built-in USB cannot be used for standards-based control of the Yamaha mixers mentioned above.  MIDI, however is a standard, so an inexpensive Chinese USB - MIDI interface cable was used to provide a standards-based interface to the Yamaha 02v96 mixer.

"Generic" USB-MIDI interface.  Photo from Aliexpress vendor listing.  Linuxslate.com is not recommending any particular vendor or retail platform. Other, similar cables should work.
What is needed:
  • Yamaha 02v96 mixer or similar vintage Yamaha digital mixer.
  • Generic USB-MIDI interface cable as shown above.
  • Android Phone, Tablet, or Chrome OS Laptop.
  • If the Android/Chrome device you are using does not have a "Full Size" USB connector (USB-A), you will need a USB OTG cable suitable for the Tablet or Phone you are using (USB-C or USB-Mini OTG cable)
  • TouchDAW Android app from the Google Play Store.  NOTE:  There is a free "Demo" version of TouchDAW available.  I strongly suggest using the Demo version until connectivity is verified. The full version costs $4.95 as of this writing.

Step 1:  Connections:
  • Connect the USB-MIDI interface cable to the Yamaha mixer (DAW).  PLEASE NOTE: MIDI uses the IN-OUT-THRU connection paradigm. The MIDI (DIN) Plug marked IN, must be connected to OUT on the mixer, and vice versa.  The THRU Connector on the is not used unless you are controlling other devices simultaneously.
  • If the Phone, Tablet or Chromebook does not have a Full size USB connector, plug the USB OTG cable into the Phone, Tablet or Chromebook.
  • Connect the USB-MIDI interface cable USB end to the Full size USB connector on the Phone, Tablet or Chromebook, or OTG Cable.

Article in Work.  Please Check Back.
Reply Reply Quote Quote Notify of replies Notify of replies  

10  Linuxslate.com Reviews & Commentary / Review Discussions / Re: HamGeek FB-8 Chinese Ham Handheld HT Radio
 on: Mar 20th, 2022, 1:20am 
Started by Administrator | Post by Administrator
HamGeek FB-8 Review
Part 6: Better description of the Menu Functions

Menus can be selected using the Encoder dial on top, the up/down keys, or by typing the number on the keypad.
  • Menu 01 - Language -- Chinese and English are supported.
  • Menu 02 - Mode - Switches between Channel and VFO mode.  The same as pressing the [# V/M] key.
  • Menu 03 - Voice - Turns Voice prompts ON or OFF
  • Menu 04 - Beep - Turns Key Beeps ON or OFF. See "Bugs" in the previous post.
  • Menu 05 - Rogger - Spelling error for Roger. Roger Beep function.  Note that Roger beeps are illegal for Ham use. The beep is a triple beep, and can be set to Start, End, Both, or OFF.  
  • Menu 06 - Standby - Dual Watch feature on/off, when off, the second (smaller, not selected) frequency or channel will not be heard.  Short cut to this function is by long pressing [6 DW].  DW is displayed at the top of the screen when on.
  • Menu 07 - TX PRI - I have to admit I have not figured this one out yet.  Settings are Edit and Busy.  Shortcut to this function is by long pressing [2 PRI]
  • Menu 08 - Key Lock - Key bad will automatically lock after the selected number of seconds. (or OFF) The keypad can be locked/unlocked by long pressing [*Lock]
  • Menu 09 - Backlight - Sets backlight time out in seconds.
  • Menu 10 - Save Mode - RX Power Saving mode - Off = Receiver always on - the lager the second number of the ratio, the more infrequently the receiver is activated.
  • Menu 11 - Freq Step - VFO step setting.
  • Menu 12 - Freq Dir - Repeater Frequency off set mode.  Offset here in the US is typically -600 KHz for 2M repeaters and +5MHz for 70cm repeaters.
  • Menu 13 - Offset - Repeater Frequency off set amount.  It should be noted that the radio does not default to the above standards.  Offset direction and frequency must be set for every repeater programmed.  See the "Bugs" section in the previous post.
  • Menu 14 - Bandwidth - FM bandwidth. Must be set to Narrow for 2m US Ham bands. This is not set automatically based on frequency.
  • Menu 15 - VOX - VOX sensitivity -- VOX on/off is selected by long pressing [3 VOX]
  • Menu 16 - Squelch - Basic signal squelch setting - 0 is off.  There is no auto squelch setting.
  • Menu 17 - Power - TX power - High or Low.
  • Menu 18 - TOT - Transmit Off Timer - Limits maximum transmit time.
  • Menu 19 - Busy Lock - I have not tried this feature.  I think it is to prevent transmitting on a busy channel.
  • Menu 20 - Scrambler - Voice scrambler function - This is illegal on Ham (and possibly other) bands.
  • Menu 21 - FreqScan - Frequency counter and CTSS/DCS finder -- Pressing [√] [MENU] after it finds the frequency of a nearby or strong signal and detects a code, will copy this frequency into the active VFO and set TX and RX CTS/DCS to the same code. Pressing [x] [EXIT] will discard the results, and return the radio to the previous mode/channel/frequency.  
  • Menu 22 - CTC/DCS - Sets TX and RX CTCSS/DCS - Select mode by pressing [* Lock]
  • Menu 23 - RX CTDC - Same as above for Receive Squelch
  • Menu 24 - TX CTDC - Same as above for sending CTCSS/DCS tones/codes without affecting the Squelch.
  • Menu 25 - Encrypt - Digital encryption? This is illegal on Ham (and possibly other) bands.
  • Menu 26 - Mute Mode - More on this as I work with this radio
  • Menu 27 - Mute Code - More on this as I work with this radio.  This may be illegal on Ham (and possibly other) bands.
  • Menu 28 - Radio - Selects whether FM broadcast or NOAA Weather Radio is received when using the "FM" (broadcast) feature.  The selected mode is activated by long pressing [0 FM]. See the "Bugs" section in the previous post.
  • Menu 29 - R Standby -  
  • Menu 30 - Tail Tone - This is typically a sub-audible tone used to turn a remote radio (repeater) off after a transmission.  Untested.
  • Menu 31 - Memory CH - Store (write) current active VFO in memory (001 - 128).
  • Menu 32 - Delete CH - Clear a channel memory (001 - 128).
  • Menu 33 - initial - Reset radio to factory settings - Erases all stored channels and settings - Selecting YES resets the radio without further confirmation.
  • Menu 34 - Voltage - Displays battery voltage.  It does not actually change or set anything.
  • Menu 35 - Edition -  This displays the Firmware Name and date (apparently not actually a version) -- It does not actually change or set anything.  There is no way to get to a firmware update mode that I have found yet.)

Coming Soon
Scan of the "Owners Manual" (Single Sheet).
Join in the Discussion!
Can you help with any of these functions?  Tips/Tricks?
Please email "john" at this domain, and I will create an account for you.  Your email will not be made public.
Google is currently providing an incorrect URL for search terms such as "HamGeek FB-8 Review".  It is linking to a "Newest Posts" link which is making this thread appear in reverse order, and mixed in with other articles here on the Linuxslate.com Forums.  The correct URL for the tread dedicated to the HamGeek FB-8 is:  http://linuxslate.com/cgi-bin/forum/YaBB.pl?num=1647740157
Reply Reply Quote Quote Notify of replies Notify of replies