Date   

Re: iGate locator

Lynn Deffenbaugh
 

Yes, it matters.  When you first start the software, it asks you to center on your location and hit Transmit.  If you zoom in on a different location and hit Transmit again, it will ask if you want to "Move ME to Center".  Hit Yes and you've set a new location.

See also: http://aprsisce.wikidot.com/doc:set-location

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

On 9/29/2013 8:30 PM, k6kusman@... wrote:

Hello all.. I was poking around the software looking for a spot to put in the static  location of the node instead of using a gps unit on it. Is this needed  or does it not matter. Thanks.



iGate locator

Larry Ellsworth - K6KUS
 

Hello all.. I was poking around the software looking for a spot to put in the static  location of the node instead of using a gps unit on it. Is this needed  or does it not matter. Thanks.


Re: APRSIS32 and the XML

Rob Giuliano
 

Lynn does a great job of keeping the XML "mostly" backward compatible.

When you update the EXE through his About, it asks to start the new EXE.  When you start the new EXE, it reads the XML from the old EXE and has defaults for the "new features".  This allow the same features to work as they did, and gives a good starting point (defaults) for new features to create the new XML.

If running multiple copies, this process happens with each copy, but you have to end each copy, then then restart it.  It reads the OLD XML in the "start in" directory, and puts in the new defaults for this new XML.

NOTE: it doesn't have any changes from the previous instance where you may have changed the "new defaults" for your use. Each is its own instance.
 
Robert Giuliano
KB8RCO


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



From: Bruce Coates
To: aprsisce@...
Sent: Sunday, September 29, 2013 7:49 PM
Subject: Re: [aprsisce] APRSIS32 and the XML

 
Hi Everyone

Thanks for all the great suggestions.  One thing I'm wondering about is what the program will do in those cases where it's updated changing the XML file format but one of more XML files have not?  Does it simply recognize the change and upgrade each old XML file if needed when it next uses that file?

73, Bruce - VE5BNC




Re: APRSIS32 and the XML

Bruce Coates
 

Hi Everyone

Thanks for all the great suggestions.  One thing I'm wondering about is what the program will do in those cases where it's updated changing the XML file format but one of more XML files have not?  Does it simply recognize the change and upgrade each old XML file if needed when it next uses that file?

73, Bruce - VE5BNC


Re: APRSIS32 and the XML

Rob Giuliano
 

You can also do this with shortcuts that have a different "Start In:" directories within the Windows shortcut.

 find it easiest to have the MAPS in a base directory which each of the XLM files pointing to the same MAP sub-directory

With the path inside the XML being relative:
   ../maps/OSMTiles/

I have "start in" paths of
\APRS\maps\OSMTiles
\APRS\maps\Ariel
\APRS\kb8rco-s
\APRS\kb8rco        This version has the EXE file (only one
\APRS\kb8rco-2

kb8rco has the following:
  Target:    \APRS\KB8RCO\APRSIS32.EXE
  Start In:  \APRS\kb8rco

kb8rco-s has the following:
  Target:    \APRS\KB8RCO\APRSIS32.EXE
  Start In:  \APRS\kb8rco-s


kb8rco-2 has the following:
  Target:    \APRS\KB8RCO\APRSIS32.EXE
  Start In:  \APRS\kb8rco-2

The start in directories have the XML and LOG files for that configuration.
I can start 1, any 2, or all 3 of the shortcuts.

UPGRADES are simple because there is ONLY 1 executable file.  However, you must restart each of them after an upgrade.

Robert Giuliano
KB8RCO


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



From: Lynn W Deffenbaugh (Mr)
To: aprsisce@...
Sent: Sunday, September 29, 2013 1:48 PM
Subject: Re: [aprsisce] APRSIS32 and the XML

 
Just make a .BAT file that changes to the directory of choice and starts
APRSIS32.EXE in that directory. You can then execute the .BAT however
you want to.

Or set the default directory in your program and then activate
APRSIS32.EXE with that as the default.

Or as James suggested, create a shortcut that specifies the directory in
which to execute and activate that shortcut from your program.

There's any number of ways to accomplish what you want with the built-in
Windows tools and techniques. And it doesn't require any changes to
APRSISCE/32 to do it.

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




Re: APRSIS32 and the XML

Lynn Deffenbaugh
 

Just make a .BAT file that changes to the directory of choice and starts APRSIS32.EXE in that directory. You can then execute the .BAT however you want to.

Or set the default directory in your program and then activate APRSIS32.EXE with that as the default.

Or as James suggested, create a shortcut that specifies the directory in which to execute and activate that shortcut from your program.

There's any number of ways to accomplish what you want with the built-in Windows tools and techniques. And it doesn't require any changes to APRSISCE/32 to do it.

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


Re: APRSIS32 and the XML

James Ewen
 

On Sun, Sep 29, 2013 at 10:32 AM, <pa3bnx@veron.nl> wrote:

I wished APRSIS32 had an command line option
to say witch APRSIS32.XML it should load.

Becuase I want to start APRSIS32 from lets say

D:&#92;APRSIS&#92;APRSIS32.exe

If I do this from the root D:&#92; in cmd

It starts with a fresh APRSIS32 Configuration screen.
So it would be nice if I could give
in cmd
D:&#92;APRSIS32&#92;APRSIS32.exe D:&#92;APRSIS32.&#92;APRSIS32.XML
You can do this, as well as run multiple copies of APRSISCE/32 at one
time, each one with a different XML file if you choose.

You could create a shortcut that starts up each version pointing to a
different XML file, or you can create a BATCH file that asks for your
input as to which XML file to point towards.

Here's an email from Lynn about this very subject:

No, you only need a single copy of the .EXE, but you'll need to make a shortcut
of that .EXE to run within the different directory that contains the .XML and will
end up with the .LOGs. I have a single APRSIS32.EXE in D:&#92;DEBUG with probably
30+ subdirectories each with just the APRSIS32.XML for various test configurations.
I run the .EXE from the parent directory but have the default directory be the sub.

BUT, you can still put a .EXE into each directory. I do that when I want to freeze my
production IGate at a current version and only do an upgrade when I'm confident that
things are stable enough. With a shared and short-cut-ed .EXE, you upgrade one image
and then just close and restart the others. With dedicated .EXEs, each of the instances
will need to download the update.


--
James
VE6SRV


APRSIS32 and the XML

pa3bnx
 

Hello Every Body,

 

I wished APRSIS32 had an command line option

to say witch APRSIS32.XML it should load.

 

Why do i want that:

 

Becuase I want to start APRSIS32 from lets say

D:\APRSIS\APRSIS32.exe

 

If I do this from the root D:\  in cmd

It starts with a fresh APRSIS32 Configuration screen.

 

So it would be nice if I could give

 

in cmd

 

D:\APRSIS32\APRSIS32.exe D:\APRSIS32.\APRSIS32.XML

 

Then I could easy start APRSIS32 from

my SoundDoppler program witch resides in a Different drive and path

With something like

 

Shell("D:\APRSIS32|APRSIS32.exe D:\APRSIS32\APRSIS32.XML")

 

In Visual Basic.

 

 

73's

PA3BNX

Lodewijk Baars

 

 

 

 


Dev and Releases

sbd sbd
 

I am starting to think there should be a shorter delay between Development and Release versions.

The current release version is over a year old, and much has happened since then.

Can we say after a month of a Development version being out and no reported problems, it goes to a release version?

We can hold two download versions on the wiki. Old and proven, and a newer that seems to work ok version.

And barring a major disaster it’s easy enough, for a version to be sent out to downgrade.

 

Just a though, my Brian cell came up with. (it’s a Brain cell, he likes to be called Brian)

 

Steve Daniels

Amateur Radio Callsign G6UIM

Torbay Freecycle  Owner

http://uk.groups.yahoo.com/group/torbay_freecycle

APRSISCE/32 Beta tester and WIKI editor http://aprsisce.wikidot.com

 

 


Re: NoGateME - Why?

sbd sbd
 

Well when this comes out of the Dev version into release I will re write the Sat Ops section of the WIKI.

Gives me an excuse to play ISS again

 

 

Steve Daniels

Amateur Radio Callsign G6UIM

Torbay Freecycle  Owner

http://uk.groups.yahoo.com/group/torbay_freecycle

APRSISCE/32 Beta tester and WIKI editor http://aprsisce.wikidot.com

 


From: aprsisce@... [mailto:aprsisce@...] On Behalf Of Lynn W Deffenbaugh (Mr)
Sent: 27 September 2013 02:10
To: aprsisce@...
Subject: Re: [aprsisce] NoGateME - Why?

 

 

On 9/26/2013 7:00 PM, Lee D Bengston wrote:

I must be missing something.  Why would an IGate not beacon both on RF and Internet


Because the station wants to ensure that his RF is operating as desired without the "interference" of direct APRS-IS delivery of his packets.


- in other words, why beacon on RF only and thus rely on gating yourself after a digipeat in order for those packets to get to the Internet?


Because you're trying to get some other RF station to hear your packet on RF, direct or through a digipeater, and you don't want any chance of it being gated from the APRS-IS to RF by some other IGate.


 

Regarding the "No Gate ME" option, I like the idea of turning that on while beaconing on both RF and IS - I always thought an IGate gating its own digipeated packets for the dupe filters to throw out was kind of dumb, anyway.


How (or if) you use it is completely up to you, but at least now the option is there.  But as for why IGates gate their own digipeated packets, the IGate design spec at http://www.aprs-is.net/IGateDetails.aspx says:


Gate all packets heard on RF to the Internet EXCEPT if any of the following are true:

  1. 3rd-party packets (data type } ).
    3rd-party packets should have all before and including the data type stripped and then the packet should be processed again starting with step 1 again.
  2. generic queries (data type ? ).
  3. packets with TCPIP, TCPXX, NOGATE, or RFONLY in the header (last 2 are optional).


Nothing in there about not gating your own packets that you might have heard back via a digipeater.  Dupe filtering isn't up to the IGate, but is a function of the APRS-IS servers.

But the REAL reason for this sort of operation is when working an APRS satellite like the ISS.  You don't want to gate your own packet because you're trying to see if a VERY remote station copies the digipeat which is also a good reason for not delivering your packet immediately to the APRS-IS.  But you can keep the APRS-IS connection active so that you can see a) packets that you heard but couldn't decode, but were gated by some other IGate, and b) possibly other packets that were attempting the ISS contact but weren't careful enough to keep their original packets out of the APRS-IS.

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


Map Bright/Dim

Lynn Deffenbaugh
 

KD4DRA just mentioned something that I'm not sure made it into the release notes. See Screen / Brightness / Bright or Dim. As long as you're not running 100% opaque (right arrow the whole way), this will change the perceived brightness of the map. It does this by changing the background over which the map is transparent from white (bright) to black (dim).

I discovered this by accident during the Android port when my map was dimmer than I thought it should be. Turns out that Android was defaulting to a black background so I added the feature there and tapped it in to APRSISCE/32 as well.

For those that haven't heard about it, please see the qualifications for alpha-testing the Android port at:

http://groups.yahoo.com/neo/groups/aprsisdr/info

And please don't bring up discussions of that port in this group, but join the APRSISDR group to keep it all straight.

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


Re: Can't enable RF port

Lynn Deffenbaugh
 

Can you do the following:

1) Check Enables / Logging / Port()

2) Check Enables / Logging / File Enabled

3) Attempt to enable your port.

4) Close the client

5) E-mail your APRSIS32.XML file and all APRSIS32*.LOG files to KJ4ERJ@... that are in the default directory. Feel free to zip them up.

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

PS. I'm suspecting that your COMM port is either not configured properly or is open in another application or is not currently known to the system (a USB serial adapter plugged into a different port will change COMn numbers)

On 9/26/2013 9:34 PM, Thomas Hole wrote:
Under enable > ports > all is selected and and the 710 port is not grayed out. I simply can't select it.

Under configure > port > D710, I check enabled and accept and it does not enable.

I am connected to the com port on the control head.

Both SSID's are set to kf6kyd-1.

Thanks Lynn.

On Sep 26, 2013, at 8:03 PM, "Lynn W Deffenbaugh (Mr)" <kj4erj@...> wrote:


Please clarify "can't get the port to enable". Is it that the Enable is grayed out, that Enable checks and nothing happens, or what are the symptoms you are experiencing.

Also, which D710 port type are you using, there are multiple choices.

And what callsign-SSID is your D710 and APRSISCE/32 instance?

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

On 9/26/2013 6:03 PM, kf6kyd@... wrote:
I am using the D710 configuration that is listed on the wiki. No matter what I do I can't get the port to enable. Is there more configuration that I'm missing?





Re: NoGateME - Why?

K5DAT
 


On Thu, Sep 26, 2013 at 9:10 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:
 

On 9/26/2013 7:00 PM, Lee D Bengston wrote:
I must be missing something.  Why would an IGate not beacon both on RF and Internet

Because the station wants to ensure that his RF is operating as desired without the "interference" of direct APRS-IS delivery of his packets.

OK, but I know that when I beacon to both RF and IS, I can check a list of raw packets from aprs.fi and typically see some small minority of beacons on RF - enough to give me a warm fuzzy that the RF is working as desired.

 - in other words, why beacon on RF only and thus rely on gating yourself after a digipeat in order for those packets to get to the Internet?

Because you're trying to get some other RF station to hear your packet on RF, direct or through a digipeater, and you don't want any chance of it being gated from the APRS-IS to RF by some other IGate.

OK, but I would think the chances of that are pretty small given we're talking about beacons as opposed to messages. 
Regarding the "No Gate ME" option, I like the idea of turning that on while beaconing on both RF and IS - I always thought an IGate gating its own digipeated packets for the dupe filters to throw out was kind of dumb, anyway.
How (or if) you use it is completely up to you, but at least now the option is there.  But as for why IGates gate their own digipeated packets, the IGate design spec at http://www.aprs-is.net/IGateDetails.aspx says:

Gate all packets heard on RF to the Internet EXCEPT if any of the following are true:

  1. 3rd-party packets (data type } ).
    3rd-party packets should have all before and including the data type stripped and then the packet should be processed again starting with step 1 again.
  2. generic queries (data type ? ).
  3. packets with TCPIP, TCPXX, NOGATE, or RFONLY in the header (last 2 are optional).

Nothing in there about not gating your own packets that you might have heard back via a digipeater.  Dupe filtering isn't up to the IGate, but is a function of the APRS-IS servers.

Yes, I understand the rules, and I understand the reasons for not wanting IGates to do dupe filtering in general, but in this specific case, it seems simple and harmless for an IGate that is beaconing to the APRS-IS to ignore it's own packet coming back through a digipeater.
 
But the REAL reason for this sort of operation is when working an APRS satellite like the ISS.  You don't want to gate your own packet because you're trying to see if a VERY remote station copies the digipeat which is also a good reason for not delivering your packet immediately to the APRS-IS.  But you can keep the APRS-IS connection active so that you can see a) packets that you heard but couldn't decode, but were gated by some other IGate, and b) possibly other packets that were attempting the ISS contact but weren't careful enough to keep their original packets out of the APRS-IS.

Cool stuff!

> So, if you're transmitting packets on RF only (type disabled on the 
> APRS-IS port), and you hear your own packet digipeated back and gate it 
> to the APRS-IS, that packet will not show the RF received path, but will 
> only show TCPIP*,qAC, making it appear to have been directly 
> injected to the APRS-IS.

By the way, I forgot to mention in my original reply that I had also noticed the described phenomenon above - a couple of years ago actually, but I misunderstood it to be the IGate software actually transmitting some beacons to the IS even though it was configured not to.  I became further perplexed when I saw this behavior with more than one IGate application.  I concluded (incorrectly) that the IGate software authors were purposely having their software send some beacons to the IS for exactly the reason that Pete L described as quoted below:

> What you don't do is only originate packets to RF. The reason you don't
> do that is you break how an IGate regulates who it gates messages to on RF.
> It is important that an IGate always send all -originated- packets to APRS-IS.

LOL - I had no idea that those beacons that looked like they were sent directly into the IS were actually self-gated digipeats of the RF beacons.  The reason they were the minority is that other IGates were gating my RF beacons faster, so most of the time I would see the ones that still showed as originated on RF.

Thanks for the great information.

Lee - K5DAT



Re: Can't enable RF port

T W
 

Under enable > ports > all is selected and and the 710 port is not grayed out. I simply can't select it.

Under configure > port > D710, I check enabled and accept and it does not enable.

I am connected to the com port on the control head.

Both SSID's are set to kf6kyd-1.

Thanks Lynn.

On Sep 26, 2013, at 8:03 PM, "Lynn W Deffenbaugh (Mr)" <kj4erj@...> wrote:

 

Please clarify "can't get the port to enable".  Is it that the Enable is grayed out, that Enable checks and nothing happens, or what are the symptoms you are experiencing.

Also, which D710 port type are you using, there are multiple choices.

And what callsign-SSID is your D710 and APRSISCE/32 instance?

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

On 9/26/2013 6:03 PM, kf6kyd@... wrote:
I am using the D710 configuration that is listed on the wiki. No matter what I do I can't get the port to enable. Is there more configuration that I'm missing?




Re: NoGateME - Why?

K5DAT
 


On Thu, Sep 26, 2013 at 7:33 PM, James Ewen <ve6srv@...> wrote:
 

On Thu, Sep 26, 2013 at 5:00 PM, Lee D Bengston <kilo5dat@...> wrote:

> I must be missing something. Why would an IGate not beacon both on RF and
> Internet

Who says the station is an i-gate? The operator may only be listening
to the APRS-IS to hear more activity than is available on the local RF
channel.
 
I was referring to Lynn's example that said, "The situation is that an IGate is transmitting beacons only via RF. A digipeated copy of that packet is received by the same IGate and is gated to the APRS-IS with the qAR construct."

Yes, a station doesn't need to be an IGate to be on both RF and Internet - no disagreement there.

- in other words, why beacon on RF only and thus rely on gating
> yourself after a digipeat in order for those packets to get to the Internet?

There's no requirement for a packet to be digipeated before being
i-gated. If your next door neighbour is running an i-gate, and you
send a packet, the neighbour will send the packet to the APRS-IS upon
hearing it directly.

Didn't say there was such a requirement.  I was only referring to Lynn's scenario where an IGate was gating it's own packet after it was digipeated.  I agree that if there is another IGate nearby, an IGate that is sending beacons via RF only could be gated by that other IGate without a digipeat.  If an IGate is going to gate its own RF beacons to the IS, however, then the packet needs to be digipeated.

> This also brings up a reason for NOT acting as an i-gate... why would
> you have 2 i-gates side by side? There's no reason for it, yet why
> should you not be able to listen into the APRS-IS stream just because
> the neighbour is running an i-gate?

I'm not aware that I said anything that should be interpreted as being in favor of implementing 2 IGates side by side.  In fact, I was thinking in the context that there was not another IGate nearby when I asked about the concept of an IGate beaconing on RF only and gating itself to the APRS-IS.

Regards,
Lee - K5DAT


Re: NoGateME - Why?

Lynn Deffenbaugh
 

On 9/26/2013 7:00 PM, Lee D Bengston wrote:
I must be missing something. Why would an IGate not beacon both on RF and Internet

Because the station wants to ensure that his RF is operating as desired without the "interference" of direct APRS-IS delivery of his packets.

- in other words, why beacon on RF only and thus rely on gating yourself after a digipeat in order for those packets to get to the Internet?

Because you're trying to get some other RF station to hear your packet on RF, direct or through a digipeater, and you don't want any chance of it being gated from the APRS-IS to RF by some other IGate.


Regarding the "No Gate ME" option, I like the idea of turning that on while beaconing on both RF and IS - I always thought an IGate gating its own digipeated packets for the dupe filters to throw out was kind of dumb, anyway.

How (or if) you use it is completely up to you, but at least now the option is there. But as for why IGates gate their own digipeated packets, the IGate design spec at http://www.aprs-is.net/IGateDetails.aspx says:

Gate all packets heard on RF to the Internet EXCEPT if any of the following are true:

  1. 3rd-party packets (data type } ).
    3rd-party packets should have all before and including the data type stripped and then the packet should be processed again starting with step 1 again.
  2. generic queries (data type ? ).
  3. packets with TCPIP, TCPXX, NOGATE, or RFONLY in the header (last 2 are optional).

Nothing in there about not gating your own packets that you might have heard back via a digipeater. Dupe filtering isn't up to the IGate, but is a function of the APRS-IS servers.

But the REAL reason for this sort of operation is when working an APRS satellite like the ISS. You don't want to gate your own packet because you're trying to see if a VERY remote station copies the digipeat which is also a good reason for not delivering your packet immediately to the APRS-IS. But you can keep the APRS-IS connection active so that you can see a) packets that you heard but couldn't decode, but were gated by some other IGate, and b) possibly other packets that were attempting the ISS contact but weren't careful enough to keep their original packets out of the APRS-IS.

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


Re: Can't enable RF port

Lynn Deffenbaugh
 

Please clarify "can't get the port to enable".  Is it that the Enable is grayed out, that Enable checks and nothing happens, or what are the symptoms you are experiencing.

Also, which D710 port type are you using, there are multiple choices.

And what callsign-SSID is your D710 and APRSISCE/32 instance?

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

On 9/26/2013 6:03 PM, kf6kyd@... wrote:
I am using the D710 configuration that is listed on the wiki. No matter what I do I can't get the port to enable. Is there more configuration that I'm missing?


Re: NoGateME - Why?

James Ewen
 

On Thu, Sep 26, 2013 at 5:00 PM, Lee D Bengston <kilo5dat@gmail.com> wrote:

I must be missing something. Why would an IGate not beacon both on RF and
Internet
Who says the station is an i-gate? The operator may only be listening
to the APRS-IS to hear more activity than is available on the local RF
channel.

- in other words, why beacon on RF only and thus rely on gating
yourself after a digipeat in order for those packets to get to the Internet?
There's no requirement for a packet to be digipeated before being
i-gated. If your next door neighbour is running an i-gate, and you
send a packet, the neighbour will send the packet to the APRS-IS upon
hearing it directly.

This also brings up a reason for NOT acting as an i-gate... why would
you have 2 i-gates side by side? There's no reason for it, yet why
should you not be able to listen into the APRS-IS stream just because
the neighbour is running an i-gate?

--
James
VE6SRV


Re: NoGateME - Why?

K5DAT
 

I must be missing something.  Why would an IGate not beacon both on RF and Internet - in other words, why beacon on RF only and thus rely on gating yourself after a digipeat in order for those packets to get to the Internet?

Regarding the "No Gate ME" option, I like the idea of turning that on while beaconing on both RF and IS - I always thought an IGate gating its own digipeated packets for the dupe filters to throw out was kind of dumb, anyway.

Regards,
Lee - K5DAT



On Wed, Sep 25, 2013 at 5:03 AM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:
 

(Wiki fodder follows)

The latest DEV release includes a feature to allow configuring an RF
port with "No Gate ME". Why would this be necessary? Well, I've
learned something new (yet again) about the APRS-IS server behaviors.
Here's my original question to Pete, AE5PL, and his subsequent answer:

> I'm trying to understand how a packet gated from RF to the -IS had its
> RFpath,qAR,KJ4ERJ-1 replaced with TCPIP*,qAC,KJ4ERJ-5 before being
> propagated using the q algorithm fromhttp://www.aprs-
> is.net/qalgorithm.aspx KJ4ERJ-1 was the source of the packet as well as the
> IGate of the packet and the verified login to the javAPRSSrvr server which is
> running as KJ4ERJ-5.
>
> The situation is that an IGate is transmitting beacons only via RF. A
> digipeated copy of that packet is received by the same IGate and is gated to
> the APRS-IS with the qAR construct. But when the packet propagates
> through the -IS, the fact that it was received via RF has been replaced with a
> qAC construct.
>
> Note: this example is from my own KJ4ERJ-1 IGate, but the real world issue
> that I'm tracking down is an operator beaconing via the ISS (RF-Only) and
> gating the received digipeat of his own packet which is exhibiting the same
> behavior. This is why Mark, MM1MPB is copied on this message.

Pete's answer:

> That is because an IGate is not supposed to pass its own packets to APRS-IS as gated packets without passing them directly to the upstream server. It has nothing to do with the q algorithm and everything to do with server operation.

> This is done before any q algorithm operation because there are clients out there that couldn't figure out how to place a TCPIP* as the only thing in the path. Pain in the butt but that is how it works to compensate for noncompliant clients.

So, if you're transmitting packets on RF only (type disabled on the
APRS-IS port), and you hear your own packet digipeated back and gate it
to the APRS-IS, that packet will not show the RF received path, but will
only show TCPIP*,qAC, making it appear to have been directly
injected to the APRS-IS. This obviously is non-desired behavior for
satellite operations.

With the new "No Gate ME" option on the RF port, APRSISCE/32 will not
pass received copies of it's own packets back to the APRS-IS allowing
remote IGates the opportunity to gate the packet preserving the received
RF path.

Note that this does not change the fact that the APRS-IS is decidedly
NOT a good vehicle for doing APRS RF coverage analysis because the dupe
filters are still in place. Only the first copy of any packet is
propagated and all other copies are summarily discarded as unnecessary
duplicates, even if received via different RF paths and/or different IGates.

Also, please note Pete's follow-up warning if you do decide to use "No
Gate ME":

> Absolutely use the login for the client's callsign, whether it is an IGate or not! The q algorithm depends on it! What you don't do is only originate packets to RF. The reason you don't do that is you break how an IGate regulates who it gates messages to on RF. It is important that an IGate always send all -originated- packets to APRS-IS. RF is the part that is optional.

So, if you're using "No Gate ME", don't expect APRS-IS-side messaging to
function correctly with remote IGates. If you're trying to be an
RF-only station with an -IS connection, you better understand ALL of the
ramifications of that operating style. You MAY be introducing more QRM
on the RF channel because remote IGates will not be aware of your
-IS-conneccted status and may be gating messages from -IS to RF for your
station because the remote IGate will believe you're on RF only and will
be "helping".

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



Can't enable RF port

T W
 

I am using the D710 configuration that is listed on the wiki. No matter what I do I can't get the port to enable. Is there more configuration that I'm missing?

11301 - 11320 of 35243