Date   

Re: APRSIS

Fred Hillhouse
 

I had a RS232 GPS and I had used an USB/RS232 converter. In the PC, it shows up on a virtual COM port.

Can you do that with the DeLorme GPS?

 

Fred N7FMH

 

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Don Eklund
Sent: Wednesday, May 06, 2020 1:35 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] APRSIS

 

Fred. How are you mapping a USB port to a computer port?

 

I ha e a couple of Delorme GPS that I would l I keep to use with apps win 32..

 

 

 

Sent from my Verizon, Samsung Galaxy smartphone

 

 

-------- Original message --------

From: Fred Hillhouse <fmhillhouse@...>

Date: 5/6/20 1:31 PM (GMT-05:00)

To: APRSISCE@groups.io

Subject: Re: [APRSISCE] APRSIS

 

Are you using a GPS connected to an USB port? If yes, is it mapped to a COM port? Is it now on a different COM port? I have had this issue before.

Fred N7FMH




Avast logo

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



Re: APRSIS

ve6tdx
 

No that is checked.
I am using the kenwood 710 with a garmin Montana GPS unit. It worked fine until the update. GPS is enabled as checked off.
Adrian ve6tdx

On Wed., May 6, 2020, 11:14 Fred Hillhouse, <fmhillhouse@...> wrote:
I think it is this setting:
Toolbar > Configure > Screen > Speed size
Is it unchecked? If so, add a check.

Fred N7FMH


Re: APRSIS

Don Eklund
 

Fred. How are you mapping a USB port to a computer port?

I ha e a couple of Delorme GPS that I would l I keep to use with apps win 32..



Sent from my Verizon, Samsung Galaxy smartphone


-------- Original message --------
From: Fred Hillhouse <fmhillhouse@...>
Date: 5/6/20 1:31 PM (GMT-05:00)
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] APRSIS

Are you using a GPS connected to an USB port? If yes, is it mapped to a COM port? Is it now on a different COM port? I have had this issue before.

Fred N7FMH


Re: APRSIS

Lynn Deffenbaugh
 

What GPS do you have connected to APRSIS32?

Are the parameters to access it still correct in Configure / Ports / NMEA?

Is Enables / GPS Enabled checked?

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

On 5/6/2020 1:10 PM, ve6tdx wrote:
To the group.
I just updated my aprsis on my computer in the car. But now I don't see my GPS or speed on the screen. I didn't make any changes from setting from my old settings. Thanks in advance. 
Adrian VE6TDX.


Re: APRSIS

Fred Hillhouse
 

Are you using a GPS connected to an USB port? If yes, is it mapped to a COM port? Is it now on a different COM port? I have had this issue before.

Fred N7FMH


Re: APRSIS

Fred Hillhouse
 

I think it is this setting:
Toolbar > Configure > Screen > Speed size
Is it unchecked? If so, add a check.

Fred N7FMH


Re: APRSIS

ve6tdx
 

To the group.
I just updated my aprsis on my computer in the car. But now I don't see my GPS or speed on the screen. I didn't make any changes from setting from my old settings. Thanks in advance. 
Adrian VE6TDX.


Re: Proposed General Release (Dev: 2020/05/01 21:21)

Lynn Deffenbaugh
 

Thank you for the updated Wiki.  To borrow from Sgt. Schultz, "I know nothing" about WINE and *nix, although I did follow the Wiki description to set up my son-in-law's IGate (KN4EOG-10).

Hopefully someone that knows and has experienced the WINE upgrade will be able to read it and comment.

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

On 5/6/2020 9:00 AM, Rob Giuliano via groups.io wrote:
I updated the WIKI on this subject.
  There are 2 sections now -> Pre WINE 2.8 (same info as before: WINE Registry) and Post WINE 2.8 (updated for USB devices: reassign existing Ports). 

Unfortunately, the explanation is a bit wordy.  If you are familar with Linux and WINE, please take a look and provide any feedback.

I have 3 TNCs that connect through USB devices, and I have successfully changed TNCs with APRSIS32 matching the COM port for each.  In my case, each USB interface had a unique Vendor and Product code. 

My one comment about the updated WINE versions is:
"The good news is that you no longer have to mess with the Registry (which can cause other problems).  Older WINE versions had a pretty simple registry, but the newer versions are much more Windows like."

Robert Giuliano
KB8RCO



On Saturday, May 2, 2020, 12:57:42 PM EDT, Rob Giuliano via groups.io <kb8rco@...> wrote:


I would argue their purpose was to ensure anything Linux 'sees' is mapped to WINE.
Why does Linux have
    tty - okay I know this one!
    tty0 - tty63
    ttyS0 - ttyS32
when only a few devices are actually present?
Isn't that what things like udev are for?

I will be doing a little investigating into possibly deleting some of these nonexistent devices and see if that cuts down what WINE sees.

Robert Giuliano
KB8RCO



On Saturday, May 2, 2020, 12:25:44 PM EDT, Greg D <ko6th.greg@...> wrote:


Hi Rob,

It sounds like the Wine team is trying to be annoyance-for-annoyance compatible with Windows :(. 

I'm on Wine 1.8.6 on an old OpenSuSE LEAP 42.1 system, and the upgrade to the latest went without a hitch.  It's an iGate that I run 24x7, and all is working fine.  Thanks for the "heads-up" for the future when I eventually upgrade the system.

Greg  KO6TH


Rob Giuliano via groups.io wrote:
I'll try a few more things and update the wiki - soon.

Robert Giuliano
KB8RCO



On Saturday, May 2, 2020, 10:36:15 AM EDT, Rob Giuliano via groups.io <kb8rco@...> wrote:


As near as I can tell, there is something in the WINE setup that automatically (and "unchangeably") links every ttyS## device in /dev to a com## in the .wine folder.  Linux (at least my XUbuntu) has ttyS0 - ttyS32.  Each USB serial device is added after that. 

Good news is that APRSIS32 "sees" all 33 (in my case) serial ports.  The bad news of course is that there is no guarantee of the USB order if you have more than 1 USB serial device.

Through investigation, I learned that udev rules can reallocate any of these com# device to a symlink device link other than an ttyS#, BUT WINE changes them back.  However, udev rule CAN override an existing device (with no hardware), that worked for me.  My desktop has 1 physical serial port on ttyS0 (com1), so I can reallocate any ttyS# with # > 0.  Just remember that COM# ports start with 1 and ttyS# devices start with 0 (zero), so my override of ttyS3 became com4.  A section of my udev rules file in /etc/udev/rules.d called 65-tnc.rules:

#65-tnc.rules
# TNC-X
# SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="tncx"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="ttyS3"

I have a line for each TNC device I connect, including some for Bluetooth connections, but I haven't tested those with WINE 5.0 yet.

Robert Giuliano
KB8RCO



On Saturday, May 2, 2020, 8:58:33 AM EDT, Michael Coslo via groups.io <mjc_n3li@...> wrote:


Hi Rob,

WINES’s handling of com ports flummoxed me. What used to be a simple symbolic link became something else indeed  ver 2.8 and later. The people at Codeweavers tried to help, but they had instructions for Mac, which were different enough that it didn’t work for me.

Needing my station up and running, I ended up removing Mint and reinstalling Windows 8.1, which is just too cruel! 8^)

When I’m not pressed for time, I’ll reinstall mint and try again.

But you might have the secret sauce for getting new versions of WINE to do the link?

Otherwise I might try again with an old version of WINE.

- 73 Mike N3LI -


> On May 2, 2020, at 12:56 AM, Rob Giuliano via groups.io <kb8rco=yahoo.com@groups.io> wrote:
>
> Just upgraded my setup.  This includes latest XUbuntu (20.04) with WINE 5.0.
> Some features are new to me with the updated WINE version.
>
> APRSIS32 ran the normal update after clicking HELP.
> Other than connecting to my TNC (WINE changed COM port stuff), NO ISSUES here!
>
> I'll let it run now.
> Robert Giuliano
> KB8RCO
>
>
>
> On Friday, May 1, 2020, 10:02:06 PM EDT, Lynn Deffenbaugh <kj4erj@...> wrote:
>
>
> I just pushed the subject version to development.  Please let me know if
> you successfully upgrade to this and if it initially looks ok.
>
> The only change since the last Development release is a spelling
> correction, changing the name for APRSISMO (check KJ4ERJ-12), and
> setting the new release timestamp.
>
> If this checks out, I'll push it to release sometime over the weekend.
>
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>
> Here are the proposed release notes.  They will be posted in full to the
> Wiki.
>
> Here's the major features in version 2020/05/01 21:21
>
> Updated ToCall and Mic-E definitions from:
> http://www.aprs.org/aprs11/tocalls.txt as of 17 Apr 2020 (updated
> 2020/04/27)
> http://aprs.org/aprs12/mic-e-types.txt through 4 Jun 2019 (Updated
> 2020/04/27)
>
> No longer suppress gating messages just because a station was heard
> INSIDE a 3rd party packet on RF.  See notes about KO6TH from 2018/09/03
> 11:36
>
> Support "Common Talker IDs" from
> http://www.catb.org/gpsd/NMEA.html#_talker_ids. See notes from
> 2017/07/17 15:05
>
> Support Always-On-Top in right click menu in both main and MultiTrack
> windows (not on CE)
>
> Support proprietary 4 digit precision extension (!DAO!xx) in Configure /
> Beacon / Precision / 4 Digits
>
> Draw a small heading arrow near symbols that beacon speed and course
>
> Support a Syslog-type port for APRISMO diagnostic capture (Development
> mode only)
>
> Added Screen / Labels / Nicknames / Delete All (n)
> Also, if you try to define a new nickname that uses the same label as an
> existing nickname, the Accept button will disable until the Label is unique.
>
> There's a new Configure / Aliases / Accumulate feature to "learn" local
> digipeater aliases for actual hop counting.
> (Note: these are things like WIDE, RELAY as well as the State and
> Regional aliases (SSn-N))
> See: http://aprsisce.wikidot.com/menu:configure-aliases
>
> Show both Non-alias used hop count and Simplistic used hop count in the
> Digi/IGate column of the packet scroller.
>
> Filtered gating of packets from -IS to RF, but only in Development
> mode.  See notes from 2012/08/31 08:02 below.
>
> There's a bunch of updates to the View / Platform submenu population and
> counting sprinkled throughout.
>
> There's a new Configure / Companions option described in 2012/09/04
> 21:26, 2012/09/06 02:03, 02:51, 13:35
>
> Support MiniDump creation on a detected crash.  This may create
> APRSIS32.DMP files in your execution directory that will assist me in
> determining the cause of crashes.
> If APRSIS32 generates a .DMP/DMZ file, it will automatically restart.
> Eventually it'll even auto-detect the .DMPs and offer to send them to me.
>
> Support port type of "Dummy" (connection type doesn't matter) to be a
> Transmit-Only Dummy Load for testing -IS to RF IGating in an RF-less
> environment.
>
> Count "Oth" packets for any packet that doesn't fit a defined type.
> These are the packets that a type (t/) filter can't pick up from a
> filtered feed.  These packet counts are display on the port status
> windows (right click in APRS-IS OK pane).
>
> There's a new set of "Busy Stations" windows available on the APRS-IS OK
> right click menu.  Read about them in 2012/09/27 07:39 below.
>
> Support Screen / Brightness / Bright/Dim which changes the background of
> the transparent maps from White to Black. Discovered on APRSISDR.  (Adam
> KC2ANT)
>
> The NMEA port now supports a direct TCP/IP connection to GPSd. Simply
> configure the NMEA port to use TCP/IP and point it to your GPSd
> instance.  If you've never heard of GPSd, don't worry about it.  If
> you've got a GPSd already running, then I don't need to tell you more,
> right?  (Steve G6UIM)
>
> RF Ports now have a "NoGate ME" checkbox to disable gating your own
> generated packets to the -IS if copied on a digipeat.
>
> Added zoom number in center of slider (breaks if/when I do fractional
> zooms).  (Greg KB3KBR, Fred N7FMH)
> The zoom number turns green (it might be hard to read) when you're
> zoomed in close enough to "Move ME".  (Greg KB3KBR)
>
> Ignore single character !shriek!s (!x! being put out by N5ETC-2)
>
> Properly parse local time (/) format specifier (Jerry KF5AOK)
>
> New support for JS8Call and FT8 log-scraping objects.  This is similar
> to the JT65 scraper that already existed.  Simply create new object of
> the appropriate type and point it to your ALL.TXT log file for the
> corresponding program.  Object will be created for any detected station
> for which a grid square is available. These are objects local to your
> instance only.
>
> Support for "Hashes".  These are similar to !shriek!s, but are delimited
> by a single preceding #, as in #JS8 or #EVENT.  More details on this to
> follow at some later date.
> Note that only 32 unique Hashes are currently supported.  This limit
> will be removed before this support is finalized.
>
> KISS (aka AX.25) callsigns are now limited to A..Z and 0..9. Invalid
> characters are simply removed from the transmitted callsign, so beware!
>
>
>
>
>
>





Re: Proposed General Release (Dev: 2020/05/01 21:21)

Rob Giuliano
 

I updated the WIKI on this subject.
  There are 2 sections now -> Pre WINE 2.8 (same info as before: WINE Registry) and Post WINE 2.8 (updated for USB devices: reassign existing Ports). 

Unfortunately, the explanation is a bit wordy.  If you are familar with Linux and WINE, please take a look and provide any feedback.

I have 3 TNCs that connect through USB devices, and I have successfully changed TNCs with APRSIS32 matching the COM port for each.  In my case, each USB interface had a unique Vendor and Product code. 

My one comment about the updated WINE versions is:
"The good news is that you no longer have to mess with the Registry (which can cause other problems).  Older WINE versions had a pretty simple registry, but the newer versions are much more Windows like."

Robert Giuliano
KB8RCO



On Saturday, May 2, 2020, 12:57:42 PM EDT, Rob Giuliano via groups.io <kb8rco@...> wrote:


I would argue their purpose was to ensure anything Linux 'sees' is mapped to WINE.
Why does Linux have
    tty - okay I know this one!
    tty0 - tty63
    ttyS0 - ttyS32
when only a few devices are actually present?
Isn't that what things like udev are for?

I will be doing a little investigating into possibly deleting some of these nonexistent devices and see if that cuts down what WINE sees.

Robert Giuliano
KB8RCO



On Saturday, May 2, 2020, 12:25:44 PM EDT, Greg D <ko6th.greg@...> wrote:


Hi Rob,

It sounds like the Wine team is trying to be annoyance-for-annoyance compatible with Windows :(. 

I'm on Wine 1.8.6 on an old OpenSuSE LEAP 42.1 system, and the upgrade to the latest went without a hitch.  It's an iGate that I run 24x7, and all is working fine.  Thanks for the "heads-up" for the future when I eventually upgrade the system.

Greg  KO6TH


Rob Giuliano via groups.io wrote:
I'll try a few more things and update the wiki - soon.

Robert Giuliano
KB8RCO



On Saturday, May 2, 2020, 10:36:15 AM EDT, Rob Giuliano via groups.io <kb8rco@...> wrote:


As near as I can tell, there is something in the WINE setup that automatically (and "unchangeably") links every ttyS## device in /dev to a com## in the .wine folder.  Linux (at least my XUbuntu) has ttyS0 - ttyS32.  Each USB serial device is added after that. 

Good news is that APRSIS32 "sees" all 33 (in my case) serial ports.  The bad news of course is that there is no guarantee of the USB order if you have more than 1 USB serial device.

Through investigation, I learned that udev rules can reallocate any of these com# device to a symlink device link other than an ttyS#, BUT WINE changes them back.  However, udev rule CAN override an existing device (with no hardware), that worked for me.  My desktop has 1 physical serial port on ttyS0 (com1), so I can reallocate any ttyS# with # > 0.  Just remember that COM# ports start with 1 and ttyS# devices start with 0 (zero), so my override of ttyS3 became com4.  A section of my udev rules file in /etc/udev/rules.d called 65-tnc.rules:

#65-tnc.rules
# TNC-X
# SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="tncx"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="ttyS3"

I have a line for each TNC device I connect, including some for Bluetooth connections, but I haven't tested those with WINE 5.0 yet.

Robert Giuliano
KB8RCO



On Saturday, May 2, 2020, 8:58:33 AM EDT, Michael Coslo via groups.io <mjc_n3li@...> wrote:


Hi Rob,

WINES’s handling of com ports flummoxed me. What used to be a simple symbolic link became something else indeed  ver 2.8 and later. The people at Codeweavers tried to help, but they had instructions for Mac, which were different enough that it didn’t work for me.

Needing my station up and running, I ended up removing Mint and reinstalling Windows 8.1, which is just too cruel! 8^)

When I’m not pressed for time, I’ll reinstall mint and try again.

But you might have the secret sauce for getting new versions of WINE to do the link?

Otherwise I might try again with an old version of WINE.

- 73 Mike N3LI -


> On May 2, 2020, at 12:56 AM, Rob Giuliano via groups.io <kb8rco=yahoo.com@groups.io> wrote:
>
> Just upgraded my setup.  This includes latest XUbuntu (20.04) with WINE 5.0.
> Some features are new to me with the updated WINE version.
>
> APRSIS32 ran the normal update after clicking HELP.
> Other than connecting to my TNC (WINE changed COM port stuff), NO ISSUES here!
>
> I'll let it run now.
> Robert Giuliano
> KB8RCO
>
>
>
> On Friday, May 1, 2020, 10:02:06 PM EDT, Lynn Deffenbaugh <kj4erj@...> wrote:
>
>
> I just pushed the subject version to development.  Please let me know if
> you successfully upgrade to this and if it initially looks ok.
>
> The only change since the last Development release is a spelling
> correction, changing the name for APRSISMO (check KJ4ERJ-12), and
> setting the new release timestamp.
>
> If this checks out, I'll push it to release sometime over the weekend.
>
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>
> Here are the proposed release notes.  They will be posted in full to the
> Wiki.
>
> Here's the major features in version 2020/05/01 21:21
>
> Updated ToCall and Mic-E definitions from:
> http://www.aprs.org/aprs11/tocalls.txt as of 17 Apr 2020 (updated
> 2020/04/27)
> http://aprs.org/aprs12/mic-e-types.txt through 4 Jun 2019 (Updated
> 2020/04/27)
>
> No longer suppress gating messages just because a station was heard
> INSIDE a 3rd party packet on RF.  See notes about KO6TH from 2018/09/03
> 11:36
>
> Support "Common Talker IDs" from
> http://www.catb.org/gpsd/NMEA.html#_talker_ids. See notes from
> 2017/07/17 15:05
>
> Support Always-On-Top in right click menu in both main and MultiTrack
> windows (not on CE)
>
> Support proprietary 4 digit precision extension (!DAO!xx) in Configure /
> Beacon / Precision / 4 Digits
>
> Draw a small heading arrow near symbols that beacon speed and course
>
> Support a Syslog-type port for APRISMO diagnostic capture (Development
> mode only)
>
> Added Screen / Labels / Nicknames / Delete All (n)
> Also, if you try to define a new nickname that uses the same label as an
> existing nickname, the Accept button will disable until the Label is unique.
>
> There's a new Configure / Aliases / Accumulate feature to "learn" local
> digipeater aliases for actual hop counting.
> (Note: these are things like WIDE, RELAY as well as the State and
> Regional aliases (SSn-N))
> See: http://aprsisce.wikidot.com/menu:configure-aliases
>
> Show both Non-alias used hop count and Simplistic used hop count in the
> Digi/IGate column of the packet scroller.
>
> Filtered gating of packets from -IS to RF, but only in Development
> mode.  See notes from 2012/08/31 08:02 below.
>
> There's a bunch of updates to the View / Platform submenu population and
> counting sprinkled throughout.
>
> There's a new Configure / Companions option described in 2012/09/04
> 21:26, 2012/09/06 02:03, 02:51, 13:35
>
> Support MiniDump creation on a detected crash.  This may create
> APRSIS32.DMP files in your execution directory that will assist me in
> determining the cause of crashes.
> If APRSIS32 generates a .DMP/DMZ file, it will automatically restart.
> Eventually it'll even auto-detect the .DMPs and offer to send them to me.
>
> Support port type of "Dummy" (connection type doesn't matter) to be a
> Transmit-Only Dummy Load for testing -IS to RF IGating in an RF-less
> environment.
>
> Count "Oth" packets for any packet that doesn't fit a defined type.
> These are the packets that a type (t/) filter can't pick up from a
> filtered feed.  These packet counts are display on the port status
> windows (right click in APRS-IS OK pane).
>
> There's a new set of "Busy Stations" windows available on the APRS-IS OK
> right click menu.  Read about them in 2012/09/27 07:39 below.
>
> Support Screen / Brightness / Bright/Dim which changes the background of
> the transparent maps from White to Black. Discovered on APRSISDR.  (Adam
> KC2ANT)
>
> The NMEA port now supports a direct TCP/IP connection to GPSd. Simply
> configure the NMEA port to use TCP/IP and point it to your GPSd
> instance.  If you've never heard of GPSd, don't worry about it.  If
> you've got a GPSd already running, then I don't need to tell you more,
> right?  (Steve G6UIM)
>
> RF Ports now have a "NoGate ME" checkbox to disable gating your own
> generated packets to the -IS if copied on a digipeat.
>
> Added zoom number in center of slider (breaks if/when I do fractional
> zooms).  (Greg KB3KBR, Fred N7FMH)
> The zoom number turns green (it might be hard to read) when you're
> zoomed in close enough to "Move ME".  (Greg KB3KBR)
>
> Ignore single character !shriek!s (!x! being put out by N5ETC-2)
>
> Properly parse local time (/) format specifier (Jerry KF5AOK)
>
> New support for JS8Call and FT8 log-scraping objects.  This is similar
> to the JT65 scraper that already existed.  Simply create new object of
> the appropriate type and point it to your ALL.TXT log file for the
> corresponding program.  Object will be created for any detected station
> for which a grid square is available. These are objects local to your
> instance only.
>
> Support for "Hashes".  These are similar to !shriek!s, but are delimited
> by a single preceding #, as in #JS8 or #EVENT.  More details on this to
> follow at some later date.
> Note that only 32 unique Hashes are currently supported.  This limit
> will be removed before this support is finalized.
>
> KISS (aka AX.25) callsigns are now limited to A..Z and 0..9. Invalid
> characters are simply removed from the transmitted callsign, so beware!
>
>
>
>
>
>





Re: Receiving using a Kenwood TH-D74 via Bluetooth

Fred Hillhouse Jr (CruelShoes)
 

Edit: get the radio running first WITHOUT any connections to other devices (e.g, laptop).


On Tue, May 5, 2020 at 10:11 AM Fred Hillhouse <fmhillhouse@...> wrote:

First off, run the radio with any connections to start. It will encode/decode APRS packets by itself. If that is not working for you then it needs to be fixed first. Once you have it working, then solve the PC connections.

 

Here is a some things that work for me on my D72. It could be different from the D74 but it is a starting place.

 

I programmed location position 1 with my home location. At home I don’t need the GPS. It is handy when I wish to catch a satellite pass to not have to wait for the GPS to figure out where I am. Yeah, I have missed passes because of this. Rainy days slow acquisition.

 

Open the squelch to determine if other stations are active. During this pandemic there is less traffic. This is for your own ears so you know they exists. Once you know other stations are active, add enough squelch to silence the radio. The radio will not send a beacon if it thinks there is a signal. An open squelch keeps the radio from transmitting.

 

Fred N7FMH

 

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of K3RWN
Sent: Tuesday, May 05, 2020 12:19 AM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Receiving using a Kenwood TH-D74 via Bluetooth

 

You may be hearing back.   I usually just monitor traffic and watch friends being spotted on the map.   I am not sure that I am actually sending my location via the radio.  I need to verify that.  Too late to check tonight but I will tomorrow

 

On 5/4/2020 23:42 PM, Mike K5MRH wrote:

Thanks. I did have those set that way. I'm getting better reception now and it's all working, so that must have been my issue. Interesting, it seems to work the same whether I have the PCOUTPUT option the APRS menu set or not.
--
Mike K5MRH




Avast logo

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




--
Best regards,
Fred N7FMH


Re: Receiving using a Kenwood TH-D74 via Bluetooth

Fred Hillhouse
 

This is my thoughts on the radio. Get it working before adding a connection to a phone/PC.

Frequency 144.390?

Tone/CTCSS/DCS clear of off?

Do you see APRS 12 on your display?

Do you see BCON on display? This is needed to beacon.

On my D72, the squelch must be closed to allow beaconing.

 

Fred N7FMH

PS. I have a D72 but they are similar.

 

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Mike K5MRH
Sent: Monday, May 04, 2020 8:21 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Receiving using a Kenwood TH-D74 via Bluetooth

 

Of course as soon as I sent that, I realized that the radio isn't decoding the packets either, so I think I may just have a reception problem. Still if anyone has any tips or configuration suggestions for the TH-D74 when please pass them along.
--
Mike K5MRH




Avast logo

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



Re: Receiving using a Kenwood TH-D74 via Bluetooth

Fred Hillhouse
 

First off, run the radio with any connections to start. It will encode/decode APRS packets by itself. If that is not working for you then it needs to be fixed first. Once you have it working, then solve the PC connections.

 

Here is a some things that work for me on my D72. It could be different from the D74 but it is a starting place.

 

I programmed location position 1 with my home location. At home I don’t need the GPS. It is handy when I wish to catch a satellite pass to not have to wait for the GPS to figure out where I am. Yeah, I have missed passes because of this. Rainy days slow acquisition.

 

Open the squelch to determine if other stations are active. During this pandemic there is less traffic. This is for your own ears so you know they exists. Once you know other stations are active, add enough squelch to silence the radio. The radio will not send a beacon if it thinks there is a signal. An open squelch keeps the radio from transmitting.

 

Fred N7FMH

 

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of K3RWN
Sent: Tuesday, May 05, 2020 12:19 AM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Receiving using a Kenwood TH-D74 via Bluetooth

 

You may be hearing back.   I usually just monitor traffic and watch friends being spotted on the map.   I am not sure that I am actually sending my location via the radio.  I need to verify that.  Too late to check tonight but I will tomorrow

 

On 5/4/2020 23:42 PM, Mike K5MRH wrote:

Thanks. I did have those set that way. I'm getting better reception now and it's all working, so that must have been my issue. Interesting, it seems to work the same whether I have the PCOUTPUT option the APRS menu set or not.
--
Mike K5MRH




Avast logo

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



Re: Receiving using a Kenwood TH-D74 via Bluetooth

K3RWN
 

You may be hearing back.   I usually just monitor traffic and watch friends being spotted on the map.   I am not sure that I am actually sending my location via the radio.  I need to verify that.  Too late to check tonight but I will tomorrow


On 5/4/2020 23:42 PM, Mike K5MRH wrote:
Thanks. I did have those set that way. I'm getting better reception now and it's all working, so that must have been my issue. Interesting, it seems to work the same whether I have the PCOUTPUT option the APRS menu set or not.
--
Mike K5MRH


Re: Receiving using a Kenwood TH-D74 via Bluetooth

Mike K5MRH
 

Thanks. I did have those set that way. I'm getting better reception now and it's all working, so that must have been my issue. Interesting, it seems to work the same whether I have the PCOUTPUT option the APRS menu set or not.
--
Mike K5MRH


Re: Receiving using a Kenwood TH-D74 via Bluetooth

K3RWN
 

This is how mine is setup.   You may want to give it a try

the PCOUTPUT in the APRS menu may need to be off.  Mine is off

In the Config Menu use these settings

Under Interface

USB Function COM+AF/IF OUTPUT

PC OUTPUT GPS - BLUETOOTH

PC OUTPUT APRS - BLUETOOTH

KISS - BLUETOOTH

Rich

 

On 5/4/2020 19:47 PM, Mike K5MRH wrote:
New to the APRSISCE and trying to get it configured to use my Kenwood TH-D74 over bluetooth. I created a port for it and I am able to get it to transmit over the radio. I see others reporting the packet I sent when I look for my callsign on aprs.fi. I am not however able to get the app to decode packets. I have the tried with the TNC in the radio set to both APRS12 and KISS12 modes and I'be configured the PC OUTPUT setting to raw packets. I see a message here from 2016 suggesting from XML file might be needed for it, but I don't know where to get them. Any help would be great. Thanks.
--
Mike K5MRH


Re: Proposed General Release (Dev: 2020/05/01 21:21)

Rob Giuliano
 

You need to download the release version:


Actually looks like this was released as of May 1.

If you want the development version, all that is necessary is to edit the XML to use it.


Even with the latest release having just be so, the development version has a few feaures that are not fully implemented in the full release.  These typically are feaures that aren't fully vetted in their impact to the APRS system as a whole.  Certain settings can cause problems, so an added bit of caution is required. 

Robert Giuliano
KB8RCO



On Monday, May 4, 2020, 7:16:20 PM EDT, Mike K5MRH <groupio@...> wrote:


I'm new to the group and I guess I picked a good time to join in. I can't find where to download the release candidate. Is it open for people to test, or are a limited number of people still testing for now?


Re: Receiving using a Kenwood TH-D74 via Bluetooth

Mike K5MRH
 

Of course as soon as I sent that, I realized that the radio isn't decoding the packets either, so I think I may just have a reception problem. Still if anyone has any tips or configuration suggestions for the TH-D74 when please pass them along.
--
Mike K5MRH


Receiving using a Kenwood TH-D74 via Bluetooth

Mike K5MRH
 

New to the APRSISCE and trying to get it configured to use my Kenwood TH-D74 over bluetooth. I created a port for it and I am able to get it to transmit over the radio. I see others reporting the packet I sent when I look for my callsign on aprs.fi. I am not however able to get the app to decode packets. I have the tried with the TNC in the radio set to both APRS12 and KISS12 modes and I'be configured the PC OUTPUT setting to raw packets. I see a message here from 2016 suggesting from XML file might be needed for it, but I don't know where to get them. Any help would be great. Thanks.
--
Mike K5MRH


Re: 7330 Disable CW

Glenn E Miller
 

Sorry. Wrong group. I'm trying to delete the post.


Re: 7330 Disable CW

Lynn Deffenbaugh
 

What is a 7330?  What does CW have to do with APRS?  And how is APRSIS32 involved in this?

It's ok to ask here, but if it's not directly APRSIS32 related, it'll likely take a more detailed question to get reasonable answers.

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

On 5/4/2020 3:03 PM, Glenn E Miller wrote:
I've done a lot of searching. I can't find the command for disabling CW in the 7330. 

Glenn N6GIW

821 - 840 of 35160