|
Hi Lynn, have been playing with MO lately and notice with the newest hydra that altitude shows as feet but looks like its being decoded as meters.
See screen shot. KB3ZTO-2 is a fixed digi and he has set a fixed altitude of 1591 feet asl but MO is showing 485.
KB3KBR Greg. Sent from my Samsung Galaxy smartphone.
|
|
|
That's definitely a bug that I'll have to get fixed. He's
actually transmitting Mic-E encoded altitude which apparently I'm
interpreting incorrectly as feet instead of meters. From
aprs.fi's decoded raw packets view:
2023-02-08 11:22:15
EST: KB3ZTO-2>T1QQ4T,WIDE2-2,qAO,K3ACS-10:'kUpl <0x1c>#/"95}Scharf Solar Energy 14.1V 10C
type:
location
format:
mice
srccallsign:
KB3ZTO-2
dstcallsign:
T1QQ4T
latitude:
41.190666666667 °
longitude:
-79.964 °
course:
0 °
speed: 0
km/h
altitude:
485 m
symboltable:
/
symbolcode:
#
mbits:
101
posresolution:
18.52 m
posambiguity:
0
comment:
Scharf Solar Energy 14.1V 10C
And if you have contact with KB3ZTO, he may want to correct the
other packet definition in his TT4.
2023-02-08 11:16:02
EST: KB3ZTO-2>APTT4,WIDE2-2,qAR,KC3ARY:Barkeyville Digi [Unsupported
packet format]
srccallsign:
KB3ZTO-2
dstcallsign:
APTT4
There is no "B" datatype indicator in the APRS specification.
This is a popular configuration mistake for TT4 owners. They
really should prefix this string with a > character to make it
a spec-compliant status report. However, Chapter 19 of
aprs101.pdf provides for this as follows:
All Other Packets
Packets that do not meet any of the formats described in this
document are
assumed to be non-APRS beacons. Programs can decide to handle
these, or
ignore them, but they must be able to process them without ill
effects.
APRS programs may treat such packets as APRS Status Reports.
This allows
APRS to accept any UI packet addressed to the typical beacon
address to be
captured as a status message. Typical TNC ID packets fall into
this category.
Once a proper Status Report (with the APRS Data Type Identifier
>) has
been received from a station it will not be overwritten by other
non-APRS
packets from that station.
However, aprs.fi's parser labels these packets as "Unsupported"
instead of interpreting them as a Status Report.
Lynn (D) - KJ4ERJ - Author of APRSISCE
for Windows Mobile and Win32
On 2/8/2023 4:42 AM, Greg Depew wrote:
Hi Lynn, have been playing with MO lately and
notice with the newest hydra that altitude shows as feet but
looks like its being decoded as meters.
See screen shot. KB3ZTO-2 is a fixed digi and he
has set a fixed altitude of 1591 feet asl but MO is showing
485.
KB3KBR Greg.
Sent from my Samsung Galaxy smartphone.
|
|
|
Yep, the status report is on his list if tweaks next time he's up the water tower. He's built a complete stand-alone digi that's solar powered and sits on top of a 161 ft water tower. I believe he said if the sun were to go out of existence
he'd be able to run for 7 days on battery. Thanks for checking the bug.
I'm not sure if the tt4 documentation says about prefixing with the >. I found out the hard way when experimenting with mine.
Thanks again!
KB3KBR Greg. Sent from my Samsung Galaxy smartphone.
toggle quoted message
Show quoted text
-------- Original message --------
From: Lynn Deffenbaugh <kj4erj@...>
Date: 2/8/23 11:37 (GMT-05:00)
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Mo showing incorrect altitude
That's definitely a bug that I'll have to get fixed. He's actually transmitting Mic-E encoded altitude which apparently I'm interpreting incorrectly as feet instead of meters. From aprs.fi's decoded raw packets view:
2023-02-08
11:22:15 EST: KB3ZTO-2>T1QQ4T,WIDE2-2,qAO,K3ACS-10:'kUpl <0x1c>#/"95}Scharf Solar Energy 14.1V 10C
type:
location
format:
mice
srccallsign:
KB3ZTO-2
dstcallsign:
T1QQ4T
latitude:
41.190666666667 °
longitude:
-79.964 °
course:
0 °
speed:
0 km/h
altitude:
485 m
symboltable:
/
symbolcode:
#
mbits:
101
posresolution:
18.52 m
posambiguity:
0
comment:
Scharf Solar Energy 14.1V 10C
And if you have contact with KB3ZTO, he may want to correct the other packet definition in his TT4.
2023-02-08
11:16:02 EST: KB3ZTO-2>APTT4,WIDE2-2,qAR,KC3ARY:Barkeyville Digi [Unsupported
packet format]
srccallsign:
KB3ZTO-2
dstcallsign:
APTT4
There is no "B" datatype indicator in the APRS specification. This is a popular configuration mistake for TT4 owners. They really should prefix this string with a > character to make it a spec-compliant status report. However, Chapter 19 of aprs101.pdf
provides for this as follows:
All Other Packets
Packets that do not meet any of the formats described in this document are assumed to be non-APRS beacons. Programs can decide to handle these, or ignore them, but they must be able to process them without ill effects.
APRS programs may treat such packets as APRS Status Reports. This allows APRS to accept any UI packet addressed to the typical beacon address to be captured as a status message. Typical TNC ID packets fall into this category. Once a proper Status Report (with
the APRS Data Type Identifier >) has been received from a station it will not be overwritten by other non-APRS packets from that station.
However, aprs.fi's parser labels these packets as "Unsupported" instead of interpreting them as a Status Report.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
On 2/8/2023 4:42 AM, Greg Depew wrote:
Hi Lynn, have been playing with MO lately and notice with the newest hydra that altitude shows as feet but looks like its being decoded as meters.
See screen shot. KB3ZTO-2 is a fixed digi and he has set a fixed altitude of 1591 feet asl but MO is showing 485.
KB3KBR Greg. Sent from my Samsung Galaxy smartphone.
|
|
|
From the manual...
"ALTNET [ call ]
Sets the ALTNET callsign, sent as the destination callsign in all outgoing packets,
except MIC-E position packets. An SSID should not be used. The default of APTT4 is
restored when cleared."
Ben Miller, PE retired KD9BBB
Yep, the status report is on his list if tweaks next time he's up the water tower. He's built a complete stand-alone digi that's solar powered and sits on top of a 161 ft water tower. I believe he said if the sun were to go out of existence
he'd be able to run for 7 days on battery. Thanks for checking the bug.
I'm not sure if the tt4 documentation says about prefixing with the >. I found out the hard way when experimenting with mine.
Thanks again!
KB3KBR Greg. Sent from my Samsung Galaxy smartphone.
-------- Original message --------
Date: 2/8/23 11:37 (GMT-05:00)
Subject: Re: [APRSISCE] Mo showing incorrect altitude
That's definitely a bug that I'll have to get fixed. He's actually transmitting Mic-E encoded altitude which apparently I'm interpreting incorrectly as feet instead of meters. From aprs.fi's decoded raw packets view:
2023-02-08
11:22:15 EST: KB3ZTO-2>T1QQ4T,WIDE2-2,qAO,K3ACS-10:'kUpl <0x1c>#/"95}Scharf Solar Energy 14.1V 10C
type:
location
format:
mice
srccallsign:
KB3ZTO-2
dstcallsign:
T1QQ4T
latitude:
41.190666666667 °
longitude:
-79.964 °
course:
0 °
speed:
0 km/h
altitude:
485 m
symboltable:
/
symbolcode:
#
mbits:
101
posresolution:
18.52 m
posambiguity:
0
comment:
Scharf Solar Energy 14.1V 10C
And if you have contact with KB3ZTO, he may want to correct the other packet definition in his TT4.
2023-02-08
11:16:02 EST: KB3ZTO-2>APTT4,WIDE2-2,qAR,KC3ARY:Barkeyville Digi [Unsupported
packet format]
srccallsign:
KB3ZTO-2
dstcallsign:
APTT4
There is no "B" datatype indicator in the APRS specification. This is a popular configuration mistake for TT4 owners. They really should prefix this string with a > character to make it a spec-compliant status report. However, Chapter 19 of aprs101.pdf
provides for this as follows:
All Other Packets
Packets that do not meet any of the formats described in this document are assumed to be non-APRS beacons. Programs can decide to handle these, or ignore them, but they must be able to process them without ill effects.
APRS programs may treat such packets as APRS Status Reports. This allows APRS to accept any UI packet addressed to the typical beacon address to be captured as a status message. Typical TNC ID packets fall into this category. Once a proper Status Report (with
the APRS Data Type Identifier >) has been received from a station it will not be overwritten by other non-APRS packets from that station.
However, aprs.fi's parser labels these packets as "Unsupported" instead of interpreting them as a Status Report.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
On 2/8/2023 4:42 AM, Greg Depew wrote:
Hi Lynn, have been playing with MO lately and notice with the newest hydra that altitude shows as feet but looks like its being decoded as meters.
See screen shot. KB3ZTO-2 is a fixed digi and he has set a fixed altitude of 1591 feet asl but MO is showing 485.
KB3KBR Greg. Sent from my Samsung Galaxy smartphone.
|
|
|
We actually were discussing the BTEXT which, it turns out, does
mention the >
BTEXT [ text ]
Sets the text to be sent periodically as a separate beacon
packet, up to 50 characters.
Set period with BPERIOD. The first character should be > for
status reports. Telemetry
variables can be sent by adding the following escape codes to
the string:
^T sends the temperature in Fahrenheit
^t sends the temperature in Celsius
^V sends the incoming supply voltage
^1 sends the voltage at JP1
^2 sends the voltage at JP2
^3 sends the voltage at JP3
^4 sends the voltage at JP4
^5 sends the voltage at JP5
^6 sends the voltage at PA1 (divided supply voltage)
^7 sends the voltage at PA2 (raw temperature voltage)
^^ sends the ^ character
Note, the MT-TT4 does not have a temperature sensor.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and
Win32
On 2/9/2023 12:23 AM, Ben Miller wrote:
From the manual...
"ALTNET [ call ]
Sets the ALTNET callsign, sent as the destination callsign in
all outgoing packets,
except MIC-E position packets. An SSID should not be used. The
default of APTT4 is
restored when cleared."
Ben Miller, PE retired
KD9BBB
Yep, the status report is on his list if
tweaks next time he's up the water tower. He's built a
complete stand-alone digi that's solar powered and sits on
top of a 161 ft water tower. I believe he said if the sun
were to go out of existence he'd be able to run for 7 days
on battery. Thanks for checking the bug.
I'm not sure if the tt4 documentation says
about prefixing with the >. I found out the hard way
when experimenting with mine.
Thanks again!
KB3KBR
Greg. Sent from my Samsung Galaxy smartphone.
-------- Original message --------
Date: 2/8/23 11:37 (GMT-05:00)
Subject: Re: [APRSISCE] Mo showing incorrect altitude
That's definitely a bug that I'll have to get fixed.
He's actually transmitting Mic-E encoded altitude which
apparently I'm interpreting incorrectly as feet instead
of meters. From aprs.fi's
decoded raw packets view:
2023-02-08
11:22:15 EST: KB3ZTO-2>T1QQ4T,WIDE2-2,qAO,K3ACS-10:'kUpl <0x1c>#/"95}Scharf Solar Energy 14.1V 10C
type:
location
format:
mice
srccallsign:
KB3ZTO-2
dstcallsign:
T1QQ4T
latitude:
41.190666666667 °
longitude:
-79.964 °
course:
0 °
speed:
0 km/h
altitude:
485 m
symboltable:
/
symbolcode:
#
mbits:
101
posresolution:
18.52 m
posambiguity:
0
comment:
Scharf Solar Energy 14.1V 10C
And if you have contact with KB3ZTO, he may want to
correct the other packet definition in his TT4.
2023-02-08
11:16:02 EST: KB3ZTO-2>APTT4,WIDE2-2,qAR,KC3ARY:Barkeyville Digi [Unsupported
packet format]
srccallsign:
KB3ZTO-2
dstcallsign:
APTT4
There is no "B" datatype indicator in the APRS
specification. This is a popular configuration mistake
for TT4 owners. They really should prefix this string
with a > character to make it a spec-compliant status
report. However, Chapter 19 of aprs101.pdf provides
for this as follows:
All Other Packets
Packets that do not meet any of the formats described in
this document are assumed to be non-APRS beacons.
Programs can decide to handle these, or ignore them, but
they must be able to process them without ill effects.
APRS programs may treat such packets as APRS Status
Reports. This allows APRS to accept any UI packet
addressed to the typical beacon address to be captured
as a status message. Typical TNC ID packets fall into
this category. Once a proper Status Report (with the
APRS Data Type Identifier >) has been received from a
station it will not be overwritten by other non-APRS
packets from that station.
However, aprs.fi's parser labels
these packets as "Unsupported" instead of interpreting
them as a Status Report.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows
Mobile and Win32
On 2/8/2023 4:42 AM, Greg Depew wrote:
Hi Lynn, have been playing with MO
lately and notice with the newest hydra that altitude
shows as feet but looks like its being decoded as
meters.
See screen shot. KB3ZTO-2 is a fixed
digi and he has set a fixed altitude of 1591 feet asl
but MO is showing 485.
KB3KBR
Greg. Sent from my Samsung Galaxy smartphone.
|
|
|
Whoops, there it is. I guessed I read right over it! Thanks Lynn!
KB3KBR Greg. Sent from my Samsung Galaxy smartphone.
toggle quoted message
Show quoted text
-------- Original message --------
From: Lynn Deffenbaugh <kj4erj@...>
Date: 2/9/23 03:38 (GMT-05:00)
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Mo showing incorrect altitude
We actually were discussing the BTEXT which, it turns out, does mention the >
BTEXT [ text ]
Sets the text to be sent periodically as a separate beacon packet, up to 50 characters. Set period with BPERIOD. The first character should be > for status reports. Telemetry variables can be sent by adding the following escape codes to the string:
^T sends the temperature in Fahrenheit
^t sends the temperature in Celsius
^V sends the incoming supply voltage
^1 sends the voltage at JP1
^2 sends the voltage at JP2
^3 sends the voltage at JP3
^4 sends the voltage at JP4
^5 sends the voltage at JP5
^6 sends the voltage at PA1 (divided supply voltage)
^7 sends the voltage at PA2 (raw temperature voltage)
^^ sends the ^ character
Note, the MT-TT4 does not have a temperature sensor.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
On 2/9/2023 12:23 AM, Ben Miller wrote:
From the manual...
"ALTNET [ call ]
Sets the ALTNET callsign, sent as the destination callsign in all outgoing packets,
except MIC-E position packets. An SSID should not be used. The default of APTT4 is
restored when cleared."
Ben Miller, PE retired
KD9BBB
Yep, the status report is on his list if tweaks next time he's up the water tower. He's built a complete stand-alone digi that's solar powered and sits on top of a 161 ft water tower. I believe he said if the sun were to go out of existence
he'd be able to run for 7 days on battery. Thanks for checking the bug.
I'm not sure if the tt4 documentation says about prefixing with the >. I found out the hard way when experimenting with mine.
Thanks again!
KB3KBR Greg. Sent from my Samsung Galaxy smartphone.
-------- Original message --------
Date: 2/8/23 11:37 (GMT-05:00)
Subject: Re: [APRSISCE] Mo showing incorrect altitude
That's definitely a bug that I'll have to get fixed. He's actually transmitting Mic-E encoded altitude which apparently I'm interpreting incorrectly as feet instead of meters. From
aprs.fi's decoded raw packets view:
2023-02-08
11:22:15 EST: KB3ZTO-2>T1QQ4T,WIDE2-2,qAO,K3ACS-10:'kUpl <0x1c>#/"95}Scharf Solar Energy 14.1V 10C
type:
location
format:
mice
srccallsign:
KB3ZTO-2
dstcallsign:
T1QQ4T
latitude:
41.190666666667 °
longitude:
-79.964 °
course:
0 °
speed:
0 km/h
altitude:
485 m
symboltable:
/
symbolcode:
#
mbits:
101
posresolution:
18.52 m
posambiguity:
0
comment:
Scharf Solar Energy 14.1V 10C
And if you have contact with KB3ZTO, he may want to correct the other packet definition in his TT4.
2023-02-08
11:16:02 EST: KB3ZTO-2>APTT4,WIDE2-2,qAR,KC3ARY:Barkeyville Digi [Unsupported
packet format]
srccallsign:
KB3ZTO-2
dstcallsign:
APTT4
There is no "B" datatype indicator in the APRS specification. This is a popular configuration mistake for TT4 owners. They really should prefix this string with a > character to make it a spec-compliant status report. However, Chapter 19 of aprs101.pdf
provides for this as follows:
All Other Packets
Packets that do not meet any of the formats described in this document are assumed to be non-APRS beacons. Programs can decide to handle these, or ignore them, but they must be able to process them without ill effects.
APRS programs may treat such packets as APRS Status Reports. This allows APRS to accept any UI packet addressed to the typical beacon address to be captured as a status message. Typical TNC ID packets fall into this category. Once a proper Status Report (with
the APRS Data Type Identifier >) has been received from a station it will not be overwritten by other non-APRS packets from that station.
However, aprs.fi's parser labels these packets as "Unsupported" instead of interpreting them as a Status Report.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
On 2/8/2023 4:42 AM, Greg Depew wrote:
Hi Lynn, have been playing with MO lately and notice with the newest hydra that altitude shows as feet but looks like its being decoded as meters.
See screen shot. KB3ZTO-2 is a fixed digi and he has set a fixed altitude of 1591 feet asl but MO is showing 485.
KB3KBR Greg. Sent from my Samsung Galaxy smartphone.
|
|
|
