APRS-IS filter + error message
Greetings,
Been running YAAC for several years, Debian Linux, Kenwood D710. I have
three profiles: one for terrestrial APRS, one as a digipeater, and one
for satellite (ISS) work.
I'm getting a strange message that I don't recall seeing before on my
terrestrial profile. If I click to edit the APRS-IS port and then close
it, with or without making any changes, I get a window message:
Error saving changes
"You are using an m/NNN filter expression but are not configured to
transmit a beacon through this port,
so you will not receive any packets."
My setting for APRS-IS filter: m/200
I've probably had that setting for several years, and I thought mainly
it meant that I would not be seeing APRS internet traffic unless it was
200 km or closer. I didn't think it had any effect on transmitting.
Also, the error message states that I won't be receiving any packets.
I don't recall seeing this pop-up before. Has something changed?
Thanks!
73, KD0KZE / Paul
|
Re: Satellite filters? Useful or not necessary?
Weeellllll.... None, if I'm painfully honest.? I've only had it up a few hours off and on over the last few days.? I'm still trying to learn as much as I can about "Best practices" settings before I leave it on autopilot.
I've done some more reading over the last day and stumbled on this conversation:
That info is about 4 years old, but it's hard finding anything current.
The delay mentioned there seems like it would serve a similar function as a terrestrial filter, without the effect of completely killing the packet.? Further down in the conversation, another user mentions that Direwolf has a SATGATE function to specifically implement this delay before gating.? The port that I'm going to use for sGate listening is a Direwolf port, so for grins I tried turning that setting on.? As far as I can tell, that delay is strictly implemented in its own gating functions, it seems like it passes heard packets to YAAC immediately.? It also makes mention on the loading text that "SATGATE is a pretty useless function and will probably be removed in future versions."?? Deep in the Direwolf user guide, it has language that "Of course some other IGate probably send the original promptly so this could just be an exercise in futility."? ... still.. best practices, and all that..
It seems like a good idea, but I can't tell if this plan has been abandoned, as the most recent info I can find is from 2017-2018 range, but maybe a checkbox option on the "Ports" tab for "Satellite Gate - 10s delay for gating directly received packets on this port"
I don't know anything about programming, I have no idea how onerous that would be to program, and I can imagine there are a lot of other things higher on the "to-do" list.? Maybe a filter would be easier --- maybe it's not worth bothering at all.? Anyway.. for your consideration.
Thanks for writing and maintaining this software!? Learning it, learning linux, and really getting a deeper understanding of APRS has been hugely interesting these past few months.
JH
|
Re: Satellite filters? Useful or not necessary?
That is an interesting concept. In theory, your assumption is correct; if you are running a sat-gate and a sat user is transmitting within direct receive range of you, it is possible that you could I-gate the packet before the ISS digipeater could send it back. But they would have to be within direct contact (non-digipeated) of your sat-gate for this to happen. YAAC doesn't presently support viscous digipeating, so it wouldn't skip ahead of the ARISS or ISS or RS0ISS digipeat callsign to digipeat your packets itself (assuming the sender was using bad practice by specifying a second ground digipeat alias after the ISS alias). So how many satellite users can you hear directly (ground-wave) at your I-gate? I'm curious whether it's worth implementing such a receive I-gate filter. Andrew, KA2DDO author of YAAC ________________________________________ From: [email protected] < [email protected]> on behalf of johnhaley3@... <johnhaley3@...> Sent: Thursday, May 13, 2021 10:43 PM To: [email protected]Subject: [yaac-users] Satellite filters? Useful or not necessary? I've been running an iGate for about 8-10 years now, but have just recently moved to YAAC running on Raspberry Pi with a TNC-Pi. I love this software, so easy to use. Anyway, I sort of inherited an ancient 2m rig that has something burned out on the transmit side, but that receives very well, and I thought I'd add a second port and do some sGate operations as well. I added a USB sound card and got it working with Direwolf, and both ports are getting along nicely. I have zero experience with ISS/Amsat ops, so my question is this: I know that on 144.390, terrestrial APRS, that most packets are transmitted with the end goal of being gated to the IS backbone, by whatever route the propagation chooses. But anyone trying to work a satellite or the ISS on 145.825 is assumed to be specifically trying to get a packet digipeated by the ISS. If my station happens to directly hear a packet on 145.825 and gate it, it won't ever register as having traversed the ISS hop, right? I would think a station would rather have a packet ignored by ground stations in the hope of hitting the ISS, vs. always getting intercepted by a ground station and gated, causing rejection of the packet with the ISS in the path. Is there a way to reject or ignore (or otherwise NOT gate) a packet with ARISS in the path, while dutifully gating packets in which the ARISS has been replaced with a *'d alias? My goal is to be as useful as possible to stations trying to work the ISS while NOT being detrimental. Is my logic sound? Is such filtering possible? More to the point, is it beneficial or necessary? John KG5BQX, West Texas
|
Satellite filters? Useful or not necessary?
I've been running an iGate for about 8-10 years now, but have just recently moved to YAAC running on Raspberry Pi with a TNC-Pi.? I love this software, so easy to use.
Anyway, I sort of inherited an ancient 2m rig that has something burned out on the transmit side, but that receives very well, and I thought I'd add a second port and do some sGate operations as well.
I added a USB sound card and got it working with Direwolf, and both ports are getting along nicely.
I have zero experience with ISS/Amsat ops, so my question is this:? I know that on 144.390, terrestrial APRS, that most packets are transmitted with the end goal of being gated to the IS backbone, by whatever route the propagation chooses.? But anyone trying to work a satellite or the ISS on 145.825 is assumed to be specifically trying to get a packet digipeated by the ISS.? If my station happens to directly hear a packet on 145.825 and gate it, it won't ever register as having traversed the ISS hop, right?? I would think a station would rather have a packet ignored by ground stations in the hope of hitting the ISS, vs. always getting intercepted by a ground station and gated, causing rejection of the packet with the ISS in the path.
Is there a way to reject or ignore (or otherwise NOT gate) a packet with ARISS in the path, while dutifully gating packets in which the ARISS has been replaced with a *'d alias?? My goal is to be as useful as possible to stations trying to work the ISS while NOT being detrimental.? Is my logic sound?? Is such filtering possible?? More to the point, is it beneficial or necessary?
John
KG5BQX, West Texas
|
Ah, you're talking about supplemental IS-to-RF forwarding. This is a special case, used only in limited circumstances, to forward Internet APRS packets that don't meet the normal transmit-capable I-gate constraints of being either: 1. an APRS Text message addressed to an RF station that was reported to the Internet by this I-gate. 2. a Position beacon (any format) from the station that just sent a case#1 packet. However, you must be _very_ conservative in what additional traffic you allow to be forwarded this way, as the Internet has far more bandwidth than the 1200-baud RF channel, and a slight typo here can make the RF channel unusable within the direct transmission range of your station (and possibly further, depending on whether or not the nearby digipeaters get reconfigured to blacklist your flood). Furthermore, such traffic should be of interest to all the local RF users (otherwise, why are you cluttering the channel with it?); there generally is never a reason to force arbitrary packets from hundreds of miles away onto the local RF channel, as they would not be locally relevant. First, you have to add a filter to your APRS-IS port configuration so the additional traffic will be forwarded from the APRS-IS to your I-gate. Second, you have to add _another_ filter on the Transmit tab of the expert-mode Configuration dialog that specifies exactly which packets are to be forwarded on to RF. Really, if the YSF stations want to be known on APRS, they should have a local station transmit APRS Objects to report the YSF station location, frequency, and capabilities. Andrew, KA2DDO author of YAAC ________________________________________ From: [email protected] < [email protected]> on behalf of Kun N7DMR <sa4591@...> Sent: Tuesday, May 11, 2021 3:19 PM To: [email protected]Subject: [yaac-users] APRS Analog - YSF Is there a way for my Analog iGate to Digipeat beacons sent by YSF stations? Meaning when my YAAC iGate see there is packet sent from YSF station into APRS-IS, rebroadcast it as Analog.
|
Is there a way for my Analog iGate to Digipeat beacons sent by YSF stations? Meaning when my YAAC iGate see there is packet sent from YSF station into APRS-IS, rebroadcast it as Analog.
|
Ah, that make sense. I have make sure RF beacon and APRS-IS beacon happens at different time. I just want to probe RF path to a distance iGate.?
|
Well, your own station should be able to see any echo-backs from local digipeaters in the traffic you receive from RF, assuming you are using a non-empty digipeat path (if you don't authorize digipeating in your packets, no compliant digipeater will do so). In fact, on RF you will see _all_ digipeats from local digipeaters, not just the first one, unlike on the Internet backbone, which deliberately filters out duplicate copies of any received transmission. Of course, if you are half-way between two digipeaters that can't hear each other, their simultaneous retransmissions of your packets may collide with each other at your station so you end up getting nothing but RFI. Note also there is no guarantee there is any working I-gate within digipeated RF range of your station, hence there is no guarantee that your RF packets will ever make it to the APRS-IS backbone. I know a user who runs the only I-gate in his state (the next nearest ones are over the state line). If you use two beacon records, you can change the timing on the two beacon records so they are less likely to land on each other (ex.: RF beacon at 47 seconds decaying to 29 minutes, Internet beacon at 7 minutes decaying to 30 minutes). The only problem is that if you force beaconing (by tapping the spacebar on the map window), the beacons are all sent simultaneously, so they will have to drift apart again (hence why I suggested such significantly different and non-multiples-of-each-other beacon rates). Andrew, KA2DDO author of YAAC ________________________________________ From: [email protected] < [email protected]> on behalf of Kun N7DMR Sent: Friday, May 7, 2021 9:30 PMSubject: Re: [yaac-users] YAAC beacon settings Ah, that make sense. When I have both beacon on, only the Internet beacon shows up which made me believe the over-the-air beacon was not sent. However, I do want my RF beacon to show up, so that I could check out local RF condition based on which digipeater picked it up. Is there a way I could let the Internet beacon and RF beacon to go out at a different time?
|
Ah, that make sense. When I have both beacon on, only the Internet beacon shows up which made me believe the over-the-air beacon was not sent. However, I do want my RF beacon to show up, so that I could check out local RF condition based on which digipeater picked it up. Is there a way I could let the Internet beacon and RF beacon to go out at a different time?
|
This is a rather odd request. _Why_ don't you want your beacon going to the Internet? It's not considered good practice for an I-gate station. Your beacon can go to both ports simultaneously. You just won't ever see your RF-transmitted beacon coming back on APRS-IS because the direct-to-Internet packet will get there first (and some other I-gate may bring it to the Internet anyway if you disable it). And the receivers of any packets you forward to the Internet (which will be tagged with your callsign as the I-gate that forwarded it to the Internet backbone) will not know where they were received because they won't know your station position. And, yes, setting a port to "transmit disabled" means _nothing_ will be transmitted out that port; that was intentional, so that not-yet-licensed users could still legally use YAAC in a receive-only mode (like short-wave listeners). However, if you really want to do this, you need to create a second beacon record, and assign one beacon record to the RF port and the other one to the APRS-IS port, then disable (not delete) the beacon associated with the APRS-IS port. Disabled beacons are never transmitted, but every APRS transmitting port has to have _some_ beacon associated with it. Hope this helps. Andrew, KA2DDO author of YAAC ________________________________________ From: [email protected] < [email protected]> on behalf of Kun N7DMR Sent: Friday, May 7, 2021 7:24 PM Subject: [yaac-users] YAAC beacon settings I have some trouble setting YAAC beacon. I am running an APRS iGate. I want my beacon to go out to TNC port. However, it always goes to TCP/IP port. If I set TCP/IP port to none transmit, YAAC will stop forwarding packets from RF to APRS-IS. How do I configure my YAAC to beacon only via TNC?
|
I have some trouble setting YAAC beacon. I am running an APRS iGate. I want my beacon to go out to TNC port.
However, it always goes to TCP/IP port. If I set TCP/IP port to none transmit, YAAC will stop forwarding packets from RF to APRS-IS.
How do I configure my YAAC to beacon only via TNC?
|
Re: Headless REST API for sending/receiving messages?
Hi Andrew,
First, thank you for the speedy response and for providing YAAC to the amateur radio community.
Yes, I plan to create a plugin for YAAC that provides a REST server.?
The Sample plugin (along with the other source code) is exceptionally useful. I was able to get a quick prototype working this morning before work and can now listen to the various events. Now. It¡¯s just a matter of noodling around with how to cleanly integrate a RESTful server into the plugin. I have some ideas on how to move forward. The only thing I have decided on is that I want to make use of Swagger/Open API to define the API specification and generate the server-side and client-side stubs.
I¡¯ll keep you posted. Is there a separate developer list?
Keep up the good work! ?
73,
Gaston KT1RUN The Tech Prepper
toggle quoted message
Show quoted text
Greetings.That's an interesting idea. I presume you mean for YAAC to be a REST server in this context, not a REST client. YAAC has no REST functionality at the present time.However, your concept is entirely doable, except that my mini-webserver currently only supports the HTTP GET method; other methods are rejected with the BAD_METHOD HTTP error (405). But I could fix that in the next build. Note that the mini-webserver also doesn't provide the full functionality of a webapp container like Tomcat, so any extras you want to add (such as HTML form upload parsing) you would have to add yourself (or find appropriate 3rd-party libraries that can do it without a webapp container).Regarding APIs to get into the internal data and data flows of YAAC, you basically have access to every public class and method in YAAC itself, plus all the 3rd party libraries bundled with YAAC (such as JSSC, OpenMap, Apache Commons Math, and Apache Commons Compress); that's why I bundle the Javadocs of YAAC in the plugin SDK zip file. Note that, because YAAC still works with Java 8, it does _not_ enforce or use any of the module features introduced in Java 9.If you download the source distribution of YAAC, you can see not only the source code of core YAAC, but also the source code of every plugin I've released as well (not just the sample plugin), so you can see how they interface with core YAAC. For example, the RepeaterFinder plugin registers itself as a TrackerListener on the StationTracker object in YAAC, so it can be informed each time a new station or object is received (in case said station or object looks like a repeater station). The ADSBdecoder and AISDecoder plugins also access the StationTracker to create new pseudo-APRS objects representing the aircraft and ships they decode so these vessels can be plotted on the YAAC map like any other APRS station. Similarly, if you look at the APRSISPseudoServer, you can see how it registers another dynamic HTTP page with the mini-webserver (instantiated on a different port) so it can produce a status page like a real APRS-IS backbone server would produce. And the TelemetryAlarm plugin can create APRS text messages (the MessageMessage class) for submission to the Transmitter class when an out-of-range telemetry value is detected.So your item#3 is trivial; just register new web pages with the appropriate URLs that do the same thing as the MessagesPage and StationsPage but in the appropriate REST output data format. Item#2 requires adding support for non-GET methods on the mini-webserver, which I will put in the next build; your registered webpage for that would have to parse either REST URLs or HTML forms to get the data to insert into a MessageMessage object (APRS text message) and submit them to the Transmitter, then produce an appropriate HTML response page to report the results of the submission.Andrew, KA2DDOauthor of YAAC________________________________________From:?[email protected]?<[email protected]> on behalf of The Tech PrepperSent: Friday, May 7, 2021 9:11 AMSubject: [yaac-users] Headless REST API for sending/receiving messages?Happy Friday,I am new to the group, but have been enjoying YAAC for a few months. As a Java software engineer I love that this project has a plugin architecture.I don't want to re-invent the wheel, but I am looking to run APRS fully headless via a REST-based API. I've seen mentions of the headless mode (nogui option) and the small web server, but it does not look like there's an API that exposes a subset of features?Here's my use case:1. Create a plugin that provides a REST endpoint for sending location beacons and station messages.2. In terms of API POST requests, my MVP is to add abstractions for sending messages to the following SSIDs: SMEGTE, EMAIL-2 and APRS2SOTA (and possibly station-to-station).3. In terms of API GET requests, my MVP is to list heard stations and incoming messages.4. This will all run on a Raspberry Pi and function as a man portable field station. I love operating from the backcountry.5. Today, I am connecting to the hotspot on my iPhone via VNC and launching YAAC. The new goal is to start direwolf and YAAC along with my API plugin on startup. For the user interface, I will be designing a small Progressive Web Application (PWA) with Node.js that will run on the Pi. Then, I can simply run the PWA from any device that has a web browser and is connected to the hotspot.My question is this: Does a REST API exist that offers endpoints for sending simple messages and/or listing heard stations? If not, this something I am starting on today.73,Gaston KT1RUNThe Tech Prepper
|
Re: Headless REST API for sending/receiving messages?
Greetings. That's an interesting idea. I presume you mean for YAAC to be a REST server in this context, not a REST client. YAAC has no REST functionality at the present time. However, your concept is entirely doable, except that my mini-webserver currently only supports the HTTP GET method; other methods are rejected with the BAD_METHOD HTTP error (405). But I could fix that in the next build. Note that the mini-webserver also doesn't provide the full functionality of a webapp container like Tomcat, so any extras you want to add (such as HTML form upload parsing) you would have to add yourself (or find appropriate 3rd-party libraries that can do it without a webapp container). Regarding APIs to get into the internal data and data flows of YAAC, you basically have access to every public class and method in YAAC itself, plus all the 3rd party libraries bundled with YAAC (such as JSSC, OpenMap, Apache Commons Math, and Apache Commons Compress); that's why I bundle the Javadocs of YAAC in the plugin SDK zip file. Note that, because YAAC still works with Java 8, it does _not_ enforce or use any of the module features introduced in Java 9. If you download the source distribution of YAAC, you can see not only the source code of core YAAC, but also the source code of every plugin I've released as well (not just the sample plugin), so you can see how they interface with core YAAC. For example, the RepeaterFinder plugin registers itself as a TrackerListener on the StationTracker object in YAAC, so it can be informed each time a new station or object is received (in case said station or object looks like a repeater station). The ADSBdecoder and AISDecoder plugins also access the StationTracker to create new pseudo-APRS objects representing the aircraft and ships they decode so these vessels can be plotted on the YAAC map like any other APRS station. Similarly, if you look at the APRSISPseudoServer, you can see how it registers another dynamic HTTP page with the mini-webserver (instantiated on a different port) so it can produce a status page like a real APRS-IS backbone server would produce. And the TelemetryAlarm plugin can create APRS text messages (the MessageMessage class) for submission to the Transmitter class when an out-of-range telemetry value is detected. So your item#3 is trivial; just register new web pages with the appropriate URLs that do the same thing as the MessagesPage and StationsPage but in the appropriate REST output data format. Item#2 requires adding support for non-GET methods on the mini-webserver, which I will put in the next build; your registered webpage for that would have to parse either REST URLs or HTML forms to get the data to insert into a MessageMessage object (APRS text message) and submit them to the Transmitter, then produce an appropriate HTML response page to report the results of the submission. Andrew, KA2DDO author of YAAC ________________________________________ From: [email protected] < [email protected]> on behalf of The Tech Prepper Sent: Friday, May 7, 2021 9:11 AM Subject: [yaac-users] Headless REST API for sending/receiving messages? Happy Friday, I am new to the group, but have been enjoying YAAC for a few months. As a Java software engineer I love that this project has a plugin architecture. I don't want to re-invent the wheel, but I am looking to run APRS fully headless via a REST-based API. I've seen mentions of the headless mode (nogui option) and the small web server, but it does not look like there's an API that exposes a subset of features? Here's my use case: 1. Create a plugin that provides a REST endpoint for sending location beacons and station messages. 2. In terms of API POST requests, my MVP is to add abstractions for sending messages to the following SSIDs: SMEGTE, EMAIL-2 and APRS2SOTA (and possibly station-to-station). 3. In terms of API GET requests, my MVP is to list heard stations and incoming messages. 4. This will all run on a Raspberry Pi and function as a man portable field station. I love operating from the backcountry. 5. Today, I am connecting to the hotspot on my iPhone via VNC and launching YAAC. The new goal is to start direwolf and YAAC along with my API plugin on startup. For the user interface, I will be designing a small Progressive Web Application (PWA) with Node.js that will run on the Pi. Then, I can simply run the PWA from any device that has a web browser and is connected to the hotspot. My question is this: Does a REST API exist that offers endpoints for sending simple messages and/or listing heard stations? If not, this something I am starting on today. 73, Gaston KT1RUN The Tech Prepper
|
Headless REST API for sending/receiving messages?
Happy Friday,
I am new to the group, but have been enjoying YAAC for a few months. As a Java software engineer I love that this project has a plugin architecture.?
I don't want to re-invent the wheel, but I am looking to run APRS fully headless via a REST-based API. I've seen mentions of the headless mode (nogui option) and the small web server, but it does not look like there's an API that exposes a subset of features?
Here's my use case:
1. Create a plugin that provides a REST endpoint for sending location beacons and station messages.
2. In terms of API POST requests, my MVP is to add abstractions for sending messages to the following SSIDs: SMEGTE, EMAIL-2 and APRS2SOTA (and possibly station-to-station).
3. In terms of API GET requests, my MVP is to list heard stations and incoming messages.
4. This will all run on a Raspberry Pi and function as a man portable field station. I love operating from the backcountry.
5. Today, I am connecting to the hotspot on my iPhone via VNC and launching YAAC. The new goal is to start direwolf and YAAC along with my API plugin on startup. For the user interface, I will be designing a small Progressive Web Application (PWA) with Node.js that will run on the Pi. Then, I can simply run the PWA from any device that has a web browser and is connected to the hotspot.
My question is this: Does a REST API exist that offers endpoints for sending simple messages and/or listing heard stations? If not, this something I am starting on today.
73,
Gaston KT1RUN
The Tech Prepper
https://youtube.com/c/thetechprepper
|
First question is, what specific Java exceptions are you getting? Appending the log with the full stack traces would be helpful. Also, what version of the Java runtime and of YAAC are you using? Andrew, KA2DDO author of YAAC ________________________________________ From: [email protected] < [email protected]> on behalf of W8GMC <Michael_MSN@...> Sent: Friday, April 30, 2021 1:25 PM To: [email protected]Subject: [yaac-users] YAAC Not starting up HI All, I have YAAC running on a Pi4 build and it had been running flawlessly with Direwolf for months. I decided to build another to take to another property and to track my wife's hiking activities in the mountains where there is no cell service. Anyway, The new build is also a Pi4 8gb, both running the NWDigital Draws hat, The new one is running from SSD where the original SDXC. I simply backed up the original image and cloned it to the SSD. System boots fine, DireWolf is working perfectly but when i start Yaac it ultimately bombs. No logging is present in the lofgile directory. It did create 1 log in that dir when i ran it with the -clear parameter. But no logging once that parameter was removed. I do see a few java exceptions rip by the term window. I reinstalled YAAC per the instructions and have the exact came issue. Im at a loss here, any thoughts on where to focus my efforts will be appreciated. Thank You, MIke W8GMC
|
HI All,?
I have YAAC running on a Pi4 build and it had been running flawlessly with Direwolf for months. I decided to build another to take to another property and to track my wife's hiking activities in the mountains where there is no cell service. Anyway, The new build is also a Pi4 8gb, both running the NWDigital Draws hat, The new one is running from SSD where the original SDXC. I simply backed up the original image and cloned it to the SSD. System boots fine, DireWolf is working perfectly but when i start Yaac it ultimately bombs. No logging is present in the lofgile directory. It did create 1 log in that dir when i ran it with the -clear parameter. But no logging once that parameter was removed. I do see a few java exceptions rip by the term window. I reinstalled YAAC per the instructions and have the exact came issue. Im at a loss here, any thoughts on where to focus my efforts will be appreciated.?
Thank You,
MIke
W8GMC
|
Oh....this explains it. Ran into the same issue.
Waiting on the update too.? :-)? ...since I'm SURE you have NOTHING else to do with your life......
Chuck Bland
|
Re: NTP / GPSD config problem
Thanks for the info, Clark.
That gave me a few clues where to look further, and I MAY have
gotten things to work by installing chrony and setting a few things
in its config file.? Will need to wait a few days (powered off) for
the clock to get sufficiently out of sync, then see if it syncs by
itself.
Greg? KO6TH
Clark Martin wrote:
toggle quoted message
Show quoted text
IIRC, there is an option in ntpd to force an update of the time.
?It won¡¯t update automatically if the system time (set to the last
time it shutdown) is more than 16 min off from the correct time.?
This is a guess, I¡¯ve gotten it to work but I don¡¯t recall
the details.
Yet another designated driver on
the information super highway.
?
Hi all,
I'm SOOO close.? What nit am I missing?
I have a Raspberry Pi 3B (Raspbian Stretch) with YAAC
running in my car.? USB GPS puck is connected, and I have
GPSD running.? The GPS has a fix, and YAAC sees GPSD and
correctly centers the map on where I am.? If I move the map,
YAAC moves it back.? Yay!
But I can't get the Pi's clock to use the GPS time via NTP;
it defaults to the time of the last shutdown.
I followed the instructions on several websites to add the
following to /etc/ntp.config.?
# gps ntp
server 127.127.28.0 minpoll 4
fudge? 127.127.28.0 time1 0.183 refid NMEA
server 127.127.28.1 minpoll 4 prefer
fudge? 127.127.28.1 refid PPS
I also commented out the Internet-based pool servers, to
force the use of the GPS.? Yet, the system time & date
is not updated to current.? Forcing ntp to restart and
similar don't help.
There are vague comments on various sites about the defaults
for GPSD not being right, but nothing about what exactly is
wrong nor how to fix it.
What did I miss?
Thanks,
Greg? KO6TH
|
Re: Should I be able to see other stations on my YAAC map?
Martin: It doesn't look like you properly filled in your configuration. For example, your beacon fixed location is still in the center of the United States, so unless you're traveling here (unlikely with COVID-19 still running around) with reciprocal operating privileges, it's not correct for a British amateur radio callsign. You should set the fixed location appropriately even if you are using GPS, because there is no guarantee you won't get a GPS drop-out (for example, when the GPS receiver is first powered up, it may have to wait to receive constellation almanac data before it can start computing fixes [i.e., cold start]). Also, are you successfully receiving APRS packets and GPS sentences from your respective ports? You are specifying /dev/ttyACM0 at 4800 baud for your GPS for direct and exclusive access (not sharing with other applications using GPSD), and /dev/ttyAMA0 at 19200 to talk to a hardware TNC. Is this correct? You can use the Test Port button on each port's configuration panel to look at the raw bytes coming in from each port to make sure they look valid. Also, if you are using GPSD, it can't share the physical serial port to the GPS receiver with YAAC; only one program can use a serial port at a time, so if you are using GPSD, you should use the GPSD port type in YAAC to connect to the GPSD daemon instead of fighting for control of the serial port with it. Furthermore, you have both an APRS-IS connection and a TNC, which makes YAAC assume you are running an I-gate. As such, you will only receive traffic from the Internet that is explicitly addressed to stations _you_ have forwarded _to_ the Internet (such as your sailboat). It may have intermittently worked earlier because of a flaky behavior in YAAC (which was fixed in a recent build; did you upgrade recently?) where, depending on the order the Serial_TNC port starts up relative to the APRS-IS port, you may or may not get an automatic default APRS-IS server filter expression to tell the APRS-IS backbone to send you additional traffic. With the recent fix, YAAC stations operating as I-gates will _never_ get extra traffic from APRS-IS unless you explicitly specify a filter expression of the additional Internet traffic you want to receive. Now, why you're not receiving any other RF traffic besides your sailboat, I can't explain without knowing more about your station setup and location. Could be mismatched audio levels between the TNC and radio, could be a too-high squelch setting, could just be lousy reception near your station, could be poor-quality signals from other APRS users that your TNC can't decode, could be lots of packet collisions if there is a large amount of traffic in your area, or conversely just not very many people transmitting APRS RF packets in your area. Another British user was asking me about digipeater setup a while ago because his local geographic area had so few RF APRS stations, and he wanted to encourage more traffic. Andrew, KA2DDO author of YAAC ________________________________________ From: [email protected] < [email protected]> on behalf of M0HKG - Martin via groups.io <m0hkg@...> Sent: Thursday, April 8, 2021 9:07 AM To: [email protected]Subject: [yaac-users] Should I be able to see other stations on my YAAC map? Firstly, an awesome piece of software - I appreciate all the hard work that's gone in to creating YAAC! I am a new RPi user and struggling with the vagueries of Linux, and this is probably a very dumb question but please bear with me. I'm 100% convinced that earlier today, my YAAC map was showing the local radio (M0HKG), the radio on my sailboat (M0HKG-7) and all the other stations that I'd normally see on aprs.fi. YAAC was also reporting my local radio and my sailboat to aprs.fi. Which was exactly what I wanted. I tried 'upgrading' my RPi by shutting down the OS and re-plugging everything (including the SD card) into a newer board but then I wasn't not seeing the stations I could see on aprs.fi. So, I swapped everything back and all I can see is the local radio (M0HKG) and the radio on my sailboat (M0HKG-7). YAAC seems to be sending my beacon from my sailboat through to aprs.fi and I can get on to the internet just fine from the RPi. And I can beacon YAAC to another radio locally which shows up on PinPoint (Windows) but I can't see any other stations on the YAAC map... I'm aware of the old saying, if it ain't broke and I should have heeded the advice... My questions are, 1) did I REALLY see other stations on my YAAC map? And, 2) if so, how do I get them back? I've attached a copy of my configuration file for reference, and any suggestions would be appreciated. Thanks/73s Martin m0hkg
|
Re: Objects on map aren't updaing
Hmmm... I have the same build of Java 11, and can't replicate your problem. Can you privately email me a copy of your YAAC.out file from your YAAC log directory, and an export of your YAAC configuration file? I suspect there's something odd about your installation that is causing it to fail to update position information. Andrew, KA2DDO author of YAAC ________________________________________ From: [email protected] < [email protected]> on behalf of Rob <luminoxs@...> Sent: Saturday, April 10, 2021 5:25 PM To: [email protected]Subject: Re: [yaac-users] Objects on map aren't updaing Hello, I did a cut and paste as I'm new to Linux and wanted to make sure I was giving you correct info. java -showversion openjdk version "11.0.10" 2021-01-19 OpenJDK Runtime Environment (build 11.0.10+9-Ubuntu-0ubuntu1.20.04) OpenJDK 64-Bit Server VM (build 11.0.10+9-Ubuntu-0ubuntu1.20.04, mixed mode)
|
The Tech Prepper