Non Aircraft Symbols / Symbol Tables cause Exception and Empty AprsPacket

[rlkollman]

I am attempting to use your software for a non-aircraft related application. Unfortunately, if any Symbol table other than '/' or '\' are sent by the client, the PacketInfo.Parse() will fail as the aprsMessage.SymbolTable = line is dependent on the dictionary 'Constants.Maps.SymbolTableMap', which does not have any other symbol table in it.

I would like to see the inclusion of a SymbolTableMap.Unknown based on a very unlikely used character (@ symbol perhaps), and the Enum needs to be added as well. Then, that aprsMessage.SymbolTable = line could be: aprsMessage.SymbolTable = (Constants.Maps.SymbolTableMap.ContainsKey(rawData[8]), Constants.Maps.SymbolTableMap[rawData[8]], SymbolTable.Unknown);

And, SymbolTable.Unknown could be enum 0.

Similarly, the aprsMessage.Symbol could be assigned with an Unknown option, or at the very least, not dependent on just 2 different types of tables. To ensure these lines to not cause the parsing to completely fail if the Symbol is not an aircraft, though, something needs to be amended. I know the existing code utilizes static Tables and Symbols, so adding an 'Unknown' to each would at least cause the parse not to fail.

Otherwise, it's all working well! Thanks :)

[corstian]

I will try to look into this upcoming week. I have some existing issues where an apostrophe is not properly recognized, so might as well be combined with this.

Would it be valuable to make the symbol table assignable, or are these symbols generally the same across all APRS servers?

[rlkollman]

Unfortunately, I am fairly new to APRS, dabbling with it for about a year now. So, referencing the APRS Protocol Specification (http://www.aprs.org/doc/APRS101.PDF - pages 90 & 91), apparently there are, in fact, only 2 tables, but, the reporting station may use numbers or upper-case letters to designate a number or letter to overlay on the symbol from table 2. If they want their car to say "3" on top of the car icon from the Secondary Table, then, what your code refers to as the Symbol Table byte (rawData[8] for CurrentMicE, and rawData[9] for PositionWithoutTimestamp...) is that designation: '3', and the Symbol Table in use is the Alternate Table.

So... If I am understanding this correctly, if the Symbol Table Byte is '/', the Primary Table is in use. If the Symbol Table Byte is '\' or '0 - 9' or 'A - Z', then the Secondary Table is in use, but the number or letter designated should be displayed on top of the Symbol (which, this code doesn't need to worry about since you're not actually providing the graphical icons).

Then, I think the actual Symbol is fairly standard across the board. But, it does change under APRS standards from time to time. http://www.aprs.org/symbols/symbolsX.txt and http://www.aprs.org/symbols/symbols-new.txt depict some of the changes over the years, so it may be difficult to keep up within code.

As for my project, I am not even interested in Symbol Tables and Symbols. The issue I have is that if anything other than '/' or '\' appears in that particular byte, the Parse() method has a 'KeyNotFound' exception due to the letter or number not appearing in the Constants.Maps.SymbolTableMap dictionary, and no AprsMessage class is returned, thus I cannot get GPS coordinates or anything from any APRS Message without one of the two keys in that dictionary (if that makes sense).

As much as this is an enhancement, I believe it really is a bug because the Parse() method will never provide an AprsMessage class in return (it returns null/nothing because an exception occurs during Parse()ing) unless the Symbol Table Byte is '/' or '\'.

[corstian]

Can you share an APRS message on which the parser fails, so I can write a test around that?

[rlkollman]

That would probably be helpful... Sorry about that:

https://github.com/skyhop/AprsClient/blob/457624a5f8d927b49661a262e3d1dceed0170717/Boerman.AprsClient/Models/PacketInfo.cs#L103

I believe this one will also cause an error if the Symbol is not any of the 4 in the PrimarySymbolTableSymbolMap and SecondarySymbolTableSymbolMap: https://github.com/skyhop/AprsClient/blob/457624a5f8d927b49661a262e3d1dceed0170717/Boerman.AprsClient/Models/PacketInfo.cs#L108

I would also expect these issues in the MicE Parsing as well: https://github.com/skyhop/AprsClient/blob/457624a5f8d927b49661a262e3d1dceed0170717/Boerman.AprsClient/Models/PacketInfo.cs#L85

Thanks!

[corstian]

Hmm naah I mean a text string which represents an APRS message as in something which needs to be run through the parser. See this file for examples: https://github.com/skyhop/AprsClient/blob/master/Boerman.AprsClient.Tests/AprsMessageTests.cs

The thing is that I currently have no alternative APRS feed to test on. As I have implemented both primary and secondary symbol tables in the dev branch I think this might solve the problem, but I'd love to test.

[rlkollman]

Here are some examples from the US:

KB9VBR-N>APDG03,TCPIP,qAC,T2INDIANA:!4456.70ND08937.08W&/A=000000440 MMDVM Voice 431.50000MHz +0.0000MHz, KB9VBR_Pi-Star KD9GCX-S>APDG01,TCPIP,qAC,KD9GCX-GS:;KD9GCX B 160126z4415.63ND08817.60Wa/A=000010RNG0001 440 Voice 433.00000MHz +0.0000MHz WE9C0M-8>APN391,qAR,K9FR:!4541.60NS09120.85W#PHG6560 W3, In honor to Bill W9NNS KD9GCX-B>APDG02,TCPIP,qAC,KD9GCX-BS:!4415.63ND08817.60W&/A=000010RNG0001 440 Voice 433.00000MHz +0.0000MHz

[corstian]

I have implemented a test for these message, and now they are parsed properly: https://github.com/skyhop/Aprs/blob/e3c9628faeab169d8b098ddd3a3684491c0ef899/Skyhop.Aprs.Client.Tests/AprsMessageTests.cs#L135

As part of moving these projects over to proper Skyhop namespaces I have updated the package on NuGet under the Skyhop.Aprs.Client name. You can find it here: https://www.nuget.org/packages/Skyhop.Aprs.Client

Please let me know whether this solves your issues!

[rlkollman]

Great progress - thanks! The adjustments you made to the Skyhop.Aprs.Client library seems to have resolved the ones above. Some additional ones I am seeing not parse with the '@' DataType byte: AA9NV>APWW10,TCPIP,qAC,T2FRANCE:@151147h4421.57NI08905.80W#AA9NV APRS-IS for Win32 Waupaca, WI KD9MIL-10>APWW10,TCPIP,qAC,T2CSNGRAD:@151150h4416.97N/08824.50W-PHG7280 ATW WA9TT-10>APWW10,TCPIP*,qAC,T2ONTARIO:@151212h4417.74N/08828.58W-APRS-IS for Win32

This one parsed as 'DataType.Object', but the Lat/Lng were null in the packet. KB9TYC>APMI06,KD9EJA-8,WIDE2-1,qAR,K9FR:;145.470WI181506z4513.17N/09112.86WrN9LIE/R 110.9pl Net Thursday Night at 8:00 p.m. tcra.org

[corstian]

Closing this issue as unrecognized symbols will not discard the message anymore.

Regarding parsing of station messages, that's something I'll need to fix another time.