I am looking at the EchoLink Link Status page and I don't see the call
sign KF7NPL-R there. At the bottom of the page it says only, The only stations shown are those which have entered location information on the
RF Info tab of Sysop Settings.
The question where are the Sysop Settings stored, and how can I insert
the location.
[Edited Message Follows]
I think Chuck's question is about the Link Status page, which shows the lat/lon and other data about the RF link.
For EchoIRLP (or theBridge), the data driving this page is in a separate section in the tbd.conf file, which I believe has some documentation in the comments.
The format is a bit tricky, and about 1/3 of the links online are sending invalid data currently.
The relevant section begins with:
; Information about your node for publishing via the EchoLink or
; APRS-IS (Automatic Packet Reporting System-Internet Service) systems.
If someone can look at WD5M-R in the EchoLink server data updates
and point out what is incorrect
On Sat, Nov 25, 2023 at 03:26 PM, David McAnally, WD5M wrote:
If someone can look at WD5M-R in the EchoLink server data updatesDavid,
and point out what is incorrect
The server is reporting an error in the syntax of messages which look like this:
)EL- wd5m!3515.06NE09835.100W0PHG3330/145110/000=WX5FWD at 2043
Off hand I notice that the longitude (09835.100W) has too many digits; the expected format would be: 09835.10W
Incidentally, a reminder that the APRS standard, which this follows, calls for lats/lons in degrees and decimal minutes -- as opposed to decimal degrees, or degrees/minutes/seconds.
(...)
The server is reporting an error in the syntax of messages which look like this:
)EL- wd5m!3515.06NE09835.100W0PHG3330/145110/000=WX5FWD at 2043
Off hand I notice that the longitude (09835.100W) has too many digits; the expected format would be: 09835.10W
Thanks for the analysis.
I'd also be happy to look at the source and possibly suggest a fix,
although I'm not sure how it would be committed.
As for other sources of invalid data, I think the largest single cohort is Asterisk/app_rpt/AllStar installations which use an EchoLink channel
driver. The main problem is that this stack isn't doing any validation of
the data elements before sending them.
Another issue (across all platforms) is valid data packets containing incorrect data, especially confusing East and West longitudes. Fixing this would require eyeballing the plotted map and contacting specific node
owners about obvious discrepancies.
Since the avrs.c source code is the same between theBridge and theLinkbox, I'd start with the avrs.c source found at https://github.com/skiphansen/thelinkbox/tree/master/src
On Sun, Nov 26, 2023 at 10:08 PM, David McAnally, WD5M wrote:
Since the avrs.c source code is the same between theBridge andtheLinkbox,
I'd start with the avrs.c source found at https://github.com/skiphansen/thelinkbox/tree/master/src
David, are you sure that version of avrs.c matches the binary you're
running?
It uses the format string %02.2f to produce the mins and decimal mins, and
I don't see how that would ever put three digits to the right of the
decimal point, unless there is a bug in the standard libraries.
The difference between
09835.100W (observed)
and
09836.00W (expected)
looks more like an error in code which is using integer arithmetic.
Yes, that is the avrs.c I am using. That does seem odd.
I did some more digging and I see that avrs.c in theBridge source code
base is completely different, vs. theLinkbox. And I think I see the bug in that version (below), which uses integer values rather than a
floating-point format string.
// Lines 256-262 in avrs.c for theBridge-1.09
Long = (int)x;
x -= Long;
x *= 60.0;
LongMin = (int)x;
x -= LongMin;
x *= 100.0;
LongHunders = (int)(x + 0.5);
In that last line, adding 0.5 causes the hundredths-of-degrees to be rounded Up in some cases, such as 99.6 becoming 100.
IMO it should always be rounded Down instead (omit the + 0.5).
I did some more digging and I see that avrs.c in theBridge source code
base is completely different, vs. theLinkbox. And I think I see the bug in that version (below), which uses integer values rather than a
floating-point format string.
// Lines 256-262 in avrs.c for theBridge-1.09
Long = (int)x;
x -= Long;
x *= 60.0;
LongMin = (int)x;
x -= LongMin;
x *= 100.0;
LongHunders = (int)(x + 0.5);
In that last line, adding 0.5 causes the hundredths-of-degrees to be rounded Up in some cases, such as 99.6 becoming 100.
IMO it should always be rounded Down instead (omit the + 0.5).
This change
does correct my example using -98.6.
That's great -- thanks for that -- and I am surprised to see that this is
not a rare problem -- the log shows 36 nodes which have the same pattern. Interestingly, most of them are running Asterisk, rather than EchoIRLP. I see in the source code for chan_echolink.c that it has essentially the same bug:
That's great -- thanks for that -- and I am surprised to see that this is
not a rare problem -- the log shows 36 nodes which have the same pattern. Interestingly, most of them are running Asterisk, rather than EchoIRLP. I see in the source code for chan_echolink.c that it has essentially the same bug:
latb = (lata - floor(lata)) * 60;
latd = (latb - floor(latb)) * 100 + 0.5;
lonb = (lona - floor(lona)) * 60;
lond = (lonb - floor(lonb)) * 100 + 0.5;
| Sysop: | deepend |
|---|---|
| Location: | Calgary, Alberta |
| Users: | 255 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 19:14:34 |
| Calls: | 1,703 |
| Calls today: | 4 |
| Files: | 4,088 |
| D/L today: |
57 files (2,385K bytes) |
| Messages: | 392,608 |