开云体育

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Yaac-Users
  2. Messages
Expanded Topics Messages Polls
Date
Re: Connecting a serial TNC

 

开云体育

The problem on Fedora (as mentioned in the YAAC help files) is that Fedora no longer assumes unprivileged users will be creating lock files in the /var/lock directory (which is now a symlink to /run/lock). Since ordinary users supposedly don't need to use the lock directory, the directory's owner _and_ group is root. You need to become superuser and change the group of the /run/lock directory to the lock group, so the antique locking code in the RXTX library will work. Also, by default, the lock directory is read-only to group, so you'll have to change the permissions to g+w (group lock has write access). Then, the 20+-year-old locking code in RXTX will work.

Hope this helps.

Andrew, KA2DDO
author of YAAC


-------- Original message --------
From: "Eric H. Christensen via groups.io" <eric@...>
Date: 6/21/20 14:01 (GMT-05:00)
To: [email protected]
Subject: [yaac-users] Connecting a serial TNC

I swear I had this working before but for some reason it's not working now.

I'm trying to connect my D72 to YAAC using /dev/ttyUSB0.? When I enter /dev/ttyUSB0 into the device name and select "Test Port" I get the "Unable to bring up Test-Port for Serial_TNC" message.

I have rxtx installed and I'm a member of dialout, lock, and tty, which should be enough permissions to gain access to the port.? I'm able to access the device using minicom.? What am I missing?? I'm using Fedora 32.

73,
Eric WG3K
Connecting a serial TNC

 

I swear I had this working before but for some reason it's not working now.

I'm trying to connect my D72 to YAAC using /dev/ttyUSB0. When I enter /dev/ttyUSB0 into the device name and select "Test Port" I get the "Unable to bring up Test-Port for Serial_TNC" message.

I have rxtx installed and I'm a member of dialout, lock, and tty, which should be enough permissions to gain access to the port. I'm able to access the device using minicom. What am I missing? I'm using Fedora 32.

73,
Eric WG3K
Re: Strange Position Reports

 

If you're referring to my comment about hearing BAMBAM in Idaho, that is incorrect. Because BAMBAM uses a 3 path hop it has a HUGE potentional reach. The digi path is more like 4 hops because of an issue with older KPC units which do not properly mark the WIDE1 digipeat. So many of the next stations digipeat the WIDE1 again, and then properly mark it. It's pretty annoying.?
Re: Strange Position Reports

 

开云体育

Hi,

I was up at steens mountain near Burns and a person was using Aprs on the repeater (non-aprs). ?I think they said the person was traveling around Idaho.

Just fyi


On Jun 19, 2020, at 10:31 PM, Michael - NA7Q <mike.ph4@...> wrote:

?

I understand this thread is old. In fact I stumbled upon in because of the "BAMBAM" station that is operating under very poor ways..

I'm the owner of NICOLI (Nicolai Mountain) and various others APRS stations. But I see NICOLI was discussed by Jeff, so I'll address it.

So NICOLI operates in the most friendly of ways as a WIDE1 digi. It doesn't spew garbage beacons like BAMBAM or many of the other stations around. It beacons a position 1 time per 10 minutes, as is the legal requirement, AND does NOT use a path. I think that is very important. Because I have multiple igates within range, and is heard by many other igates, there is no reason to add a path.?

It also has 1, yes just 1 telemetry beacon that is sent 1 time, yes 1 time PER hour with a 1 hop path. This equals 7 beacons per hour, and only 1 hop in that duration. Pretty good compared to most that just clutter and congest the network beyond belief.

Another fun fact, NICOLI only uses 5 watts on a low gain antenna on top of the 30 foot tower.?

Why does it reach so far? Location location location.
Nicolai Mountain has an incredible path through the Gorge and into the east side almost across the entire station of Washington and Oregon at times.
Frequently my Trout Lake station is able to be heard on Nicolai under normal conditions. Everything about this digi is done with one thing in mind. Provide coverage to an area that isn't covered, reduce congestion, block as many digi beacons as possible that shouldn't be using a path. Unfortunately the unit has the maximum block slots filled up. So some junk gets through. Like BAMBAM....

I've been wanting to get a hold of KI7RUS because of BAMBAM. It's using a seriously bad path, and is able to be heard across the entire state of Washington and Oregon. I heard it coming across a digi in Idaho last week! It's outrageous. It's not even located at the location it beacons. It beacons too frequently for the weather and the telemetry. Which in his case is every 5 minutes. APRS.fi and APRSDirect only update at 10 minute intervals for weather and telemtry. So beaconing more often does nothing.

I hope to get a hold of that guy at some point, and I hope that he is understanding. All too often these guys are not.?

73
NA7Q
Re: Working Satellites w/FT3D

Gervais Fillion
 

开云体育

keith
may i ask what frequencies for those satellites?
i wonder if i can hear them.
thanks
gervais
ve2ckn


De : [email protected] <[email protected]> de la part de Keith Kaiser <wa0tjt@...>
Envoyé : 20 juin 2020 10:29
? : [email protected] <[email protected]>
Objet : [yaac-users] Working Satellites w/FT3D
?
Has anyone out there programmed their FT3d with the splits for AO-91, AO-92, ISS? If so would you be willing to share that file??
I'm curious also about how they should be set up. For example I think I should put the downlink frequency on the B side and the uplink on the A, is this correct??
Additionally how many steps on the uplink side should I set to handle the doppler shifts?
I was able to listen to AO-92 last night but I'm not convinced I had the radio set up correctly for a two way conversation. Any help would be appreciated.
-- Keith

Re: Strange Position Reports

 

I understand this thread is old. In fact I stumbled upon in because of the "BAMBAM" station that is operating under very poor ways..

I'm the owner of NICOLI (Nicolai Mountain) and various others APRS stations. But I see NICOLI was discussed by Jeff, so I'll address it.

So NICOLI operates in the most friendly of ways as a WIDE1 digi. It doesn't spew garbage beacons like BAMBAM or many of the other stations around. It beacons a position 1 time per 10 minutes, as is the legal requirement, AND does NOT use a path. I think that is very important. Because I have multiple igates within range, and is heard by many other igates, there is no reason to add a path.?

It also has 1, yes just 1 telemetry beacon that is sent 1 time, yes 1 time PER hour with a 1 hop path. This equals 7 beacons per hour, and only 1 hop in that duration. Pretty good compared to most that just clutter and congest the network beyond belief.

Another fun fact, NICOLI only uses 5 watts on a low gain antenna on top of the 30 foot tower.?

Why does it reach so far? Location location location.
Nicolai Mountain has an incredible path through the Gorge and into the east side almost across the entire station of Washington and Oregon at times.
Frequently my Trout Lake station is able to be heard on Nicolai under normal conditions. Everything about this digi is done with one thing in mind. Provide coverage to an area that isn't covered, reduce congestion, block as many digi beacons as possible that shouldn't be using a path. Unfortunately the unit has the maximum block slots filled up. So some junk gets through. Like BAMBAM....

I've been wanting to get a hold of KI7RUS because of BAMBAM. It's using a seriously bad path, and is able to be heard across the entire state of Washington and Oregon. I heard it coming across a digi in Idaho last week! It's outrageous. It's not even located at the location it beacons. It beacons too frequently for the weather and the telemetry. Which in his case is every 5 minutes. APRS.fi and APRSDirect only update at 10 minute intervals for weather and telemtry. So beaconing more often does nothing.

I hope to get a hold of that guy at some point, and I hope that he is understanding. All too often these guys are not.?

73
NA7Q
YAAC Telemetry

 

Andrew,

You may recall that several months ago we exchanged messages concerning problems I was having with telemetry alerts. When you announced YAAC release 152 I was encouraged to read points 22, 23, 24, and 25, and I was glad to see that there has been significant progress. However at least one problem still remains. (I am now running YAAC release 153 with telemetry plugin 0.3 installed.)

When I go to the new email configuration page and set up an email server, and then initiate a test message, the message is sent and ultimately received in the email server inbox. This is a significant advance on previous versions when no connection to the server was achieved. However, when I go to the View Telemetry Alarms page and attempt a test message, nothing is received at the specified destination inbox.

Robert Clinton W0BUX/G0BUX
URGENT: new beta build#153 of YAAC, created 2020-Jun-16

 

next beta build#153 of YAAC ("Yet Another APRS Client"), created 2020-Jun-16

downloadable from
or

changes and updates include:
1. [CRITICAL] fix timer breakage across many functions of YAAC that
was introduced in build 152. This also affected rolling log file writing.
2. update tool used to post built-in help files to author's website so it
will also post help for plugins.
3. update forced beaconing to also flush log files to disk immediately
after the forced beaconing.
4. add James Palmer's mnemonics support to the Bookmarks menu.
5. fix logging of transmitted AX.25 packets to not occur until packets
actually leave YAAC (i.e., after timeslotting delays, etc.). Note this
doesn't account for TNC delays waiting for a clear channel, but it is
still more time-accurate than the prior transmit logging.
6. clean-up of plugin help files to better merge with core YAAC help.
7. fix error display code in callsign DB plugin for downloading Canadian
and Australian databases.
8. in MADIS post plugin, add the option of reporting the YAAC receive
time of the weather packets, as opposed to any timestamp the sending
weather station might include in the packets. Note that some weather
stations have seriously incorrect clock settings.
Re: Timed beacon not working beta152

 

I seem to be having the same problem. Here is a small portion of my error log.
How do I reload 151??
Sun Jun 14 12:50:42 MDT 2020:/dev/ttyS0: excessively long time 541msec to receive 62-byte frame
Sun Jun 14 12:51:16 MDT 2020:/dev/ttyS0: excessively long time 641msec to receive 75-byte frame
Sun Jun 14 12:51:17 MDT 2020:/dev/ttyS0: excessively long time 701msec to receive 82-byte frame
Sun Jun 14 12:51:23 MDT 2020:/dev/ttyS0: excessively long time 500msec to receive 58-byte frame
Sun Jun 14 12:52:22 MDT 2020:/dev/ttyS0: excessively long time 642msec to receive 75-byte frame
Sun Jun 14 12:52:58 MDT 2020:/dev/ttyS0: excessively long time 641msec to receive 75-byte frame
purgeStaleTraffic: deleted 41 old msgs and 2 old stations
Sun Jun 14 12:54:01 MDT 2020:/dev/ttyS0: excessively long time 842msec to receive 100-byte frame
Sun Jun 14 12:54:25 MDT 2020:/dev/ttyS0: excessively long time 642msec to receive 75-byte frame
Sun Jun 14 12:55:00 MDT 2020:/dev/ttyS0: excessively long time 339msec to receive 40-byte frame
Sun Jun 14 12:55:25 MDT 2020:/dev/ttyS0: excessively long time 541msec to receive 62-byte frame
Sun Jun 14 12:55:29 MDT 2020:/dev/ttyS0: excessively long time 722msec to receive 84-byte frame
Sun Jun 14 12:55:34 MDT 2020:/dev/ttyS0: excessively long time 480msec to receive 55-byte frame
Sun Jun 14 12:55:52 MDT 2020:/dev/ttyS0: excessively long time 601msec to receive 71-byte frame
Sun Jun 14 12:56:48 MDT 2020:/dev/ttyS0: excessively long time 480msec to receive 55-byte frame
Sun Jun 14 12:57:38 MDT 2020:/dev/ttyS0: excessively long time 802msec to receive 94-byte frame
Sun Jun 14 12:58:16 MDT 2020:/dev/ttyS0: excessively long time 641msec to receive 75-byte frame
purgeStaleTraffic: deleted 18 old msgs and 1 old stations
Sun Jun 14 12:59:02 MDT 2020:/dev/ttyS0: excessively long time 842msec to receive 100-byte frame
Sun Jun 14 12:59:05 MDT 2020:/dev/ttyS0: excessively long time 903msec to receive 107-byte frame
Sun Jun 14 12:59:08 MDT 2020:/dev/ttyS0: excessively long time 601msec to receive 70-byte frame
Sun Jun 14 13:00:01 MDT 2020:/dev/ttyS0: excessively long time 461msec to receive 54-byte frame
Sun Jun 14 13:00:18 MDT 2020:/dev/ttyS0: excessively long time 782msec to receive 93-byte frame
Sun Jun 14 13:00:29 MDT 2020:/dev/ttyS0: excessively long time 721msec to receive 86-byte frame
Sun Jun 14 13:02:00 MDT 2020:/dev/ttyS0: excessively long time 540msec to receive 64-byte frame
Sun Jun 14 13:02:21 MDT 2020:/dev/ttyS0: excessively long time 521msec to receive 61-byte frame
Sun Jun 14 13:02:37 MDT 2020:/dev/ttyS0: excessively long time 843msec to receive 100-byte frame
Sun Jun 14 13:03:16 MDT 2020:/dev/ttyS0: excessively long time 782msec to receive 91-byte frame
purgeStaleTraffic: deleted 76 old msgs and 2 old stations
Sun Jun 14 13:03:47 MDT 2020:/dev/ttyS0: excessively long time 782msec to receive 91-byte frame
Sun Jun 14 13:03:48 MDT 2020:/dev/ttyS0: excessively long time 742msec to receive 88-byte frame
Sun Jun 14 13:03:49 MDT 2020:/dev/ttyS0: excessively long time 742msec to receive 88-byte frame
Sun Jun 14 13:04:36 MDT 2020:/dev/ttyS0: excessively long time 360msec to receive 41-byte frame
Sun Jun 14 13:05:00 MDT 2020:/dev/ttyS0: excessively long time 400msec to receive 47-byte frame
Sun Jun 14 13:05:26 MDT 2020:/dev/ttyS0: excessively long time 843msec to receive 100-byte frame
Sun Jun 14 13:05:34 MDT 2020:/dev/ttyS0: excessively long time 581msec to receive 67-byte frame
Sun Jun 14 13:05:44 MDT 2020:/dev/ttyS0: excessively long time 763msec to receive 89-byte frame
Sun Jun 14 13:06:47 MDT 2020:/dev/ttyS0: excessively long time 581msec to receive 68-byte frame
Sun Jun 14 13:08:20 MDT 2020:/dev/ttyS0: excessively long time 420msec to receive 48-byte frame
purgeStaleTraffic: deleted 44 old msgs and 1 old stations
Sun Jun 14 13:09:47 MDT 2020:/dev/ttyS0: excessively long time 581msec to receive 69-byte frame
Sun Jun 14 13:10:01 MDT 2020:/dev/ttyS0: excessively long time 400msec to receive 47-byte frame
Sun Jun 14 13:10:02 MDT 2020:/dev/ttyS0: excessively long time 460msec to receive 54-byte frame
Sun Jun 14 13:10:30 MDT 2020:/dev/ttyS0: excessively long time 782msec to receive 93-byte frame
Sun Jun 14 13:10:34 MDT 2020:/dev/ttyS0: excessively long time 843msec to receive 100-byte frame
Sun Jun 14 13:10:40 MDT 2020:/dev/ttyS0: excessively long time 1024msec to receive 122-byte frame
Sun Jun 14 13:10:43 MDT 2020:/dev/ttyS0: excessively long time 722msec to receive 86-byte frame
Sun Jun 14 13:10:44 MDT 2020:/dev/ttyS0: excessively long time 541msec to receive 62-byte frame
Sun Jun 14 13:11:00 MDT 2020:/dev/ttyS0: excessively long time 460msec to receive 54-byte frame
Sun Jun 14 13:11:15 MDT 2020:/dev/ttyS0: excessively long time 520msec to receive 61-byte frame
Sun Jun 14 13:11:31 MDT 2020:/dev/ttyS0: excessively long time 561msec to receive 65-byte frame
Sun Jun 14 13:11:59 MDT 2020:/dev/ttyS0: excessively long time 460msec to receive 54-byte frame
Sun Jun 14 13:12:21 MDT 2020:/dev/ttyS0: excessively long time 581msec to receive 68-byte frame
Sun Jun 14 13:14:02 MDT 2020:/dev/ttyS0: excessively long time 602msec to receive 71-byte frame
Sun Jun 14 13:14:17 MDT 2020: invalid message format K5RHD-10>APMI06 => "K5RHD-10>APMI06,WIDE1-1,qAR,N0AUX-1:@141914#3950.70N/10505.14W&PHG8230 Digi/iGate in Arvada, CO DM79", treat as DefaultMessage:
java.lang.IllegalArgumentException: invalid format time '141914#'?

On Sun, Jun 14, 2020 at 7:50 PM Ian Morrison <imorrison@...> wrote:

Hi Andrew,

I see the same thing and had to go back to 151.

?

73, Ian

VE3EP

?

Sent from for Windows 10

?

From: Joseph LaFerla
Sent: Sunday, June 14, 2020 7:32 PM
To: [email protected]
Subject: [yaac-users] Timed beacon not working beta152

?

HI Andrew

I installed the new beta 152 and notice that the timed beacon does not seem to be working.? I have YAAC set to beacon every 30 minutes.? I can beacon by pressing the space bar or the BCN button but the auto beacon does not work.? I downgraded to beta 151 and the timed beacon works fine with no setting changes.? Is there some setting in 152 for the beacon that I have missed?? Thanks for a great program and excellent support as usual.

Thanks and 73

Joe VA3JLF

?



--
Thank You and God Bless?
Richard
?

Richard Beggs? ? ? ? ? ? N0EB? ? ? 145.295
1220 H Street?
?Salida, Co. 81201?
??Email:?Richard.N0EB@...
?Cell 719-239-1788 LL 719-539-5435?
**
?A socialist is basically a communist who doesn’t?
have the power to take everything from their?
citizens at gunpoint ... Yet!
broken beaconing

 

Greetings, all.

Yes, it appears that automatic beaconing was broken by my attempt to not overflow antique hardware TNCs. I am working on a fix now.

Please hold off on upgrading until I get build 153 available.

Andrew, KA2DDO
author of YAAC
Re: Timed beacon not working beta152

 

开云体育

Hi Andrew,

I see the same thing and had to go back to 151.

?

73, Ian

VE3EP

?

Sent from for Windows 10

?

From: Joseph LaFerla
Sent: Sunday, June 14, 2020 7:32 PM
To: [email protected]
Subject: [yaac-users] Timed beacon not working beta152

?

HI Andrew

I installed the new beta 152 and notice that the timed beacon does not seem to be working.? I have YAAC set to beacon every 30 minutes.? I can beacon by pressing the space bar or the BCN button but the auto beacon does not work.? I downgraded to beta 151 and the timed beacon works fine with no setting changes.? Is there some setting in 152 for the beacon that I have missed?? Thanks for a great program and excellent support as usual.

Thanks and 73

Joe VA3JLF

?

0E3CC93CC47544CFB043DD73F6C50A38.png

Re: Timed beacon not working beta152

 

Fast beaconing is the initial rate, as in "go fast when you first get on the air, and slow down if you're not changing anything."

Hmmm... this sounds odd. Could you privately email me the export of your configuration, and your YAAC.out log file? Sounds like something might be broken.

Andrew, KA2DDO

________________________________________
From: [email protected] <[email protected]> on behalf of Joseph LaFerla <joe@...>
Sent: Sunday, June 14, 2020 8:26 PM
To: [email protected]
Subject: Re: [yaac-users] Timed beacon not working beta152

I can't find a setting called "fast" beacon, but my initial repeat rate is 60 and stable slow repeat rate is 1800. Smart beaconing is disabled. If I have missed some setting please tell me what page it is on so I can find it. Note that I said that in beta 151 with all the same settings the auto beacon works perfectly Thanks.

Joe VA3JLF
Re: Timed beacon not working beta152

 

I can't find a setting called "fast" beacon, but my initial repeat rate is 60 and stable slow repeat rate is 1800. Smart beaconing is disabled.? If I have missed some setting please tell me what page it is on so I can find it.? Note that I said that in beta 151 with all the same settings the auto beacon works perfectly Thanks.

Joe VA3JLF
Re: Timed beacon not working beta152

 

What is the fast time for your beacon? A recent feature allowed setting fast to 0, which means don't _ever_ auto-beacon. This was intended for places where automatic station control is prohibited (for example, on the 60-meter band in the US). If you don't have a non-zero fast beacon, that beacon will never transmit automatically.

Andrew, KA2DDO
author of YAAC

________________________________________
From: [email protected] <[email protected]> on behalf of Joseph LaFerla <joe@...>
Sent: Sunday, June 14, 2020 7:32 PM
To: [email protected]
Subject: [yaac-users] Timed beacon not working beta152

HI Andrew

I installed the new beta 152 and notice that the timed beacon does not seem to be working. I have YAAC set to beacon every 30 minutes. I can beacon by pressing the space bar or the BCN button but the auto beacon does not work. I downgraded to beta 151 and the timed beacon works fine with no setting changes. Is there some setting in 152 for the beacon that I have missed? Thanks for a great program and excellent support as usual.

Thanks and 73

Joe VA3JLF
Timed beacon not working beta152

 

HI Andrew

I installed the new beta 152 and notice that the timed beacon does not seem to be working.? I have YAAC set to beacon every 30 minutes.? I can beacon by pressing the space bar or the BCN button but the auto beacon does not work.? I downgraded to beta 151 and the timed beacon works fine with no setting changes.? Is there some setting in 152 for the beacon that I have missed?? Thanks for a great program and excellent support as usual.

Thanks and 73

Joe VA3JLF
Re: next beta build#152 of YAAC, created 2020-Jun-12

 

Thanks. This is great!

I haven't yet been able to get telemetry working, this should do the trick.
next beta build#152 of YAAC, created 2020-Jun-12

 

next beta build#152 of YAAC ("Yet Another APRS Client"), created 2020-Jun-12

downloadable from
or

changes and updates include:
1. fix generation of Maidenhead locators to use more string all-uppercase
as specified in the APRS Protocol Specification.
2. fix round-off errors for decoding day-hour-minute timestamps near end of
month.
3. fix some Javadoc errors in source code.
4. fix reschedulable timers (as used for timeslot code in port drivers) to
actually be reschedulable after they expire.
5. properly handle classpath setup for plugins that reject initialization.
6. fix timer-based logger classes to allow changing the flush rate independent
of the log rollover time, and to allow post-processing of a closed
periodic log file.
7. fix configuration importer to force replaced callsigns to be restricted
to legal AX.25 callsign-SSID syntax.
8. allow popup menu "View URL" and "Send Email" to work on map views (as
well as tabular views).
9. add keyboard mnemonics to Bookmarks menu (per James Palmer AG5VQ).
10. allow popup menu on callsign column of Tracked Station table view.
11. fix NullPointerException problem in Radio View display when rapid
updates are occurring.
12. fix formatting of Credits tab of Help->About dialog.
13. make progress dialog more compact so it won't get in the way during
extremely long background tasks (by James Palmer, AG5VQ).
14. correct errors in implementing MADIS quality checks (particularly the
Level 1 self temporal consistency delta checks), add partial
Level 3 spatial consistency checks.
15. add slot length control for timeslotted APRS ports, so that YAAC knows
when to stop adding packets for transmission when the end of the
timeslot approaches, even if there is more traffic to send.
16. more attempts to improve performance of OpenStreetMap renderer.
17. fix way statistics counters in OpenStreetMap PBF importer.
18. add device interface check to Bluetooth plugin using new plugin
error reporting, so user will be informed if host computer does not
have a Bluetooth interface or does not have a native library for
that operating system.
19. add James Palmer's performance optimizations for downloading and
parsing national public record databases for amateur radio callsigns.
20. enhance MADIS Post plugin to allow user-selectable file format in either
CSV or JSON format, with the option to automatically push a finished
file via HTTP POST or FTP to another host, and add help on how to
use the feature. Default format is that used by previous version
of plugin.
21. have the Small Screen plugin remember the desktop position and size
of its window.
22. augment email client code in Telemetry Alarm plugin to allow non-default
port numbers for the remote SMTP server.
23. allow displaying the defined units of telemetry data (as specified
by the remote station) in telemetry alarms.
24. add built-in help for Telemetry Alarm plugin.
25. restructure Telemetry Alarm plugin configuration so email configuration
is done in the expert-mode configuration dialog as for every other
part of YAAC, and add ability to send self-addressed test emails
to verify the email configuration.
26. fix plugin help index XML files to avoid index merge failures.
27. fix Weather Alert plugin to detect wind gusts from stations that only
report current wind speed and not recent gust peaks.
28. add ability to speak station/object course (direction of travel) in
Sounds plugin.
29. add weather station clock error condition to Weather Alert plugin.
30. more fixups of UoMD findbugs issues.
Re: YAAC and Sat gates

 

开云体育

Thanks Andrew

That explains it.

Bob

On 8/6/20 11:11 pm, Andrew P. wrote:

Greetings.

Re; diff between I-gate and S-gate:
_._,_._,_
Re: YAAC and Sat gates

 

Greetings.

Re; diff between I-gate and S-gate: you said it: the frequency being monitored to forward to the Internet. Also, S-gates generally aren't transmit-capable, i.e., Rx I-gate.

Re: your Maidenhead difficulties: That's odd. The documentation for Maidenhead locators says that lowercase is OK (and even preferred if allowed by the character set in use) for the 2nd pair of letters (at least, according to Wikipedia at ) so that is what YAAC uses when it automatically generates a Maidenhead locator based on the the default beacon's latitude and longitude. However, you can always turn off automatically generating the locator and manually type it in as the first 6 characters of your status text. In the meantime, I'll ask the Direwolf author about it.

Andrew, KA2DDO
author of YAAC
YAAC and Sat gates

 

I'm trying to set up a Sgate in my regional area 160km south of the big smoke.
I'm using a RPi, a RTL-SDR, and direwolf. It works as an Igate.
What's the difference between an I gate and a S gate? Besides the RX frequency.

In testing my S gate I found I get an error at a remote direwolf receiver telling me I'm using a lowercase character in my maidenhead grid like QF55hd
It doesn't like the lower case hd. I tracked this down to my status beacon but there is nowhere to set the grid square on this status beacon page.
There is only space for my text which is how I know it's by status beacon which sends the lower case character.
I remember there was a once only place where you can set the status grid during the initial installation so how can I replace my grid square QF55hd with QF55HD?
Without deleting and re installing YAAC.
Thanks, Bob vk2byf
2561 - 2580 of 2944