[DECtalk] Dectalk express

Ryan Hutchings RyanHornibrook at aol.com
Thu Sep 20 09:10:00 EDT 2007


I,

 

I have used a dos pc and a  windows pc to do the copy.

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.

I have a feeling that the problem is the internal buffers or the circuitry
or chips that manage indexing on the dectalk unit.

Ryan

 

  _____  

From: dectalk-bounces at bluegrasspals.com
[mailto:dectalk-bounces at bluegrasspals.com] On Behalf Of Dan Nordell
Sent: 20 September 2007 13:36
To: DECtalk Discussions
Subject: Re: [DECtalk] Dectalk express

 

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/351a7dbd/attachment.html>


More information about the Dectalk mailing list