该信号使用什么编码？

我有一个便宜的无线泳池温度计（AcuRite 617 1），我想在接收器处截取温度数据，并将其与计算机数据记录系统一起使用。

方便的是，在接收器内部是一个小的分线板，该分线板连接到天线并具有数字“ V”，“ G”，“ D”和“ SH”引脚：

这是传输期间从“ D”引脚捕获的数据片段（这些片段每分钟发生一次）。在此部分之前，似乎有更高速率的数据，但我相信可能是噪声-这是1.36kHz / 680Hz数据的开始。

我已经在Google上搜索了一下，找不到看起来像这样的编码，但是如果我想知道正在发生什么，这就是我的想法：

• 最初的680 Hz的4个周期用于同步时钟，但不包含任何数据
• 随后出现的13个周期为1.36 kHz（初始速率的2倍）的周期似乎具有以下两种形式之一：它们要么在周期中点之前下降，要么在周期中点之后下降-我认为一种形式是合乎逻辑的，而另一种形式是合乎逻辑的是零。
• 之后，似乎会有一个奇怪的间隙，但是如果您减去前面的“ 1”部分的低位部分，则剩余间隙为735 µs，这是相位的（相位校正！）的延续。 680 Hz前同步码。

我看的正确吗？此编码有名称吗？

突破板上的其他注意事项：

• 该板标记为“ RF211”，并且看起来与MICRF211“工作在433.92MHz的通用3V QwikRadio接收器”保持一致3
• MICRF211数据表具有下图（几乎没有解释），与我所捕获的相比，除了双倍数据速率方波外，它看起来与我所看到的非常相似：
  

2016-02-14更新：我已经重新访问了该项目，并且似乎在4周期前同步码和1周期“后同步码”之间获得了干净的64位流，此后显示板通过以下方式关闭了RF模块：将^ SH拉低（顶行）：

根据麦瑞（Micrel）的“ 33/66％PWM”方案（在Google上没有其他地方显示），这就是

-_-_-_-_0000011110011000110000000000000000000000100011101000010010101010-_

所以现在我必须开始控制温度以解码这些位。以下（“ x”）是似乎在显示中没有明显变化的位：

0000011110011000110000000000000000000000100011101000010010101010
------------------------------------------------x----xxxx----xxx

我假设这些位是最低有效位或电池电量（当电池电量严重下降时仅显示为“低”）。

2016年2月15日更新：我正在路上进行演示，以使新的“逆向工程” stackexchange能够确定其含义：https : //reverseengineering.stackexchange.com/questions/12048/what-is-contained在此传输RF池温度传感器基本单元中

麦克雷尔将其称为33/66％PWM方案。它似乎是一个非常简单但临时的协议。

PWM代表脉宽调制。Wikipedia页面上有更详细的说明，但简而言之，PWM是您保持固定时间段的位置，因此这里是从上升沿到下一个上升沿的时间，但是您会花大量时间在高点上通过改变下降沿的发生时间来改变状态。对于这个，您可以看到“ 1”的高33％，“ 0”的高66％。

初始脉冲序列等于高电平和低电平时间。通常这样做是为了让接收器在接收实际数据之前同步。

请参阅http://www.micrel.com/_PDF/App-Notes/an-22.pdf，以获取有关模块期望内容的更多详细信息。

能够接收这种编码的典型方法是将其输入到微控制器的定时器输入捕捉引脚中。或者，您可以简单地连接到通用输入，并以4-5倍的PWM周期对其进行采样。从那里开始，解码算法并不难。

或者，根据市场建议，您可以返回温度传感器本身。但是，如果它是模拟输出信号，则必须自己将其转换为数字信号，并且日志记录中的数字可能与原始输出略有不同。

我认识的人通常将这种编码技术称为“ PWM”，我认为这是一个合理的描述。

我首先想到的是查看您的数据流，并假设您正确地猜测了位的极性，那就是它是一个12位ADC读数，LSB在前，起始位为“ 1”。我首先使用LSB，因为大概是下一个读数的开始显示一个单位的变化，并且ADC（池）温度的读数不太可能在短时间内变化第二或第三MSB。

我将进一步深入系统，回到生成数据的任何内容（而不是传输数据），看看是否可以识别温度传感器，并在传输的数据和温度之间寻找某种关联。

几乎所有的RF传输方案在其数据编码协议中都将需要具有一些特性。其中包括：

1. 一致的格式前导码，用于将接收机锁定在频率上
2. 同步脉冲指示器，用于在帧指示时标记开始
3. 一种使用某种编码时钟对数据1和0进行编码以恢复数据的方法。

您记下的奇数球脉冲肯定是同步脉冲指示器。

数据编码似乎遵循我所看到的所谓的脉冲宽度编码。这是一种相当普遍的技术，其中一个过渡方向遵循一个恒定频率，导致恒定宽度的位单元时间。在位单元期间，活动脉冲表示为位单元时间的25％或位单元时间的75％。该方案不是像曼彻斯特编码所提供的脉冲到脉冲DC平衡编码方案。这是一种常见的脉冲宽度编码技术，通过发送额外的位来在整个消息中创建总体平衡，从而在消息协议内提供DC平衡。以最简单的形式，数据发送两次，第二个副本在逻辑上相反。

在您的示例中，很奇怪地看到在同步脉冲之前出现了脉宽调制数据。但是，如果将数据解码算法设计为在此位置接收具有同步的接收数据，这仍然是可行的方案。本机可能在同步之前发送一种类型的数据，而在之后发送一种类型的数据。拆分可以在传感器地址/温度数据或真实数据/反相数据之间进行。

编辑：

有趣的是，几乎看起来发射机单元正在使用不同的软件算法来为同步模式之前的数据单元和同步模式之后以及之后的脉冲宽度制定正脉冲宽度。这意味着可能会有单独的软件块来生成比该模式的后续部分要早的模式。模式的这种差异可能意味着在每种情况下，数据源在如何逐位访问方面都需要不同的处理方式。在时序图中看到的差异可能只是指令时序或模式生成循环中的两个差异。

我已经开始解码Acurite 617，这是我的初步观察。我可以告诉你，最后一个字节是某种“校验”字节，最后三个字节之后的第二个字节包含温度。还使用第7位发送这些字节以进行偶校验，并且仅使用每个字节的低半字节。我编写了一个Arduino程序来捕获数据，并看到以下消息/温度。

40 ce c0 00 00 0c 03是
（00 0C 03）=> 0C3 => 67F

40 ce c0 00 00 0c 84 39
（00 0C 04）=> 0C4 => 67F

40 ce c0 00 00 0c 05 b8
（00 0C 05）=> 0C5 => 67F

我看到的其他数据/温度是：

E2 => 73F

F5 => 76F

108 => 80F（81 00 88）

109 => 80F

使用此方法，您应该能够进行“直线”（假设）转换。

由于我的范围不大（而且数据每分钟发送一次）因此我不确定我的时间安排。我看到同步HI和LO为720微秒，数据位为240和480微秒。

希望以后会有更多信息。我有一堆。一旦它们开始泄漏，我便将它们从水池中取出并晾干，以便在房屋周围使用。后来的617个模块（拧下底部螺丝和O形圈）的使用寿命似乎更长。

我做了一些解码。最后一个字节（校验字节）使所有八个字节的XOR等于0FFH。例如，对于“ 40 CE C0 00 00 8D 0C 30”，40 xor CE xor C0 xor 00 xor 00 xor 8D xor 0C xor 30等于0FF。

另外，我将温度降至34F，计数为10十进制（即00 00 0A），在80F时为264十进制（即81 00 88或108H）。

由此，我正在使用Temp（F）= 0.1811 * Count + 32.1889。如果看到任何错误，我可能会获得更大的跨度以获得更好的数据。

在2016年2月14日看Rob Starling的字符串：

00000111/10011000/11000000/00000000/00000000/10001110/10000100/10101010 07 98 C0 00 00 8E 84 AA

XOR = FF

计数= 0E4或228

温度= 73.5F