The following aprsisce poll is now closed. Here are the
final results:


POLL QUESTION: Which way should the zoom up/down +/- work?

CHOICES AND RESULTS
- Up/+ should show more area/stations, 3 votes, 50.00%
- Up/+ should show more detail, 3 votes, 50.00%



For more information about this group, please visit


For help with Yahoo! Groups, please visit

--- In aprsisce@..., "Peter Loveall" <pete@...> wrote:

I would say that since there have been no other reports of javAPRSSrvr just quitting sending packets but maintaining the keep-alives, the server "going dumb" is actually the result of an improper filter setting. The advantage of setting the filter at login is the logresp comment you get back from the server confirming your new filter setting. At any time later, you can still use a comment line to set the filter to something else.

I (hopefully) never said it was a server bust. I'm dealing with a bunch of unknowns here, and I've ONLY seen the problem while driving down the road going in and out of cellular coverage. It's not the world's most reproducable environment.

Since I'm already fielding the #logresp and you've confirmed what I suspected that I'm able to update the filter later no matter which way I specify it, I'll see about embedding the first filter in the logon command.

I am unable to test the software at this point because I have no need for highly active data flows to my cell phone and I want a reconnect attempt as soon as possible when I do use my cell phone for APRS. Personnaly, I find masking a client issue by extending the disconnect time only delays determination of the real cause of a problem and usually leads me to frustration with any software that I work with.

I'm not sure I understand the "reconnect as soon as possible" bit. APRSISCE does try to immediately reconnect if a connection is lost UNLESS the Windows Mobile connection manager status says that it won't succeed anyway. The disconnect time is not delayed, by not counting the keep-alives as traffic, I'm actually ALLOWING the disconnect to occur after the quiet time has expired. Before I started ignoring the keep-alives, the client would simply go (effectively) dead receiving ONLY keepalives until the user got truly frustrated and closed the client.

I'm not trying to "mask a client issue", I'm trying to resolve the issue while still keeping the Beta functioning at the same time. That's the whole point of BETA software, to work around unknown issues to allow other testing proceed while still attempting to find a permanent resolution to the workarounds. Frustration comes with the Beta landscape and testing partially baked software isn't for everyone.

I have no doubt that the issue is in my client code, it's certainly the new kid on the well established block. As soon as I understand all of the vagueness of "always on" cellular data connections and the behavior of continuously open sockets across cellular switches, I have every confidence that I'll eliminate the problem. In the meantime, at least the client recovers the connection and gets the feed going again as soon as it notices the lack of non-keep-alive traffic.

Lynn (D) - KJ4ERJ - Adding my contribution to the APRS community

--- In aprsisce@..., "ldeffenb" <kj4erj@...> wrote:

--- In aprsisce@..., "Peter Loveall" <pete@> wrote:

--- In aprsisce@..., "ldeffenb" <kj4erj@> wrote:

5) Corrected the logon string's Version content so we should quit getting the "adjunct HH:MM Missing filter keyword" complaint at login (most of you have probably never noticed anyway).

This would have been noticed as the server "going dumb". If the server's filter is not set properly, then all you will receive is keep-alive comment lines. I highly recommend that you go back to considering the keep-alive comment lines as confirmation that the server is there and functional.

Actually, this would NOT have caused the server dumb. I don't send the filter string with the logon, but send it as a separate command so that I can re-send it if the user re-configures the settings. I only put the vers on the logon line, but prior to the fix, my version string had an embedded space causing the server to THINK I was trying to send a filter.

I would say that since there have been no other reports of javAPRSSrvr just quitting sending packets but maintaining the keep-alives, the server "going dumb" is actually the result of an improper filter setting. The advantage of setting the filter at login is the logresp comment you get back from the server confirming your new filter setting. At any time later, you can still use a comment line to set the filter to something else.

I am unable to test the software at this point because I have no need for highly active data flows to my cell phone and I want a reconnect attempt as soon as possible when I do use my cell phone for APRS. Personnaly, I find masking a client issue by extending the disconnect time only delays determination of the real cause of a problem and usually leads me to frustration with any software that I work with.

73,

Pete AE5PL

--- In aprsisce@..., "Peter Loveall" <pete@...> wrote:

--- In aprsisce@..., "ldeffenb" <kj4erj@> wrote:

5) Corrected the logon string's Version content so we should quit getting the "adjunct HH:MM Missing filter keyword" complaint at login (most of you have probably never noticed anyway).

This would have been noticed as the server "going dumb". If the server's filter is not set properly, then all you will receive is keep-alive comment lines. I highly recommend that you go back to considering the keep-alive comment lines as confirmation that the server is there and functional.

Actually, this would NOT have caused the server dumb. I don't send the filter string with the logon, but send it as a separate command so that I can re-send it if the user re-configures the settings. I only put the vers on the logon line, but prior to the fix, my version string had an embedded space causing the server to THINK I was trying to send a filter.

If you are concerned about if the login was handled correctly, the logresp comment line that is sent after the login contains confirmation of the login, whether it is verified or not, if the filter was set properly, and what server you logged into.

I field and log the logresp line to a debug log just for that reason. However, since the filter isn't on the logon line, it doesn't help me with that.

The keep-alives are generated after 20 seconds of inactivity on the port -from- the server which is every 20 seconds if you don't set a filter and no one sends you a message. If you do your reads as ReadLine with receivetimeout set to 30000, you shouldn't have any hang issues on reading (be sure to encapsulate in try/catch code looking for any exception). If there is an error, close the connection and try to reconnect.

My hang issues are with DNS translations and the initial connect as I'm doing the synchronous socket calls currently. I poll the Window Mobile Communications Manager for status, but sometimes even though it APPEARS to be on-line for data, the gethostbyname() and/or connect() calls take a LONG time to timeout.

I don't issue an recv() call unless an ioctlsocket() shows that there is actually data available for reading, so once I'm connected, hanging is not a problem, just not getting data or an error for an extended time period, what I call the Quiet time limit.

I WILL re-enable counting the keep-alives as non-quiet traffic as soon as I'm happy that my client is actually working correctly. In the meantime, the 10 or so (max) copies that are out there in use shouldn't be doing much to the APRS-IS.

73s to you and keep asking the questions, it's how I learned as much as I think I know!

Lynn (D) - KJ4ERJ

--- In aprsisce@..., "ldeffenb" <kj4erj@...> wrote:

5) Corrected the logon string's Version content so we should quit getting the "adjunct HH:MM Missing filter keyword" complaint at login (most of you have probably never noticed anyway).

This would have been noticed as the server "going dumb". If the server's filter is not set properly, then all you will receive is keep-alive comment lines. I highly recommend that you go back to considering the keep-alive comment lines as confirmation that the server is there and functional.

If you are concerned about if the login was handled correctly, the logresp comment line that is sent after the login contains confirmation of the login, whether it is verified or not, if the filter was set properly, and what server you logged into.

The keep-alives are generated after 20 seconds of inactivity on the port -from- the server which is every 20 seconds if you don't set a filter and no one sends you a message. If you do your reads as ReadLine with receivetimeout set to 30000, you shouldn't have any hang issues on reading (be sure to encapsulate in try/catch code looking for any exception). If there is an error, close the connection and try to reconnect.

73,

Pete AE5PL

Testers,

There's yet another release of APRSISCE available (APRSISCE6P090811.zip)! Here's a short list of what's new and different.

Lynn (D) - KJERJ

1) Station comments are now displayed in the station popup.

2) Station course and speed are parsed and displayed in the station popup (ONLY if provided by remote station, not "guessed" at by distance/time). (Thanks to John N8JJ) I'm thinking about providing a scaled arrow (short and thick for slow, long and thin for fast) in the course direction in the future, thoughts? Also, should I think about calculating course and speed, even though this can result in strange answers?

3) Station PHGR (Power/Height/Gain/Range) is parsed, calculated, and displayed, including the Beacon Rate (per hour) if provided.

4) Rng: (Range) has changed to Pos: (Position) in the station popup and the bearing is now displayed in 16 compass point text, not degrees. (16 points are also used for the course if displayed)

5) Corrected the logon string's Version content so we should quit getting the "adjunct HH:MM Missing filter keyword" complaint at login (most of you have probably never noticed anyway).

6) No longer display the Pos: 0 @ 0 if you station pop-up "ME".

7) Screens bigger than 320x240 in size will increase the displayed icon size as you zoom in. This looked better than I expected. I just need to figure out a graceful scale also.

8) Station popup coordinates no longer display table/icon information, but use spaces. The coordinates are now more readable and the selected icon's name is displayed anyway.

9) Double-clicking an empty map space now displays OSM Tile fetcher queue information and doesn't say (1 failed) while it is actively downloading a tile.

10) The OSM Tile prefetcher now pulls all outward-zooming parent tiles whenever a lower level tile is retrieved. This makes zooming out faster. It is smart enough to stop when it encounters a tile that's already been loaded.

11) Corrected a timing issue that could cause the tile pre-fetcher to access non-allocated memory. I have no idea what the user-side of this would have looked like, but it probably would NOT have been pretty.

12) TCP communication errors are now forced into APRSISCE.log, even if Debug Logging is not enabled.

13) The forecast range red dot is now 100% opaque again to avoid the square background it had at 50%. I need to get fade and transparency working together for the station icons.

14) Double-clicking where a rectangle overlaps the circle should now honor the top rectangle, this was really strange for a while!

Known Issues:

1) I had the tile prefetcher lock up last night during testing. I ran out of data coverage range and it just stopped fetching tiles. Closing and restarting the client corrected the situation.

2) If a corrupted OSM tile is fetched (web server error during the fetch, for instance), that tile file is detected as corrupt but not removed from the device. This means you'll have a permanent map "hole" there at a single zoom level until I get this fixed.

To Dos: (Incomplete)
Parse and display Frequency object information
Delete bad PNGs to allow refetch
Support larger Icons (complements Noel W8TVI)
Fix up fonts for VGA (640x480) devices (test with Noel W8TVI)
Allow configuration of location for OSMTiles cache (w/o editing XML)
Allow configuration of date/time display & GMT vs local (Dave N8PU)
Allow configurable removal of some screen elements (Satellites, John N8JJ)
Optimize circle redraws for off-screen stations
Track selected station (in center of screen)
Pan (Drag) screen for browsing the map
Record/Recall last DNS/IP for OSM/APRS-IS (faster reconnect)
Asynchronous TCP/IP connections & reading (solves hangs)
Timeout on OSM Tile fetcher (solves stalls)
Implement whatever results from the Zoom +/- Poll

Win32 client only for the following:
Simultaneously track multiple targets in separate circles
Support NMEA GPS

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the aprsisce
group.

File : /APRSISCE6P090811.zip
Uploaded by : ldeffenb <kj4erj@...>
Description : New Station Info (Comment, PHG, cse/spd), Logon fix, OSM prefetcher fix & expansion

You can access this file at the URL:


To learn more about file sharing for your group, please visit:


Regards,

ldeffenb <kj4erj@...>

Lynn W. Deffenbaugh wrote:

Noel,

So I was just comparing the two versions of the program,
and I think I figured out what it is I didn't like about the normal one:
The icons get too small when you zoom out to see more map. Just too
small on the 3" VGA screen for my taste.

So, they get too small too quickly in both versions, right? I only
expanded them in the second, but didn't change when/how they get small.

Yeah... they get too small.
I'd rather them just overlap than get really small.

I do kinda like the bigger icon at higher zoom levels.

I don't think they really need to made any bigger.. at least not on this
screen. But it would make them look nicer at high zoom, so I'll work on
that.

So the 2x maximum expansion looks good to you? I concur with that
opinion as well.

I think 2x the "normal" size would be good on a VGA device.

Also, what overall size (X/Y) should I make the grid for the larger icon
set?

To get them up to double size clearly, we'll need each square to be 42
pixels instead of the current 21 pixel squares (21-4 giving the 17x17
icons that the program ends up painting).

I did a quick experiment here with IrfanView and I think if you start
with just a resize/resample 200% retaining aspect ratio, you'll have a
good starting point to clean them up. As I mentioned before though, try
to make sure that all non-important pixels are actually pure white
(RGB(255,255,255)) or they won't go transparent correctly.

Will do.

I'm trying to figure out how to fade them out and keep the transparency
so I quit getting the square around fading stations. If you look close
at the red dot in the screen caps you sent me, you can see what I'm
talking about. I was drawing it at 50% fade, but that messes up the
transparency. I'm going back to 100% for the red dot, but aging
stations will still start having a square around them as they fade.
I'll get it fixed somehow!

I guess I didn't mess around with that too much... it didn't bother me.

Thanks again for any efforts you can do on getting clearer, bigger
icons. I'm hoping that I can just use them for all resolutions with the
320x240 phone just using them at 50% with Win32 doing the scaling for
me. Scaling down tends to look better than scaling up!

Lynn (D) - KJ4ERJ

Noel
W8TVI

My reason for voting for the "+" to 'zoom' in to show more details is partly
based on the way the works, or Google Earth,
the "+" plus button brings the map in for more detail, sort of like getting
right down to street level, as opposed to looking down from a plane or
something that is way up in the sky; just my two cents on that.
Dave N8PU

--- In aprsisce@..., "David Shrum" <dave.n8pu@...> wrote:

That page is way above my understanding, but what I had in mind was to be
able to change the way it is displayed so if I wanted to have the
month/day/year I could, but if another user wanted it day/month/year or
year/day/month they could.

I'll make it much simpler than that page, but it basically says that there'll be %X parameter that represent the various components of the date/time. Whatever you put in the configuration parameter will govern what displays.

On the time it would be nice if we could select a time zone independent of
the device, say GMT time for instance we could and be able to select either
a 12 or 24 hour format.

GMT vs the device is not too difficult. Arbitrary time zones are MUCH harder! 12 vs 24 will be automatic given the %X parameters mentioned above.

Since you ask, I thought I would ask. :)

I'm always willing to listen to any and all ideas. The best part about being the developer is I get to choose what does and does not make the cut (although with me, it's normally WHEN it gets implemented, not IF).

I can't remember if you said you were going to try to let us track a
specific call, but that would be nice; similar to what it is with
where you can 'type' in a call and if it is
available it will display it and scroll the screen so we can view their
progress. I know it is much better on a computer screen but if you are out
away from yours it would be nice to see where they were.

Yes, that is absolutely in the plans, as is the ability to pan around the map with some way of getting it back to you (or the currently selected station) in the center. Not sure when I'll get that going, but I just added the course/speed parsing. I've got a few more things to do before it's worth putting another release out though.

Lynn (D) - KJ4ERJ

That page is way above my understanding, but what I had in mind was to be
able to change the way it is displayed so if I wanted to have the
month/day/year I could, but if another user wanted it day/month/year or
year/day/month they could.

On the time it would be nice if we could select a time zone independent of
the device, say GMT time for instance we could and be able to select either
a 12 or 24 hour format.

Since you ask, I thought I would ask. :)

I can't remember if you said you were going to try to let us track a
specific call, but that would be nice; similar to what it is with
where you can 'type' in a call and if it is
available it will display it and scroll the screen so we can view their
progress. I know it is much better on a computer screen but if you are out
away from yours it would be nice to see where they were.

Thanks
Dave N8PU

Dave,

Would a strftime format string be suitable for your time/date format
specification? Or how did you have in mind to configure it?



Lynn (D) - KJ4ERJ



David Shrum wrote:

Noel,

So I was just comparing the two versions of the program,
and I think I figured out what it is I didn't like about the normal one:
The icons get too small when you zoom out to see more map. Just too
small on the 3" VGA screen for my taste.

So, they get too small too quickly in both versions, right? I only expanded them in the second, but didn't change when/how they get small.

I do kinda like the bigger icon at higher zoom levels.

I don't think they really need to made any bigger.. at least not on this
screen. But it would make them look nicer at high zoom, so I'll work on
that.

So the 2x maximum expansion looks good to you? I concur with that opinion as well.

Also, what overall size (X/Y) should I make the grid for the larger icon
set?

To get them up to double size clearly, we'll need each square to be 42 pixels instead of the current 21 pixel squares (21-4 giving the 17x17 icons that the program ends up painting).

I did a quick experiment here with IrfanView and I think if you start with just a resize/resample 200% retaining aspect ratio, you'll have a good starting point to clean them up. As I mentioned before though, try to make sure that all non-important pixels are actually pure white (RGB(255,255,255)) or they won't go transparent correctly.

I'm trying to figure out how to fade them out and keep the transparency so I quit getting the square around fading stations. If you look close at the red dot in the screen caps you sent me, you can see what I'm talking about. I was drawing it at 50% fade, but that messes up the transparency. I'm going back to 100% for the red dot, but aging stations will still start having a square around them as they fade. I'll get it fixed somehow!

Thanks again for any efforts you can do on getting clearer, bigger icons. I'm hoping that I can just use them for all resolutions with the 320x240 phone just using them at 50% with Win32 doing the scaling for me. Scaling down tends to look better than scaling up!

Lynn (D) - KJ4ERJ

One feature I would like and that would be to be able to change the
date and time format to the way I want it.
Dave N8PU

So I was just comparing the two versions of the program,
and I think I figured out what it is I didn't like about the normal one:
The icons get too small when you zoom out to see more map. Just too
small on the 3" VGA screen for my taste.

I do kinda like the bigger icon at higher zoom levels.

I don't think they really need to made any bigger.. at least not on this
screen. But it would make them look nicer at high zoom, so I'll work on
that.

Also, what overall size (X/Y) should I make the grid for the larger icon
set?

Noel
W8TVI

ldeffenb wrote:

Oh, one more thing. If you do tackle making a larger icon set, it is important that all background pixels be pure white (RGB(255,255,255)). The program uses this as the transparency color when copying the icons to the screen.

Lynn (D) - KJ4ERJ

Noel,

--- In aprsisce@..., Noel Shrum <noel.w8tvi@...> wrote:

I have a graphics tablet and The GIMP.

What format are you using for the icons?

Perhaps you could send me a copy and I could start working on a larger
set for you?

I just posted APRSISZoom.zip that contains a zoomed icons for screens larger than 320 pixels. As your scale gets smaller than 2 miles, the icons will begin to expand (the actual scale code is listed below for C programmers). See if they look ok on your higher resolution screen before diving into the editor.

But, just to cover all bases, I've also included the .BMP files from which the icons are drawn. The icons are clipped out of these composite pictures automatically by the program. My intention is to allow users to specify external Icon files as well, if they ever want to customize them. For that reason, I'd really rather not build the support for two sizes of icons unless it is visually necessary.

Of course, if you do take the time to expand these BMPs and clean them up manually, I could always make the larger set the standard and scale them down on smaller screens!

The program assumes that the icons are laid out in a 16x6 grid. It divides the image width and height by 16 and 6 to get the actual icon size. It then assumes a 2 pixel border all around. In the end, it gets a 17x17 pixel icon out of a 21x21 repeating square.

Let me know how the expanded icons look on your screen. They didn't actually look as bad as I thought they might when I previewed them here (not on a phone screen, though!)

Lynn (D) - KJ4ERJ

PS. Here's the current brute-force code that does icon scaling. I want to make it a more dynamic scale based on circle size, device resolution, and the scale of the screen, but, as I mentioned before, I haven't worked out the details yet. It's striking a balance between recognizability and showing lots of stations in a small area.

Of course, if you click on a station icon, the popup does tell you what the icon is supposed to be!

if (scale >= 128)
{ Mult = 1; Div = 2;
} else if (scale >= 64)
{ Mult = 2; Div = 3;
} else if (scale >= 32)
{ Mult = 3; Div = 4;
} else if (width < 320) /* Drop out all 320x240 screens */
{ Mult = 1; Div = 1;
} else if (scale >= 8) /* Bigger screens begin to magnify */
{ Mult = 1; Div = 1;
} else if (scale >= 2)
{ Mult = 5; Div = 4;
} else if (scale >= 0.5)
{ Mult = 6; Div = 4;
} else if (scale >= 0.125)
{ Mult = 7; Div = 4;
} else
{ Mult = 2; Div = 1;
}

(The poll is now open for voting. I may know about APRS-IS and Windows Mobile programming, but Yahoo Group management goes beyond my abilities! Thanks for letting me know!)

Greetings,

I'm taking some abuse from my son about what the up/+ and down/- should
do with respect to zooming the map, so I'm throwing it out to the group
to help me make the client mostly intuitive for most of the people.
Things I'd like you to consider before voting are:

Showing more or less map area
Showing more or less map detail
Showing more or fewer stations

Notice how I'm NOT using the word zoom in these, because there are no
"in" or "out" keys on the keyboard. What does in and out mean anyway?
So, the poll link below asks what the Up/+ should do. Give me your
group opinion and I'll make it so.



Lynn (D) - KJ4ERJ - Author of APRSISCE

开云体育

I have a graphics tablet and The GIMP.

What format are you using for the icons?

Perhaps you could send me a copy and I could start working on a larger
set for you?

Noel

Lynn W. Deffenbaugh wrote: