-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathNOTES
255 lines (223 loc) · 10.3 KB
/
NOTES
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
Anaren boosterpack with Emmoco firmware looks like this over BLE:
[BC:6A:29:AB:2E:31][LE]> primary
attr handle: 0x0001, end grp handle: 0x000b uuid: 00001800-0000-1000-8000-00805f9b34fb
attr handle: 0x000c, end grp handle: 0x000f uuid: 00001801-0000-1000-8000-00805f9b34fb
attr handle: 0x0010, end grp handle: 0xffff uuid: 0000ffe0-0000-1000-8000-00805f9b34fb
# 1800: Generic Access
[BC:6A:29:AB:2E:31][LE]> characteristics 1 0x0b
# 2a00: Device Name
handle: 0x0002, char properties: 0x02, char value handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb
# 2a01: Appearance
handle: 0x0004, char properties: 0x02, char value handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb
# 2a02: Peripheral Privacy Flag
handle: 0x0006, char properties: 0x02, char value handle: 0x0007, uuid: 00002a02-0000-1000-8000-00805f9b34fb
# 2a03: Reconnection Address
handle: 0x0008, char properties: 0x0a, char value handle: 0x0009, uuid: 00002a03-0000-1000-8000-00805f9b34fb
# 2a04: Peripheral Preferred Connection Parameters
handle: 0x000a, char properties: 0x02, char value handle: 0x000b, uuid: 00002a04-0000-1000-8000-00805f9b34fb
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x01
Characteristic value/descriptor: 00 18
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x02
Characteristic value/descriptor: 02 03 00 00 2a
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x03
Characteristic value/descriptor:
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x04
Characteristic value/descriptor: 02 05 00 01 2a
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x05
Characteristic value/descriptor: 00 00
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x06
Characteristic value/descriptor: 02 07 00 02 2a
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x07
Characteristic value/descriptor: 00
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x08
Characteristic value/descriptor: 0a 09 00 03 2a
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x09
Characteristic value/descriptor: 00 00 00 00 00 00
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x0a
Characteristic value/descriptor: 02 0b 00 04 2a
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x0b
Characteristic value/descriptor: 50 00 a0 00 00 00 e8 03
# 1801: Generic Attribute
[BC:6A:29:AB:2E:31][LE]> characteristics 0x0c 0x0f
handle: 0x000d, char properties: 0x20, char value handle: 0x000e, uuid: 00002a05-0000-1000-8000-00805f9b34fb
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x0c
Characteristic value/descriptor: 01 18
# 2a05: Service Changed (Indicate)
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x0d
Characteristic value/descriptor: 20 0e 00 05 2a
# uint16: Start of Affected Attribute Handle Range
# uint16: End of Affected Attribute Handle Range
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x0e
Error: Characteristic value/descriptor read failed: Attribute can't be read
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x0f
Characteristic value/descriptor: 00 00
[BC:6A:29:AB:2E:31][LE]> characteristics 0x10
handle: 0x0011, char properties: 0x12, char value handle: 0x0012, uuid: 0000ffe1-0000-1000-8000-00805f9b34fb
handle: 0x0014, char properties: 0x12, char value handle: 0x0015, uuid: 0000ffe2-0000-1000-8000-00805f9b34fb
handle: 0x0017, char properties: 0x0c, char value handle: 0x0018, uuid: 0000ffe3-0000-1000-8000-00805f9b34fb
handle: 0x0019, char properties: 0x0c, char value handle: 0x001a, uuid: 0000ffe4-0000-1000-8000-00805f9b34fb
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x10
Characteristic value/descriptor: e0 ff
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x11
Characteristic value/descriptor: 12 12 00 e1 ff
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x12
Error: Characteristic value/descriptor read failed: Request attribute has encountered an unlikely error
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x13
Characteristic value/descriptor:
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x14
Characteristic value/descriptor:
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x15
Characteristic value/descriptor:
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x16
Characteristic value/descriptor:
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x17
Characteristic value/descriptor:
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x18
Error: Characteristic value/descriptor read failed: Attribute can't be read
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x19
Characteristic value/descriptor:
[BC:6A:29:AB:2E:31][LE]> char-read-hnd 0x1a
Error: Characteristic value/descriptor read failed: Attribute can't be read
=============
[BC:6A:29:AB:2E:31][LE]> primary ffe0
Starting handle: 0x0010 Ending handle: 0xffff
[BC:6A:29:AB:2E:31][LE]> characteristics 0x0010 0xffff
handle: 0x0011, char properties: 0x12, char value handle: 0x0012, uuid: 0000ffe1-0000-1000-8000-00805f9b34fb
handle: 0x0014, char properties: 0x12, char value handle: 0x0015, uuid: 0000ffe2-0000-1000-8000-00805f9b34fb
handle: 0x0017, char properties: 0x0c, char value handle: 0x0018, uuid: 0000ffe3-0000-1000-8000-00805f9b34fb
handle: 0x0019, char properties: 0x0c, char value handle: 0x001a, uuid: 0000ffe4-0000-1000-8000-00805f9b34fb
[BC:6A:29:AB:2E:31][LE]> char-desc 0x0010 0xffff
handle: 0x0010, uuid: 00002800-0000-1000-8000-00805f9b34fb * GATT Primary Service Declaration
handle: 0x0011, uuid: 00002803-0000-1000-8000-00805f9b34fb + GATT Characteristic Declaration
handle: 0x0012, uuid: 0000ffe1-0000-1000-8000-00805f9b34fb
handle: 0x0013, uuid: 00002902-0000-1000-8000-00805f9b34fb + Client Characteristic Configuration
handle: 0x0014, uuid: 00002803-0000-1000-8000-00805f9b34fb + GATT Characteristic Declaration
handle: 0x0015, uuid: 0000ffe2-0000-1000-8000-00805f9b34fb
handle: 0x0016, uuid: 00002902-0000-1000-8000-00805f9b34fb + Client Characteristic Configuration
handle: 0x0017, uuid: 00002803-0000-1000-8000-00805f9b34fb + GATT Characteristic Declaration
handle: 0x0018, uuid: 0000ffe3-0000-1000-8000-00805f9b34fb
handle: 0x0019, uuid: 00002803-0000-1000-8000-00805f9b34fb + GATT Characteristic Declaration
handle: 0x001a, uuid: 0000ffe4-0000-1000-8000-00805f9b34fb
========================================================================
After some playing around, the role of the attributes looks like this:
ffe1 [R,I]: Data read
Receives Indicate messages containing variable id in
the first byte, zero in second byte, variable value
in the rest. Maybe variable id is two-byte (LE).
ffe2[R,I]: Operation completion code
After some writes, esp. into uuid ffe3, this characteristic
gets Indicate 32bit long, all zeroes, or with non-zero first
byte. Observed 0x07 and 0x33. Looks like return code from the
operation initiated by write into ffe3.
ffe3[W]: Command(?)
Write of any length, with the first byte 1 or 2 results in
Indicate message on ffe2.
ffe4[W]: Data write(?)
Write seems to affect the Indicate code that arrives in response
to subsequent writes to ffe3.
======================================================================
Hypothesis: command may have similar format to the Em_Message that is
used to communicate between the MCM and EDR.
#define Em_Message_INDSIZE 4
typedef uint8_t Em_Message_Size;
typedef uint8_t Em_Message_Kind;
typedef uint8_t Em_Message_ResId;
typedef uint8_t Em_Message_Chan;
#define Em_Message_NOP 0
#define Em_Message_FETCH 1
#define Em_Message_FETCH_DONE 2
#define Em_Message_STORE 3
#define Em_Message_STORE_DONE 4
#define Em_Message_INDICATOR 5
#define Em_Message_CONNECT 6
#define Em_Message_DISCONNECT 7
#define Em_Message_ECHO 8
#define Em_Message_PAIRING 9
#define Em_Message_PAIRING_DONE 10
#define Em_Message_OFFLINE 11
#define Em_Message_ACCEPT 12
#define Em_Message_START 13
#define Em_Message_ACTIVE_PARAMS 14
typedef struct Em_Message_Header {
uint8_t size;
uint8_t kind;
uint8_t resId;
uint8_t chan;
} Em_Message_Header;
typedef struct Em_App_Message {
uint8_t dummy[3];
uint8_t sot;
struct Em_Message_Header {
uint8_t size;
uint8_t kind;
uint8_t resId;
uint8_t chan;
} hdr;
uint8_t data[20]; /* 4 for Indicator */
} Em_App_Message;
Write ffe3 Ind ffe2
FF -
FE 0D 00 protocolLevel
FD 0D 00 protocolLevel
FC 42 20 79 91 51 01 00 00 Build
FB -
FA bc d0 b8 ea f0 13 c8 32 0b 21 07 09 c0 5c 43 48 0d 00 11 00
F9 04 09
F8 -
F7 -
F6 00
F5 50 55 4c 53 2d 43 4e 54 52
00 -
01 00 00 00 53 - byte changes after reset (EA)
02 00 00 00 53
After write to ffe4 write to ffe3 stops producing results
Hypothesis about a match between Em messagas and wire messages was wrong
=============================================
Other hardware that looks more promising:
NUCLEO-L053R8 (STM32L053R8T6)
http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/LN1847/PF260001
X-NUCLEO-IDB05A1 (SPBTLE-RF)
http://www.st.com/web/catalog/tools/FM146/CL2167/SC2006/LN1988/PF262191
===================
Apparent hardware glitch:
| 2015-12-28 05:48:47 | 95 |
| 2015-12-28 06:19:15 | 96 |
| 2015-12-28 06:22:01 | 97 |
| 2015-12-28 06:24:48 | 98 |
| 2015-12-28 06:27:35 | 99 |
| 2015-12-28 06:30:23 | 100 |
| 2015-12-28 06:33:10 | 101 |
| 2015-12-28 06:35:57 | 102 |
>>
| 2015-12-28 06:56:49 | 103 |
| 2015-12-28 06:56:52 | 104 |
| 2015-12-28 06:56:54 | 105 |
| 2015-12-28 06:56:56 | 106 |
| 2015-12-28 06:56:57 | 107 |
| 2015-12-28 06:56:59 | 108 |
| 2015-12-28 06:57:01 | 109 |
| 2015-12-28 06:57:02 | 110 |
<<
| 2015-12-28 09:34:24 | 111 |
| 2015-12-28 09:35:11 | 112 |
| 2015-12-28 18:53:29 | 113 |
selected eight lines are bogus. Mechanical counter reading is less by
eight than counted by the software. Apparently triggered by high flow
of hot water (still definitely not 500 l/min high!).
2016-02-05:
Created a binary that counts interrupts (and sometimes misses real events)
in the branch 'countjitter'. There is no jitter, actually. Bogus events
where apparently caused by conductive moist on the PCB. They stopped after
the device was enclosed in a plastic box. Before that, they coninsided
with strong flow of hot water that caused high humidity in the room.
Switched back to 'master' branch.
Considering fully autonomous sensor based on cc3200. I want to put the
device in 'hybernation' mode but that requires saving of the state in
the SPI flash. That is only possible by writing a whole file every time
(i.e. up to ~100 times a day). Ugly. But apparently there is no other
way, as long as I want to keep real time clock running. I think that I
have to, for the thing to work properly. Alternative is keeping the
device in LPDS mode, but that consumes almost 300 uA just in standby,
leaving me with no budget for active operations. Their filesystem has
no wear levelling, and no way to append to a preexisting file, I'll have
to rewrite the whole of it every time I go to hybernate.