[DECtalk] Dectalk express

[Dan Nordell]

Ryan,

You don't say what system you are sending the 
files FROM nor whether your problems are new.

 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.

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.

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.

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.

Hope this helps.

Dan Nordell

At 11:10 AM 9/20/2007 +0100, you wrote:
>Hi all,
>
>I am new to the list. I use a dectalk express 
>synth and I am having problems with the unit.
>
>I have the following problem with my dectalk.
>
>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
>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
>the next file you send.
>
>It appears to be an indexing problem.
>
>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
>stops half way through reading the output.
>
>Could this simply be a fault in the serial 
>cable, or is this a problem with the internal components of the dectalk unit?
>
>I have tried upgrading the firmware of the unit, 
>but this did not solve my problem.
>
>I have never experienced this problem with previous dectalk expresses.
>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).
>
>Thanks
>
>Ryan Hutchings
>_______________________________________________
>DECtalk mailing list
>DECtalk at bluegrasspals.com
>http://jaybird.no-ip.info/mailman/listinfo/dectalk

*******************************************
*
* Daniel E. Nordell, P.E.
* Xcel Energy
* 414 Nicollet Mall
* Minneapolis, MN 55401
*
* Phone:   +1 (612) 330-5822
* FAX:      +1 (612) 573-4029 (FAX)
* Email:   d.nordell at ieee.org
*
*******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://bluegrasspals.com/pipermail/dectalk/attachments/20070920/3504bd5a/attachment.html>