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

只看该作者 · 2007-7-3 20:41

对于低频通讯(RS232通讯,红外,低频包括27MHz,433MHz等)来说,当数据量庞大时,务必会造成通讯的缓慢.有时候影响传输和工作效率.

现在我正在开发一个方案,采用38K的红外通讯来传输8个8位的数据(这些数据是通过外部AD采样得到的),来控制几个LAMP灯的亮度,从而达到某种视觉效果,可是在工作中,我发现通讯时,数据量太多,几乎发送一桢数据需要耗时100ms左右,通讯速度太慢,从而使LAMP灯变化效果不好...

请教各位大虾,有没有简单的数据压缩技术(最好为1/4压缩比).
急,急!!
谢谢!!

1万 · 2007-7-3 20:48

只看该作者 · 2007-7-3 21:19

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

1万 · 2007-7-3 21:27

只看该作者 · 2007-7-3 21:36

只看该作者 · 2007-7-4 08:40

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

2万 · 2007-7-4 09:03

4万 · 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

1万 · 2007-7-4 17:47

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

只看该作者 · 2007-7-4 17:55

不是cpu处理造成的……

1万 · 2007-7-4 18:37

我要先提几个问题：
1）要控制几盏灯？
2）每盏灯亮度的控制精度有多高？

假设你有8盏灯，那么传送8个8位的数据意味着每盏灯亮度的控制精度为8位，即每盏灯亮度可以有256级。
---------------
请问你的应用需要这么高的精度吗？
你的灯能够反应这么高的精度吗？或者说人眼能否分辨这么高精度的亮度调节吗？

我怀疑你是否真的需要有这么高的控制精度。所以建议你试一下把亮度控制的级别减少，看看效果如何。
---------------

另一个思路是，第一次传送完整的数值后，以后只传送变化的相对值，如果变化不快的话，这是完全可行的。如变化的相对值控制在+3~-3之间或+7~-7之间，那每盏灯一次只需传送3位或4位。

1万 · 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楼："平常人" 的说法.

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

终身成就奖章

坚毅之洋流

技术领袖奖章

十世金身

永恒之光奖章

精英会员奖章

湍急之河流

技术高手奖章

常驻人口

核心会员奖章

奔腾之江水

技术奇才奖章

欢快之小溪

以坛为家

甘甜之泉水

偶尔光临