Date   
Re: Operate aprs while listening to hf on another band is that possible?

R. Patrick Ryan
 

Eric K9LGE,

Regarding HF operation, not to my knowledge.
Technically, the Kenwood TS-2000A may be used mobile, although I haven't attempted it.

73 de Pat

Re: 'Red Dot' meaning?

Mike Heskett WB5QLD
 

Or, you could just tell you APRSISCE what your position is and turn off the GPS. It isn't a "Mobile Home", probably.

Michael Heskett
WB5QLD

-----Original Message-----
From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of KD7YZ Bob
Sent: Saturday, February 15, 2020 7:54 AM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] 'Red Dot' meaning?

Ah, thank you. Smart-Beaconing.
So since this is home and the rig on the bench, always, I need to turn off SmartBeacon ... right?

Cuz, other than Plate-Tectonics, I am not moving.
--
KD7YZ Bob EM88LL

Re: 'Red Dot' meaning?

KD7YZ Bob
 

Ah, thank you. Smart-Beaconing.
So since this is home and the rig on the bench, always, I need to turn off SmartBeacon ... right?

Cuz, other than Plate-Tectonics, I am not moving.
--
KD7YZ Bob EM88LL

Re: 'Red Dot' meaning?

Greg Depew
 

http://aprsisce.wikidot.com/doc:red-dot



Greg KB3KBR Sent from my Verizon, Samsung Galaxy smartphone



-------- Original message --------
From: KD7YZ Bob <kd7yz@...>
Date: 2/15/20 07:23 (GMT-05:00)
To: APRSISCE@groups.io
Subject: [APRSISCE] 'Red Dot' meaning?

This morning I see a red-dot, few pixels, hovering/drifting about my "ME"-House location indicator.

It's 12 degrees(f) and I am guessing some ice on the outdoor little GPS dome. might be affecting the GPS coord's.
Sometimes, down at the bottom of the window, I see mostly 51 green ....other times this AM I see a lot of Red's and oranges.
Is that the cause or meaning of a Reddish orb hanging about?

Though I see all greens (GPS Sats) now and the Red Orb is a dozen miles NE of me.

hmmmm.
--
KD7YZ Bob EM88LL



'Red Dot' meaning?

KD7YZ Bob
 

This morning I see a red-dot, few pixels, hovering/drifting about my "ME"-House location indicator.

It's 12 degrees(f) and I am guessing some ice on the outdoor little GPS dome. might be affecting the GPS coord's.
Sometimes, down at the bottom of the window, I see mostly 51 green ....other times this AM I see a lot of Red's and oranges.
Is that the cause or meaning of a Reddish orb hanging about?

Though I see all greens (GPS Sats) now and the Red Orb is a dozen miles NE of me.

hmmmm.
--
KD7YZ Bob EM88LL

Re: Operate aprs while listening to hf on another band is that possible?

Eric Lorenz K9LGE
 

Pat,

Didn't one of the older Kenwood mobile dual band radios do that as well (or had a third separate output) for APRS?

Eric

On Fri, Feb 14, 2020, 3:36 PM R. Patrick Ryan <kc6vvt@...> wrote:
For your, and this group's information, my Kenwood TS-2000A Transceiver is always available and working on 144.390 MHz FM with its internal 1200 baud TNC operating with APRSIS32 on the right hand B or SUB side, while I use the left hand A side for HF SSB contacts.
One day, had to work HF split using the A/B function, and both the MAIN A and SUB B sides displayed the two HF frequencies, yet when the APRSIS32 program sent a beacon, the TS-2000 SUB B side momentarily displayed the VHF 144.390 as it transmitted, and then reverted back to the HF frequency display.
Just verified, in VFO mode,  working VHF Split, A side 146.52, B side 146.55, and forced an APRSIS32 TRANSMIT. Same thing as above, the B side reverted to the memory APRS frequency for duration of transmit, then back to split transmit frequency of 146.55. Of course, being on same VHF band caused audio to drop out for a bit.
Amazing radio design.  73 de Pat KC6VVT





Re: Operate aprs while listening to hf on another band is that possible?

R. Patrick Ryan
 

For your, and this group's information, my Kenwood TS-2000A Transceiver is always available and working on 144.390 MHz FM with its internal 1200 baud TNC operating with APRSIS32 on the right hand B or SUB side, while I use the left hand A side for HF SSB contacts.
One day, had to work HF split using the A/B function, and both the MAIN A and SUB B sides displayed the two HF frequencies, yet when the APRSIS32 program sent a beacon, the TS-2000 SUB B side momentarily displayed the VHF 144.390 as it transmitted, and then reverted back to the HF frequency display.
Just verified, in VFO mode, working VHF Split, A side 146.52, B side 146.55, and forced an APRSIS32 TRANSMIT. Same thing as above, the B side reverted to the memory APRS frequency for duration of transmit, then back to split transmit frequency of 146.55. Of course, being on same VHF band caused audio to drop out for a bit.
Amazing radio design. 73 de Pat KC6VVT

Re: APRSIS23 HF APRS & PTC-IIex

John Brent - VA7WPN
 

I used that script, I had to change the pac1: to pac: as my PTC-IIex output is pac:, otherwise I was getting errors.

But..

Once the command "pac baud r300" is issued, when the next command "pac" or "kiss" is sent, it resets the TNC. 

But.. when I check the baud rate using "pac b" it tells me that its in R300 (Robust Packet) mode. It won't start kiss via "K", "Kiss" or "@K", or enter the packet menu without rebooting. The only way I can correct this is by using the command "pac b 1200" or any other baud rate to get out of robust packet mode.

John Brent
 VA7WPN

Re: APRSIS23 HF APRS & PTC-IIex

Lynn Deffenbaugh
 

If you use a terminal emulator, what is the prompt after entering each command manually?  That's what should follow the ! in your <Open/CloseCmd>s.  Test it on your TNC and you'll know what is correct regardless of what other people with other hardware and/or firmware might be telling you.

But those messages are not fatal, they only slow down the opening as it has to wait for the default 1 second timeout before going on.

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

On 2/13/2020 9:55 PM, John Brent - VA7WPN wrote:
This is the output from the trace(port(10.147.30))

WinMain:2020-02-14T02:44:41.877 Starting Port(10.1473)
Port(10.1473):2020-02-14T02:44:41.877 CpReader Running on COM2:9600,N,8,1 (11 OpenCmds, 3 CloseCmds)
Port(10.1473):2020-02-14T02:44:41.877 Opening COM2:9600,N,8,1
Port(10.1473):2020-02-14T02:44:41.877 Opening COM2 with 4 Args
Port(10.1473):2020-02-14T02:44:41.878 Opened COM2:9600,N,8,1, Flushing 0 in TransmitQueue, Sending 11 OpenCmds
Port(10.1473):2020-02-14T02:44:45.534 Missed Expected Response(pac1:) From Command(PAC!pac1:)
Port(10.1473):2020-02-14T02:44:47.535 Missed Expected Response(pac1:) From Command(USER 0!pac1:)
Port(10.1473):2020-02-14T02:44:49.536 Missed Expected Response(pac1:) From Command(PRBOX 0!pac1:)
Port(10.1473):2020-02-14T02:44:51.537 Missed Expected Response(pac1:) From Command(BAUD R300!pac1:)

I belive it is looking for a pac1: responce but the PTC gives a pac:. A number of people have told me that the pac1: is correct. but I am doubting that.

thank you again,

John Brent

Re: APRSIS23 HF APRS & PTC-IIex

John Brent - VA7WPN
 

This is the output from the trace(port(10.147.30))

WinMain:2020-02-14T02:44:41.877 Starting Port(10.1473)
Port(10.1473):2020-02-14T02:44:41.877 CpReader Running on COM2:9600,N,8,1 (11 OpenCmds, 3 CloseCmds)
Port(10.1473):2020-02-14T02:44:41.877 Opening COM2:9600,N,8,1
Port(10.1473):2020-02-14T02:44:41.877 Opening COM2 with 4 Args
Port(10.1473):2020-02-14T02:44:41.878 Opened COM2:9600,N,8,1, Flushing 0 in TransmitQueue, Sending 11 OpenCmds
Port(10.1473):2020-02-14T02:44:45.534 Missed Expected Response(pac1:) From Command(PAC!pac1:)
Port(10.1473):2020-02-14T02:44:47.535 Missed Expected Response(pac1:) From Command(USER 0!pac1:)
Port(10.1473):2020-02-14T02:44:49.536 Missed Expected Response(pac1:) From Command(PRBOX 0!pac1:)
Port(10.1473):2020-02-14T02:44:51.537 Missed Expected Response(pac1:) From Command(BAUD R300!pac1:)

I belive it is looking for a pac1: responce but the PTC gives a pac:. A number of people have told me that the pac1: is correct. but I am doubting that.

thank you again,

John Brent

Re: APRSIS23 HF APRS & PTC-IIex

Rob Giuliano
 

Thanks for sharing!

Yes, Windows seems to like the COMM port connection created by BlueTooth better than using the BlueTooth wizard and settings.

Robert Giuliano
KB8RCO



On Sunday, February 9, 2020, 5:49:40 AM EST, Wolfgang Bieber <oh6dl@...> wrote:


Hello Rob,

solution found - when creating a new port in APRSIS32, instead of taking the Bluetooth connection (originally I used this one, because the modem connects via Bluetooth only), I took COM-Port connection using settings of the PC serial to Bluetooth connection. Now the modem is running without problem in RPR mode controlled by APRSIS,

Thanks for your efforts!

73´s, Wolfgang - OH6DL

Re: SCS modem card TRXPTC

Wolfgang Bieber
 

Solution: although the modem connects via Bluetooth only, use COM-Port when creating a new port in APRSIS. PC settings of serial-to-Bluetooth comport applied, APRSIS32 connects and controls the modem.

Re: APRSIS23 HF APRS & PTC-IIex

Wolfgang Bieber
 

Hello Rob,

solution found - when creating a new port in APRSIS32, instead of taking the Bluetooth connection (originally I used this one, because the modem connects via Bluetooth only), I took COM-Port connection using settings of the PC serial to Bluetooth connection. Now the modem is running without problem in RPR mode controlled by APRSIS,

Thanks for your efforts!

73´s, Wolfgang - OH6DL

Re: APRSIS23 HF APRS & PTC-IIex

Rob Giuliano
 

I remember seeing something about waiting for cmd: and that it times out.
Can you post your open and close commands from the XML?
  The original ones you used that expected the cmd:, not the Simply(KISS) ones.
  I assume that is the response from the unit when in command mode?
  Couldn't find that in the manual, and I don't have one to check.
  If not, what do you see in HyperTerminal (or TeraTerm, etc.) when connected and you power up the unit and it is waiting for input?

From what i can find, I think something like this might work:
<OpenCmd>^013!cmd:!2</OpenCmd>
<OpenCmd>@K^013!cmd:!2</OpenCmd>
<CloseCmd>^192^255^192^013!cmd:!2</CloseCmd>

I release this will actually give 2 <Enter> commands (^013 and the one already provided), but I sometimes find this enusre the cmd: reply comes up.
That and setting QuietTime to 0 (at least for a day) and see if that provides any success.

The cmd: must match the response fromt he unit when waiting for input.

Robert Giuliano
KB8RCO



On Saturday, February 8, 2020, 12:12:55 PM EST, Wolfgang Bieber <oh6dl@...> wrote:


Hello Robert,

thanks for your comments. The answer to all questions is YES, the test with Simply Kiss was done with same result. However, I have been connecting today the modem using APRSDROID via Bluetooth to work in RPR as a tracker. So I assume the recommended XML file for use with APRSIS32 is not compatible.

73´s, Wolfgang - OH6DL

Re: APRSIS23 HF APRS & PTC-IIex

Wolfgang Bieber
 

Hello Robert,

thanks for your comments. The answer to all questions is YES, the test with Simply Kiss was done with same result. However, I have been connecting today the modem using APRSDROID via Bluetooth to work in RPR as a tracker. So I assume the recommended XML file for use with APRSIS32 is not compatible.

73´s, Wolfgang - OH6DL

Re: APRSIS23 HF APRS & PTC-IIex

Rob Giuliano
 

I am not familiar with the SCS TRXPTC.  Everything comes up Pactor.

However, my first question would be:
1. Is the modem capable of going into KISS mode?
   APRSIS32 expect the data coming in to be KISS

2. Second.  Is the modem capable of staying in KISS mode over power cycles?

3. Last, and most important, is the modem already in KISS mode?

A quick check would be to disable that port and create a new port on the same interface, except as Simply(KISS).
  This will send no commands and just start listening.

Also, you can set the Quiet to zero for testing.  If no data is received in the time set in QUIET, APRSIS32 will try and reset the modem.
If the radio frequency is not very active, ...

Robert Giuliano
KB8RCO



On Friday, February 7, 2020, 7:35:36 AM EST, Wolfgang Bieber <oh6dl@...> wrote:


Hello John,

I do have a quite similar difficulty with SCS card modem "TRXPTC". My observation is, that the modem is waiting for a reply to several OPEN commands and then disconnecting. I checked the Log for the relevant port and found this:

Port(5.354):2020-02-07T11:57:50.354 Missed Expected Response(cmd:) From Command(QUIT!cmd:)
Port(5.354):2020-02-07T11:57:50.354 Terminating after 60496 msec vs 60000 Quiet

Maybe you check your log as well? Is it the same/similar message showing.

73,s Wolfgang OH6DL

Re: APRSIS23 HF APRS & PTC-IIex

Wolfgang Bieber
 

Hello John,

I do have a quite similar difficulty with SCS card modem "TRXPTC". My observation is, that the modem is waiting for a reply to several OPEN commands and then disconnecting. I checked the Log for the relevant port and found this:

Port(5.354):2020-02-07T11:57:50.354 Missed Expected Response(cmd:) From Command(QUIT!cmd:)
Port(5.354):2020-02-07T11:57:50.354 Terminating after 60496 msec vs 60000 Quiet

Maybe you check your log as well? Is it the same/similar message showing.

73,s Wolfgang OH6DL

SCS modem card TRXPTC

Wolfgang Bieber
 

Hello,

is someone using this board and could possibly assist with correct XML file for use with APRSIS32? I followed instruction given by Helge, SA7SKY in the Robust Packet Network Manual (page 11), The board connects via Bluetooth to the computer when firing APRSIS32, however neither beacons are sent, nor traffic via RF possible.

After going through the CMD open/close routine, the board disconnects and switches to STBY.

To assure the board is working, I used Alpha 4.0 in Pactor mode and FSK successfully on same TRCV (IC-7200).

RPN manual as well as Port Log attached.

Thanks in advance for your thoughts.

73´s, Wolfgang OH6DL

Re: Proportional beaconing feature request

James Ewen
 

Justin,

I can see that I got so distracted by the weird paths that I forgot to look for the "has-been-digipeated bit" in the packets.

2020-02-03 17:42:42 MST: KD1ELK>SSRPQU,KE7JVX-3*,WIDE1,WIDE2-1,qAO,K7EIR-12:`'Fmo4u>/`"8/}Justins Tacoma_% 

This first packet with the incorrect mark up got me going down the wrong path.

Just about every packet after that was heard direct by W7JET-10 and gated. Because the packets all had the exact same content, I incorrectly assumed that they were duplicate packets that had been handled by a variety of digipeaters. I didn't catch the missing "has-been-digipeated bit", and incorrectly assumed the digipeaters had filled in the path elements, and not that you were manually setting fixed path elements.

I'm sure glad that your local digipeater network was not handling the packets incorrectly so as to add in hops by themselves. There are software digipeaters that can be configured to modify paths to cause this type of issue, but most of the digipeaters are Kantronics, and don't support that type of operation.
 
However, I stand by my first statement... user education, courteous operations, and a well planned and executed digipeater network are a better solution than trying to brute force your way into a network.

Proportional pathing can be a component of courteous operations if implemented properly.



James
VE6SRV


On Wed, Feb 5, 2020 at 10:02 AM James Ewen via Groups.Io <ve6srv=gmail.com@groups.io> wrote:
Justin,

If you are going to be doing tests, one of the best things you can do is to send test packets with time stamps. 

This shows the time that the packet was sent in the packet itself, and then each digipeat will have a time stamp as well. 

The list of all the packets sent from your station show identical content, which makes it look like it’s the same packet being handled multiple times. You are using a compressed packet which makes it harder for human readability. 

If you were sending the same compressed packet multiple times, and using hard coded path elements, that might explain some of what I was so confused about. 

Observing only partial results that are available on the APRS-IS can make for erroneous assumptions. 

The packets I was able to see made for a very confusing observation. I was at a loss to figure out how those various digipeaters were able to screw up handling the packet so bad. 



On Wed, Feb 5, 2020 at 9:54 AM Justin Cherington <huntjlc@...> wrote:

Thanks for the write up! Very informative. I’m aware of the state specific digipeating but need to test it out to see if it’s in place here. 

The paths that show me going to El Paso was intentional, I knew one of them was corrupting packets but didn’t know which. So I kept adding them over time until I found the culprit. 

--
James
VE6SRV

Re: Proportional beaconing feature request

James Ewen
 

Justin,

If you are going to be doing tests, one of the best things you can do is to send test packets with time stamps. 

This shows the time that the packet was sent in the packet itself, and then each digipeat will have a time stamp as well. 

The list of all the packets sent from your station show identical content, which makes it look like it’s the same packet being handled multiple times. You are using a compressed packet which makes it harder for human readability. 

If you were sending the same compressed packet multiple times, and using hard coded path elements, that might explain some of what I was so confused about. 

Observing only partial results that are available on the APRS-IS can make for erroneous assumptions. 

The packets I was able to see made for a very confusing observation. I was at a loss to figure out how those various digipeaters were able to screw up handling the packet so bad. 



On Wed, Feb 5, 2020 at 9:54 AM Justin Cherington <huntjlc@...> wrote:

Thanks for the write up! Very informative. I’m aware of the state specific digipeating but need to test it out to see if it’s in place here. 

The paths that show me going to El Paso was intentional, I knew one of them was corrupting packets but didn’t know which. So I kept adding them over time until I found the culprit. 

--
James
VE6SRV