| |
PE1DNN > ALL 26.12.02 00:41l 251 Lines 12179 Bytes #999 (0) @ WW
BID : VD7P7HPE1DNN
Read: GUEST
Subj: Re: tsthost + thd7 / tmd700
Path: DB0FHN<DB0RGB<DB0MRW<DB0ERF<DB0FBB<DB0GOS<DB0EEO<PI8DAZ<PI8APD<PE1DNN
Sent: 021225/2318Z @:PE1DNN.PI8APD.#GLD.NLD.EU #:52162 [Apeldoorn] $:VD7P7HPE1D
From: PE1DNN@PE1DNN.PI8APD.#GLD.NLD.EU
To : ALL@WW
T:From: Henk de Groot <pe1dnn@pe1dnn.ampr.org>
T:Newsgroups: ampr.org.ww.all
T:Message-Id: <audeav$2t5$1@pe1dnn.ampr.org>
Hello Paulo,
ct2gnh@ct2gnh.ctav.prt.eu schreef:
> Hello, i send a 7plus file, named as kiss.zip
> it will solve the problem config of thd7 and tmd700
> with tsthost !
Maybe the TMD700, but not THD7. It's not a configuration issue, the TH-D7
is full of bugs.
I'm currently experimenting to make a TH-D7 into a small portable APRS
digipeater with a PC (Just for fun to see if it can be done). You have to
be very gentle for the TNC, a slight overload and it stops responding. I
have it working now, it runs for about 20 minutes without a hangup and I
have a mechanism that restarts the TNC when it doesn't appear to send data
anymore (its tricky but can be done...). Anyway it requires a specialized
driver (i.e. low level C programming) to have any chance, no way it works
with standard KISS drivers.
Find attached my findings of using KISS AX.25 on the TH-D7. It works, but
only very restricted. More reports from me can be found on the TH-D7 yahoo
group, they were also posted to packet at that time.
With the load of bugs in the TH-D7 implementation I can't imagine that the
TMD700 is any better. I don't have a TMD700 so I can't verify.
Kind regards,
Henk.
-----------------------------------------------------------------------
Subject: TH-D7E "StaCon" error in KISS
Hello,
Yesterday I did some tests with the THD7 in KISS and found out how to
avoid the KISS hangup where the "STA" and "CON" indications are shown
and the TNC not responds anymore. I conducted the test for an issue on
the APRS SIG, but the text may be interesting for you too.
There are some rumours that packets with > 100 bytes will kill the KISS
TNC. THIS IS NOT TRUE. There are problems with long packets however in
standalone APRS mode which Kenwood can fix. The KISS TNC is killed by
sending too much frames to it. It seems like the TH-D7 can only buffer
one full-size information frame at the time.
Here is the text I wrote to the APRS SIG (which a changed preamble for
posting here).
Kind regards.
Henk.
------------------------------------------------------------------------
I did some experiments and there are some interesting things to know
about KISS with the THD7. The software I use restricts the size of the
data to 256 bytes as per AX25 V2 specification so I did not try oversized
packets. Of course when sending a complete KISS frame with 256 bytes
payload data the totoal number of bytes will be higher due to the header
and due to the escape-bytes in the KISS data.
Executive Summary (Detailed description will follow below)
------------------------------------------------------------------------
Good news: The TH-D7E V2.0 in KISS works!!!
+----------------------------------------------------+
| USE MAXFRAME of 1, at most 2 on your transmissions |
| and the TH-D7 will not hang with the "con" "sta" |
| indicators lit anymore. MAXFRAME 3 and up gives |
| problems, at least at 1200 baud |
+----------------------------------------------------+
Uplink:
-------
Sending 250 byte data-frames are no problem. Apparently the TH-D7 has
enough storage capacity to hold the data and the AX.25 header of a
full-size frame. MAXFRAME however is a problem. Sending 1 frame at a
time works reliable. Sending 2 frames at a time doesn't gain much since
they are send as two separate frames anyway. I got a CRC error with
YAPP using 2 frames, but you may get away with it... When sending 3 or
more frames to the TH-D7 in one go then the TNC hangs with the "con"
and "sta" indication burning. I would recommend to use a MAXFRAME of 1
on the TH-D7 in KISS mode.
Downlink:
---------
When using 1200 baud there are no problems with reception. At least 3
consecutive frames with 230 bytes of payload data each works fine (no
digis in the header). With 9600 baud the transmitting station should
send only one information frame at a time since the TH-D7 can only buffer
one frame on reception. If the sender sends more frames then the link
will become very slow due to a lot of retransmissions. Two TH-D7's may
work together however due to the way adjacent frames are transmitted.
But since the TH-D7 is at its best when it uses a MAX-FRAME of 1, this
is not really an advantage.
------------------------------------------------------------------------
------------------------------------------------------------------------
Detailed description:
---------------------
First the good news. You can send binary packets with 250 bytes payload.
Reception works okay too.
I conducted some tests on a connection-oriented link at 1200 baud with our
near-by packet BBS. I used a connection-oriented link to be able to do a
YAPP upload and download. The tools I used for this are TSTHOST 1.43 (dos)
and the TFPCX 2.73 driver. The maximum packet size I used was 250 bytes,
TSTHOST will not accept a higher setting but I bet 256 bytes works fine
since 256 bytes also works on UI frame transmissions.
I put the THD7 in KISS the following way:
------------------------------------------------------------------------
TC 1
TC 0
XFLOW OFF
PACLEN 0
TX 25
KISS ON
RESTART
------------------------------------------------------------------------
(Note: TC is not a TNC command but a THD7 command. TC 1 switches the TNC
off, TC 0 switches it on. This way I know for sure that I have a clean
start! For the "TC 1" command capitals letters are important, otherwise
it doesn't work.)
My BBS is not using DAMA, if it does also insert "PPERSIST OFF" and "DWAIT
0" after the "TX 25" setting. NEVER USE THIS ON NON-DAMA LINKS!
Binary uploading:
-----------------
I have a good link with the BBS and there was nobody else using the same
QRG. I started a YAPP upload of a .ZIP file (actually dnexe030.zip...).
So I tried a MAX-FRAME of 6 (MAX-FRAME of 7 gives problems with some
implementations, that's why I never go beyond 6). The THD7 is not able to
intermediately store 6 frames. Within seconds it hangs with the "con" and
"sta" indication lit in the screen. There is no response from the TNC
anymore, I can however still send the command "TC 1" to switch the TNC off.
The link speed to the radio is 9600 baud while the air interface is only
1200 baud. That's why the THD7 will have to buffer the frames.
I restarted the attempt, this time I set MAX-FRAME to 1. This actually works
without getting a hang-up. I am able to transfer 70 Bytes/second this way
according to TSTHOST's information. 1200 baud equals to 150 Bytes/second but
you have to subtract the RX/TX changeover time and the protocol-overhead,
this is actually not too bad when sending only 1 frame at a time. I used a
TXdelay of 25, which is 250 ms which works reliable on the TH7D.
Now that I know a MAX-FRAME of 1 works I bumped the number of frames up to
see where the limit is. MAX-FRAME of 2 reveals an interesting thing, which I
did not know. The two frames are not transmitted as one block by the TH-D7,
but also 2 consecutive frames; the TH-D7 shortly interrupts the transmission
between the two frames. The BBS receives the frames okay so the TH-D7
apparently inserts also a TXdelay between the frames. The first attempt to
upload the file failed. YAPP aborted with a CRC error. The second time went
better. The transmission speed was a bit higher, 88 Bytes/second.
I went to MAX-FRAME of 3. That was interesting too. First of all I noticed
that the data was not flowing okay anymore. Looking the monitor screen I saw
that the BBS was consistently loosing the 3rd frame. I guess that is because
it was not transmitted all right anymore. After some time I aborted the
upload and low-and-behold, the TNC hang himself with "con" and "sta"
burning.
What I could make of this is that the TH-D7 just buffers 1 complete frame.
The TNC can also hold 1 TX frame. When I use a MAX-FRAME of 1, I hardly see
the "sta" indication. I assume that the KISS frame that just arrived is
passed on to the TNC immediately for transmission. With a MAX-FRAME of 2
this also is okay, 1 frame is in the TNC, the other in the TH-D7 firmware.
An extra RR frame will fit also, but not a complete new I frame. When
overrun the TH-D7 gives up. So never pass more than 2 frames to the TH-D7 in
KISS. I'm guessing now, but I think the reason why the TH-D7 has no problem
in TAPR mode is because of XON/XOFF flow control. In transparent KISS
software flow-control does not work.
I set MAXFRAME back to 1 and uploaded the whole file, 239022 bytes, which
succeeds in one go without a single hiccup (it is a torture for the TH-D7
however, it got really hot since is took almost an hour to complete!). When
I do a "DIR" in the DOSFBB directory then the size matches the original.
This file will now be used for the next test where I retrieve it again using
YAPP.
Binary downloading:
-------------------
With uploading I uploaded a ZIP file of 239022 bytes. Now I try to download
it again using YAPP. This time I don't have much control over the packet
size and the number of packets I am receiving.
The BBS I use sends packets with 230 bytes of payload data and a MAX-FRAME
of 3. I went to the directory where I uploaded my ZIP file and started the
download procedure. This went without problems. Frankly I also did not
expect any problems. There is no buffering problem in the TH-D7 during
download since the KISS link is much faster than the 1200-baud radio link.
There are never more than 2 full packets in the TH-D7: The received packet,
which is currently send to the KISS link and the packet being collected in
the TNC from RF. I got a speed of 97 Bytes/second. I remember similar
figures from the days when I used to have a BayCom modem for up- and
downloading to the FBB-BBS. It looks quite normal to me.
I have noticed before, problems arise when using 9600 baud. In that case the
TH-D7 will only receive the first information frame of a block of I-frames
correctly. When the TH-D7 has only internal storage for 1 frame then this
adds up. With 1200 baud the buffer is cleared before the next frame arrives.
With 9600 baud this is not the case anymore. The 9600 synchronous data-rate
on RF is higher than the asynchronous data-rate on the KISS link. So the
next frame is received before the buffer is cleared and the TH-D7 has to
drop that frame. As noticed above, when sending 2 frames with a TH-D7 the
transmission is shortly interrupted between the two frames. This may buy
enough time to clear the buffer so 2 TH-D7's talking to each other with 9600
baud may work for that reason (and if it is still too fast the Txdelay can
be increased to increase the time between the information frames). When
using another implementation also the transmitter has to restrict its
transmissions to 1 frame at a time. If not the link will become very slow
due to retransmissions.
After I downloaded my ZIP file, which proceeded without any problem, I
compared the downloaded file with the original. A binary compare showed no
difference at all.
There may be a potential killing bit-pattern. Even when the TH-D7 is in KISS
mode you can switch the TNC off by sending "TC 1<CR>" to the TH-D7. If the
TH-D7 follows the KISS specification the "T" character may be implemented as
a special "command byte", in that case there is no problem. If that is not
the case however than an accidental "TC 1<CR>" sequence in the transmitted
data may switch the TNC off. I have not verified this. The chance this
happens is pretty low I think. The ZIP file I uploaded did not contain such
a pattern.
Kind regards,
Henk.
P.S. Copying and publishing this text is hereby permitted, no explicit
permission from me needed (although its nice to hear if it is usefull).
--
#########################################################################
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 SuSE 7.3
Read previous mail | Read next mail
| |
