Santek EZ Door Sign: Difference between revisions

From Leo's Notes
This page was last edited on 29 March 2025, at 03:07.
No edit summary
Line 32: Line 32:
!Notes
!Notes
|-
|-
|0xBB
|<code>0xBB</code>
|0x00
|<code>0x00</code>
|0x00
|<code>0x00</code>
|0x01
|<code>0x01</code>
|slide (1 byte)
|slide (1 byte)
|??
|<code>??</code>
|0x7E
|<code>0x7E</code>
|Redraws the specified slide (0 ~ 4)
|Redraws the specified slide (0 ~ 4)
|-
|-
|0xBB
|<code>0xBB</code>
|0x01
|<code>0x01</code>
|0x00
|<code>0x00</code>
|0x01
|<code>0x01</code>
|slide (1 byte)
|slide (1 byte)
|??
|<code>??</code>
|0x7E
|<code>0x7E</code>
|Redraw slide response
|Redraw slide response
|-
|-
|0xBB
|<code>0xBB</code>
|0x00
|<code>0x00</code>
|0x00
|<code>0x00</code>
|0x01
|<code>0x01</code>
|0xFE
|<code>0xFE</code>
|0xFF
|<code>0xFF</code>
|0x7E
|<code>0x7E</code>
|next slide
|Command next slide
|-
|-
|0xBB
|<code>0xBB</code>
|0x00
|<code>0x00</code>
|0x00
|<code>0x00</code>
|0x01
|<code>0x01</code>
|0xFF
|<code>0xFF</code>
|0x00
|<code>0x00</code>
|0x7E
|<code>0x7E</code>
|previous slide (called 'up' in C# code)
|Command previous slide (called 'up' in C# code)
|-
|-
|0xBB
|<code>0xBB</code>
|0x00
|<code>0x00</code>
|0x01
|<code>0x01</code>
|0x01
|<code>0x01</code>
|slide (1 byte)
|slide (1 byte)
|
|
|0x7E
|<code>0x7E</code>
|Check if site is blank. if returned 4th byte is 254, then isBlank is false
|Check slide data
|-
|-
|0xBB
|<code>0xBB</code>
|0x01
|<code>0x01</code>
|0x01
|<code>0x01</code>
|0x01
|<code>0x01</code>
|status (1 byte)
|status (1 byte)
|
|
|0x7E
|<code>0x7E</code>
|If the status code returned back is 0xFE, the slide is not blank.
|Response to the check slide call. Status is one of:
 
* 0xFF - Slide is blank or unwritten
* 0xFE - Slide has data
|-
|-
|0xBB
|<code>0xBB</code>
|0x00
|<code>0x00</code>
|0x03
|<code>0x03</code>
|0x02
|<code>0x02</code>
|slide-canvas
|slide-canvas
(2 bytes)
(2 bytes)
|??
|<code>??</code>
|0x7E
|<code>0x7E</code>
|Begin sending data for a specific slide and canvas. All data for the slide must be rewritten.
|Begin sending data for a specific slide and canvas. All data for the slide must be rewritten as everything is wiped.
Data is always 2 bytes long, containing:
Data is always 2 bytes long, containing:


Line 100: Line 103:
* canvas: Color canvas (0 or 1)
* canvas: Color canvas (0 or 1)
|-
|-
|0xBB
|<code>0xBB</code>
|0x01
|<code>0x01</code>
|0x03
|<code>0x03</code>
|0x01
|<code>0x01</code>
|0x01
|<code>0x01</code>
|
|
|0x7E
|<code>0x7E</code>
|Response to the slide-canvas command.
|Response to the slide-canvas command.
|-
|-
|0xBB
|<code>0xBB</code>
|0x00
|<code>0x00</code>
|0x04
|<code>0x04</code>
|0x12
|<code>0x12</code>
|column-bitmap
|column-bitmap
(18 bytes)
(18 bytes)
|??
|<code>??</code>
|0x7E
|<code>0x7E</code>
|send image bitmap data by column.
|send image bitmap data by column.
Data is always 18 bytes long. 2 for column number, 16 for bitmap data.
Data is always 18 bytes long. 2 for column number, 16 for bitmap data.
Line 126: Line 129:
This is how you can retrieve data for the 296x128 pixel display.
This is how you can retrieve data for the 296x128 pixel display.
|-
|-
|0xBB
|<code>0xBB</code>
|0x01
|<code>0x01</code>
|0x04
|<code>0x04</code>
|0x01
|<code>0x01</code>
|0x01
|<code>0x01</code>
|
|
|0x7E
|<code>0x7E</code>
|did send image row data succeed? Data should be 0x01
|did send image row data succeed? Data should be 0x01
|-
|-
|0xBB
|<code>0xBB</code>
|0x00
|<code>0x00</code>
|0x05
|<code>0x05</code>
|0x04
|<code>0x04</code>
|slide-canvas-column
|slide-canvas-column
(4 bytes)
(4 bytes)
|??
|<code>??</code>
|0x7E
|<code>0x7E</code>
|Get image bitmap from display memory.
|Get image bitmap from display memory.
Data is always 4 bytes long.
Data is always 4 bytes long.
Line 154: Line 157:
See the response payload below.
See the response payload below.
|-
|-
|0xBB
|<code>0xBB</code>
|0x01
|<code>0x01</code>
|0x05
|<code>0x05</code>
|0x12
|<code>0x12</code>
|column-bitmap
|column-bitmap
(24 bytes)
(24 bytes)
|??
|<code>??</code>
|0x7E
|<code>0x7E</code>
|Bitmap data received from a get command. The response message is always 24 bytes long.
|Bitmap data received from a get command. The response message is always 24 bytes long.
There are 18 bytes of payload data and is the same format as the send-image-column command.
There are 18 bytes of payload data and is the same format as the send-image-column command.
Line 168: Line 171:
* Bitmap: 16 bytes. One bit per pixel makes 128 pixels
* Bitmap: 16 bytes. One bit per pixel makes 128 pixels
|-
|-
|0xBB
|<code>0xBB</code>
|
|
|0x06
|<code>0x06</code>
|
|
|
|
|
|
|0x7E
|<code>0x7E</code>
|iap model
|iap model
|-
|-
|0xBB
|<code>0xBB</code>
|0x00
|<code>0x00</code>
|0x07
|<code>0x07</code>
|0x01
|<code>0x01</code>
|0x00
|<code>0x00</code>
|0x08
|<code>0x08</code>
|0x7E
|<code>0x7E</code>
|power off
|power off
|}
|}
Line 189: Line 192:
The display is tri-color and uses 2 bits per pixel to denote color. The 2 bits are written across two separate 'canvases' as part of the write operation. When writing an image:
The display is tri-color and uses 2 bits per pixel to denote color. The 2 bits are written across two separate 'canvases' as part of the write operation. When writing an image:


# Set the canvas to 0
# Call the start write command (<code>0x03</code>) and specify the desired slide and <code>0x00</code> canvas
# Write the bitmap (column by column, from left to right, top to bottom). There should be 128 pixels (as the display is 128 pixels high). Black and red pixels should be 0. White should be 1. (see table below)
# Write the bitmap with command <code>0x04</code>. This command operates column by column, from left to right, top to bottom. There should be 128 pixels (as the display is 128 pixels high). Black and red pixels should be 0. White should be 1. (see table below)
# Set the canvas to 1
# Call the start write command (<code>0x03</code>) again but this time set canvas to <code>0x01</code>
# Write the bitmap like in step 2, but set the bitmap to 0 for black and white and 1 for red.
# Write the bitmap again with command <code>0x04</code> as in step 2, but this time, set the bitmap to 0 for black and white and 1 for red.


You must write to all addresses. The memory for the slide appears to get wiped when a write is initiaited. Skipping any of the columns for either canvases will cause the image to become corrupt.
You must write to all addresses. The memory for the slide appears to get wiped when a write is initiaited. Skipping any of the columns for either canvases will cause the image to become corrupt.
If you call the 0x03 begin write command but don't actually write anything, the slide data becomes uninitialized and appears completely red. The check slide command (<code>0x01</code>) also returns <code>0xFF</code> rather than <code>0xFE</code> denoting that there is no data at this slide.
{| class="wikitable"
{| class="wikitable"
!
!

Revision as of 03:07, 29 March 2025

The Santek EZ Door Sign is cordless e-ink display intended to be mounted outside of offices or rooms. It is capable of storing 5 custom images that can be displayed and rotated with the side button.

The 2.9" variant which I obtained has a resolution of 296 x 128 pixels and is capable of displaying black, white, and red.

Serial protocol

Background

Santek provides a Windows based app written in C# that is able to interact with the door signs. My goal is to have some Linux based device that can periodically update these displays (such as the weather or calendar events on an hourly basis). In order to do that, I will need to figure out how exactly this device talks via the USB port.

There are some GitHub projects that try to interface with this device already including https://github.com/m3m0r7/ez-door-sign in PHP and https://github.com/kenichi884/ezsign.py in Python. However, the documentation on the serial protocol is a bit lacking. Fortunately, the protocol doesn't seem too complicated.

Serial configuration

Use 9600 baud. No parity.

The display has to be on. Ensure that the blue LED is lit before trying to talk to it via serial.

Commands and messages

Here are some of the supported commands by the display.

Command Type is 0 if it's a command that's sent to the display. It will be a 1 if it's data that's a response to a command made by the display.

Header Command

Type

Command

ID

Data

Length

Data Chksum Ending Notes
0xBB 0x00 0x00 0x01 slide (1 byte) ?? 0x7E Redraws the specified slide (0 ~ 4)
0xBB 0x01 0x00 0x01 slide (1 byte) ?? 0x7E Redraw slide response
0xBB 0x00 0x00 0x01 0xFE 0xFF 0x7E Command next slide
0xBB 0x00 0x00 0x01 0xFF 0x00 0x7E Command previous slide (called 'up' in C# code)
0xBB 0x00 0x01 0x01 slide (1 byte) 0x7E Check slide data
0xBB 0x01 0x01 0x01 status (1 byte) 0x7E Response to the check slide call. Status is one of:
  • 0xFF - Slide is blank or unwritten
  • 0xFE - Slide has data
0xBB 0x00 0x03 0x02 slide-canvas

(2 bytes)

?? 0x7E Begin sending data for a specific slide and canvas. All data for the slide must be rewritten as everything is wiped.

Data is always 2 bytes long, containing:

  • slide: slide number (0 through 4)
  • canvas: Color canvas (0 or 1)
0xBB 0x01 0x03 0x01 0x01 0x7E Response to the slide-canvas command.
0xBB 0x00 0x04 0x12 column-bitmap

(18 bytes)

?? 0x7E send image bitmap data by column.

Data is always 18 bytes long. 2 for column number, 16 for bitmap data.

Bitmap data here is based on the canvas setting in order to get that extra bit for color.

  • Column: 2 bytes in decimal. (0 ~ 295) (0x00,0x00 ~ 0x01,0x27)
  • Bitmap: 16 bytes. One bit per pixel makes 128 pixels

This is how you can retrieve data for the 296x128 pixel display.

0xBB 0x01 0x04 0x01 0x01 0x7E did send image row data succeed? Data should be 0x01
0xBB 0x00 0x05 0x04 slide-canvas-column

(4 bytes)

?? 0x7E Get image bitmap from display memory.

Data is always 4 bytes long.

  • Slide: Slide number (0 through 4)
  • Canvas: Color canvas (0 or 1)
  • Column: 2 bytes. (0 ~ 295)

To retrieve the actual color, you have to read both canvas

See the response payload below.

0xBB 0x01 0x05 0x12 column-bitmap

(24 bytes)

?? 0x7E Bitmap data received from a get command. The response message is always 24 bytes long.

There are 18 bytes of payload data and is the same format as the send-image-column command.

  • Column: 2 bytes. (0 ~ 295)
  • Bitmap: 16 bytes. One bit per pixel makes 128 pixels
0xBB 0x06 0x7E iap model
0xBB 0x00 0x07 0x01 0x00 0x08 0x7E power off

Writing bitmap information

The display is tri-color and uses 2 bits per pixel to denote color. The 2 bits are written across two separate 'canvases' as part of the write operation. When writing an image:

  1. Call the start write command (0x03) and specify the desired slide and 0x00 canvas
  2. Write the bitmap with command 0x04. This command operates column by column, from left to right, top to bottom. There should be 128 pixels (as the display is 128 pixels high). Black and red pixels should be 0. White should be 1. (see table below)
  3. Call the start write command (0x03) again but this time set canvas to 0x01
  4. Write the bitmap again with command 0x04 as in step 2, but this time, set the bitmap to 0 for black and white and 1 for red.

You must write to all addresses. The memory for the slide appears to get wiped when a write is initiaited. Skipping any of the columns for either canvases will cause the image to become corrupt.

If you call the 0x03 begin write command but don't actually write anything, the slide data becomes uninitialized and appears completely red. The check slide command (0x01) also returns 0xFF rather than 0xFE denoting that there is no data at this slide.

Canvas = 0 Canvas = 1 Color
Pixel bit value 0 0 Black
1 0 White
0 1 Red

For black and white only pictures, you can effectively ignore setting canvas=1.