|
If you want to know which device a station uses look at the path in the
raw datas
or find it straight under
aprs.fi 'info'
for a callsign (& SSID). What we are looking for is named
APRS TO-CALL VERSION NUMBERS
of which the latest can be found on GitHub.com/aprsorg or here if you just click on the magenta part.
❷ OZ1PMX-10 (stationary) info page 
raw page 
Device is UI-View indicated in the raw datas which can be seen here in the line Last Path behind callsign> as APU25N, so APU25N = UI-View and is good for the exchange of messages ✔ ❸ LY2EZ (mobile) info page 
raw page 
Device is none indicated. It can be seen in the raw datas in the line Last Path behind callsign> as APRS only, so APRS = unnamed tracker and is not good for the exchange of messages ✘ ❹ DL1NZA (mobile) info page 
raw page 
Device is TinyTrack 4 indicated. It can be seen in the raw datas in the line Last Path behind callsign> as APTT4, so APTT4 = TinyTrack 4 tracker and is not good for the exchange of messages ✘ STOP ! That is not fully correct ! Tiny Track 4 can be used in combination with Geosat 5 or 6 and then serves as interface for messages. So you have to know / ask the guy. And if the user wants to make sure he is adressed it is wise to notify in the beacon comment i.e.: TT4@Geosat ❺ DL2BWO (stationary) info page 
raw page 
Device is none indicated. In the raw datas which can be seen here in the line Last Path behind callsign> we find APRM. aprs.fi does not know that APRM is the APRS program provided by DF8HL named APR MAP. Well, and you learned about it now. And the reason it is not 'automatically' indicated on aprs.fi is because it is not listed in the APRS TO-CALL VERSION NUMBERS. APRM = APR MAP and is good for the exchange of messages ✔ ❻ DF8LS-5 (Jogger) & SA7SKY (mobile) info page 
raw page 
Device is APRSdroid version 12 indicated in the raw datas which can be seen here in the line Last Path behind callsign> as APDR12, so APDR12 = APRSdroid in internet mode and is good for the exchange of messages (via TCP/IP) ✔ info page 
raw page 
Device is APRSdroid version 14 indicated in the raw datas which can be seen here in the line Last Path behind callsign> as APDR14, so APDR14 = APRSdroid in TNC KISS mode and is good for the exchange of messages (via radio) ✔ ❼ C91PM-10 (IGATE) info page 
raw page 
Device is Xastir version 200 indicated in the raw datas which can be seen here in the line Last Path behind callsign> as APX200, so APX200 = Xastir and is good for the exchange of messages ✔ ❽ DF1CHB-12 (mobile) info page 
raw page 
Device is none indicated. It can be seen in the raw datas in the line Last Path behind callsign> as APRS only, so APRS = unnamed tracker (well, here stated in the beacon comment) and is not good for the exchange of messages ✘ Well, not good for messages under SSID-12 and this configuration. We are not talking here about the ability of a tracker to operate in connected mode and exchange messages then ! ❾ DF8LS-7 (Jogger) info page 
raw page 
Device is Kenwood TH-D72 indicated in the raw datas which can be seen here in the line Last Path behind callsign> as U4RT30, so U4RT30 = TH-D72 and is good for the exchange of messages ✔ STOP ! That is not fully correct ! In this case it was U4RT30. The same Kenwood transceiver varies that signature but as a guideline: 'U' at the beginning is in most cases a Kenwood device. When looking into the APRS TO-CALL VERSION NUMBERS a TH-D72 is supposed to be APK003. ❿ DF8LS (mobile) info page 
raw page 
Device is ICOM: unknown version 510 (D-Star) indicated. It can be seen in the raw datas in the line Last Path behind callsign> as API510, so API510 = ICOM ID-5100 = D-Star and is not good for the exchange of messages ✘ STOP ! We are not talking here about the ability of that device to do messages within the D-Star system. But there is no interaction via APRS-IS between classic APRS and D-Star. In fact the (oneway) feeding of a D-Star packet including ICON, position and beacon comment is just done as subtext content of the databand and is not a 'conventional' UNPROTO packet ! It is not APRS, it is the impression of it. Specials It needs a little bit of training to learn which devices have message interfaces and then again there are special operations. And to give you the worst case in order to find out I tell you about SA7SKY as an example. SA7SKY once had a triple feed into the APRS-IS via VHF (TM-D710 & smart-beaconing), HF-RPR (SCS Tracker & automode ≈ 60-90 second) & D-Star (ICOM 5100 via PTT) ! So one beacon you identify the station as non-message capable but the next as able to handle. Result? YES HE CAN APRS-IS will always send messages via the latest gate a station was transmitting / beaconing / messaging last. So to stress for a last time the example: SA7SKY has a SCS Tracker only for RPR-HF-APRS running but since (and only if) the station is in range of a 2m Igate as well with a Kenwood TM-D710 and messages will get from i.e. 30m to 2m ! Very special, I know, but existing. In very rare cases hams have a display attached to their tracker so they can read (only) messages. A commercial example would be the Short Message Display (SMD) produced by Hinztec. Since that has no influence on the beacons that are transmitted there is no possiblility to find out. Again; unless the beacon comment shows a statement. Other items to keep in mind APRS-IS returns answers via the incomming path but does not check if it came from a rx-only gate ! So the answer would go down the drain without any indication. Some people like to manipulate the APRS TO-CALL VERSION NUMBERS to give it a personal touch. So that gives a bit of camouflage. Yes, and it still will work. As long as the 4 to 6 digits start which AP.... you will be fine. But don't exspect aprs.fi to realize which device you are finally using. APRSIS32 APRSIS32 it the only APRS program taking into respect the APRS TO-CALL VERSION NUMBERS and refuses to automatically offer the message window option for a non capable station. Anyway if for some reason you know it better a manual message window can be opened. |
