Kenwood THD7E 144/430 FM Dual Bander Page 1 of 8 ___________________________________________________________________
Back in Summer of 2000 G4APL purchased two Kenwood THD7E 144/430 FM Dual Bander with built in TNC (Terminal Node Controller) Software version was version 2.0 Using this with PaKeT DOS terminal program on a very old laptop that had to load the program off a floppy drive as it did not have hard drive. A great time was had on Packet Radio when the family was on holiday in Cumbria North West England. Gaining access to the local Node and working back to the Surrey Hills using a Mixture of NetRom radio and worm-hole links. Further tests was to use the two hand helds in APRS mode, just to send SMS type message over the 2m band between G4APL and daughter 2E1PAL. The OLD man G4APL fingers are very slow typing messages compared to the speed of 2E1PAL Other tests was to connect the Handheld up to a WIN98 PC running SV2AGW packet engine with the TCP/IP snap-in driving the Hand Held's TNC in Kiss mode. The RF speed being set to 1200bd or 9600bd access the TCP/IP server in Caterham gb7cip.ampr.org. It was found that the TNC kept locking up. Having seen the work by Henk PE1DNN during the early part of 2001 with regards to 'Long UI packet problem in APRS'. Our two THD7e's were sent to Kenwood to have the software upgrade carried out on them. De Paul G4APL --------------------------------------------------------------------------------------------------------------------------------------------------------------

G4APL GB7CIP

25.12.2002
Kenwood THD7E 144/430 FM Dual Bander Page 2 of 8 ___________________________________________________________________
Report on the KISS AX25 THD7 Hand Held Transceiver by Henk de Groot PE1DNN@PI8APD.#GLD.NLD.EU Apeldoorn, The Netherlands, JO32AF NOKIA-ATF2, YAM Modem, Linux SuSE 7.3

August 2002

P.S. Copying and publishing this text is hereby permitted, no explicit permission from me needed (although its nice to hear if it is useful). 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 hang-up 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 total 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 | +--------------------------------------------------------------------------+
Kenwood THD7E 144/430 FM Dual Bander Page 3 of 8 ___________________________________________________________________
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 connectionoriented 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.

Kenwood THD7E 144/430 FM Dual Bander Page 4 of 8 ___________________________________________________________________
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

Kenwood THD7E 144/430 FM Dual Bander Page 5 of 8 ___________________________________________________________________
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 useful). Henk de Groot | Apeldoorn, The Netherlands, JO32AF PE1DNN@PI8APD.#GLD.NLD.EU | NOKIA-ATF2, YAM Modem, Linux SuSE 7.3
Kenwood THD7E 144/430 FM Dual Bander Page 6 of 8 ___________________________________________________________________ Subject: The TH-D7 bugs By Henk de Groot PE1DNN
August 2002 Hello, WARNING: Technical content! Here is more information about the problems I found in the TH -D7. It has been posted before but seeing the discussion here it may be of interest. Kind regards. Henk.
Hello All, I promised a lot of people to report about the latest Kenwood update for the TH-D7E handheld transceiver with built-in TNC. For those who are not aware of it the following. Kenwood has now at least 3 versions of the TH -D7E in the field. The fi rst version, which is usually referred to as v1.0, was the European version of the TH -D7A but was unfortunately lacking some functionality essential for Europe. This was KISS support and DAMA support. The second version, v2.0, fixed this. This second version also corrected some other things like the ability to use 9600 baud in APRS mode - needed for watching DX clusters - and the ability to handle higher precision NMEA position strings, like transmitted by newer eTrex GPSses for example. The third version, which also identifies itself as v2.0, fixed an annoying bug in the second version, known as the "long packet" problem. Kenwood can update existing TH-D7E's, but unfortunately only the TH-D7E v2.0. I know this fix is available in the UK and in Belgium. My unit was send to Belgium via my dealer. A round-trip can be as short as 2 weeks, but for me it was over 8 weeks due to the fact that because of warrantee I had to send it via the dealer. So far I've not heard it was available in Germany, which kind of surprises me. I just got my TH -D7E back and tested some of the known problems. First of all some data about the upgrade itself. From the outside theres no visible difference between this new version and the old v2.0 version. None of the menus are changed and even the TNC start-up message is the same as before the upgrade (same date, same 2Chip version number). To me it seems that the only way to verify if it is new or an old TH -D7E v2.0 is by watching the behaviour with the known bugs of the old v2.0 version.

Problem: Long UI packet problem in APRS Symptom: Decoding packets stopped, Beacon transmission stopped. Cycling the TNC is needed to bring APRS to life again. Report : In the TH-D7E v2.0 this problem occurred on reception of a packet which length, written down in TAPR TNC format, exceeds 195 characters. This was very reproducible. After the upgrade I tried to reproduce the problem. It looks like the Engineers at Kenwood found the weak spot. Even UI frames with 256 bytes of data, the maximum length according to the AX.25 spec, doesn't do any harm anymore! I'm very pleased with this I can tell you!
Kenwood THD7E 144/430 FM Dual Bander Page 7 of 8 ___________________________________________________________________
I let it run for half a day on our heavily loaded LAP QRG, after that torture, which killed the APRS function for sure with the old v2.0, the TH-D7E still ran happily. After I pressed the TNC button once more to enter Packet mode I noticed that it hung up on me, I was not able to send anything. So still something gets messed up after reception of the long packet, but I don't think this is a problem. If TH -D7E is just switched on an then set to Packet there is no problem as far as I could see. Problem: Hang-up in KISS mode after some time of use Symptom: "STA" and "CON" burning on the display, no transmission and reception of packets anymore, no response from the TNC anymore Report : This problem occurred with WinAPRS in KISS mode on the TH-D7E after a few hours. There was however a much quicker way to get this hang-up. That was by using the TH-D7E in KISS with the DIGI_NED digipeater software. Then the hang-up occurred in minutes. This problem still exists. It is however a *lot* better now. It now takes about 30 minutes to have the same problem again, using the digipeater method. So definitely something is improved. Unfortunately its not eliminated however. With the old v2.0 it was possible to regain control by sending the command "TC 1", which switched the TNC off (important, "TC" in capitals). Then with "TC 0" the TNC could be activated again. This method still works with the new v2.0. Problem: PERSIST works the wrong way around Symptom: With PERSIST=255 the TNC never transmits instead of always With PERSIST=0 the TNC always transmits instead of never Report : This is annoying if you use the latest version of TFPCX which, when connected to a DAMA node, programs the PERSIST parameter to 255 to get better DAMA behaviour. The TH -D7E refuses to transmit in that case. This can be verified in terminal mode. Just set PERSIST to 255 and try to transmit something. The transmission will be queued in the TH-D7E. If you then set PERSIST to 0 all the queued data is transmitted. On the new v2.0 this problem still exists. A bypass for those who want to work in DAMA with the latest TFPCX version can switch the PERSIST channel access method off and use the DWAIT method with a time of 0 for direct access. To start KISS use the following commands to do this: cmd: PPERSIST OFF cmd: DWAIT 0 cmd: KISS ON cmd: RESTART WARNING: Only use this with DAMA, not for normal connections! For normal connections you can use this table to find out the correct PERSIST values which depends on the total number of the stations on the channel: nr of users on the channel 1 (only you) TAPR PERSIST 32 THD7E PERSIST 224

The assumption here is that the TH -D7E persist is 256 - PERSIST ----------------------------------------------------------------------------------------Problem: RESptime timer doesn't work Symptom: Slow connection because the TH-D7E doesn't take initiative when the node doesn't send a POLL bit on the last I frame
Kenwood THD7E 144/430 FM Dual Bander Page 8 of 8 ___________________________________________________________________
Report : A lot of protocol stacks used in Western Europe do not send a poll bit on the last transmitted I frame before witching to reception. This makes the gaps between the transmission and the RR ack a bit wider so other stations have a chance to "break-in". The RR response of the receiver is triggered by the internal RES timer instead. In de Kenwood this timer doesn't seem to work. Now the link becomes slow because the TH-D7E waits until the node or BBS polls the TH-D7E due to an elapsed FRACK timer. This has not changed with the new v2.0 version.
Problem: Slow 9600 baud in KISS Symptom: Only 1 frame at the time is handled in KISS at 9600 baud Report : It looks that after reception of 1 frame the TH -D7E is so busy to transmit it to the serial KISS port that the next frame is always missed. As far as I could see this has not changed with the new v2.0 version. In 1200 baud there seems to be no problem in KISS (except for the hang-up problem mentioned above), but that was already the case with the previous v2.0 version.
Summary: As far as I could see the advantage of the upgrade is the ability to sustain long packets in APRS mode, which was, for me at least, the most annoying problem and I am really pleased that Kenwood managed to fix this. Futher more the KISS mode seems to be more stable. Although the other problems still remain, the advantage of this upgrade is worth more than enough to have to part with the TH -D7E for a few weeks. After sending it off I started to realize however how much I missed this nice handheld device, I'm glad it is back now. The upgrade itself was free of change (under warrantee), I only covered the postage from me to my dealer and back. I hope this information was useful for you, and many thanks to Kenwood for listening and fixing the most annoying problem. I am a happy man! Kind regards, Henk. I accidentally found a new small bug. Set the TNC in APRS mode. Press LIST once. Now if you press the PTT the TH-D7E jumps back to the normal screen. If you however do this while rec eiving an APRS message the transmitter goes on and stays on even after release of the PTT button! Pressing the PTT again for a short time stops the transmission. I don't know if the old v2.0 version has this too.