<html>
<body>
Ryan,<br><br>
I know nothing at all about Dectalk Express, so my response to you was
based only on analyzing the symptoms. You may well be right that
the problem lies in how Dectalk Express handles its buffers.<br><br>
I still think that a possible workaround would be to append a null file
to the end of the one you want to transfer.<br><br>
Dan<br><br>
At 02:10 PM 9/20/2007 +0100, you wrote:<br>
<blockquote type=cite class=cite cite=""><font size=2 color="#000080">
I,<br>
<br>
I have used a dos pc and a windows pc to do the copy.<br>
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.<br>
I have a feeling that the problem is the internal buffers or the
circuitry or chips that manage indexing on the dectalk unit.<br>
Ryan<br>
<br>
<hr>
<div align="center"></font></div>
<font face="Tahoma" size=2><b>From:</b> dectalk-bounces@bluegrasspals.com
[<a href="mailto:dectalk-bounces@bluegrasspals.com" eudora="autourl">
mailto:dectalk-bounces@bluegrasspals.com</a>] <b>On Behalf Of </b>Dan
Nordell<br>
<b>Sent:</b> 20 September 2007 13:36<br>
<b>To:</b> DECtalk Discussions<br>
<b>Subject:</b> Re: [DECtalk] Dectalk express<br>
</font><font face="Times New Roman, Times"> <br>
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>
</font><font face="Times New Roman, Times" size=2>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 uk – so if possible, is there anyone in the uk (if the repairs can be
done locally this will minimise breakage of the unit during
posting).<br>
<br>
Thanks<br>
<br>
Ryan Hutchings<br>
</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><br><br>
<font face="Times New Roman, Times">
*******************************************<br>
*<br>
* Daniel E. Nordell, P.E.<br>
* Xcel Energy<br>
* 414 Nicollet Mall<br>
* Minneapolis, MN 55401<br>
* <br>
* Phone: +1 (612) 330-5822<br>
* FAX: +1 (612) 573-4029 (FAX)<br>
* Email: d.nordell@ieee.org<br>
* <br>
*******************************************<br>
</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></blockquote>
<x-sigsep><p></x-sigsep>
*******************************************<br>
*<br>
* Daniel E. Nordell, P.E.<br>
* Xcel Energy<br>
* 414 Nicollet Mall<br>
* Minneapolis, MN 55401<br>
* <br>
* Phone: +1 (612) 330-5822<br>
* FAX: +1 (612) 573-4029 (FAX)<br>
* Email: d.nordell@ieee.org<br>
* <br>
*******************************************<br>
</body>
</html>