[DECtalk] Dectalk express

Thu Sep 20 11:20:57 EDT 2007

Ryan,

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.

I still think that a possible workaround would be 
to append a null file to the end of the one you want to transfer.

Dan

At 02:10 PM 9/20/2007 +0100, you wrote:
>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
>*
>*******************************************
>_______________________________________________
>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/921d61f8/attachment.html>