开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育

Re: next beta build#149 of YAAC, created 2020-May-09

 

Hi Andrew

Just wanted to let you know that I'm still having issues with YAAC not recognizing the Weathercat wx data format with the latest update :(

Here's an extract from the log file

Sun May 10 19:59:43 EDT 2020: WxPoller unable to read weather due to: java.text.ParseException: Unparseable date: "FW6940>APRS,TCPIP*:@102359z4208.54N/07137.00W_252/000g000t056r000p000P000h38b10160WeatherCatV244B2H31"
at java.text.DateFormat.parse(DateFormat.java:366)
at org.ka2ddo.yaac.io.WxnowTxtConnector$WxPoller.run(WxnowTxtConnector.java:104)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Sun May 10 19:59:43 EDT 2020: port WXNOW.TXT: /Users/admin/Library/Application Support/WCWeb/WXNOW.txt failed


and this is the WXNOW.txt file

FW6940>APRS,TCPIP*:@110014z4208.54N/07137.00W_252/000g000t054r000p000P000h44b10160WeatherCatV244B2H31

Any help is much appreciated?


73 de Bob


On Sat, May 9, 2020 at 2:55 PM Andrew P. <andrewemt@...> wrote:
next beta build#149 of YAAC ("Yet Another APRS Client"), created 2020-May-09

downloadable from
? ? ? ? ? ? ? ?or

changes and updates include:
1. yet more improvements and bugfixes in OpenStreetMap importer, including
? ? support for coastline shapefiles and actually fixing tiling of large
? ? bodies of water, and adjusting default assumptions for incomplete OSM
? ? records to account for cases where the assumptions didn't apply (such
? ? as assuming a riverbank is a closed area of a section of the river
? ? [both banks] rather than potentially only one shoreline).
2. fix errors in the Maven pom.xml files provided for an alternate means
? ? of building YAAC. Note that the Ant build.xml files are still the
? ? supported means of building YAAC and its plugins.
3. clean up Javadocs and fill in more missing Javadocs.
4. eliminate incorrect identification of TCPXX as a digipeater alias.
5. more minor performance enhancements.
6. add ability to parse time intervals (Ages) as well as display them.
7. fix up display of the YAAC Help->About dialog, ensuring that it
? ? can't grow excessively large from installing many plugins and increasing
? ? the font size.
8. allow quad-sized icons so if all icons are displayed in double-size
? ? then more significant stations/objects can still be displayed in
? ? a larger size on the map.
9. fix displaying weather stations as old-style weather map symbols
? ? so that the temperature and dew point are in the configured
? ? temperature units instead of fixed at Fahrenheit.
10. fix beacon configuration to ensure any modified beacon record has
? ? ?the chance to be saved when switching to another beacon record,
? ? ?and ensure the controls for setting beacon-specific rates are
? ? ?properly set to the last values for that beacon instance instead
? ? ?of always to the APRS defaults. Also add sanity check to beacon
? ? ?free-text comment in case user puts the word EMERGENCY in the
? ? ?text, just to validate that they really want to announce a real
? ? ?emergency to listening stations.
11. fix configuration wizard to propagate callsign-SSID changes to
? ? ?existing ports rather than only to any new ones (which might not
? ? ?be created when the callsign is changed).
12. add to list of standard APRS-IS backbone rotator domain names, the
? ? ?CWOP rotator (which contains traffic from non-amateur-radio
? ? ?Citizen's Weather Observation Program stations)
13. for the WxNow.TXT port driver, supplement support for the 2-line
? ? ?Cumulus file format with chooseable support for the 1-line
? ? ?Weathercat (TNC2 command-mode frame) format, and allow freely
? ? ?typing the model code of the weather sensor as an alternative
? ? ?to the canned list of model codes.
14. add transmit slowdown to radio ports to try to ensure TNC has time
? ? ?to get the last packet out before pushing a new packet into the
? ? ?TNC, as some TNCs don't have the buffer space for more packets
? ? ?from the computer when the last one hasn't finished going to the
? ? ?radio yet. Was already there for Serial_TNC port type, added for
? ? ?other TNC port types.
15. update the list of referred websites for obtaining OpenStreetMap
? ? ?dataset downloads.
16. restructure the email composition method in the Telemetry Alarm
? ? ?plugin so it can be accessible from other plugins.
17. properly handle weather data in APRS packets when the field is
? ? ?provided but filled with "..." to indicate the sending station
? ? ?does not actually have that data parameter.
18. reduce JVM heap thrashing by replacing calls to
? ? ?StringBuilder.append(s.substring(start,end)) with
? ? ?StringBuilder.append(s, start, end).
19. add more support in core YAAC for inter-plugin data sharing.
20. eliminate spurious re-render of the OpenStreetMap layer just
? ? ?because a new station was heard.
21. refactor MADIS weather data quality check so it can be used
? ? ?elsewhere than just in the Health Monitor view, including in
? ? ?the new Weather Alert plugin (more about this later).
22. fix issue reported on APRSSIG mailing list 8 May 2020 about
? ? ?I-gating packets with embedded carriage return and line feed
? ? ?characters.
23. (provided by James Palmer AG5VQ) fix bugs in the CallsignDB
? ? ?plugin to support multiple licenses/callsigns per individual
? ? ?licensee.
24. fix duplicate speaking of the degree portion of a longitude
? ? ?in the sounds plugin.
25. add new Weather Alert plugin, which reports when certain conditions
? ? ?are detected in local or remote weather data, by verbal speech,
? ? ?email, SMS, highlighting the station on the map, and sending
? ? ?APRS text messages.



Re: next beta build#149 of YAAC, created 2020-May-09

 

Hi, Joe.

Ouch! You found a _very_ obscure bug in the OSM importer. Due to the peculiar methodology used to enter East Lake into OpenStreetMap, as one unlabeled way for the shoreline and one unlabeled way for the small island within the lake, plus a relation with the labelling tying the two ways together, YAAC made the false assumption that everything needed for the outer shoreline was in the original way. This was not the case; all the details (name, type of area, etc.) were on the relation. But YAAC discarded the relation with all the details as being a point-for-point duplicate of the unlabeled way, and YAAC doesn't render ways without labelling information.

This will be fixed in the next build, but I'll have to wait for the next weekly OSM snapshot to be available before I start the all-day import of the planet again. No point in doing it on the current snapshot that will be outdated in a few days.

Andrew, KA2DDO
author of YAAC
________________________________________
From: [email protected] <[email protected]> on behalf of Joseph LaFerla <joe@...>
Sent: Sunday, May 10, 2020 4:51 PM
To: [email protected]
Subject: Re: [yaac-users] next beta build#149 of YAAC, created 2020-May-09

Hi Andrew

Thanks for the new build. The rendering of the mapping in my area around Lake Ontario and Prince Edward County more generally is perfect, as far as I can tell. The shoreline rendering is so good now that small creeks and rivers can easily be discerned even at higher levels of zoom. However, the small (relative to Lake Ontario) lake in front of my house called East Lake is still missing. While the shoreline is there, the area of the map where the lake is is not coloured blue but is still white. The coordinates of the lake are 43.9189 N and 77.2003 W. For reference, there are two weather stations, (mine VA3JLF-1 and VE3EP-1 Ian) on the south east shore of what should be the lake.

Please let me know if I can provide you with any further information to enable you to locate the lake. As I mentioned to you earlier, the lake is found on the OpenStreetMap original mapping.

Thanks again for your efforts. From what you have said before, this map rendering is not for the faint of heart!
Your support of your software is also very much appreciated.

Joe VA3JLF


Re: next beta build#149 of YAAC, created 2020-May-09

 

Hi Andrew

Thanks for the new build.? The rendering of the mapping in my area around Lake Ontario and Prince Edward County more generally is perfect, as far as I can tell.? The shoreline rendering is so good now that small creeks and rivers can easily be discerned even at higher levels of zoom.? However, the small (relative to Lake Ontario) lake in front of my house called East Lake is still missing. While the shoreline is there, the area of the map where the lake is is not coloured blue but is still white. ? The coordinates of the lake are 43.9189 N and 77.2003 W.? For reference, there are two weather stations, (mine VA3JLF-1 and VE3EP-1 Ian) on the south east shore of what should be the lake.

Please let me know if I can provide you with any further information to enable you to locate the lake.? As I mentioned to you earlier, the lake is found on the OpenStreetMap original mapping.?

Thanks again for your efforts.? From what you have said before, this map rendering is not for the faint of heart!
? Your support of your software is also very much appreciated.?

Joe VA3JLF


Re: next beta build#149 of YAAC, created 2020-May-09

 

This is good news. Thanks!

I'll set up a test station this week to check out 13 and 14.

I'm excited about 25, and especially for parsing remote data. If the next version could send tweets it would be perfect, as weather reporters in our state use Twitter.


next beta build#149 of YAAC, created 2020-May-09

 

next beta build#149 of YAAC ("Yet Another APRS Client"), created 2020-May-09

downloadable from
or

changes and updates include:
1. yet more improvements and bugfixes in OpenStreetMap importer, including
support for coastline shapefiles and actually fixing tiling of large
bodies of water, and adjusting default assumptions for incomplete OSM
records to account for cases where the assumptions didn't apply (such
as assuming a riverbank is a closed area of a section of the river
[both banks] rather than potentially only one shoreline).
2. fix errors in the Maven pom.xml files provided for an alternate means
of building YAAC. Note that the Ant build.xml files are still the
supported means of building YAAC and its plugins.
3. clean up Javadocs and fill in more missing Javadocs.
4. eliminate incorrect identification of TCPXX as a digipeater alias.
5. more minor performance enhancements.
6. add ability to parse time intervals (Ages) as well as display them.
7. fix up display of the YAAC Help->About dialog, ensuring that it
can't grow excessively large from installing many plugins and increasing
the font size.
8. allow quad-sized icons so if all icons are displayed in double-size
then more significant stations/objects can still be displayed in
a larger size on the map.
9. fix displaying weather stations as old-style weather map symbols
so that the temperature and dew point are in the configured
temperature units instead of fixed at Fahrenheit.
10. fix beacon configuration to ensure any modified beacon record has
the chance to be saved when switching to another beacon record,
and ensure the controls for setting beacon-specific rates are
properly set to the last values for that beacon instance instead
of always to the APRS defaults. Also add sanity check to beacon
free-text comment in case user puts the word EMERGENCY in the
text, just to validate that they really want to announce a real
emergency to listening stations.
11. fix configuration wizard to propagate callsign-SSID changes to
existing ports rather than only to any new ones (which might not
be created when the callsign is changed).
12. add to list of standard APRS-IS backbone rotator domain names, the
CWOP rotator (which contains traffic from non-amateur-radio
Citizen's Weather Observation Program stations)
13. for the WxNow.TXT port driver, supplement support for the 2-line
Cumulus file format with chooseable support for the 1-line
Weathercat (TNC2 command-mode frame) format, and allow freely
typing the model code of the weather sensor as an alternative
to the canned list of model codes.
14. add transmit slowdown to radio ports to try to ensure TNC has time
to get the last packet out before pushing a new packet into the
TNC, as some TNCs don't have the buffer space for more packets
from the computer when the last one hasn't finished going to the
radio yet. Was already there for Serial_TNC port type, added for
other TNC port types.
15. update the list of referred websites for obtaining OpenStreetMap
dataset downloads.
16. restructure the email composition method in the Telemetry Alarm
plugin so it can be accessible from other plugins.
17. properly handle weather data in APRS packets when the field is
provided but filled with "..." to indicate the sending station
does not actually have that data parameter.
18. reduce JVM heap thrashing by replacing calls to
StringBuilder.append(s.substring(start,end)) with
StringBuilder.append(s, start, end).
19. add more support in core YAAC for inter-plugin data sharing.
20. eliminate spurious re-render of the OpenStreetMap layer just
because a new station was heard.
21. refactor MADIS weather data quality check so it can be used
elsewhere than just in the Health Monitor view, including in
the new Weather Alert plugin (more about this later).
22. fix issue reported on APRSSIG mailing list 8 May 2020 about
I-gating packets with embedded carriage return and line feed
characters.
23. (provided by James Palmer AG5VQ) fix bugs in the CallsignDB
plugin to support multiple licenses/callsigns per individual
licensee.
24. fix duplicate speaking of the degree portion of a longitude
in the sounds plugin.
25. add new Weather Alert plugin, which reports when certain conditions
are detected in local or remote weather data, by verbal speech,
email, SMS, highlighting the station on the map, and sending
APRS text messages.


Re: duplicate messages from new subscribers

 

I sent my initial message twice because the first time I did not see any
indication that it had been sent.
The second time, I noticed the header about moderator approval.

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Andrew P.
Sent: Thursday, May 7, 2020 7:18 PM
To: [email protected]
Subject: [yaac-users] duplicate messages from new subscribers

Greetings, all.

I'm not sure if it's the new subscribers sending in duplicate, or a bug
("feature"?) of 开云体育, but I find most new message submitters have two
new messages waiting for moderation approval from me.

No need to send it twice; I'll get to it as soon as I can get to my
computer. It's too hard to use the 开云体育 admin screens on a cellphone.

The group is currently configured to require moderator approval for anyone's
first message to the group, since anyone can join without requiring
moderator approval. I haven't yet have to reinstate moderation on anyone yet
(what a polite group!).

Andrew, KA2DDO
author of YAAC
mailing list moderator
...


duplicate messages from new subscribers

 

Greetings, all.

I'm not sure if it's the new subscribers sending in duplicate, or a bug ("feature"?) of 开云体育, but I find most new message submitters have two new messages waiting for moderation approval from me.

No need to send it twice; I'll get to it as soon as I can get to my computer. It's too hard to use the 开云体育 admin screens on a cellphone.

The group is currently configured to require moderator approval for anyone's first message to the group, since anyone can join without requiring moderator approval. I haven't yet have to reinstate moderation on anyone yet (what a polite group!).

Andrew, KA2DDO
author of YAAC
mailing list moderator


Re: Fixes for some defects in the callsigndb plugin

 

Thank you for taking a look at that. If you can send me updated source or Unix/Linux patch files, I will merge that into the build I was planning on releasing tomorrow (if I don't get it done tonight).

That build already has some significant improvements and some new features available coming up.

Andrew, KA2DDO
author of YAAC


Fixes for some defects in the callsigndb plugin

 

Andrew,

I am a retired software developer and Extra class Ham, AG5VQ. I recently started experimenting with APRS and found YAAC to be both interesting and in active development.

While experimenting with the callsigndb plugin, I discovered the following defects:
  • Looking up call signs loaded from the FCC DB shows at most the call sign, country, status, and expiration date.
  • Many amateur callsigns from the ACMA database are not found, because clients (e.g. Client id 118314, the Central Highlands Amateur Radio Club) may have multiple call signs.
  • The sequence (No callsigndb.dat; Load RAC; Exit; Load RAC) results in
    java.io.IOException: unable to move obsolete DB .dat file out of the way
  • The sequence (No callsigndb.dat; Load FCC; Load FCC) results in multiple EOFExceptions.
  • Reloading call sign source can cause an unnecessary rebuild of the DB, e.g., due to mismatches between null valued Strings loaded from callsigndb.dat and empty Strings loaded from FCC, etc.
I have created fixes for these defects and hope you will be interested in incorporating them in the next version of the plugin.

Thank you for creating YAAC and for making it so useful, easy to understand and modify.

Jim Palmer


Re: more digi settings

 

High altitude balloon filers do use 144.390 but there is no need there to use a >high transmit rate and it's suggested to use a Wide2-1 path. That's more than >enough to get the position painted on the internet and help with payload >recovery if the balloon gets out of range.
Actually, it's suggested to use no digipeat path for high altitude balloons, as at their typical cruising altitude, they can hit several counties directly without digipeating, so waking up several dozen digipeaters for a first hop is also discourteous. The best balloon setups change their path based on their altimeter, so they only digipeat when close to the ground or landed where they need the digipeat support.


Re: more digi settings

 

Just curious.? Are there dog trackers on the 2 meter band or did you cobble something together?
The maximal update rate I was able to experiment with was to hard program and test transmit a position once every 3 seconds.? I did the testing off the national frequency and it was the maximum rate the receiver could decode the position packet.? There was no digipeating or messaging.? Just wanted to see if it could be done to track a remote device.? I never tried instituting it in the field though.

I would never do high rate reporting on the national frequency.? That is so discourteous.? For high powered rocket tracking, once every 5 seconds is enough and I mainly use 70cm trackers.? If I flew a 2 meter one, again I'd be off 144.390 and use another frequency for my own personal monitoring.

High altitude balloon filers do use 144.390 but there is no need there to use a high transmit rate and it's suggested to use a Wide2-1 path.? That's more than enough to get the position painted on the internet and help with payload recovery if the balloon gets out of range.

Kurt KC9LDH

On Sunday, May 3, 2020, 04:27:42 PM CDT, scotty ratcliffe <scottyratcliffe@...> wrote:


Right now i have two radios running in to YAAC, 1 on 144.390 national frequency, the other on a different frequency for my dog trackers. I have the dog trackers transmitting a a high rate. Is it possible to "store and forward" say 30 seconds of packets from 2 radio and send in burst?


Re: more digi settings

 

That sounds dangerously like a way to clog the national channel with your burst. Sure, you'd save a tiny bit of time not having to key up and send multiple flag bytes on the channel before starting subsequent packets, but several models of TNCs can't handle that packet rate (they expect dead time before the next packet to get the last packet forwarded to the computer, probably because they don't have multi-threaded firmware), and it wouldn't reduce the total amount of time you would be holding the channel by very much.

Just how many packets were you planning on bursting in each batch, and how often? Or, in other words, what percentage of the shared national channel's local bandwidth were you planning to consume with these bursts? With the average size of an APRS packet, the 1200-baud local channel can't handle more than about 900 packets in a a half hour from all nearby stations combined, and that's with stations who listen for clear-channel before transmitting and otherwise "play well" with other channel users, so as to minimize wasted channel time due to collisions.

Note that normal APRS stations send their data at a much slower rate than when the data comes in. For example, a GPS receiver typically provides an updated position every second. But the fastest "polite" rate for sending APRS position reports for one originating station is no more often than once a minute (i.e., 1/60 of the data points), and is more typically every 10 minutes, depending on the rate of motion of the reporting station. Similarly, some weather stations can report data as often as once a second, but typically only send to APRS once every 10 to 15 minutes (how fast does weather really change?). Also, note that most digipeaters (including YAAC) will retransmit out the receiving port; this is so stations on the "other side" of the digipeater can hearing the originating station's packets (i.e., the whole point of a digipeater), so unless your private channel port is receive-only, you will be interfering with your own trackers (especially if they are transmit-only trackers that don't listen for a clear channel before transmitting).

So, unless you plan on downsampling the dog-tracker position reports from your private channel before retransmitting them, and staggering the resampling, you will probably annoy all the other local users of the national RF channel.

There is presently no down-sampling feature for digipeated packets in YAAC. On the other hand, YAAC (like most well-behaving digipeaters) automatically drops duplicate packets from any specific received station so it will only forward a duplicated packet no more often than every 30 seconds. This is a digipeater feature to protect the channel from originating stations making excessive transmissions, such that the excessive transmissions won't be multiplied by the digipeaters.

I presume each of your dog-trackers has a unique station ID (and would therefore appear as a unique originating station on APRS)? That might bypass the digipeater throttling. If they all use your callsign and have the dog instance in the packet body, they might get throttled unpredictably, depending on the throttling algorithm implementation in each digipeater.

I would strongly recommend slowing down your dog-trackers' transmit rate. After all, the dogs can't run _that_ fast, and standard APRS position data only has a quantized resolution of about +/- 60 feet (well within the position error of GPS receivers without perfect skyview). And slowing down the tracker transmission rate would definitely extend the trackers' battery life. Either that, or use your own frequency instead of the nationally shared frequency. I know of several bicycle events that do that in order to get more frequent updates from multiple trackers without interference.

Just my $.02.

Andrew, KA2DDO
author of YAAC
________________________________________
From: [email protected] <[email protected]> on behalf of scotty ratcliffe <scottyratcliffe@...>
Sent: Sunday, May 3, 2020 5:27 PM
Subject: Re: [yaac-users] more digi settings

Right now i have two radios running in to YAAC, 1 on 144.390 national frequency, the other on a different frequency for my dog trackers. I have the dog trackers transmitting a a high rate. Is it possible to "store and forward" say 30 seconds of packets from 2 radio and send in burst?


Re: more digi settings

 

Right now i have two radios running in to YAAC, 1 on 144.390 national frequency, the other on a different frequency for my dog trackers. I have the dog trackers transmitting a a high rate. Is it possible to "store and forward" say 30 seconds of packets from 2 radio and send in burst?


Re: Not saving objects

 

You were correct Andrew, very easy fix, I must have look at that page 5 times and not seen it. Thank you for your help!?


On Sun, May 3, 2020 at 10:52 AM, Andrew P.
<andrewemt@...> wrote:
Persisting locally-defined objects across restarts is easy. This is a configurable capability in YAAC. Go to the menu choice File->Configure->Expert Mode, select the Behavior tab, and check the checkbox labelled "Restore locally-originated objects when YAAC restarts".

________________________________________

From: [email protected] <[email protected]> on behalf of ab8xg via groups.io <ab8xg=[email protected]>
Sent: Saturday, May 2, 2020 7:36 PM
To: [email protected]
Subject: [yaac-users] Not saving objects

Hello all and thanks for letting me join the group.
The problem I am having is when I create an object it works fine as long as I have the program running, or don't loose power etc. Then the object is gone and I have to do it over. Can't find a place to save it. It is marked as permanent on the setup menu. Any way not a huge deal I would just like to find out if I am missing something. And I'm sure I am.

Thanks
Kenny Coen /AB8XG


<>




Re: more digi settings

 

Greetings.

What exactly do you want to do here?

YAAC already supports timeslotting, configurable on a port-by-port basis, although that is limited by how much extra timing baggage the external TNC adds. I am adding a feature to _prevent_ consecutive packet sends, because I have had reported to me that a lot of TNCs can't handle getting a second packet from the computer while the first packet isn't finished transmitting yet, such that back-to-back packets cause the second packet to be dropped or destroyed, and not all USB-to-RS232 interfaces and TNCs supports hardware flow control (so the computer can be held back by the TNC until the TNC can accept another packet).

Awaiting your clarification of your feature needs....

Andrew, KA2DDO
author of YAAC

________________________________________
From: [email protected] <[email protected]> on behalf of scotty ratcliffe <scottyratcliffe@...>
Sent: Friday, May 1, 2020 7:18 PM
Subject: [yaac-users] more digi settings

Hello is it possiable to add more digi setting like conesctive packet send. and to set the time to hold packets for the burst send.
_._,_._,_


Re: Not saving objects

 

Persisting locally-defined objects across restarts is easy. This is a configurable capability in YAAC. Go to the menu choice File->Configure->Expert Mode, select the Behavior tab, and check the checkbox labelled "Restore locally-originated objects when YAAC restarts".

________________________________________
From: [email protected] <[email protected]> on behalf of ab8xg via groups.io <ab8xg@...>
Sent: Saturday, May 2, 2020 7:36 PM
To: [email protected]
Subject: [yaac-users] Not saving objects

Hello all and thanks for letting me join the group.
The problem I am having is when I create an object it works fine as long as I have the program running, or don't loose power etc. Then the object is gone and I have to do it over. Can't find a place to save it. It is marked as permanent on the setup menu. Any way not a huge deal I would just like to find out if I am missing something. And I'm sure I am.

Thanks
Kenny Coen /AB8XG

<>


Not saving objects

 

Hello all and thanks for letting me join the group.?
The problem I am having is when I create an object it works fine as long as I have the program running, or don't loose power etc. Then the object is gone and I have to do it over. Can't find a place to save it. It is marked as permanent on the setup menu. Any way not a huge deal I would just like to find out if I am missing something. And I'm sure I am.?

Thanks
Kenny Coen /AB8XG


Re: New

 

开云体育

Thank you.


On May 2, 2020, at 11:13 AM, Andrew P. <andrewemt@...> wrote:

?The recommended place to begin is with a radio listening to your local traffic through a TNC (hardware or software). If you don't already have a hardware TNC, the software ones actually perform much better and only require a soundcard interface to your radio.

You don't need a passcode unless you're planning on sending traffic to the APRS-IS Internet backbone. You can do radio operations or receive-only Internet without one.

If you decide you want to send to APRS-IS, then, if you don't have a Logbook of the World certificate (so you can use the secure means to log into the backbone), you need to privately email the author of your chosen software and tell them your identity and callsign so they can verify you are a licensed amateur radio operator and then issue you a passcode.

Hope this helps.

Andrew, KA2DDO
author of YAAC


Re: New

 

The recommended place to begin is with a radio listening to your local traffic through a TNC (hardware or software). If you don't already have a hardware TNC, the software ones actually perform much better and only require a soundcard interface to your radio.

You don't need a passcode unless you're planning on sending traffic to the APRS-IS Internet backbone. You can do radio operations or receive-only Internet without one.

If you decide you want to send to APRS-IS, then, if you don't have a Logbook of the World certificate (so you can use the secure means to log into the backbone), you need to privately email the author of your chosen software and tell them your identity and callsign so they can verify you are a licensed amateur radio operator and then issue you a passcode.

Hope this helps.

Andrew, KA2DDO
author of YAAC


New

 

Hi.

im new to YAAC. ?How do I get a passcode? ?Where do I begin?

delivers1234
kr3lim