Date   

Re: APRSISCE mobile installation

Lynn Deffenbaugh
 

Do you actually have a Windows Mobile device, or did you mean to say APRSIS32 on Windows?

What exactly is a "Microsoft GPS receiver/antenna"?  Does it hook to your D-700?  Or does it deliver NMEA GPS strings to windows via a COM port?  if it is USB-only without an NMEA capability, it won't help.

And yes, the D-700 can be easily interfaced to.  See also:

http://aprsisce.wikidot.com/tnc-d700

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

On 4/27/2020 4:12 PM, Michael Coslo via groups.io wrote:
Has anyone in here set up mobile operations with APRSISCE?

Radio would be a D-700, and if possible, I’d like to use my Microsoft GPS receiver/antenna.

- 73 Mike N3LI -


Re: (Re)Corrected initial FT8/JS8/JT65 objects (Dev: 2020/04/27 16:06)

Steven Joerger
 

I can verify that FT8 and JS8Call work for me now in the 16:06 build.

I do not have JT65hf setup to test this one however.

Steve N4TQU

On 4/27/2020 4:07 PM, Lynn Deffenbaugh wrote:
Yep, and for the same reason.  I fixed FT8, meant to fix JS8, and didn't even think about JT65.  All three of them are fixed now, I hope.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
On 4/27/2020 3:24 PM, Steven Joerger wrote:
Lynn,

Thanks for the feedback.

Downloaded the latest update and FT8 object creation worked.

However JS8Call object creation still crashes.

Steve N4TQU


On 4/27/2020 3:18 PM, Lynn Deffenbaugh wrote:
Thank you for the report Steve!  This happens when I make changes after having created my own objects and not going back to create new ones.

The crash problem is hopefully fixed.  When you can download the latest version and try again, please let me know if/that it works now.

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

On 4/27/2020 2:46 PM, Steven Joerger wrote:


On 4/27/2020 2:31 PM, Lynn Deffenbaugh wrote:
While working on that last informational message, I noticed that I ahd the wrong default -SSID for FT8 objects.  It is now -F8 as I originally intended.

Oh, and if you decide to play with JS8Call and APRSIS32, adding "u/APJ8*" to your filter will also get you all APRS packets generated by the APRSIS support built into JS8Call. That's JS8Call's official ToCall.  Shortly after I fired up my JS8Call-monitoring instance, I received:


Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
I just updated my application to the build 2020/04/27 14:13 and it still crashes when I try to create a FT8 object.

I get as far as selecting my ALL.TXT file, another window opens briefly then the application shutsdown and restarts.

Please advise?

Steve N4TQU







APRSISCE mobile installation

Michael Coslo
 

Has anyone in here set up mobile operations with APRSISCE?

Radio would be a D-700, and if possible, I’d like to use my Microsoft GPS receiver/antenna.

- 73 Mike N3LI -


(Re)Corrected initial FT8/JS8/JT65 objects (Dev: 2020/04/27 16:06)

Lynn Deffenbaugh
 

Yep, and for the same reason.  I fixed FT8, meant to fix JS8, and didn't even think about JT65.  All three of them are fixed now, I hope.

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

On 4/27/2020 3:24 PM, Steven Joerger wrote:
Lynn,

Thanks for the feedback.

Downloaded the latest update and FT8 object creation worked.

However JS8Call object creation still crashes.

Steve N4TQU


On 4/27/2020 3:18 PM, Lynn Deffenbaugh wrote:
Thank you for the report Steve!  This happens when I make changes after having created my own objects and not going back to create new ones.

The crash problem is hopefully fixed.  When you can download the latest version and try again, please let me know if/that it works now.

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

On 4/27/2020 2:46 PM, Steven Joerger wrote:


On 4/27/2020 2:31 PM, Lynn Deffenbaugh wrote:
While working on that last informational message, I noticed that I ahd the wrong default -SSID for FT8 objects.  It is now -F8 as I originally intended.

Oh, and if you decide to play with JS8Call and APRSIS32, adding "u/APJ8*" to your filter will also get you all APRS packets generated by the APRSIS support built into JS8Call. That's JS8Call's official ToCall.  Shortly after I fired up my JS8Call-monitoring instance, I received:


Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
I just updated my application to the build 2020/04/27 14:13 and it still crashes when I try to create a FT8 object.

I get as far as selecting my ALL.TXT file, another window opens briefly then the application shutsdown and restarts.

Please advise?

Steve N4TQU






Re: Corrected initial creation of FT8/JS8 objects (Dev: 2020/04/27 15:12)

Steven Joerger
 

Lynn,

Thanks for the feedback.

Downloaded the latest update and FT8 object creation worked.

However JS8Call object creation still crashes.

Steve N4TQU

On 4/27/2020 3:18 PM, Lynn Deffenbaugh wrote:
Thank you for the report Steve!  This happens when I make changes after having created my own objects and not going back to create new ones.
The crash problem is hopefully fixed.  When you can download the latest version and try again, please let me know if/that it works now.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
On 4/27/2020 2:46 PM, Steven Joerger wrote:


On 4/27/2020 2:31 PM, Lynn Deffenbaugh wrote:
While working on that last informational message, I noticed that I ahd the wrong default -SSID for FT8 objects.  It is now -F8 as I originally intended.

Oh, and if you decide to play with JS8Call and APRSIS32, adding "u/APJ8*" to your filter will also get you all APRS packets generated by the APRSIS support built into JS8Call.  That's JS8Call's official ToCall.  Shortly after I fired up my JS8Call-monitoring instance, I received:


Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
I just updated my application to the build 2020/04/27 14:13 and it still crashes when I try to create a FT8 object.

I get as far as selecting my ALL.TXT file, another window opens briefly then the application shutsdown and restarts.

Please advise?

Steve N4TQU





Corrected initial creation of FT8/JS8 objects (Dev: 2020/04/27 15:12)

Lynn Deffenbaugh
 

Thank you for the report Steve!  This happens when I make changes after having created my own objects and not going back to create new ones.

The crash problem is hopefully fixed.  When you can download the latest version and try again, please let me know if/that it works now.

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

On 4/27/2020 2:46 PM, Steven Joerger wrote:


On 4/27/2020 2:31 PM, Lynn Deffenbaugh wrote:
While working on that last informational message, I noticed that I ahd the wrong default -SSID for FT8 objects.  It is now -F8 as I originally intended.

Oh, and if you decide to play with JS8Call and APRSIS32, adding "u/APJ8*" to your filter will also get you all APRS packets generated by the APRSIS support built into JS8Call.  That's JS8Call's official ToCall.  Shortly after I fired up my JS8Call-monitoring instance, I received:


Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
I just updated my application to the build 2020/04/27 14:13 and it still crashes when I try to create a FT8 object.

I get as far as selecting my ALL.TXT file, another window opens briefly then the application shutsdown and restarts.

Please advise?

Steve N4TQU




Re: Corrected default FT8 -SSID (Dev: 2020/04/27 14:13)

Steven Joerger
 

On 4/27/2020 2:31 PM, Lynn Deffenbaugh wrote:
While working on that last informational message, I noticed that I ahd the wrong default -SSID for FT8 objects.  It is now -F8 as I originally intended.
Oh, and if you decide to play with JS8Call and APRSIS32, adding "u/APJ8*" to your filter will also get you all APRS packets generated by the APRSIS support built into JS8Call.  That's JS8Call's official ToCall.  Shortly after I fired up my JS8Call-monitoring instance, I received:
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
I just updated my application to the build 2020/04/27 14:13 and it still crashes when I try to create a FT8 object.

I get as far as selecting my ALL.TXT file, another window opens briefly then the application shutsdown and restarts.

Please advise?

Steve N4TQU


Corrected default FT8 -SSID (Dev: 2020/04/27 14:13)

Lynn Deffenbaugh
 

While working on that last informational message, I noticed that I ahd the wrong default -SSID for FT8 objects.  It is now -F8 as I originally intended.

Oh, and if you decide to play with JS8Call and APRSIS32, adding "u/APJ8*" to your filter will also get you all APRS packets generated by the APRSIS support built into JS8Call.  That's JS8Call's official ToCall.  Shortly after I fired up my JS8Call-monitoring instance, I received:


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


JS8CAll/FT8/JT65 Log Scrapers

Lynn Deffenbaugh
 

Ok, for a bit of background and description of this.  It exists because I was working with JT65 a few years ago and wanted a way to visualize the gridsquares of the stations I was copying.  So I implemented in my favorite position mapping and display tool, APRSIS32.  Here's what I posted when this support was originally implemented for JT65 on 8/8/2012 8:39PM:

Ok, here's the feature that I mentioned earlier today.  This is NOT the 
final implementation, but I'm releasing it in this form to solicit feedback.

If you use JT65-HF, then you should have a JT65hf-log.csv somewhere.  
You can tell where it's at via JT65-HF's Setup / Configuration tab at 
the bottom labeled "Location of RX/TX history file".  Make a note of 
that as you'll need to navigate to it to set up the JT65 visualizer object.
Kick it all off with Configure / Objects / New JT65

Confirm Yes to Create JT65 Object At ME (the only place you can create it)

A file browser dialog will appear asking you to locate the 
JT65hf-log.csv file.  When you find the proper directory and file, click 
Open.

In the Object dialog, you'll want to check Enabled.  The default name is 
<yourcall>-JT and the default symbol is DX (primary table %).  Whatever 
-SSID you give the object will be added to the JT65 spot callsigns when 
their objects are created (-JT is used if you don't specify an -SSID).  
The symbol of this object is also used to create the spots.

The only other functioning control in this configuration is the Reset 
checkbox.  If you check that, then on the next update, ALL of the spots 
are processed instead of only the new ones.  Of course, spots older than 
<Stations.MaxAge> aren't loaded no matter what, but Reset is a handy way 
to pull in more spots if you've increased <Stations.MaxAge> across a 
restart.

When you Accept the new object, you should see a series of <callsign>-JT 
(or your object's -SSID) show up in the packet scroller as internal 
packets.  And your map should show them as a grid-square ambiguous 
stations (purple rectangle).  If you have too many and you're using a 
new instance, you may have to increase Configure / Screen / Label / Max 
Visible to see them.  You'll probably also want Screen / Labels / 
Callsign checked to be most useful.

If you want to see ONLY the JT65 objects, you should have a View / 
Shrieks / !JT65! that will filter the view.  Kind of handy in a 
MultiTrack if you're doing this in an instance that's also getting an 
APRS-IS feed.  I bring up a MultiTrack on my own -JT object and save it 
as "Always".

Oh, and Configure / Messages / Lookup(WHO-IS) / Full Address is also a 
handy thing to check for quick full lookups of a *-JT station.

For those of you that do JT65, let me know what you think.  For the rest 
of you, please pardon the distraction, but this is a test bed for some 
of the other future visualization features that will be more directly 
related to APRS.
Well, that was longer than I expected and I'm not sure how much, if any of it, changed since then.  But that's the gist of it.

What's new is the ability to process the ALL.TXT files from JS8Call and FT8 the same way.  The default -SSIDs for the objects are different (-J8 and -F8), and they are #hashes instead of !shriek!s.  JT65 objects remain as !JT65! however.

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

On 4/27/2020 1:58 PM, Arnold Harding. - KQ6DI wrote:
Due to the plethora of emails I can tell this is vitally important in APRS, but can someone explain where and what this is?  Thanks.
Arnold, KQ6DI

1) 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.


Re: FTM-400 ToCall was: Dev 2020/04/26 22:23

Glenn O'Connor
 

After 20+ years with APRS, I never did understand the Mic-E's.

I dug up an old message'S raw data from my rig:
KF0ED-9>APY400,CHILLI*,WIDE2-1,qAR,KD0YUJ::KF0ED :test{0

Tnx fer all you do Lynn!

Glenn-KF0ED


Re: FTM-400 ToCall was: Dev 2020/04/26 22:23

Lynn Deffenbaugh
 

That's a Mic-E posit.  You need to send a message to see what it uses as a ToCall.  Mic-E posits put part of the location data in the ToCall field.

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

On 4/27/2020 1:53 PM, Glenn O'Connor wrote:

 From a -400…

 

KC0GP-9>SYTU5S,CHILLI,RAYCO,WIDE2*,qAR,N0JVW:`y@Arr6k/`"6;}147.225MHz Toff +060_%

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Greg Depew
Sent: Monday, April 27, 2020 12:52 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] FTM-400 ToCall was: Dev 2020/04/26 22:23

 

My 400 sent an ack back to me earlier today. Its showing APY400. KB3KBR-12 is the ssid. 

 

 

 

Greg KB3KBR Sent from my Verizon, Samsung Galaxy smartphone

 

 

 

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

From: Lynn Deffenbaugh <kj4erj@...>

Date: 4/27/20 13:49 (GMT-05:00)

Subject: [APRSISCE] FTM-400 ToCall was: Dev 2020/04/26 22:23

 

The FTM-400 is in http://www.aprs.org/aprs12/mic-e-types.txt, but not http://www.aprs.org/aprs11/tocalls.txt.  Can someone that has access to a known FTM-400 check the raw packets at aprs.fi and confirm what ToCall they are using for non-position packets?  Their position packets are Mic-E which is how we're identifying them.

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

On 4/27/2020 12:15 PM, Greg Depew wrote:

The 400 was added in previous release. My mobile is a 400 and has been working for quite a while. 

 

 

 

Greg KB3KBR Sent from my Verizon, Samsung Galaxy smartphone

 

 

 

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

From: Glenn O'Connor <ka0lnr37@...>

Date: 4/27/20 12:11 (GMT-05:00)

Subject: Re: [APRSISCE] JS8CAll/FT8 Log Scrapers (Dev 2020/04/26 22:23)

 

Lynn, I see no listing for the Yaesu FTM-400. The -350, yes.

 

 

73,

Glenn-KF0ED

 

 

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Lynn Deffenbaugh
Sent: Monday, April 27, 2020 10:02 AM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] JS8CAll/FT8 Log Scrapers (Dev 2020/04/26 22:23)

 

Also, I just noticed that these devices are not listed in http://www.aprs.org/aprs11/tocalls.txt

Can someone that owns each of these devices send a message to anyone and check the raw packets at aprs.fi to see what ToCall they are actually using?

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

On 4/27/2020 10:59 AM, Lynn Deffenbaugh wrote:

I only mirrored what Bob had listed at http://www.aprs.org/aprs12/mic-e-types.txt

Which leads me to ask if the model number actually includes the final R as you showed but is NOT included in Bob's definitions?

 

So maybe we got the hyphen right, but are still worng (sic)...

 

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

On 4/27/2020 10:45 AM, Dennis Griffin wrote:

In case anyone is confused, Yaesu didn’t include a hyphen in the FT1DR, FT2DR & FT3DR HT model descriptors, as they have for every other transceiver model that I’m aware of since the FT-51R.

 

Thanks for adding it correctly, Lynn.

 

73 de Dennis KD7CAC
Scottsdale, AZ

 

On Apr 27, 2020, at 6:48 AM, Ryszard Labus via groups.io <r.labus@...> wrote:

 

It works well now.

<lobbcmjhfakpnhcf.png>

Really good job.
Thank You.

R.

W dniu 2020-04-27 o 14:00, Lynn Deffenbaugh pisze:

Well, because those notes were accumulated from the changes done over the past 2 years, not necessarily recently.  FT-3D will be in the next update, hopefully later today as I catch up on more stuff.


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

On 4/27/2020 4:03 AM, Ryszard Labus via groups.io wrote:

What i am doing wrong?

I cant see FT-3D as recognized?

<hicijalgjldiggho.png>

W dniu 2020-04-27 o 05:15, Lynn Deffenbaugh pisze:

12) The recognized ToCalls and Mic-E type codes have been update per Bob's pages.

-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl
-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl

 


Re: JS8CAll/FT8 Log Scrapers (Dev 2020/04/26 22:23)

Arnold Harding. - KQ6DI
 

Due to the plethora of emails I can tell this is vitally important in APRS, but can someone explain where and what this is?  Thanks.
Arnold, KQ6DI

1) 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.


Re: FTM-400 ToCall was: Dev 2020/04/26 22:23

Glenn O'Connor
 

 From a -400…

 

KC0GP-9>SYTU5S,CHILLI,RAYCO,WIDE2*,qAR,N0JVW:`y@Arr6k/`"6;}147.225MHz Toff +060_%

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Greg Depew
Sent: Monday, April 27, 2020 12:52 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] FTM-400 ToCall was: Dev 2020/04/26 22:23

 

My 400 sent an ack back to me earlier today. Its showing APY400. KB3KBR-12 is the ssid. 

 

 

 

Greg KB3KBR Sent from my Verizon, Samsung Galaxy smartphone

 

 

 

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

From: Lynn Deffenbaugh <kj4erj@...>

Date: 4/27/20 13:49 (GMT-05:00)

Subject: [APRSISCE] FTM-400 ToCall was: Dev 2020/04/26 22:23

 

The FTM-400 is in http://www.aprs.org/aprs12/mic-e-types.txt, but not http://www.aprs.org/aprs11/tocalls.txt.  Can someone that has access to a known FTM-400 check the raw packets at aprs.fi and confirm what ToCall they are using for non-position packets?  Their position packets are Mic-E which is how we're identifying them.

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

On 4/27/2020 12:15 PM, Greg Depew wrote:

The 400 was added in previous release. My mobile is a 400 and has been working for quite a while. 

 

 

 

Greg KB3KBR Sent from my Verizon, Samsung Galaxy smartphone

 

 

 

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

From: Glenn O'Connor <ka0lnr37@...>

Date: 4/27/20 12:11 (GMT-05:00)

Subject: Re: [APRSISCE] JS8CAll/FT8 Log Scrapers (Dev 2020/04/26 22:23)

 

Lynn, I see no listing for the Yaesu FTM-400. The -350, yes.

 

 

73,

Glenn-KF0ED

 

 

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Lynn Deffenbaugh
Sent: Monday, April 27, 2020 10:02 AM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] JS8CAll/FT8 Log Scrapers (Dev 2020/04/26 22:23)

 

Also, I just noticed that these devices are not listed in http://www.aprs.org/aprs11/tocalls.txt

Can someone that owns each of these devices send a message to anyone and check the raw packets at aprs.fi to see what ToCall they are actually using?

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

On 4/27/2020 10:59 AM, Lynn Deffenbaugh wrote:

I only mirrored what Bob had listed at http://www.aprs.org/aprs12/mic-e-types.txt

Which leads me to ask if the model number actually includes the final R as you showed but is NOT included in Bob's definitions?

 

So maybe we got the hyphen right, but are still worng (sic)...

 

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

On 4/27/2020 10:45 AM, Dennis Griffin wrote:

In case anyone is confused, Yaesu didn’t include a hyphen in the FT1DR, FT2DR & FT3DR HT model descriptors, as they have for every other transceiver model that I’m aware of since the FT-51R.

 

Thanks for adding it correctly, Lynn.

 

73 de Dennis KD7CAC
Scottsdale, AZ

 

On Apr 27, 2020, at 6:48 AM, Ryszard Labus via groups.io <r.labus@...> wrote:

 

It works well now.

<lobbcmjhfakpnhcf.png>

Really good job.
Thank You.

R.

W dniu 2020-04-27 o 14:00, Lynn Deffenbaugh pisze:

Well, because those notes were accumulated from the changes done over the past 2 years, not necessarily recently.  FT-3D will be in the next update, hopefully later today as I catch up on more stuff.


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

On 4/27/2020 4:03 AM, Ryszard Labus via groups.io wrote:

What i am doing wrong?

I cant see FT-3D as recognized?

<hicijalgjldiggho.png>

W dniu 2020-04-27 o 05:15, Lynn Deffenbaugh pisze:

12) The recognized ToCalls and Mic-E type codes have been update per Bob's pages.

-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl
-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl

 


Re: FTM-400 ToCall was: Dev 2020/04/26 22:23

Greg Depew
 

My 400 sent an ack back to me earlier today. Its showing APY400. KB3KBR-12 is the ssid. 



Greg KB3KBR Sent from my Verizon, Samsung Galaxy smartphone



-------- Original message --------
From: Lynn Deffenbaugh <kj4erj@...>
Date: 4/27/20 13:49 (GMT-05:00)
To: APRSISCE@groups.io
Subject: [APRSISCE] FTM-400 ToCall was: Dev 2020/04/26 22:23

The FTM-400 is in http://www.aprs.org/aprs12/mic-e-types.txt, but not http://www.aprs.org/aprs11/tocalls.txt.  Can someone that has access to a known FTM-400 check the raw packets at aprs.fi and confirm what ToCall they are using for non-position packets?  Their position packets are Mic-E which is how we're identifying them.

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

On 4/27/2020 12:15 PM, Greg Depew wrote:
The 400 was added in previous release. My mobile is a 400 and has been working for quite a while. 



Greg KB3KBR Sent from my Verizon, Samsung Galaxy smartphone



-------- Original message --------
From: Glenn O'Connor <ka0lnr37@...>
Date: 4/27/20 12:11 (GMT-05:00)
Subject: Re: [APRSISCE] JS8CAll/FT8 Log Scrapers (Dev 2020/04/26 22:23)

Lynn, I see no listing for the Yaesu FTM-400. The -350, yes.

 

 

73,

Glenn-KF0ED

 

 

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Lynn Deffenbaugh
Sent: Monday, April 27, 2020 10:02 AM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] JS8CAll/FT8 Log Scrapers (Dev 2020/04/26 22:23)

 

Also, I just noticed that these devices are not listed in http://www.aprs.org/aprs11/tocalls.txt

Can someone that owns each of these devices send a message to anyone and check the raw packets at aprs.fi to see what ToCall they are actually using?

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

On 4/27/2020 10:59 AM, Lynn Deffenbaugh wrote:

I only mirrored what Bob had listed at http://www.aprs.org/aprs12/mic-e-types.txt

Which leads me to ask if the model number actually includes the final R as you showed but is NOT included in Bob's definitions?

 

So maybe we got the hyphen right, but are still worng (sic)...

 

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

On 4/27/2020 10:45 AM, Dennis Griffin wrote:

In case anyone is confused, Yaesu didn’t include a hyphen in the FT1DR, FT2DR & FT3DR HT model descriptors, as they have for every other transceiver model that I’m aware of since the FT-51R.

 

Thanks for adding it correctly, Lynn.

 

73 de Dennis KD7CAC
Scottsdale, AZ



On Apr 27, 2020, at 6:48 AM, Ryszard Labus via groups.io <r.labus@...> wrote:

 

It works well now.

<lobbcmjhfakpnhcf.png>

Really good job.
Thank You.

R.

W dniu 2020-04-27 o 14:00, Lynn Deffenbaugh pisze:

Well, because those notes were accumulated from the changes done over the past 2 years, not necessarily recently.  FT-3D will be in the next update, hopefully later today as I catch up on more stuff.


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

On 4/27/2020 4:03 AM, Ryszard Labus via groups.io wrote:

What i am doing wrong?

I cant see FT-3D as recognized?

<hicijalgjldiggho.png>

W dniu 2020-04-27 o 05:15, Lynn Deffenbaugh pisze:

12) The recognized ToCalls and Mic-E type codes have been update per Bob's pages.

-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl
-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl

 


Re: Yaesu FTnD was: Dev 2020/04/26 22:23

Lynn Deffenbaugh
 

Well, that didn't come out like I had planned.  It was supposed to say that you've likely hit the nail on the head and I'll quit thinking about that one at least.

Now we still need to determine what unique (or not) ToCall these devices use when sending a non-Mic-E packet like a message or an ack (which is really just a normal APRS message with a pre-defined content).

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

On 4/27/2020 1:46 PM, Lynn Deffenbaugh wrote:



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

On 4/27/2020 12:20 PM, Dennis Griffin wrote:
Hi Lynn,

I believe that FT1D, FT2D & FT3D are intended to be base model designators, with the R signifying the model being appropriate for the American(?) market.

Each of these were/are also available with a DE suffix as well as the DR suffix, and the FT1D also had an XDR suffix follow-on model.

This is similar to how Icom & Kenwood append an A or an E to many (all?) of their models to signify American or European market models.

I suspect that may be why Bob B listed only FT3D, so that any variation of that base model would be ID’d in APRS correctly.

You may recall seeing this from the TH-D74 FW update notes:

Updated item : (Version 1.08  1.09) [June 26, 2019]

The following features are updated.

1. Enables decoding of standard APRS telemetry format.(Displays telemetry packets sent from the PSAT2.)
2. Enables display of the model name "FT3D" when received an APRS position packet from the Yaesu FT3DR/E.

73 de Dennis KD7CAC
Scottsdale, AZ


On Apr 27, 2020, at 7:59 AM, Lynn Deffenbaugh <kj4erj@...> wrote:

I only mirrored what Bob had listed at http://www.aprs.org/aprs12/mic-e-types.txt

Which leads me to ask if the model number actually includes the final R as you showed but is NOT included in Bob's definitions?

So maybe we got the hyphen right, but are still worng (sic)...

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

On 4/27/2020 10:45 AM, Dennis Griffin wrote:
In case anyone is confused, Yaesu didn’t include a hyphen in the FT1DR, FT2DR & FT3DR HT model descriptors, as they have for every other transceiver model that I’m aware of since the FT-51R.

Thanks for adding it correctly, Lynn.

73 de Dennis KD7CAC
Scottsdale, AZ


On Apr 27, 2020, at 6:48 AM, Ryszard Labus via groups.io <r.labus@...> wrote:

It works well now.

<lobbcmjhfakpnhcf.png>

Really good job.
Thank You.

R.

W dniu 2020-04-27 o 14:00, Lynn Deffenbaugh pisze:
Well, because those notes were accumulated from the changes done over the past 2 years, not necessarily recently.  FT-3D will be in the next update, hopefully later today as I catch up on more stuff.

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

On 4/27/2020 4:03 AM, Ryszard Labus via groups.io wrote:

What i am doing wrong?

I cant see FT-3D as recognized?

<hicijalgjldiggho.png>

W dniu 2020-04-27 o 05:15, Lynn Deffenbaugh pisze:
12) The recognized ToCalls and Mic-E type codes have been update per Bob's pages.
-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl
-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl



Yaesu FTnD was: Dev 2020/04/26 22:23

Lynn Deffenbaugh
 



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

On 4/27/2020 12:20 PM, Dennis Griffin wrote:
Hi Lynn,

I believe that FT1D, FT2D & FT3D are intended to be base model designators, with the R signifying the model being appropriate for the American(?) market.

Each of these were/are also available with a DE suffix as well as the DR suffix, and the FT1D also had an XDR suffix follow-on model.

This is similar to how Icom & Kenwood append an A or an E to many (all?) of their models to signify American or European market models.

I suspect that may be why Bob B listed only FT3D, so that any variation of that base model would be ID’d in APRS correctly.

You may recall seeing this from the TH-D74 FW update notes:

Updated item : (Version 1.08  1.09) [June 26, 2019]

The following features are updated.

1. Enables decoding of standard APRS telemetry format.(Displays telemetry packets sent from the PSAT2.)
2. Enables display of the model name "FT3D" when received an APRS position packet from the Yaesu FT3DR/E.

73 de Dennis KD7CAC
Scottsdale, AZ


On Apr 27, 2020, at 7:59 AM, Lynn Deffenbaugh <kj4erj@...> wrote:

I only mirrored what Bob had listed at http://www.aprs.org/aprs12/mic-e-types.txt

Which leads me to ask if the model number actually includes the final R as you showed but is NOT included in Bob's definitions?

So maybe we got the hyphen right, but are still worng (sic)...

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

On 4/27/2020 10:45 AM, Dennis Griffin wrote:
In case anyone is confused, Yaesu didn’t include a hyphen in the FT1DR, FT2DR & FT3DR HT model descriptors, as they have for every other transceiver model that I’m aware of since the FT-51R.

Thanks for adding it correctly, Lynn.

73 de Dennis KD7CAC
Scottsdale, AZ


On Apr 27, 2020, at 6:48 AM, Ryszard Labus via groups.io <r.labus@...> wrote:

It works well now.

<lobbcmjhfakpnhcf.png>

Really good job.
Thank You.

R.

W dniu 2020-04-27 o 14:00, Lynn Deffenbaugh pisze:
Well, because those notes were accumulated from the changes done over the past 2 years, not necessarily recently.  FT-3D will be in the next update, hopefully later today as I catch up on more stuff.

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

On 4/27/2020 4:03 AM, Ryszard Labus via groups.io wrote:

What i am doing wrong?

I cant see FT-3D as recognized?

<hicijalgjldiggho.png>

W dniu 2020-04-27 o 05:15, Lynn Deffenbaugh pisze:
12) The recognized ToCalls and Mic-E type codes have been update per Bob's pages.
-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl
-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl



FTM-400 ToCall was: Dev 2020/04/26 22:23

Lynn Deffenbaugh
 

The FTM-400 is in http://www.aprs.org/aprs12/mic-e-types.txt, but not http://www.aprs.org/aprs11/tocalls.txt.  Can someone that has access to a known FTM-400 check the raw packets at aprs.fi and confirm what ToCall they are using for non-position packets?  Their position packets are Mic-E which is how we're identifying them.

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

On 4/27/2020 12:15 PM, Greg Depew wrote:
The 400 was added in previous release. My mobile is a 400 and has been working for quite a while. 



Greg KB3KBR Sent from my Verizon, Samsung Galaxy smartphone



-------- Original message --------
From: Glenn O'Connor <ka0lnr37@...>
Date: 4/27/20 12:11 (GMT-05:00)
Subject: Re: [APRSISCE] JS8CAll/FT8 Log Scrapers (Dev 2020/04/26 22:23)

Lynn, I see no listing for the Yaesu FTM-400. The -350, yes.

 

 

73,

Glenn-KF0ED

 

 

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Lynn Deffenbaugh
Sent: Monday, April 27, 2020 10:02 AM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] JS8CAll/FT8 Log Scrapers (Dev 2020/04/26 22:23)

 

Also, I just noticed that these devices are not listed in http://www.aprs.org/aprs11/tocalls.txt

Can someone that owns each of these devices send a message to anyone and check the raw packets at aprs.fi to see what ToCall they are actually using?

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

On 4/27/2020 10:59 AM, Lynn Deffenbaugh wrote:

I only mirrored what Bob had listed at http://www.aprs.org/aprs12/mic-e-types.txt

Which leads me to ask if the model number actually includes the final R as you showed but is NOT included in Bob's definitions?

 

So maybe we got the hyphen right, but are still worng (sic)...

 

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

On 4/27/2020 10:45 AM, Dennis Griffin wrote:

In case anyone is confused, Yaesu didn’t include a hyphen in the FT1DR, FT2DR & FT3DR HT model descriptors, as they have for every other transceiver model that I’m aware of since the FT-51R.

 

Thanks for adding it correctly, Lynn.

 

73 de Dennis KD7CAC
Scottsdale, AZ



On Apr 27, 2020, at 6:48 AM, Ryszard Labus via groups.io <r.labus@...> wrote:

 

It works well now.

<lobbcmjhfakpnhcf.png>

Really good job.
Thank You.

R.

W dniu 2020-04-27 o 14:00, Lynn Deffenbaugh pisze:

Well, because those notes were accumulated from the changes done over the past 2 years, not necessarily recently.  FT-3D will be in the next update, hopefully later today as I catch up on more stuff.


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

On 4/27/2020 4:03 AM, Ryszard Labus via groups.io wrote:

What i am doing wrong?

I cant see FT-3D as recognized?

<hicijalgjldiggho.png>

W dniu 2020-04-27 o 05:15, Lynn Deffenbaugh pisze:

12) The recognized ToCalls and Mic-E type codes have been update per Bob's pages.

-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl
-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl

 


General release was: Dev: 2020/04/26 22:23

Lynn Deffenbaugh
 

Greg,

That is EXACTLY why I'm wrapping up loose ends on the current development release!  I've done some work on MbTiles as a map storage format in APRSISMO and want to port that (complete the port, actually) into APRSISCE/32, but I want to get the current version into general release first.

Yes, a new general release is coming.  And the release notes will leave a lot to be desired unless someone would like to take all of the accumulated raw releases from Development and try to boil out the features worth mentioning for the General release update?

I can provide the raw text to any suitable victim... er volunteer!

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

On 4/27/2020 12:20 PM, Greg D wrote:
Hi Lynn,

Before you dig into making a lot of changes, is there any chance you could take the prior version and make it the standard release (not development)?  Seems like it's about time, no? 

Greg  KO6TH


Greg Depew wrote:
The 400 was added in previous release. My mobile is a 400 and has been working for quite a while. 



Greg KB3KBR Sent from my Verizon, Samsung Galaxy smartphone



-------- Original message --------
From: Glenn O'Connor <ka0lnr37@...>
Date: 4/27/20 12:11 (GMT-05:00)
Subject: Re: [APRSISCE] JS8CAll/FT8 Log Scrapers (Dev 2020/04/26 22:23)

Lynn, I see no listing for the Yaesu FTM-400. The -350, yes.

 

 

73,

Glenn-KF0ED

 

 

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Lynn Deffenbaugh
Sent: Monday, April 27, 2020 10:02 AM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] JS8CAll/FT8 Log Scrapers (Dev 2020/04/26 22:23)

 

Also, I just noticed that these devices are not listed in http://www.aprs.org/aprs11/tocalls.txt

Can someone that owns each of these devices send a message to anyone and check the raw packets at aprs.fi to see what ToCall they are actually using?

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

On 4/27/2020 10:59 AM, Lynn Deffenbaugh wrote:

I only mirrored what Bob had listed at http://www.aprs.org/aprs12/mic-e-types.txt

Which leads me to ask if the model number actually includes the final R as you showed but is NOT included in Bob's definitions?

 

So maybe we got the hyphen right, but are still worng (sic)...

 

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

On 4/27/2020 10:45 AM, Dennis Griffin wrote:

In case anyone is confused, Yaesu didn’t include a hyphen in the FT1DR, FT2DR & FT3DR HT model descriptors, as they have for every other transceiver model that I’m aware of since the FT-51R.

 

Thanks for adding it correctly, Lynn.

 

73 de Dennis KD7CAC
Scottsdale, AZ



On Apr 27, 2020, at 6:48 AM, Ryszard Labus via groups.io <r.labus@...> wrote:

 

It works well now.

<lobbcmjhfakpnhcf.png>

Really good job.
Thank You.

R.

W dniu 2020-04-27 o 14:00, Lynn Deffenbaugh pisze:

Well, because those notes were accumulated from the changes done over the past 2 years, not necessarily recently.  FT-3D will be in the next update, hopefully later today as I catch up on more stuff.


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

On 4/27/2020 4:03 AM, Ryszard Labus via groups.io wrote:

What i am doing wrong?

I cant see FT-3D as recognized?

<hicijalgjldiggho.png>

W dniu 2020-04-27 o 05:15, Lynn Deffenbaugh pisze:

12) The recognized ToCalls and Mic-E type codes have been update per Bob's pages.

-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl
-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl

 



Re: AnyTone 868 was: Dev 2020/04/26 22:23

Ryszard Labus
 

Like i said APRS to-call can be configured from CPS. This is bad way, that was an example.

R

W dniu 2020-04-27 o 18:10, Lynn Deffenbaugh pisze:

SQ9MDD-5 shows up as "App: APRSd, etc (878)" because it uses a ToCall of APD878 which at some point in the past, but apparently not in the current ToCalls was defined as:

"APDxxx", "APRSd, etc"

But certainly APD878 is not currently defined in the ToCall list that I can see.

 APD  APD4xx  UP4DAR platform
      APDDxx  DV-RPTR Modem and Control Center Software 
      APDFxx  Automatic DF units
      APDGxx  D-Star Gateways by G4KLX ircDDB
      APDHxx  WinDV (DUTCH*Star DV Node for Windows)
      APDInn  DIXPRS - Bela, HA5DI
      APDIGI  Used by PSAT2 to indicate the digi is ON
      APDIGI  digi ON for PSAT2 and QIKCOM-2
      APDKxx  KI4LKF g2_ircddb Dstar gateway software
      APDNOx  APRSduino by DO3SWW
      APDOxx  ON8JL Standalone DStar Node
      APDPRS  D-Star originated posits
      APDRxx  APRSdroid Android App http://aprsdroid.org/
      APDSXX  SP9UOB for dsDigi and ds-tracker
      APDTxx  APRStouch Tone (DTMF)
      APDTMF  digi off mode on QIKCOM2 and DTMF ON
      APDUxx  U2APRS by JA7UDE
      APDVxx  OE6PLD's SSTV with APRS status exchange
      APDWxx  DireWolf, WB2OSZ

But if it is configurable somewhere, it should be set to APAT81 according to the definition:

      APATxx  for Anytone. 81 for 878 HT 
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

PS.  According to http://wa8lmf.net/bruninga/aprs/tocalls.txt

 APD  APRSd,  etc
      APDTxx  APRStouch Tone (DTMF)
      APDFxx  Automatic DF units
      APDPRS  D-Star originated posits

Gotta love history revisionism...

On 4/27/2020 11:52 AM, Ryszard Labus via groups.io wrote:

Hi.

APBM1D is DPRS(DMR position) frame oryginated from Brand Meister network.
Anytone 878 can't send compressed frame. And dest call can be changed (!) from CPS
It's look like this:

2020-04-27T15:46:45.448 RF[KISS TC DIGI LOCALNET][1200] SQ9MDD-5>APD878,WIDE1-1,WIDE2-1:!5215.01N/02055.59E[000/000/A=000453145.574MHz lub SR5WZ

SQ9MDD.

W dniu 2020-04-27 o 17:38, Lynn Deffenbaugh pisze:

KF0ED-15 shows as "App: BrandMeister DMR (1D)" because if you look at the raw packet, it is using a ToCall of APBM1D, not the APATxx which is defined for Anytone.  And it is sending an "@" position packet, not a Mic-E packet, so the type code won't matter (regardless of the fact that only 878 has a type code defined).

I'm not sure I understand how an "IS only" device is coming through with a BrandMeister ToCall, but I don't know anything about DMR and/or its links to APRS.

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

On 4/27/2020 11:16 AM, Glenn O'Connor wrote:

I’ve just enabled my KF0ED-15 for my AnyTone 868. Its APRS is IS only. The 878 does RF and IS.

 

Glenn-KF0ED

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Lynn Deffenbaugh
Sent: Monday, April 27, 2020 10:02 AM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] JS8CAll/FT8 Log Scrapers (Dev 2020/04/26 22:23)

 

Also, I just noticed that these devices are not listed in http://www.aprs.org/aprs11/tocalls.txt

Can someone that owns each of these devices send a message to anyone and check the raw packets at aprs.fi to see what ToCall they are actually using?

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

On 4/27/2020 10:59 AM, Lynn Deffenbaugh wrote:

I only mirrored what Bob had listed at http://www.aprs.org/aprs12/mic-e-types.txt

Which leads me to ask if the model number actually includes the final R as you showed but is NOT included in Bob's definitions?

 

So maybe we got the hyphen right, but are still worng (sic)...

 

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

On 4/27/2020 10:45 AM, Dennis Griffin wrote:

In case anyone is confused, Yaesu didn’t include a hyphen in the FT1DR, FT2DR & FT3DR HT model descriptors, as they have for every other transceiver model that I’m aware of since the FT-51R.

 

Thanks for adding it correctly, Lynn.

 

73 de Dennis KD7CAC
Scottsdale, AZ



On Apr 27, 2020, at 6:48 AM, Ryszard Labus via groups.io <r.labus@...> wrote:

 

It works well now.

<lobbcmjhfakpnhcf.png>

Really good job.
Thank You.

R.

W dniu 2020-04-27 o 14:00, Lynn Deffenbaugh pisze:

Well, because those notes were accumulated from the changes done over the past 2 years, not necessarily recently.  FT-3D will be in the next update, hopefully later today as I catch up on more stuff.


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

On 4/27/2020 4:03 AM, Ryszard Labus via groups.io wrote:

What i am doing wrong?

I cant see FT-3D as recognized?

<hicijalgjldiggho.png>

W dniu 2020-04-27 o 05:15, Lynn Deffenbaugh pisze:

12) The recognized ToCalls and Mic-E type codes have been update per Bob's pages.

-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl
-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl

 

-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl
-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl


Re: JS8CAll/FT8 Log Scrapers (Dev 2020/04/26 22:23)

Dennis Griffin
 

Hi Lynn,

I believe that FT1D, FT2D & FT3D are intended to be base model designators, with the R signifying the model being appropriate for the American(?) market.

Each of these were/are also available with a DE suffix as well as the DR suffix, and the FT1D also had an XDR suffix follow-on model.

This is similar to how Icom & Kenwood append an A or an E to many (all?) of their models to signify American or European market models.

I suspect that may be why Bob B listed only FT3D, so that any variation of that base model would be ID’d in APRS correctly.

You may recall seeing this from the TH-D74 FW update notes:

Updated item : (Version 1.08  1.09) [June 26, 2019]

The following features are updated.

1. Enables decoding of standard APRS telemetry format.(Displays telemetry packets sent from the PSAT2.)
2. Enables display of the model name "FT3D" when received an APRS position packet from the Yaesu FT3DR/E.

73 de Dennis KD7CAC
Scottsdale, AZ


On Apr 27, 2020, at 7:59 AM, Lynn Deffenbaugh <kj4erj@...> wrote:

I only mirrored what Bob had listed at http://www.aprs.org/aprs12/mic-e-types.txt

Which leads me to ask if the model number actually includes the final R as you showed but is NOT included in Bob's definitions?

So maybe we got the hyphen right, but are still worng (sic)...

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

On 4/27/2020 10:45 AM, Dennis Griffin wrote:
In case anyone is confused, Yaesu didn’t include a hyphen in the FT1DR, FT2DR & FT3DR HT model descriptors, as they have for every other transceiver model that I’m aware of since the FT-51R.

Thanks for adding it correctly, Lynn.

73 de Dennis KD7CAC
Scottsdale, AZ


On Apr 27, 2020, at 6:48 AM, Ryszard Labus via groups.io <r.labus@...> wrote:

It works well now.

<lobbcmjhfakpnhcf.png>

Really good job.
Thank You.

R.

W dniu 2020-04-27 o 14:00, Lynn Deffenbaugh pisze:
Well, because those notes were accumulated from the changes done over the past 2 years, not necessarily recently.  FT-3D will be in the next update, hopefully later today as I catch up on more stuff.

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

On 4/27/2020 4:03 AM, Ryszard Labus via groups.io wrote:

What i am doing wrong?

I cant see FT-3D as recognized?

<hicijalgjldiggho.png>

W dniu 2020-04-27 o 05:15, Lynn Deffenbaugh pisze:
12) The recognized ToCalls and Mic-E type codes have been update per Bob's pages.
-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl
-- 
SINUX Ryszard Labus
ul. Domaniewska 47/10 02-672 Warszawa
NIP: 548-138-01-53    tel: 666385002
          r.labus@...
http://sinux.pl   http://sinux.com.pl