Date   

Reply for membership from KB9YDK

Dean A. Nelson <KB9YDK@...>
 

Reply for membership from KB9YDK Dean

 

Thank you

73’s

Dean


Virus-free. www.avg.com


Re: aprsis32 and fldig kiss interface

Miguel EB5JEQ
 

OK, Lynn, thanks for your help.  I go to try  your advices, and  I  later will tell you my results.

When you have time, I tell to you my journey to the states. 

73s 


PASSWORD

Gary 2200E N6GLS
 

I have registered and have my map. I would like a password.  My name is Gary Asbury N6GLS. 



Sent from my T-Mobile 4G LTE Device


Re: Using NWS County shapefiles for other packets

Jon KM8V
 

Is there a document or guide on how to gate NWS warnings and watches out over the air?

I'm not sure how to subscribe to or receive warning or alert info from the WXSVR.

Thanks & 73 de KM8V


Re: aprsis32 and fldig kiss interface

Rob Giuliano
 

As I recall from the old KPC-3 manual and such, TNC-2 KISS is the base KISS protocol.
Later there were additions that were called XKISS and I think others extensions.

Robert Giuliano
KB8RCO



On Wednesday, April 22, 2020, 5:25:49 AM EDT, Lynn Deffenbaugh <kj4erj@...> wrote:


I don't know fldigi and how it works, but I do know that APRSIS32 doesn't do UDP/IP, but only TCP/IP.  If the labels on the various options ae to be trusted, I suspect you'll want Listen/Bind selected.  If they're checkboxes and not radio buttons, you'll also want TCP/IP checked as well and maybe AX25 Decode, although I'm not sure how that would apply to KISS.

Then, configure APRSIS32 with a Simply(KISS) type port with a TCP/IP connection to 127.0.0.1 and the port should match the I/O number box in your fldigi configuration dialog.

At least, that'd be my rank amateur guess from reading the screen.

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

PS.  I have no idea what a "TNC-2 KISS protocol" is.  Usually it's either KISS with AX.25 formatted packets or non-KISS (or telnet) TCP/IP with TNC-2 formatted (ASCII, humanly readable) packets.  I've never enountered the two packet formats in the same protocol name...

On 4/22/2020 4:52 AM, miguel.bahi@... wrote:
Hi, I want to try aprsis32 in HF 30 meters with psk63 modulation of fldigi. But no success.

I configure fldigi like this 



and I am create one port in APRSIS32 "fldigi"  device ( I try simpleKISS and KISS ), tcpip  , ip 127.0.0.1 port 7342 
But I obtain fldigi port delay. 

this is the msg of the log of this port
Port(fldigi):2020-04-22T08:01:25.448 connect(@127.0.0.1) Failed
Port(fldigi):2020-04-22T08:01:25.448 Delaying Restart for 18907/20000 msec
Port(fldigi):2020-04-22T08:01:44.463 Restarting Reader...
Port(fldigi):2020-04-22T08:01:44.463 TcpReader Running on @127.0.0.1 or 127.0.0.1:7342 (6 OpenCmds, 4 CloseCmds)
Port(fldigi):2020-04-22T08:01:45.549 connect errno 10061
Port(fldigi):2020-04-22T08:01:45.549 connect(@127.0.0.1) Failed
Port(fldigi):2020-04-22T08:01:45.549 Delaying Restart for 38914/40000 msec

Any suggestion?

thanks in advance.

73 Miguel EB5JEQ.


Re: aprsis32 and fldig kiss interface

Lynn Deffenbaugh
 

I found http://www.w1hkj.com/FldigiHelp/config_io_page.html which would seem to imply that there are two possibilities.

1) Simply(KISS) in APRSIS32 nd do NOT check AX25 Decode

2) Text port type in APRSIS32 and DO check AX25 Decode

In either case, you'll definitely want both TCP/IP and Listen/Bind checked and use the I/O number from fldigi as the Port number in APRSIS32's TCP/IP connection.  In the second case, it's not really speaking "KISS", but is actually a humanly-readable TNC-2-formatted telnet-type simple TCP/IP socket connection.  If you're good with networking, you should be able to telnet to the port in option 2 and see all the received packets.

I'm leaning toward the second option because of the following note in the AX25 Decode section.

NOTE:
When actived, only valid ax25 data will be displayed to the receive panel. No un-squelched random characters will be seen.

This would seem to imply that without AX25 decode, fldigi would be running in some sort of "PASSALL" mode whereby ALL decodes are passed through without checking the FCS checksums.  This can result in seriously corrupted packets being passed because the checksum isn't actually available to the receiving program in a KISS packet so they can't be validated by anyone but the demodulator.

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

PS.  Wow, pretty cool AX.25 CRC/FCS description for MatLab of all things!


On 4/22/2020 5:22 AM, Lynn Deffenbaugh wrote:

I don't know fldigi and how it works, but I do know that APRSIS32 doesn't do UDP/IP, but only TCP/IP.  If the labels on the various options ae to be trusted, I suspect you'll want Listen/Bind selected.  If they're checkboxes and not radio buttons, you'll also want TCP/IP checked as well and maybe AX25 Decode, although I'm not sure how that would apply to KISS.

Then, configure APRSIS32 with a Simply(KISS) type port with a TCP/IP connection to 127.0.0.1 and the port should match the I/O number box in your fldigi configuration dialog.

At least, that'd be my rank amateur guess from reading the screen.

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

PS.  I have no idea what a "TNC-2 KISS protocol" is.  Usually it's either KISS with AX.25 formatted packets or non-KISS (or telnet) TCP/IP with TNC-2 formatted (ASCII, humanly readable) packets.  I've never enountered the two packet formats in the same protocol name...

On 4/22/2020 4:52 AM, miguel.bahi@... wrote:
Hi, I want to try aprsis32 in HF 30 meters with psk63 modulation of fldigi. But no success.

I configure fldigi like this 



and I am create one port in APRSIS32 "fldigi"  device ( I try simpleKISS and KISS ), tcpip  , ip 127.0.0.1 port 7342 
But I obtain fldigi port delay. 

this is the msg of the log of this port
Port(fldigi):2020-04-22T08:01:25.448 connect(@127.0.0.1) Failed
Port(fldigi):2020-04-22T08:01:25.448 Delaying Restart for 18907/20000 msec
Port(fldigi):2020-04-22T08:01:44.463 Restarting Reader...
Port(fldigi):2020-04-22T08:01:44.463 TcpReader Running on @127.0.0.1 or 127.0.0.1:7342 (6 OpenCmds, 4 CloseCmds)
Port(fldigi):2020-04-22T08:01:45.549 connect errno 10061
Port(fldigi):2020-04-22T08:01:45.549 connect(@127.0.0.1) Failed
Port(fldigi):2020-04-22T08:01:45.549 Delaying Restart for 38914/40000 msec

Any suggestion?

thanks in advance.

73 Miguel EB5JEQ.


Re: aprsis32 and fldig kiss interface

Lynn Deffenbaugh
 

I don't know fldigi and how it works, but I do know that APRSIS32 doesn't do UDP/IP, but only TCP/IP.  If the labels on the various options ae to be trusted, I suspect you'll want Listen/Bind selected.  If they're checkboxes and not radio buttons, you'll also want TCP/IP checked as well and maybe AX25 Decode, although I'm not sure how that would apply to KISS.

Then, configure APRSIS32 with a Simply(KISS) type port with a TCP/IP connection to 127.0.0.1 and the port should match the I/O number box in your fldigi configuration dialog.

At least, that'd be my rank amateur guess from reading the screen.

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

PS.  I have no idea what a "TNC-2 KISS protocol" is.  Usually it's either KISS with AX.25 formatted packets or non-KISS (or telnet) TCP/IP with TNC-2 formatted (ASCII, humanly readable) packets.  I've never enountered the two packet formats in the same protocol name...

On 4/22/2020 4:52 AM, miguel.bahi@... wrote:
Hi, I want to try aprsis32 in HF 30 meters with psk63 modulation of fldigi. But no success.

I configure fldigi like this 



and I am create one port in APRSIS32 "fldigi"  device ( I try simpleKISS and KISS ), tcpip  , ip 127.0.0.1 port 7342 
But I obtain fldigi port delay. 

this is the msg of the log of this port
Port(fldigi):2020-04-22T08:01:25.448 connect(@127.0.0.1) Failed
Port(fldigi):2020-04-22T08:01:25.448 Delaying Restart for 18907/20000 msec
Port(fldigi):2020-04-22T08:01:44.463 Restarting Reader...
Port(fldigi):2020-04-22T08:01:44.463 TcpReader Running on @127.0.0.1 or 127.0.0.1:7342 (6 OpenCmds, 4 CloseCmds)
Port(fldigi):2020-04-22T08:01:45.549 connect errno 10061
Port(fldigi):2020-04-22T08:01:45.549 connect(@127.0.0.1) Failed
Port(fldigi):2020-04-22T08:01:45.549 Delaying Restart for 38914/40000 msec

Any suggestion?

thanks in advance.

73 Miguel EB5JEQ.


aprsis32 and fldig kiss interface

Miguel EB5JEQ
 

Hi, I want to try aprsis32 in HF 30 meters with psk63 modulation of fldigi. But no success.

I configure fldigi like this 



and I am create one port in APRSIS32 "fldigi"  device ( I try simpleKISS and KISS ), tcpip  , ip 127.0.0.1 port 7342 
But I obtain fldigi port delay. 

this is the msg of the log of this port
Port(fldigi):2020-04-22T08:01:25.448 connect(@127.0.0.1) Failed
Port(fldigi):2020-04-22T08:01:25.448 Delaying Restart for 18907/20000 msec
Port(fldigi):2020-04-22T08:01:44.463 Restarting Reader...
Port(fldigi):2020-04-22T08:01:44.463 TcpReader Running on @127.0.0.1 or 127.0.0.1:7342 (6 OpenCmds, 4 CloseCmds)
Port(fldigi):2020-04-22T08:01:45.549 connect errno 10061
Port(fldigi):2020-04-22T08:01:45.549 connect(@127.0.0.1) Failed
Port(fldigi):2020-04-22T08:01:45.549 Delaying Restart for 38914/40000 msec

Any suggestion?

thanks in advance.

73 Miguel EB5JEQ.


Re: Nickname File Transfer

Lynn Deffenbaugh
 

Interesting thought, but not currently implemented, of course.  And it's not quite as easy as it might sound given that I'm using a pre-packaged lua XML reader/interpreter and that's not part of the native XML spec.

What would end up happening is that the <include>...</include> value would simply come through as an element in the parsed XML which the APRSIS32 XML processor would summarily ignore and drop on the floor on the next save.

I'll give it some thought though...

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

On 4/19/2020 11:19 AM, Rob Giuliano via groups.io wrote:
Lynn,
Is adding an 'include" (<Include>{path and xml file name}</include>) into the main xml as a means of doing simple things like this?
I realize this would make it a pain when saving the XML, a simple expansion and write out as a single file would even work as a short term fix.

Robert Giuliano
KB8RCO



On Saturday, April 18, 2020, 7:11:14 PM EDT, Bob KE6GYD <ke6gyd@...> wrote:


Our group has over 100 nicknames set up on my computer.  Is there a file containing those nicknames that can be transferred to other members computers so they don't have to recreate them all?
73
Bob
KE6GYD  


Re: Nickname File Transfer

Rob Giuliano
 

Lynn,
Is adding an 'include" (<Include>{path and xml file name}</include>) into the main xml as a means of doing simple things like this?
I realize this would make it a pain when saving the XML, a simple expansion and write out as a single file would even work as a short term fix.

Robert Giuliano
KB8RCO



On Saturday, April 18, 2020, 7:11:14 PM EDT, Bob KE6GYD <ke6gyd@...> wrote:


Our group has over 100 nicknames set up on my computer.  Is there a file containing those nicknames that can be transferred to other members computers so they don't have to recreate them all?
73
Bob
KE6GYD  


Re: Igate verification

Lynn Deffenbaugh
 

Glad to know it's all working now!  Ever the simple things trip us up.

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

On 4/19/2020 1:24 AM, Yatharth Verma via groups.io wrote:
Hi,
Indeed, Xmit was disabled on the APRS-IS port. After enabling fresh packets are being Igated. I verified this using the Igate trace log. Moreover, the packet entry made it to aprs.fi as well '2020-04-19 07:17:55 IST: RS0ISS>CQ,qAR,VU3NUF-10:>ARISS - International Space Station'.

Thank you Lynn for the quick help.

Best regards,
Yatharth
VU3NUF



On Thursday, April 16, 2020, 11:53:37 PM GMT+5:30, Lynn Deffenbaugh <kj4erj@...> wrote:


Check your Configure / Ports / APRS-IS.  I suspect you have Xmit disabled on that port which completely disables transmitting anything to the APRS-IS, including IGate packets.  Or at least you had it disabled when that packet was received and that log was generated.

You might find it beneficial to tune your radio to your local APRS frequency until we can ascertain that your IGate is working properly with all the settings.  At least there, you might get more packets received than waiting for a satellite pass.  Especially if you can generate your own APRS packets from another local radio.

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

On 4/16/2020 12:46 PM, Yatharth Verma via groups.io wrote:
Hi,
Thanks for the quick reply! I checked for Igate logs under view logs. There were 2 logs Igate(not) & Igate enabled. The Igate enabled one showed:
WinMain:2020-04-16T14:21:17.539 UZ7HO[AGW] IGating Receive-Only
WinMain:2020-04-16T14:21:17.539 ***** IGate Enabled Receive-Only *****

and the Igate(not) showed this entry:
WinMain:2020-04-16T10:42:53.908 RFtoIS:    !Xmit(APRS-IS)  (RS0ISS>CQ:>ARISS - International Space Station)
I didn't understand what Igate(not) means

Also, I checked the trace log of Packets which I suppose should show all the packets displayed in the scroller and it showed:
2020-04-16T10:42:53.908 RF[UZ7HO][1200] RS0ISS>CQ:>ARISS - International Space Station

So does it mean that the packet was Igated?

Regarding aprs.fi - till the time I received this packet from ISS I was using the callsign VU3NUF but I tweaked the settings a little bit today and added a suffix VU3NUF-10, but it was hours after receiving the packet.

Best regards,
Yatharth
VU3NUF

On Thursday, April 16, 2020, 08:43:00 PM GMT+5:30, Lynn Deffenbaugh <kj4erj@...> wrote:


Look under Enables / View Log for any IGate* logs.  Bring each of those up and enable it.  One of them should tell you whether or not packets are being gated to the APRS-IS.

However, those are not "CQ" packets from the ISS.  That's actually the ToCall or UnProto piece.  The packet is from RS0ISS (the first part before the >) with a destination (ToCall/UnProto) of CQ (the part after the > until either a comma or colon).  It has an empty path (colon immediately follows ToCall with no commas) and is actually a status packet (the > after the colon).  Therefore it has no location (the ISS never actually says where it is), so it will show up on your map at 0,0 or at the Null Island.

But one of the IGate* trace logs should be able to answer your question.

Well, sort of.  Your question was whether the packet is "reaching aprs.fi", but that is not under APRSIS32's direct control.  APRSIS32 is only responsible for delivering gated packets to your immediate upstream (directly connected) APRS-IS server.  Whether your packet actually gets distributed, and how far, through the APRS-IS is dependent on timing and the duplicate suppression rules of the APRS-IS servers.

A quick check at https://aprs.fi/?c=raw&call=RS0ISS&limit=1000&view=normal doesn't show anything from VU3NUF, which I assume (possibly incorrectly) is the callsign under which you are running APRSIS32?

Remember, aprs.fi is simply (albeit quite complex actually) a database capturing and displaying data from the APRS-IS as well as several other sources.  It is NOT the APRS-IS network.

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

On 4/16/2020 10:55 AM, Yatharth Verma via groups.io wrote:
Greetings..from India!

I have just started using APRSIS32 again after a hiatus of 2 years, therefore there is something which I need to seek help for.

First of all, about my installation:

1. Intel i5 CPU with 4 GB RAM
2. Windows 8.1 operating system
3. RTL-SDR radio dongle for RX with UZ&HO sound modem (working correctly)
4. Homebrewed QFH antenna

Now my problem:
I am receiving APRS CQ packets from an ISS pass correctly. I say correctly since it gets displayed on the sound modem screen (text pasted below):

1:Fm RS0ISS To CQ <UI R Pid=F0 Len=36> [16:12:53R] [+++]
>ARISS - International Space Station

This also reaches APRSIS32 in the log of the sound modem port:
Port(UZ7HO):2020-04-16T10:42:53.908 AGW:AX.25[0] RS0ISS>CQ:>ARISS - International Space Station

But I am unable to verify (rather I don't know how to verify), whether this packet is being Igated or not. Please help me find out this. And also whether it is reaching aprs.fi or not?

I shall be grateful for any help.

Best regards,
Yatharth
VU3NUF


Re: Igate verification

Yatharth Verma
 

Hi,
Indeed, Xmit was disabled on the APRS-IS port. After enabling fresh packets are being Igated. I verified this using the Igate trace log. Moreover, the packet entry made it to aprs.fi as well '2020-04-19 07:17:55 IST: RS0ISS>CQ,qAR,VU3NUF-10:>ARISS - International Space Station'.

Thank you Lynn for the quick help.

Best regards,
Yatharth
VU3NUF



On Thursday, April 16, 2020, 11:53:37 PM GMT+5:30, Lynn Deffenbaugh <kj4erj@...> wrote:


Check your Configure / Ports / APRS-IS.  I suspect you have Xmit disabled on that port which completely disables transmitting anything to the APRS-IS, including IGate packets.  Or at least you had it disabled when that packet was received and that log was generated.

You might find it beneficial to tune your radio to your local APRS frequency until we can ascertain that your IGate is working properly with all the settings.  At least there, you might get more packets received than waiting for a satellite pass.  Especially if you can generate your own APRS packets from another local radio.

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

On 4/16/2020 12:46 PM, Yatharth Verma via groups.io wrote:
Hi,
Thanks for the quick reply! I checked for Igate logs under view logs. There were 2 logs Igate(not) & Igate enabled. The Igate enabled one showed:
WinMain:2020-04-16T14:21:17.539 UZ7HO[AGW] IGating Receive-Only
WinMain:2020-04-16T14:21:17.539 ***** IGate Enabled Receive-Only *****

and the Igate(not) showed this entry:
WinMain:2020-04-16T10:42:53.908 RFtoIS:    !Xmit(APRS-IS)  (RS0ISS>CQ:>ARISS - International Space Station)
I didn't understand what Igate(not) means

Also, I checked the trace log of Packets which I suppose should show all the packets displayed in the scroller and it showed:
2020-04-16T10:42:53.908 RF[UZ7HO][1200] RS0ISS>CQ:>ARISS - International Space Station

So does it mean that the packet was Igated?

Regarding aprs.fi - till the time I received this packet from ISS I was using the callsign VU3NUF but I tweaked the settings a little bit today and added a suffix VU3NUF-10, but it was hours after receiving the packet.

Best regards,
Yatharth
VU3NUF

On Thursday, April 16, 2020, 08:43:00 PM GMT+5:30, Lynn Deffenbaugh <kj4erj@...> wrote:


Look under Enables / View Log for any IGate* logs.  Bring each of those up and enable it.  One of them should tell you whether or not packets are being gated to the APRS-IS.

However, those are not "CQ" packets from the ISS.  That's actually the ToCall or UnProto piece.  The packet is from RS0ISS (the first part before the >) with a destination (ToCall/UnProto) of CQ (the part after the > until either a comma or colon).  It has an empty path (colon immediately follows ToCall with no commas) and is actually a status packet (the > after the colon).  Therefore it has no location (the ISS never actually says where it is), so it will show up on your map at 0,0 or at the Null Island.

But one of the IGate* trace logs should be able to answer your question.

Well, sort of.  Your question was whether the packet is "reaching aprs.fi", but that is not under APRSIS32's direct control.  APRSIS32 is only responsible for delivering gated packets to your immediate upstream (directly connected) APRS-IS server.  Whether your packet actually gets distributed, and how far, through the APRS-IS is dependent on timing and the duplicate suppression rules of the APRS-IS servers.

A quick check at https://aprs.fi/?c=raw&call=RS0ISS&limit=1000&view=normal doesn't show anything from VU3NUF, which I assume (possibly incorrectly) is the callsign under which you are running APRSIS32?

Remember, aprs.fi is simply (albeit quite complex actually) a database capturing and displaying data from the APRS-IS as well as several other sources.  It is NOT the APRS-IS network.

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

On 4/16/2020 10:55 AM, Yatharth Verma via groups.io wrote:
Greetings..from India!

I have just started using APRSIS32 again after a hiatus of 2 years, therefore there is something which I need to seek help for.

First of all, about my installation:

1. Intel i5 CPU with 4 GB RAM
2. Windows 8.1 operating system
3. RTL-SDR radio dongle for RX with UZ&HO sound modem (working correctly)
4. Homebrewed QFH antenna

Now my problem:
I am receiving APRS CQ packets from an ISS pass correctly. I say correctly since it gets displayed on the sound modem screen (text pasted below):

1:Fm RS0ISS To CQ <UI R Pid=F0 Len=36> [16:12:53R] [+++]
>ARISS - International Space Station

This also reaches APRSIS32 in the log of the sound modem port:
Port(UZ7HO):2020-04-16T10:42:53.908 AGW:AX.25[0] RS0ISS>CQ:>ARISS - International Space Station

But I am unable to verify (rather I don't know how to verify), whether this packet is being Igated or not. Please help me find out this. And also whether it is reaching aprs.fi or not?

I shall be grateful for any help.

Best regards,
Yatharth
VU3NUF


Re: Nickname File Transfer

Fred Hillhouse
 

I don’t believe there is a direct way to transfer them. However, You may be able to copy them from your .xml and paste them in the others.

 

Be sure to back up your xml files first. It might take several tries. Of course any modification will have to be done while APRSIS32 is NOT running.

 

Fred N7FMH

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Bob KE6GYD
Sent: Saturday, April 18, 2020 7:11 PM
To: APRSISCE@groups.io
Subject: [APRSISCE] Nickname File Transfer

 

Our group has over 100 nicknames set up on my computer.  Is there a file containing those nicknames that can be transferred to other members computers so they don't have to recreate them all?
73
Bob
KE6GYD  




Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com



Nickname File Transfer

Bob KE6GYD
 

Our group has over 100 nicknames set up on my computer.  Is there a file containing those nicknames that can be transferred to other members computers so they don't have to recreate them all?
73
Bob
KE6GYD  


Re: Igate verification

Lynn Deffenbaugh
 

Check your Configure / Ports / APRS-IS.  I suspect you have Xmit disabled on that port which completely disables transmitting anything to the APRS-IS, including IGate packets.  Or at least you had it disabled when that packet was received and that log was generated.

You might find it beneficial to tune your radio to your local APRS frequency until we can ascertain that your IGate is working properly with all the settings.  At least there, you might get more packets received than waiting for a satellite pass.  Especially if you can generate your own APRS packets from another local radio.

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

On 4/16/2020 12:46 PM, Yatharth Verma via groups.io wrote:
Hi,
Thanks for the quick reply! I checked for Igate logs under view logs. There were 2 logs Igate(not) & Igate enabled. The Igate enabled one showed:
WinMain:2020-04-16T14:21:17.539 UZ7HO[AGW] IGating Receive-Only
WinMain:2020-04-16T14:21:17.539 ***** IGate Enabled Receive-Only *****

and the Igate(not) showed this entry:
WinMain:2020-04-16T10:42:53.908 RFtoIS:    !Xmit(APRS-IS)  (RS0ISS>CQ:>ARISS - International Space Station)
I didn't understand what Igate(not) means

Also, I checked the trace log of Packets which I suppose should show all the packets displayed in the scroller and it showed:
2020-04-16T10:42:53.908 RF[UZ7HO][1200] RS0ISS>CQ:>ARISS - International Space Station

So does it mean that the packet was Igated?

Regarding aprs.fi - till the time I received this packet from ISS I was using the callsign VU3NUF but I tweaked the settings a little bit today and added a suffix VU3NUF-10, but it was hours after receiving the packet.

Best regards,
Yatharth
VU3NUF

On Thursday, April 16, 2020, 08:43:00 PM GMT+5:30, Lynn Deffenbaugh <kj4erj@...> wrote:


Look under Enables / View Log for any IGate* logs.  Bring each of those up and enable it.  One of them should tell you whether or not packets are being gated to the APRS-IS.

However, those are not "CQ" packets from the ISS.  That's actually the ToCall or UnProto piece.  The packet is from RS0ISS (the first part before the >) with a destination (ToCall/UnProto) of CQ (the part after the > until either a comma or colon).  It has an empty path (colon immediately follows ToCall with no commas) and is actually a status packet (the > after the colon).  Therefore it has no location (the ISS never actually says where it is), so it will show up on your map at 0,0 or at the Null Island.

But one of the IGate* trace logs should be able to answer your question.

Well, sort of.  Your question was whether the packet is "reaching aprs.fi", but that is not under APRSIS32's direct control.  APRSIS32 is only responsible for delivering gated packets to your immediate upstream (directly connected) APRS-IS server.  Whether your packet actually gets distributed, and how far, through the APRS-IS is dependent on timing and the duplicate suppression rules of the APRS-IS servers.

A quick check at https://aprs.fi/?c=raw&call=RS0ISS&limit=1000&view=normal doesn't show anything from VU3NUF, which I assume (possibly incorrectly) is the callsign under which you are running APRSIS32?

Remember, aprs.fi is simply (albeit quite complex actually) a database capturing and displaying data from the APRS-IS as well as several other sources.  It is NOT the APRS-IS network.

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

On 4/16/2020 10:55 AM, Yatharth Verma via groups.io wrote:
Greetings..from India!

I have just started using APRSIS32 again after a hiatus of 2 years, therefore there is something which I need to seek help for.

First of all, about my installation:

1. Intel i5 CPU with 4 GB RAM
2. Windows 8.1 operating system
3. RTL-SDR radio dongle for RX with UZ&HO sound modem (working correctly)
4. Homebrewed QFH antenna

Now my problem:
I am receiving APRS CQ packets from an ISS pass correctly. I say correctly since it gets displayed on the sound modem screen (text pasted below):

1:Fm RS0ISS To CQ <UI R Pid=F0 Len=36> [16:12:53R] [+++]
>ARISS - International Space Station

This also reaches APRSIS32 in the log of the sound modem port:
Port(UZ7HO):2020-04-16T10:42:53.908 AGW:AX.25[0] RS0ISS>CQ:>ARISS - International Space Station

But I am unable to verify (rather I don't know how to verify), whether this packet is being Igated or not. Please help me find out this. And also whether it is reaching aprs.fi or not?

I shall be grateful for any help.

Best regards,
Yatharth
VU3NUF


Re: Igate verification

Yatharth Verma
 

Hi,
Thanks for the quick reply! I checked for Igate logs under view logs. There were 2 logs Igate(not) & Igate enabled. The Igate enabled one showed:
WinMain:2020-04-16T14:21:17.539 UZ7HO[AGW] IGating Receive-Only
WinMain:2020-04-16T14:21:17.539 ***** IGate Enabled Receive-Only *****

and the Igate(not) showed this entry:
WinMain:2020-04-16T10:42:53.908 RFtoIS:    !Xmit(APRS-IS)  (RS0ISS>CQ:>ARISS - International Space Station)
I didn't understand what Igate(not) means

Also, I checked the trace log of Packets which I suppose should show all the packets displayed in the scroller and it showed:
2020-04-16T10:42:53.908 RF[UZ7HO][1200] RS0ISS>CQ:>ARISS - International Space Station

So does it mean that the packet was Igated?

Regarding aprs.fi - till the time I received this packet from ISS I was using the callsign VU3NUF but I tweaked the settings a little bit today and added a suffix VU3NUF-10, but it was hours after receiving the packet.

Best regards,
Yatharth
VU3NUF

On Thursday, April 16, 2020, 08:43:00 PM GMT+5:30, Lynn Deffenbaugh <kj4erj@...> wrote:


Look under Enables / View Log for any IGate* logs.  Bring each of those up and enable it.  One of them should tell you whether or not packets are being gated to the APRS-IS.

However, those are not "CQ" packets from the ISS.  That's actually the ToCall or UnProto piece.  The packet is from RS0ISS (the first part before the >) with a destination (ToCall/UnProto) of CQ (the part after the > until either a comma or colon).  It has an empty path (colon immediately follows ToCall with no commas) and is actually a status packet (the > after the colon).  Therefore it has no location (the ISS never actually says where it is), so it will show up on your map at 0,0 or at the Null Island.

But one of the IGate* trace logs should be able to answer your question.

Well, sort of.  Your question was whether the packet is "reaching aprs.fi", but that is not under APRSIS32's direct control.  APRSIS32 is only responsible for delivering gated packets to your immediate upstream (directly connected) APRS-IS server.  Whether your packet actually gets distributed, and how far, through the APRS-IS is dependent on timing and the duplicate suppression rules of the APRS-IS servers.

A quick check at https://aprs.fi/?c=raw&call=RS0ISS&limit=1000&view=normal doesn't show anything from VU3NUF, which I assume (possibly incorrectly) is the callsign under which you are running APRSIS32?

Remember, aprs.fi is simply (albeit quite complex actually) a database capturing and displaying data from the APRS-IS as well as several other sources.  It is NOT the APRS-IS network.

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

On 4/16/2020 10:55 AM, Yatharth Verma via groups.io wrote:
Greetings..from India!

I have just started using APRSIS32 again after a hiatus of 2 years, therefore there is something which I need to seek help for.

First of all, about my installation:

1. Intel i5 CPU with 4 GB RAM
2. Windows 8.1 operating system
3. RTL-SDR radio dongle for RX with UZ&HO sound modem (working correctly)
4. Homebrewed QFH antenna

Now my problem:
I am receiving APRS CQ packets from an ISS pass correctly. I say correctly since it gets displayed on the sound modem screen (text pasted below):

1:Fm RS0ISS To CQ <UI R Pid=F0 Len=36> [16:12:53R] [+++]
>ARISS - International Space Station

This also reaches APRSIS32 in the log of the sound modem port:
Port(UZ7HO):2020-04-16T10:42:53.908 AGW:AX.25[0] RS0ISS>CQ:>ARISS - International Space Station

But I am unable to verify (rather I don't know how to verify), whether this packet is being Igated or not. Please help me find out this. And also whether it is reaching aprs.fi or not?

I shall be grateful for any help.

Best regards,
Yatharth
VU3NUF


Re: Igate verification

Lynn Deffenbaugh
 

Look under Enables / View Log for any IGate* logs.  Bring each of those up and enable it.  One of them should tell you whether or not packets are being gated to the APRS-IS.

However, those are not "CQ" packets from the ISS.  That's actually the ToCall or UnProto piece.  The packet is from RS0ISS (the first part before the >) with a destination (ToCall/UnProto) of CQ (the part after the > until either a comma or colon).  It has an empty path (colon immediately follows ToCall with no commas) and is actually a status packet (the > after the colon).  Therefore it has no location (the ISS never actually says where it is), so it will show up on your map at 0,0 or at the Null Island.

But one of the IGate* trace logs should be able to answer your question.

Well, sort of.  Your question was whether the packet is "reaching aprs.fi", but that is not under APRSIS32's direct control.  APRSIS32 is only responsible for delivering gated packets to your immediate upstream (directly connected) APRS-IS server.  Whether your packet actually gets distributed, and how far, through the APRS-IS is dependent on timing and the duplicate suppression rules of the APRS-IS servers.

A quick check at https://aprs.fi/?c=raw&call=RS0ISS&limit=1000&view=normal doesn't show anything from VU3NUF, which I assume (possibly incorrectly) is the callsign under which you are running APRSIS32?

Remember, aprs.fi is simply (albeit quite complex actually) a database capturing and displaying data from the APRS-IS as well as several other sources.  It is NOT the APRS-IS network.

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

On 4/16/2020 10:55 AM, Yatharth Verma via groups.io wrote:
Greetings..from India!

I have just started using APRSIS32 again after a hiatus of 2 years, therefore there is something which I need to seek help for.

First of all, about my installation:

1. Intel i5 CPU with 4 GB RAM
2. Windows 8.1 operating system
3. RTL-SDR radio dongle for RX with UZ&HO sound modem (working correctly)
4. Homebrewed QFH antenna

Now my problem:
I am receiving APRS CQ packets from an ISS pass correctly. I say correctly since it gets displayed on the sound modem screen (text pasted below):

1:Fm RS0ISS To CQ <UI R Pid=F0 Len=36> [16:12:53R] [+++]
>ARISS - International Space Station

This also reaches APRSIS32 in the log of the sound modem port:
Port(UZ7HO):2020-04-16T10:42:53.908 AGW:AX.25[0] RS0ISS>CQ:>ARISS - International Space Station

But I am unable to verify (rather I don't know how to verify), whether this packet is being Igated or not. Please help me find out this. And also whether it is reaching aprs.fi or not?

I shall be grateful for any help.

Best regards,
Yatharth
VU3NUF


Igate verification

Yatharth Verma
 

Greetings..from India!

I have just started using APRSIS32 again after a hiatus of 2 years, therefore there is something which I need to seek help for.

First of all, about my installation:

1. Intel i5 CPU with 4 GB RAM
2. Windows 8.1 operating system
3. RTL-SDR radio dongle for RX with UZ&HO sound modem (working correctly)
4. Homebrewed QFH antenna

Now my problem:
I am receiving APRS CQ packets from an ISS pass correctly. I say correctly since it gets displayed on the sound modem screen (text pasted below):

1:Fm RS0ISS To CQ <UI R Pid=F0 Len=36> [16:12:53R] [+++]
>ARISS - International Space Station

This also reaches APRSIS32 in the log of the sound modem port:
Port(UZ7HO):2020-04-16T10:42:53.908 AGW:AX.25[0] RS0ISS>CQ:>ARISS - International Space Station

But I am unable to verify (rather I don't know how to verify), whether this packet is being Igated or not. Please help me find out this. And also whether it is reaching aprs.fi or not?

I shall be grateful for any help.

Best regards,
Yatharth
VU3NUF


Re: Mobile stations

Jack L. Blake Sr (AI4LL)
 

Same here in South West VIrginia. APRS traffic lighter than normal


Re: Mobile stations

Russ Marsolek
 

Minnesota is about $1.30 today.

 

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Gurdon Wolfe via groups.io
Sent: Wednesday, April 15, 2020 1:07 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Mobile stations

 

    Same in the Space Coast (Brevard County) of Florida with gas selling at $1.84 a gallon too.

 

 73, Don

 W4GCW

 

 

y To Group | Mute This Topic | New Topic

 

Log In

 

Unsubscribe

 

1461 - 1480 of 35661