Re: MTT4BT Digipeater, weather station, Beacon, and Message issues....
I have made some progress...
Path1 cannot be empty (null). Just putting anything in there caused expected behavior to happen in Proportional Pathing.
Beacon Text: Beacon a message, bulletin or announcement; I had to add the ":BLNx???? :" address block. Not many characters after that are left.
Weather is still an issue. The MTT4 does not like to stay in contact with the PEET Brothers output.
Even with power cycling the weather w/ position packet doesn't like to stay connected.
2021-08-23 10:40:49 EDT: >APTT4,qAR,:!4341.89N/07109.20W_.../...g003t...r...p...P000h..b.....TU2k
If I try to send a weather w/o position, APRS.fi complains that it doesn't support the weather format.
2021-08-22 14:11:23 EDT: >APTT4,qAR,:_........c...s...g...t...r...p...P...h..b.....TU2k [Unsupported weather format]
Neither of the above have data, but only the one is 'accepted'.
The Ultimeter 100 in data logger mode feds this into the MTT4:
!!0059000702A0060B----------------00E9032F00010027
But at about 2 per second. I don't want to take down the local network. :o? But it is an acceptable packet. Didn't have time to really test it yesterday to see if the weather was being decoded by APRS.fi or local radios.
In Packet Mode the follow is outputted every five minutes:
$ULTW00B2000402A2060C----000086A00001----00E9034300020032
APRS.fi accepts this fine too.
In both cases, I put port B to TEXT mode. But it appeared that received packets were being sent to the Ultimeter and the ultimeter was in full duplex. Ergo, all received packets were being sent again as UI packets. OOPS. I see DeafText now and think that might be better for port B.
Two questions still remain; why doesn't Weather without position work and why does the TT4 not stay in communication with the PEET Data Logger Mode?
//AC1DW
|
Hey Bob,
???? It is the middle of August. Any updates????
///Paul
toggle quoted message
Show quoted text
On Tue, Mar 9, 2021 at 08:21 PM, Bob Holowenko wrote:
At this time we don't have any confirmation as we'll not be able to access the mountain top until late a July/August time frame. We know we have power to the distribution board as the repeater, controller, and link radio still have power. There's a chance we popped the fuse, but due to poor planning the MTT4B had a 10A fuse.
?
I've got internet access to a TNC on an adjacent hill about 60km away from the affected mountain top, and I am not seeing any signs of the MTT4B trying to transmit.
?
Lightning is not out of the question, but I doubt just one item would have succumbed to a nearby hit. This site is famous for melting 12inch lightning rods down to stubs.?
?
Aside from waiting four to five months, I'm not sure if there's anything else I can do.
?
Cheers!
?
|
Re: "Limited" Fill In Digipeater Configuration
...
If you set it up to be private, you are kinf of being a 'stingy HAM'. ...
OMG, LOL, is that like HAM^2 ????? /// Paul
|
MTT4BT Digipeater, weather station, Beacon, and Message issues....
Hello. The Lakes Region Repeater Assoc. in NH has an MTT4 that I am trying to get to do all the above. Attached are the current settings. The goal is / was to use proportional pathing (PPATHING is TRUE) so the weather report would go out local (no path) most of the time but still show on maps as an "L" digipeater. (Limited, no msg, no iGate). The other Posit, Beacon, Message would follow suit if I read the manual correctly. " Set to enable proportional pathing on sent packets. For each packet type (position,
beacon, telemetry, weather), every other transmission will be sent direct, with no
digipeater path requested. Every other remaining is sent with PATH1 only. Every fourth
is sent via PATH1, PATH2, and every eighth is sent via PATH1, PATH2+1. PATH2 is
assumed to be an n-N callsign, and PATH2+1 means the n and N are both
incremented. So a PATH2 of SS2-2 would be sent as SS3-3 every eighth transmission.
Note PPATHING does not apply to packet sent from received serial." My settings:
| PATH1 |
? |
| PATH2 |
WIDE2-1 |
| PATH3 |
? |
I thought from above, that transmissions would have a path of WIDE2-1 every fourth transmission, WIDE3-2 (or WIDE2-2) every eighth, and be direct all the others. If you look at the APRS.fi raw data for W1BST, this is NOT happening.
But, Hey, almost EVERY packet is getting to the APRSIS.
Weather Station Issue: We have an Ultimeter 100 (Peet Brothers) weather station connected. Set to Data Logger Mode (Station sends current data to MTT4 about twice a second.)
Since we beacon position and NEVER move the unit, I was trying to prevent the icon on APRS.fi from being a WX symbol. It appears to be hard coded that way if WXPOS is TRUE. (PPERIOD is 3599) as per the APRS Spec 1.01pg62 (i'm still learning)
If WXPOS is FALSE, the following is transmitted from the MTT4:???? 2021-08-18 14:00:43 EDT: >APTT4,qAR,:_........c...s...g...t...r...p...P...h..b.....TU2k [Unsupported weather format]
If WXPOS is TRUE, the following is transmitted from the MTT4: ???? 2021-08-18 17:34:46 EDT: >APTT4,qAR,:!4341.89N/07109.20W_.../...g...t...r...p...P...h..b.....TU2k
??? Power cycling the MTT4 then will get it to relay the weather station:???? 2021-08-18 23:39:53 EDT: >APTT4,qAR,:!4341.89N/07109.20W_266/002g002t072r001p000P001h..b.....TU2k
???? I am finding I need to power cycle every time, after I do a softrst. Just quitting cmd mode doesn't get the MTT4 and weather station talking correctly.
Beacon Issue:
I set BText originally to "HamFest 28 Aug 8a-2p see www.W1BST.ORG 4 detail"
I expected to see BEACON for destination in the packet. What was transmitted was:
???? 2021-08-18 14:00:44 EDT: >APTT4,qAR,:HamFest?28?Aug?8am-2pm?See?www.W1BST.0RG?details [Unsupported packet format]
I am assuming that is because there is no "APRS Data Type Identifier" in the data field
I tried ":", then ">". Would "{" be better?
Message Issue: (Messages, Bulletins and Announcements)
How do you send a message with the MTT4 set up as a digipeater? I guess it really is more like trying to sending Bulletins or Announcements.We would like to announce our local club HamFest coming up. I used the BTEXT & BPERIOD for this; but was hoping there is a better way.
Hope I provided enough information to be useful.
I am very new to APRS. I did find a and looked at addendums 1.1 and 1.2 on the APRS.org site. Is there a better PDF of the spec to be using?
/73 Paul
|
On serial DB-9 connectors, pins 7 & 8 are RTS and CTS, two flow control handshaking lines.? Some serial cables short these together to bypass hardware handshaking. The TT4 uses pins 7 & 8 as the secondary serial port pins.? If PORTB is set to TEXT or KISS mode, all received decoded packets will be sent out pin 7, and if they are bridged with such a cable, will come right back in pin 8 as data to be sent over the radio.??
If someone is using one of these cables, a simple fix is to set PORTB to GPS or DEAFTEXT mode.? Only waypoint data is sent out to a GPS, and seeing that return is ignored.? And nothing is sent out to a DEAFTEXT port, which is used for some weather stations.
Byon
On Mon, Aug 16, 2021 at 8:32 AM Lynn Deffenbaugh < kj4erj@...> wrote:
I understand what the "intention" was of
the default to Status Report, but software cannot read intent,
just content.? So anything that doesn't fit something else is, by
definition, a Status Report.? Even if that anything is a
fully-formed TNC2-formatted packet.
Lynn (D) - KJ4ERJ - Author of APRSISCE
for Windows Mobile and Win32
On 8/16/2021 10:20 AM, Robert Bruninga
wrote:
Yes, anything manually typed into a TNC for
transmission should?
at least be transmitted and we called that a default status
packet.
But this situation is different.? It is not someone
generating "status"
packets but some arrangement of hardware that is
incorrectly taking
the output of one?TNC stream and just transmittiing it raw
as if it
was trying to emulate a digi, which is not how digis work.
bob
On Mon, Aug 16, 2021 at 7:21
AM Lynn Deffenbaugh < kj4erj@...> wrote:
Well, we call them "bad" or "bogus" packets, but the
aprs101.pdf spec actually would classify them as "APRS
Status Reports" and as such, IGate software is completely
spec-compliant to be passing them along.? Consider the
following from page 89 of aprs101.pdf:
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.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile
and Win32
On 8/16/2021 12:15 AM, Rich Painter wrote:
Why are igates, etc passing bad packets? bad
packets should not be promulgated.
regards
rich
On Sun, Aug 15, 2021
at 3:44 PM Lynn Deffenbaugh < kj4erj@...>
wrote:
The bogus packets being gated by KB9HGI-10
spontaneously stopped about 40 minutes after
KB9HGI thought that "nothing is wrong with the
Igate".?? KB9HGI-10 is still operating, but is
gating packets normally now so apparently the
problem was identified and corrected.
Lynn (D) - KJ4ERJ - Author of APRSISCE for
Windows Mobile and Win32
PS.? For the record, here's the last bogus packets
gated and the first of the good packets that have
continued since.? Notice the 8 minute gap between
the two during which time I suspect it was
actually fixed.
WinMain:2021-08-14T04:48:21.740 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]W0CBL-1>APDW16,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:!4015.91NS09234.82W#PHG5540Kirksville, MO
WinMain:2021-08-14T04:48:27.223 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]KB9HGI-15>APTT4,WIDE2-1,qAR,KB9HGI-10:W0CBL-1>APDW16,NR9Q-1*,WIDE2-1:!4015.91NS09234.82W#PHG5540Kirksville, MO
WinMain:2021-08-14T04:50:08.801 IS[APRS-IS](Hit(e/KB9HGI-10)) [1]KB9HGI-15>APTT4,WIDE2-1,qAR,KB9HGI-10:KC9LDH-9>APAVT5,KS9A-10,CHILLI*,WIDE2:=4034.61N\09002.28WO192/012/A=000702Unit 2 K 3.82V 84.0F TF Err
WinMain:2021-08-14T04:58:06.655 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]KB0NWT>T0RX0V,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:'x&Xl -/]
WinMain:2021-08-14T05:05:38.918 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]KB9HGI-2>S9UW1R,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:`w3?l!k[/`"5i}Monitoring 146.520_(
WinMain:2021-08-14T05:08:02.156 IS[APRS-IS](Hit(e/KB9HGI-10)) [1]KB9HGI-2>S9UW1R,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:`w3?l!k[/`"5i}Monitoring 146.520_(
WinMain:2021-08-14T05:08:21.105 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]W0CBL-1>APDW16,qAR,KB9HGI-10:!4015.91NS09234.82W#PHG5540Kirksville, MO
On 8/15/2021 5:21 PM, Robert Bruninga wrote:
The packets look like someone just
hooked the output of one TNC to theTX input of
another one
instead of actually implementing an IGate
or digi.? So the one TNC is trnansmitting?the
parsed and "displayed" packet as received
from another.? Once received, the format
is a "display" format and not part of the
on-air AX.25 protocol.
Bob, WB4APR
On Sat, Aug
14, 2021 at 12:11 AM KB9HGI < kb9hgi@...>
wrote:
No I don¡¯t think
nothing is wrong with the Igate I have
had it on for years its in rx only mode
and its been working fine. A buddy of
mine AA9GL has been running a digi. But
was wanting to shut it off. He never had
that problem his fixed station moving to
different locations. I need to hook the
TT4 back up computer again and try some
different setting either its config
wrong or it¡¯s a piece of junk!
?
Steve KB9HGI
?
Sent from
for Windows
?
?
AND bad packets
are NOT supposed to be passed on!
They are supposed to be discarded.
?
On Fri, Aug 13,
2021 at 2:36 PM Lynn Deffenbaugh
<kj4erj@...>
wrote:
They are
completely invalid packets.?? If
a 3rd party packet is received,
it is supposed to be unwrapped
before being gated.
Something is
broken with this IGate.
Lynn (D) -
KJ4ERJ - Author of APRSISCE for
Windows Mobile and Win32
PS.? From
Third Party Packets
Please refer to the chapter
in the APRS specification on
third-party packets. At this
time, all IGates strip any
path information out of the
third-party header to reduce
bandwidth requirements and
maintain AX.25 packet length
compatibility.
- ?An
IGate should not gate
third-party packets (data
type }) with TCPIP or TCPXX
in the third-party header to
APRS-IS.
- Third-party
packets without TCPIP in the
header are to be gated to
APRS-IS?AFTER?stripping
the RF header and
third-party data type.
?
On 8/13/2021
3:24 PM, Robert Bruninga wrote:
I'm
probably in a chemo fog, but
most of the packets
-originated- by
the
callsign KB9HGI-15 appear
(raw as listed on )
to be
other people's packets in
its payload field..?
Shouldnt?these
be
identified as 3rd-party in
someway since they don't
match?
the
APRS?protocol with a
first-characer?identifier?
Or does
the?3rd party flag only
apply if the?packet is
re-transmitted
back to
RF as in a message packet.
I'm
embarrassed?that I am now
forgetting more about APRS
details
?
On Fri,
Aug 13, 2021 at 12:15 PM
KB9HGI <kb9hgi@...>
wrote:
Here
is my tiny tracker
KB9HGI-15 which is in
a fixed location but
is moving all over the
place.
?
Sent
from
for Windows
?
?
Which
SSID is your
digipeater on?
KB9HGI-15? I see
you've used a lot of
SSIDs:
This is where I see
what I expect to be
your TT4, along with
some other SSIDs:
And you're currently
underway:
Everything checks out
at the moment, right?
?
--
Richard
A. Painter, P.E.
Retired
--
Richard A. Painter, P.E. Retired
|
I understand what the "intention" was of
the default to Status Report, but software cannot read intent,
just content.? So anything that doesn't fit something else is, by
definition, a Status Report.? Even if that anything is a
fully-formed TNC2-formatted packet.
Lynn (D) - KJ4ERJ - Author of APRSISCE
for Windows Mobile and Win32
On 8/16/2021 10:20 AM, Robert Bruninga
wrote:
toggle quoted message
Show quoted text
Yes, anything manually typed into a TNC for
transmission should?
at least be transmitted and we called that a default status
packet.
But this situation is different.? It is not someone
generating "status"
packets but some arrangement of hardware that is
incorrectly taking
the output of one?TNC stream and just transmittiing it raw
as if it
was trying to emulate a digi, which is not how digis work.
bob
On Mon, Aug 16, 2021 at 7:21
AM Lynn Deffenbaugh < kj4erj@...> wrote:
Well, we call them "bad" or "bogus" packets, but the
aprs101.pdf spec actually would classify them as "APRS
Status Reports" and as such, IGate software is completely
spec-compliant to be passing them along.? Consider the
following from page 89 of aprs101.pdf:
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.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile
and Win32
On 8/16/2021 12:15 AM, Rich Painter wrote:
Why are igates, etc passing bad packets? bad
packets should not be promulgated.
regards
rich
On Sun, Aug 15, 2021
at 3:44 PM Lynn Deffenbaugh < kj4erj@...>
wrote:
The bogus packets being gated by KB9HGI-10
spontaneously stopped about 40 minutes after
KB9HGI thought that "nothing is wrong with the
Igate".?? KB9HGI-10 is still operating, but is
gating packets normally now so apparently the
problem was identified and corrected.
Lynn (D) - KJ4ERJ - Author of APRSISCE for
Windows Mobile and Win32
PS.? For the record, here's the last bogus packets
gated and the first of the good packets that have
continued since.? Notice the 8 minute gap between
the two during which time I suspect it was
actually fixed.
WinMain:2021-08-14T04:48:21.740 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]W0CBL-1>APDW16,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:!4015.91NS09234.82W#PHG5540Kirksville, MO
WinMain:2021-08-14T04:48:27.223 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]KB9HGI-15>APTT4,WIDE2-1,qAR,KB9HGI-10:W0CBL-1>APDW16,NR9Q-1*,WIDE2-1:!4015.91NS09234.82W#PHG5540Kirksville, MO
WinMain:2021-08-14T04:50:08.801 IS[APRS-IS](Hit(e/KB9HGI-10)) [1]KB9HGI-15>APTT4,WIDE2-1,qAR,KB9HGI-10:KC9LDH-9>APAVT5,KS9A-10,CHILLI*,WIDE2:=4034.61N\09002.28WO192/012/A=000702Unit 2 K 3.82V 84.0F TF Err
WinMain:2021-08-14T04:58:06.655 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]KB0NWT>T0RX0V,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:'x&Xl -/]
WinMain:2021-08-14T05:05:38.918 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]KB9HGI-2>S9UW1R,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:`w3?l!k[/`"5i}Monitoring 146.520_(
WinMain:2021-08-14T05:08:02.156 IS[APRS-IS](Hit(e/KB9HGI-10)) [1]KB9HGI-2>S9UW1R,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:`w3?l!k[/`"5i}Monitoring 146.520_(
WinMain:2021-08-14T05:08:21.105 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]W0CBL-1>APDW16,qAR,KB9HGI-10:!4015.91NS09234.82W#PHG5540Kirksville, MO
On 8/15/2021 5:21 PM, Robert Bruninga wrote:
The packets look like someone just
hooked the output of one TNC to theTX input of
another one
instead of actually implementing an IGate
or digi.? So the one TNC is trnansmitting?the
parsed and "displayed" packet as received
from another.? Once received, the format
is a "display" format and not part of the
on-air AX.25 protocol.
Bob, WB4APR
On Sat, Aug
14, 2021 at 12:11 AM KB9HGI < kb9hgi@...>
wrote:
No I don¡¯t think
nothing is wrong with the Igate I have
had it on for years its in rx only mode
and its been working fine. A buddy of
mine AA9GL has been running a digi. But
was wanting to shut it off. He never had
that problem his fixed station moving to
different locations. I need to hook the
TT4 back up computer again and try some
different setting either its config
wrong or it¡¯s a piece of junk!
?
Steve KB9HGI
?
Sent from
for Windows
?
?
AND bad packets
are NOT supposed to be passed on!
They are supposed to be discarded.
?
On Fri, Aug 13,
2021 at 2:36 PM Lynn Deffenbaugh
<kj4erj@...>
wrote:
They are
completely invalid packets.?? If
a 3rd party packet is received,
it is supposed to be unwrapped
before being gated.
Something is
broken with this IGate.
Lynn (D) -
KJ4ERJ - Author of APRSISCE for
Windows Mobile and Win32
PS.? From
Third Party Packets
Please refer to the chapter
in the APRS specification on
third-party packets. At this
time, all IGates strip any
path information out of the
third-party header to reduce
bandwidth requirements and
maintain AX.25 packet length
compatibility.
- ?An
IGate should not gate
third-party packets (data
type }) with TCPIP or TCPXX
in the third-party header to
APRS-IS.
- Third-party
packets without TCPIP in the
header are to be gated to
APRS-IS?AFTER?stripping
the RF header and
third-party data type.
?
On 8/13/2021
3:24 PM, Robert Bruninga wrote:
I'm
probably in a chemo fog, but
most of the packets
-originated- by
the
callsign KB9HGI-15 appear
(raw as listed on )
to be
other people's packets in
its payload field..?
Shouldnt?these
be
identified as 3rd-party in
someway since they don't
match?
the
APRS?protocol with a
first-characer?identifier?
Or does
the?3rd party flag only
apply if the?packet is
re-transmitted
back to
RF as in a message packet.
I'm
embarrassed?that I am now
forgetting more about APRS
details
?
On Fri,
Aug 13, 2021 at 12:15 PM
KB9HGI <kb9hgi@...>
wrote:
Here
is my tiny tracker
KB9HGI-15 which is in
a fixed location but
is moving all over the
place.
?
Sent
from
for Windows
?
?
Which
SSID is your
digipeater on?
KB9HGI-15? I see
you've used a lot of
SSIDs:
This is where I see
what I expect to be
your TT4, along with
some other SSIDs:
And you're currently
underway:
Everything checks out
at the moment, right?
?
--
Richard
A. Painter, P.E.
Retired
--
Richard A. Painter, P.E. Retired
|
Re: TT4 with Peet Ultimiter Troubleshooting
The TT4 can be set to 5V TTL interface with jumpers.? If you didn't change the jumpers, then the TT4 is using RS232 level logic and will cause serious problems with the Pi.
Some people have used a single resistor between the TT4 (TX) and Pi (RX) pins to protect it.? I prefer? 2 resistor voltage divider which can usually fit in a DE9 backshell.??
As stated below, the format is very specific.? It probably requires zeros for any non-reported value as well.
On Mon, Aug 16, 2021 at 2:15, Gil Smith <tinytrak@...> wrote: Hi John:
I can't answer your question on TT4 integration as I have not tried that, but I have also dabbled with a home-brew wx station, and fought my share of integration battles.? Regarding your serial connection between the pi and tt4, I would first ensure that the signal levels are compatible.? The pi port is 3.3V iirc, and the tt4 runs on 5V -- though a 3.3v cmos signal from the pi into 5v tt4 input should work fine (with ttl thresholds).? I am not sure if the pi has 5V-tolerant inputs, and would not connect the other direction without confirming that, using a level translator, or at least a series resistor in the line.? Maybe you are using a usb-to-serial adapter on the pi and not the gpio pins, so different situation then.? Do you have a scope to check the data stream?? Serial problems can be levels, inverted data, swapped rx/tx, wrong baud...? Are you sending properly-formatted data to the tt4 sec port?
FWIW, I have also used a pi for wx station use, but for sending to the internet only.? If you go back and find a post of mine from Apr 3 I posted python pi code that formatted data for aprs-is (and a few others).? The aprs formatting is a bit finicky and does not like extra digits in a field and such.? I believe the formatting for radio transmission is much the same as aprs-is.? I have also used bme280 sensors -- I compared multiple units and I found temp to be pretty consistent, pressure to be dead-nuts, but humidity was all over the place.? There is a "conditioning" process for humidity sensors, but I did not get that fancy.?
----- Original message -----
Subject: [TinyTrak] TT4 with Peet Ultimiter Troubleshooting
Date: Sunday, August 15, 2021 8:30 PM
Hello to the group,
I am in need of troubleshooting assistance with a Peet Ultimiter compatible home brew weather station that I have connected to my TT4.
This is what I have so far:
The TT4 is connected to a Motorola Radius M130 control station, and receives and transmits within specifications, as calibrated against my service monitor.
I wrote code in Java for a Weather Station that runs on a Raspberry Pi 4 which has a 7" display, as well as code to display the output of a Bosch I2C BME280 temperature/pressure/humidity sensor (which I reverse engineered from the Adafruit Python driver).
I also wrote code to generate the Peet $ULTW 52 character sentence from the weather station. I do not have any other sensors yet. Just the temp/humidity/pressure.
All of that works fine, so I fabricated a "Y" adapter to feed the RPi weather station to the secondary port on the TT4.
The problem is that the TT4 sends the data into the network, but all the fields are blank.
I am trying to figure out if the problem is in my code, or in the settings in the TT4.
Is there anyone who has a working Peet Ultimiter connected to a TT4 who can post a copy of their TT4 SETTINGS display dump?
That way I can rule out the configuration of the TT4.
Thanks in advance for your assistance,
John N1CTF
|
Yes, anything manually typed into a TNC for transmission should? at least be transmitted and we called that a default status packet. But this situation is different.? It is not someone generating "status" packets but some arrangement of hardware that is incorrectly taking the output of one?TNC stream and just transmittiing it raw as if it was trying to emulate a digi, which is not how digis work.
bob
On Mon, Aug 16, 2021 at 7:21 AM Lynn Deffenbaugh < kj4erj@...> wrote:
Well, we call them "bad" or "bogus"
packets, but the aprs101.pdf spec actually would classify them as
"APRS Status Reports" and as such, IGate software is completely
spec-compliant to be passing them along.? Consider the following
from page 89 of aprs101.pdf:
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.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and
Win32
On 8/16/2021 12:15 AM, Rich Painter
wrote:
Why are igates, etc passing bad packets? bad packets should
not be promulgated.
regards
rich
On Sun, Aug 15, 2021 at 3:44
PM Lynn Deffenbaugh < kj4erj@...> wrote:
The bogus packets being gated by KB9HGI-10
spontaneously stopped about 40 minutes after KB9HGI
thought that "nothing is wrong with the Igate".??
KB9HGI-10 is still operating, but is gating packets
normally now so apparently the problem was identified and
corrected.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows
Mobile and Win32
PS.? For the record, here's the last bogus packets gated
and the first of the good packets that have continued
since.? Notice the 8 minute gap between the two during
which time I suspect it was actually fixed.
WinMain:2021-08-14T04:48:21.740 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]W0CBL-1>APDW16,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:!4015.91NS09234.82W#PHG5540Kirksville, MO
WinMain:2021-08-14T04:48:27.223 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]KB9HGI-15>APTT4,WIDE2-1,qAR,KB9HGI-10:W0CBL-1>APDW16,NR9Q-1*,WIDE2-1:!4015.91NS09234.82W#PHG5540Kirksville, MO
WinMain:2021-08-14T04:50:08.801 IS[APRS-IS](Hit(e/KB9HGI-10)) [1]KB9HGI-15>APTT4,WIDE2-1,qAR,KB9HGI-10:KC9LDH-9>APAVT5,KS9A-10,CHILLI*,WIDE2:=4034.61N\09002.28WO192/012/A=000702Unit 2 K 3.82V 84.0F TF Err
WinMain:2021-08-14T04:58:06.655 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]KB0NWT>T0RX0V,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:'x&Xl -/]
WinMain:2021-08-14T05:05:38.918 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]KB9HGI-2>S9UW1R,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:`w3?l!k[/`"5i}Monitoring 146.520_(
WinMain:2021-08-14T05:08:02.156 IS[APRS-IS](Hit(e/KB9HGI-10)) [1]KB9HGI-2>S9UW1R,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:`w3?l!k[/`"5i}Monitoring 146.520_(
WinMain:2021-08-14T05:08:21.105 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]W0CBL-1>APDW16,qAR,KB9HGI-10:!4015.91NS09234.82W#PHG5540Kirksville, MO
On 8/15/2021 5:21 PM, Robert Bruninga wrote:
The packets look like someone just hooked
the output of one TNC to theTX input of another one
instead of actually implementing an IGate or digi.?
So the one TNC is trnansmitting?the
parsed and "displayed" packet as received from
another.? Once received, the format
is a "display" format and not part of the on-air
AX.25 protocol.
Bob, WB4APR
On Sat, Aug 14, 2021
at 12:11 AM KB9HGI < kb9hgi@...>
wrote:
No I don¡¯t think nothing is
wrong with the Igate I have had it on for years
its in rx only mode and its been working fine. A
buddy of mine AA9GL has been running a digi. But
was wanting to shut it off. He never had that
problem his fixed station moving to different
locations. I need to hook the TT4 back up
computer again and try some different setting
either its config wrong or it¡¯s a piece of junk!
?
Steve KB9HGI
?
Sent from
for Windows
?
?
AND bad packets are NOT
supposed to be passed on! They are supposed
to be discarded.
?
On Fri, Aug 13, 2021 at
2:36 PM Lynn Deffenbaugh <kj4erj@...>
wrote:
They are completely
invalid packets.?? If a 3rd party packet
is received, it is supposed to be
unwrapped before being gated.
Something is broken
with this IGate.
Lynn (D) - KJ4ERJ -
Author of APRSISCE for Windows Mobile
and Win32
PS.? From
Third Party Packets
Please refer to the chapter in the
APRS specification on third-party
packets. At this time, all IGates
strip any path information out of the
third-party header to reduce bandwidth
requirements and maintain AX.25 packet
length compatibility.
- ?An IGate should
not gate third-party packets (data
type }) with TCPIP or TCPXX in the
third-party header to APRS-IS.
- Third-party
packets without TCPIP in the header
are to be gated to APRS-IS?AFTER?stripping
the RF header and third-party data
type.
?
On 8/13/2021 3:24 PM,
Robert Bruninga wrote:
I'm probably in a
chemo fog, but most of the packets
-originated- by
the callsign
KB9HGI-15 appear (raw as listed on
)
to be other
people's packets in its payload
field..? Shouldnt?these
be identified
as 3rd-party in someway since they
don't match?
the
APRS?protocol with a
first-characer?identifier?
Or does the?3rd
party flag only apply if
the?packet is re-transmitted
back to RF as
in a message packet.
I'm
embarrassed?that I am now
forgetting more about APRS details
?
On Fri, Aug 13,
2021 at 12:15 PM KB9HGI <kb9hgi@...>
wrote:
Here is my
tiny tracker KB9HGI-15 which
is in a fixed location but is
moving all over the place.
?
Sent from
for Windows
?
?
Which SSID
is your digipeater on?
KB9HGI-15? I see you've used a
lot of SSIDs:
This is where I see what I
expect to be your TT4, along
with some other SSIDs:
And you're currently underway:
Everything checks out at the
moment, right?
?
--
Richard
A. Painter, P.E. Retired
--
Richard A. Painter, P.E. Retired
|
Well, we call them "bad" or "bogus"
packets, but the aprs101.pdf spec actually would classify them as
"APRS Status Reports" and as such, IGate software is completely
spec-compliant to be passing them along.? Consider the following
from page 89 of aprs101.pdf:
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.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and
Win32
On 8/16/2021 12:15 AM, Rich Painter
wrote:
Why are igates, etc passing bad packets? bad packets should
not be promulgated.
regards
rich
On Sun, Aug 15, 2021 at 3:44
PM Lynn Deffenbaugh < kj4erj@...> wrote:
The bogus packets being gated by KB9HGI-10
spontaneously stopped about 40 minutes after KB9HGI
thought that "nothing is wrong with the Igate".??
KB9HGI-10 is still operating, but is gating packets
normally now so apparently the problem was identified and
corrected.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows
Mobile and Win32
PS.? For the record, here's the last bogus packets gated
and the first of the good packets that have continued
since.? Notice the 8 minute gap between the two during
which time I suspect it was actually fixed.
WinMain:2021-08-14T04:48:21.740 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]W0CBL-1>APDW16,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:!4015.91NS09234.82W#PHG5540Kirksville, MO
WinMain:2021-08-14T04:48:27.223 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]KB9HGI-15>APTT4,WIDE2-1,qAR,KB9HGI-10:W0CBL-1>APDW16,NR9Q-1*,WIDE2-1:!4015.91NS09234.82W#PHG5540Kirksville, MO
WinMain:2021-08-14T04:50:08.801 IS[APRS-IS](Hit(e/KB9HGI-10)) [1]KB9HGI-15>APTT4,WIDE2-1,qAR,KB9HGI-10:KC9LDH-9>APAVT5,KS9A-10,CHILLI*,WIDE2:=4034.61N\09002.28WO192/012/A=000702Unit 2 K 3.82V 84.0F TF Err
WinMain:2021-08-14T04:58:06.655 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]KB0NWT>T0RX0V,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:'x&Xl -/]
WinMain:2021-08-14T05:05:38.918 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]KB9HGI-2>S9UW1R,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:`w3?l!k[/`"5i}Monitoring 146.520_(
WinMain:2021-08-14T05:08:02.156 IS[APRS-IS](Hit(e/KB9HGI-10)) [1]KB9HGI-2>S9UW1R,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:`w3?l!k[/`"5i}Monitoring 146.520_(
WinMain:2021-08-14T05:08:21.105 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]W0CBL-1>APDW16,qAR,KB9HGI-10:!4015.91NS09234.82W#PHG5540Kirksville, MO
On 8/15/2021 5:21 PM, Robert Bruninga wrote:
The packets look like someone just hooked
the output of one TNC to theTX input of another one
instead of actually implementing an IGate or digi.?
So the one TNC is trnansmitting?the
parsed and "displayed" packet as received from
another.? Once received, the format
is a "display" format and not part of the on-air
AX.25 protocol.
Bob, WB4APR
On Sat, Aug 14, 2021
at 12:11 AM KB9HGI < kb9hgi@...>
wrote:
No I don¡¯t think nothing is
wrong with the Igate I have had it on for years
its in rx only mode and its been working fine. A
buddy of mine AA9GL has been running a digi. But
was wanting to shut it off. He never had that
problem his fixed station moving to different
locations. I need to hook the TT4 back up
computer again and try some different setting
either its config wrong or it¡¯s a piece of junk!
?
Steve KB9HGI
?
Sent from
for Windows
?
?
AND bad packets are NOT
supposed to be passed on! They are supposed
to be discarded.
?
On Fri, Aug 13, 2021 at
2:36 PM Lynn Deffenbaugh <kj4erj@...>
wrote:
They are completely
invalid packets.?? If a 3rd party packet
is received, it is supposed to be
unwrapped before being gated.
Something is broken
with this IGate.
Lynn (D) - KJ4ERJ -
Author of APRSISCE for Windows Mobile
and Win32
PS.? From
Third Party Packets
Please refer to the chapter in the
APRS specification on third-party
packets. At this time, all IGates
strip any path information out of the
third-party header to reduce bandwidth
requirements and maintain AX.25 packet
length compatibility.
- ?An IGate should
not gate third-party packets (data
type }) with TCPIP or TCPXX in the
third-party header to APRS-IS.
- Third-party
packets without TCPIP in the header
are to be gated to APRS-IS?AFTER?stripping
the RF header and third-party data
type.
?
On 8/13/2021 3:24 PM,
Robert Bruninga wrote:
I'm probably in a
chemo fog, but most of the packets
-originated- by
the callsign
KB9HGI-15 appear (raw as listed on
)
to be other
people's packets in its payload
field..? Shouldnt?these
be identified
as 3rd-party in someway since they
don't match?
the
APRS?protocol with a
first-characer?identifier?
Or does the?3rd
party flag only apply if
the?packet is re-transmitted
back to RF as
in a message packet.
I'm
embarrassed?that I am now
forgetting more about APRS details
?
On Fri, Aug 13,
2021 at 12:15 PM KB9HGI <kb9hgi@...>
wrote:
Here is my
tiny tracker KB9HGI-15 which
is in a fixed location but is
moving all over the place.
?
Sent from
for Windows
?
?
Which SSID
is your digipeater on?
KB9HGI-15? I see you've used a
lot of SSIDs:
This is where I see what I
expect to be your TT4, along
with some other SSIDs:
And you're currently underway:
Everything checks out at the
moment, right?
?
--
Richard
A. Painter, P.E. Retired
--
Richard A. Painter, P.E. Retired
|
Re: TT4 with Peet Ultimiter Troubleshooting
Hi John:
I can't answer your question on TT4 integration as I have not tried that, but I have also dabbled with a home-brew wx station, and fought my share of integration battles.? Regarding your serial connection between the pi and tt4, I would first ensure that the signal levels are compatible.? The pi port is 3.3V iirc, and the tt4 runs on 5V -- though a 3.3v cmos signal from the pi into 5v tt4 input should work fine (with ttl thresholds).? I am not sure if the pi has 5V-tolerant inputs, and would not connect the other direction without confirming that, using a level translator, or at least a series resistor in the line.? Maybe you are using a usb-to-serial adapter on the pi and not the gpio pins, so different situation then.? Do you have a scope to check the data stream?? Serial problems can be levels, inverted data, swapped rx/tx, wrong baud...? Are you sending properly-formatted data to the tt4 sec port?
FWIW, I have also used a pi for wx station use, but for sending to the internet only.? If you go back and find a post of mine from Apr 3 I posted python pi code that formatted data for aprs-is (and a few others).? The aprs formatting is a bit finicky and does not like extra digits in a field and such.? I believe the formatting for radio transmission is much the same as aprs-is.? I have also used bme280 sensors -- I compared multiple units and I found temp to be pretty consistent, pressure to be dead-nuts, but humidity was all over the place.? There is a "conditioning" process for humidity sensors, but I did not get that fancy.?
----- Original message -----
Subject: [TinyTrak] TT4 with Peet Ultimiter Troubleshooting
Date: Sunday, August 15, 2021 8:30 PM
Hello to the group,
I am in need of troubleshooting assistance with a Peet Ultimiter compatible home brew weather station that I have connected to my TT4.
This is what I have so far:
The TT4 is connected to a Motorola Radius M130 control station, and receives and transmits within specifications, as calibrated against my service monitor.
I wrote code in Java for a Weather Station that runs on a Raspberry Pi 4 which has a 7" display, as well as code to display the output of a Bosch I2C BME280 temperature/pressure/humidity sensor (which I reverse engineered from the Adafruit Python driver).
I also wrote code to generate the Peet $ULTW 52 character sentence from the weather station. I do not have any other sensors yet. Just the temp/humidity/pressure.
All of that works fine, so I fabricated a "Y" adapter to feed the RPi weather station to the secondary port on the TT4.
The problem is that the TT4 sends the data into the network, but all the fields are blank.
I am trying to figure out if the problem is in my code, or in the settings in the TT4.
Is there anyone who has a working Peet Ultimiter connected to a TT4 who can post a copy of their TT4 SETTINGS display dump?
That way I can rule out the configuration of the TT4.
Thanks in advance for your assistance,
John N1CTF
|
Insure that you do not have spaces in the hard coded latitude value.
This will enable position ambiguity per the APRS spec.
APRS.fi also supports optional position ambiguity.
|
TT4 with Peet Ultimiter Troubleshooting
Hello to the group,
I am in need of troubleshooting assistance with a Peet Ultimiter compatible home brew weather station that I have connected to my TT4.
This is what I have so far:
The TT4 is connected to a Motorola Radius M130 control station, and receives and transmits within specifications, as calibrated against my service monitor.
I wrote code in Java for a Weather Station that runs on a Raspberry Pi 4 which has a 7" display, as well as code to display the output of a Bosch I2C BME280 temperature/pressure/humidity sensor (which I reverse engineered from the Adafruit Python driver).
I also wrote code to generate the Peet $ULTW 52 character sentence from the weather station. I do not have any other sensors yet. Just the temp/humidity/pressure.
All of that works fine, so I fabricated a "Y" adapter to feed the RPi weather station to the secondary port on the TT4.
The problem is that the TT4 sends the data into the network, but all the fields are blank.
I am trying to figure out if the problem is in my code, or in the settings in the TT4.
Is there anyone who has a working Peet Ultimiter connected to a TT4 who can post a copy of their TT4 SETTINGS display dump?
That way I can rule out the configuration of the TT4.
Thanks in advance for your assistance,
John N1CTF
|
Why are igates, etc passing bad packets? bad packets should not be promulgated. regards rich
On Sun, Aug 15, 2021 at 3:44 PM Lynn Deffenbaugh < kj4erj@...> wrote:
The bogus packets being gated by
KB9HGI-10 spontaneously stopped about 40 minutes after KB9HGI
thought that "nothing is wrong with the Igate".?? KB9HGI-10 is
still operating, but is gating packets normally now so apparently
the problem was identified and corrected.
Lynn (D) - KJ4ERJ - Author of APRSISCE
for Windows Mobile and Win32
PS.? For the record, here's the last bogus packets gated and the
first of the good packets that have continued since.? Notice the 8
minute gap between the two during which time I suspect it was
actually fixed.
WinMain:2021-08-14T04:48:21.740 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]W0CBL-1>APDW16,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:!4015.91NS09234.82W#PHG5540Kirksville, MO
WinMain:2021-08-14T04:48:27.223 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]KB9HGI-15>APTT4,WIDE2-1,qAR,KB9HGI-10:W0CBL-1>APDW16,NR9Q-1*,WIDE2-1:!4015.91NS09234.82W#PHG5540Kirksville, MO
WinMain:2021-08-14T04:50:08.801 IS[APRS-IS](Hit(e/KB9HGI-10)) [1]KB9HGI-15>APTT4,WIDE2-1,qAR,KB9HGI-10:KC9LDH-9>APAVT5,KS9A-10,CHILLI*,WIDE2:=4034.61N\09002.28WO192/012/A=000702Unit 2 K 3.82V 84.0F TF Err
WinMain:2021-08-14T04:58:06.655 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]KB0NWT>T0RX0V,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:'x&Xl -/]
WinMain:2021-08-14T05:05:38.918 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]KB9HGI-2>S9UW1R,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:`w3?l!k[/`"5i}Monitoring 146.520_(
WinMain:2021-08-14T05:08:02.156 IS[APRS-IS](Hit(e/KB9HGI-10)) [1]KB9HGI-2>S9UW1R,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:`w3?l!k[/`"5i}Monitoring 146.520_(
WinMain:2021-08-14T05:08:21.105 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]W0CBL-1>APDW16,qAR,KB9HGI-10:!4015.91NS09234.82W#PHG5540Kirksville, MO
On 8/15/2021 5:21 PM, Robert Bruninga
wrote:
The packets look like someone just hooked the
output of one TNC to theTX input of another one
instead of actually implementing an IGate or digi.? So the
one TNC is trnansmitting?the
parsed and "displayed" packet as received from another.?
Once received, the format
is a "display" format and not part of the on-air AX.25
protocol.
Bob, WB4APR
On Sat, Aug 14, 2021 at 12:11
AM KB9HGI < kb9hgi@...> wrote:
No I don¡¯t think nothing is wrong
with the Igate I have had it on for years its in rx only
mode and its been working fine. A buddy of mine AA9GL
has been running a digi. But was wanting to shut it off.
He never had that problem his fixed station moving to
different locations. I need to hook the TT4 back up
computer again and try some different setting either its
config wrong or it¡¯s a piece of junk!
?
Steve KB9HGI
?
Sent from for
Windows
?
?
AND bad packets are NOT supposed
to be passed on! They are supposed to be discarded.
?
On Fri, Aug 13, 2021 at 2:36 PM
Lynn Deffenbaugh <kj4erj@...>
wrote:
They are completely invalid
packets.?? If a 3rd party packet is received, it
is supposed to be unwrapped before being gated.
Something is broken with this
IGate.
Lynn (D) - KJ4ERJ - Author of
APRSISCE for Windows Mobile and Win32
PS.? From
Third Party Packets
Please refer to the chapter in the APRS
specification on third-party packets. At this
time, all IGates strip any path information
out of the third-party header to reduce
bandwidth requirements and maintain AX.25
packet length compatibility.
- ?An IGate should not
gate third-party packets (data type }) with
TCPIP or TCPXX in the third-party header to
APRS-IS.
- Third-party packets
without TCPIP in the header are to be gated
to APRS-IS?AFTER?stripping the RF
header and third-party data type.
?
On 8/13/2021 3:24 PM, Robert
Bruninga wrote:
I'm probably in a chemo
fog, but most of the packets -originated- by
the callsign KB9HGI-15
appear (raw as listed on )
to be other people's
packets in its payload field..?
Shouldnt?these
be identified as
3rd-party in someway since they don't
match?
the APRS?protocol with
a first-characer?identifier?
Or does the?3rd party
flag only apply if the?packet is
re-transmitted
back to RF as in a
message packet.
I'm embarrassed?that I
am now forgetting more about APRS details
?
On Fri, Aug 13, 2021 at
12:15 PM KB9HGI <kb9hgi@...>
wrote:
Here is my tiny
tracker KB9HGI-15 which is in a fixed
location but is moving all over the
place.
?
Sent from for
Windows
?
?
Which SSID is your
digipeater on? KB9HGI-15? I see you've
used a lot of SSIDs:
This is where I see what I expect to
be your TT4, along with some other
SSIDs:
And you're currently underway:
Everything checks out at the moment,
right?
?
--
Richard A.
Painter, P.E. Retired
-- Richard A. Painter, P.E. Retired
|
The bogus packets being gated by
KB9HGI-10 spontaneously stopped about 40 minutes after KB9HGI
thought that "nothing is wrong with the Igate".?? KB9HGI-10 is
still operating, but is gating packets normally now so apparently
the problem was identified and corrected.
Lynn (D) - KJ4ERJ - Author of APRSISCE
for Windows Mobile and Win32
PS.? For the record, here's the last bogus packets gated and the
first of the good packets that have continued since.? Notice the 8
minute gap between the two during which time I suspect it was
actually fixed.
WinMain:2021-08-14T04:48:21.740 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]W0CBL-1>APDW16,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:!4015.91NS09234.82W#PHG5540Kirksville, MO
WinMain:2021-08-14T04:48:27.223 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]KB9HGI-15>APTT4,WIDE2-1,qAR,KB9HGI-10:W0CBL-1>APDW16,NR9Q-1*,WIDE2-1:!4015.91NS09234.82W#PHG5540Kirksville, MO
WinMain:2021-08-14T04:50:08.801 IS[APRS-IS](Hit(e/KB9HGI-10)) [1]KB9HGI-15>APTT4,WIDE2-1,qAR,KB9HGI-10:KC9LDH-9>APAVT5,KS9A-10,CHILLI*,WIDE2:=4034.61N\09002.28WO192/012/A=000702Unit 2 K 3.82V 84.0F TF Err
WinMain:2021-08-14T04:58:06.655 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]KB0NWT>T0RX0V,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:'x&Xl -/]
WinMain:2021-08-14T05:05:38.918 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]KB9HGI-2>S9UW1R,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:`w3?l!k[/`"5i}Monitoring 146.520_(
WinMain:2021-08-14T05:08:02.156 IS[APRS-IS](Hit(e/KB9HGI-10)) [1]KB9HGI-2>S9UW1R,WIDE1-1,WIDE2-1,qAR,KB9HGI-10:`w3?l!k[/`"5i}Monitoring 146.520_(
WinMain:2021-08-14T05:08:21.105 IS[APRS-IS](Hit(e/KB9HGI-10)) [0]W0CBL-1>APDW16,qAR,KB9HGI-10:!4015.91NS09234.82W#PHG5540Kirksville, MO
On 8/15/2021 5:21 PM, Robert Bruninga
wrote:
toggle quoted message
Show quoted text
The packets look like someone just hooked the
output of one TNC to theTX input of another one
instead of actually implementing an IGate or digi.? So the
one TNC is trnansmitting?the
parsed and "displayed" packet as received from another.?
Once received, the format
is a "display" format and not part of the on-air AX.25
protocol.
Bob, WB4APR
On Sat, Aug 14, 2021 at 12:11
AM KB9HGI < kb9hgi@...> wrote:
No I don¡¯t think nothing is wrong
with the Igate I have had it on for years its in rx only
mode and its been working fine. A buddy of mine AA9GL
has been running a digi. But was wanting to shut it off.
He never had that problem his fixed station moving to
different locations. I need to hook the TT4 back up
computer again and try some different setting either its
config wrong or it¡¯s a piece of junk!
?
Steve KB9HGI
?
Sent from for
Windows
?
?
AND bad packets are NOT supposed
to be passed on! They are supposed to be discarded.
?
On Fri, Aug 13, 2021 at 2:36 PM
Lynn Deffenbaugh <kj4erj@...>
wrote:
They are completely invalid
packets.?? If a 3rd party packet is received, it
is supposed to be unwrapped before being gated.
Something is broken with this
IGate.
Lynn (D) - KJ4ERJ - Author of
APRSISCE for Windows Mobile and Win32
PS.? From
Third Party Packets
Please refer to the chapter in the APRS
specification on third-party packets. At this
time, all IGates strip any path information
out of the third-party header to reduce
bandwidth requirements and maintain AX.25
packet length compatibility.
- ?An IGate should not
gate third-party packets (data type }) with
TCPIP or TCPXX in the third-party header to
APRS-IS.
- Third-party packets
without TCPIP in the header are to be gated
to APRS-IS?AFTER?stripping the RF
header and third-party data type.
?
On 8/13/2021 3:24 PM, Robert
Bruninga wrote:
I'm probably in a chemo
fog, but most of the packets -originated- by
the callsign KB9HGI-15
appear (raw as listed on )
to be other people's
packets in its payload field..?
Shouldnt?these
be identified as
3rd-party in someway since they don't
match?
the APRS?protocol with
a first-characer?identifier?
Or does the?3rd party
flag only apply if the?packet is
re-transmitted
back to RF as in a
message packet.
I'm embarrassed?that I
am now forgetting more about APRS details
?
On Fri, Aug 13, 2021 at
12:15 PM KB9HGI <kb9hgi@...>
wrote:
Here is my tiny
tracker KB9HGI-15 which is in a fixed
location but is moving all over the
place.
?
Sent from for
Windows
?
?
Which SSID is your
digipeater on? KB9HGI-15? I see you've
used a lot of SSIDs:
This is where I see what I expect to
be your TT4, along with some other
SSIDs:
And you're currently underway:
Everything checks out at the moment,
right?
?
--
Richard A.
Painter, P.E. Retired
|
The packets look like someone just hooked the output of one TNC to theTX input of another one instead of actually implementing an IGate or digi.? So the one TNC is trnansmitting?the parsed and "displayed" packet as received from another.? Once received, the format is a "display" format and not part of the on-air AX.25 protocol.
Bob, WB4APR
On Sat, Aug 14, 2021 at 12:11 AM KB9HGI < kb9hgi@...> wrote: No I don¡¯t think nothing is wrong with the Igate I have had it on for years its in rx only mode and its been working fine. A buddy of mine AA9GL has been running a digi. But was wanting to shut it off. He never had that problem his fixed station moving to different locations. I need to hook the TT4 back up computer again and try some different setting either its config wrong or it¡¯s a piece of junk! ? Steve KB9HGI ? Sent from for Windows ? ? AND bad packets are NOT supposed to be passed on! They are supposed to be discarded. ? On Fri, Aug 13, 2021 at 2:36 PM Lynn Deffenbaugh <kj4erj@...> wrote: They are completely invalid packets.?? If a 3rd party packet is received, it is supposed to be unwrapped before being gated. Something is broken with this IGate. Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
PS.? From Third Party PacketsPlease refer to the chapter in the APRS specification on third-party packets. At this time, all IGates strip any path information out of the third-party header to reduce bandwidth requirements and maintain AX.25 packet length compatibility. - ?An IGate should not gate third-party packets (data type }) with TCPIP or TCPXX in the third-party header to APRS-IS.
- Third-party packets without TCPIP in the header are to be gated to APRS-IS?AFTER?stripping the RF header and third-party data type.
? On 8/13/2021 3:24 PM, Robert Bruninga wrote: I'm probably in a chemo fog, but most of the packets -originated- by the callsign KB9HGI-15 appear (raw as listed on ) to be other people's packets in its payload field..? Shouldnt?these be identified as 3rd-party in someway since they don't match? the APRS?protocol with a first-characer?identifier? Or does the?3rd party flag only apply if the?packet is re-transmitted back to RF as in a message packet. I'm embarrassed?that I am now forgetting more about APRS details ? On Fri, Aug 13, 2021 at 12:15 PM KB9HGI <kb9hgi@...> wrote: Here is my tiny tracker KB9HGI-15 which is in a fixed location but is moving all over the place. 
? Sent from for Windows ? ? Which SSID is your digipeater on? KB9HGI-15? I see you've used a lot of SSIDs:
This is where I see what I expect to be your TT4, along with some other SSIDs:
And you're currently underway:
Everything checks out at the moment, right?
?
--
Richard A. Painter, P.E. Retired
|
Here is the settings in my TT4 BANK??? is???????????? 0 P300????? is???????????? FALSE TXTDISP?????????????? is???????????? FALSE NODISP is???????????? FALSE PPATHING????????? is???????????? FALSE DMSDISP???????????? is???????????? FALSE MICETMV??????????? is???????????? FALSE ENTS????? is???????????? FALSE TELHIRES????????????? is???????????? FALSE TELVOLT?????????????? is???????????? TRUE TELTEMP????????????? is???????????? TRUE PREEMPT???????????? is???????????? FALSE DIGIID?? is???????????? TRUE WXPOS is???????????? TRUE TELREAD????????????? is???????????? TRUE FRAWDISP????????? is???????????? FALSE HRAWDISP????????? is???????????? FALSE WYPTXT?????????????? is???????????? FALSE PKTICOM???????????? is???????????? TRUE PKTOCOM?????????? is???????????? FALSE RPATHDISP???????? is???????????? FALSE LEDS????? is???????????? TRUE PAVPEN?????????????? is???????????? FALSE DEC96?? is???????????? FALSE DDIST??? is???????????? FALSE HEADERLN????????? is???????????? FALSE DMETRIC???????????? is???????????? FALSE SOFTRST????????????? is???????????? TRUE MSGCMD??????????? is???????????? FALSE MSGCAP????????????? is???????????? FALSE LRNTPS is???????????? FALSE GPSCHK?????????????? is???????????? FALSE INTCLK? is???????????? FALSE DECSTAT????????????? is???????????? FALSE DIGIMY is???????????? TRUE TOSV???? is???????????? FALSE TALT????? is???????????? FALSE TSPEED is???????????? TRUE TIMESTAMP?????? is???????????? TRUE TIMEHMS??????????? is???????????? TRUE SBEN???? is???????????? FALSE TSWPT? is???????????? TRUE AMODE is???????????? TEXT BMODE is???????????? GPS ABAUD is???????????? 4800 BBAUD is???????????? 4800 BNKMODE????????? is???????????? 0 SSIDROUTE???????? is???????????? 0 ALTNET is???????????? APTT4 MYCALL??????????????? is???????????? KB9HGI-15 PATH1?? is???????????? WIDE1-1 PATH2?? is???????????? WIDE2-1 PATH3?? is TSTAT??? is???????????? KB9HGI's????????????? Digipeater?????????? Quincy, IL BTEXT??? is???????????? >/TinyTrak4??????? Alpha BPERIOD????????????? is???????????? 0 TXD??????? is???????????? 40 MTXD??? is???????????? 10 PERSIST is???????????? 65 SLOTTIME??????????? is???????????? 15 QUIET?? is???????????? 10 TRNKMODE??????? is???????????? 0 CDMODE???????????? is???????????? TONES CDLEVEL?????????????? is???????????? 20 TXLEVEL?????????????? is???????????? 128 TXTWIST????????????? is???????????? 50 RXAMP is???????????? 10 GWAYLEN?????????? is???????????? 9 GWAYMODE????? is???????????? NMEA GRELAYBITS??????? is???????????? 1 GRELAYRATE????? is???????????? 0 GKRELAY????????????? is???????????? 0 LOCATION?????????? is???????????? 3957.1300N???????? 09123.3400W GALT???? is???????????? 1000 TSYMCODE???????? is???????????? # TSYMTABLE??????? is???????????? / STATUSRATE????? is???????????? 1 PPERIOD????????????? is???????????? 1800 MPPERIOD????????? is???????????? 0 SBSSPEED??????????? is???????????? 5 SBFSPEED??????????? is???????????? 60 SBSPERIOD???????? is???????????? 1800 SBFPERIOD???????? is???????????? 90 SBTANGLE?????????? is???????????? 27 SBTSLOPE??????????? is???????????? 255 SBTTIME????????????? is???????????? 5 MMSG? is???????????? 2 TSOFFSET??????????? is???????????? 17 TDAO??? is???????????? 0 TPROTOCOL?????? is???????????? MIC-E TPSWITCH?????????? is???????????? 0 TPERIOD????????????? is???????????? 0 TVOLTTWK????????? is???????????? 128 TTEMPTWK???????? is???????????? 128 WPERIOD??????????? is???????????? 0 ALIAS1? is???????????? WIDE1 ALIAS2? is ALIAS3? is DUPETIME????????? is???????????? 30 FILTERCALL???????? is TXFREQ is???????????? 144.390 RXFREQ is???????????? 144.390 RXSQUELCH??????? is???????????? 0 ? Sent from for Windows ?
toggle quoted message
Show quoted text
From: Rich PainterSent: Friday, August 13, 2021 6:14 PM To: [email protected]Subject: Re: [TinyTrak] TT4 digipeater ? AND bad packets are NOT supposed to be passed on! They are supposed to be discarded. ? On Fri, Aug 13, 2021 at 2:36 PM Lynn Deffenbaugh <kj4erj@...> wrote: They are completely invalid packets.?? If a 3rd party packet is received, it is supposed to be unwrapped before being gated. Something is broken with this IGate. Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
PS.? From Third Party PacketsPlease refer to the chapter in the APRS specification on third-party packets. At this time, all IGates strip any path information out of the third-party header to reduce bandwidth requirements and maintain AX.25 packet length compatibility. - ?An IGate should not gate third-party packets (data type }) with TCPIP or TCPXX in the third-party header to APRS-IS.
- Third-party packets without TCPIP in the header are to be gated to APRS-IS?AFTER?stripping the RF header and third-party data type.
? On 8/13/2021 3:24 PM, Robert Bruninga wrote: I'm probably in a chemo fog, but most of the packets -originated- by the callsign KB9HGI-15 appear (raw as listed on ) to be other people's packets in its payload field..? Shouldnt?these be identified as 3rd-party in someway since they don't match? the APRS?protocol with a first-characer?identifier? Or does the?3rd party flag only apply if the?packet is re-transmitted back to RF as in a message packet. I'm embarrassed?that I am now forgetting more about APRS details ? On Fri, Aug 13, 2021 at 12:15 PM KB9HGI <kb9hgi@...> wrote: Here is my tiny tracker KB9HGI-15 which is in a fixed location but is moving all over the place. ? Sent from for Windows ? ? Which SSID is your digipeater on? KB9HGI-15? I see you've used a lot of SSIDs:
This is where I see what I expect to be your TT4, along with some other SSIDs:
And you're currently underway:
Everything checks out at the moment, right?
?
--
Richard A. Painter, P.E. Retired
|
No I don¡¯t think nothing is wrong with the Igate I have had it on for years its in rx only mode and its been working fine. A buddy of mine AA9GL has been running a digi. But was wanting to shut it off. He never had that problem his fixed station moving to different locations. I need to hook the TT4 back up computer again and try some different setting either its config wrong or it¡¯s a piece of junk! ? Steve KB9HGI ? Sent from for Windows ?
toggle quoted message
Show quoted text
From: Rich PainterSent: Friday, August 13, 2021 6:14 PM To: [email protected]Subject: Re: [TinyTrak] TT4 digipeater ? AND bad packets are NOT supposed to be passed on! They are supposed to be discarded. ? On Fri, Aug 13, 2021 at 2:36 PM Lynn Deffenbaugh <kj4erj@...> wrote: They are completely invalid packets.?? If a 3rd party packet is received, it is supposed to be unwrapped before being gated. Something is broken with this IGate. Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
PS.? From Third Party PacketsPlease refer to the chapter in the APRS specification on third-party packets. At this time, all IGates strip any path information out of the third-party header to reduce bandwidth requirements and maintain AX.25 packet length compatibility. - ?An IGate should not gate third-party packets (data type }) with TCPIP or TCPXX in the third-party header to APRS-IS.
- Third-party packets without TCPIP in the header are to be gated to APRS-IS?AFTER?stripping the RF header and third-party data type.
? On 8/13/2021 3:24 PM, Robert Bruninga wrote: I'm probably in a chemo fog, but most of the packets -originated- by the callsign KB9HGI-15 appear (raw as listed on ) to be other people's packets in its payload field..? Shouldnt?these be identified as 3rd-party in someway since they don't match? the APRS?protocol with a first-characer?identifier? Or does the?3rd party flag only apply if the?packet is re-transmitted back to RF as in a message packet. I'm embarrassed?that I am now forgetting more about APRS details ? On Fri, Aug 13, 2021 at 12:15 PM KB9HGI <kb9hgi@...> wrote: Here is my tiny tracker KB9HGI-15 which is in a fixed location but is moving all over the place. 
? Sent from for Windows ? ? Which SSID is your digipeater on? KB9HGI-15? I see you've used a lot of SSIDs:
This is where I see what I expect to be your TT4, along with some other SSIDs:
And you're currently underway:
Everything checks out at the moment, right?
?
--
Richard A. Painter, P.E. Retired
|
AND bad packets are NOT supposed to be passed on! They are supposed to be discarded.
rich
On Fri, Aug 13, 2021 at 2:36 PM Lynn Deffenbaugh < kj4erj@...> wrote:
They are completely invalid packets.?? If
a 3rd party packet is received, it is supposed to be unwrapped
before being gated.
Something is broken with this IGate.
Lynn (D) - KJ4ERJ - Author of APRSISCE
for Windows Mobile and Win32
PS.? From
Third Party Packets
Please refer to the chapter
in the APRS specification on third-party packets. At this
time, all IGates strip any path information out of the
third-party header to reduce bandwidth requirements and
maintain AX.25 packet length compatibility.
- ?An IGate should not gate third-party packets (data type
}) with TCPIP or TCPXX in the third-party header to APRS-IS.
- Third-party packets without TCPIP in the header are to be
gated to APRS-IS?AFTER?stripping
the RF header and third-party data type.
On 8/13/2021 3:24 PM, Robert Bruninga
wrote:
I'm probably in a chemo fog, but most of the
packets -originated- by
the callsign KB9HGI-15 appear (raw as listed on )
to be other people's packets in its payload field..?
Shouldnt?these
be identified as 3rd-party in someway since they don't
match?
the APRS?protocol with a first-characer?identifier?
Or does the?3rd party flag only apply if the?packet is
re-transmitted
back to RF as in a message packet.
I'm embarrassed?that I am now forgetting more about APRS
details
than I care to admit.
Bob
On Fri, Aug 13, 2021 at
12:15 PM KB9HGI < kb9hgi@...> wrote:
Here is my tiny tracker KB9HGI-15
which is in a fixed location but is moving all over
the place.
?
Sent from for
Windows
?
?
Which SSID is your digipeater on?
KB9HGI-15? I see you've used a lot of SSIDs:
This is where I see what I expect to be your TT4,
along with some other SSIDs:
And you're currently underway:
Everything checks out at the moment, right?
-- Richard A. Painter, P.E. Retired
|
Is his I-Gate retransmitting packets that his digipeater initiated or processed? If Bob B. can't figure it out, we are all doomed! Maybe he should set some of his gear up with tactical call signs , at least for system validation.
73,
Allen AF6OF
-----Original Message-----
From: Lynn Deffenbaugh <kj4erj@...>
To: [email protected]
Sent: Fri, Aug 13, 2021 1:36 pm
Subject: Re: [TinyTrak] TT4 digipeater
They are completely invalid packets.?? If
a 3rd party packet is received, it is supposed to be unwrapped
before being gated.
Something is broken with this IGate.
Lynn (D) - KJ4ERJ - Author of APRSISCE
for Windows Mobile and Win32
PS.? From
Third Party Packets
Please refer to the chapter
in the APRS specification on third-party packets. At this
time, all IGates strip any path information out of the
third-party header to reduce bandwidth requirements and
maintain AX.25 packet length compatibility.
- ?An IGate should not gate third-party packets (data type
}) with TCPIP or TCPXX in the third-party header to APRS-IS.
- Third-party packets without TCPIP in the header are to be
gated to APRS-IS?AFTER?stripping
the RF header and third-party data type.
On 8/13/2021 3:24 PM, Robert Bruninga
wrote:
I'm probably in a chemo fog, but most of the
packets -originated- by
the callsign KB9HGI-15 appear (raw as listed on )
to be other people's packets in its payload field..?
Shouldnt?these
be identified as 3rd-party in someway since they don't
match?
the APRS?protocol with a first-characer?identifier?
Or does the?3rd party flag only apply if the?packet is
re-transmitted
back to RF as in a message packet.
I'm embarrassed?that I am now forgetting more about APRS
details
than I care to admit.
Bob
On Fri, Aug 13, 2021 at
12:15 PM KB9HGI < kb9hgi@...> wrote:
Here is my tiny tracker KB9HGI-15
which is in a fixed location but is moving all over
the place.
?
Sent from for
Windows
?
?
Which SSID is your digipeater on?
KB9HGI-15? I see you've used a lot of SSIDs:
This is where I see what I expect to be your TT4,
along with some other SSIDs:
And you're currently underway:
Everything checks out at the moment, right?
|
They are completely invalid packets.?? If
a 3rd party packet is received, it is supposed to be unwrapped
before being gated.
Something is broken with this IGate.
Lynn (D) - KJ4ERJ - Author of APRSISCE
for Windows Mobile and Win32
PS.? From
Third Party Packets
Please refer to the chapter
in the APRS specification on third-party packets. At this
time, all IGates strip any path information out of the
third-party header to reduce bandwidth requirements and
maintain AX.25 packet length compatibility.
- ?An IGate should not gate third-party packets (data type
}) with TCPIP or TCPXX in the third-party header to APRS-IS.
- Third-party packets without TCPIP in the header are to be
gated to APRS-IS?AFTER?stripping
the RF header and third-party data type.
On 8/13/2021 3:24 PM, Robert Bruninga
wrote:
I'm probably in a chemo fog, but most of the
packets -originated- by
the callsign KB9HGI-15 appear (raw as listed on )
to be other people's packets in its payload field..?
Shouldnt?these
be identified as 3rd-party in someway since they don't
match?
the APRS?protocol with a first-characer?identifier?
Or does the?3rd party flag only apply if the?packet is
re-transmitted
back to RF as in a message packet.
I'm embarrassed?that I am now forgetting more about APRS
details
than I care to admit.
Bob
On Fri, Aug 13, 2021 at
12:15 PM KB9HGI < kb9hgi@...> wrote:
Here is my tiny tracker KB9HGI-15
which is in a fixed location but is moving all over
the place.
?
Sent from for
Windows
?
?
Which SSID is your digipeater on?
KB9HGI-15? I see you've used a lot of SSIDs:
This is where I see what I expect to be your TT4,
along with some other SSIDs:
And you're currently underway:
Everything checks out at the moment, right?
|
AC1DW
Rich Painter
