| |
I3XTY > TUTTI 29.05.09 21:28l 484 Lines 19604 Bytes #999 (0) @ ITA
BID : 40128_I3XTY
Read: GUEST IV3JER IZ6WQP
Subj: MSG n. 7 di I3ZJV
Path: IZ3LSV<IK6ZDE<IK2XDE<IR2UBX<IW2OHX<IK3GET<I3LUG<I3XTY<I3XTY
Sent: 090529/2221 @:I3XTY.TV.IVEN.ITA.EU $:40128_I3XTY Sally 4.1.232
Date: ven, 29 mag 2009 22:21:51 LT
From: I3XTY (Luigi)
To: TUTTI@ITA
Subject: MSG n. 7 di I3ZJV
Inviato da: I3XTY@I3XTY.TV.IVEN.ITA.EU
From: I3ZJV@I3XTY.TV.IVEN.ITA.EU
To : TUTTI@ITA
From: PE1DNN@PE1DNN.PI8APD.#GLD.NLD.EU
To : KENWOO@EU
T:From: pe1dnn@os.pe1dnn.ampr.org (Henk de Groot)
T:Newsgroups: ampr.org.eur.kenwoo
T:Message-Id: <slrn8qga3v.de2.pe1dnn@os.pe1dnn.ampr.org>
Hello TH-D7E user,
This is a bulletin I send out to the dutch packet network. Since it
also may apply to you when you build up APRS in your area you may
be interested in this TH-D7E mishap. I just translated the text
which I send out, the rest of the text was already in English.
----------------
There are considerable problems with the TH-D7E on our APRS network.
Slowly everybody owning this protable tranceiver start to notice.
The problem is the following. If the tranceiver is tuned to the
APRS frequency and receives data, then ater a while decoding of
APRS messages stops (are not shown on the display) and the portable
seases to transmit beacons. You can see this because "MY PACKET"
messages stop to appear and when you look closely you'll see that
the tranceiver is not tranmitting beacons at all anymore.
After a own investigation I found out that the tranceiver cannot handle
big packets well enough and reception of one of them will stop the
APRS function. As appendix you'll find a number of messages which may
help to reproduce the error. This error has been verified with at least
3 of those tranceivers (all TH-D7E with version 2.0 prom). Unfortunately
I could not find anybody in my area with a version 1.0 prom. [ There
are no TH-D7E's I know of which does NOT have this fault, I guess they
are all faulty ].
Meanwhile another HAM having the same problem with his tranceiver has
put the problem forward to his dealer and I did the same to with
my dealer for the product I purchaged. Please also report to your
dealer if you also notice this error. When enough people report this,
there might be something done about it. Don't let the dealer tell you
that he did not know this problem. It has been reported to at least
2 dealers, it has been discussed on the APRS Special Interest Group,
I posted it to the dutch newsgroup nl.radio.amateurs and to the packet
group APRS@NLDNET. And now I'm posting it to APRS@DL and APRS@EU.
I whish to point out that the device is used where it was designed for
and that you may reasonably expext, also judgeing the sails-prise, that
the device is suitable for APRS use. This use is also described in
the manual. This is a different error than the KISS and DAMA problem,
those were not mentioned in the manual.
Kind regards,
Henk.
These texts are free to be used/copied (but not manipulated).
Here is the text of some messages I've send to the APRS SIG
(texts are slightly edited so texts on which I respond are
put first. The original text can be found at "www.tapr.org").
---------------------------------------------------------------------
Date: Tue, 22 Aug 2000 16:40:03 +0200
Author: <henk.de.groot@hetnet.nl>
Subject: TH-D7E APRS reception/beacon stop
Hello SIG,
I have a question. The APRS load in our area is growing, especially when
I also test my own digipeater on Air.
We now started to experience problems with the TH-D7E which is equipped
with the version 2.0 prom (the one supporting KISS).
When I set up the TNC to receive APRS - with logging on the display - then
after a while the display logging stops. It receives packets but does not
decode and show. From that moment on also no beacon transmissions are
performed anymore by the unit. When I cycle the BCN button by pressing
it off and on again still no transmission. When I cycle the TNC from
APRS via Packet, off, back to APRS the unit start working again.
Especially when I test my own digipeater the TH-D7 will give up within
15 minutes.
I did a search on the SIG and saw that the TH-D7A had the same kind
of problem, but much worse. On the TH-D7E v2.0 the unit can still be
controlled, no lockup of the keyboard so that you have to take off
the battery or anything like that.
I did some testing. The unit has the behaviour both on 6 volt battery as
on a 9 volt stabilized power supply. When I set the unit up for beaconing
on the APRS frequency but receive on an empty frequency then the unit just
continues to send beacons for more than 48 hours without interruption.
When my own digipeater is not on the air it can take up to more that 2
hours before the "not-decoding/transmitting" happens. If the unit only
receives but is not setup to send beacons then the problem still occurs.
So it seems to have a relation with packet reception.
Now this is not only my unit that fails. We have 2 other Ham's here in
the area. With exactly the same problem.
You can test this yourself by setting up your TH-D7 in APRS mode on a
fixed antenna (to receive may packets, load is needed). Just let it sit
and check regulairy if the unit still decodes APRS packets and if by
cycling the BCON button a beacon is realy transmitted. Be sure not to
have APO enabled. Don't cycle the TNC because then you reinitialize
everything. By the way, setting battery save does not make a change.
What I would like to know (I know the TH-D7A locks up):
1) How do other TH-D7E v2.0 behave, do they also have the same
problem (besides to 2 other units in our area)?
2) How does the TH-D7E v1.0 behave, does it lock up like the
TH-D7A used to do, or just like the TH-D7E v 2.0 that it stops
decoding and transmitting after a while?
3) How does the TH-D7A(G) behave, does it have fixed the
problem?
Since the TH-D7E v2.0 does not lock-up solid and I don't expect that the
TH-D7A(G) doesn't either, but does it keep on decoding received data?
I would like to get reports on this. I seems that this problem is unknown
by the dealers and yet we have 3 units behaving exactly the same way on
high APRS load. So please report so we have something to show to Kenwood
an its dealers to get it fixed.
Kind regards,
Henk.
---------------------------------------------------------------------
Date: Tue, 22 Aug 2000 23:44:34 +0200
Author: "Henk de Groot" <henk.de.groot@hetnet.nl>
Subject: Re: TH-D7E APRS reception/beacon stop
> THe problem we think we saw at dayton, is that if the channel is 100%
> busy including noise and open squelch, such that the radio never gets to
> transmit, then after some time, the transmit buffer might be filling up
> and then radio might be locking up...
>
> Could that explain what you see? Again, it rquires 100% busy channel
> tho...?
No, It's not that busy! The TNC also does not have a "STA" message, so
the transmit buffer is empty. When I press BCON twice to force a beacon
then "STA" also does not appear.
I am now able to reproduce the problem in about 10 seconds, and you can
do the same after reading this. Send the following two frames into the
air in one go (no pause between the frames):
PE1DNN-2>TEST:xxxxxxxxxxxxxxxxxxxxxx[250 x]xxxxxxxxxxxxxxx
PE1DNN-2>TEST:xxxxxxxxxxxxxxxxxxxxxx[250 x]xxxxxxxxxxxxxxx
So that's two messages with a payload of 251 bytes (250 x-ses plus a
carriage return).
After the THD7 attempted to read those two frames it does not decode
APRS anymore and cycling the BCON button doesn't send a beacon anymore.
So the messages seem to overrun something inside.
So if you are blessed with users that use a long status message like some
have the habit here, then you loose.
For users of DIGI_NED, you can create those two frames easily. Make a file
"thd7.ini" containing the 250 'x' characters. Then create a digi_ned.ini
file with the following minimum content:
----------------------------------
send: 20 all TEST
thd7.ini
send: 20 all TEST
thd7.ini
digi_owner: PE1DNN
digi_call: PE1DNN-2
digi_dest: APZ016
----------------------------------
Then run digi_ned. In about 5 secondes DIGI_NED will deposit the two
beacons, in this case 2 times 250 'x' characters. After the TH-D7E
v2.0 receives it the APRS function is dead, no decoding and no
beacon transmissions anymore.
Kind regards,
Henk.
---------------------------------------------------------------------
Date: Wed, 23 Aug 2000 10:35:38 +0200
Author: <henk.de.groot@hetnet.nl>
Subject: Re: TH-D7E APRS reception/beacon stop
> > I am now able to reproduce the [D7 lockup] problem... Send these:
> >
> > PE1DNN-2>TEST:xxxxxxxxxxxxxxxxxxxxxx[250 x]xxxxxxxxxxxxxxx
> > PE1DNN-2>TEST:xxxxxxxxxxxxxxxxxxxxxx[250 x]xxxxxxxxxxxxxxx
> >
> > After the THD7 attempted to read those two frames it does not decode
> > APRS anymore...
>
> Yes, this is equivalent to hitting your head with a hammer. Dont do it.
> and it will stop hurting... <grin>.
>
> All APRS formats are much shorter than that. The longest STATUS beacon
> is 63 bytes, so no packet in APRS should ever be this long...
>
> > So if you are blessed with users that use a long status message like some
> > have the habit here, then you loose.
>
> They violate the protocol.... Their software should not permit them to
> enter a STATUS that is longer than what will be displayed on other users
> screens.. And of course other D7 and D700's only display the first 20 or
> 28 characters which is even more of a restriction...
>
> bob
Well, not exactly. They are perfectly valid AX.25 frames. It does not
violate any protocol in any way. You cannot refer to the APRS
specification since it is not an APRS type frame. It is just a plain
AX.25 version 2 UI frame. And even if the frame would be invalid, which
it isn't, then there is no excuse to exhibit this behavior. When I send this
frame to DosAPRS, would you find it acceptable that it stopped functioning?
I bet you send out a fix for it a.s.a.p. when that would happen.
If you set TH-D7E on a DX cluster frequency that also carries normal AX.25
traffic then you loose too. In Europe we have this a lot. The interlinks
that carry the AX.25 Packet traffic also carry the DX cluster data.
Packet-lengths of 255 are perfectly normal on these interlinks and I bet
the TH-D7E will also exhibit this behavior when the frame is an "I"
frame. There is no excuse not to cope with these packets.
This is not hitting yourself with a hammer at all, this is *not* high load.
It are long packets but well within the AX.25 protocol specification. I
directed the packet to "TEST" so it is not APRS so violation of the APRS
protocol is not applicable.
It is sloppy programming in the unit. They cannot get the interpretation of
the PERSIST counter right, the RESP timer doesn't work and now it stops
responding on 2 perfectly valid AX.25 frames. And this is v2.0 software so
not even the first attempt.
By the way, I heard that the D700 has problems when monitoring our DX
cluster. Could be the very same problem. I don't own the unit but it is
easy to test now...
About the restricted status length, you're wrong! There *is* a limited
length *but* if you have a long third-party prefix, your information
field may well grow up to 255 characters if they are stacked (third party
packet through another third party network). Besides that you can have raw
weather reports (has no limit in the specification), Telemetry report with
an unspecified comment length, "NWS Buletin text" without a defined
maximum length, user-definded packets and invalid-data/test-data packets
which are not restricted in lenght either. So even in APRS you can
perfectly have these long frames. Two in a row and you decoder and beacon
is gone. I bet that's what happened in Dayton too.
So your statement that no APRS frame is that long is not valid. Also you
can have normal beacons which are not APRS but appear on the APRS QRG
like ID frames for example. These are restricted by the AX.25 protocol
specification and are valid to have a length of 255 bytes (plus <CR>).
I don't know how to do it, but can somebody look on the web how many
packets have Information field lengths above 250 characters? I bet
there are a lot.
Sorry that I have to react this way, but it looks to like you want to
defend Kenwood by saying that this is not really a problem. Here in
Europe it is and it is very annoying that after making a trip you find
out the tracks stops half-way because beacons were not longer transmitted.
Or that you have the unit on standby to be alerted when somebody sends a
message and then somebody does that but alerting does not occur because
decoding the packets stopped.
I will try to find out what the unit can sustain and I'm thinking about
making an option in the digipeater to limit the packet sizes to what
the TH-D7E can digest. I also have to find out if the packet-header also
counts. I used a small packet header but with a large packet header
this may occur on even much smaler information-fields. Also when using
much smaler information fields but sending 3 packets in a row it may
also cause the problem. So it is way to early to state already that
this doesn't happen in normal APRS. I don't know what your reasons are
to jump to the conclusion that this is not a real problem in APRS, but it
does not solve the problem.
Kind regards,
Henk.
---------------------------------------------------------------------
Date: Wed, 23 Aug 2000 10:52:45 +0200
Author: <henk.de.groot@hetnet.nl>
Subject: Re: TH-D7E APRS reception/beacon stop
> From: "bounce-aprssig-18892@lists.tapr.org" <bounce-aprssig-18892
> @lists.tapr.org> on behalf of "Brian B. Riley" <brianbr@macconnect.com>
> Sent: Wednesday, August 23, 2000 1:16 AM
> To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
> Subject: [aprssig] Re: TH-D7E APRS reception/beacon stop
>
> There is no doubt that this is a bug ... Kenwood should have
> anticipated this problem ... that said, I was under the impression
> that a 'standard' APRS frame has a maximum of 128 bytes of data
> and that any 'proper APRS client' having in excess of 128 bytes
> of data will break it at 128 and send an additional frame.
>
> 73 de brian
> --
> N1BQ-3 @ 44 31.73N 072 51.55W
> WideN-N digi and weather station in Underhill Center, VT
> <n1bq@amsat.org>
Take a look at a worst case status message with appended worst-case
3rd party part:
3rd party identification: 1
source call: 9
separator: 1
destination call: 9
8 digipeaters: 81
terminating colon: 1
status message identification: 1
max length status message: 62
If you add this up then you see that the packet is already 165 bytes,
so reserving 128 bytes for buffer-space is definately too small. The
unit should at least be able to cope with that.
Kind regards,
Henk.
---------------------------------------------------------------------
Date: Wed, 23 Aug 2000 22:12:18 +0200
Author: "Henk de Groot" <henk.de.groot@hetnet.nl>
Subject: TH-D7E crash limits
Okay, I was hitting myself with a hammer when I crashed my TH-D7E APRS
reception using to sequential transmissions with large packets
(251 bytes).
So I sat down and tried to find out how big this hammer actually is
with which I was hitting myself. Here are the results.
I send out 2 packets like this
PE1DNN-2>TEST:xxxxxxxxxxx<number of chars>xxxxxxxxx<CR>
PE1DNN-2>TEST:<CR>
So one "big" packet and one with only one character.
The limits the TH-D7E can keep up with is a payload of 181 bytes.
When transmitting 182 bytes the unit stops decoding and sending
beacons. This 182 bytes are 181 "x" characters plus a terminating
return.
I was curious if more data would hurt more. So I send 3 of those
181 byte packets in one go, and the TH-D7E would stay up.
I also tested this combination:
PE1DNN-2>TEST:<CR>
PE1DNN-2>TEST:xxxxxxxxxxx<number of chars>xxxxxxxxx<CR>
In this case the limits are exactly the same, 181 bytes is okay
and 182 byte is not.
The next test was to add a digipeater in the frame. So I added a
digipeater DUMMYX-10 to my path and tried.
PE1DNN-2>TEST,DUMMYX-10:xxxxxxxx<number of chars>xxxxxxx<CR>
PE1DNN-2>TEST:<CR>
I expected that the payload would decrease by 7 bytes, since that is
the space a digipeater occupies. But to my surprise this hits the
payload by 10 bytes. So the buffer works on the decoded values from
the AX.25 stream (the call+SSID is 9 bytes plus a comma).
The limit with one digipeater is at 171/172 bytes. This means that
every digipeater eats up 10 bytes. You can have 8 of them so that
means the save playload limit is 101 bytes. If you ever send more
than 101 bytes you may crash a TH-D7E.
Of course I checked this:
PE1DNN-2>TEST,DUMMYX-10,DUMMYX-10,DUMMYX-10,DUMMYX-10,DUMMYX-10,
DUMMYX-10,DUMMYX-10,DUMMYX-10:xxxxxxxx<number of chars>xxxxxxx<CR>
PE1DNN-2>TEST:<CR>
(sorry if the lines break up, its too long...)
Sure, the limit is at 101/102 bytes, verified. I did not use a
worse case length call and destination addess. This would take
an extra 6 bytes from the palyload. The absolute save length to
use for UI packets is 95 bytes...
I also tried with only a single packet. I used the frame with
all those DIGIs in it (8). And yes, the unit breaks down again!
The limit is amazingly still at 101/102!
The last try is to remove all the DIGI's from the path and see
if the limit is now still at 181/182. Well, it was!! So you
dont need that second transmission.
During the last test I discovered some instability. Sometimes
a longer packet was accepted. Maybe that's had to do with
reception errors.
I did a small stress test by send 10 packets like this:
PE1DNN-2>TEST:xxxxxxxxxxx<number of chars>xxxxxxxxx<CR>
containing 181 characters pay-load. The TH-D7E will survive
that with no problem.
So now we know how hard I hit myself with a hammer. I have no
clue why this was not a known bug (yes the lockup was known,
but not why). You only need one big packet to make this happen.
Of course this is not a scientific test. I had the handheld
just in my hand. Of course I did all the test several times
to be sure. But I do not know the infuence of environment
temperature, on time dependency, dependency on TXDelay flags
and the type of signal used during TX-Delay. So your milage
may vary.
To be sure I did a quick test with a local HAM with the same
unit. I added the local digipeater "PE1MEW-2" in the path.
This would shrink the possible pay-load with 9 bytes (8 for
the call plus a comma). So 172/173 should be the border.
His unit stopt decoding packets however at 172 and continued
to work with 171. Reason is the extra '*' that appears when
he receives the packet via the digi.
I have no idea how the performance of the other Kenwood units
is, please post results (Although if your unit completely
locks up then I understand that you don't want to conduct
such tests).
But for hitting myself with a hammer, a very small plastic
hammer will do so it appears and it still huts the same.
So I must be hammering on a very weak spot then...
Kind regards,
Henk.
Can anybody please test the TH-D7A(G). If that unit is okay
we can push Kenwood Europe to deliver the same software for
the E model.
---------------------------------------------------------------------
#########################################################################
The difference between theory and practice in practice is bigger than the
difference between theory and practice in theory.
Henk de Groot | Apeldoorn, The Netherlands, JO32AF
PE1DNN@PI8APD.#GLD.NLD.EU | NOKIA-ATF2, YAM Modem, Linux RedHat 5.2
73 a tutti de Luigi.
li, ven 29 maggio 2009 22:20 LT (+2.00 UTC)
I3XTY Paese, Veneto
BBS I3XTY@I3XTY.TV.IVEN.ITA.EU
e_mail i3xty@yahoo.it
http://
Messaggio inviato con Sally V4.1.232 software packet per Windows 32bit.
Message sent with Sally V4.1. Windows packet software.
Read previous mail | Read next mail
| |
