开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育
  1. Yaac-Users
  2. Topics

QRU server timing issues

 

开云体育

Hey everyone I have a quick question to see if anyone else has experienced this issue before I file a bug.

?

I have a simple setup with YAAC using kiss over ip connected to Direwolf on the same system.? I have been playing around with the QRU fuctionality in YAAC and have seen some behavior that is presenting as a timing issue I just don’t know how to validate where the issue is.

?

I can create an object in YAAC and set a QRU group.? The QRU server is turned on in the configuration.? Once I add this object the object gets transmitted out as expected and I see the packet on a second station.?

?

When I send a message to QRU with the group name I see one of two responses.? Response 1 is what I expect I get an acknowledgement, then the object information is sent, and finally a message back with the summary on the number of objects in that group.?

?

The second response looks the same in the raw packet sniffer as the first response however when watching the logs on direwolf only the initial ack is sent. Not the objects or the summary message.

?

If anyone has seen this or has some ideas on how to further debug to try and figure out what it is working sometimes but not other please let me know.

?

Thanks,

Scott – W2KP

?

?
 

Let's take a look at your problem.

Re: timing: that is entirely possible. Are you receiving the QRU response directly or via a digipeater? If the latter, how long do you wait before querying again? I ask because New-N paradigm digipeaters are specifically designed to not digipeat any given packet more often than once every 30 seconds; so are the APRS-IS backbone servers. So, if you make the same query in under 30 seconds, the response may get sent by the QRU server station, but blocked by the digipeater because it's the exact same Object message(s) and the exact same text message of the quantity report.

So bear in mind that not receiving the second occurrence is not the same as it not being sent. Check the transmit logs on the sending station to see if the response was transmitted a second time. Note that the query and query ack can get through because the querying text message has a sequence number, so each query packet (and corresponding ack) has different contents (even if the actual QRU query text is identical).

Also, what kind of station are you using to make the queries? Fixed or mobile? Note on the YAAC expert-mode configuration tab Transmit, there is not only a checkbox to enable QRU service, but a control to specify the default maximum range the station will respond to. For example, if a station 100 miles away sends the query over digipeaters, but the QRU server only has a 50-mile maximum QRU response radius (or the query specifies an explicit 50-mile limit), the server won't answer; after all, why would that distant station care about a resource it's too far away to reach? And if the querying station has not yet sent a position report that the YAAC QRU server can receive, YAAC will assume the querying station is at the Coast-of-Africa point (latitude 0, longitude 0), which is hundreds to thousands of miles away from any real station location, so it's likely to be out of range for a response.

Hope this helps.

Andrew, KA2DDO
author of YAAC
________________________________________
From: [email protected] <[email protected]> on behalf of Scott Gillins <scott@...>
Sent: Friday, January 5, 2024 1:46 AM

Hey everyone I have a quick question to see if anyone else has experienced this issue before I file a bug.

I have a simple setup with YAAC using kiss over ip connected to Direwolf on the same system. I have been playing around with the QRU fuctionality in YAAC and have seen some behavior that is presenting as a timing issue I just don’t know how to validate where the issue is.

I can create an object in YAAC and set a QRU group. The QRU server is turned on in the configuration. Once I add this object the object gets transmitted out as expected and I see the packet on a second station.

When I send a message to QRU with the group name I see one of two responses. Response 1 is what I expect I get an acknowledgement, then the object information is sent, and finally a message back with the summary on the number of objects in that group.

The second response looks the same in the raw packet sniffer as the first response however when watching the logs on direwolf only the initial ack is sent. Not the objects or the summary message.

If anyone has seen this or has some ideas on how to further debug to try and figure out what it is working sometimes but not other please let me know.

Thanks,
Scott – W2KP
 

Thanks for reaching with suggestions and questions.? here is a bit more info on the setup.

I have been running this exercise on a non standard ARPS frequency to cut down on the noise.

There are no digipeters in the mix.? I have a radio connected to a Rasperrypi running Direwolf and YAAC.? YAAC is talking to Direwolf as the TNC via KISS over IP.? in the logs as W2KP-4

I am sending QRU message from Yaesu FT2D as KI7YRY-1 in the logs

Below are the logs that I captured that show the miss I originally described.? I have tried to explain what was happening I hope it makes sense.

You can see yaac logs
23:22:33 are the original object announcements? These were sent and seen
23:23:33 are the original object announcements? These were sent and seen
23:22:53 beacon from test handheld with position report

23:23:51 First QRU message sent and heard by yaac
23:23:51 object packet sent out

in the direwolf logs starting at 23:23:51
23:23:51 message in from client
23:23:51 ack from yaac back to clent
23:23:52 object sent out
23:23:52 summary message sent out to client

23:24:37 random beacon from YAAC out.

Second test

yaac raw packets
23:24:39 QRU from client
23:24:39 obj sent from YAAC

Direwolf logs
23:24:39 QRU packet
23:24:39 ACK


???? Never see the OBJ packet seen in yaac logs at 23:24:39 in the Direwolf logs.



Direwolf Logs:
KI7YRY-1 audio level = 27(6/7) ? ?||||||___
[0.2 23:23:51] KI7YRY-1>APY02D,WIDE1-1,WIDE2-1::QRU ? ? ?:RACE{11<0x0d>
The APRS protocol specification says nothing about a possible carriage return after the
message id.? Adding CR might prevent proper interoperability with with other applications.
APRS Message, number "11", from "KI7YRY-1" to "QRU", Yaesu FT2D series
RACE
[0L 23:23:51] QRU>APJYC1::KI7YRY-1 :ack11
[0L 23:23:52] W2KP-4>APJYC1,WIDE1-1,NOGATE,RFONLY:;obj3 ? ? *062233h3334.82N\11157.06W!bj3
[0L 23:23:52] QRU>APJYC1::KI7YRY-1 :Sent 1 RACE Objects Max 1 de W2KP-4
[0L 23:24:37] W2KP-4>SSSTXR,WIDE1-1,WIDE2-1:`'Rul s//"8R} Truck Pi<0x0d>


KI7YRY-1 audio level = 26(6/6) ? ?||||||___
[0.2 23:24:39] KI7YRY-1>APY02D,WIDE1-1,WIDE2-1::QRU ? ? ?:RACE{12<0x0d>
The APRS protocol specification says nothing about a possible carriage return after the
message id.? Adding CR might prevent proper interoperability with with other applications.
APRS Message, number "12", from "KI7YRY-1" to "QRU", Yaesu FT2D series
RACE
[0L 23:24:39] QRU>APJYC1::KI7YRY-1 :ack12

YAAC raw packet log:

image.png


On Fri, Jan 5, 2024 at 6:20?PM Andrew P. <andrewemt@...> wrote:
Let's take a look at your problem.

Re: timing: that is entirely possible. Are you receiving the QRU response directly or via a digipeater? If the latter, how long do you wait before querying again? I ask because New-N paradigm digipeaters are specifically designed to not digipeat any given packet more often than once every 30 seconds; so are the APRS-IS backbone servers. So, if you make the same query in under 30 seconds, the response may get sent by the QRU server station, but blocked by the digipeater because it's the exact same Object message(s) and the exact same text message of the quantity report.

So bear in mind that not receiving the second occurrence is not the same as it not being sent. Check the transmit logs on the sending station to see if the response was transmitted a second time. Note that the query and query ack can get through because the querying text message has a sequence number, so each query packet (and corresponding ack) has different contents (even if the actual QRU query text is identical).

Also, what kind of station are you using to make the queries? Fixed or mobile? Note on the YAAC expert-mode configuration tab Transmit, there is not only a checkbox to enable QRU service, but a control to specify the default maximum range the station will respond to. For example, if a station 100 miles away sends the query over digipeaters, but the QRU server only has a 50-mile maximum QRU response radius (or the query specifies an explicit 50-mile limit), the server won't answer; after all, why would that distant station care about a resource it's too far away to reach? And if the querying station has not yet sent a position report that the YAAC QRU server can receive, YAAC will assume the querying station is at the Coast-of-Africa point (latitude 0, longitude 0), which is hundreds to thousands of miles away from any real station location, so it's likely to be out of range for a response.

Hope this helps.

Andrew, KA2DDO
author of YAAC
________________________________________
From: [email protected] <[email protected]> on behalf of Scott Gillins <scott@...>
Sent: Friday, January 5, 2024 1:46 AM

Hey everyone I have a quick question to see if anyone else has experienced this issue before I file a bug.

I have a simple setup with YAAC using kiss over ip connected to Direwolf on the same system.? I have been playing around with the QRU fuctionality in YAAC and have seen some behavior that is presenting as a timing issue I just don’t know how to validate where the issue is.

I can create an object in YAAC and set a QRU group.? The QRU server is turned on in the configuration.? Once I add this object the object gets transmitted out as expected and I see the packet on a second station.

When I send a message to QRU with the group name I see one of two responses.? Response 1 is what I expect I get an acknowledgement, then the object information is sent, and finally a message back with the summary on the number of objects in that group.

The second response looks the same in the raw packet sniffer as the first response however when watching the logs on direwolf only the initial ack is sent. Not the objects or the summary message.

If anyone has seen this or has some ideas on how to further debug to try and figure out what it is working sometimes but not other please let me know.

Thanks,
Scott – W2KP

1 - 3 of 3