1. APRSISCE@groups.io
   Date   
ME

pat obrien
 

How do you get rid of the ME in the setup, I have filled the windows popup 4x, and it still comes up me, I have got the qth down and dragged it to transmit and still ME, Any help appreciated.
POB/K8LEN
Re: APRSIS23 HF APRS & PTC-IIex

John Brent - VA7WPN
 

Here are the instructions I have been following :

https://robust-packet.net/Robust-Packet-Network-Manual.pdf

Specificaly : 
Re: APRSIS23 HF APRS & PTC-IIex

Lynn Deffenbaugh
 

Answers interspersed below...


On 1/22/2020 3:24 PM, John Brent - VA7WPN wrote:
I am putting together an HF APRS station, or attempting to anyways. I am using a TS-2000 and SCS PTC-IIex as hardware. I am using APRSIS32 to control it all. But I am finding it not so easy to get it to work with my equipment. I will explain below.

A) When I set the baud rate to 300 baud, it saves but when I reopen the port configuration it is set to 1200 again. I can confirm this is the same in the XML file, even if I edit the XML to be 300 baud it will revert to 1200 again.
The port setting for baud rate is a red herring.  It is not used.  The RF baud rate is completely under the control of the TNC, not APRSIS32.  This dates back to my start when I really didn't understand how it all worked.

B) Editing the XML file, when I edit it as per instructions on the instructions on the Robust Packet website for HF APRS and APRSIS32... the PTC-IIex restarts, the LED's go off, and is non responsive. How ever if I dont edit anything, it sends packets... but not at 300 baud. APRSIS32 was off when I edited the XML file.
Can you provide a link to the instructions you are following? And what port type you are specifying in APRSIS32?  I'm not familiar with the PTC-IIex, but maybe someone else is.


Any ideas what is going on?
Yeah, it's not working!  (Couldn't resist...)

thanks a ton.

PS : I have read other posts before I posted this one.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
APRSIS23 HF APRS & PTC-IIex

John Brent - VA7WPN
 

Good afternoon,

I am putting together an HF APRS station, or attempting to anyways. I am using a TS-2000 and SCS PTC-IIex as hardware. I am using APRSIS32 to control it all. But I am finding it not so easy to get it to work with my equipment. I will explain below.

A) When I set the baud rate to 300 baud, it saves but when I reopen the port configuration it is set to 1200 again. I can confirm this is the same in the XML file, even if I edit the XML to be 300 baud it will revert to 1200 again.
B) Editing the XML file, when I edit it as per instructions on the instructions on the Robust Packet website for HF APRS and APRSIS32... the PTC-IIex restarts, the LED's go off, and is non responsive. How ever if I dont edit anything, it sends packets... but not at 300 baud. APRSIS32 was off when I edited the XML file. 

Any ideas what is going on?

thanks a ton. 

PS : I have read other posts before I posted this one.
] soundmodem and aprsi32

Bill Vodall
 

These pages will give you a good start 


On Tue, Jan 21, 2020, 12:56 AM Jose Manuel Martinez Barbera <ea8ee1@...> wrote:
If it works perfectly with the first agw option, tested in vhf, a question which hf frequencies and aprs modes can I use for testing

El lun., 20 ene. 2020 a las 22:44, Rob Giuliano via Groups.Io (<kb8rco=yahoo.com@groups.io>) escribió:
As far as I know, there are no special settings within APRSIS32 for HF.
UZ7HO's SoundModem application is a sofwtare based TNC and its settings take care of the HF vs. VHF/UHF settings.
  You will hvae to check the UZ7HO manual for the proper settings for HF
These are not within APRSIS32.

To interface the UZ7HO SoundModem to APRSIS32, you have 2 options:
1. AGW port over TCP/IP  
    Menu >Configure >New Port ... 
       Port Type:    AGW
       Port Name:  UZ7HO                { or your choice}
       Hit  <Create> button
    Choose <TCP/IP>
       IP or DNS:    LocalHost          {IP address of computer running SoundModem}
       Port:              8000                   {Unless you have configured a different port}
2. KISS port over TCP/IP
    Menu >Configure >New Port ... 
       Port Type:    Simply(KISS)
       Port Name:  UZ7HO                { or your choice}
       Hit  <Create> button
    Choose <TCP/IP>
       IP or DNS:    LocalHost          {IP address of computer running SoundModem}
       Port:              8100                   {Unless you have configured a different port}

Good luck - let us know how it works out.

Robert Giuliano
KB8RCO



On Monday, January 20, 2020, 12:16:00 PM EST, Jose Manuel Martinez Barbera <ea8ee1@...> wrote:




Someone has the configuration of aprs32 with soundmodem software for aprs hf
Re: APRSIS32

Lynn Deffenbaugh
 

You can download APRSIS32 from the following link.  You'll likely also want to upgrade to the latest development version immediately after installing and applying your APRS-IS passcode.

http://aprsisce.wikidot.com/downloads

http://aprsisce.wikidot.com/doc:development-version

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

On 1/22/2020 7:41 AM, Neal Harden via Groups.Io wrote:

Hallo Lynn

 

I thought I had set up APRSIS on my laptop, about a year ago.  For some reason I now cannot find it.  I need to use it for an upcoming Scouting event so could I please re-register and have access to the files.

 

Thanks

 

Neal Harden

M1EKM

Gloucestershire UK
Re: APRSIS32

Steve
 

Passcode for M1EKM is 13976

This passcode will work for any -SSID (http://aprsisce.wikidot.com/doc:ssids) you choose to use.
Because it is actually the APRS-IS network passcode, it should also work with other APRS-IS client software.

73
Steve, KF6WAX

On Wed, Jan 22, 2020 at 12:41 PM Neal Harden via Groups.Io <gnharden=btopenworld.com@groups.io> wrote:

Hallo Lynn

 

I thought I had set up APRSIS on my laptop, about a year ago.  For some reason I now cannot find it.  I need to use it for an upcoming Scouting event so could I please re-register and have access to the files.

 

Thanks

 

Neal Harden

M1EKM

Gloucestershire UK
APRSIS32

Neal Harden
 

Hallo Lynn

 

I thought I had set up APRSIS on my laptop, about a year ago.  For some reason I now cannot find it.  I need to use it for an upcoming Scouting event so could I please re-register and have access to the files.

 

Thanks

 

Neal Harden

M1EKM

Gloucestershire UK
Re: [EXT] Re: [APRSISCE] Using Kantronics KPC3+ with APRSIS32

Kevin Reeve
 

I have not seen any issues with delayed KPC3+ digipeates here in Utah.  We pretty much run exclusively with KPc3+ in standalone, so no external software.



Kevin N7RXE




On Jan 21, 2020, at 09:13, Lynn Deffenbaugh via Groups.Io <kj4erj@...> wrote:

Gil,

Good suggestion, but it isn't really using a KPC-3+ as a digipeater that is an issue, but using a KPC-3+ in KISS mode with upstream software doing the digipeating.

The KPC-3+ firmware does excellent digipeating as far as I know.  Provided that the digipeating is being done completely within the device itself.

There is a well documented bug in the KPC-3+ firmware's KISS support that causes received packets to be delayed in delivery out the KISS port.  This means that any software-based digipeater (or IGate for that matter) receiving KISS packets from a KPC-3+ will be marching slowly backwards in time as the delays seem to get longer and longer until the KPC-3+ is reset.

This is will documented in an article by Hessu, the author of aprs.fi, at the following link.

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

Recommended reading as well as this article:

https://packet-radio.net/kantronics-kpc3-kiss-considered-harmful/

It seems that the issue may be solved by simply tying RTS and CTS together at the KPC-3+ end of the serial cable.  But getting this word out, and worse, convincing KPC-3+ owners running in KISS mode, is an ongoing challenge.

Oh, and I've seen the issue more with KISS-mode KPC-3+ devices being used with IGates than I have with digipeating.  Digipeating delays would be seen in the local RF environment as a digipeat being received long after a packet was actually transmitted.  Yes, it does happen, but on the -IS, the effects are usually much more visible.

And yes, there does seem to be a software-controlled digipeater using a KISS-mode KPC-3+ somewhere out in your neck of the woods!

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

On 1/21/2020 6:51 AM, Gil wrote:
Lynn,

Perhaps you could enlighten the group about the issues with using a KPC-3 as a digipeater.  I am still plagued with "late" digipeats of my mobile APRS station that place me far away from where I actually am - as I understand the issue, they place me where I was several minutes ago because they delay the digipeat long enough (past the "dup-checking" time) that the system thinks it's a new location even though it's actually a former one.  As a result, I often see my track having "retrograde" motion - I move forward and then appear to jump miles backward.  It has no apparent effect on fixed stations because they don't move, but moving stations are affected drastically by this delay.

In APRSISCE/32, these late digipeats show up as a sort of ghost icon at a former location - sometimes many miles from the actual present location of the most recent beacon.

These late digipeats, ones that have been delayed in their forwarding after being received and "handled", often delayed by several minutes, always seem to be the result of a digipeater using a KPC-3(+) unit.  I have politely tried to point this out to the digipeater owners to no avail.  Since this affects APRS users in general, and APRSISCE/32 users in particular, and since there is already a discussion of KPC-3(+) units underway, this forum might be a place to address this matter.

Gil, WB2UTI

CAUTION: This email originated from outside of USU. If this appears to be a USU employee, beware of impersonators. Do not click links, reply, download images, or open attachments unless you verify the sender’s identity and know the content is safe.
Re: Using Kantronics KPC3+ with APRSIS32

Lynn Deffenbaugh
 

Gil,

Good suggestion, but it isn't really using a KPC-3+ as a digipeater that is an issue, but using a KPC-3+ in KISS mode with upstream software doing the digipeating.

The KPC-3+ firmware does excellent digipeating as far as I know.  Provided that the digipeating is being done completely within the device itself.

There is a well documented bug in the KPC-3+ firmware's KISS support that causes received packets to be delayed in delivery out the KISS port.  This means that any software-based digipeater (or IGate for that matter) receiving KISS packets from a KPC-3+ will be marching slowly backwards in time as the delays seem to get longer and longer until the KPC-3+ is reset.

This is will documented in an article by Hessu, the author of aprs.fi, at the following link.

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

Recommended reading as well as this article:

https://packet-radio.net/kantronics-kpc3-kiss-considered-harmful/

It seems that the issue may be solved by simply tying RTS and CTS together at the KPC-3+ end of the serial cable.  But getting this word out, and worse, convincing KPC-3+ owners running in KISS mode, is an ongoing challenge.

Oh, and I've seen the issue more with KISS-mode KPC-3+ devices being used with IGates than I have with digipeating.  Digipeating delays would be seen in the local RF environment as a digipeat being received long after a packet was actually transmitted.  Yes, it does happen, but on the -IS, the effects are usually much more visible.

And yes, there does seem to be a software-controlled digipeater using a KISS-mode KPC-3+ somewhere out in your neck of the woods!

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

On 1/21/2020 6:51 AM, Gil wrote:
Lynn,

Perhaps you could enlighten the group about the issues with using a KPC-3 as a digipeater.  I am still plagued with "late" digipeats of my mobile APRS station that place me far away from where I actually am - as I understand the issue, they place me where I was several minutes ago because they delay the digipeat long enough (past the "dup-checking" time) that the system thinks it's a new location even though it's actually a former one.  As a result, I often see my track having "retrograde" motion - I move forward and then appear to jump miles backward.  It has no apparent effect on fixed stations because they don't move, but moving stations are affected drastically by this delay.

In APRSISCE/32, these late digipeats show up as a sort of ghost icon at a former location - sometimes many miles from the actual present location of the most recent beacon.

These late digipeats, ones that have been delayed in their forwarding after being received and "handled", often delayed by several minutes, always seem to be the result of a digipeater using a KPC-3(+) unit.  I have politely tried to point this out to the digipeater owners to no avail.  Since this affects APRS users in general, and APRSISCE/32 users in particular, and since there is already a discussion of KPC-3(+) units underway, this forum might be a place to address this matter.

Gil, WB2UTI
Re: Using Kantronics KPC3+ with APRSIS32

Gil
 

Lynn,

Perhaps you could enlighten the group about the issues with using a KPC-3 as a digipeater.  I am still plagued with "late" digipeats of my mobile APRS station that place me far away from where I actually am - as I understand the issue, they place me where I was several minutes ago because they delay the digipeat long enough (past the "dup-checking" time) that the system thinks it's a new location even though it's actually a former one.  As a result, I often see my track having "retrograde" motion - I move forward and then appear to jump miles backward.  It has no apparent effect on fixed stations because they don't move, but moving stations are affected drastically by this delay.

In APRSISCE/32, these late digipeats show up as a sort of ghost icon at a former location - sometimes many miles from the actual present location of the most recent beacon.

These late digipeats, ones that have been delayed in their forwarding after being received and "handled", often delayed by several minutes, always seem to be the result of a digipeater using a KPC-3(+) unit.  I have politely tried to point this out to the digipeater owners to no avail.  Since this affects APRS users in general, and APRSISCE/32 users in particular, and since there is already a discussion of KPC-3(+) units underway, this forum might be a place to address this matter.

Gil, WB2UTI
Re: soundmodem and aprsi32

Jose Manuel Martinez Barbera
 

If it works perfectly with the first agw option, tested in vhf, a question which hf frequencies and aprs modes can I use for testing


El lun., 20 ene. 2020 a las 22:44, Rob Giuliano via Groups.Io (<kb8rco=yahoo.com@groups.io>) escribió:
As far as I know, there are no special settings within APRSIS32 for HF.
UZ7HO's SoundModem application is a sofwtare based TNC and its settings take care of the HF vs. VHF/UHF settings.
  You will hvae to check the UZ7HO manual for the proper settings for HF
These are not within APRSIS32.

To interface the UZ7HO SoundModem to APRSIS32, you have 2 options:
1. AGW port over TCP/IP  
    Menu >Configure >New Port ... 
       Port Type:    AGW
       Port Name:  UZ7HO                { or your choice}
       Hit  <Create> button
    Choose <TCP/IP>
       IP or DNS:    LocalHost          {IP address of computer running SoundModem}
       Port:              8000                   {Unless you have configured a different port}
2. KISS port over TCP/IP
    Menu >Configure >New Port ... 
       Port Type:    Simply(KISS)
       Port Name:  UZ7HO                { or your choice}
       Hit  <Create> button
    Choose <TCP/IP>
       IP or DNS:    LocalHost          {IP address of computer running SoundModem}
       Port:              8100                   {Unless you have configured a different port}

Good luck - let us know how it works out.

Robert Giuliano
KB8RCO



On Monday, January 20, 2020, 12:16:00 PM EST, Jose Manuel Martinez Barbera <ea8ee1@...> wrote:




Someone has the configuration of aprs32 with soundmodem software for aprs hf
Re: Using Kantronics KPC3+ with APRSIS32

Lynn Deffenbaugh
 

When using a real TNC, there is no "correct COM port ... for PTT".  The serial port only controls protocol communication to the TNC.  The TNC's radio port handles the PTT with the radio directly, not from the computer.

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

On 1/20/2020 10:24 PM, Steve Schreiber via Groups.Io wrote:
I am trying to setup a Kantronics KPC3+ to use APRSIS32, but I am unable to get my radio to transmit. I have been using a soundcard interface to run APRSIS32 with no issues, but I would like to use my KPC3+ with a different radio setup. I have configured the port to use the correct COM port on my computer for PTT functionality, but the radio does not transmit. I searched the home page and found the following information: "Be careful of the squelched audio versus carrier detect setting (INTERNAL vs SOFTWARE on a KPC)". I am not sure where I need to go to verify this setting. Could someone please point me in the right direction? Thank you for your time.

Steve KG5LAA

Re: Using Kantronics KPC3+ with APRSIS32

George Smith <n7jjy@...>
 

I use software
N7JJY 



On Mon, Jan 20, 2020 at 8:35 PM, G Hopper
<kb7wsd@...> wrote:
I'm running a similar setup (KCP-3, no plus) and I can share what ever settings from my setup.  Just let me know what all you are looking for and I can either screen shot, or perhaps send the config file.

You can email me direct at kb7wsd@...

73,
Grant
KB7WSD

On Mon, Jan 20, 2020 at 7:24 PM Steve Schreiber via Groups.Io <skypilot_454=yahoo.com@groups.io> wrote:
I am trying to setup a Kantronics KPC3+ to use APRSIS32, but I am unable to get my radio to transmit. I have been using a soundcard interface to run APRSIS32 with no issues, but I would like to use my KPC3+ with a different radio setup. I have configured the port to use the correct COM port on my computer for PTT functionality, but the radio does not transmit. I searched the home page and found the following information: "Be careful of the squelched audio versus carrier detect setting (INTERNAL vs SOFTWARE on a KPC)". I am not sure where I need to go to verify this setting. Could someone please point me in the right direction? Thank you for your time.

Steve KG5LAA

Re: Using Kantronics KPC3+ with APRSIS32

G Hopper
 

I'm running a similar setup (KCP-3, no plus) and I can share what ever settings from my setup.  Just let me know what all you are looking for and I can either screen shot, or perhaps send the config file.

You can email me direct at kb7wsd@...

73,
Grant
KB7WSD


On Mon, Jan 20, 2020 at 7:24 PM Steve Schreiber via Groups.Io <skypilot_454=yahoo.com@groups.io> wrote:
I am trying to setup a Kantronics KPC3+ to use APRSIS32, but I am unable to get my radio to transmit. I have been using a soundcard interface to run APRSIS32 with no issues, but I would like to use my KPC3+ with a different radio setup. I have configured the port to use the correct COM port on my computer for PTT functionality, but the radio does not transmit. I searched the home page and found the following information: "Be careful of the squelched audio versus carrier detect setting (INTERNAL vs SOFTWARE on a KPC)". I am not sure where I need to go to verify this setting. Could someone please point me in the right direction? Thank you for your time.

Steve KG5LAA

Using Kantronics KPC3+ with APRSIS32

Steve Schreiber
 

I am trying to setup a Kantronics KPC3+ to use APRSIS32, but I am unable to get my radio to transmit. I have been using a soundcard interface to run APRSIS32 with no issues, but I would like to use my KPC3+ with a different radio setup. I have configured the port to use the correct COM port on my computer for PTT functionality, but the radio does not transmit. I searched the home page and found the following information: "Be careful of the squelched audio versus carrier detect setting (INTERNAL vs SOFTWARE on a KPC)". I am not sure where I need to go to verify this setting. Could someone please point me in the right direction? Thank you for your time.

Steve KG5LAA
Re: soundmodem and aprsi32

Rob Giuliano
 

As far as I know, there are no special settings within APRSIS32 for HF.
UZ7HO's SoundModem application is a sofwtare based TNC and its settings take care of the HF vs. VHF/UHF settings.
  You will hvae to check the UZ7HO manual for the proper settings for HF
These are not within APRSIS32.

To interface the UZ7HO SoundModem to APRSIS32, you have 2 options:
1. AGW port over TCP/IP  
    Menu >Configure >New Port ... 
       Port Type:    AGW
       Port Name:  UZ7HO                { or your choice}
       Hit  <Create> button
    Choose <TCP/IP>
       IP or DNS:    LocalHost          {IP address of computer running SoundModem}
       Port:              8000                   {Unless you have configured a different port}
2. KISS port over TCP/IP
    Menu >Configure >New Port ... 
       Port Type:    Simply(KISS)
       Port Name:  UZ7HO                { or your choice}
       Hit  <Create> button
    Choose <TCP/IP>
       IP or DNS:    LocalHost          {IP address of computer running SoundModem}
       Port:              8100                   {Unless you have configured a different port}

Good luck - let us know how it works out.

Robert Giuliano
KB8RCO



On Monday, January 20, 2020, 12:16:00 PM EST, Jose Manuel Martinez Barbera <ea8ee1@...> wrote:




Someone has the configuration of aprs32 with soundmodem software for aprs hf
Re: TOT resetting too soon

Lynn Deffenbaugh
 

Set the timer to zero if you don't want it.

It is very useful for the APRS-IS port because there is a certain failure mode in TCP/IP networking that can cause one end of a connection (say the APRSIS32 end) to believe the connection is alive but the other end thinks it is gone.  The connection can stay this way for a large number of minutes (remember that TCP/IP was designed to be self-healing and provides for routing packets around gaps in the network caused by nuclear elimination of major routing nodes), and sometimes the connection never realizes that it is all gone.  At least, until the confused end tries to send a packet over the connection.

In the case of mobile data networking this condition can happen when you go in and out of cellular data coverage.  And remember that APRSIS32 started as APRSISCE on Windows Mobile phones.

The Quiet Timer is also handy for some TNC/radio combinations that can drop out of KISS mode unexpectedly.  When that happens, packets quit coming through and the Quiet Time is counted.  When it is finally exceeded, the port is disabled and re-enabled causing the <Open/CloseCmd>s to be issued that will hopefully bring the port back into the proper state.  Consider Kenwood APRS radios and KISS (not Simply(KISS)) type ports when reading this.

It can be tricky to determine a suitable Quiet Timer for your APRS RF environment to avoid resetting the port unnecessarily, but that's the fun of the hobby.

But again, if you find it to be interfering with something, just set it to zero to disable it.

But I would like to know more details of your setup and what interference you are seeing!

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

On 1/20/2020 4:49 PM, Christopher Rose wrote:
Lynn, why is the software using any timers that reset anything? Seems to interfere more than help
Chris
KB8UIH



Sent from my Verizon, Samsung Galaxy smartphone


-------- Original message --------
From: Lynn Deffenbaugh <kj4erj@...>
Date: 1/20/20 4:31 PM (GMT-05:00)
Subject: Re: [APRSISCE] TOT resetting too soon

I hate to say it, but none of that seems to apply to APRSIS32?

7.64 is not a version number of APRSIS32.  Versions are date and time stamps.

Not sure what a "Kenwood rept" is, and Port one?  Kenwoods typically call them A and B, don't they?

"RF on the input"?  The input of what?  Unless "rept" is an abbreviation for Repeater?

APRSIS32 has a "Quiet Time", but not a "Time Out Timer"?  Is that what you meant?

But the Quiet Time only serves to reset the connection to a TNC in the event that no packets are received within the specified time.

And AFAIK, the Quiet Time does not have any bugs.  If reception times out, it waits the full timeout again before resetting the port.  Unless, of course, a packet is received on that port in the meantime.

Of course, it might be that this message was supposed to be directed to a Kenwood radio support group instead of APRSISCE?

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

On 1/20/2020 4:21 PM, ve7wat wrote:
We are running  ver 7.64 with a Kenwood rept on Port one ONLY.   Yesterday we encountered RF on the input that would not disappear.  the Time Out Timer (set for 300 sec) did its job and dropped the transmitter.
However even though the signal had not dropped the TOT was reset after about 10 sec (actually set for 15 sec & COS drop)and the transmitter was reactivated.  Any suggestions?

Fortunately we found the source of the RF and turned it off.

Geoff
VE7WAT/VE7HGD

Re: TOT resetting too soon

Christopher Rose
 

Lynn, why is the software using any timers that reset anything? Seems to interfere more than help
Chris
KB8UIH



Sent from my Verizon, Samsung Galaxy smartphone


-------- Original message --------
From: Lynn Deffenbaugh <kj4erj@...>
Date: 1/20/20 4:31 PM (GMT-05:00)
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] TOT resetting too soon

I hate to say it, but none of that seems to apply to APRSIS32?

7.64 is not a version number of APRSIS32.  Versions are date and time stamps.

Not sure what a "Kenwood rept" is, and Port one?  Kenwoods typically call them A and B, don't they?

"RF on the input"?  The input of what?  Unless "rept" is an abbreviation for Repeater?

APRSIS32 has a "Quiet Time", but not a "Time Out Timer"?  Is that what you meant?

But the Quiet Time only serves to reset the connection to a TNC in the event that no packets are received within the specified time.

And AFAIK, the Quiet Time does not have any bugs.  If reception times out, it waits the full timeout again before resetting the port.  Unless, of course, a packet is received on that port in the meantime.

Of course, it might be that this message was supposed to be directed to a Kenwood radio support group instead of APRSISCE?

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

On 1/20/2020 4:21 PM, ve7wat wrote:
We are running  ver 7.64 with a Kenwood rept on Port one ONLY.   Yesterday we encountered RF on the input that would not disappear.  the Time Out Timer (set for 300 sec) did its job and dropped the transmitter.
However even though the signal had not dropped the TOT was reset after about 10 sec (actually set for 15 sec & COS drop)and the transmitter was reactivated.  Any suggestions?

Fortunately we found the source of the RF and turned it off.

Geoff
VE7WAT/VE7HGD

Re: TOT resetting too soon

Lynn Deffenbaugh
 

I hate to say it, but none of that seems to apply to APRSIS32?

7.64 is not a version number of APRSIS32.  Versions are date and time stamps.

Not sure what a "Kenwood rept" is, and Port one?  Kenwoods typically call them A and B, don't they?

"RF on the input"?  The input of what?  Unless "rept" is an abbreviation for Repeater?

APRSIS32 has a "Quiet Time", but not a "Time Out Timer"?  Is that what you meant?

But the Quiet Time only serves to reset the connection to a TNC in the event that no packets are received within the specified time.

And AFAIK, the Quiet Time does not have any bugs.  If reception times out, it waits the full timeout again before resetting the port.  Unless, of course, a packet is received on that port in the meantime.

Of course, it might be that this message was supposed to be directed to a Kenwood radio support group instead of APRSISCE?

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

On 1/20/2020 4:21 PM, ve7wat wrote:
We are running  ver 7.64 with a Kenwood rept on Port one ONLY.   Yesterday we encountered RF on the input that would not disappear.  the Time Out Timer (set for 300 sec) did its job and dropped the transmitter.
However even though the signal had not dropped the TOT was reset after about 10 sec (actually set for 15 sec & COS drop)and the transmitter was reactivated.  Any suggestions?

Fortunately we found the source of the RF and turned it off.

Geoff
VE7WAT/VE7HGD

1241 - 1260 of 35243