Well, the next build of YAAC is going to make the user responsible for selecting the same date format as they configured in the radio.

So I don't have to force radio owners to use a format unfriendly to them, but then they're going to have to tell YAAC whose format they chose.

Andrew, KA2DDO

________________________________________
From: [email protected] <[email protected]> on behalf of Doug Rosser <vk2dcr@...>
Sent: Monday, November 16, 2020 4:43 PM
To: [email protected]
Subject: Re: [yaac-users] Last Received 3014 Days ago

I'm not sure that mm/dd/yyyy is any more sane - particularly for those of us in the ROW :-)
Better to stick with yyyy/mm/dd - a least worst option.
Doug VK2DCR

I'm not sure that mm/dd/yyyy is any more sane - particularly for those of us in the ROW :-)?
Better to stick with yyyy/mm/dd - a least worst option.?
Doug VK2DCR

OK, does that mean I should back out my change of timestamp format?

I need to release a build today because of the Leonids meteor shower tonight (I also need to climb on my roof to set up another antenna, too).

Andrew, KA2DDO
author of YAAC

________________________________________
From: [email protected] <[email protected]> on behalf of John Roberts <intellisig@...>
Sent: Monday, November 16, 2020 11:48 AM
To: [email protected]
Subject: Re: [yaac-users] Last Received 3014 Days ago

Hi Andrew,

I may have changed the setting in the FTM400 config menu. I planned to test that tonight.

I think it's hard for you to build code that will anticipate whatever format the user may have selected. I sympathize with you.

John

On Mon, Nov 16, 2020 at 10:56 AM Andrew P. <andrewemt@...<mailto:andrewemt@...>> wrote:
That does seem too weird. I'm fixing the date format in the next build to be the saner month/day/year format your sample sent me.

I don't get to pick the format; Yaesu does, because their firmware is what is writing the date/time stamp to the serial port that YAAC is reading.

I couldn't find anything in the Yaesu FTM400DR APRS Manual about the serial port output, i.e., they don't document it, so I may have to change it in the future to be user-settable in YAAC, and advise the users to look at the format their particular radio is using in the Test Port mode.

Andrew, KA2DDO
author of YAAC

________________________________________
From: [email protected] <[email protected]> on behalf of rhclinton <rhclinton@...>
Sent: Monday, November 16, 2020 11:41 AM
To: [email protected]
Subject: Re: [yaac-users] Last Received 3014 Days ago

or how about the even saner year/month/day format

On 16.11.20 15:56:52, Andrew P. <andrewemt@...> wrote:

That does seem too weird. I'm fixing the date format in the next build to be the saner month/day/year format your sample sent me.

That does seem too weird. I'm fixing the date format in the next build to be the saner month/day/year format your sample sent me.

开云体育

Per chance, did you change the date format on your Yaesu?

Considering that the delay you reported is 8 1/4 YEARS off, I would check the date (not the time) in the radio. The Yaesu radio provides the complete date/timestamp for each received packet.

Hope this helps.

Andrew, KA2DDO
author of YAAC

Since you're using DireWolf as your TNC, it has to control the PTT on your radio, not YAAC.

Consult the DireWolf documentation as to the proper syntax for the PTT directive for your radio.

Assuming that you have DireWolf properly set up to transmit packets, you need to enable the AGWPE port in YAAC for transmit.

Hope that helps.

Andrew, KA2DDO
author of YAAC

Hi,

I have YAAC running via RS232 with a Yaesu FTM400XDR.

It's parsing APRS just fine, but the "last rcvd" date for all the stations is 3014days ago.

My radio isn't able to get a GPS fix inside my house. Is that causing it to report invalid dates on the APRS messages? I've set the clock inside the radio correctly.

Thanks,
John

I have the receive side operating but do not have control of the radio for beaconing.

1 port for 705’s built-in gps on gpsd
1 port on AGWPE for direwolf modem
?cont get control port for radio, have rigctl but not enough knowledge to know much more.

flrig connects and controls the radio, have wsjt-x running, lost getting YAAC to beacon.

any help appreciated

I have the gps and AGWPE ports operational using direwolf but I’m have it no luck getting control of the radio for beaconing. The data shows in direwolf but no transmit signaling.

I’ve setup repeater finder for Icom CI-V auto-tuning but still lost.

I’m using a Icom 705 on raspberry pi. Any help would be appreciated.

Sent from my mobile

See below...

From: [email protected] <[email protected]> on behalf of Eric H. Christensen
Sent: Wednesday, November 11, 2020 4:38 PM
Subject: Re: [yaac-users] Water issues, again.

On Wednesday, November 11th, 2020 at 12:28 PM, Andrew P. <andrewemt@...> wrote:

OK, I found out what was wrong with Pamlico Sound and related areas in North Carolina.

Whoever entered those areas into OpenStreetMap listed them as natural=water, but didn't
provide a water tag to indicate what type of water body it was (a pond, a reservoir, a lake,
a bay, etc.). So the YAAC importer threw relation#11190230 (Pamlico Sound) away because
it didn't have a type telling YAAC how to render it.

Yep, that was me. OSM doesn't have a tag for "Sound" so it was questionable as to which
tag to use for the Albemarle and Pamlico Sounds. But they were both water so...

That's about as good as you can get, given the present approved tag values. The "natural" tag does have a supported value of "bay", but they claim that doesn't always mean water. ?!?!?!

I have a fix for the importer in the next build of YAAC that will recognize items marked
as natural=water, and, if it doesn't have a water=something tag to specify the type of
water body, tag it as an unknown type of waterway. This corrects the problem with
Pamlico Sound, and also with the rivers feeding into the Sound.

I'm still working on waterways in this area. Are some of the rivers not tagged appropriately?

The tagging looks as good as for other rivers I've seen (such as the Delaware River near my QTH).

Should be good once I grind through the next import. Just finished downloading planet-201102.osm.pbf from planet.openstreetmap.org, so I can start importing with the fixed code that I already tested on a subset for North Carolina.

73,
Eric

Andrew, KA2DDO

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Wednesday, November 11th, 2020 at 12:28 PM, Andrew P. <andrewemt@...> wrote:

OK, I found out what was wrong with Pamlico Sound and related areas in North Carolina.

Whoever entered those areas into OpenStreetMap listed them as natural=water, but didn't provide a water tag to indicate what type of water body it was (a pond, a reservoir, a lake, a bay, etc.). So the YAAC importer threw relation#11190230 (Pamlico Sound) away because it didn't have a type telling YAAC how to render it.

Yep, that was me. OSM doesn't have a tag for "Sound" so it was questionable as to which tag to use for the Albemarle and Pamlico Sounds. But they were both water so...

I have a fix for the importer in the next build of YAAC that will recognize items marked as natural=water, and, if it doesn't have a water=something tag to specify the type of water body, tag it as an unknown type of waterway. This corrects the problem with Pamlico Sound, and also with the rivers feeding into the Sound.

I'm still working on waterways in this area. Are some of the rivers not tagged appropriately?

73,
Eric<blockquote class="protonmail_quote" type="cite">
OK, I found out what was wrong with Pamlico Sound and related areas in North Carolina.<br><br>Whoever entered those areas into OpenStreetMap listed them as natural=water, but didn't provide a water tag to indicate what type of water body it was (a pond, a reservoir, a lake, a bay, etc.). So the YAAC importer threw relation#11190230 (Pamlico Sound) away because it didn't have a type telling YAAC how to render it.<br><br>I have a fix for the importer in the next build of YAAC that will recognize items marked as natural=water, and, if it doesn't have a water=something tag to specify the type of water body, tag it as an unknown type of waterway. This corrects the problem with Pamlico Sound, and also with the rivers feeding into the Sound.<br><br>It will take me a couple days to rerun the OpenStreetMap planet-wide data set with the updated code and release the new build of YAAC.<br><br>Andrew, KA2DDO<br>author of YAAC


<div width="1" style="color:white;clear:both"></div>


</blockquote>

OK, I found out what was wrong with Pamlico Sound and related areas in North Carolina.

Whoever entered those areas into OpenStreetMap listed them as natural=water, but didn't provide a water tag to indicate what type of water body it was (a pond, a reservoir, a lake, a bay, etc.). So the YAAC importer threw relation#11190230 (Pamlico Sound) away because it didn't have a type telling YAAC how to render it.

I have a fix for the importer in the next build of YAAC that will recognize items marked as natural=water, and, if it doesn't have a water=something tag to specify the type of water body, tag it as an unknown type of waterway. This corrects the problem with Pamlico Sound, and also with the rivers feeding into the Sound.

It will take me a couple days to rerun the OpenStreetMap planet-wide data set with the updated code and release the new build of YAAC.

Andrew, KA2DDO
author of YAAC

开云体育