Date   

Re: interoperating with a Satellite tracker

Dave AA6YQ
 

+ AA6YQ comments below

I particularly enjoy the feature set of gpredict. Have a peek here https://sourceforge.net/projects/gpredict/ It has fairly active development having been most recently revised around 5 months ago. It utilizes the Hamlib interface for radio and rotator control. That likely complicates its potential interaction with the DXLab suite but it might be worth a look anyway.

+ In the model that Joe W4TV suggested earlier in this thread, the satellite tracking application would directly control both the transceiver and the AZ/EL rotator, and it would continuously convey the current RX frequency, TX frequency, and Mode to Commander via DDE or UDP or TCP. I'll check to see if gpredict has this ability.

+ Thanks!

73,

Dave, AA6YQ


Re: interoperating with a Satellite tracker

David Andreatta - WD0HXN
 

Hi, Dave, all;

I particularly enjoy the feature set of gpredict. Have a peek here https://sourceforge.net/projects/gpredict/  It has fairly active development having been most recently revised around 5 months ago. It utilizes the Hamlib interface for radio and rotator control. That likely complicates its potential interaction with the DXLab suite but it might be worth a look anyway.

Thanks for all the great work and support!

73,

Dave Andreatta
WD0HXN
Erie, CO


On Saturday, September 7, 2019, 8:08:15 PM MDT, Dave AA6YQ <aa6yq@...> wrote:


*** snip ***

Besides SatPC32 and Orbitron, what other Windows-hosted satellite trackers should I investigate?

      73,

                Dave, AA6YQ





Re: interoperating with a Satellite tracker

Dave AA6YQ
 

+ AA6YQ comments below

On Sat, Sep 7, 2019 at 08:01 PM, John Feist wrote:

A possible good reference

+ Thanks, John!

      73,

          Dave, AA6YQ


Re: interoperating with a Satellite tracker

John Feist
 

A possible good reference

At one time I used a Dos based instatrack it was a hardware/software Az/El controller. Probably long gone. Paul KB5MU was very much involved.


On Sat, Sep 7, 2019 at 7:08 PM Dave AA6YQ <aa6yq@...> wrote:
While at the Northeast HamXposition today, I spent some time at the N1T satellite station with Fred AB10C, a long-time DXLab user.
This station was controlled by MacDoppler running on an Apple computer. MacDoppler can be configured to broadcast UDP messages
conveying the current doppler-adjusted RX and TX frequencies. These messages are not documented, but Fred has reverse-engineering
them. It should be possible to extend Commander to treat MacDoppler as a "radio model". With this model selected, Commander would
accept the RX and TX frequencies reported in the UDP messages and convey these frequencies to the other DXLab applications; this
would enable DXKeeper to correctly log the frequencies in satellite QSOs, for example. While DXLab can be run on an Apple by using
Parallels or equivalent, most users of this approach would run MacDoppler on Apple that is network-connected to a PC running DXLab.

When I asked about PC-hosted satellite trackers other than SatPC32, Fred mentioned Orbitron. From an installation and initial use
perspective, Orbitron seems significantly better than SatPC32. However, it communicates RX and TX frequencies, antenna azimuth, and
antenna elevation via one DDE broadcast. Receiving this broadcast would enable Commander to convey RX and TX frequencies to the
other DXLab applications (as described above), but unfortunately would also require extending DXView to implement AZ/EL rotator
control; I don't like spending time on wheel re-invention.

Besides SatPC32 and Orbitron, what other Windows-hosted satellite trackers should I investigate?

       73,

                Dave, AA6YQ





interoperating with a Satellite tracker

Dave AA6YQ
 

While at the Northeast HamXposition today, I spent some time at the N1T satellite station with Fred AB10C, a long-time DXLab user.
This station was controlled by MacDoppler running on an Apple computer. MacDoppler can be configured to broadcast UDP messages
conveying the current doppler-adjusted RX and TX frequencies. These messages are not documented, but Fred has reverse-engineering
them. It should be possible to extend Commander to treat MacDoppler as a "radio model". With this model selected, Commander would
accept the RX and TX frequencies reported in the UDP messages and convey these frequencies to the other DXLab applications; this
would enable DXKeeper to correctly log the frequencies in satellite QSOs, for example. While DXLab can be run on an Apple by using
Parallels or equivalent, most users of this approach would run MacDoppler on Apple that is network-connected to a PC running DXLab.

When I asked about PC-hosted satellite trackers other than SatPC32, Fred mentioned Orbitron. From an installation and initial use
perspective, Orbitron seems significantly better than SatPC32. However, it communicates RX and TX frequencies, antenna azimuth, and
antenna elevation via one DDE broadcast. Receiving this broadcast would enable Commander to convey RX and TX frequencies to the
other DXLab applications (as described above), but unfortunately would also require extending DXView to implement AZ/EL rotator
control; I don't like spending time on wheel re-invention.

Besides SatPC32 and Orbitron, what other Windows-hosted satellite trackers should I investigate?

73,

Dave, AA6YQ


Re: Dx lab dxkeeper feature suggestion request

Dave AA6YQ
 

+ AA6YQ comments below

I'm open to suggestions of other sat tracking options that work with dxlabs packages...

+ The question is whether there's a "better" satellite tracking application that's suited to interoperation with DXLab along the lines that Joe W4TV suggested earlier in this thread.

73,

Dave, AA6YQ


Re: Dx lab dxkeeper feature suggestion request

Bill Pence
 

I'm open to suggestions of other sat tracking options that work with dxlabs packages...


On Sat, Sep 7, 2019, 12:37 AM Dave AA6YQ <aa6yq@...> wrote:
* More AA6YQ comments below

>snip<


Dave, as an alternative to "Sat mode" support for the FT-847, you might want to consider a "SatPC32" transceiver (that would provide a generic satellite support).  Two clips from the web site:

> Further, the program provides a constantly active DDE interface, which
> allows third-party-programs to receive the antenna positions,
> frequencies and modes calculated by SatPC32.

> The frequency- and mode-control works with the following radios:
>
> Yaesu transceivers FT-736R, FT-847,   FT-817, FT-857 and FT-897,
>
> Kenwood transceivers TS-790E/A and TS-2000,
>
> ICOM transceivers IC-820, IC-821,  IC-910H und IC-9100,
>
> ICOM receivers and transmitters, that work with the same cat protocol
> (i.e. IC-275, IC-475).

DDE documentation <http://www.dk1tb.de/manual_e.htm#RemoteControl> (such as it is) is in the Documents page with demo code in the download.

+ I don't see either DDE documentation or demo code in the URL you've cited.

* I found the DDE documentation further down in the document you cited, and I found the DDE demo in the SatPC32 folder on my Windows 10 test system. SatPC32 will not control either my IC-706 or my IC-7200 -- neither of which is a Satellite radio. The DDE demo says "connected to SatPC32", but "**NO SATELLITE**" -- even though SatPC32 shows AO-73 selected in the upper-left corner of its Main window.

* From what I've seen of its user interface and documentation, SatPC32 looks like a poor choice as the satellite tracker with which DXLab interoperates.

       73,

              Dave, AA6YQ





Re: RESOLVED - Missing Spots in DX-Atlas

Russ Ravella
 

Should anyone else make the same mistake I did, let me post what happened after I responded to Dave's request above which resolved my confusion (there was no real problem).

As you can see, Dave had me light up the entire selection space.  That did indeed reveal every spot on the map that survived my SC filters as far as I could see (as you know where there are a lot of spots the map can get cluttered making it hard to verify).  Anticipating what Dave was going to have me do next, I started unselecting each option one-by-one until spots that I thought should show up that didn't disappeared again.  This revealed that I had only selected two of the three NA regions as origins in DXView>Plot Settings>Origin but I have all three selected for my SC Origin filter.  So, as usual, DXL was doing exactly what it was being asked to do.

For what it's worth, the reason I have things set up this way is I live in a highly HOA constrained neighborhood and have a pretty basic antenna.  With that, I am especially unlikely to hear (let alone be able to work) any station spotted from outside the US or even my region of the US.  Also, I am currently concentrating on non-US station goals.  So I usually look at spots OF anywhere but the US, FROM only the US.  I vacillate on the value of including the two NA regions I'm not in as Origin options (if I don't there are often few if any spots at all).  Apparently at some point I selected all three as spot sources but had only two selected for display (in DX Atlas' configuration).  So it looked like spots in SC weren't being displayed on the map that should be.  Following Dave's diagnostic approach revealed the problem.  Since there might be others with a similar game plan, I'd make sure you make similar selections In SC and Map options to avoid this confusion.

By the way, as I was completing the last step, I did indeed receive an email from Dave suggesting I do exactly that - of course...


Re: Dx lab dxkeeper feature suggestion request

Dave AA6YQ
 

* More AA6YQ comments below

snip<

Dave, as an alternative to "Sat mode" support for the FT-847, you might want to consider a "SatPC32" transceiver (that would provide a generic satellite support). Two clips from the web site:

Further, the program provides a constantly active DDE interface, which
allows third-party-programs to receive the antenna positions,
frequencies and modes calculated by SatPC32.
The frequency- and mode-control works with the following radios:

Yaesu transceivers FT-736R, FT-847, FT-817, FT-857 and FT-897,

Kenwood transceivers TS-790E/A and TS-2000,

ICOM transceivers IC-820, IC-821, IC-910H und IC-9100,

ICOM receivers and transmitters, that work with the same cat protocol
(i.e. IC-275, IC-475).
DDE documentation <http://www.dk1tb.de/manual_e.htm#RemoteControl> (such as it is) is in the Documents page with demo code in the download.

+ I don't see either DDE documentation or demo code in the URL you've cited.

* I found the DDE documentation further down in the document you cited, and I found the DDE demo in the SatPC32 folder on my Windows 10 test system. SatPC32 will not control either my IC-706 or my IC-7200 -- neither of which is a Satellite radio. The DDE demo says "connected to SatPC32", but "**NO SATELLITE**" -- even though SatPC32 shows AO-73 selected in the upper-left corner of its Main window.

* From what I've seen of its user interface and documentation, SatPC32 looks like a poor choice as the satellite tracker with which DXLab interoperates.

73,

Dave, AA6YQ


Re: Missing Spots in DX-Atlas

Dave AA6YQ
 

* more AA6YQ comments below

Sorry, should have addressed that in my initial post. I have noticed it before. I can't say for sure that it's always been the case but it has often been the case. I also should have mentioned my configuration hasn't changed in quite awhile other than routine Win10 updates (I'm holding at 1803 but allow updates to it) and regular updates to everything else.

* As a first step, on the "Plot Settings" tab of DXView's Configuration window, check very box in the "Band Filter", "Mode Filter", "Continent Filter" and "Origin Filter" panels -- including the ? boxes. Then set the Selection panel's Lifetime to 3 hours.

* From that point forward, do active stations shown on SpotCollector's Main window not appear on DX Atlas? If so, please

1. make a screen shot of SpotCollector's Main window showing an active station that does not appear on DX Atlas

2. make a screen shot of DX Atlas

3. attach both screen shots to an email message, and send the message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ


Re: Missing Spots in DX-Atlas

Russ Ravella
 

Sorry, should have addressed that in my initial post. I have noticed it before. I can’t say for sure that it’s always been the case but it has often been the case. I also should have mentioned my configuration hasn’t changed in quite awhile other than routine Win10 updates (I’m holding at 1803 but allow updates to it) and regular updates to everything else.

On Sep 6, 2019, at 8:56 PM, Dave AA6YQ <aa6yq@...> wrote:

+ AA6YQ comments below

I’m noticing lots of spots that survive my SC filter setup (Continent and Orgin and (Age < 60 minutes)) aren’t plotted on the DX-Atlas map but many are. DXView Config>Plot Settings>Selection>Lifetime is set to 1 hr (and Spots + QSOs are selected), all bands and modes are selected, everything in Band Filter except 4,2,70 and ? are selected (which are not = missing plots), and the Continent and origin filters are set same as in SC. Can’t see anything in Config>World Map that would seem to explain it. I can’t see a pattern in which spots aren’t plotted.

I’ve got something set wrong but can’t find it. Any help would be appreciated as always.

+ Have there always been missing spots in DX Atlas, or is this new behavior? If the latter, when did this behavior start, and what configuration changes did you make around that time?

73,

Dave, AA6YQ




Re: Missing Spots in DX-Atlas

Dave AA6YQ
 

+ AA6YQ comments below

I’m noticing lots of spots that survive my SC filter setup (Continent and Orgin and (Age < 60 minutes)) aren’t plotted on the DX-Atlas map but many are. DXView Config>Plot Settings>Selection>Lifetime is set to 1 hr (and Spots + QSOs are selected), all bands and modes are selected, everything in Band Filter except 4,2,70 and ? are selected (which are not = missing plots), and the Continent and origin filters are set same as in SC. Can’t see anything in Config>World Map that would seem to explain it. I can’t see a pattern in which spots aren’t plotted.

I’ve got something set wrong but can’t find it. Any help would be appreciated as always.

+ Have there always been missing spots in DX Atlas, or is this new behavior? If the latter, when did this behavior start, and what configuration changes did you make around that time?

73,

Dave, AA6YQ


Re: Dx lab dxkeeper feature suggestion request

Dave AA6YQ
 

+ AA6YQ comments below

Unlike N1MM+ and wsjt-x where N1MM+ suspends its polling and accepts frequency from wsjt-x, Commander is *never* "passive" - Commander is *always* polling for frequency, s-meter, etc.

+ That's necessary to track TX meters like SWR and RF Power output.


Dave, as an alternative to "Sat mode" support for the FT-847, you might want to consider a "SatPC32" transceiver (that would provide a generic satellite support). Two clips from the web site:

Further, the program provides a constantly active DDE interface, which
allows third-party-programs to receive the antenna positions,
frequencies and modes calculated by SatPC32.
The frequency- and mode-control works with the following radios:

Yaesu transceivers FT-736R, FT-847, FT-817, FT-857 and FT-897,

Kenwood transceivers TS-790E/A and TS-2000,

ICOM transceivers IC-820, IC-821, IC-910H und IC-9100,

ICOM receivers and transmitters, that work with the same cat protocol
(i.e. IC-275, IC-475).
DDE documentation <http://www.dk1tb.de/manual_e.htm#RemoteControl> (such as it is) is in the Documents page with demo code in the download.

+ I don't see either DDE documentation or demo code in the URL you've cited.

73,

Dave, AA6YQ


Re: Dx lab dxkeeper feature suggestion request

Dave AA6YQ
 

+ AA6YQ comments below

Looking over the 847 cat commands on page 92 of the 847 user guide, The only thing I see missing is a way to query sat mode status...

+ A description of "Satellite Mode" is missing.

But I think this:
Sending opcode 0x03 gets main vfo
Sending opcode 0x13 gets sat rx vfo data Sending opcode 0x23 gets sat rx vfo data...
Should get the needed data, except for figuring out if the radio is actually in sat mode.

I wonder what the sat vfo read returns if not in sat mode? Maybe 00 00 00 00 or main vfo freq?

Since in sat mode, DX commander is passive, it just needs freq data for both vfo's for logging.

+ I'm unwilling to spend weeks sending you new versions of Commander to test in order to answer questions like those above via trial and error.


We use vspe with n1mm and wsjt-x for contest (This was before the interface from n1mm to wsjt...) Since n1mm is "passive" in this case. We have not had conflicts.

+ Two applications controlling the same radio means that one application can change the radio's state without the other radio knowing about it, the result will be erroneous. For example:

1. App 1: select VFO A

2. App 2: select VFO B

3. App 1: report current VFO's frequency

+ In the above sequence, App 1 expects to receive VFO A's frequency, but it will actually receive VFO B's frequency.


Take this discussion off list?

+ There is nothing to discuss. I will only extend Commander to support the FT-847's Satellite mode if Yeasu either sends me competent CAT documentation, or loans me an FT-847 for a day.

73,

Dave, AA6YQ


Re: Dx lab dxkeeper feature suggestion request

Dave AA6YQ
 

+ AA6YQ comments below

What I was asking was could dxkeeper auto populate the rx/tx freqs from the last logged qso on this satellite...
This way, once I log a qso on satellite (x), each subsequent qso on that sat gets the "inherited" freq from last time on this sat...

+ That would be inconsistent with "DXKeeper logs the frequency and mode reported by Commander". Exceptions increase perceived complexity.

73,

Dave, AA6YQ


Missing Spots in DX-Atlas

Russ Ravella
 

Hi Dave,

I’m noticing lots of spots that survive my SC filter setup (Continent and Orgin and (Age < 60 minutes)) aren’t plotted on the DX-Atlas map but many are.  DXView Config>Plot Settings>Selection>Lifetime is set to 1 hr (and Spots + QSOs are selected), all bands and modes are selected, everything in Band Filter except 4,2,70 and ? are selected (which are not = missing plots), and the Continent and origin filters are set same as in SC.  Can’t see anything in Config>World Map that would seem to explain it. I can’t see a pattern in which spots aren’t plotted.

I’ve got something set wrong but can’t find it.  Any help would be appreciated as always.
Thanks, Russ KR6W 


Re: Dx lab dxkeeper feature suggestion request

Joe Subich, W4TV
 

On 2019-09-06 5:54 PM, Bill Pence wrote:
We use vspe with n1mm and wsjt-x for contest
(This was before the interface from n1mm to wsjt...)
Since n1mm is "passive" in this case. We have not had conflicts.
Unlike N1MM+ and wsjt-x where N1MM+ suspends its polling and
accepts frequency from wsjt-x, Commander is *never* "passive" -
Commander is *always* polling for frequency, s-meter, etc.

Dave, as an alternative to "Sat mode" support for the FT-847, you
might want to consider a "SatPC32" transceiver (that would provide
a generic satellite support). Two clips from the web site:

Further, the program provides a constantly active DDE interface,
which allows third-party-programs to receive the antenna positions,
frequencies and modes calculated by SatPC32.
The frequency- and mode-control works with the following radios:
Yaesu transceivers FT-736R, FT-847, FT-817, FT-857 and FT-897,
Kenwood transceivers TS-790E/A and TS-2000,
ICOM transceivers IC-820, IC-821, IC-910H und IC-9100,
ICOM receivers and transmitters, that work with the same cat protocol
(i.e. IC-275, IC-475).
DDE documentation <http://www.dk1tb.de/manual_e.htm#RemoteControl> (such
as it is) is in the Documents page with demo code in the download.

Any questions can probably be answered by DK1TB:
<http://www.dk1tb.de/indexeng.htm>

73,

... Joe, W4TV


On 2019-09-06 5:54 PM, Bill Pence wrote:
Looking over the 847 cat commands on page 92 of the 847 user guide,
The only thing I see missing is a way to query sat mode status...
But I think this:
Sending opcode 0x03 gets main vfo
Sending opcode 0x13 gets sat rx vfo data
Sending opcode 0x23 gets sat rx vfo data...
Should get the needed data, except for figuring out if the radio is
actually in sat mode.
I wonder what the sat vfo read returns if not in sat mode? Maybe 00 00 00
00 or main vfo freq?
Since in sat mode, DX commander is passive, it just needs freq data for
both vfo's for logging.
We use vspe with n1mm and wsjt-x for contest
(This was before the interface from n1mm to wsjt...)
Since n1mm is "passive" in this case. We have not had conflicts.
Take this discussion off list?
On Fri, Sep 6, 2019, 5:22 PM Bill Pence via Groups.Io <pence.bill=
gmail.com@groups.io> wrote:

I understand, and the radio is old besides...

What I was asking was could dxkeeper auto populate the rx/tx freqs from
the last logged qso on this satellite...
This way, once I log a qso on satellite (x), each subsequent qso on that
sat gets the "inherited" freq from last time on this sat...




On Fri, Sep 6, 2019, 4:26 PM Dave AA6YQ <aa6yq@...> wrote:

+ AA6YQ comments below

I am the satellite op with FT847 trying to get log freq populated in
dxkeeper.

I had tried vspe to connect both commander and satpc32 and while both
connect, commander does not read the 2 vfo's. you explained that the 847
did not support reading both vfo. ( curiously, there are posts on #amsat bb
that seem to indicate it used to work but...)

+ The use of VSPE to enable both Commander and SatPC32 to simultaneously
control your FT-847 is an invalid configuration.

+ Yaesu's FT-847 documentation is ludicrously cryptic. It mentions 3
"read frequency" operations:

1. Read MAIN VFO frequency and mode status

2. Read SAT RX VFO frequency and mode status

3. Read SAT TX VFO frequency and mode status

+ Commander does not currently support the FT-847's "Satellite Mode".
Given the poor documentation, that won't change unless Yaesu loans me a
radio for a day or two.

73,

Dave, AA6YQ






Re: Dx lab dxkeeper feature suggestion request

Bill Pence
 

Looking over the 847 cat commands on page 92 of the 847 user guide,
The only thing I see missing is a way to query sat mode status...
But I think this:
Sending opcode 0x03 gets main vfo
Sending opcode 0x13 gets sat rx vfo data
Sending opcode 0x23 gets sat rx vfo data...
Should get the needed data, except for figuring out if the radio is actually in sat mode.

I wonder what the sat vfo read returns if not in sat mode? Maybe 00 00 00 00 or main vfo freq?

Since in sat mode, DX commander is passive, it just needs freq data for both vfo's for logging.


We use vspe with n1mm and wsjt-x for contest 
(This was before the interface from n1mm to wsjt...)
Since n1mm is "passive" in this case. We have not had conflicts.

Take this discussion off list?

On Fri, Sep 6, 2019, 5:22 PM Bill Pence via Groups.Io <pence.bill=gmail.com@groups.io> wrote:
I understand, and the radio is old besides...

What I was asking was could dxkeeper auto populate the rx/tx freqs from the last logged qso on this satellite...
This way, once I log a qso on satellite (x), each subsequent qso on that sat gets the "inherited" freq from last time on this sat...




On Fri, Sep 6, 2019, 4:26 PM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below

I am the satellite op with FT847 trying to get log freq populated in dxkeeper.

I had tried vspe to connect both commander and satpc32 and while both connect, commander does not read the 2 vfo's.  you explained that the 847 did not support reading both vfo. ( curiously, there are posts on #amsat bb that seem to indicate it used to work but...)

+ The use of VSPE to enable both Commander and SatPC32 to simultaneously control your FT-847 is an invalid configuration.

+ Yaesu's FT-847 documentation is ludicrously cryptic. It mentions 3 "read frequency" operations:

1. Read MAIN VFO frequency and mode status

2. Read SAT RX VFO frequency and mode status

3. Read SAT TX VFO frequency and mode status

+ Commander does not currently support the FT-847's "Satellite Mode".  Given the poor documentation, that won't change unless Yaesu loans me a radio for a day or two.

             73,

                 Dave, AA6YQ






Re: Dx lab dxkeeper feature suggestion request

Bill Pence
 

I understand, and the radio is old besides...

What I was asking was could dxkeeper auto populate the rx/tx freqs from the last logged qso on this satellite...
This way, once I log a qso on satellite (x), each subsequent qso on that sat gets the "inherited" freq from last time on this sat...




On Fri, Sep 6, 2019, 4:26 PM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below

I am the satellite op with FT847 trying to get log freq populated in dxkeeper.

I had tried vspe to connect both commander and satpc32 and while both connect, commander does not read the 2 vfo's.  you explained that the 847 did not support reading both vfo. ( curiously, there are posts on #amsat bb that seem to indicate it used to work but...)

+ The use of VSPE to enable both Commander and SatPC32 to simultaneously control your FT-847 is an invalid configuration.

+ Yaesu's FT-847 documentation is ludicrously cryptic. It mentions 3 "read frequency" operations:

1. Read MAIN VFO frequency and mode status

2. Read SAT RX VFO frequency and mode status

3. Read SAT TX VFO frequency and mode status

+ Commander does not currently support the FT-847's "Satellite Mode".  Given the poor documentation, that won't change unless Yaesu loans me a radio for a day or two.

             73,

                 Dave, AA6YQ






Re: Dx lab dxkeeper feature suggestion request

Dave AA6YQ
 

+ AA6YQ comments below

I am the satellite op with FT847 trying to get log freq populated in dxkeeper.

I had tried vspe to connect both commander and satpc32 and while both connect, commander does not read the 2 vfo's. you explained that the 847 did not support reading both vfo. ( curiously, there are posts on #amsat bb that seem to indicate it used to work but...)

+ The use of VSPE to enable both Commander and SatPC32 to simultaneously control your FT-847 is an invalid configuration.

+ Yaesu's FT-847 documentation is ludicrously cryptic. It mentions 3 "read frequency" operations:

1. Read MAIN VFO frequency and mode status

2. Read SAT RX VFO frequency and mode status

3. Read SAT TX VFO frequency and mode status

+ Commander does not currently support the FT-847's "Satellite Mode". Given the poor documentation, that won't change unless Yaesu loans me a radio for a day or two.

73,

Dave, AA6YQ

22741 - 22760 of 210262