Kenwood TS-2000 and Kenwood TH-D7AG KISS mode TNCs
WH
Has anyone successfully used the KISS mode feature of the built in TNC's of
the Kenwood TS-2000 or the THD7AG radios?
I am about to purchase both of these radios and I would like to use them in
a KISS mode configuration to allow the host computers connected to them to
use host software which requires KISS support.
Kenwood tech-support indicated that the TNC's are pretty basic but they are
supposed to support KISS mode. However, in a contradictory statement, they
indicated that it does support KISS but does not support binary transfers. A
standard KISS mode TNC should support binary data due to the data escaping
mechanism in the KISS protocol spec.
Any advice/comments would be hugely appreciated!
-Will
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Rob Janssen
>Kenwood tech-support indicated that the TNC's are pretty basic but they are
>supposed to support KISS mode. However, in a contradictory statement, they
>indicated that it does support KISS but does not support binary transfers. A
>standard KISS mode TNC should support binary data due to the data escaping
>mechanism in the KISS protocol spec.
>Any advice/comments would be hugely appreciated!
I don't own one of these devices, but I do know that Kenwood tech people
are well known for their ignorance about packet radio and the terminology.
So I would not be surprised if they wrote things like that.
There is (was? was this ever fixed?) a bug in the TNC firmware in that the
persistence parameter is misinterpreted. Setting it to 255 means to never
key the transmitter, instead of always keying it immediately.
This causes malfunction in combination with software that tries to do the
channel access on the PC (e.g. DAMA) and tries to help the user by setting
the parameters to "correct" values...
Rob
--
+--------------------------------+--------------------------------------+
| Rob Janssen pe1...@amsat.org | WWW: http://www.knoware.nl/users/rob |
| AMPRnet: r...@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+--------------------------------+--------------------------------------+
Dana H. Myers
Don't forget the "other" serious bug in the D7/D700 TNC; it simply
does not send acks to I-frames without the Poll bit set. Since the
Poll bit is normally only set as a result of a retry, this means that
a D7/D700 connected to anything other than another D/D700 will give
very poor performance, such as when connected to a BBS.
The D7/D700 also *always* sets the Poll bit on I-frames; this means
that one D7/D700 connected to another will give reasonable throughput
but this comes at the expense of channel loading. Further, this bug
forces non-D7/D700 TNCs to respond to every I-frame with an ack, which
reduces channel efficiency.
I wrote Kenwood a letter about this, and included a packet trace with
notes, and have heard nothing but deafening silence from them. I guess
that's what I get for the $700 that I spent for a TM-D700A.
My suspicion is that Kenwood/Tasco focused their development and testing
effort on the APRS capability of the TNC, which does not use connected-
mode AX.25.
Dana K6JQ
da...@dioxine.com
Charles Brabham
"WH" <whr...@hotmail.com> wrote in message
news:3b5c6064$1...@goliath.newsgroups.com...
> Hi All,
>
> Has anyone successfully used the KISS mode feature of the built in TNC's
of
> the Kenwood TS-2000 or the THD7AG radios?
>
Yes, I've seen KISS mode used sucessfully in both radios.
Charles, N5PVL
JJ
> of
> > the Kenwood TS-2000 or the THD7AG radios?
> >
>
> Yes, I've seen KISS mode used sucessfully in both radios.
>
> Charles, N5PVL
Excellent. Have you seen it handle 8-bit binary data using KISS mode?
The KISS protocol itself should handle the data transparency by escaping any
binary char's that match KISS framing char's. And the serial interface is
8N1, which it has to be because the KISS framing chars (0xC0, 0xDB, 0xDC,
0xDD) all have bit 7 on.
However, someone in a prior posting thought that they did not support 8 bit
transfer in KISS mode. The dealer I am trying to purchase these radios
from is currently trying it but he indicated that its not working. I am
thinking it would most likely be a configuration error and not lack of
support of 8 bit KISS transfers. However, before I invest all this money, I
am hoping someone has tried this already. Basically if anyone can confirm
that they did a file transfer or sent an image using KISS or even used
TCP/IP in KISS mode using these two specific radios.
Please let me know.
Best Regards!
Roger Barker
writes
>> > Has anyone successfully used the KISS mode feature of the built in TNC's
>> of
>> > the Kenwood TS-2000 or the THD7AG radios?
>> >
>>
>> Yes, I've seen KISS mode used sucessfully in both radios.
>>
>> Charles, N5PVL
>
>Excellent. Have you seen it handle 8-bit binary data using KISS mode?
>
>The KISS protocol itself should handle the data transparency by escaping any
>binary char's that match KISS framing char's. And the serial interface is
>8N1, which it has to be because the KISS framing chars (0xC0, 0xDB, 0xDC,
>0xDD) all have bit 7 on.
>
>However, someone in a prior posting thought that they did not support 8 bit
>transfer in KISS mode. The dealer I am trying to purchase these radios
>from is currently trying it but he indicated that its not working.
I don't know about the TS-2000, but KISS does work on the latest version
of the TH-D7. It didn't work on the original version. There is a
limitation in that the radio only has a very small buffer size. If you
look in the TH-D7 group on YahooGroups, you'll find some notes about it
from PE1DNN. He also sent the information on the packet network last
month.
--
Roger Barker, G4IDE - ro...@peaksys.co.uk
For UI-View go to - http://www.packetradio.org.uk
For WinPack go to - http://www.peaksys.co.uk
WH
news:5NktdJAf...@peaksys.co.uk...
> of the TH-D7. It didn't work on the original version. There is a
> limitation in that the radio only has a very small buffer size. If you
> look in the TH-D7 group on YahooGroups, you'll find some notes about it
> from PE1DNN. He also sent the information on the packet network last
> month.
Was there any limitations with respect 8bit binary transfers in KISS mode
using the TH-D7? Kenwood support is telling me that don't support
transparent mode and hence no binary transfers. I don't believe them since
the KISS framing characters are 8bits. Unless their KISS firmware is doing
something strange like stripping the high order bit on all the data with in
the KISS frame.
So, have you see/heard anyone not able to send binary data via KISS mode?
Any input would be hugely appreciated!
Thanks in advance!
Roger Barker
<whr...@hotmail.com> writes
>"Roger Barker" <ro...@peaksys.co.uk> wrote in message
>news:5NktdJAf...@peaksys.co.uk...
>> In article <xfC77.54913$Mb7.1...@brie.direct.ca>, JJ <J...@home.com>
>> writes
>>
>> I don't know about the TS-2000, but KISS does work on the latest version
>> of the TH-D7. It didn't work on the original version. There is a
>> limitation in that the radio only has a very small buffer size. If you
>> look in the TH-D7 group on YahooGroups, you'll find some notes about it
>> from PE1DNN. He also sent the information on the packet network last
>> month.
>
>Was there any limitations with respect 8bit binary transfers in KISS mode
>using the TH-D7? Kenwood support is telling me that don't support
>transparent mode and hence no binary transfers.
Transparent mode and KISS mode are entirely different things.
The TH-D7 can't support transparent mode, because it only has XON/XOFF
handshaking. That doesn't mean it can't support KISS mode, because in
KISS mode you don't need any handshaking.
Rob Janssen
>Was there any limitations with respect 8bit binary transfers in KISS mode
>using the TH-D7? Kenwood support is telling me that don't support
>transparent mode and hence no binary transfers. I don't believe them since
>the KISS framing characters are 8bits. Unless their KISS firmware is doing
>something strange like stripping the high order bit on all the data with in
>the KISS frame.
That would have to be a very strange form of stripping, or else the
callsigns in the header, many control bytes, and the commonly used PID of
0xF0 would not survive the transmission either!
WH
>
> The TH-D7 can't support transparent mode, because it only has XON/XOFF
> handshaking. That doesn't mean it can't support KISS mode, because in
> KISS mode you don't need any handshaking.
Thats a good point. I get the feeling that Kenwood was thinking how can
they support raw binary transfers in a "transparent" mode when the only way
they can provide any sort of flow control would be using XON/XOFF since
there is only a 3 conductor interface between the radio and the computer
(TxD, RxD, and GND).
This does raise a good point. Since KISS is a clearly delimited protocol.
They should always be able to differentiate between KISS frame and software
flow control chars (XON/XOFF). But it sounds like they probably don't even
do that.
Therefore, I guess you could get into a situation where the computer sends a
KISS frame and the D7AG, since it can only buffer one frame, is stilling
waiting for an idle period on the channel, and the D7AG would not be able to
tell the host to quench any further KISS frames and the host may send the
next subsequent KISS frame and overwrite the existing frame. That would
not be a good thing.
Comments anyone?
-Will
D. Stussy
Why wouldn't this packet overrun be caught by whichever protocol is being used?
Roger Barker
<whr...@hotmail.com> writes
[snip]
>
>Therefore, I guess you could get into a situation where the computer sends a
>KISS frame and the D7AG, since it can only buffer one frame, is stilling
>waiting for an idle period on the channel, and the D7AG would not be able to
>tell the host to quench any further KISS frames and the host may send the
>next subsequent KISS frame and overwrite the existing frame. That would
>not be a good thing.
Flow control is never used between a PC and a KISS TNC, or at least it
shouldn't be. That's not how the TH-D7 fails to meet the KISS spec, it
fails to meet it because KISS cannot properly be implemented with such a
tiny buffer size. If you read the KISS spec, you'll find this - note the
last sentence:-
"2. Asynchronous Frame Format
-----------------------------
The 'asynchronous packet protocol' spoken between the host and TNC is
very simple, since its only function is to delimit frames. Each frame
is both preceded and followed by a special FEND (Frame End) character,
analogous to an HDLC flag. No CRC or checksum is provided. In addition,
no RS-232C handshaking signals are employed."
And a bit farther down - not the first sentence even if you don't read
the rest:-
"5. Buffer and Packet Size Limits
---------------------------------
One of the things that makes the KISS TNC simple is the deliberate lack
of TNC/host flow control. The host computers run higher level protocol
(typically TCP, but AX.25 in the connected mode also qualifies) that
handles flow control on an end-to-end basis. Ideally, the TNC would
always have more buffer memory than the sum of all the flow control
windows of all of the logical connections using it at that moment. This
would allow for the worst case (i.e., all users sending simultaneously).
In practice, however, many (if not most) user connections are idle for
long periods of time, so buffer memory may be safely 'overbooked'. When
the occasional 'bump' occurs, the TNC must drop the packet gracefully,
i.e., ignore it without crashing or losing packets already queued. The
higher level protocol is expected to recover by 'backing off' and
retransmitting the packet at a later time, just as it does whenever a
packet is lost in the network for any other reason. As long as this
occurs infrequently, the performance degradation is slight; therefore
the TNC should provide as much packet buffering as possible, limited
only by available RAM."
--
Roger Barker, G4IDE - ro...@peaksys.co.uk
For UI-View go to - http://www.packetradio.org.uk
For WinPack go to - http://www.peaksys.co.uk
NOTE - I do NOT wish this message to appear in any format
on the UK packet network.