Spec-Related E-mail Date: Wed, 18 Jul 2001 08:33:20 -0400 (EDT) From: Bob Bruninga Subject: Re: [aprsspec] Area Objects On Tue, 17 Jul 2001, Curt Mills, WE7U wrote: > Area Object Questions: > ---------------------- > Perhaps circles/ellipses are defined with the lat/long point being > the center of the object? The upper left corner point of the box > the circle/ellipse would fit inside? Yes, that is correct > Same for rectangles: is the lat/long point the [LOWER]right-angle > corner, or perhaps the upper left corner of the rectangle it would fit > inside? Yes. Lower right. The offsets then define the distance back to the upper left. > 2) What sort of triangle? The triangle is just a specialized LINE. Draw the line using the rules for LINES. Then make it into an isosceles triangle symetrical about the vertical axis. Thus you can only draw isosceles triangles and only with the base down... > End result: I wouldn't be able to draw a triangle of any other > rotation. Imagine a search where I knew the direction of travel > to be northerly due to tracks being found, but I couldn't draw > a triangle on the search area that angled upwards... Use the LINE with a WIDTH. Im not sure that any of the other authors implemented LINE WIDTHS, but APRSdos did. This way you can draw a rectangle at any angle, showing a corridor or other such shape... > 3) For circles: Does it have to be a circle in lat/long, or could it > be a more useful circle with a constant radius (distance-wise)? Constant radius. APRSdos always scales a map so that there is no distortion based on latitude. Thus, a circle is a circle... > spec says lat/long, which isn't as useful as say a circle of 0.5 > miles radius. The main reason is that it will look like an ellipse > instead of a circle most places in the world. A 50 mile circle is an elipse on any mercator projection map. That is why APRSdos scales all map screens to latitude to eliminate that distortion. Most other authors have not done that. > 4) Unless circles and ellipses are defined differently, why have > circles at all? Ellipses can be circles. Actually, we never did elipses. The only definitions in APRS are circles, lines boxes and triangles. There was no interest in doing elipses.. > One of the shareware APRS programs appears to have incorrect sizing > for the area objects, and they also go the wrong direction from the > corner point w.r.t. what the spec says. Yep, I have been fighting this for years. There seems to be little interest in fixing it... Bob Date: Thu, 19 Jul 2001 09:52:15 -0500 From: Gerry Creager N5JXS Subject: Re: [aprsspec] Area Objects Date: Mon, 17 Apr 2000 18:15:30 -0400 (EDT) From: Bob Bruninga Subject: [aprsspec] Re: Query Lines Boxes and Etc On Mon, 17 Apr 2000, Sadowski, Allan wrote: > An interesting thought... If you could have a LAT/LON and a sequence of > vectors (length and direction) then it'd be a short notation for an object > path... so tornado - hurricane paths could be displayed... hmmm interesting > in the case of a hurricane if each segment equated to an hour in time... What I had originally proposed was before we began using BASe-91 characters and compressed format, so here is what I would propose today using the existing ITEM format (compressed). )NAME!\yyyyxxxx)SSSxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxyx ^^^^^^^^^^^^^^^^ WHERE this is just an ITEM named "NAME" in compressed format using the symbol characters of "\)" (This is a currently undefined SYMBOL). The YYYYXXXX is the starting point anywhere on the planet to the nearest foot. The first 3 bytes in the COMMENT field for this ITEM is the SCALE in base 91, giving a scale anywhere from 1 foot to 142 miles (per line segment) The remainder of the line are any number of pairs of X/Y offsets from each previous point. Each offset is a single base 91 number with anything above 45 being positive and below 45 being negative. The result then can be any multifaceted shape from a small scale of about 1 foot per line segment up to an object 142 miles on a side. NOtice that this is a completely legal ITEM. Its just that the SYMBOL (ICON) has this unique set of display rules... de WB4APR. Thus, I can transmit to you in ONE PACKET a complete MAP of the route from the nearest INTERSTATE to my front door in a single packet... Date: Tue, 18 Apr 2000 15:10:17 -0400 (EDT) From: Bob Bruninga Subject: [aprsspec] Re: Query Lines Boxes and Etc On Tue, 18 Apr 2000, Bob Bruninga wrote: > > >By using an origin and base91 offsets, then we could send polygons(or > > >contiguous line segments with as many as 40 points in a single packet. > How about if we defined the SSS scale factor to be in Meters. Then > the range of scale would be from 3 feet to 420 miles before you would have > to go to multiple segments. BETTER IDEA: The offsets and scale should all be done in terms of LAT/LONG (not meters) to avoid any complex spherical trig functions. If we let the units be in terms of .000001 degree of LAT/LONG, then we get approximately 1 meter precision. AND since this is just a "shape" then if we define the symbol character of ")" to be a polygon then it can be transmitted in ANY existing APRS POSIT, OBJECT or ITEM report. So the format wouild be: * ANY POSIT, OBJECT or ITEM defines the origin of the polygon * SYMBOL of "\)" indicates it will be a polygon * Comment field format is then: CSSSxyxyxyxyxyxyxy... Where C is the color 0-15 (or 16-32 means FILL the polygon) SSS is the scale factor in units of .00001 degree of lat/long xy are offset pairs between each subsequent point Thus the following comment field on an OBJECT located at 3847.04N 07710.53W could completely define the Washington DC BELTWAY: +!$ Date: Tue, 17 Jul 2001 14:13:11 -0700 (PDT) From: "Curt Mills, WE7U" Subject: [aprsspec] Re: Weather On Tue, 17 Jul 2001, Bob Bruninga wrote: > On Tue, 17 Jul 2001, Curt Mills, WE7U wrote: > > > 1) Why are there two 's' fields defined, wind speed _and_ snow? > > Is one a typo and should have been a capital 'S'? Probably snow? > > In the complete WX format, the WIND SPEED does not have a "s" format > identifier since it is in a FIXED position. Thus if you see "s", then it > is snow. > > But then the Sprouls added the format for their verbose positionless > Weather format and I think it does have an s... That's going to be rather confusing in the future. Both wind speed and snow in the same packet have the same identifier for the field. > > 2) Rainfall in last 24 hours. I assume this is intended to be a > > rolling count going backwards from the current time 24 hours, and not > > the amount of rain that was seen yesterday. "last 24 hours" implies > > a rolling count to me. I'm fairly sure on this one, just checking. > > Yes. I think only the original APRSdos does this. Newer programs took > the simpler approach of starting the count at midnight... Xastir does this (as of Saturday): Keeps 24 hourly data buckets and uses them to come up with the 24-hour rain and the since-midnight rain totals. The 24-hour rain is the difference between current rain total and the lowest rain_total stored in the 24 buckets. Seemed like the right way to do it. > > 3) The "Other parameters" _letters_ are defined, but the number of > > bytes for each field are not. > > I'll assume 'L' has 4 bytes (L999) YES > > 's' has ?? bytes? Format? (s1.25, s100.99) NO. 3 fixed bytes Ok. So we can transmit inches of snow from "s00" to "s99", and not fractional inches? Is that intended to be snow base or fresh snow? If fresh snow, what timeframe? You deleted the below line from your response. 'l' is in the spec also under the "Other parameters" heading, supposed to be luminosity greater than 1000. Not knowing the range for luminosity, do I assume that a 1000 gets added to a three digit value to give the final result for the 'l' field? > > 'l' has ?? bytes? (l1000, l10000, l100000000) So a value of 1500 would be encoded as "l500" ?? Can luminosity ever be greater than 1999? Curt Mills, WE7U Date: Tue, 17 Jul 2001 12:11:45 -0700 (PDT) From: "Curt Mills, WE7U" Subject: [aprsspec] Weather Page 64 of the APRS spec talks about weather report format: "s = sustained one-minute wind speed (in mph). p = rainfall (in hundredths of an inch) in the last 24 hours. ... Other parameters that are available on some weather station units include: L = luminosity (in watts per square meter) 999 and below. l (lower-case letter "L") = luminosity (in watts per square meter) 1000 and above. (L is inserted in place of one of the rain values). s = snowfall (in inches) in the last 24 hours. # = raw rain counter" Weather Questions: ------------------ 1) Why are there two 's' fields defined, wind speed _and_ snow? Is one a typo and should have been a capital 'S'? Probably snow? 2) Rainfall in last 24 hours. I assume this is intended to be a rolling count going backwards from the current time 24 hours, and not the amount of rain that was seen yesterday. "last 24 hours" implies a rolling count to me. I'm fairly sure on this one, just checking. 3) The "Other parameters" _letters_ are defined, but the number of bytes for each field are not. I'll assume 'L' has 4 bytes (L999) 'l' has ?? bytes? (l1000, l10000, l100000000) 's' has ?? bytes? Format? (s1.25, s100.99) '#' has ?? bytes? Units? Format? 4) What is the "raw rain counter"? Is that the "total rain" counter that some weather stations provide, or the raw counts from the rain bucket over some time period? How many bytes for that field and in what format? 1/100 inch? Inches? Counts? Date: Tue, 17 Jul 2001 15:38:19 -0400 (EDT) From: Bob Bruninga Subject: Re: [aprsspec] Weather On Tue, 17 Jul 2001, Curt Mills, WE7U wrote: > > Page 64 of the APRS spec talks about weather report format: > Weather Questions: > ------------------ > 1) Why are there two 's' fields defined, wind speed _and_ snow? > Is one a typo and should have been a capital 'S'? Probably snow? In the complete WX format, the WIND SPEED does not have a "s" format identifier since it is in a FIXED position. Thus if you see "s", then it is snow. But then the Sprouls added the format for their verbose positionless Weather format and I think it does have an s... > 2) Rainfall in last 24 hours. I assume this is intended to be a > rolling count going backwards from the current time 24 hours, and not > the amount of rain that was seen yesterday. "last 24 hours" implies > a rolling count to me. I'm fairly sure on this one, just checking. Yes. I think only the original APRSdos does this. Newer programs took the simpler approach of starting the count at midnight... > 3) The "Other parameters" _letters_ are defined, but the number of > bytes for each field are not. > I'll assume 'L' has 4 bytes (L999) YES > 's' has ?? bytes? Format? (s1.25, s100.99) NO. 3 fixed bytes > '#' has ?? bytes? Units? Format? #### 4 BYTES always > > 4) What is the "raw rain counter"? Is that the "total rain" counter > that some weather stations provide, or the raw counts from the > rain bucket over some time period? How many bytes for that field > and in what format? 1/100 inch? Inches? Counts? It is the current 4 digit count from that instrument. It is useless unless the recepient is keeping the previous values for comaprison... de WB4APR, Bob Date: Tue, 17 Jul 2001 18:49:34 -0400 (EDT) From: Bob Bruninga Subject: Re: [aprsspec] Weather On Tue, 17 Jul 2001, Curt Mills, WE7U wrote: > Ok. So we can transmit inches of snow from "s00" to "s99", and not > fractional inches? Is that intended to be snow base or fresh snow? > If fresh snow, what timeframe? I meant sXXX so 0.0 to 9.9 then 10 to 999 inches... > > You deleted the below line from your response. 'l' is in the spec > also under the "Other parameters" heading, supposed to be luminosity > greater than 1000. Not knowing the range for luminosity, do I assume > that a 1000 gets added to a three digit value to give the final > result for the 'l' field? I think it is lxxx and if is greater than 1000 then it becomes Lxxx where you can think of the L as the onethousands digit... I dont have it in front of me, but that is the gyst of it.. Bob Date: Thu, 11 Apr 2002 15:57:06 -0400 (EDT) From: Bob Bruninga Subject: Re: [aprsspec] Weather Icons On Thu, 11 Apr 2002, Curt, WE7U wrote: > So, are the \W and /W icons to be used for stations sending Complete > Weather Reports on APRS? If so, the spec text is wrong. > > I just tweaked Xastir to only allow \_ and /_ for weather stations. > If the NWS icons are intended for use at NWS _as_ weather stations, > then I need to tweak the code some more, and the spec needs to be > corrected as well. Yes, I have always accepted /W and \W interchangeably with /_ and \_. thanks for finding the bug in the spec... Bob > How do you differentiate "No X" from "No sensor for X". > Is your windspeed 0 because it really is, or because you don't have a sensor? Well, the spec allows "..." or " " for the fields. It also allows any field to be absent, as long as it's not one of the few required fields at the beginning. The number of '.' or ' ' characters matches the field width. This is part of a private reply from Bob. I asked his permission to post portions of it to the list. Perhaps someday if a volunteer shows up to put out a revised spec, this info and the recent weather info about snow fields, luminosity, and raw rain counter can be put into the spec. Since there are no examples for these, the number of bytes in each field is undefined in the spec. Also the "s" flag for Snow conflicts with another implementation regarding sustained one-minute wind speed. Note that the spec does not fully specify the fields for the additional weather fields possible (details from Bob in an earlier message to the aprsspec list), and for Area Objects, ellipses were never implemented, and the reference "corner" and direction for the offsets for all Area Objects/Items is incorrect in the spec. The spec also doesn't specify how to define a triangle or a circle properly. Circles have no corners, and triangles can be defined many ways. See the below and earlier messages from Bob in the aprsspec list for the definitions. Also consider putting in a reference packet for each type of object so that the sizes and reference points can be checked in a new APRS implementation. We're currently noticing that our objects and Bob's objects are of different sizes. Wah. ---------- Forwarded message ---------- Date: Fri, 20 Jul 2001 20:21:57 -0400 (EDT) From: Bob Bruninga Subject: Re: [aprsspec] Re: Area Objects (fwd) On Fri, 20 Jul 2001, Curt Mills, WE7U wrote: > > > Perhaps circles/ellipses are defined with the lat/long point being > > > the center of the object? The upper left corner point of the box > > > the circle/ellipse would fit inside? > > > > Yes, that is correct > > Which? I asked two questions that were entirely different. This is > an important point for me. No, I only see one answer. Yes.. The point is the center. The offset is the upper left corner defined as the corner of the box it fits into... > Is the point: > 1) The center of the circle? > 2) The upper left corner point of the box it would fit inside? > 3) The lower right corner point of the box it would fit inside? > > Which one? Your oritiginal question I dont recall seeing any reference to the lower right. If so, it is not involved. bob Date: Thu, 16 Aug 2001 09:31:04 -0700 (PDT) From: Olivier Calle Subject: [aprsspec] Area Object Sizing There was a thread on this topic in late June that started with my confusion in trying to decode area objects by reading the spec. After discussion in that thread with Steve Dimse, we concluded that the spec was a bit misleading and came up with the following equation: offset_in_degrees = (offset_in_packet / 100)^2 Later, I communicated privately with Bob because this equation still seemed to create the wrong size areas. He sent me some example objects, describing their sizes (i.e.: rectangle 20miles by 30miles), for me to compare. I then was sure that the above equation is not correct. Bob then sent me a code snippet and I believe I found the correct equation and a possible explanation of the confusion: offset_in_degrees = (offset_in_packet^2) / 1500 Using that equation gave me areas with sizes the same as the example objects that Bob had sent me. I believe the confusion may have come from the comment near that section of code that talks about 100ths of a degree squared. Comments? -- Olivier Calle Date: Fri, 6 Apr 2001 04:25:03 -0000 From: Dale Huguley Subject: Re: Weather alert parsing broken? Hi Rolf & All- Rolf said: > I only saw NWS stations with fixed size 6 character upercase letter > only names. I use this as a selection criteria together with ":NWS-" > in the information field. Have you seen other names? > I hope to have the WX server interactive by the Dayton Hamfest and will be adding "SKY" in addition to the ":NWS-" messages from the "positionless" stations like "MIASVR". This is in order to not fill up the limited message buffer in the D700 and D7a radios. An alternative way to filter is to also look for a fixed 5 character sequence after the curly brace at the end of anything from my parser. I am going to have to go to ssid's on rare occasions also - 73 de kg5qd Dale Date: Sun, 25 Nov 2001 11:24:56 +0000 From: dale huguley Subject: [aprssig] Fundamental Changes to Wxsvr Hi All- As I outlined at Dayton this year- there are some changes in the works to the Wxsvr Data stream. The memory problem in the D7 and D700 will force a rewrite of the rest of the display software using APRS. Since I have gotten nothing but grief lately about the Tropic and other lengthy sets of packets- I guess I'll change it slowly and let the various authors try to catch up. When Mark Sproul came up with the original "NWS-" type method to Highlight a county in Winaprs, it was designed for manual transmission of a couple of counties by a skywarn operator. I began to add human readable messages to the county listings in order to fill out the information transmitted. I call these "associated packets". They appear to come from the same callsign and have a message number at the end which is unique to the associated packets. AFGNPW>APRS::NWS-WARN :251500z,WIND,AK_Z213, {P7IAA AFGNPW>APRS::NWS-WARN :HIGH WIND WARNING THROUGH SATURDAY NIGHT {P7IAB AFGNPW>APRS::NWS-WARN :FOR SAINT LAWRENCE ISLAND {P7IAC Ok fine- but a more verbose warning will fill the D700 memory even if unwanted- there is no way to filter "NWS-" warnings in the Kenwood radios. So the first adjustment will be to change any message that doesn't light up an area to a message to a message group. AFGNPW>APRS::NWS-WARN :251500z,WIND,AK_Z213, {P7IAA AFGNPW>APRS::SKYAFG :HIGH WIND WARNING THROUGH SATURDAY NIGHT {P7IAB AFGNPW>APRS::SKYAFG :FOR SAINT LAWRENCE ISLAND {P7IAC Setting "SKY***" as a message group in the Kenwoods will give you all the Skywarn messages- Setting "SKYAFG" as a message group will give you the messages for the AFG NWS office only. This change should cut the problem in the D700 memory in half or better. Someone that doesn't want any skywarn messages must place something in their Message Groups or the radios will not filter messages at all. During the winter there are very long messages to outline areas because the areas affected by a winter storm can be huge. ABRWSW>APRS::NWS-WATCH:252215z,WINTER_STORM,MN_Z039,MN_Z046,SD_Z005,SD_Z006,SD_Z007, {PASAA ABRWSW>APRS::NWS-WATCH:252215z,WINTER_STORM,SD_Z008,SD_Z010,SD_Z011,SD_Z017,SD_Z018, {PASAB ABRWSW>APRS::NWS-WATCH:252215z,WINTER_STORM,SD_Z019,SD_Z020,SD_Z021,SD_Z022,SD_Z023, {PASAC ABRWSW>APRS::NWS-WATCH:252215z,WINTER_STORM,SD_Z033,SD_Z034,SD_Z035,SD_Z036,SD_Z037, {PASAD ABRWSW>APRS::NWS-WATCH:252215z,WINTER_STORM,SD_Z045,SD_Z048,SD_Z051, {PASAE 3 of these type of warnings and the D700 memory is full no matter what the message groups setting. The NWS has a compact format for sending this type of information which looks like: MNZ039-046-SDZ005>008-010-011-017>023-033>037-045-048-051-252215- converted to aprs type it would look like ABRWSW>APRS::NWS-WATCH:252215z,WINTER_STORM,MNZ039-046-SDZ005>008-010-011-017>023-033>037-045-048-051 {PASAA Changing to this would require the software on the receiving end to know that SDZ005>008 means SDZ005,SDZ006,SDZ007,SDZ008. There is no guarantee that the numbers are sequential so this must come from a database of some type. The shape files being used by Winaprs,Xastir and Aprs Plus have the data within them. Aprs Dos would have to use a database of some type. This is more long-term change than moving to message groups- it requires a change in lots of pieces of software. The changes I have outlined so far will cut the memory problem in the D700 by 75% or so- but doesn't address the problem I see with usefulness. If the D700 or D7 is your only means of communication - mobile, camping , boating etc.- then the information you need is not available. If you need to read the text for a Winter Storm Warning to see the timing for heavy snow in a mountain pass - you have to use something besides aprs even though the you have the equipment. I plan to have the sever interactive- send a message to ABRWSW KG5QD>APRS::ABRWSW :? and receive: ABRWSW>APRS::SKYABR5QD:...WINTER STORM WATCH FOR MONDAY... ABRWSW>APRS::SKYABR5QD:A STRONG LOW PRESSURE SYSTEM WILL MOVE INTO THE ABRWSW>APRS::SKYABR5QD:AREA SUNDAY NIGHT AND MONDAY. SNOW WILL ABRWSW>APRS::SKYABR5QD:START SUNDAY NIGHT IN THE WEST AND THE HEAVIEST ABRWSW>APRS::SKYABR5QD:SNOW WILL MOVE EAST MONDAY. TOTAL SNOW ABRWSW>APRS::SKYABR5QD:ACCUMULATIONS WITH THIS STORM WILL REACH 4 TO 8 ABRWSW>APRS::SKYABR5QD:INCHES. HIGH WINDS WILL ALSO ACCOMPANY THE LOW ABRWSW>APRS::SKYABR5QD:AND REDUCE VISIBILITY IN BLOWING SNOW. Much more useful information- set "SKYABR???" as a message group with ??? being the last three characters of your call. This could be sent also to your call specifically - but I prefer letting anyone that cares to read it. As far as implimentation- the change to message groups will happen very soon now- this I can do on my own. The change in the way counties and zones are enumerated has to be done by everyone writing software but me, so it is out of my hands. The interactive portion is the hardest to write code for- may take a while. Also it has become obvious that I have to take a tighter reign on who I-gates the information I parse- I may have to go to a more secure server type of situation. 73 de kg5qd Dale Date: Thu, 29 Nov 2001 12:14:36 +0000 From: dale huguley Subject: [aprssig] Message Groups and Wxsvr Hi All- Time to get out those D700 and D7 manuals and program a message group or groups to receive verbose messages from Wxsvr. Wildcards are allowed so that programming "SKY*" will get you all of the messages available in your particular RF situation. "SKY???" (where ??? is the County Warning Area) filters all but your local area. If you don't know what area you are in - the code will match the first three characters of the "From" call that the "NWS-" messages use. Example-- OTXWSW>APRS::NWS-ADVIS:292300z,WX_MESSAGE,WA_Z042, {TBKEA OTXWSW>APRS::SKYOTX :HEAVY SNOW WARNING CONTINUES TODAY {TBKEB Without "SKY*" or "SKYOTX" in your message groups you will not see the second message. Some more universal group codes: SKYNHC National Hurricane Center - Atlantic SKYEPC National Hurricane Center - Eastern Pacific SKYCPC Central Pacific Hurricane Center - Honolulu SKYSEC Space Environment Center (Space Wx) Boulder Colorado You may add up to six message groups by putting a comma between them. So -- if you want Miami messages, Atlantic Hurricane messages and Space Weather- you would program "SKYMIA,SKYNHC,SKYSEC". A useful way to do this for skywarn situations is to use the "PM" system of the D700 and have a normal and a filtered message group set-up in different memories -- and be able to change back and forth with a couple of keystrokes. 73 de kg5qd Dale Date: Thu, 15 Aug 2002 09:06:10 -0400 From: E. Tupis Subject: [aprsspec] Spec Clarification Request I'd like to formally request that the following be considered by those "in the loop" in making these decisions... == The issue == The way that icon determination for 4-cypher Grid-in-Status transmissions is ambiguous and can lead to unintended result, unless clarified. == Example == This is a 6-cypher grid w/icon & overlay identified (no ambiguity): >FM19XXBV will display the "V" icon with the letter "B" overlayed Is this a 4-cypher grid w/icon & overlay or is this a 6-cypher grid with a forgotten icon & overlay? (ambiguity): >FM19XX will display the "X" icon with the letter "X" overlayed == Suggested Solution == Require 6-cypher gridsquare for Grid-in-Status when icon & overlay is desired o When no icon & overlay is included, display as gridsquare icon o When only 4-cyphers are used, accept and display as gridsquare icon Respectfully, Ev, W2EV Date: Wed, 21 Aug 2002 06:27:51 -0400 From: "Ev Tupis (W2EV)" Subject: [aprsspec] Re: Grid-in-Status Ambiguous Icon & Overlay followup? > >I sent a reply 2 days ago after I returned form Travel... > >Maybe you missed it? > > I think I also missed it. However, I didn't think there was any > ambiguity in the spec regarding 4 character and six character grids. Or > perhaps I'm forgetting what Ev originally asked? The ambiguity occurs when a 4-cypher grid is sent, using grid-in-status. I discovered it as I was designing a new set of icons to release to the BEACONet community (where we use GR##ID exclusively)... >GR##IDoI will display an icon associated with "I" with an overlay of "o". >GR##ID is ambiguous as one doesn't know if the intent was to send a 6-cypher grid without an icon or overlay expressly chosen or if it is a 4-cypher grid with an icon of "D" and an overlay of "I". I offered the suggestion that the grid-in-status spec consider requiring 6-cypher grids and to display as /G if there is no icon/overlay shown...but am more interested in removing the ambiguity than necessarily getting stymied by how that is accomplished right now. I was suprised by the lack of comment on it, but then realized that the Lyris system "burped" at around the same time and many may have missed the post. Best wishes, Ev, W2EV BEACONet Date: Thu, 22 Aug 2002 08:46:40 -0400 (EDT) From: Bob Bruninga Subject: [aprsspec] Re: Grid-in-Status Ambiguous Icon & Overlay followup? On Wed, 21 Aug 2002, Ev Tupis (W2EV) wrote: > > >I sent a reply 2 days ago after I returned form Travel... > > >Maybe you missed it? > how that is accomplished right now. I was suprised by the lack of comment on > it, but then realized that the Lyris system "burped" at around the same time and > many may have missed the post. Yes, it appears that lyris ate my reply. Here it is: > I agree. The >GG##gg/$ construct was only meant for the full 6 digit > gridsquare. If the full 6 digits are not konwn, then I think the > letters ZZ or something else were supposed to be substituded.... > Thanks > Bob Date: Thu, 22 Aug 2002 08:48:08 -0400 (EDT) From: Bob Bruninga Subject: [aprsspec] Re: Grid-in-Status Ambiguous Icon & Overlay followup? On Wed, 21 Aug 2002, Roger Barker wrote: > Have a read of section 16 of the APRS spec. You will see that the > table/overlay and symbol characters must be included, they are not > optional. If you only send a total of six characters, then it must be > interpreted as a four character locator. Yes, that is the correct interpretation too... bob