<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PostalCode"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="State"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="City"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="country-region"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:blue;
text-decoration:underline;}
p
{mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:595.3pt 841.9pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-GB link=blue vlink=blue>
<div class=Section1>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'>I,<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'>I have used a dos pc and a windows pc to
do the copy.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'>I don’t know how familiar you are
with dectalk express, but it uses indexing to control its sending and receiving.
The dos copy is valid, it is documented and I have used it with previous dectalk
expresses.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'>I have a feeling that the problem is the
internal buffers or the circuitry or chips that manage indexing on the dectalk
unit.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'>Ryan<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3 face="Times New Roman"><span lang=EN-US style='font-size:12.0pt'>
<hr size=2 width="100%" align=center tabindex=-1>
</span></font></div>
<p class=MsoNormal><b><font size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>
dectalk-bounces@bluegrasspals.com [mailto:dectalk-bounces@bluegrasspals.com] <b><span style='font-weight:bold'>On Behalf Of </span></b>Dan Nordell<br>
<b><span style='font-weight:bold'>Sent:</span></b> 20 September 2007 13:36<br>
<b><span style='font-weight:bold'>To:</span></b> DECtalk Discussions<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [DECtalk] Dectalk
express</span></font><span lang=EN-US><o:p></o:p></span></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size: 12.0pt'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size: 12.0pt'>Ryan,<br>
<br>
You don't say what system you are sending the files FROM nor whether your
problems are new.<br>
<br>
>From the symptoms I don't think you have a problem with the cable. It is
more likely a problem with either the sending or receiving end of the
connection related to how the system buffers data on the way out (sending end)
or on the way in (receiving - DECtalk) end. In order to make such data
transfer more efficient, most systems don't send data immediately but rather
put it into a buffer which is sent only when it is full. The overhead
cost of sending each character individually would bring many computers to their
knees. Similarly, on the receiving end, the data will be put into a
buffer and sent to the receiving program only when the buffer is full.
The problem, of course, comes at the end of the transmission when there is no
more data to be sent, but the last bit is still sitting in the buffer on either
the receiving or sending end. This is often fixed on the sending end by
the sending program "closing" the connection, which is a signal for
the system to "flush" the buffer and send the last little bit.
If you're sending the data by using a DOS copy or screen capture process, the
sending end will not have a "close" mechanism and probably has no
idea that you're done sending data. Likewise, the receiving end (DECtalk
device), if it uses a similar buffering technique, may have no idea that the
end of the data has arrived. Another way in which the sending end
sometimes knows when to flush the buffer is by time. If no additional
data has arrived in, let's say, one second, then the sending end may pretty
safely send the data it has. If more data arrives, it is no problem to
start the process over again, and the overheads in sending only one character
in a whole second are a small fraction of the total time. Similarly, the
receiving end can use a similar strategy to flush it's buffer if there is a
pause in receiving data.<br>
<br>
But your problem is compounded by the fact that you are working with existing
systems and can't control their internal buffer-flushing behavior - unless you
somehow have configuration control over device timeouts, which you might want
to check into. From what you say, I'm guessing that your sending end is
probably some flavor of Windows, which would very likely have buffer and timing
issues because of its complexity.<br>
<br>
The best solution would be to use a "file transfer" program on both
ends of the connection, which will provide both buffer management as well as
error detection and correction. There are a bunch of such programs
available - some free - on the Internet.<br>
<br>
You have already stumbled into a "brute force" technique for dealing
with partially full buffers. That is to send more "garbage"
data at the end of your intended transmission to cause the buffer to finish
sending the "good" data. You could do this a bit more
gracefully by appending to your copy a copy of a "null" (filled with
zeroes or filled with space characters) file or something like that which won't
cause any trouble at the receiving end. That would probably be my
preferred technique if I were faced with the trouble you are experiencing.<br>
<br>
Hope this helps.<br>
<br>
Dan Nordell<br>
<br>
At 11:10 AM 9/20/2007 +0100, you wrote:<br>
<br>
<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face="Times New Roman"><span style='font-size: 10.0pt'>Hi all,<br>
<br>
I am new to the list. I use a dectalk express synth and I am having problems
with the unit. <br>
<br>
I have the following problem with my dectalk.<br>
<br>
When sending files to the dectalk express using the dos copy command, the file
is partially sent to the dectalk express, but then the dectalk suddenly stops<br>
speaking. The only way to get it to continue is to send another file which
causes the dectalk to finish reading the other file and then starts reading<br>
the next file you send. <br>
<br>
It appears to be an indexing problem.<br>
<br>
Also when I use a screen reader such as jaws for dos, when output is sent to
the unit (such as output from the dir command, some of the output is lost
(speech<br>
stops half way through reading the output. <br>
<br>
Could this simply be a fault in the serial cable, or is this a problem with the
internal components of the dectalk unit?<br>
<br>
I have tried upgrading the firmware of the unit, but this did not solve my
problem.<br>
<br>
I have never experienced this problem with previous dectalk expresses.<br>
Is there anyone on the list who knows how to repair these units? I am in the <st1:country-region w:st="on">uk</st1:country-region> – so if possible, is there anyone in
the <st1:country-region w:st="on"><st1:place w:st="on">uk</st1:place></st1:country-region>
(if the repairs can be done locally this will minimise breakage of the unit
during posting).<br>
<br>
Thanks<br>
<br>
Ryan Hutchings<br>
</span></font>_______________________________________________<br>
DECtalk mailing list<br>
DECtalk@bluegrasspals.com<br>
<a href="http://jaybird.no-ip.info/mailman/listinfo/dectalk" eudora=autourl>http://jaybird.no-ip.info/mailman/listinfo/dectalk</a><o:p></o:p></p>
<p></x-sigsep><font size=3 face="Times New Roman"><span style='font-size:12.0pt'><x-sigsep>*******************************************<br>
*<br>
* Daniel E. Nordell, P.E.<br>
* Xcel Energy<br>
* 414 Nicollet Mall<br>
* <st1:place w:st="on"><st1:City w:st="on">Minneapolis</st1:City>, <st1:State w:st="on">MN</st1:State> <st1:PostalCode w:st="on">55401</st1:PostalCode></st1:place><br>
* <br>
* Phone: +1 (612) 330-5822<br>
* FAX: +1 (612) 573-4029 (FAX)<br>
* Email: d.nordell@ieee.org<br>
* <br>
*******************************************<o:p></o:p></span></font></p>
</div>
</body>
</html>