https://web.archive.org/web/20151018021202/https://kypn.wordpress.com/category/d710-radio/ -- RMS Express with the Kenwood D710 Radios September 30, 2015 UPDATE October 2015: From looking at the KISS spec there is no flow control in the spec. Thus KISS mode TNCs need to have more than adequate buffer sizes and/or your higher level software better be able to keep from overflowing the transmit buffers! While the Kenwood TH-D72 and TM-D710 internal TNCs have better buffer sizes than their predecessors, it looks like it is still easy to overrun them if you run the serial port too fast or try jamming too many large frames at them when used in KISS mode. Original posting follows….. Seeing reports that some folks using RMS Express (RMSE) with the D710’s internal TNC are having what looks like buffering/flow control issues when trying to send large messages. This is a typical response back from the Gateway when this happens: Error check failed on receiving B2 message. [Check sum failure – failed to assemble correct binary image] – Disconnecting I looked into it some and “may” do more when time allows, but this is not a priority here since KYPN does not use RMS Express for VHF/UHF access to our BBS system. Used some at times for HF Robust Packet access with SCS Tracker modems, but that’s a whole different animal. This problem appears to be related to RMSE is using KISS to talk to the D710’s internal TNC, a weaker than normal KISS implementation in the D710 (buffer memory size probably needs to be larger), and RMS Express presenting overly aggressive TNC defaults to users. This is not an issue for applications that do not use KISS mode to talk to the TNC. The D710’s non-KISS mode flow control has been tested and it functions appropriately. One example is Outpost PMM software that works reliably with the D710’s (and D72 HTs) internal TNC. The problem is triggered with RMSE since it defaults to some poor values for a packet link regardless of TNC used and I suspect the D710 TNC specific code in RMSE could use a few tweaks itself. Sorry, but it is real hard to think of a real packet network where many of these values would be appropriate. RMS Express, fresh install default packet values. Sorry, but I’m unable to think of a real packet network where many of these values would be appropriate. Click for larger view if needed. In fairness, during first time TNC setup RMSE warns you with a popup box about using aggressive TNC/link parameters with the internal TNC in the Kenwood D72/D7xx series radios. You might want to pay some heed to that warning box! With the D710 you can resolve this issue by: 1. As you setup the D710 TNC parameters in RMSE, use more saner/appropriate link values. 2. Set the D710’s COM port speed down to 9600 baud via Menu #528, adjust COM port speed in RMSE to match, and power cycle the radio so the changes will take effect. The above will help you be a more considerate user of a shared packet channel. You may also experience more reliable links on low SNR connections. Note that there is no practical benefit to running the TM-D710’s COM port any faster than 9600 baud. Also note that this has no impact on the PC programming port speed which is controlled by Menu #519. Common for folks to think they are the same or mix up the functions of those two menu items. TIP: Buffering issues generally don’t show themselves till you are sending large messages out. This is due to a 9600 baud serial port is going to flow data into the TNC faster than the RF layer can send it out. Small messages may never overflow buffers and trigger errors. On receive it rarely shows up as the serial flows have no trouble keeping up with the slower incoming RF flows. Please don’t email me wanting what exact values you should be using in the RMS Express packet TNC setup screen. Nothing personal, but I’m going to hit delete and move on. Why? Well three reasons: 1. Every packet network is different. You should check with your local sysop(s) as to what are good values for your particular area and network. This has long been a ‘best practice” on packet radio. 2. Your TNC’s manual and Google are your friends. There is plenty of reference material out there. 3. To be a good packet operator you really need to learn the impact of key values like Frack, Paclen, MaxFrame, Persist, and SlotTime. It’s very helpful to understand how to tweak some of those settings for varying link/channel conditions. Others need to be set to your local network’s standard values and left the heck alone. Just handing you “plug these in” values will not help you learn what you need to learn. This is especially true for EmComm packet radio operators that are likely to find themselves out operating in less than optimal and congested packet channel conditions. This is a good example as to why you really need to stress test your particular packet setup by BOTH sending and receiving several large messages with it. Most buffering related issues don’t show up till you start pushing a few KB out across the link. Test your particular setup by sending and receiving messages that cause the TNC to handle at least 10kb of data over the serial port. Keep in mind that RMSE compresses the message so you will need to start with at least 20kb of content to get a good test message size. A little LOL warning: This is also a good way to test if your radio’s heatsinking/cooling is up to the task of serious usage at full power levels (it’s probably not). You might also wish to check with your local gateway’s sysop to ensure he hasn’t set himself up to have a radio meltdown when someone finally stress tests his radio gear, grin. Yeah it is very telling that it has taken so long for this particular issue to be noticed within the Winlink crowd. It does vindicate my long stated opinion that many in the Winlink crowd are not properly stress testing their setups. Makes one wonder how many of them are in for some ugly surprises when they start having to handle large messages or high messaging loads with a system they have never properly stress tested? WA4ZKO © WA4ZKO and The Kentucky Packet Network (KYPN) Blog, 2008-2015. You may reuse content found here ONLY if full and clear credit is given to the author, a link to the original content is provided, and you do not alter the content. Fair enough? --