QTH.app 0.7.2

[Weston Bustraan]

New build available: QTH-0.7.2.dmg

Anyone running QTH 0.7.0 or 0.7.1 as a digipeater or iGate should update ASAP.

Changelog:

* Fixed issue where digipeated/igated packets were losing their ‘repeated’ flag when copied, causing QTH to think the packets were originating locally. This bug was introduced in 0.7.0.

- Wes W8WJB

[Weston Bustraan]

Ken,

There is only one circumstance currently where QTH generates a Status packet and that is in response to a direct status query. If I see your station online at some point, I will send a query and see if that works.

As far as offline maps are concerned, you may want to check out the article I posted about Using offline maps with QTH.app. Granted, that article is about using OpenStreetMap, not OpenTopoMap, but the concepts are similar.

I've wrestled with how to handle offline maps and ultimately landed on using a tile server approach. There are so many different map formats out there that I felt like integrating support directly into QTH would be a challenge where I would never be able to keep up with. Using a tile server, however, means that the details of converting a given map format into image tiles are moved out of QTH and into a separate code base that does not have to be solely maintained by me. It also means that tile servers can be written in any language that might be convenient and it would be useful beyond just QTH.

For example, I've been asked about whether QTH.app would support maps from the US Forest Service or US Geological Survey. For these, I would probably go the route of creating a Python script that would serve up map tiles based on the GeoTIFF files.

- Wes W8WJB

On Sun, Jan 9, 2022 at 11:24 PM Ken Hagler <kha...@gmail.com> wrote:

On Jan 9, 2022, at 8:02 PM, Weston Bustraan <wbus...@gmail.com> wrote:
>
> * Fixed issue where digipeated/igated packets were losing their ‘repeated’ flag when copied, causing QTH to think the packets were originating locally. This bug was introduced in 0.7.0.

This fixed the location problem, and I’m seeing the correct comment and PHG now. I seem to be stuck with the TCARES status message on aprs.fi, as it shows _last_ status and QTH doesn’t have a way to set a new status (or at least, not that I could find).

Incidentally, I noticed that you support other maps like OpenTopoMap. I weren’t already, please consider adding a way to use offline tiles. It would be especially nice if you could use the “OSMDroid sqlite” format for offline maps, as this is what ATAK uses
--
                              Ken Hagler

|                   http://www.orange-road.com/                   |
|   And tho' we are not now that strength which in old days       |
|   Moved earth and heaven, that which we are, we are --Tennyson  |

[Ken Hagler]

On Jan 10, 2022, at 8:07 AM, Weston Bustraan <wbus...@gmail.com> wrote:
>
> There is only one circumstance currently where QTH generates a Status packet and that is in response to a direct status query. If I see your station online at some point, I will send a query and see if that works.

I saw a couple of pings come in from you on the aprs.fi app on my iPad, but QTH didn’t get them.

[Weston Bustraan]

Actually, it did. The response to a ?APRSS query is to generate a STATUS packet. If you check aprs.fi, you'll see that the old, erroneous status has been updated to reflect your comment string.

QTH. by default, does not display QRU/query messages in the chat window unless "Display QRU requests in chat" is checked in Preferences -> Messaging.

However, on my first attempt, I realized that I had restricted queries generated by the menu options to only local connections. This absolutely makes sense for queries that target all stations, but a directed query seems fine to allow over APRS-IS. Then I remembered that a directed query is just a standard APRS message with a specific payload. So, I went into chat and sent a "?APRSS" message. That was enough to trigger a status response.

The awkwardness with this approach was that, because the spec says that a station should respond with a STATUS message, it did not reply with a message ACK and so it looked like the message was not received in the chat window.

I then made some changes in the code to allow these query messages to go out over APRS-IS. What will happen is, if you attempt to query a station, it will find the connection that last heard that station and send the message out over that connection only, and that can be an APRS-IS connection. The last query I sent this way. I will include this new functionality in the next release.

- Wes W8WJB