Android App

W4WHL

Here is the latest.  Its not pretty, but I will spend pretty time on android.  I think I have the basic concept down.  Now to figure out the Opus


https://www.youtube.com/watch?v=i98ckWJ_0Qg

Walt - KZ1F

What I was saying William is to separate processing of the packet from receiving the packet. AWT is also not your best choice. That won't do GPS. However, if you used JavaFX8, it would use Prism which mediates the technology used.

W4WHL

Ah Gotcha!  I'll research it

Walt - KZ1F

Well, that may not be a design goal for you whereas it is for me. I could actually take this and convert it to Android but I think what I will do with Android is an Android specific UI.  Gotta research drawing a 16bit line, hmmm. Actually, DAH?, what the graphics context takes is a float anyway so I will have to convert the short to a float. That DAH was 0x000c is a short.

William, the Android will definitely do OpenGL which definitely will do GPS..at least in Android L or 5.x. For people with older devices, I don't know. They could upgrade to 5.x. I think I will base my Android on 22, it picked up the Material L&F which has some very nice effects.

Are you using Android Studio? Android Studio allows you to either send the app to the device or emulate it in a vm.

Walt - KZ1F

I believe there was a third option Steve, earlier versions of SSDR would process the data in the receiveUDP callback whereas now Eric simply adds it to a queue, as I was pointing out to William, and processing each in a non-IO thread. Once that changed I no longer had an issue. In fact, the only time I did have an issue was if the monitor slept and when it woke up it would be like hyperdrive (my thread of similar name) trying to catch up but there were no UDP interrupts so just mostly blank lines came out. Again, after the queue change all is fine.

Walt - KZ1F

I don't have any huge objection to history, I just didn't want an infinitely long waterfall. Aside from that, thank you Steve. I haven't tried processing the FFT or waterfall data as I am still working on final layout.

W4WHL

I am using Android Studio

G4YDO

hi,  great work. i have it working on my samsung 8 phone, apart from no audio. i think i must be doing something wrong?

Walt - KZ1F

https://github.com/chriswhocodes/DemoFX
download the zip, build with ant
./run.sh -s true

the difference between hardware acceleration  and software acceleration is 61fps v 30fps, still better than the 24 I believe SSDR has.

EA4GLI

Hi William,

Can I also be in the beta test list?

Thanks!

MikeMeeks

Me too.

Walt - KZ1F

If you actually read through this William says where he is putting stuff.

"Let me know the good and the bad   But please don't ask how to load it.  Google it"

https://www.dropbox.com/s/3vvwcf82xkper3w/app-debug.apk?dl=0

EA4GLI

I added a small video running the app in my shack.


https://www.youtube.com/watch?v=VawEewpyQIs

EA4GLI

Thanks Walt. I realized a few minutes after I posted. Still, if William wants/needs any beta testers I am game!

Walt - KZ1F

@Sal, that's kind of cool. I am confused though. What was driving the the two monitors? Was this with SSDR driving the monitors and William's android app moving the frequency? You were turning the dial on the Nexus as well as the Flex Control

EA4GLI

Yeah, I need a tripod or someone to record me. I was using my cellphone so i had to keep going up and down. Couldn't get a wide angle shot with everything.

I was using both, William's app most of the time and then the Flex control at the end for comparison.

And yes, ssdr out of a laptop is running on both monitors.

W4WHL

I got a pan-adapter successfully run on android.  It was much tougher than on the PC using java.  This is just a dry run, I have much more work to do.  I need to streamline the methods to speed everything up.  But I'm pretty darn chuffed its working at all.

https://www.youtube.com/watch?v=8plHMGvIq4M

The jerkyness is my phones recording.  Not the App

William

Walt - KZ1F

Yes that's very nice indeed

Michael - N5TGL

Very, very cool, William!

IW7DMH, Enzo

Simply great! The wild horse is nearly tamed

Chris DL5NAM

William great work. Thanks

Still only one wish. Please can you add in file name some info for what device (Android or CMD...)  and version numbering? It help's us if we download and store more then one file. Thanks

Walt - KZ1F

William, How are you handling bidrectional notifications and events?

Walt - KZ1F

Another question I have is how married to Processing are you? When I mentioned JavaFX8 before, it natively uses GPU via Prism and you can move the app to any platform via the Gradle build script. That zip file will demonstrate between run.sh and softrun,sh the difference in performance by offloading the graphics to the gpu vs doing it in source. Something to think about.

W4WHL

Walt,

I'm still researching this, as its new to me.  I am having performance issues between threads.  Even using parallel processing, one thread still hangs because of the other.

I'm currently running two parallel Asynctask.  One for handling tcp read/writes.  And another for UDP reads.  My issue is not the graphics.  Turning all screen writes off, does not stop the hangs.  The problem lies with the network read/write routines.

Both asyntask are in an infinite loop, constantly listing for incoming data.  if one thread is processing data the other is hung.

I'm not completely sure how to solve this.  I thought runing them in seperate threads would solve the issue.  But it doesn't.

Open to ideas on this.

William

Walt - KZ1F

try this:

void startMyTask(AsyncTask asyncTask) {
    if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB)
        asyncTask.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR, params);
    else
        asyncTask.execute(params);
}

In early versions of Android, if you had multiple asyncTasks only one would run at a time, exactly what you are describing. This tests for the version of Android and dispatches the asycTasks accordingly.

Or, upgrade to 5.x
Actually, I am glad you told me that as, I am running on 5.x but when it goes to GooglePlay it may be downloaded to an earlier version so I will do the same when I have asyncTasks.

W4WHL

Walt,

I'm already doing this.  But its not working as I expected.  For some reason the Asynctask are still affecting the performance of the other.  Adding thread.sleep for a few ms in each, held some, but I still get hangs.

William

Stan VA7NF

Not familiar with Android dispatcher but very familiar with async processing.  "constantly listening for incoming data" infers that you have two threads each without a wait.  With a single processor the dispatcher will run each thread until a break then dispatch the other thread.

W4WHL

Stan,

Thanks,  how would you go about fixing this.  Any ideas?

William

Walt - KZ1F

As I don't know what hardware or version of Android William has I can't say definitively you are wrong but I am almost positive you are wrong. The days of 'waiting' in a spin loop are about 20 years past. Android derives from Linux and Linux is a multi threaded kernel. The thread listening for IO from the TCP/IP stack is in a wait, this gives any other thread an opportunity to run. Ultimately the thread is blocked  waiting on the main OS's TCP/IP stack. when an packet arrives for that port the thread is marked runnable. The concept of Executor is new in Java5 Even if there was but a single process that was time slicing multiple threads each thread would still get access to the cpu, so long as it was runnable. William, you aren't doing anything with synchronization are you? That could be killing you. I don't believe you are blocked where you think you are blocked.

What version of Android are you running and what is the tablet manufacturer and model? Also, if you go to settings->about and look for model, version, and kernel. You should be able to model what is happening in the VM emulation. Is it possible to copy the code running under asychTask?

W4WHL

I'm doing quite a bit or array manipulation in the UI thread.  I have quite a few methods to manipulate and parse data.  All of which run in UI thread.  I think this is the root of my problem.  The data is coming in so fast, the UI thread is hanging processing the data.

I think I need to move all this to separate threads.  But that is a bit of work that will take some time.

William