Date   

Re: Path's with APRSIS32

James Ewen
 

On Fri, Nov 8, 2013 at 11:59 AM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:

> No, it's not "smart enough" and I suspect that neither are you or anyone else
> unless you've spent a good deal of time studying your local RF network.  

Anyone using APRS *SHOULD* study the local RF network, and understand the topology of their local network. From the knowledge gained there, they will know what an appropriate path would be to use in their area. Watching the local RF network teaches you which digipeaters can which other digipeaters. You learn the paths that packets can travel, and just how far a packet will travel based on the number of hops used.

People that do not invest the time in learning this information about their local network can easily become a burden to their network by using paths that cover too much area, or putting out too many packets, and clogging their local network.

You don't just fire up the HF rig, crank the amplifier to full power and start yapping away... (at least you shouldn't). You should be listening, and understanding the propagation characteristics so you don't clobber other people, and have a better chance of getting a signal into the desired area. Hop requests in APRS are equivalent to the power setting on HF. You use as little as required to get the communications desired completed. There's no need to push 1000 watts to talk to your buddy 3 miles away.

*IF* all APRS digipeaters were set up properly, responding to the same ALIASES in the proper and consistent manner, it is extremely simple to do some forensic investigation into the packets received. Not only is there evidence showing the digipeaters used, but also the original hop request.

However due to people not investing the time to understand the application of APRS and how digipeaters are supposed to work, and just slapping something together, as well as non-compliant digipeating rules in hardware and software based digipeaters. You can have a look at the common digipeating concepts used by APRS here: http://aprsisce.wikidot.com/doc:digipeating

When non-compliant digipeating rules are invoked, it can make it difficult to be able to reverse decode the path the packet traversed to get to the destination. It is possible to be able to build an efficient "shortest return route" path be knowing the location of the desired end station, and having a "network neighbors" list (or map). You basically create a routing list which contains the digipeaters required to get a packet from the origin to the desired destination.

Because APRS is a best effort network, and in some cases a severely overloaded, or poorly implemented network, it can be difficult to ensure that the path chosen will get the information to the desired end point. Add into that the vagaries of VHF propagation, where paths can exist at one point in time, and not a few minutes later, it becomes difficult to be able to truly build an accurate and reliable map.

It takes a lot of statistical averaging of observations of the network to really get a good grasp of which digipeaters can hear each other on a regular an reliable basis. There are add-ons that have been developed to try and measure the network health and reliability. Using these concepts and programs, it is possible to get a better understanding of what you are seeing, and how the local network is performing.

Lynn's routines that show the paths a packet *may* have taken help visualize your local network, but there's no way to know if the path between point A and point B carried a single packet during a brief ducting event, or if it is a highly reliable path between both points. The observer needs to watch the activity and make those kinds of determinations. It also can't know that a non-compliant midpoint digipeater never inserted it's callsign, and that what appears to be a valid path from point A to point C actually passed through point B enroute.

It's these kind of issues that make Lynn pull his hair out and declare that no one is smart enough to know how to build a reverse path to get a packet back to the origin. You need a fair bit of statistical averaging, long term observation, deductive reasoning, and sometimes some basic gut-feelings to figure out what is happening.

I have been doing APRS network observation and path analysis for nearly 2 decades, and I can spend hours trying to decipher the information found in a packet. Sometimes you have to dig through packets from neighboring stations looking for the evidence you need to be able to back up your theory on where the packet may have gone if you are dealing with non-compliant digipeaters in the mix. Quite often there is no way to prove anything conclusively, but through conjecture and circumstantial evidence, you can come to a most likely conclusion.

Looking for i-gates causing delayed packet delivery to the internet also requires a bit of detective work. I spent countless hours gathering evidence to back up my claims that it was the i-gates that were delaying the packet delivery, not digipeaters hanging onto packets on the RF channel. There were a handful of us that shared information back and forth for a number of weeks, defending our theories and concepts before we finally tracked the issue down to the Kantronics firmware bug that causes the delays. 

If you watch for long enough, you can build yourself a very complicated network map, but you can decipher the information provided enough to learn how your local network actually works.



--
James
VE6SRV


Re: Path's with APRSIS32

Lynn Deffenbaugh
 

In a perfect world where every digipeater inserted its callsign, decremented the alias's -SSID and marked it used if the result is zero, then you would be able to use a packet's path to know everything it did.  You could even determine what the original -SSID was (WIDE2-2 vs WIDE2-1 for instance) by counting the digipeaters appearing before it and after the previous alias.

But we don't live in a perfect world.

Consider your first example:  ECET52,W8OAK-14,CHLSEA*,WIDE2-1,qAR,W8HHF-15.  What alias did W8OAK-14 replace?  Or did this packet start out with a WIDE2-3?  There's no way to know.

Your second example, ECET52,WIDE1-1,WIDE2-2,qAR,W8OAK-15 is easier.  W8OAK-15 heard it direct.  Unless, of course, there's a seriously non-standard digipeater in the area that simply repeats every packet it hears unchanged (yes, there are some out there that do that).

As you pointed out, reversing the digipeaters in a path is problematic as well.  What's an alias and what's a digipeater?  Especially with things like CHLSEA in the mix coupled with some new stuff apparently going on overseas like WIPIW4-5, ITA3-3, POEE2*, TEST2-2, VFR1-1, ILAZ1-1.  These are actual path components detected by APRSISCE/32 as being "possible aliases".

You can see what APRSISCE/32 considers a possible alias by looking at Configure / Aliases / Possible and scrolling down through the menu. Those have all appeared at one time or another as a path component in a received packet and match Bob's definition of an alias as "ends in a digit" with an optional -SSID.  If you do look at this menu, be careful because if you select one from the Possible list, it will make it a defined "Known" alias which affects which portions of packet's paths are ignored and/or processed when doing the Screen / Paths / Appearance lines.

By the same token, it is important that you have all of the known aliases in use in your area defined in Configure / Aliases / Known or there will be holes in the above-mentioned path lines where the "digipeater" (the unknown alias) is not a known station and therefore not plottable as a line.

Bottom line: a message or ack is no different than a locally generated beacon and will be transmitted using the same configured path until I implement QSO-specific path entry.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 11/8/2013 3:21 PM, Rob Giuliano wrote:
Wouldn't the path show as a group of callsigns that have been inserted to replace WIDEn-N or any other Alias?
 
EXAMPLE:
  ECET5W,W8OAK-14,CHLSEA*,WIDE2-1,qAR,W8HHF-15:`o51lJb>/]"7>}=
Which probably came from: 
  ECET5W,WIDE1-1,WIDE2-2,qAR,W8OAK-15:`o51lJb>/]"7>}=
if you only get the second part that shows callsigns and aliases, how can you know what the original part was?
On the other hand, if you reversed it and sent via:
   CHLSEA, W8OAK-14
How can you be sure those station WILL "respond to" (digi) of its callsign-ssid that was inserted.
They may only digi off WIDEn-N.
   Even if each station does, it doesn't mean it was the most efficient path, just the "last successful" path.
   A closer station may have been overwhelmed by another local packet at that particular time.
 
It would make sense that the BEST method would be to send with a given "generic" path and take advantage of
 
Robert Giuliano
KB8RCO


---------------------------------------------

From: Lynn W Deffenbaugh (Mr)
To: aprsisce@...
Sent: Friday, November 8, 2013 1:59 PM
Subject: Re: [aprsisce] Path's with APRSIS32

(Corrected NOT smart enough)

On 11/8/2013 12:41 PM, ptompkins@... wrote:
I've dug around the manual and such and I did see a reference from a post from last year which stated that the path a message takes over RF is the same path that is defined as the Beacon.

Is that correct?

Yes, that is correct.  Currently, everything transmitted by APRSISCE/32 uses the Configure / Beacon / Path except for objects which have a per-object path definition which defaults to the Configure / Beacon / Path when the object is first created.

So if my "Configure" / "Beacon" / "Path" is WIDE1-1,WIDE2-1 that is where my default messages over RF go correct?

Yes.


Next question, in the attached screenshot I see a line which shows how the packet got to me (Really cool BTW!).

Yes, and you can see even more than just this one path line if you use Screen / Paths / Appearance and play around with the various settings in there.  For instance, here are all of the Direct and First hops of packets sent by N4GVA-2, an aerial photographer who did a flight diagonally across Florida this morning.  And balloonatics still insist that they need to have a path when they fly, but that's another soapbox.




If I try to talk to that station is the software smart enough to know the path to send the packet or will it go the same path as the message path (Which I believe to be the Beacon path which I have WIDE1-1,WIDE2-2).

No, it's not "smart enough" and I suspect that neither are you or anyone else unless you've spent a good deal of time studying your local RF network.  There was an extensive discussion in the aprssig recently about "reversing" the received path for APRS messages, but IMHO it's just not possible given the variety of digipeaters out there and random levels of WIDEn-N support (not to mention SSn-N which replaces rather than inserting callsigns).  Even if a message is received with SS7-3 in the path, that doesn't mean that an SS4-4 is necessary to respond.  The original message may have only been an SS7-4 but there's no way to tell.  And reversing the used digipeaters isn't a good idea either because the fact that A hears B hears C doesn't mean that C hears B hears A.

Eventually there will be a per-Chat path specification that will control the path used for messages and acks within that particular QSO, but for now Configure / Beacon / Path is the only game in the APRSISCE/32 town.


Finally, how many times will a message try to transmit before it gives up over RF because of no replied ACK. ?

Only as many as necessary or until the software give up!  But then it will try again for another batch of retries until it REALLY gives up.  But then, you can manually trigger another set and another set and another set until either an ack is received or you manually cancel that pending message.  Please read http://aprsisce.wikidot.com/message-retries for additional details.


I'm sorry for all my newbie questions.

Questions are good.  It means that someone's actually using the software!   Ask anytime.  But please be aware that sometimes the answer may only be a link to a Wiki page.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32




Phillip
KD7QOT






Re: Path's with APRSIS32

Rob Giuliano
 

Wouldn't the path show as a group of callsigns that have been inserted to replace WIDEn-N or any other Alias?
 
EXAMPLE:
  ECET5W,W8OAK-14,CHLSEA*,WIDE2-1,qAR,W8HHF-15:`o51lJb>/]"7>}=
Which probably came from: 
  ECET5W,WIDE1-1,WIDE2-2,qAR,W8OAK-15:`o51lJb>/]"7>}=
if you only get the second part that shows callsigns and aliases, how can you know what the original part was?
On the other hand, if you reversed it and sent via:
   CHLSEA, W8OAK-14
How can you be sure those station WILL "respond to" (digi) of its callsign-ssid that was inserted.
They may only digi off WIDEn-N.
   Even if each station does, it doesn't mean it was the most efficient path, just the "last successful" path.
   A closer station may have been overwhelmed by another local packet at that particular time.
 
It would make sense that the BEST method would be to send with a given "generic" path and take advantage of
 
Robert Giuliano
KB8RCO


---------------------------------------------

From: Lynn W Deffenbaugh (Mr)
To: aprsisce@...
Sent: Friday, November 8, 2013 1:59 PM
Subject: Re: [aprsisce] Path's with APRSIS32

(Corrected NOT smart enough)

On 11/8/2013 12:41 PM, ptompkins@... wrote:
I've dug around the manual and such and I did see a reference from a post from last year which stated that the path a message takes over RF is the same path that is defined as the Beacon.

Is that correct?

Yes, that is correct.  Currently, everything transmitted by APRSISCE/32 uses the Configure / Beacon / Path except for objects which have a per-object path definition which defaults to the Configure / Beacon / Path when the object is first created.

So if my "Configure" / "Beacon" / "Path" is WIDE1-1,WIDE2-1 that is where my default messages over RF go correct?

Yes.


Next question, in the attached screenshot I see a line which shows how the packet got to me (Really cool BTW!).

Yes, and you can see even more than just this one path line if you use Screen / Paths / Appearance and play around with the various settings in there.  For instance, here are all of the Direct and First hops of packets sent by N4GVA-2, an aerial photographer who did a flight diagonally across Florida this morning.  And balloonatics still insist that they need to have a path when they fly, but that's another soapbox.




If I try to talk to that station is the software smart enough to know the path to send the packet or will it go the same path as the message path (Which I believe to be the Beacon path which I have WIDE1-1,WIDE2-2).

No, it's not "smart enough" and I suspect that neither are you or anyone else unless you've spent a good deal of time studying your local RF network.  There was an extensive discussion in the aprssig recently about "reversing" the received path for APRS messages, but IMHO it's just not possible given the variety of digipeaters out there and random levels of WIDEn-N support (not to mention SSn-N which replaces rather than inserting callsigns).  Even if a message is received with SS7-3 in the path, that doesn't mean that an SS4-4 is necessary to respond.  The original message may have only been an SS7-4 but there's no way to tell.  And reversing the used digipeaters isn't a good idea either because the fact that A hears B hears C doesn't mean that C hears B hears A.

Eventually there will be a per-Chat path specification that will control the path used for messages and acks within that particular QSO, but for now Configure / Beacon / Path is the only game in the APRSISCE/32 town.


Finally, how many times will a message try to transmit before it gives up over RF because of no replied ACK. ?

Only as many as necessary or until the software give up!  But then it will try again for another batch of retries until it REALLY gives up.  But then, you can manually trigger another set and another set and another set until either an ack is received or you manually cancel that pending message.  Please read http://aprsisce.wikidot.com/message-retries for additional details.


I'm sorry for all my newbie questions.

Questions are good.  It means that someone's actually using the software!   Ask anytime.  But please be aware that sometimes the answer may only be a link to a Wiki page.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32




Phillip
KD7QOT





Re: Path's with APRSIS32 [1 Attachment]

Lynn Deffenbaugh
 

(Corrected NOT smart enough)

On 11/8/2013 12:41 PM, ptompkins@... wrote:
I've dug around the manual and such and I did see a reference from a post from last year which stated that the path a message takes over RF is the same path that is defined as the Beacon.

Is that correct?

Yes, that is correct.  Currently, everything transmitted by APRSISCE/32 uses the Configure / Beacon / Path except for objects which have a per-object path definition which defaults to the Configure / Beacon / Path when the object is first created.

So if my "Configure" / "Beacon" / "Path" is WIDE1-1,WIDE2-1 that is where my default messages over RF go correct?

Yes.


Next question, in the attached screenshot I see a line which shows how the packet got to me (Really cool BTW!).

Yes, and you can see even more than just this one path line if you use Screen / Paths / Appearance and play around with the various settings in there.  For instance, here are all of the Direct and First hops of packets sent by N4GVA-2, an aerial photographer who did a flight diagonally across Florida this morning.  And balloonatics still insist that they need to have a path when they fly, but that's another soapbox.




If I try to talk to that station is the software smart enough to know the path to send the packet or will it go the same path as the message path (Which I believe to be the Beacon path which I have WIDE1-1,WIDE2-2).

No, it's not "smart enough" and I suspect that neither are you or anyone else unless you've spent a good deal of time studying your local RF network.  There was an extensive discussion in the aprssig recently about "reversing" the received path for APRS messages, but IMHO it's just not possible given the variety of digipeaters out there and random levels of WIDEn-N support (not to mention SSn-N which replaces rather than inserting callsigns).  Even if a message is received with SS7-3 in the path, that doesn't mean that an SS4-4 is necessary to respond.  The original message may have only been an SS7-4 but there's no way to tell.  And reversing the used digipeaters isn't a good idea either because the fact that A hears B hears C doesn't mean that C hears B hears A.

Eventually there will be a per-Chat path specification that will control the path used for messages and acks within that particular QSO, but for now Configure / Beacon / Path is the only game in the APRSISCE/32 town.


Finally, how many times will a message try to transmit before it gives up over RF because of no replied ACK. ?

Only as many as necessary or until the software give up!  But then it will try again for another batch of retries until it REALLY gives up.  But then, you can manually trigger another set and another set and another set until either an ack is received or you manually cancel that pending message.  Please read http://aprsisce.wikidot.com/message-retries for additional details.


I'm sorry for all my newbie questions.

Questions are good.  It means that someone's actually using the software!   Ask anytime.  But please be aware that sometimes the answer may only be a link to a Wiki page.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32



Phillip
KD7QOT



Re: Path's with APRSIS32 [1 Attachment]

Lynn Deffenbaugh
 

On 11/8/2013 12:41 PM, ptompkins@... wrote:
I've dug around the manual and such and I did see a reference from a post from last year which stated that the path a message takes over RF is the same path that is defined as the Beacon.

Is that correct?

Yes, that is correct.  Currently, everything transmitted by APRSISCE/32 uses the Configure / Beacon / Path except for objects which have a per-object path definition which defaults to the Configure / Beacon / Path when the object is first created.

So if my "Configure" / "Beacon" / "Path" is WIDE1-1,WIDE2-1 that is where my default messages over RF go correct?

Yes.


Next question, in the attached screenshot I see a line which shows how the packet got to me (Really cool BTW!).

Yes, and you can see even more than just this one path line if you use Screen / Paths / Appearance and play around with the various settings in there.  For instance, here are all of the Direct and First hops of packets sent by N4GVA-2, an aerial photographer who did a flight diagonally across Florida this morning.  And balloonatics still insist that they need to have a path when they fly, but that's another soapbox.




If I try to talk to that station is the software smart enough to know the path to send the packet or will it go the same path as the message path (Which I believe to be the Beacon path which I have WIDE1-1,WIDE2-2).

No, it's "smart enough" and I suspect that neither are you or anyone else unless you've spent a good deal of time studying your local RF network.  There was an extensive discussion in the aprssig recently about "reversing" the received path for APRS messages, but IMHO it's just not possible given the variety of digipeaters out there and random levels of WIDEn-N support (not to mention SSn-N which replaces rather than inserting callsigns).  Even if a message is received with SS7-3 in the path, that doesn't mean that an SS4-4 is necessary to respond.  The original message may have only been an SS7-4 but there's no way to tell.  And reversing the used digipeaters isn't a good idea either because the fact that A hears B hears C doesn't mean that C hears B hears A.

Eventually there will be a per-Chat path specification that will control the path used for messages and acks within that particular QSO, but for now Configure / Beacon / Path is the only game in the APRSISCE/32 town.


Finally, how many times will a message try to transmit before it gives up over RF because of no replied ACK. ?

Only as many as necessary or until the software give up!  But then it will try again for another batch of retries until it REALLY gives up.  But then, you can manually trigger another set and another set and another set until either an ack is received or you manually cancel that pending message.  Please read http://aprsisce.wikidot.com/message-retries for additional details.


I'm sorry for all my newbie questions.

Questions are good.  It means that someone's actually using the software!   Ask anytime.  But please be aware that sometimes the answer may only be a link to a Wiki page.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32



Phillip
KD7QOT



Path's with APRSIS32

Phillip Tompkins
 

I've dug around the manual and such and I did see a reference from a post from last year which stated that the path a message takes over RF is the same path that is defined as the Beacon.


Is that correct?
So if my "Configure" / "Beacon" / "Path" is WIDE1-1,WIDE2-1 that is where my default messages over RF go correct?

Next question, in the attached screenshot I see a line which shows how the packet got to me (Really cool BTW!).  If I try to talk to that station is the software smart enough to know the path to send the packet or will it go the same path as the message path (Which I believe to be the Beacon path which I have WIDE1-1,WIDE2-2).

Finally, how many times will a message try to transmit before it gives up over RF because of no replied ACK. ?

I'm sorry for all my newbie questions.

Phillip
KD7QOT


Re: Weird

Don Poaps
 

I'm sorry fat fingers. Your not picking stations north of w0th Tracey, CA. I have ve7av-4, w7kj I think, ve4gls a WX station. I only picked 1 WA station all day today I'm not even getting the east coast. I only picked n1py I think the other day. That's the furthest packet station I picked up.

My station runs almost 23 hours a day. 

Later

Don va7dgp

On Saturday, November 2, 2013, Don Poaps wrote:
Your not picking stations north of w0

On Saturday, November 2, 2013, Lynn W Deffenbaugh (Mr) wrote:
I'm using Direwolf and UZ7HO on 10.147.60 USB and am picking up stations:



Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 11/2/2013 10:30 PM, Don Poaps wrote:
I was tracking N1ZZZ /MM direct until he went quite as he dropped into the Suez Canal. After that I have not picked up a signal Robust Packet on 10147.3. Not even the east coast. He will begin to Beacon somewhere around Nov 4 once he gets into the Mediterrean Sea.
I'm also running UZ7HO and AWGtracker on 2000 HZ. I have picked the ISS and various station (ie ND7AN-4) and west coast Packet stations. I have not picked up Stephen as he motors across USA. It seems that 30 m is dead.
 
Later
 
Don
 
On Sat, Nov 2, 2013 at 7:16 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:
 

The person you need to track down is N1ZZZ who is marine mobile running Robust Packet on 30m using APRSIS32.  I gave it a quick search, but couldn't find the particular link where he described his setup.  But google it all together and see what you can learn.

And APRSIS32 runs will under WINE!  It's all about setting port security and getting one "registry" entry built correctly.

See http://aprsisce.wikidot.com/doc:linux


Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 11/2/2013 10:00 PM, Don Poaps wrote:
FYI
 
I have a ham friend in CA that is trying to setup a APRS Robust Packet Igate on 10147.3  I sent him the Link for APRSIS32. He's into Linux.
 
Thank You again
 


 
On Sat, Nov 2, 2013 at 6:53 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:
 

No, I didn't mean that. You're beaconing posits and not beaconing
GridSquares any more, so you are good. I was answering the curiosity
about how you were so far out of place BEFORE you made the changes today.



Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 11/2/2013 9:45 PM, Don Poaps wrote:
> Thank You for the imput today. I must have check something and mess
> some
--
Don Poaps
New Westminster, BC
VA7DGP
Satern Member
Vector Member
Surrey Amateur Radio
Metrotown Salvation Army Community Church Member
 
 



--
Don Poaps
New Westminster, BC
VA7DGP
Satern Member
Vector Member
Surrey Amateur Radio
Metrotown Salvation Army Community Church Member
 
 


Re: Weird

Don Poaps
 

Your not picking stations north of w0


On Saturday, November 2, 2013, Lynn W Deffenbaugh (Mr) wrote:
I'm using Direwolf and UZ7HO on 10.147.60 USB and am picking up stations:



Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 11/2/2013 10:30 PM, Don Poaps wrote:
I was tracking N1ZZZ /MM direct until he went quite as he dropped into the Suez Canal. After that I have not picked up a signal Robust Packet on 10147.3. Not even the east coast. He will begin to Beacon somewhere around Nov 4 once he gets into the Mediterrean Sea.
I'm also running UZ7HO and AWGtracker on 2000 HZ. I have picked the ISS and various station (ie ND7AN-4) and west coast Packet stations. I have not picked up Stephen as he motors across USA. It seems that 30 m is dead.
 
Later
 
Don
 
On Sat, Nov 2, 2013 at 7:16 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:
 

The person you need to track down is N1ZZZ who is marine mobile running Robust Packet on 30m using APRSIS32.  I gave it a quick search, but couldn't find the particular link where he described his setup.  But google it all together and see what you can learn.

And APRSIS32 runs will under WINE!  It's all about setting port security and getting one "registry" entry built correctly.

See http://aprsisce.wikidot.com/doc:linux


Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 11/2/2013 10:00 PM, Don Poaps wrote:
FYI
 
I have a ham friend in CA that is trying to setup a APRS Robust Packet Igate on 10147.3  I sent him the Link for APRSIS32. He's into Linux.
 
Thank You again
 


 
On Sat, Nov 2, 2013 at 6:53 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:
 

No, I didn't mean that. You're beaconing posits and not beaconing
GridSquares any more, so you are good. I was answering the curiosity
about how you were so far out of place BEFORE you made the changes today.



Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 11/2/2013 9:45 PM, Don Poaps wrote:
> Thank You for the imput today. I must have check something and mess
> something up.
>
> Later
>
> Don
>


--
Don Poaps
New Westminster, BC
VA7DGP
Satern Member
Vector Member
Surrey Amateur Radio
Metrotown Salvation Army Community Church Member
 
 


Re: Weird

Lynn Deffenbaugh
 

I'm using Direwolf and UZ7HO on 10.147.60 USB and am picking up stations:



Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 11/2/2013 10:30 PM, Don Poaps wrote:
I was tracking N1ZZZ/MM direct until he went quite as he dropped into the Suez Canal. After that I have not picked up a signal Robust Packet on 10147.3. Not even the east coast. He will begin to Beacon somewhere around Nov 4 once he gets into the Mediterrean Sea.
I'm also running UZ7HO and AWGtracker on 2000 HZ. I have picked the ISS and various station (ie ND7AN-4) and west coast Packet stations. I have not picked up Stephen as he motors across USA. It seems that 30 m is dead.
Later
Don
On Sat, Nov 2, 2013 at 7:16 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:

The person you need to track down is N1ZZZ who is marine mobile running Robust Packet on 30m using APRSIS32. I gave it a quick search, but couldn't find the particular link where he described his setup. But google it all together and see what you can learn.

And APRSIS32 runs will under WINE! It's all about setting port security and getting one "registry" entry built correctly.

See http://aprsisce.wikidot.com/doc:linux


Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 11/2/2013 10:00 PM, Don Poaps wrote:
FYI
I have a ham friend in CA that is trying to setup a APRS Robust Packet Igate on 10147.3 I sent him the Link for APRSIS32. He's into Linux.
Thank You again


On Sat, Nov 2, 2013 at 6:53 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:

No, I didn't mean that. You're beaconing posits and not beaconing
GridSquares any more, so you are good. I was answering the curiosity
about how you were so far out of place BEFORE you made the changes today.



Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 11/2/2013 9:45 PM, Don Poaps wrote:
> Thank You for the imput today. I must have check something and mess
> something up.
>
> Later
>
> Don
>
> On Sat, Nov 2, 2013 at 4:27 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:
>>
>>
>> 2013-11-02 17:53:44 EDT: VA7DGP-1>APWW10,TCPIP*,qAC,T2ONTARIO:>CN89me/lDX: VA7LLB-9 42.0mi 104<0xb0> 21:53 4902.76N 12203.35W
>>
>>
>> Actually, that's one area where APRSISCE/32 is out of spec. The GridSquare in the status report is supposed to be:
>>
>> The Maidenhead grid locator may be 4 or 6 characters long, and must immediately follow the > Data Type Identifier.
>>
>>
>>
>
> --
> Don Poaps
> New Westminster, BC
> VA7DGP
> Satern Member
> Vector Member
> Surrey Amateur Radio
> Metrotown Salvation Army Community Church Member
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>
>




--
Don Poaps
New Westminster, BC
VA7DGP
Satern Member
Vector Member
Surrey Amateur Radio
Metrotown Salvation Army Community Church Member




--
Don Poaps
New Westminster, BC
VA7DGP
Satern Member
Vector Member
Surrey Amateur Radio
Metrotown Salvation Army Community Church Member


Re: Weird

Don Poaps
 

I was tracking N1ZZZ /MM direct until he went quite as he dropped into the Suez Canal. After that I have not picked up a signal Robust Packet on 10147.3. Not even the east coast. He will begin to Beacon somewhere around Nov 4 once he gets into the Mediterrean Sea.
I'm also running UZ7HO and AWGtracker on 2000 HZ. I have picked the ISS and various station (ie ND7AN-4) and west coast Packet stations. I have not picked up Stephen as he motors across USA. It seems that 30 m is dead.
 
Later
 
Don
 

On Sat, Nov 2, 2013 at 7:16 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:
 

The person you need to track down is N1ZZZ who is marine mobile running Robust Packet on 30m using APRSIS32.  I gave it a quick search, but couldn't find the particular link where he described his setup.  But google it all together and see what you can learn.

And APRSIS32 runs will under WINE!  It's all about setting port security and getting one "registry" entry built correctly.

See http://aprsisce.wikidot.com/doc:linux


Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 11/2/2013 10:00 PM, Don Poaps wrote:
FYI
 
I have a ham friend in CA that is trying to setup a APRS Robust Packet Igate on 10147.3  I sent him the Link for APRSIS32. He's into Linux.
 
Thank You again
 


 
On Sat, Nov 2, 2013 at 6:53 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:
 

No, I didn't mean that. You're beaconing posits and not beaconing
GridSquares any more, so you are good. I was answering the curiosity
about how you were so far out of place BEFORE you made the changes today.



Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 11/2/2013 9:45 PM, Don Poaps wrote:
> Thank You for the imput today. I must have check something and mess
> something up.
>
> Later
>
> Don
>
> On Sat, Nov 2, 2013 at 4:27 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:
>>
>>
>> 2013-11-02 17:53:44 EDT: VA7DGP-1>APWW10,TCPIP*,qAC,T2ONTARIO:>CN89me/lDX: VA7LLB-9 42.0mi 104<0xb0> 21:53 4902.76N 12203.35W
>>
>>
>> Actually, that's one area where APRSISCE/32 is out of spec. The GridSquare in the status report is supposed to be:
>>
>> The Maidenhead grid locator may be 4 or 6 characters long, and must immediately follow the > Data Type Identifier.
>>
>>
>>
>
> --
> Don Poaps
> New Westminster, BC
> VA7DGP
> Satern Member
> Vector Member
> Surrey Amateur Radio
> Metrotown Salvation Army Community Church Member
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>
>




--
Don Poaps
New Westminster, BC
VA7DGP
Satern Member
Vector Member
Surrey Amateur Radio
Metrotown Salvation Army Community Church Member
 
 




--
Don Poaps
New Westminster, BC
VA7DGP
Satern Member
Vector Member
Surrey Amateur Radio
Metrotown Salvation Army Community Church Member
 
 


Re: Weird

Lynn Deffenbaugh
 

The person you need to track down is N1ZZZ who is marine mobile running Robust Packet on 30m using APRSIS32. I gave it a quick search, but couldn't find the particular link where he described his setup. But google it all together and see what you can learn.

And APRSIS32 runs will under WINE! It's all about setting port security and getting one "registry" entry built correctly.

See http://aprsisce.wikidot.com/doc:linux

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 11/2/2013 10:00 PM, Don Poaps wrote:
FYI
I have a ham friend in CA that is trying to setup a APRS Robust Packet Igate on 10147.3 I sent him the Link for APRSIS32. He's into Linux.
Thank You again


On Sat, Nov 2, 2013 at 6:53 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:

No, I didn't mean that. You're beaconing posits and not beaconing
GridSquares any more, so you are good. I was answering the curiosity
about how you were so far out of place BEFORE you made the changes today.



Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 11/2/2013 9:45 PM, Don Poaps wrote:
> Thank You for the imput today. I must have check something and mess
> something up.
>
> Later
>
> Don
>
> On Sat, Nov 2, 2013 at 4:27 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:
>>
>>
>> 2013-11-02 17:53:44 EDT: VA7DGP-1>APWW10,TCPIP*,qAC,T2ONTARIO:>CN89me/lDX: VA7LLB-9 42.0mi 104<0xb0> 21:53 4902.76N 12203.35W
>>
>>
>> Actually, that's one area where APRSISCE/32 is out of spec. The GridSquare in the status report is supposed to be:
>>
>> The Maidenhead grid locator may be 4 or 6 characters long, and must immediately follow the > Data Type Identifier.
>>
>>
>>
>
> --
> Don Poaps
> New Westminster, BC
> VA7DGP
> Satern Member
> Vector Member
> Surrey Amateur Radio
> Metrotown Salvation Army Community Church Member
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>
>




--
Don Poaps
New Westminster, BC
VA7DGP
Satern Member
Vector Member
Surrey Amateur Radio
Metrotown Salvation Army Community Church Member


Re: Weird

Don Poaps
 

Yes it's in the right spot. Don's Senior Hangout. AKA Connault Heights Villa.
 
73
 
Don
 
va7dgp

On Sat, Nov 2, 2013 at 7:00 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:
On 11/2/2013 7:27 PM, Lynn W Deffenbaugh (Mr) wrote:
I'll have to bone up on my perl (I think) and take a look at libFAP to see just what it does with this.

http://cpansearch.perl.org/src/HESSU/Ham-APRS-FAP-1.19/ seems to be the latest online from 30-Dec-2012 and it doesn't support GridSquares in Status Reports anyway.  That doesn't mean that Hessu isn't parsing it external to the library though.

But I don't think so, since even his decoded view doesn't show it whereas the decoded view after the timestamp was provided does show the parse of the timestamp.

So we still don't know how aprs.fi had the station so far off, but it has it correct now, right?



Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32




--
Don Poaps
New Westminster, BC
VA7DGP
Satern Member
Vector Member
Surrey Amateur Radio
Metrotown Salvation Army Community Church Member
 
 


Re: Weird

Don Poaps
 

FYI
 
I have a ham friend in CA that is trying to setup a APRS Robust Packet Igate on 10147.3  I sent him the Link for APRSIS32. He's into Linux.
 
Thank You again
 


 

On Sat, Nov 2, 2013 at 6:53 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:
 

No, I didn't mean that. You're beaconing posits and not beaconing
GridSquares any more, so you are good. I was answering the curiosity
about how you were so far out of place BEFORE you made the changes today.



Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 11/2/2013 9:45 PM, Don Poaps wrote:
> Thank You for the imput today. I must have check something and mess
> something up.
>
> Later
>
> Don
>
> On Sat, Nov 2, 2013 at 4:27 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:
>>
>>
>> 2013-11-02 17:53:44 EDT: VA7DGP-1>APWW10,TCPIP*,qAC,T2ONTARIO:>CN89me/lDX: VA7LLB-9 42.0mi 104<0xb0> 21:53 4902.76N 12203.35W
>>
>>
>> Actually, that's one area where APRSISCE/32 is out of spec. The GridSquare in the status report is supposed to be:
>>
>> The Maidenhead grid locator may be 4 or 6 characters long, and must immediately follow the > Data Type Identifier.
>>
>>
>>
>
> --
> Don Poaps
> New Westminster, BC
> VA7DGP
> Satern Member
> Vector Member
> Surrey Amateur Radio
> Metrotown Salvation Army Community Church Member
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>
>




--
Don Poaps
New Westminster, BC
VA7DGP
Satern Member
Vector Member
Surrey Amateur Radio
Metrotown Salvation Army Community Church Member
 
 


Re: Weird

Lynn Deffenbaugh
 

On 11/2/2013 7:27 PM, Lynn W Deffenbaugh (Mr) wrote:
I'll have to bone up on my perl (I think) and take a look at libFAP to see just what it does with this.

http://cpansearch.perl.org/src/HESSU/Ham-APRS-FAP-1.19/ seems to be the latest online from 30-Dec-2012 and it doesn't support GridSquares in Status Reports anyway.  That doesn't mean that Hessu isn't parsing it external to the library though.

But I don't think so, since even his decoded view doesn't show it whereas the decoded view after the timestamp was provided does show the parse of the timestamp.

So we still don't know how aprs.fi had the station so far off, but it has it correct now, right?



Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32


Re: Weird

Lynn Deffenbaugh
 

No, I didn't mean that. You're beaconing posits and not beaconing GridSquares any more, so you are good. I was answering the curiosity about how you were so far out of place BEFORE you made the changes today.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 11/2/2013 9:45 PM, Don Poaps wrote:
Thank You for the imput today. I must have check something and mess
something up.

Later

Don

On Sat, Nov 2, 2013 at 4:27 PM, Lynn W Deffenbaugh (Mr) <kj4erj@arrl.net> wrote:


2013-11-02 17:53:44 EDT: VA7DGP-1>APWW10,TCPIP*,qAC,T2ONTARIO:>CN89me/lDX: VA7LLB-9 42.0mi 104<0xb0> 21:53 4902.76N 12203.35W


Actually, that's one area where APRSISCE/32 is out of spec. The GridSquare in the status report is supposed to be:

The Maidenhead grid locator may be 4 or 6 characters long, and must immediately follow the > Data Type Identifier.


<snipped>
--
Don Poaps
New Westminster, BC
VA7DGP
Satern Member
Vector Member
Surrey Amateur Radio
Metrotown Salvation Army Community Church Member


------------------------------------

Yahoo Groups Links




Re: Weird

Don Poaps
 

Thank You for the imput today. I must have check something and mess
something up.

Later

Don

On Sat, Nov 2, 2013 at 4:27 PM, Lynn W Deffenbaugh (Mr) <kj4erj@arrl.net> wrote:



2013-11-02 17:53:44 EDT: VA7DGP-1>APWW10,TCPIP*,qAC,T2ONTARIO:>CN89me/lDX: VA7LLB-9 42.0mi 104<0xb0> 21:53 4902.76N 12203.35W


Actually, that's one area where APRSISCE/32 is out of spec. The GridSquare in the status report is supposed to be:

The Maidenhead grid locator may be 4 or 6 characters long, and must immediately follow the > Data Type Identifier.


<snipped>
--
Don Poaps
New Westminster, BC
VA7DGP
Satern Member
Vector Member
Surrey Amateur Radio
Metrotown Salvation Army Community Church Member


Re: Weird

Lynn Deffenbaugh
 

2013-11-02 17:53:44 EDT: VA7DGP-1>APWW10,TCPIP*,qAC,T2ONTARIO:>CN89me/lDX: VA7LLB-9 42.0mi 104<0xb0> 21:53 4902.76N 12203.35W 

Actually, that's one area where APRSISCE/32 is out of spec.  The GridSquare in the status report is supposed to be:

The Maidenhead grid locator may be 4 or 6 characters long, and must immediately follow the > Data Type Identifier.

Well, I got that part right, but it goes on to say:

All letters must be transmitted in upper case.

So the aprs.fi parser might be ignoring the final two lower-case letters (yes, I need to fix that regardless of how much more human-friendly I think it is).  But then again, the spec goes on to say:

Letters may be received in upper case or lower case.

But the difference between "must" and "may" means that the APRSISCE/32 packet is out of spec whereas any parser that ignores the lower case would simply not be opting for accepting lower case.

I'll have to bone up on my perl (I think) and take a look at libFAP to see just what it does with this.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

PS.  But then again, it's a moot point because VA7DGP-1 has removed the (redundant and misleading) GridSquare from the status report anyway!


On 11/2/2013 6:57 PM, Keith VE7GDH wrote:
Don VA7DGP wrote…

APRS.fi showed my call out by Chilliwack, Abbotsford area. I have modified info per Lynn. I think its beaconing ok now.

I don't know why aprs.fi was doing that. I could understand that if you were beaconing a grid square of CN89 but not CN89me.

73 es cul - Keith VE7GDH
www.ui-view.org
--
"I may be lost, but I know exactly where I am!"




Re: Weird

Keith VE7GDH
 

Don VA7DGP wrote…

APRS.fi showed my call out by Chilliwack, Abbotsford area. I have modified info per Lynn. I think its beaconing ok now.

I don't know why aprs.fi was doing that. I could understand that if you were beaconing a grid square of CN89 but not CN89me.

73 es cul - Keith VE7GDH
www.ui-view.org
--
"I may be lost, but I know exactly where I am!"



Re: Weird

Don Poaps
 

APRS.fi showed my call out by Chilliwack, Abbotsford area. I have modified info per Lynn. I think its beaconing ok now.

Don va7dgp


On Saturday, November 2, 2013, Keith VE7GDH wrote:
 

Don VA7DGP wrote...

> I have the cross hair located right at my QTH in New Westminister.
> [SIC] va7dgp-1. When I load up APRS.fi. My locations is off towards
> Abbotsford, BC Something not being picked up or pumped into the
> Internet.

http://aprs.fi/?c=raw&call=VA7DGP*&limit=1000&view=normal

VA7DGP-1 is mostly beaconing telemetry. However, I see a grid square
sent a few minutes ago in a "best DX report" CN89me. I wasn't seeing
you on RF. I added DGP-1 to my filter and got you to send a position
report. Now I can see you via TCPIP, plotted somewhere within that
grid square, which does take in New Westminster.

Looking on aprs.fi, at first I didn't at first see any recent position
reports from VA7DGP-1. When did you see yourself out by Abbotsford?
Since I forced a beacon from you, I have seen a couple of position
reports containing a lat/long, about half an hour apart. The lat/long
puts you are your usual home QTH. The grid square of course just
puts you somewhere in the grid square. However, it wasn't way up
the valley at Abbotsford. Whatever was happening to place you at
Abbotsford didn't apparently make it to the APRS-IS.

73 es cul - Keith VE7GDH
www.ui-view.org
--
"I may be lost, but I know exactly where I am!"



--
Don Poaps
New Westminster, BC
VA7DGP
Satern Member
Vector Member
Surrey Amateur Radio
Metrotown Salvation Army Community Church Member
 
 


Re: Weird

Keith VE7GDH
 

Don VA7DGP wrote...

I have the cross hair located right at my QTH in New Westminister.
[SIC] va7dgp-1. When I load up APRS.fi. My locations is off towards
Abbotsford, BC Something not being picked up or pumped into the
Internet.
http://aprs.fi/?c=raw&call=VA7DGP*&limit=1000&view=normal

VA7DGP-1 is mostly beaconing telemetry. However, I see a grid square
sent a few minutes ago in a "best DX report" CN89me. I wasn't seeing
you on RF. I added DGP-1 to my filter and got you to send a position report. Now I can see you via TCPIP, plotted somewhere within that
grid square, which does take in New Westminster.

Looking on aprs.fi, at first I didn't at first see any recent position reports from VA7DGP-1. When did you see yourself out by Abbotsford?
Since I forced a beacon from you, I have seen a couple of position
reports containing a lat/long, about half an hour apart. The lat/long
puts you are your usual home QTH. The grid square of course just
puts you somewhere in the grid square. However, it wasn't way up
the valley at Abbotsford. Whatever was happening to place you at
Abbotsford didn't apparently make it to the APRS-IS.

73 es cul - Keith VE7GDH
www.ui-view.org
--
"I may be lost, but I know exactly where I am!"

11361 - 11380 of 35670