-Anaren boosterpach with Emmoco firmware looks like this over BLE:
+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
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.
projects / pulsecounter.git / blobdiff