Monday, August 17, 2015

More Tweaks and Tuning

Before and after our last roadtrip, I made a few changes to the Digital Dash system.  Nothing major, but I did address a few long-standing issues that have proven to be worth the effort to correct.

The first has to do with the Destinations panel.  If you've read some the previous entries, you know this is a pop-up panel that holds five preset destinations; all I have to do is pick one and the system starts navigating to it.

Normally it has an entry for Home, three places that we visit fairly often, and a slot for an ad hoc destination that's just called "Current".  Usually, I just edit the address for that last entry and don't bother changing the on-screen name.

However, for our last trip I needed to change everything except for the Home designation since we were going to be visiting several places in an unfamiliar area.  Changing the addresses was easy; all I needed to do was change the entry list in the "%V3_Destinations" variable.  However, to get the right names on the screen, I was going to have to manually edit the pop-up scene.  I wasn't too wild about doing that because I was just going to have to change it back after the trip and there's always the chance that I'd end up slightly moving the position of one of the elements.  And since the process that chooses the navigation destination relies on precise screen positioning, a small change would stop it from working.

So instead, I made a new variable in the Startup task: "%V3_DestinationNames" and turned it into an array.  It, of course, holds the onscreen names that I want to have displayed.  I also added a small loop in the Startup task that reads that array and uses Tasker's "Element Text" to change the names in the scene.  That way there's no risk of accidentally moving something and it makes future changes much easier to do.

I actually have two copies of both "%V3_Destinations" and "%V3_DestinationNames" in the Startup Task.  One holds my normal, default values and the other can be used for future trips.  I just disable the pair that I'm not using.

The second thing I did was go through and re-balance all the task priorities.  I admit I hadn't paid much attention to this before, even though I should have.  Before I did this, I would get occasions where the interface would be slow to respond; I'd hit the Next Track button and nothing would happen, so I'd hit it again and all of sudden it would jump two tracks.  Or it would take several seconds to pause the music.

To fix that, I went into every profile that dealt with user interaction and bumped the launched task priority up to around 40.  I also tweaked other tasks while I was at it, and the result is that the system is now very responsive to user input and there's never any confusion about whether the screen (or Bluetooth controller) tap has registered.

The last thing I did on the tablet was to fix an annoyance that has been around for quite some  time.  Every once in awhile the overlay scenes on Torque would "blink"; disappearing for a second before they would pop back on.  When this first started happening, long ago, I did a little investigation, but somehow came to the conclusion that it was something inherent in either Tasker or the Android OS.  After all, I was displaying four overlays, each with many elements and possible interactions and I figured I was just pushing the limits of the systems and it was something that I would have to live with.  And since was an annoyance rather than an actual problem, I just let it go.

But when I began to look at it a little deeper, I realized that it was actually my profile and task that was removing the displays.  I still don't really know why this is happening; the profile is triggered by Torque being in the foreground and none of my code is changing that condition when the problem manifests itself.  For some reason, Torque just loses focus for a fraction of a second from time to time, which was triggering the profile's exit task and removing the display, only to put it right back on again.

Fortunately, the fix was pretty simple.  I modified the exit task for the profile to start with a one-second Wait.  After that, it checks Tasker's built-in %PACTIVE variable to see if the profile is active.  If it is, the exit task is stopped.  This de-bouncing code is enough to stop the problem.  Since I put it in, the display has been rock-solid.

The final change I made was on the phone, rather than the tablet.  Again, if you read some of the earlier posts, you'll know that every couple of minutes the phone is supposed to read the temperature from its sensor and send it to the tablet via an AutoRemote message for display on the main screen.

The problem is that this has never worked quite right.  Messages wouldn't get sent consistently, or they'd get sent but never arrive, or a bunch of them would show up at once.  I ran lots of tests and tried lots of things, but I could never quite figure out the problem.

As it turns out, there were two issues:  One was that AutoRemote normally sends its messages through the web via Google.  That service seems to be a bit buggy and unreliable, causing lost and delayed messages.  The fix was to switch to using AutoRemote's Direct Messaging option.  Now, messages go from the phone to the tablet...uh, directly...using the Bluetooth tether between the two devices.

 That took care of messages the were sent but not received, but the system on the phone still wasn't sending messages consistently.  This time, the problem was of my own making.

When I decided to mount the phone in the car as well as the tablet, I did so because I wanted to have Waze constantly running and visible because I like its road hazard reporting.  However, I don't like its on-screen speedometer; it just too small to be useful.  So, I reused some code that I had originally developed to put a speedometer on Google Maps, without really paying much attention.

I had used a simple task that grabbed Tasker's %LOCSPD variable, converted it from meters-per-second to miles-per-hour and fed that to an onscreen variable.  The task would then wait before looping back and repeating.  The problem was that it was "waiting" exactly one millisecond.  My speed was being reported with great granularity, but that loop was blocking the low-level task I had set up to send the temperature messages.

Rather than rewrite this routine to use AutoLocation, I simply modified it by adding the temperature sending code to the loop.  Now, it has a loop counter that is incremented every time the speed is updated and after so many times, will send the temperature and reset the counter so it can start incrementing again.  I also changed the wait to 250 milliseconds, which is much more reasonable.  The result is that I now get consistent temperature updates about once per minute on the tablet.  It finally works the way I wanted.

None of these changes were very big, but they have made the system more stable, responsive, and user-friendly.

No comments: