Merge pull request #7 from kienvo/master
BadgeBLE: add description of uploading behavior
This commit is contained in:
32
BadgeBLE.md
32
BadgeBLE.md
@@ -13,20 +13,26 @@ The characteristic accepts 16 byte long data packets.
|
||||
|
||||
The badge supports up to 8 bitmaps which can have various features enabled.
|
||||
|
||||
| format | data | description |
|
||||
| --------- | --------- | ------------ |
|
||||
| uint8[6] | header | fixed header: "wang\0\0" |
|
||||
| uint8 | flash | bitfield describing which of the 8 bitmaps are flashing |
|
||||
| uint8 | marquee | bitfield describing which of the 8 bitmaps feature an animated border |
|
||||
| uint8[8] | modes | speed+mode for each of the 8 bitmaps. See below. |
|
||||
| uint16[8] | sizes | count of 8 pixel wide chunks for each bitmap (Big endian) |
|
||||
| uint8[6] | padding | 6 bytes zeroes of padding
|
||||
| uint8[6] | timestamp | one byte each for (year % 256), month, day, hour, minute, second. Purpose unclear.
|
||||
| uint8[4] | padding | 4 bytes zeroes of padding
|
||||
| uint8[16] | separator | zeroes to separate header from bitmap data |
|
||||
| uint8[11]\*N | bitmapdata | image data for all bitmaps. Each bitmap consists of a number of 11 byte chunks describing an 8x11 bitmap, each byte describes 8 pixels, starting with the most significant bit. The number of chunks is listed in the "sizes" fields above, N = sum(sizes). |
|
||||
| uint8[?] | padding | the last 16-byte block of bitmap data is padded with zeroes if necessary. |
|
||||
| offset | byte-size | format | name | description |
|
||||
| --------- | --------- | ------------ | ---------- | ------------ |
|
||||
| 00h | 6 | uint8[6] | header | "wang\0\0" - magic number to indicate a new data frame begin |
|
||||
| 06h | 1 | uint8 | flash | bitfield describing which of the 8 bitmaps are flashing |
|
||||
| 07h | 1 | uint8 | marquee | bitfield describing which of the 8 bitmaps feature an animated border |
|
||||
| 08h | 8 | uint8[8] | modes | speed+mode for each of the 8 bitmaps. See below. |
|
||||
| 10h | 16 | uint16[8] | sizes | count of 8 pixel wide chunks for each bitmap (Big endian) |
|
||||
| 20h | 6 | uint8[6] | padding | 6 bytes zeroes of padding
|
||||
| 26h | 6 | uint8[6] | timestamp | one byte each for (year % 256), month, day, hour, minute, second. Purpose unclear.
|
||||
| 2Ch | 4 | uint8[4] | padding | 4 bytes zeroes of padding
|
||||
| 30h | 16 | uint8[16] | separator | zeroes to separate header from bitmap data |
|
||||
| 40h | 11*N | uint8[11\*N] | bitmapdata | image data for all bitmaps. Each bitmap consists of a number of 11 byte chunks describing an 8x11 bitmap, each byte describes 8 pixels, starting with the most significant bit. The number of chunks is listed in the "sizes" fields above, N = sum(sizes). |
|
||||
| 40h+11*N | ? | uint8[?] | padding | the last 16-byte block of bitmap data is padded with zeroes if necessary. |
|
||||
|
||||
Because the characteristic data value is fixed at 16 bytes, it only be able to
|
||||
receive 16 bytes once each time, so the big fat data frame will be split into
|
||||
16-byte chunks and will be sent out in sequence. For example, 16 bytes from
|
||||
offset 00h-0Fh will be sent first, followed by the next 16 bytes from offset
|
||||
10h-1Fh, and so on. For the last 16-byte of bitmap data, there would be some
|
||||
cases, where some last bytes were not used, these should be filled with zeros.
|
||||
|
||||
#### Modes
|
||||
|
||||
|
||||
Reference in New Issue
Block a user