想探询一下简单的压缩码技术

发表于 2007-7-3 20:41

对于低频通讯(RS232通讯,红外,低频包括27MHz,433MHz等)来说,当数据量庞大时,务必会造成通讯的缓慢.有时候影响传输和工作效率. 现在我正在开发一个方案,采用38K的红外通讯来传输8个8位的数据(这些数据是通过外部AD采样得到的),来控制几个LAMP灯的亮度,从而达到某种视觉效果,可是在工作中,我发现通讯时,数据量太多,几乎发送一桢数据需要耗时100ms左右,通讯速度太慢,从而使LAMP灯变化效果不好... 请教各位大虾,有没有简单的数据压缩技术(最好为1/4压缩比). 急,急!! 谢谢!!

发表于 2007-7-3 20:48

发表于 2007-7-3 21:19

一桢数据有100多毫秒,客户要求采用38KHz的红外载波,距离要求12米左右; 我采用了数字编码发送,数据1为600us载波信号和600us的低电平信号; 数据0为600us的载波信号和1200us的低电平信号,总共发送68位数据...... 是比较多的,所以想到压缩方式........

发表于 2007-7-3 21:27

发表于 2007-7-3 21:36

发表于 2007-7-4 08:40

应该应用不上吧........

发表于 2007-7-4 09:03

发表于 2007-7-4 10:44

看看你的数据是否有规律，这是决定压缩程度的唯一条件，数据量过低是无法压缩的。

发表于 2007-7-4 17:21

发表于 2007-7-4 17:24

1。改变码的宽度，将码的宽度缩小 2。改变码的结构，数据0用600us的载波，数据1用600us的低电平

发表于 2007-7-4 17:32

发表于 2007-7-4 17:47

这样会节约出大量的时间，给你显示是没有问题的。

发表于 2007-7-4 17:55

不是cpu处理造成的……

发表于 2007-7-4 18:37

我要先提几个问题： 1）要控制几盏灯？ 2）每盏灯亮度的控制精度有多高？ 假设你有8盏灯，那么传送8个8位的数据意味着每盏灯亮度的控制精度为8位，即每盏灯亮度可以有256级。 --------------- 请问你的应用需要这么高的精度吗？ 你的灯能够反应这么高的精度吗？或者说人眼能否分辨这么高精度的亮度调节吗？ 我怀疑你是否真的需要有这么高的控制精度。所以建议你试一下把亮度控制的级别减少，看看效果如何。 --------------- 另一个思路是，第一次传送完整的数值后，以后只传送变化的相对值，如果变化不快的话，这是完全可行的。如变化的相对值控制在+3~-3之间或+7~-7之间，那每盏灯一次只需传送3位或4位。

发表于 2007-7-4 19:04

就是因为他自己搞的通讯协议，所以要解析波形的，这样会占用大量的MCU处理时间，如果使用232以及中断方式就会把这个时间转让给其他的用途。

发表于 2007-7-4 20:04

信号就那么一个一个慢慢的传过来的，现在的问题是波特率慢啊

发表于 2007-7-5 09:01

最终是要lamp的高度变化的效果好，也许可以换个角度，改变LAMP的亮度方法上想一想

发表于 2007-7-5 10:49

发表于 2007-7-5 11:48

相信我没错的，红外遥控我敢说我很专。 很多欧洲版的红外遥控用曼码和密勒码。

发表于 2011-9-28 17:46

都是高手,顶

想探询一下简单的压缩码技术

相关帖子

1桢有多大？38K做载波也太小了

谢谢

这个的速度也太慢了，平均下来也就700-800个BPS

用曼彻斯特码或密勒码！

红外用曼彻斯特码或密勒码???

必须改载波频率，改编码没太大作用的

数据压缩是靠数据间的关联性实现的

有

试一下下面的方法

用差分码，如果有长期规律，就做预测差分码

用232协议就行，协议低层MCU自己管理就行，接收用中断方式

to 楼上，楼主的问题是时间不够是波特率太慢造成的

关于“简单的压缩码技术”，楼主的问题应该从应用本身找

TO 14L

to楼上，就是把cpu时间放出来，也是没用的

re

同意 15楼："平常人" 的说法.

曼彻斯特码和密勒码在红外遥控里允许较高的波特率。

浏览过的版块

终身成就奖章

坚毅之洋流

技术领袖奖章

十世金身

永恒之光奖章

精英会员奖章

湍急之河流

技术高手奖章

常驻人口

核心会员奖章

奔腾之江水

技术奇才奖章

欢快之小溪

以坛为家

甘甜之泉水

偶尔光临