Date   

Re: Kpc3+ (Note on the long-delayed packet problem)

Lynn Deffenbaugh
 

http://aprs.org/kpc3/fix14439.html


404: Page not found
This error is generated when there was no web page with the name you specified at the web site.

Troubleshooting suggestions:

Ensure the page you are linking to exists in the correct folder.

Check your file name for case sensitivity . Index.htm is not the same as index.htm!

Temporarily disable any rewrite rules by renaming your .htaccess file if it exists.


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



On 6/14/2021 5:30 PM, Robert Bruninga wrote:
Thanks, I have added it tot he two configuration files for th e KPC3
found on the http://aprs.org/kpc3/fix14439.html page.
That page was developed in about 2004 to come up with the
nominal APRS-IS configuration we have today.

Bob, Wb4APR

On Mon, Jun 14, 2021 at 4:50 PM Robert D. York <kf4ffn@...> wrote:
>
> Ok,
>
> On Mon, Jun 14, 2021, 1:13 PM Lynn Deffenbaugh <kj4erj@...> wrote:
>>
>> The issue with the KPC-3+ has nothing to do with the MON command, but everything to do with a firmware bug and handshaking signals.  Please read and understand:
>>
>> http://blog.aprs.fi/2011/03/kantronics-kpc3-considered-harmful.html
>>
>> And especially the comment that says:
>>
>> I was working with Kantronics support on this issue and I seem to have solved it by shorting the RTS and CTS pins together within my serial cable. (PINS 4/5 on DB25 and PINS 7/8 on DB9) I simply ran a jumper between the two. This appears to be an issue with how the APRS software and/or the AX.25 stack controls the RTS pin and shorting the RTS and CTS together prevents the software from holding the RTS pin low. If the RTS pin is at low voltage the KPC3+ will start buffering and does not get caught back up. I have been running mine for several weeks without showing this behavior again. Before I made the change it would happen after about 12 hours.
>>
>>
>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>>
>>
>> On 6/14/2021 1:30 PM, Gil wrote:
>>
>> Please check your KPC3+ (or KPC3) once you've got it in operation.  I have seen those TNCs delay packets for a significant amount of time before digipeating them.  They are sometimes delayed so long that the system thinks they're new packets - and repositions my mobile station accordingly.  I've seen my mobile beacons regurgitated by KPC3 digipeaters many minutes (and miles) after they were sent.  On a recurring basis, it makes the track appear to be bouncing back and forth from where it most recently was (as digipeated by other digipeaters) to where it formerly was (at a former beacon location delayed by the KPC3) - many miles away (I think astronomers call it "retrograde motion" when they refer to the apparent observed motion of some planets).  I have a problem with a KPC3 digipeater doing that right now (I need to try to contact the owner again...).  I can see my beacons showing up from it 5 or more minutes after they were sent from my station at another location.  It won't be obvious for a fixed station, but it sure shows up for mobiles.
>>
>> Please just check that your setup is not doing that.  Monitor it for a while once you've got it going.  This is apparently a known problem for some KPC3s.  Lynn can probably provide information regarding what to do about it.
>>
>> Gil Chapin, WB2UTI
>


Re: Kpc3+ (Note on the long-delayed packet problem)

Robert Bruninga
 

Thanks, I have added it tot he two configuration files for th e KPC3
found on the http://aprs.org/kpc3/fix14439.html page.
That page was developed in about 2004 to come up with the
nominal APRS-IS configuration we have today.

Bob, Wb4APR


On Mon, Jun 14, 2021 at 4:50 PM Robert D. York <kf4ffn@...> wrote:
>
> Ok,
>
> On Mon, Jun 14, 2021, 1:13 PM Lynn Deffenbaugh <kj4erj@...> wrote:
>>
>> The issue with the KPC-3+ has nothing to do with the MON command, but everything to do with a firmware bug and handshaking signals.  Please read and understand:
>>
>> http://blog.aprs.fi/2011/03/kantronics-kpc3-considered-harmful.html
>>
>> And especially the comment that says:
>>
>> I was working with Kantronics support on this issue and I seem to have solved it by shorting the RTS and CTS pins together within my serial cable. (PINS 4/5 on DB25 and PINS 7/8 on DB9) I simply ran a jumper between the two. This appears to be an issue with how the APRS software and/or the AX.25 stack controls the RTS pin and shorting the RTS and CTS together prevents the software from holding the RTS pin low. If the RTS pin is at low voltage the KPC3+ will start buffering and does not get caught back up. I have been running mine for several weeks without showing this behavior again. Before I made the change it would happen after about 12 hours.
>>
>>
>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>>
>>
>> On 6/14/2021 1:30 PM, Gil wrote:
>>
>> Please check your KPC3+ (or KPC3) once you've got it in operation.  I have seen those TNCs delay packets for a significant amount of time before digipeating them.  They are sometimes delayed so long that the system thinks they're new packets - and repositions my mobile station accordingly.  I've seen my mobile beacons regurgitated by KPC3 digipeaters many minutes (and miles) after they were sent.  On a recurring basis, it makes the track appear to be bouncing back and forth from where it most recently was (as digipeated by other digipeaters) to where it formerly was (at a former beacon location delayed by the KPC3) - many miles away (I think astronomers call it "retrograde motion" when they refer to the apparent observed motion of some planets).  I have a problem with a KPC3 digipeater doing that right now (I need to try to contact the owner again...).  I can see my beacons showing up from it 5 or more minutes after they were sent from my station at another location.  It won't be obvious for a fixed station, but it sure shows up for mobiles.
>>
>> Please just check that your setup is not doing that.  Monitor it for a while once you've got it going.  This is apparently a known problem for some KPC3s.  Lynn can probably provide information regarding what to do about it.
>>
>> Gil Chapin, WB2UTI
>


Re: My Bluetooth Mobilink TNC 2 issue

Don Poaps
 

Hi Todd.

I did use the Mobilink Audio Config program on my Android phone. I've
put the Bluetooth on the back burner for now.

Thank You

73

Don Poaps
New Westminster, BC
VA7DGP DATA
VA7QU VOICE


Winlink: va7qu@...
Subject://wl2k

ALLSTAR 530780
HH# 5971
HH# 11384
Alberta Mesh# 5404

On Mon, Jun 14, 2021 at 1:53 PM <todd.dugdale@...> wrote:

If you configure the Mobilinkd TNC for one radio, and then use it on another, the audio settings will be different. The TX audio might be too low or too high, or there's too much difference between the levels of the two tones. It sounds like you set up the audio on the Alinco, and then plugged the TNC into a Woxoun. This might explain why the Alinco "works" and the other radio doesn't. If you set up the TX audio on the Woxoun, you would know it transmits because you need to listen to the transmitted audio level on a different radio.

Further, if you did a "reset" of the Mobilinkd TNC (as you said), then you wiped out the audio settings for the Alinco and you're using the defaults.

The problem is probably not that the Mobilinkd isn't "transmitting"; the transmitted signal probably can't be read because of bad audio levels.


Re: Kpc3+ settings for APRSISCE

Robert D. York
 

Ok,


On Mon, Jun 14, 2021, 1:13 PM Lynn Deffenbaugh <kj4erj@...> wrote:

The issue with the KPC-3+ has nothing to do with the MON command, but everything to do with a firmware bug and handshaking signals.  Please read and understand:

http://blog.aprs.fi/2011/03/kantronics-kpc3-considered-harmful.html

And especially the comment that says:

I was working with Kantronics support on this issue and I seem to have solved it by shorting the RTS and CTS pins together within my serial cable. (PINS 4/5 on DB25 and PINS 7/8 on DB9) I simply ran a jumper between the two. This appears to be an issue with how the APRS software and/or the AX.25 stack controls the RTS pin and shorting the RTS and CTS together prevents the software from holding the RTS pin low. If the RTS pin is at low voltage the KPC3+ will start buffering and does not get caught back up. I have been running mine for several weeks without showing this behavior again. Before I made the change it would happen after about 12 hours.

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


On 6/14/2021 1:30 PM, Gil wrote:
Please check your KPC3+ (or KPC3) once you've got it in operation.  I have seen those TNCs delay packets for a significant amount of time before digipeating them.  They are sometimes delayed so long that the system thinks they're new packets - and repositions my mobile station accordingly.  I've seen my mobile beacons regurgitated by KPC3 digipeaters many minutes (and miles) after they were sent.  On a recurring basis, it makes the track appear to be bouncing back and forth from where it most recently was (as digipeated by other digipeaters) to where it formerly was (at a former beacon location delayed by the KPC3) - many miles away (I think astronomers call it "retrograde motion" when they refer to the apparent observed motion of some planets).  I have a problem with a KPC3 digipeater doing that right now (I need to try to contact the owner again...).  I can see my beacons showing up from it 5 or more minutes after they were sent from my station at another location.  It won't be obvious for a fixed station, but it sure shows up for mobiles.

Please just check that your setup is not doing that.  Monitor it for a while once you've got it going.  This is apparently a known problem for some KPC3s.  Lynn can probably provide information regarding what to do about it.

Gil Chapin, WB2UTI


Re: My Bluetooth Mobilink TNC 2 issue

todd.dugdale@...
 

If you configure the Mobilinkd TNC for one radio, and then use it on another, the audio settings will be different. The TX audio might be too low or too high, or there's too much difference between the levels of the two tones. It sounds like you set up the audio on the Alinco, and then plugged the TNC into a Woxoun. This might explain why the Alinco "works" and the other radio doesn't.  If you set up the TX audio on the Woxoun, you would know it transmits because you need to listen to the transmitted audio level on a different radio.

 Further, if you did a "reset" of the Mobilinkd TNC (as you said), then you wiped out the audio settings for the Alinco and you're using the defaults.

The problem is probably not that the Mobilinkd isn't "transmitting"; the transmitted signal probably can't be read because of bad audio levels.


Re: Kpc3+ settings for APRSISCE

Lynn Deffenbaugh
 

The issue with the KPC-3+ has nothing to do with the MON command, but everything to do with a firmware bug and handshaking signals.  Please read and understand:

http://blog.aprs.fi/2011/03/kantronics-kpc3-considered-harmful.html

And especially the comment that says:

I was working with Kantronics support on this issue and I seem to have solved it by shorting the RTS and CTS pins together within my serial cable. (PINS 4/5 on DB25 and PINS 7/8 on DB9) I simply ran a jumper between the two. This appears to be an issue with how the APRS software and/or the AX.25 stack controls the RTS pin and shorting the RTS and CTS together prevents the software from holding the RTS pin low. If the RTS pin is at low voltage the KPC3+ will start buffering and does not get caught back up. I have been running mine for several weeks without showing this behavior again. Before I made the change it would happen after about 12 hours.

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


On 6/14/2021 1:30 PM, Gil wrote:
Please check your KPC3+ (or KPC3) once you've got it in operation.  I have seen those TNCs delay packets for a significant amount of time before digipeating them.  They are sometimes delayed so long that the system thinks they're new packets - and repositions my mobile station accordingly.  I've seen my mobile beacons regurgitated by KPC3 digipeaters many minutes (and miles) after they were sent.  On a recurring basis, it makes the track appear to be bouncing back and forth from where it most recently was (as digipeated by other digipeaters) to where it formerly was (at a former beacon location delayed by the KPC3) - many miles away (I think astronomers call it "retrograde motion" when they refer to the apparent observed motion of some planets).  I have a problem with a KPC3 digipeater doing that right now (I need to try to contact the owner again...).  I can see my beacons showing up from it 5 or more minutes after they were sent from my station at another location.  It won't be obvious for a fixed station, but it sure shows up for mobiles.

Please just check that your setup is not doing that.  Monitor it for a while once you've got it going.  This is apparently a known problem for some KPC3s.  Lynn can probably provide information regarding what to do about it.

Gil Chapin, WB2UTI


Re: ICOM ID51A DPRS ON MAP

EA1AXY
 


Re: KPC-3

Les Keegan
 

I should have said also the KPC-3 has a DB-25 plug that you will need a cable to go to the computer from the TNC.

Les Keegan
N4LPK

On Monday, June 14, 2021, 02:01:36 PM EDT, Les Keegan via groups.io <l_keegan@...> wrote:


If the KPC-3 has a DB-9 on the back of it you need a DB-9 to 6 pin mini din cable for the V71A.

Les Keegan
N4LPK

On Monday, June 14, 2021, 11:11:28 AM EDT, Michael McNamara via groups.io <n3mrm@...> wrote:


How to connect my KPC-3 to my Kenwood TM-V71.


Re: KPC-3

Les Keegan
 

If the KPC-3 has a DB-9 on the back of it you need a DB-9 to 6 pin mini din cable for the V71A.

Les Keegan
N4LPK

On Monday, June 14, 2021, 11:11:28 AM EDT, Michael McNamara via groups.io <n3mrm@...> wrote:


How to connect my KPC-3 to my Kenwood TM-V71.


Re: Kpc3+ settings for APRSISCE

Robert D. York
 

IMPORTANT!! If you intend to leave the TNC attached to a computer, but will not be running an APRS or other terminal program on that computer, you must make sure that the INITKPC3.TNC and RESTORE.TNC files are modified to include "MON ON" and "MON OFF", respectively. And, before exiting from any terminal program, issue a "MON OFF" command.

In this particular circumstance, it is possible for the computer's serial port to tell the TNC to not send data. When the TNC's port buffer fills, the TNC may stop working. This problem has not been reported when the TNC is not plugged into a computer, or if the computer is actively listening to the TNC. In the absense of a connected computer, however, the TNC just sends the excess data off to the bit bucket. [Note: failure to provide a properly-sized bit bucket will require proper drainage, or sufficient airflow to allow for adequate bit evaporation]


On Mon, Jun 14, 2021, 12:30 PM Gil <gil.chapin@...> wrote:
Please check your KPC3+ (or KPC3) once you've got it in operation.  I have seen those TNCs delay packets for a significant amount of time before digipeating them.  They are sometimes delayed so long that the system thinks they're new packets - and repositions my mobile station accordingly.  I've seen my mobile beacons regurgitated by KPC3 digipeaters many minutes (and miles) after they were sent.  On a recurring basis, it makes the track appear to be bouncing back and forth from where it most recently was (as digipeated by other digipeaters) to where it formerly was (at a former beacon location delayed by the KPC3) - many miles away (I think astronomers call it "retrograde motion" when they refer to the apparent observed motion of some planets).  I have a problem with a KPC3 digipeater doing that right now (I need to try to contact the owner again...).  I can see my beacons showing up from it 5 or more minutes after they were sent from my station at another location.  It won't be obvious for a fixed station, but it sure shows up for mobiles.

Please just check that your setup is not doing that.  Monitor it for a while once you've got it going.  This is apparently a known problem for some KPC3s.  Lynn can probably provide information regarding what to do about it.

Gil Chapin, WB2UTI


Re: Kpc3+ settings for APRSISCE

Robert D. York
 

Yes Sir, I set the "MON"to Off before exiting the Terminal Mode to KISS Mode as suggested by WB4APR.
We'll see what happens.

On Mon, Jun 14, 2021, 12:30 PM Gil <gil.chapin@...> wrote:
Please check your KPC3+ (or KPC3) once you've got it in operation.  I have seen those TNCs delay packets for a significant amount of time before digipeating them.  They are sometimes delayed so long that the system thinks they're new packets - and repositions my mobile station accordingly.  I've seen my mobile beacons regurgitated by KPC3 digipeaters many minutes (and miles) after they were sent.  On a recurring basis, it makes the track appear to be bouncing back and forth from where it most recently was (as digipeated by other digipeaters) to where it formerly was (at a former beacon location delayed by the KPC3) - many miles away (I think astronomers call it "retrograde motion" when they refer to the apparent observed motion of some planets).  I have a problem with a KPC3 digipeater doing that right now (I need to try to contact the owner again...).  I can see my beacons showing up from it 5 or more minutes after they were sent from my station at another location.  It won't be obvious for a fixed station, but it sure shows up for mobiles.

Please just check that your setup is not doing that.  Monitor it for a while once you've got it going.  This is apparently a known problem for some KPC3s.  Lynn can probably provide information regarding what to do about it.

Gil Chapin, WB2UTI


Re: Rd transmission from my transceiver

Robert D. York
 

I reset tnc several times as I discovered suggestions from the APRS community. Which required hard reset or jumper rotation.
So I learned the significance of getting everything done before switching to KISS mode.
The APRSISCE software is another hurdle that will some practice.
Today you taught me how to get to Trace(transmit) and your suspension of port error was right on que.
Since I've learned the maze of deleting an undesirable port.
Thanks again for your help.



On Mon, Jun 14, 2021, 12:13 PM Lynn Deffenbaugh <kj4erj@...> wrote:

Can you fill us in on the resolution so that others that may have the same problem won't have to go through so many questions to get to the answer?

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


On 6/14/2021 1:07 PM, Robert D. York wrote:
Thanks Sir, the problem has been resolved thanks to your questions and direction.

On Mon, Jun 14, 2021, 12:04 PM Lynn Deffenbaugh <kj4erj@...> wrote:

[INT] is an "INTernal" transmission used to propagate information strictly inside APRSISCE/32.

[IS+RF] is a packet that would like to be transmitted on both APRS-IS and RF ports, but only if said ports are actually enabled for transmitting the specific type of packet.

The Port(<YourPortName>) enabled and viewing is the next place to look for why a packet may not be getting to your TNC.

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


On 6/14/2021 12:39 PM, Robert D. York wrote:
Please define [INT] and [IS+RF] provided in Trace(Transmit) log

On Mon, Jun 14, 2021, 10:49 AM Lynn Deffenbaugh <kj4erj@...> wrote:

When APRSISCE/32 transmits, of course!  Open and enable the Transmit trace log and then hit the Transmit menu option.

Maybe also read: http://aprsisce.wikidot.com/doc:transmitting

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


On 6/14/2021 11:34 AM, Robert D. York wrote:
When should I see transmission indication on my tnc and txcvr while on APRSISCE?


Re: Kpc3+ settings for APRSISCE

Gil
 

Please check your KPC3+ (or KPC3) once you've got it in operation.  I have seen those TNCs delay packets for a significant amount of time before digipeating them.  They are sometimes delayed so long that the system thinks they're new packets - and repositions my mobile station accordingly.  I've seen my mobile beacons regurgitated by KPC3 digipeaters many minutes (and miles) after they were sent.  On a recurring basis, it makes the track appear to be bouncing back and forth from where it most recently was (as digipeated by other digipeaters) to where it formerly was (at a former beacon location delayed by the KPC3) - many miles away (I think astronomers call it "retrograde motion" when they refer to the apparent observed motion of some planets).  I have a problem with a KPC3 digipeater doing that right now (I need to try to contact the owner again...).  I can see my beacons showing up from it 5 or more minutes after they were sent from my station at another location.  It won't be obvious for a fixed station, but it sure shows up for mobiles.

Please just check that your setup is not doing that.  Monitor it for a while once you've got it going.  This is apparently a known problem for some KPC3s.  Lynn can probably provide information regarding what to do about it.

Gil Chapin, WB2UTI


Re: ICOM ID51A DPRS ON MAP

Lynn Deffenbaugh
 

Doesn't the D-star repeater or hotspot also need to be running D-PRS to take the received positions, reformat them, and inject them to the APRS-IS?

http://www.aprs-is.net/dprs.aspx


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


On 6/14/2021 1:09 PM, justin killen via groups.io wrote:
First off, you have to be within range of a D-star repeater or hotspot. DPRS doesn’t work the same as APRS. As long as you’re at within range of a D-star repeater, is all in the settings of the radio from there


Re: Rd transmission from my transceiver

Lynn Deffenbaugh
 

Can you fill us in on the resolution so that others that may have the same problem won't have to go through so many questions to get to the answer?

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


On 6/14/2021 1:07 PM, Robert D. York wrote:
Thanks Sir, the problem has been resolved thanks to your questions and direction.

On Mon, Jun 14, 2021, 12:04 PM Lynn Deffenbaugh <kj4erj@...> wrote:

[INT] is an "INTernal" transmission used to propagate information strictly inside APRSISCE/32.

[IS+RF] is a packet that would like to be transmitted on both APRS-IS and RF ports, but only if said ports are actually enabled for transmitting the specific type of packet.

The Port(<YourPortName>) enabled and viewing is the next place to look for why a packet may not be getting to your TNC.

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


On 6/14/2021 12:39 PM, Robert D. York wrote:
Please define [INT] and [IS+RF] provided in Trace(Transmit) log

On Mon, Jun 14, 2021, 10:49 AM Lynn Deffenbaugh <kj4erj@...> wrote:

When APRSISCE/32 transmits, of course!  Open and enable the Transmit trace log and then hit the Transmit menu option.

Maybe also read: http://aprsisce.wikidot.com/doc:transmitting

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


On 6/14/2021 11:34 AM, Robert D. York wrote:
When should I see transmission indication on my tnc and txcvr while on APRSISCE?


Re: ICOM ID51A DPRS ON MAP

justin killen
 

First off, you have to be within range of a D-star repeater or hotspot. DPRS doesn’t work the same as APRS. As long as you’re at within range of a D-star repeater, is all in the settings of the radio from there


Re: Rd transmission from my transceiver

Robert D. York
 

Thanks Sir, the problem has been resolved thanks to your questions and direction.


On Mon, Jun 14, 2021, 12:04 PM Lynn Deffenbaugh <kj4erj@...> wrote:

[INT] is an "INTernal" transmission used to propagate information strictly inside APRSISCE/32.

[IS+RF] is a packet that would like to be transmitted on both APRS-IS and RF ports, but only if said ports are actually enabled for transmitting the specific type of packet.

The Port(<YourPortName>) enabled and viewing is the next place to look for why a packet may not be getting to your TNC.

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


On 6/14/2021 12:39 PM, Robert D. York wrote:
Please define [INT] and [IS+RF] provided in Trace(Transmit) log

On Mon, Jun 14, 2021, 10:49 AM Lynn Deffenbaugh <kj4erj@...> wrote:

When APRSISCE/32 transmits, of course!  Open and enable the Transmit trace log and then hit the Transmit menu option.

Maybe also read: http://aprsisce.wikidot.com/doc:transmitting

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


On 6/14/2021 11:34 AM, Robert D. York wrote:
When should I see transmission indication on my tnc and txcvr while on APRSISCE?


Re: Rd transmission from my transceiver

Lynn Deffenbaugh
 

[INT] is an "INTernal" transmission used to propagate information strictly inside APRSISCE/32.

[IS+RF] is a packet that would like to be transmitted on both APRS-IS and RF ports, but only if said ports are actually enabled for transmitting the specific type of packet.

The Port(<YourPortName>) enabled and viewing is the next place to look for why a packet may not be getting to your TNC.

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


On 6/14/2021 12:39 PM, Robert D. York wrote:
Please define [INT] and [IS+RF] provided in Trace(Transmit) log

On Mon, Jun 14, 2021, 10:49 AM Lynn Deffenbaugh <kj4erj@...> wrote:

When APRSISCE/32 transmits, of course!  Open and enable the Transmit trace log and then hit the Transmit menu option.

Maybe also read: http://aprsisce.wikidot.com/doc:transmitting

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


On 6/14/2021 11:34 AM, Robert D. York wrote:
When should I see transmission indication on my tnc and txcvr while on APRSISCE?


Re: ICOM ID51A DPRS ON MAP

Lynn Deffenbaugh
 

I'm not sure I know what an "ID51A GPS" is?  But I suspect it has to do with D-Star and not APRS...

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


On 6/14/2021 12:35 PM, Al Massaro KF5SMH wrote:
We are attempting to have all of our team members activate their ID51A GPS  and then be able to track them on the map.
As yet we cannot get the position reports to show up on the map, we have tried both the A and G message options.
Anybody try this and if so, how did you get it to work?
Any help appreciated!

AL M 
KF5SMH


Re: Rd transmission from my transceiver

Robert D. York
 

Please define [INT] and [IS+RF] provided in Trace(Transmit) log


On Mon, Jun 14, 2021, 10:49 AM Lynn Deffenbaugh <kj4erj@...> wrote:

When APRSISCE/32 transmits, of course!  Open and enable the Transmit trace log and then hit the Transmit menu option.

Maybe also read: http://aprsisce.wikidot.com/doc:transmitting

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


On 6/14/2021 11:34 AM, Robert D. York wrote:
When should I see transmission indication on my tnc and txcvr while on APRSISCE?

881 - 900 of 36337