hyperterminal

[Ray.R]

No...no..  It's all good.  I guess the smilies didn't do the trick.

How is your progress so far?

[tapullino]

ok sorry..

I found this.http://forums.ni.com/t5/LabVIEW/AT-commands-for-a-voice-modem/m-p/85060/highlight/true#M52199

I think the right way

[djacob]

me too refered that link earlier.but was unable to solve the problem

[Ray.R]

Can you describe what is not working?

Or how closer / far from your solution it brings you?

[djacob]

the problems arises during serial write of the voice clip in .wav format to the COM port corresponding to the modem.what i did was converted the .wav file into an array and then write it serially to COM port using VISA.due to this i think i'm dropping some packets or something like that due to buffer size or some other problem.as i have already mentioned iam able to hear the voice message on my phone when vi is executed,but not the entire message.i could hear it only for about 10 secs.rest is lost.
Does anyone have idea about how to write a .wav file through COM/serial port.one of my friend over here suggested that i should write it a rate of 1024 bits/s.but i don't know how to do this.
if you wish to see my vi, i can post snapshot over here

[tapullino]

I think it's a problem of buffer.

Transmitting audio data

To begin transmitting audio data, the host sends the command AT+VTX or AT#VTX. This results in a response from the modem of CONNECT or VCON. (Modems using the "plus" command set usually respond CONNECT, while those using the "hash" set respond VCON, which stands for voice connect).

From then on, the modem interprets any data sent from the computer as wave audio data, using the codec selected by the AT+VSM or AT#VSM command.

The audio data is always sent to the modem slightly faster than it can play it, so the modem may buffer a small portion of it and play it smoothly with no clicks or pops caused by delays in the computer's operating system. For example, during playback of an 8 kHz audio file at 8-bit resolution (which creates 8,000 bytes, or 80,000 bits when including start/stop bits, per second), the data must travel over the serial port at a minimum of 115,200 bits per second. (115,200 bit/s is the first setting of a typical computer serial port that's greater than 80,000). In addition, due to some extra overhead involved in doubling DLE bytes in the stream (mentioned below), a small amount of extra bandwidth is mandatory to allow for this.

When the modem wants the computer to temporarily pause so the playback can catch up, it temporarily lowers the CTS (Clear to Send) signal on the RS232 serial port. The modem re-raises the signal in time for the computer to resume sending audio data before the playback buffer becomes completely empty.

When the computer wants to signal the end of audio data, most modems expect to see an ASCII DLE character (0x10), followed by the ! character.

Because the DLE byte can and often does occur in normal audio data, it must be sent twice to the modem when it is to be interpreted as a byte of audio data.

Most modems also accept a sequence of DLE + CAN (cancel) as a signal to cancel audio playback. The distinction is that the modem is to understand that it is to immediately abort playback now, rather than let remaining data in the playback buffer run to completion.

When the modem is done playback, it responds OK.

please insert VI snapshot

[djacob]

thanks tapullino.
i will be uploading the snapshots today itself

[djacob]

please refer the attached pdf for details on how i made the vi

[Ray.R]

djacob,

Are you initializing your serial port to use flow control? as tapullino suggested..

In the attached pdf, I did not see the portion of code which initializes the serial port.

 

[djacob]

oh ,i will check that