Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- Yaac-Users
- Messages
Search
Re: New User
OK, so I am using a remote connection to a raspberry pi. So far no problem. On the other hand, to save screen, I was shrinking down the window to see around it. That was the problem as the program was starting up. So after logging in several times, I made the screen full size and when running the program, everything started working. Now working through the setup screens. Does direwolf need to start before starting YAAC?
|
Re: New User
Did you start YAAC from a command prompt (as opposed to clicking on the YAAC.jar file in a graphical file manager)? If so, then YAAC should print out what it is doing to the terminal window. Capture that output and email it to me or the list, and we'll see what the issue is.
Andrew, KA2DDO author of YAAC |
next beta build#150 of YAAC, created 2020-May-11
next beta build#150 of YAAC ("Yet Another APRS Client"), created 2020-May-11
downloadable from or changes and updates include: 1. add support for Peet Bros weather stations' "complete record" protocol for sending weather data to computers. 2. add support for manual-only beaconing, on a per-beacon definition basis, so that a system working cross-band VHF and HF (on a band where automatic transmissions are prohibited) can beacon automatically on VHF and comply with regulations on the HF band. Add a more obvious control (the BCN button) to trigger manual beacon transmissions, with a visual indication whether it is "reasonable" to force another beacon. 3. fix proportional path editing logic in case user deletes all paths; this then assumes that the user meant only the direct (no digipeat) path. 4. make some UI adjustments to prevent sudden widening of lists and text fields because the widget doesn't have any text entries to figure the necessary width of the widget. 5. fix NullPointerException when viewing the health monitor for weather stations that have only sent one packet since YAAC has started. 6. stop drawing street names upside down; name flipping should only occur for borderlines (such as province or national boundaries) where the side of the line the name occurs on matters. 7. try to fix parsing for the Yaesu port driver. 8. fix weird case in OpenStreetMap importers where a Relation for a body of water has only one Way in the shoreline, and no labelling tags on the Way (only on the Relation). In such cases, the unlabelled Way is dropped, and the multipolygon element of the Relation gets dropped because it doesn't merge multiple Ways together. 9. some cleanup of online help documentation. |
Re: FTM-400XDR and YaesuConnector
Hmmm... The existing Yaesu port driver should "almost" work, but not quite. There are two issues:
1. Because of the possibility of some dingbat sending a packet with a line break (carriage return and/or linefeed) embedded in the middle of the text, there is code that won't pass the packet on to the rest of YAAC until the next packet is received (so the first line of the next packet triggers the flush). This would obviously be very annoying when there is low traffic volume, so I'm adding a timer to push the packets through within a "reasonable" time instead of waiting for the next packet to start. 2. There was a problem in parsing the digipeat list of a packet (although that shouldn't have broken the packets without digipeat paths). In any case, both these issues will be fixed in the next build. When you get build#150, tell me if you still have issues. Andrew, KA2DDO author of YAAC ________________________________________ From: [email protected] <[email protected]> on behalf of ke7kus@... <ke7kus@...> Sent: Monday, May 11, 2020 1:01 AM To: [email protected] Subject: [yaac-users] FTM-400XDR and YaesuConnector I've recently attempted to configure YAAC to receive serial output from a Yaesu FTM-400XDR radio. With the FTM-400 set in "PACKET" data output mode, I get serial port output which resembles TNC-2 formatted packets with some extraneous Yaesu-provided injects which corrupt an otherwise standardized packet format. (Thank you Yaesu.) In the YAAC Javadoc, I noted the existence of a YaesuConnector class, and in Build #148 there is a configuration option for a "Yaesu" port where one defines the serial port, baud rate, and station callsign for the port. I configured this port in YAAC, but received packets do not display on the YAAC graphical map as packets come in. When I run the "Test Port" utility in the Port configuration dialog, I get output similar to the following: W5NGU-3>APRX28 [08/13/16 00:26:22] <UI>: ;W5NGU-VHF*111111z3313.66N/09707.60WrW5NGU 146.920 pl 110.9 -0.6 W5NGU-3>APRX28 [08/13/16 00:26:23] <UI>: ;W5FKN-VHF*111111z3307.84N/09706.00WrW5NGU 145.17 pl 110.9 +5MHz W5NGU-3>APRX28 [08/13/16 00:26:25] <UI>: ;WA5LIE/F *111111z3313.75N/09707.64WrWA5LIE/F Fusion 443.525 pl 118.8 +5MHz N0FIB-7>SRTX6T,K5FTW-5*,WIDE2 [08/13/16 00:26:35] <UI R>: `}5Wlp [/`"60}_$ Here it is easy to see the "customized" Yaesu serial string format which has been implemented instead of a standard TNC-2 formatted packet. This also indicates that the serial port is receiving packets from the FTM-400 radio. In reading the YaesuConnector Javadoc, it appears the YaesuConnector class may have been designed to perform some basic string handling and remove the Yaesu injects to return the packets back to TNC-2 format and display them in YAAC; however, I was unable to trace the string handling method for the incoming serial event in the code documentation. I suspect that either the FTM-400 is outputting packets in a format slightly different from what the YaesuConnector was designed to process, or I need to configure the Yaesu radio to output packets in a different format (i.e. using the "GPS" or "WAYPOINT" modes in the FTM-400 data configuration menus.) Has anyone had success with getting FTM-400XDR packets to import into YAAC and display on the map? If so, can you please post your FTM-400 and YAAC settings? If not, if someone could point me to the code section which executes serial string handling, I'll be happy to write some code to attempt to fix the incoming packets to make them usable for YAAC display. 73, Kurt KE7KUS |
FTM-400XDR and YaesuConnector
I've recently attempted to configure YAAC to receive serial output from a Yaesu FTM-400XDR radio.? With the FTM-400 set in "PACKET" data output mode, I get serial port output which resembles TNC-2 formatted packets with some extraneous Yaesu-provided injects which corrupt an otherwise standardized packet format.? (Thank you Yaesu.)? In the YAAC Javadoc, I noted the existence of a YaesuConnector class, and in Build #148 there is a configuration option for a "Yaesu" port where one defines the serial port, baud rate, and station callsign for the port.? I configured this port in YAAC, but received packets do not display on the YAAC graphical map as packets come in.? When I run the "Test Port" utility in the Port configuration dialog, I get output similar to the following:
Here it is easy to see the "customized" Yaesu serial string format which has been implemented instead of a standard TNC-2 formatted packet.? This also indicates that the serial port is receiving packets from the FTM-400 radio. In reading the YaesuConnector Javadoc, it appears the YaesuConnector class may have been designed to perform some basic string handling and remove the Yaesu injects to return the packets back to TNC-2 format and display them in YAAC; however, I was unable to trace the string handling method for the incoming serial event in the code documentation.? I suspect that either the FTM-400 is outputting packets in a format slightly different from what the YaesuConnector was designed to process, or I need to configure the Yaesu radio to output packets in a different format (i.e. using the "GPS" or "WAYPOINT" modes in the FTM-400 data configuration menus.) Has anyone had success with getting FTM-400XDR packets to import into YAAC and display on the map?? If so, can you please post your FTM-400 and YAAC settings?? If not, if someone could point me to the code section which executes serial string handling, I'll be happy to write some code to attempt to fix the incoming packets to make them usable for YAAC display. 73, Kurt KE7KUS |
Re: next beta build#149 of YAAC, created 2020-May-09
Hi Andrew
Thanks for recognizing my ability as a? bug crasher!!!? I did not know I had such ability.? Glad that my lake has now received honourable mention in the annals of YAAC.? Yay for the small guys!? I look forward to the next build. Joe VA3JLF |
Re: next beta build#149 of YAAC, created 2020-May-09
开云体育It may take a while before I add tweeting support. I need to find out if there is a freely licensed or public domain means of automatically sending tweets.Andrew, KA2DDO author of YAAC -------- Original message --------
From: Bill WA4OPQ <wa4opq@...> Date: 5/10/20 12:21 (GMT-05:00) To: [email protected] Subject: Re: [yaac-users] 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. |
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 |
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
toggle quoted message
Show quoted text
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:
Thank you for creating YAAC and for making it so useful, easy to understand and modify. Jim Palmer |
to navigate to use esc to dismiss