(出處: http://www.samool.com/delphibbs/379/3797202.htm)
MSComm控件的主要属性及事件
（1）CommPort：设置或返回串行端口号，缺省值1。
（2）Setting：设置或返回串口通信参数，格式为“波特率，奇偶校验位，数据位，
停止位”。例如：MSComm1.Setting:=′9600,n,8,1′
（3）PortOpen：打开或关闭串行端口，格式为：MSComm1.PortOpen:={True|False}
（4）InBufferSize：设置或返回接收缓冲区的大小，缺省值为1024字节。
（5）InBufferCount：返回接收缓冲区内等待读取的字节数，可通过设置该属性为0来
清空接收缓冲区。
（6）RThreshold：该属性为一阀值，它确定当接收缓冲区内的字节个数达到或超过该
值后就产生代码为ComEvReceive的OnComm事件。
（7）SThreshold：该属性为一阀值，它确定当发送缓冲区内的字节个数少于该值后就
产生代码为ComEvSend的OnComm事件。
（8）InputLen：设置或返回接收缓冲区内用Input读入的字节数，设置该属性为0表示
Input读取整个缓冲区的内容。
（9）Input：从接收缓冲区读取一串字符。
（10）OutBufferSize：设置或返回发送缓冲区的大小，缺省值为512字节。
（11）OutBufferCount：返回发送缓冲区内等待发送的字节数，可通过设置该属性为0
来清空缓冲区。
（12）OutPut：向发送缓冲区传送一串字符。
如果在通信过程中发生错误或事件，就会触发OnComm事件，并由CommEvent属性代码反映错误类型，在通信程序的设计中可根据该属性值来执行不同的操作。CommEvent属性值及其含义如下：
（1）ComEvSend：值为1，发送缓冲区的内容少于SThreshold指定的值。
（2）ComEvReceive：值为2，接收缓冲区内字符数达到RThreshold指定的值。
（3）ComEvFrame：值为1004，硬件检测到帧错误。
（4）ComEvRxOver：值为1008，接收缓冲区溢出。
（5）ComEvTxFull：值为1010，发送缓冲区溢出。
（6）ComEvRxParity：值为1009，奇偶校验错误。
（7）ComEvEOF：值为7，接收数据中出现文件尾（ASCII码为26）字符。
2008年7月20日 星期日
Using AT commands to Send and Receive SMS
Tutorial :: Using AT commands to Send and Receive SMS
http://www.control.com.sg/at_commands_sms.aspx#Receiving%20SMS%20using%20using%20AT%20commands
SMS source samples (for GSM phones)
http://www.scampers.org/steve/sms/samples.htm
AT commands for GSM (GB2312)
http://www.cnblogs.com/goodloop/archive/2006/03/03/342282.html
http://www.control.com.sg/at_commands_sms.aspx#Receiving%20SMS%20using%20using%20AT%20commands
SMS source samples (for GSM phones)
http://www.scampers.org/steve/sms/samples.htm
AT commands for GSM (GB2312)
http://www.cnblogs.com/goodloop/archive/2006/03/03/342282.html
2008年7月16日 星期三
How to convert .wav files to .gsm for Asterisk use
[Target]
Convert a .wav file(VIO voice greeting-VP1.wav) to .gsm
[Enviornment]
Ubuntu 7.10
Sound files of Asterisk is put under /var/lib/asterisk/sounds
[Steps]
1. Copy VP1.wav onto Desktop
2. Install sox : ae@Asterisk-PBX:/$sudo apt-get install sox
3. convert file to gsm format :
If your WAV file was in stereo, add the -c1(c one) option to convert to mono, or the output will sound very strange
ae@Asterisk-PBX:/$sox VP1.wav -r 8000 -c1 VP1.gsm resample -ql
4. put the .gsm file into Asterisk sounds folder :
ae@Asterisk-PBX:/$sudo cp VP1.gsm /var/lib/asterisk/sounds/
5. modify extensions.conf to use the new voice prompt
[reference]
http://www.voip-info.org/wiki/view/Convert+WAV+audio+files+for+use+in+Asterisk
Convert a .wav file(VIO voice greeting-VP1.wav) to .gsm
[Enviornment]
Ubuntu 7.10
Sound files of Asterisk is put under /var/lib/asterisk/sounds
[Steps]
1. Copy VP1.wav onto Desktop
2. Install sox : ae@Asterisk-PBX:/$sudo apt-get install sox
3. convert file to gsm format :
If your WAV file was in stereo, add the -c1(c one) option to convert to mono, or the output will sound very strange
ae@Asterisk-PBX:/$sox VP1.wav -r 8000 -c1 VP1.gsm resample -ql
4. put the .gsm file into Asterisk sounds folder :
ae@Asterisk-PBX:/$sudo cp VP1.gsm /var/lib/asterisk/sounds/
5. modify extensions.conf to use the new voice prompt
[reference]
http://www.voip-info.org/wiki/view/Convert+WAV+audio+files+for+use+in+Asterisk
2008年7月15日 星期二
How to Build Live Update Server for Test
如何建立apt-server
1）先switch 到root權限
打開terminal 視窗
ae@ae-desktop2:~$sudo su
會要求輸入密碼，之後字尾會從”$”變成”#”
2）以ubuntuOS為例，首先需安裝apache2，命令如下：
root@ae-desktop2:/home/ae#apt-get install dpkg-dev apache2
3）建立APT目錄：
root@ae-desktop2:/home/ae#mkdir -p /var/www/lexis30/ippbx
4）Copy將被升級的packages到指定目錄：
LiveUpdate 昇級需要的packages，以使用
共5個deb packages
root@ae-desktop2:/home/ae#cp your.deb /var/www/lexis30/ippbx
5）建立packages的連結
root@ae-desktop2:/home/ae#cd /var/www/lexis30
root@ae-desktop2:/var/www/lexis30#dpkg-scanpackages ippbx /dev/null | gzip
會產生一個叫Packages.gz的檔案，因為測試使用，所以需要手動去改變version號，在VIT1/E1上才會抓取並顯示可以更新.
6）手動更新版本號
- 使用ubuntu 6.06時，打以下指令
root@ae-desktop2:/var/www/lexis30#vim Packages.gz
修改裡面的Version:
- 使用ubuntu 7.10時，打以下指令
root@ae-desktop2:/var/www/lexis30#gzip –d Packages.gz
會解出一個Packages的檔
root@ae-desktop2:/var/www/lexis30#vim Packages
修改裡面的Version:
修改完後再輸入以下指令
root@ae-desktop2:/var/www/lexis30#gzip
注意：上一步產生Packages.gz時，如果是使用Ubuntu 7.10，則檔案中會有一行"Depends: "，這行需要刪除，否則會有問題
client端如何更新
以ubuntu為列，修改如下檔：
/etc/apt/source.list 修改為：
deb http://apt-server IP/lexis30 /
2008年7月2日 星期三
RFC2833 DTMF packets
The observed behavior is that the Asterisk unit sends six RTP Event packets for each digit press. The first three packets are typical "start of event" packets. The first of these three has the SDP marker set to True (per RFC 2833). The other two have this marker set to False which is typical. All three of these "start" packets have the event duration set to zero. This is also typical. Basically, these three packets serve as a preamble telling the terminating gateway that a DTMF event is coming. See frames 3633-3635 of the attached capture for an example.
The last three packets of the six are all identical "end of event" packets. Each has the end-of-event bit set which is a different flag than the marker bit used in the first start packet. Each of these "end" packets also provide the total duration of the tone event. The Asterisk behavior observed is the total event duration is always 800 clocks ticks. Clock ticks are in reference to an 8kHz clock. So, 8 clock ticks represent 1 millisecond. And, 800 clock ticks would indicate a 100 ms tone duration. See frames 3636-3638 for examples.
The above behavior seems to indicate that when an Asterisk detects a digit press it calls a routine that always generates the above six packets (three start, three end, volume always 10, and tone duration always 100 ms). Other originating devices (i.e. Cisco) will actually sample the digit press for volume and duration and send event "update" packets (my terminology) between the start and end packets. These update packets increase the event duration throughout the length of the digit press. The samples are usually sent at an interval equivalent to the ptime of the codec (i.e. 20 ms for G.711). However, there's nothing inherently wrong with the 6-packet method used by Asterisk. And, I believe it would be considered to conform to RFC 2833. There is however another problem with the way Asterisk delivers these six packets that's at the heart of the double digit problem.
Let's look at two digit press examples from the capture. One that was interpreted correctly (digit press of a "1") and another that experienced a triple bounce (digit press of a "2").
Frames 3633 through 3638 represent one digit press event of the number "1". This digit played out correctly. Note the sequence numbers of these three frames show they arrived in sequence.
Frame 3633 - seq 56430 - start marker true - end of event false - event duration 0
Frame 3634 - seq 56431 - start marker false - end of event false - event duration 0
Frame 3635 - seq 56432 - start marker false - end of event false - event duration 0
Frame 3636 - seq 56433 - start marker false - end of event true - event duration 800
Frame 3637 - seq 56433 - start marker false - end of event true - event duration 800
Frame 3638 - seq 56433 - start marker false - end of event true - event duration 800
Now look at frames 3741 through 3746 for a single press of the number "2". Note how the frames arrive out of sequence.
Frame 3741 - seq 56485 - start marker true - end of event false - event duration 0
Frame 3742 - seq 56488 - start marker false - end of event true - event duration 800
Frame 3743 - seq 56488 - start marker false - end of event true - event duration 800
Frame 3744 - seq 56486 - start marker false - end of event false - event duration 0
Frame 3745 - seq 56488 - start marker false - end of event true - event duration 800
Frame 3746 - seq 56487 - start marker false - end of event false - event duration 0
The above plays out as a triple press. The first three frames are played out as one tone. The fourth and fifth frames play out a second tone. And the sixth frame starts a third tone. Packets arriving out of sequence like this are the cause of the double and triple digits heard by IVRs on the terminating side.
Examination of the time delta between each of the above frames indicates the Asterisk is sending the 6 packets that represent an RTP event as a single burst. The time differential between the packets is extremely small. It is often sub-10 micro-seconds (that's micro, not milli). Given the nature of latency on the public Internet it's easy to see why packets sent so close together may arrive out of sequence at the other end.
I suggest that you find the Asterisk routine responsible for generating the 6-packet RTP event and insert some "sleep" time between each of the six packets to space them out better. Or perhaps, insert just one sleep cycle between the three "start" packets and the three "end" packets. I think the latter is a better suggestion. I believe a 20 ms sleep cycle (the typical ptime for G.711 and G.729) between the three start packets and the three end packets should be enough to compensate for IP jitter in transport. However, you can experiment with different values to see what makes DTMF transport most reliable."
The last three packets of the six are all identical "end of event" packets. Each has the end-of-event bit set which is a different flag than the marker bit used in the first start packet. Each of these "end" packets also provide the total duration of the tone event. The Asterisk behavior observed is the total event duration is always 800 clocks ticks. Clock ticks are in reference to an 8kHz clock. So, 8 clock ticks represent 1 millisecond. And, 800 clock ticks would indicate a 100 ms tone duration. See frames 3636-3638 for examples.
The above behavior seems to indicate that when an Asterisk detects a digit press it calls a routine that always generates the above six packets (three start, three end, volume always 10, and tone duration always 100 ms). Other originating devices (i.e. Cisco) will actually sample the digit press for volume and duration and send event "update" packets (my terminology) between the start and end packets. These update packets increase the event duration throughout the length of the digit press. The samples are usually sent at an interval equivalent to the ptime of the codec (i.e. 20 ms for G.711). However, there's nothing inherently wrong with the 6-packet method used by Asterisk. And, I believe it would be considered to conform to RFC 2833. There is however another problem with the way Asterisk delivers these six packets that's at the heart of the double digit problem.
Let's look at two digit press examples from the capture. One that was interpreted correctly (digit press of a "1") and another that experienced a triple bounce (digit press of a "2").
Frames 3633 through 3638 represent one digit press event of the number "1". This digit played out correctly. Note the sequence numbers of these three frames show they arrived in sequence.
Frame 3633 - seq 56430 - start marker true - end of event false - event duration 0
Frame 3634 - seq 56431 - start marker false - end of event false - event duration 0
Frame 3635 - seq 56432 - start marker false - end of event false - event duration 0
Frame 3636 - seq 56433 - start marker false - end of event true - event duration 800
Frame 3637 - seq 56433 - start marker false - end of event true - event duration 800
Frame 3638 - seq 56433 - start marker false - end of event true - event duration 800
Now look at frames 3741 through 3746 for a single press of the number "2". Note how the frames arrive out of sequence.
Frame 3741 - seq 56485 - start marker true - end of event false - event duration 0
Frame 3742 - seq 56488 - start marker false - end of event true - event duration 800
Frame 3743 - seq 56488 - start marker false - end of event true - event duration 800
Frame 3744 - seq 56486 - start marker false - end of event false - event duration 0
Frame 3745 - seq 56488 - start marker false - end of event true - event duration 800
Frame 3746 - seq 56487 - start marker false - end of event false - event duration 0
The above plays out as a triple press. The first three frames are played out as one tone. The fourth and fifth frames play out a second tone. And the sixth frame starts a third tone. Packets arriving out of sequence like this are the cause of the double and triple digits heard by IVRs on the terminating side.
Examination of the time delta between each of the above frames indicates the Asterisk is sending the 6 packets that represent an RTP event as a single burst. The time differential between the packets is extremely small. It is often sub-10 micro-seconds (that's micro, not milli). Given the nature of latency on the public Internet it's easy to see why packets sent so close together may arrive out of sequence at the other end.
I suggest that you find the Asterisk routine responsible for generating the 6-packet RTP event and insert some "sleep" time between each of the six packets to space them out better. Or perhaps, insert just one sleep cycle between the three "start" packets and the three "end" packets. I think the latter is a better suggestion. I believe a 20 ms sleep cycle (the typical ptime for G.711 and G.729) between the three start packets and the three end packets should be enough to compensate for IP jitter in transport. However, you can experiment with different values to see what makes DTMF transport most reliable."
2008年7月1日 星期二
VISIP DTMF debug
screen resolution problem in ubuntu 6.06
1. Ctrl &Alt&F1
2. sudo dpkg-reconfigure xserver-xorg
3. In case it doesn't work:
sudo lspci grep -i vga
grep -i driver /etc/X11/xorg.conf
訂閱：
文章 (Atom)
發表文章
