Re: Number of blobs shown in the track


kc8sfq
 

As I said, just an observation. NOW if you could have the map rotate as I drive based on heading. That way the map resembles the lay of the land outside my window. While you're at, why don't you have the top on the Jeep icon go up when I drive onto a NWS warning area?

Actually, the track up feature would be nice and would help with the mental gymnastics when driving south. I wouldn't be surprised if that would cost a lot of code.

73:  Ron

PS: I hope to be giving APRS demos most of the weekend at a truck show.
++++++++++++++++++++++++++++++

> I actually agonized quite long and tried both ways of colorizing the
> proximity of stations and finally decided that the red is more visible
> against the typical white background and you'd probably be more
> interested in those stations closer to you than those further away.
> Hence the choice of red for close and green for far.
>
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>
> On 8/16/2011 3:33 PM, kc8sfq@... wrote:
>>
>>
>> Just an observation. Since we are talking colors, It seems to me that
>> as a satalite reception improves, it's color goes from red (just
>> barely heard) to bright green for "loud and clear". This is logical.
>> The scrolling list however seems top go from green at the perimeter of
>> your range circle to red for right under foot. That seems counter
>> intuitive to me. I have adapted and really love the program. I am
>> reluctant, however, to live on the raged edge of developement. That
>> process is delightful to watch none-the-less.
>>
>>
>>
>> > Given:
>> >
>> > "Invalid" color Background - See details in the upcoming "Invalids"
>> > trace log
>> > Purple - Duplicate packet
>> > Pink - Too Quick packet (sub second)
>> > Red - Too Fast packet (>20,000mph or double rolling average)
>> > Aqua - "Restart" packet (long story, under development)
>> > Gray - Unknown Invalid (should never be seen)
>> >
>> > And:
>> >
>> > switch (Invalid)
>> > {
>> > case TRACK_OK: return RGB(192,255,192); /* Green is OK */
>> > case TRACK_DUP: return RGB(255,192,255); /* Purple is DUP
>> > */
>> > case TRACK_QUICK: return RGB(255,192,192); /* Pink is QUICK */
>> > case TRACK_FAST: return RGB(255,128,128); /* Red is FAST */
>> > case TRACK_RESTART: return RGB(128,255,255); /* Aqua is
>> > RESTART */
>> > default:
>> > return RGB(128,128,128); /* Gray is unknown */
>> > }
>> >
>> > What color should replace Black when a digipeated packet is heard back
>> > (Kenwood's "My Pos")? RGB values would be nice.
>> >
>> > Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>> >
>> > On 8/16/2011 11:21 AM, Fred Hillhouse wrote:
>> >>
>> >>
>> >> That is correct. It would be nice to have a different color fill for
>> >> those heard back.
>> >> Yes, patience grasshopper.
>> >>
>> >>
>> ------------------------------------------------------------------------
>> >> *From:* aprsisce@... [mailto:aprsisce@...]
>> *On
>> >> Behalf Of *Randy Love
>> >> *Sent:* Tuesday, August 16, 2011 11:12
>> >> *To:* aprsisce@...
>> >> *Subject:* Re: [aprsisce] Number of blobs shown in the track
>> >>
>> >> For the ME station, the black blobs are the transmitted beacons,
>> >> regardless of whether we hear them back from a digi or not?
>> >>
>> >>
>> >> On Tue, Aug 16, 2011 at 10:43 AM, Lynn W Deffenbaugh (Mr)
>> >> > wrote:
>> >>
>> >> Not exactly. The centered and following station's track has a
>> >> black blob at each packet point. If you're centered/following ME,
>> >> then those are the points at which beacon packets were
>> >> transmitted. It's the non-black blobs that are questionable and
>> >> those are shown for all station's tracks. See the bottom list at
>> >> http://aprsisce.wikidot.com/scrolling-stations for the color
>> >> description.
>> >>
>> >> APRSISCE/32 displays tracks as follows for centered and
>> >> non-centered stations:
>> >>
>> >> Centered: Whole track as a line and 32 most recent transmission
>> >> points plus all "invalid" transmission points
>> >>
>> >> Non-Centered: 32 most recent points as a line, but only "invalid"
>> >> transmission points
>> >>
>> >> I'll see about making each of those numbers configurable, but be
>> >> aware that markers such as these are not cheap to draw which is
>> >> why the program limits them as it does. System load and drawing
>> >> performance can be impacted by such things.
>> >>
>> >> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>> >>
>> >>
>> >>
>> >> On 8/16/2011 10:29 AM, Randy Love wrote:
>> >>> Reuben,
>> >>>
>> >>> the bobs indicate packets that are questionable for some reason.
>> >>> if you only have valid packets in your track, then the line is
>> >>> uniform.
>> >>>
>> >>> Randy
>> >>> WF5X
>> >>>
>> >>> On Tue, Aug 16, 2011 at 8:34 AM, Reuben Wells >> >>> > wrote:
>> >>>
>> >>> Hi Lynn,
>> >>>
>> >>> Thanks for the new dev release, I will take it for a test
>> >>> drive later this week. Per below, is there a way to increase
>> >>> the number of blobs in the track display?
>> >>>
>> >>> Reuben / M0RXW
>> >>>
>> >>> On 14 Aug 2011, at 17:43, Reuben Wells >> >>> > wrote:
>> >>>
>> >>>> Hi,
>> >>>>
>> >>>> Is it possible to increase the number of square blobs shown
>> >>>> in the track (via the menus or XML file)? We were running
>> >>>> some tests today in advance of an event and the square blobs
>> >>>> are very useful in reviewing visually where the packets were
>> >>>> received from and where the blind spots are. It looks like
>> >>>> APRSISCE only display the last 30 or so points.
>> >>>>
>> >>>> Reuben / M0RXW
>> >>>>
>> >>>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>
>

Join APRSISCE@groups.io to automatically receive all group messages.