终于有空继续做了一些研究,下面是对老的那篇分析的更新。
在做出任何分析之前,我先提供下本文章所用到的原始文件:
描述 | 下载 |
---|---|
Periodic Beacon | hb.csv |
ESL Init | init.csv |
Download (AT 0.0s) | dl-0.csv |
Download (AT 7.17128s) | dl-1.csv |
Download (AT 21.7058s) | dl-2.csv |
Download (AT 28.6028s) | dl-3.csv |
Download (AT 38.8901s) | dl-4.csv |
上一篇文章提及了,ESL 的唤醒包长度为 2 bytes,从观测官方基站通信行为来看,基站会不停的发射唤醒包(数据不停的变化),大约持续发射 12s 左右。下图对比了两次唤醒包。
从上图看出,两次唤醒包的数据分别为 0xA5A8 和 0xA81D 。然后唤醒包后紧跟的正式唤醒时间分别是 7.17128s 和 10.2873s 。由此看出,唤醒包数据很有可能是计数器或者是时间。
假设忽略开头的 A ,0x5A8 就是 1448 , 0x81D 就是 2077 。都除以 200 得出 7.24 和 10.385 。接收到唤醒包到正式唤醒的时间差是 7.17128 和 10.2873 。仅从这两个包的情况来看,误差很小,很有可能是正确的,当然还需要更多样本进行确认。
根据新的资料, Beacon 包的格式可能可以多解析一项, byte 1 ,为标签硬件型号。
更新后的 Beacon 格式如下:
Bytes | Example 1 | Example 2 | Function |
---|---|---|---|
0 | C0 | 0C | UNKNOWN |
1 | 40 | 40 | ESL TYPE |
2 | 50 | 50 | RECEIVER ID BYTE 1 |
3 | 41 | 41 | RECEIVER ID BYTE 2 |
4 | 83 | 81 | RECEIVER ID BYTE 3 |
5 | 66 | 66 | RECEIVER ID BYTE 4 |
6 | 53 | 50 | ESL ID BYTE 1 |
7 | A4 | C4 | ESL ID BYTE 2 |
8 | FE | 23 | ESL ID BYTE 3 |
9 | 0A | 0B | ESL ID BYTE 4 |
10 | A1 | A1 | CHANNEL ID |
11 | 22 | 31 | UNKNOWN |
12 | 1E | 21 | VOLTAGE |
13 | 00 | 00 | UNKNOWN |
14 | BA | 61 | CRC-16/XMODEM LOW BYTE |
15 | A3 | 49 | CRC-16/XMODEM HIGH BYTE |
ESL Type 0x40 代表的应该是 Stellar-M 黑白屏幕, MSP430, A7106 的硬件。其他型号的硬件编号待整理。