SMARTSDR FOR ANDROID DEVICE

IK6IHJ

Hi, it would be an excellent idea to develop a version of SmartSdr for Android devices given the widespread use of this operating system.
Greetings.
IK6IHJ

KD0RC

I agree! I keep hoping that someone with the requisite skill set will step forward and tackle this project.

Trucker

I think the reason no one has developed an Android app for the Flex is due to the many variations of the Android OS and hardware. Even the variations of the Linux OS make it harder to target Linux as well. It is quite possible someone could do an Android app or a Linux app. That did happen several years ago. But, the person who created the Linux program, didn't want to deal with maintaining it and he never shared his work. He did post a video of it working and it looked quite good.

James

WD5GWY

Dan Trainor

Yes, that is always the issue: too many variations of the Android OS and hardware. Cost of maintaining. WA1QZX

Jabi

Where can I get the program for Android?
73,s de Jabi, ea2aru.

VE7ATJ_Don

Hi jabi... as discussed in this thread, there is no version of SmartSDR for android at this time.

John K3MA

If you want to operate your Flex radio remotely with an Android device there is an option. It works but it is not an optimum solution we would all like.

You can use an application called RCForb. You can find out more about it by looking on the Remotehams.com website. Briefly, you run an RCForb server application on a computer at the Flex radio location and you can use the RCForb Android application to operate it. Lots of other things can be done with this configuration once you set it up. It has been around and in use for well over 5 years so it has been well-vetted and used with Flex radios.

You won't get a panadapter to view but the other functions and capabilities of the Flex are available.

Some of you already know about this solution so I post it just for the benefit of those who may not but still want a solution to evaluate on an Android device.

HamRadioVlog

I too would love the Android version. I would happily subscribe/buy it. Maybe if enough people say the same, Flex may see the benefit ($$) of it

Neil D Friedman N3DF

Flex didn’t create an iOS version (Marcus did). Seems unlikely it would create an Android version .

Mike-VA3MW

Have an Android client would be amazing. However, for the foreseeable future, it is not on FlexRadio project list.

However, our engineering team would happily help people get going in the correct direction. If you know any Android programmers, you may wish to lean on them and see if they would help as a project.

Here is how easy it is

https://youtu.be/sUhLGnixdaM?si=hOP3Mn3LGmsgxoAS

Bob - W7KWS -

I posted a YouTube video of my evolved version of for remoting my Flex Radio from an Android phone.

I've upgraded to a Flex 6600 but all 6xxx models should work the same. The cell phone you are watching in the video is a Samsung S22 on Verizon's Visible $45/month prepaid priority unlimited data plan using Verizon's towers and their premium 4G/5G network.

I prefer Samsung phones for this split screen project. I've tested other Android phones and find their implementation of split screen is very cumbersome to get started.

RCForb is shown in the lower portion of the S22's screen. RCForb is a native Android Remote client in the Play Store for $9.99 and is the only software cost for this project.

The preferred RDP server is Chrome Remote Desktop. It and RCForb server for my Windows PC at the station are both free and are available at remotehams.com and remotedesktop.google.com respectively.

The Remote Desktop (RDP) client is running on the phone and is shown in the top half of the S22's screen. The RDP content is of the station PC. In addition to SmartSDR, it shows PST-Rotator which controls the antenna rotator, antenna switch and SteppIR in three separate windows. Also showing is the remote software for my Elecraft amplifier.

Some might find things small in the RDP portion of the phone's screen but most functions are performed in RCForb which works quite nicely with its menu arrangement. For those few functions needing access in the top RDP screen, it's easy to zoom up and down when needed, but muscle memory is usually all I need. Watch the video closely for my finger taps and rotation of the knob.

To show the finger action on the phone, for this video demonstration only, I used Remotix as the RDP client on the phone. My preferred RDP app is Chrome Remote Desktop, particularly on a slow connection. The Chrome RDP client is available in the Play Store. Chrome RDP doesn't interfere with the PC's sound drivers on the PC like Microsoft's RDP server does, and Chrome is more bandwidth efficient than most other RDP solutions.

Bandwidth requirements vary with waterfall rate and frames per second settings in SmartSDR. I keep the spectrum scope at five and the waterfall at around 65 for a 2-megibit/second overall data rate and these settings work fine for me.

Note, RCForb is operated using your finger, including rotation of the tuning knob. Tapping the top or bottom of the knob will move the frequency by on step which is selected to the left of the knob. I use 5KHz. steps. The RDP curser arrow is also moved with your finger using the screen as a trackpad. No mouse is used or needed.

I hope you find this update useful.

https://www.youtube.com/watch?v=WIS3c21w6AU&t=77s

K5WH

Well, we may have the answers to a very long-awaited functionality for the Android environment.

Check out this YouTube video, and catch him at Hamvention this weekend for more details.

It's not 100% just yet, but it appears to be VERY close.

Glass Radio MVP 2024-05-09 (youtube.com)

I for one, can't wait to get my hands on it, and major kudos to the author for making it happen.

Walter/K5WH

David Decoons, wo2x

normancyyj

Can't wait for it to be available. Right now I use Chrome remote on my Android tablet to control the 6600. W

ChrisAC9KH

The iPad is by far the dominant tablet platform both globally, and in the U.S. It has a tightly controlled development environment that is standardized, making it easy to support. By contrast, Android is fragmented, the hardware is not standardized, and you can buy a brand new cheap Android tablet that may not even support the latest Android operating system. Each vendor that sells Android tablets releases their own version of Android, and while Google updates the Google apps onit, the base system and updates come from the vendor. And this is not even consistent among vendors.

I used to develop and maintain the codebase for a flight control/ground station app on Android for drones, and believe me, the Android ecosystem is a nightmare. Even simple things like UI scaling for different size and resolution screens, adjusting for tablet orientation, or what processor/GPU does it have and what SDK that does one require to get it to build and run, that is trivial on iOS becomes very difficult to achieve with any sort of consistency on Android.

Mobile platforms are the future, the venerable desktop PC is a dying breed. But I finally gave up on supporting Android because it just wasn't practical, and went to iOS only. Apple's development environment can't be beat and it makes life a lot less stressful as a software developer.

Mike-VA3MW

Chris, this is what we have learned as well.

ChrisAC9KH

Mike, yes, and unfortunately linux has much of the same problems. There's not much consistency between different distributions. The back end is the same and it's trivial to implement the Flex API to get it to work. But if you want some consistency in the UI between different distributions and desktop environments, that is more of a challenge. Do you build the UI on GTK for the Gnome environment, and then have it stick out like a sore thumb on KDE and possibly some of the menus or UI functions don't work? This is the problem.

I suppose a UI could be designed to make it somewhat cross-platform using something like Qt. But I'm not particularly fond of Qt either. It also has some problems with scaling elements in the UI on some mobile devices with chopping off of dialogs or buttons on Android, but that work fine on a laptop or desktop PC.

I personally use SmartSDR for both Mac and iOS, but I also sometimes use xSDR6000 and I've done some work on that for my own use. Doug is in the process of re-writing xSDR6000 to make it a more native MacOS application written in Swift. In the end, that is the best - develop the codebase and UI native for the operating system for which it's intended because cross-platform attempts rarely succeed. Even MacOS to iOS requires two different codebases in most instances. Even though the two operating systems run the same kernel and even look pretty much the same, a touchscreen device requires different UI elements.

AB4MW

> @ChrisAC9KH said:
> Mike, yes, and unfortunately linux has much of the same problems. There's not much consistency between different distributions. The back end is the same and it's trivial to implement the Flex API to get it to work. But if you want some consistency in the UI between different distributions and desktop environments, that is more of a challenge. Do you build the UI on GTK for the Gnome environment, and then have it stick out like a sore thumb on KDE and possibly some of the menus or UI functions don't work? This is the problem.

Using a cross-platform UI system like Flutter or Qt makes this doable. I have had UI's that were nearly indistinguishable between Windows and Linux and Mac on both platforms.

For ease of creation and time to MVP, Qt. For less hassle to make apps for Win/Lin/Mac/iOS/Android/Web from one code base, Flutter.

AB4MW

example Qt6 controller in progress

ChrisAC9KH

Where Qt runs into a problem is achieving consistent look and feel for the platform. A good example of this is the difference between the radio control panel in SmartSDR on Windows vs Mac/iOS. On Windows the panel looks "busy", and IMO not particularly intuitive. It has a scroll bar on it. Hover over something with your mouse and move the scroll wheel and it suddenly starts adjusting radio settings instead of scrolling the control panel up or down. Click on the selection buttons on the top (like for the EQ) and the frickin thing disappears. Put your mouse over the bandpass filter and now a dragger thing appears to change the shape of it, but if you move the scroll wheel while on that dialog it changes the frequency of the radio! This is typical of the way Windows developers do things. Put all sorts of wiz-**** stuff in it that's just sort of piled on randomly and that's not particularly intuitive.

Move this to Mac or iOS, and users are NOT gonna be happy with it. When we scroll in the radio panel we expect it to scroll, not adjust the radio settings - that's what the sliders are for. Whether you are on a MacBook Pro or an iPad Air 5 using a mouse, this has to work the same. When we select one of the buttons on the top we expect that one to slide up or down and come into focus because we selected it, not have it disappear out of the panel. Or if we want to change the shape of the bandpass filter, we expect to be able to do that with a dialog that's intuitive and that allows us to set it precisely to what we want, not randomly drag it back and forth and up and down until it looks right. If you want to drag your filter around you can do that on the panadapter, why duplicate it on that little tiny filter shape box in the radio control panel?

I could go on, but I think you see what I'm getting at. They both achieve the same thing, but they have to achieve it with the look and feel that's native to what the user expects on their platform of choice to have a good software application. That's virtually impossible to do with cross-platform attempts like building a UI with Qt - been there, done it, tried it. On linux or Android it probably don't matter, since both of those are a hodgepodge of software thrown into a big pile in the first place. On Windows, Mac and iOS users expect it to look and act native with the rest of the system, and that includes location and function of dialogs in Settings context menus.