Implement a native Java driver for the Sigma ASC 434 programmable LED display.
The display is an older three-color LED sign intended for shop windows and similar installations. It can be controlled over RS-232 and supports significantly more than simply displaying text.
We have successfully recovered the original Windows software, Sign Manager 2.34, made it run under Wine on Linux, and proven that the display can be controlled directly from Linux without Wine.
The long-term goal is to understand enough of the Sigma protocol to control the display completely from Java, without depending on Sign Manager or Wine at runtime.
The original Windows software should remain useful as a reference implementation while reverse-engineering the protocol.
Hardware
Known hardware:
Sigma ASC 434 LED display
Three-color LED display
RS-232 interface
USB-to-RS232 adapter under Linux
Adapter currently appears as:
/dev/ttyUSB0
The tested serial configuration is:
9600 baud
8 data bits
no parity
1 stop bit
no software flow control
no hardware flow control
Static inspection of Msgeditor.exe showed formatting corresponding to a two-digit hexadecimal display ID.
The exact valid ID range still needs to be verified.
The following:
]"
appears to separate the addressing/header part from the command.
The first payload in the example is:
AZHello World!
Frames or blocks appear to terminate with:
]$]$
There is an additional control byte:
0x1F
between the two blocks in this example.
The final block is:
]!Z00]"E. Z]$]$
Its exact semantics still need to be determined.
It appears likely to be related to committing, executing or activating the newly written message.
These interpretations are reverse-engineering observations and must not be treated as final protocol documentation until experimentally verified.
Possible chunking and acknowledgement protocol
Static inspection of Msgeditor.exe suggests that Sign Manager may not always simply write the complete transmission as one uninterrupted byte stream.
There appears to be logic around:
]$]$
where blocks may be sent separately and a response from the display is read before continuing.
At least one inspected code path appeared to treat response bytes such as:
Y
O
as positive responses.
This needs further verification.
Importantly, the physical ASC 434 accepted the complete 42-byte Hello World! transmission in one write from the Linux shell:
printf'...' > /dev/ttyUSB0
Therefore chunking/ACK handling was not necessary for this simple transmission.
The Java driver should nevertheless investigate and implement the actual protocol rather than assume that one large write will work for every command.
This may become important for:
larger messages
memory operations
querying the display
reading stored data
display discovery
ID operations
configuration commands
error detection
multiple displays on the same serial connection
The transport/protocol implementation should therefore be capable of:
block/chunk transmission
configurable read/write timeouts
reading responses
ACK/error interpretation
clearing stale input where necessary
retries only where the actual protocol proves they are safe
Required Java driver functionality
The target is not merely a "send text" implementation.
The driver should ultimately expose enough of the ASC 434 protocol to replace Sign Manager for normal operation.
1. Serial transport
Implement native Java communication with the serial device.
The implementation must support at least the known working configuration:
9600 8N1
no software flow control
no hardware flow control
The protocol implementation should not unnecessarily depend on Linux shell commands such as stty or printf.
The production implementation must not invoke Wine or Sign Manager.
Transport concerns should be kept separate from Sigma protocol encoding and decoding.
2. Display discovery
Sign Manager contains functionality for scanning for connected displays.
Investigate this operation and reproduce it.
This is important because the Java driver should preferably be capable of confirming that a Sigma display exists and identifying it instead of blindly assuming that a configured serial device contains the expected hardware.
Discovery should be considered when designing the driver's constructor/opening API.
For example, construction/opening may eventually perform operations conceptually similar to:
open serial port
↓
scan/probe
↓
identify ASC 434
↓
read display ID/configuration
↓
return usable display instance
The exact Java API should only be decided after the discovery protocol is understood.
3. Display ID
Investigate and implement support for:
discovering the current display ID
reading the current display ID
changing the display ID
addressing a specific display
determining valid ID values/range
determining whether multiple displays can share one serial connection
The known successful transmission contains:
Z00
which currently appears to mean display ID 00.
The driver should not permanently hardcode Z00.
4. Text messages
Support creating and transmitting text messages.
Reverse engineer and expose the properties supported by Sign Manager, including at least:
text contents
text color
font
display effect
scrolling
speed/timing where supported
The ASC 434 is a three-color display.
Determine the actual protocol representation for all colors supported by the hardware.
The Java API should expose meaningful concepts rather than forcing callers to construct raw control sequences.
5. Stored messages
The sign has internal memory and stored messages.
Determine the memory/message model and implement it.
Investigate:
how messages are numbered/addressed
how a message is written
how a message is overwritten
whether existing messages can be read back from the display
whether Sign Manager only writes messages or can also retrieve them
maximum message count
maximum message size
how message metadata is represented
whether messages have names/IDs/slots
what happens to unused slots
whether individual messages can be deleted
It is specifically important to determine whether the ASC 434 protocol allows reading already stored messages, or whether stored messages can only be overwritten.
If reading messages is not supported by the protocol, document this explicitly rather than inventing simulated read functionality.
6. Multiple pages
Support the display's concept of multiple pages/messages being shown in sequence.
Investigate and implement:
defining pages
assigning content to pages
page order
switching between pages
automatic cycling
per-page timing if supported
transitions/effects between pages if supported
The Java model should represent this functionality explicitly instead of requiring callers to manually construct protocol strings.
7. Reset memory
Reverse engineer and implement the Sign Manager operation for resetting/clearing display memory.
Determine whether:
all message memory is cleared
individual messages can be cleared
configuration survives the reset
display ID survives the reset
date/time survives the reset
This is a destructive operation and should be represented clearly in the Java API.
Particular care should be taken while reverse-engineering this command on the physical display.
8. Date and time
The display supports setting date/time.
Reverse engineer and implement:
setting date
setting time
reading date/time if supported
determining the internal date/time representation
Also investigate whether the display can dynamically include fields such as:
current date
current time
weekday
inside displayed messages.
9. Brightness
Reverse engineer and implement brightness control.
Determine:
valid brightness levels
how brightness values are encoded
whether brightness can be queried
whether the setting is persistent
whether automatic brightness functionality exists
Expose brightness as a typed Java concept once the valid values/range are understood.
10. Remaining Sign Manager functionality
Inspect Sign Manager and document every meaningful operation it exposes for the ASC 434.
The final Java driver should aim to cover the hardware rather than only the operations already known when this issue was created.
Anything discovered while investigating Sign Manager should be added to the protocol documentation.
Reverse-engineering strategy
Use three complementary approaches.
A. templog.dat differential analysis
This should be the preferred first approach.
Create controlled experiments in Sign Manager where exactly one property changes.
Example:
Experiment 1:
text = TEST
color = red
Experiment 2:
text = TEST
color = green
Compare the generated templog.dat files and identify the changed control sequence.
Repeat this for each feature.
Other useful comparisons:
A vs B
red vs green
green vs third color
font 1 vs font 2
static vs scroll
speed 1 vs speed 2
page 1 vs page 2
message slot 1 vs slot 2
brightness level N vs N+1
ID 00 vs ID 01
Always change only one property at a time where possible.
B. Inspect Msgeditor.exe
Static inspection of Msgeditor.exe has already successfully exposed useful parts of the protocol.
This approach should continue to be used.
Useful targets include calls to the PComm API:
sio_open
sio_ioctl
sio_write
sio_read
In particular, follow callers of:
sio_write
to understand how outgoing blocks are generated.
Follow:
sio_read
and related functions to understand:
acknowledgement
discovery
queries
display responses
error handling
Relevant readable strings already found in Msgeditor.exe include protocol fragments such as:
]!
Z%02X
]"
AZ
]$]$
The executable has therefore already proven to be directly useful for understanding the Sigma protocol.
Disassembly should especially be used for features that cannot easily be observed from templog.dat, such as:
scanning/discovery
commands that expect a response
reading device state
acknowledgement handling
retries/timeouts
reading stored messages
display ID queries
C. Physical-device experiments
Every inferred protocol feature should eventually be verified against the physical ASC 434.
Sign Manager should be treated as the known-working reference implementation.
The direct Linux transmission already proves that the protocol can be reproduced independently.
Keep experiments small and preferably change only one variable at a time.
Be especially careful with:
reset-memory commands
display ID changes
undocumented configuration commands
because these may alter persistent device state.
Protocol documentation
The reverse-engineered protocol must be documented as part of this work.
Do not leave important protocol knowledge hidden only inside Java implementation code.
Document at least:
physical/serial interface
baud rate
data bits
parity
stop bits
flow control
frame structure
display addressing
command identifiers
terminators
control characters
escaping rules
text encoding
colors
fonts
effects
scrolling
timing/speed
page representation
message storage
memory commands
date/time commands
brightness commands
display discovery
ID commands
query/response protocol
acknowledgement/error responses
timeout requirements
chunking rules
known limits
known model-specific behavior
Clearly distinguish between:
experimentally verified behavior
behavior inferred from Sign Manager output
behavior inferred from static analysis/disassembly
unresolved assumptions/questions
Suggested internal architecture
Keep the following concerns separate:
Application API
|
v
Sigma ASC 434 domain/model
|
v
Sigma protocol encoder/decoder
|
v
Serial transport
|
v
/dev/ttyUSB*
Do not expose raw protocol strings such as:
]!Z00]"AZ...
to normal callers.
Raw frames may still be useful internally and for diagnostic/debug tooling.
The public API may eventually contain concepts such as:
Display
DisplayId
Message
Page
Color
Font
Effect
Brightness
where these concepts are justified by the actual device protocol.
Do not invent abstractions prematurely.
First understand the corresponding hardware/protocol behavior, then model it in Java.
Error handling
The driver must not silently ignore communication failures.
Expected failure categories should eventually include:
serial device cannot be opened
serial device disappears
unsupported serial configuration
no display responds
wrong/unexpected display ID
timeout waiting for response
malformed display response
negative acknowledgement
unsupported command
invalid message/page configuration
invalid display ID
invalid brightness value
protocol state inconsistency
Errors should retain enough context to diagnose whether the problem occurred at:
serial transport
protocol
display command
device response
Diagnostics
Provide enough diagnostics that serial/protocol failures can be investigated without returning to Sign Manager.
Useful diagnostic information includes:
selected serial device
configured baud rate
target display ID
command type
transmitted frame/block length
received response
timeout
protocol error
It should be possible to enable logging of raw transmitted and received bytes.
Raw protocol traffic should not be logged unconditionally during normal operation.
A hex-oriented diagnostic representation similar to:
TX: 5d 21 5a 30 30 ...
RX: 59
would be useful while reverse-engineering and debugging.
OpenSpec
Capture the driver capability and externally visible behavior in OpenSpec as part of the implementation.
The specification should cover at least:
opening/discovering an ASC 434
addressing by display ID
text/message handling
page handling
configuration operations
read/query operations
timeout and protocol error behavior
destructive operations such as memory reset
Protocol implementation details that are not part of the public API should live in appropriate protocol documentation rather than unnecessarily leaking into the public specification.
Out of scope
For this issue:
Do not depend on Wine at runtime.
Do not invoke Msgeditor.exe from Java.
Do not treat templog.dat as the production protocol API.
Do not implement a solution that merely shells out to stty, printf or cat.
Do not hardcode only the known Hello World! transmission.
Do not assume every Sign Manager operation can be performed as one uninterrupted write merely because the simple text test worked that way.
Do not assume Z00 is the only valid address.
Do not guess undocumented protocol behavior where it can instead be verified using Sign Manager, executable inspection or the physical display.
Wine and Sign Manager are reverse-engineering/reference tools only.
Acceptance criteria
The work is complete when:
Java can open and communicate with the ASC 434 directly through the serial device.
The known Hello World! example can be reproduced from Java without Wine.
The Sigma protocol framing used by the implementation is documented.
Display discovery equivalent to Sign Manager has been investigated and implemented where supported.
Display ID behavior has been understood.
Display IDs can be read and changed where supported by the protocol.
Text messages can be created without hardcoded raw frames.
Supported text colors are implemented.
Supported fonts are implemented.
Supported display effects are implemented.
Scrolling/timing functionality is implemented where supported.
Multiple pages/messages and switching/cycling between them are supported.
Stored-message behavior has been understood and implemented.
Reading existing stored messages is implemented if supported by the hardware protocol.
Lack of read-back support is documented explicitly if the hardware does not support it.
Memory reset is supported.
Date/time configuration is supported.
Brightness control is supported.
Required response/ACK/timeout/chunking behavior has been understood and implemented.
Sign Manager's display scan/discovery mechanism has been reverse engineered sufficiently to reproduce the relevant functionality.
Relevant additional ASC 434 functionality exposed by Sign Manager has been identified and either implemented or explicitly documented.
The reverse-engineered protocol is documented separately from implementation details.
Verified protocol behavior is clearly distinguished from inferred or unresolved behavior.
OpenSpec has been updated for the externally visible driver behavior.
The production Java driver has no dependency on Wine or Sign Manager.
Known-good reference
The following is currently the smallest known working native Linux example:
provides a practical path toward fully documenting the protocol and implementing a complete native Java driver.
## Summary
Implement a native Java driver for the Sigma ASC 434 programmable LED display.
The display is an older three-color LED sign intended for shop windows and similar installations. It can be controlled over RS-232 and supports significantly more than simply displaying text.
We have successfully recovered the original Windows software, **Sign Manager 2.34**, made it run under Wine on Linux, and proven that the display can be controlled directly from Linux without Wine.
The long-term goal is to understand enough of the Sigma protocol to control the display completely from Java, without depending on Sign Manager or Wine at runtime.
The original Windows software should remain useful as a reference implementation while reverse-engineering the protocol.
---
## Hardware
Known hardware:
- Sigma ASC 434 LED display
- Three-color LED display
- RS-232 interface
- USB-to-RS232 adapter under Linux
- Adapter currently appears as:
```text
/dev/ttyUSB0
```
The tested serial configuration is:
```text
9600 baud
8 data bits
no parity
1 stop bit
no software flow control
no hardware flow control
```
In conventional notation:
```text
9600 8N1
```
---
## Original Windows software
The original software has been recovered:
```text
Setup(Sign Manager2.34).exe
```
SHA-256:
```text
a043c7b861d2616d04874d3acd00f75be9559ce36830308b9d530f40a9bb8f7b
```
The installer is an old 32-bit Windows installer and installs the software under:
```text
C:\Program Files (x86)\CLGD\MsgEditor
```
Important installed files include:
```text
Msgeditor.exe
GroupManager.exe
Pcomm.dll
group.dat
```
`Msgeditor.exe` is the main Sign Manager application.
`Pcomm.dll` was inspected and is not the Sigma protocol implementation itself. It is an old generic serial communication library from Moxa Technologies.
It exports functions such as:
```text
sio_open
sio_close
sio_ioctl
sio_baud
sio_read
sio_write
sio_putch
sio_getch
sio_flush
sio_flowctrl
sio_RTS
sio_DTR
sio_SetReadTimeouts
sio_SetWriteTimeouts
```
The actual Sigma protocol framing appears to be implemented in `Msgeditor.exe`.
Static inspection/disassembly of `Msgeditor.exe` has already been useful and should continue to be used where black-box experiments are insufficient.
---
## Running Sign Manager under Wine
Sign Manager 2.34 works successfully under Wine on Linux.
A dedicated Wine prefix is used:
```text
$HOME/.local/share/wineprefixes/signmanager
```
The application can be started with:
```bash
WINEPREFIX="$HOME/.local/share/wineprefixes/signmanager" \
wine "C:\Program Files (x86)\CLGD\MsgEditor\Msgeditor.exe"
```
### Mapping the USB serial adapter to COM1
The Linux serial device can be exposed to Sign Manager as `COM1`.
The Wine registry mapping used is:
```bash
WINEPREFIX="$HOME/.local/share/wineprefixes/signmanager" \
wine reg add 'HKLM\Software\Wine\Ports' \
/v COM1 \
/d /dev/ttyUSB0 \
/f
```
Wine may automatically recreate `dosdevices/com1` and point it at `/dev/ttyS0`.
If necessary, stop Wine, delete the generated mapping, and let Wine recreate it using the registry configuration:
```bash
WINEPREFIX="$HOME/.local/share/wineprefixes/signmanager" wineserver -k
rm -f \
"$HOME/.local/share/wineprefixes/signmanager/dosdevices/com1"
WINEPREFIX="$HOME/.local/share/wineprefixes/signmanager" wineboot
```
The registry can be verified with:
```bash
WINEPREFIX="$HOME/.local/share/wineprefixes/signmanager" \
wine reg query 'HKLM\Software\Wine\Ports'
```
Expected value:
```text
COM1 REG_SZ /dev/ttyUSB0
```
On Arch Linux, `/dev/ttyUSB0` is owned by the `uucp` group.
Example:
```text
crw-rw---- 1 root uucp ... /dev/ttyUSB0
```
The user therefore needs access to that group:
```bash
sudo usermod -aG uucp "$USER"
```
A new login session is required afterwards.
---
## Important reverse-engineering discovery: `templog.dat`
One of the most useful discoveries is that Sign Manager does not construct and transmit everything only in memory.
Before transmission, `Msgeditor.exe` writes the outgoing data stream to:
```text
C:\templog.dat
```
Inside the current Wine prefix this is:
```text
$HOME/.local/share/wineprefixes/signmanager/drive_c/templog.dat
```
This makes Sign Manager an extremely convenient protocol oracle.
A message can be created in Sign Manager and then the exact bytes it intends to send can be inspected directly.
For example:
```bash
xxd -g1 \
"$HOME/.local/share/wineprefixes/signmanager/drive_c/templog.dat"
```
or:
```bash
hexdump \
"$HOME/.local/share/wineprefixes/signmanager/drive_c/templog.dat"
```
The preferred reverse-engineering strategy should therefore be:
1. Create a known message or command in Sign Manager.
2. Save/copy `templog.dat`.
3. Change exactly one property.
4. Generate the data again.
5. Compare the two files.
6. Determine which bytes/control sequences represent that property.
Useful experiments include changing only:
- text
- text color
- font
- display effect
- scroll mode
- speed
- page
- message slot
- brightness
- display ID
- date/time
- memory operations
This is likely much faster than attempting to understand all of `Msgeditor.exe` through disassembly alone.
---
## Proven direct Linux communication
A message has successfully been transmitted to the display directly from Linux without Wine or Sign Manager.
The serial port was configured with:
```bash
stty -F /dev/ttyUSB0 \
9600 cs8 -parenb -cstopb \
-ixon -ixoff -crtscts \
raw -echo
```
This command then successfully displayed:
```text
Hello World!
```
on the physical Sigma ASC 434:
```bash
printf ']!Z00]"AZHello World!]$]$\x1f]!Z00]"E. Z]$]$' \
> /dev/ttyUSB0
```
This proves that:
- the display does not require the Windows software
- the protocol can be generated directly
- there is no special Windows driver requirement
- Java should be capable of controlling the display directly through the serial port
The same transmission also works by sending the generated `templog.dat` directly:
```bash
cat \
"$HOME/.local/share/wineprefixes/signmanager/drive_c/templog.dat" \
> /dev/ttyUSB0
```
---
## Known `Hello World!` transmission
For a simple message containing:
```text
Hello World!
```
Sign Manager generated a 42-byte transmission.
Human-readable representation:
```text
]!Z00]"AZHello World!]$]$<0x1F>]!Z00]"E. Z]$]$
```
Exact bytes:
```text
5d 21 5a 30 30 5d 22 41 5a
48 65 6c 6c 6f 20 57 6f 72 6c 64 21
5d 24 5d 24 1f
5d 21 5a 30 30 5d 22 45 2e 20 20 5a
5d 24 5d 24
```
Equivalent escaped representation:
```text
]!Z00]"AZHello World!]$]$\x1f]!Z00]"E. Z]$]$
```
Current interpretation is that:
```text
]!
```
appears to start a command/frame.
The following:
```text
Z00
```
appears to address display ID `00`.
Static inspection of `Msgeditor.exe` showed formatting corresponding to a two-digit hexadecimal display ID.
The exact valid ID range still needs to be verified.
The following:
```text
]"
```
appears to separate the addressing/header part from the command.
The first payload in the example is:
```text
AZHello World!
```
Frames or blocks appear to terminate with:
```text
]$]$
```
There is an additional control byte:
```text
0x1F
```
between the two blocks in this example.
The final block is:
```text
]!Z00]"E. Z]$]$
```
Its exact semantics still need to be determined.
It appears likely to be related to committing, executing or activating the newly written message.
These interpretations are reverse-engineering observations and must not be treated as final protocol documentation until experimentally verified.
---
## Possible chunking and acknowledgement protocol
Static inspection of `Msgeditor.exe` suggests that Sign Manager may not always simply write the complete transmission as one uninterrupted byte stream.
There appears to be logic around:
```text
]$]$
```
where blocks may be sent separately and a response from the display is read before continuing.
At least one inspected code path appeared to treat response bytes such as:
```text
Y
O
```
as positive responses.
This needs further verification.
Importantly, the physical ASC 434 accepted the complete 42-byte `Hello World!` transmission in one write from the Linux shell:
```bash
printf '...' > /dev/ttyUSB0
```
Therefore chunking/ACK handling was not necessary for this simple transmission.
The Java driver should nevertheless investigate and implement the actual protocol rather than assume that one large write will work for every command.
This may become important for:
- larger messages
- memory operations
- querying the display
- reading stored data
- display discovery
- ID operations
- configuration commands
- error detection
- multiple displays on the same serial connection
The transport/protocol implementation should therefore be capable of:
- block/chunk transmission
- configurable read/write timeouts
- reading responses
- ACK/error interpretation
- clearing stale input where necessary
- retries only where the actual protocol proves they are safe
---
# Required Java driver functionality
The target is not merely a "send text" implementation.
The driver should ultimately expose enough of the ASC 434 protocol to replace Sign Manager for normal operation.
---
## 1. Serial transport
Implement native Java communication with the serial device.
The implementation must support at least the known working configuration:
```text
9600 8N1
no software flow control
no hardware flow control
```
The protocol implementation should not unnecessarily depend on Linux shell commands such as `stty` or `printf`.
The production implementation must not invoke Wine or Sign Manager.
Transport concerns should be kept separate from Sigma protocol encoding and decoding.
---
## 2. Display discovery
Sign Manager contains functionality for scanning for connected displays.
Investigate this operation and reproduce it.
This is important because the Java driver should preferably be capable of confirming that a Sigma display exists and identifying it instead of blindly assuming that a configured serial device contains the expected hardware.
Discovery should be considered when designing the driver's constructor/opening API.
For example, construction/opening may eventually perform operations conceptually similar to:
```text
open serial port
↓
scan/probe
↓
identify ASC 434
↓
read display ID/configuration
↓
return usable display instance
```
The exact Java API should only be decided after the discovery protocol is understood.
---
## 3. Display ID
Investigate and implement support for:
- discovering the current display ID
- reading the current display ID
- changing the display ID
- addressing a specific display
- determining valid ID values/range
- determining whether multiple displays can share one serial connection
The known successful transmission contains:
```text
Z00
```
which currently appears to mean display ID `00`.
The driver should not permanently hardcode `Z00`.
---
## 4. Text messages
Support creating and transmitting text messages.
Reverse engineer and expose the properties supported by Sign Manager, including at least:
- text contents
- text color
- font
- display effect
- scrolling
- speed/timing where supported
The ASC 434 is a three-color display.
Determine the actual protocol representation for all colors supported by the hardware.
The Java API should expose meaningful concepts rather than forcing callers to construct raw control sequences.
---
## 5. Stored messages
The sign has internal memory and stored messages.
Determine the memory/message model and implement it.
Investigate:
- how messages are numbered/addressed
- how a message is written
- how a message is overwritten
- whether existing messages can be read back from the display
- whether Sign Manager only writes messages or can also retrieve them
- maximum message count
- maximum message size
- how message metadata is represented
- whether messages have names/IDs/slots
- what happens to unused slots
- whether individual messages can be deleted
It is specifically important to determine whether the ASC 434 protocol allows reading already stored messages, or whether stored messages can only be overwritten.
If reading messages is not supported by the protocol, document this explicitly rather than inventing simulated read functionality.
---
## 6. Multiple pages
Support the display's concept of multiple pages/messages being shown in sequence.
Investigate and implement:
- defining pages
- assigning content to pages
- page order
- switching between pages
- automatic cycling
- per-page timing if supported
- transitions/effects between pages if supported
The Java model should represent this functionality explicitly instead of requiring callers to manually construct protocol strings.
---
## 7. Reset memory
Reverse engineer and implement the Sign Manager operation for resetting/clearing display memory.
Determine whether:
- all message memory is cleared
- individual messages can be cleared
- configuration survives the reset
- display ID survives the reset
- date/time survives the reset
This is a destructive operation and should be represented clearly in the Java API.
Particular care should be taken while reverse-engineering this command on the physical display.
---
## 8. Date and time
The display supports setting date/time.
Reverse engineer and implement:
- setting date
- setting time
- reading date/time if supported
- determining the internal date/time representation
Also investigate whether the display can dynamically include fields such as:
- current date
- current time
- weekday
inside displayed messages.
---
## 9. Brightness
Reverse engineer and implement brightness control.
Determine:
- valid brightness levels
- how brightness values are encoded
- whether brightness can be queried
- whether the setting is persistent
- whether automatic brightness functionality exists
Expose brightness as a typed Java concept once the valid values/range are understood.
---
## 10. Remaining Sign Manager functionality
Inspect Sign Manager and document every meaningful operation it exposes for the ASC 434.
The final Java driver should aim to cover the hardware rather than only the operations already known when this issue was created.
Anything discovered while investigating Sign Manager should be added to the protocol documentation.
---
# Reverse-engineering strategy
Use three complementary approaches.
## A. `templog.dat` differential analysis
This should be the preferred first approach.
Create controlled experiments in Sign Manager where exactly one property changes.
Example:
```text
Experiment 1:
text = TEST
color = red
Experiment 2:
text = TEST
color = green
```
Compare the generated `templog.dat` files and identify the changed control sequence.
Repeat this for each feature.
Other useful comparisons:
```text
A vs B
red vs green
green vs third color
font 1 vs font 2
static vs scroll
speed 1 vs speed 2
page 1 vs page 2
message slot 1 vs slot 2
brightness level N vs N+1
ID 00 vs ID 01
```
Always change only one property at a time where possible.
---
## B. Inspect `Msgeditor.exe`
Static inspection of `Msgeditor.exe` has already successfully exposed useful parts of the protocol.
This approach should continue to be used.
Useful targets include calls to the PComm API:
```text
sio_open
sio_ioctl
sio_write
sio_read
```
In particular, follow callers of:
```text
sio_write
```
to understand how outgoing blocks are generated.
Follow:
```text
sio_read
```
and related functions to understand:
- acknowledgement
- discovery
- queries
- display responses
- error handling
Relevant readable strings already found in `Msgeditor.exe` include protocol fragments such as:
```text
]!
Z%02X
]"
AZ
]$]$
```
The executable has therefore already proven to be directly useful for understanding the Sigma protocol.
Disassembly should especially be used for features that cannot easily be observed from `templog.dat`, such as:
- scanning/discovery
- commands that expect a response
- reading device state
- acknowledgement handling
- retries/timeouts
- reading stored messages
- display ID queries
---
## C. Physical-device experiments
Every inferred protocol feature should eventually be verified against the physical ASC 434.
Sign Manager should be treated as the known-working reference implementation.
The direct Linux transmission already proves that the protocol can be reproduced independently.
Keep experiments small and preferably change only one variable at a time.
Be especially careful with:
- reset-memory commands
- display ID changes
- undocumented configuration commands
because these may alter persistent device state.
---
# Protocol documentation
The reverse-engineered protocol must be documented as part of this work.
Do not leave important protocol knowledge hidden only inside Java implementation code.
Document at least:
- physical/serial interface
- baud rate
- data bits
- parity
- stop bits
- flow control
- frame structure
- display addressing
- command identifiers
- terminators
- control characters
- escaping rules
- text encoding
- colors
- fonts
- effects
- scrolling
- timing/speed
- page representation
- message storage
- memory commands
- date/time commands
- brightness commands
- display discovery
- ID commands
- query/response protocol
- acknowledgement/error responses
- timeout requirements
- chunking rules
- known limits
- known model-specific behavior
Clearly distinguish between:
1. experimentally verified behavior
2. behavior inferred from Sign Manager output
3. behavior inferred from static analysis/disassembly
4. unresolved assumptions/questions
---
# Suggested internal architecture
Keep the following concerns separate:
```text
Application API
|
v
Sigma ASC 434 domain/model
|
v
Sigma protocol encoder/decoder
|
v
Serial transport
|
v
/dev/ttyUSB*
```
Do not expose raw protocol strings such as:
```text
]!Z00]"AZ...
```
to normal callers.
Raw frames may still be useful internally and for diagnostic/debug tooling.
The public API may eventually contain concepts such as:
```text
Display
DisplayId
Message
Page
Color
Font
Effect
Brightness
```
where these concepts are justified by the actual device protocol.
Do not invent abstractions prematurely.
First understand the corresponding hardware/protocol behavior, then model it in Java.
---
# Error handling
The driver must not silently ignore communication failures.
Expected failure categories should eventually include:
- serial device cannot be opened
- serial device disappears
- unsupported serial configuration
- no display responds
- wrong/unexpected display ID
- timeout waiting for response
- malformed display response
- negative acknowledgement
- unsupported command
- invalid message/page configuration
- invalid display ID
- invalid brightness value
- protocol state inconsistency
Errors should retain enough context to diagnose whether the problem occurred at:
```text
serial transport
protocol
display command
device response
```
---
# Diagnostics
Provide enough diagnostics that serial/protocol failures can be investigated without returning to Sign Manager.
Useful diagnostic information includes:
- selected serial device
- configured baud rate
- target display ID
- command type
- transmitted frame/block length
- received response
- timeout
- protocol error
It should be possible to enable logging of raw transmitted and received bytes.
Raw protocol traffic should not be logged unconditionally during normal operation.
A hex-oriented diagnostic representation similar to:
```text
TX: 5d 21 5a 30 30 ...
RX: 59
```
would be useful while reverse-engineering and debugging.
---
# OpenSpec
Capture the driver capability and externally visible behavior in OpenSpec as part of the implementation.
The specification should cover at least:
- opening/discovering an ASC 434
- addressing by display ID
- text/message handling
- page handling
- configuration operations
- read/query operations
- timeout and protocol error behavior
- destructive operations such as memory reset
Protocol implementation details that are not part of the public API should live in appropriate protocol documentation rather than unnecessarily leaking into the public specification.
---
# Out of scope
For this issue:
- Do not depend on Wine at runtime.
- Do not invoke `Msgeditor.exe` from Java.
- Do not treat `templog.dat` as the production protocol API.
- Do not implement a solution that merely shells out to `stty`, `printf` or `cat`.
- Do not hardcode only the known `Hello World!` transmission.
- Do not assume every Sign Manager operation can be performed as one uninterrupted write merely because the simple text test worked that way.
- Do not assume `Z00` is the only valid address.
- Do not guess undocumented protocol behavior where it can instead be verified using Sign Manager, executable inspection or the physical display.
Wine and Sign Manager are reverse-engineering/reference tools only.
---
# Acceptance criteria
The work is complete when:
- Java can open and communicate with the ASC 434 directly through the serial device.
- The known `Hello World!` example can be reproduced from Java without Wine.
- The Sigma protocol framing used by the implementation is documented.
- Display discovery equivalent to Sign Manager has been investigated and implemented where supported.
- Display ID behavior has been understood.
- Display IDs can be read and changed where supported by the protocol.
- Text messages can be created without hardcoded raw frames.
- Supported text colors are implemented.
- Supported fonts are implemented.
- Supported display effects are implemented.
- Scrolling/timing functionality is implemented where supported.
- Multiple pages/messages and switching/cycling between them are supported.
- Stored-message behavior has been understood and implemented.
- Reading existing stored messages is implemented if supported by the hardware protocol.
- Lack of read-back support is documented explicitly if the hardware does not support it.
- Memory reset is supported.
- Date/time configuration is supported.
- Brightness control is supported.
- Required response/ACK/timeout/chunking behavior has been understood and implemented.
- Sign Manager's display scan/discovery mechanism has been reverse engineered sufficiently to reproduce the relevant functionality.
- Relevant additional ASC 434 functionality exposed by Sign Manager has been identified and either implemented or explicitly documented.
- The reverse-engineered protocol is documented separately from implementation details.
- Verified protocol behavior is clearly distinguished from inferred or unresolved behavior.
- OpenSpec has been updated for the externally visible driver behavior.
- The production Java driver has no dependency on Wine or Sign Manager.
---
# Known-good reference
The following is currently the smallest known working native Linux example:
```bash
stty -F /dev/ttyUSB0 \
9600 cs8 -parenb -cstopb \
-ixon -ixoff -crtscts \
raw -echo
printf ']!Z00]"AZHello World!]$]$\x1f]!Z00]"E. Z]$]$' \
> /dev/ttyUSB0
```
This has been tested successfully against the physical Sigma ASC 434 and displays:
```text
Hello World!
```
Use this as the initial known-good baseline when implementing the Java transport and protocol encoder.
---
# Reference artifacts
Known useful reverse-engineering artifacts:
```text
Setup(Sign Manager2.34).exe
Msgeditor.exe
Pcomm.dll
templog.dat
```
Known SHA-256 for the recovered Sign Manager installer:
```text
a043c7b861d2616d04874d3acd00f75be9559ce36830308b9d530f40a9bb8f7b
```
The combination of:
```text
Sign Manager
+
templog.dat
+
static inspection of Msgeditor.exe
+
physical ASC 434 experiments
```
provides a practical path toward fully documenting the protocol and implementing a complete native Java driver.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
Implement a native Java driver for the Sigma ASC 434 programmable LED display.
The display is an older three-color LED sign intended for shop windows and similar installations. It can be controlled over RS-232 and supports significantly more than simply displaying text.
We have successfully recovered the original Windows software, Sign Manager 2.34, made it run under Wine on Linux, and proven that the display can be controlled directly from Linux without Wine.
The long-term goal is to understand enough of the Sigma protocol to control the display completely from Java, without depending on Sign Manager or Wine at runtime.
The original Windows software should remain useful as a reference implementation while reverse-engineering the protocol.
Hardware
Known hardware:
The tested serial configuration is:
In conventional notation:
Original Windows software
The original software has been recovered:
SHA-256:
The installer is an old 32-bit Windows installer and installs the software under:
Important installed files include:
Msgeditor.exeis the main Sign Manager application.Pcomm.dllwas inspected and is not the Sigma protocol implementation itself. It is an old generic serial communication library from Moxa Technologies.It exports functions such as:
The actual Sigma protocol framing appears to be implemented in
Msgeditor.exe.Static inspection/disassembly of
Msgeditor.exehas already been useful and should continue to be used where black-box experiments are insufficient.Running Sign Manager under Wine
Sign Manager 2.34 works successfully under Wine on Linux.
A dedicated Wine prefix is used:
The application can be started with:
Mapping the USB serial adapter to COM1
The Linux serial device can be exposed to Sign Manager as
COM1.The Wine registry mapping used is:
Wine may automatically recreate
dosdevices/com1and point it at/dev/ttyS0.If necessary, stop Wine, delete the generated mapping, and let Wine recreate it using the registry configuration:
The registry can be verified with:
Expected value:
On Arch Linux,
/dev/ttyUSB0is owned by theuucpgroup.Example:
The user therefore needs access to that group:
A new login session is required afterwards.
Important reverse-engineering discovery:
templog.datOne of the most useful discoveries is that Sign Manager does not construct and transmit everything only in memory.
Before transmission,
Msgeditor.exewrites the outgoing data stream to:Inside the current Wine prefix this is:
This makes Sign Manager an extremely convenient protocol oracle.
A message can be created in Sign Manager and then the exact bytes it intends to send can be inspected directly.
For example:
or:
The preferred reverse-engineering strategy should therefore be:
templog.dat.Useful experiments include changing only:
This is likely much faster than attempting to understand all of
Msgeditor.exethrough disassembly alone.Proven direct Linux communication
A message has successfully been transmitted to the display directly from Linux without Wine or Sign Manager.
The serial port was configured with:
This command then successfully displayed:
on the physical Sigma ASC 434:
This proves that:
The same transmission also works by sending the generated
templog.datdirectly:Known
Hello World!transmissionFor a simple message containing:
Sign Manager generated a 42-byte transmission.
Human-readable representation:
Exact bytes:
Equivalent escaped representation:
Current interpretation is that:
appears to start a command/frame.
The following:
appears to address display ID
00.Static inspection of
Msgeditor.exeshowed formatting corresponding to a two-digit hexadecimal display ID.The exact valid ID range still needs to be verified.
The following:
appears to separate the addressing/header part from the command.
The first payload in the example is:
Frames or blocks appear to terminate with:
There is an additional control byte:
between the two blocks in this example.
The final block is:
Its exact semantics still need to be determined.
It appears likely to be related to committing, executing or activating the newly written message.
These interpretations are reverse-engineering observations and must not be treated as final protocol documentation until experimentally verified.
Possible chunking and acknowledgement protocol
Static inspection of
Msgeditor.exesuggests that Sign Manager may not always simply write the complete transmission as one uninterrupted byte stream.There appears to be logic around:
where blocks may be sent separately and a response from the display is read before continuing.
At least one inspected code path appeared to treat response bytes such as:
as positive responses.
This needs further verification.
Importantly, the physical ASC 434 accepted the complete 42-byte
Hello World!transmission in one write from the Linux shell:Therefore chunking/ACK handling was not necessary for this simple transmission.
The Java driver should nevertheless investigate and implement the actual protocol rather than assume that one large write will work for every command.
This may become important for:
The transport/protocol implementation should therefore be capable of:
Required Java driver functionality
The target is not merely a "send text" implementation.
The driver should ultimately expose enough of the ASC 434 protocol to replace Sign Manager for normal operation.
1. Serial transport
Implement native Java communication with the serial device.
The implementation must support at least the known working configuration:
The protocol implementation should not unnecessarily depend on Linux shell commands such as
sttyorprintf.The production implementation must not invoke Wine or Sign Manager.
Transport concerns should be kept separate from Sigma protocol encoding and decoding.
2. Display discovery
Sign Manager contains functionality for scanning for connected displays.
Investigate this operation and reproduce it.
This is important because the Java driver should preferably be capable of confirming that a Sigma display exists and identifying it instead of blindly assuming that a configured serial device contains the expected hardware.
Discovery should be considered when designing the driver's constructor/opening API.
For example, construction/opening may eventually perform operations conceptually similar to:
The exact Java API should only be decided after the discovery protocol is understood.
3. Display ID
Investigate and implement support for:
The known successful transmission contains:
which currently appears to mean display ID
00.The driver should not permanently hardcode
Z00.4. Text messages
Support creating and transmitting text messages.
Reverse engineer and expose the properties supported by Sign Manager, including at least:
The ASC 434 is a three-color display.
Determine the actual protocol representation for all colors supported by the hardware.
The Java API should expose meaningful concepts rather than forcing callers to construct raw control sequences.
5. Stored messages
The sign has internal memory and stored messages.
Determine the memory/message model and implement it.
Investigate:
It is specifically important to determine whether the ASC 434 protocol allows reading already stored messages, or whether stored messages can only be overwritten.
If reading messages is not supported by the protocol, document this explicitly rather than inventing simulated read functionality.
6. Multiple pages
Support the display's concept of multiple pages/messages being shown in sequence.
Investigate and implement:
The Java model should represent this functionality explicitly instead of requiring callers to manually construct protocol strings.
7. Reset memory
Reverse engineer and implement the Sign Manager operation for resetting/clearing display memory.
Determine whether:
This is a destructive operation and should be represented clearly in the Java API.
Particular care should be taken while reverse-engineering this command on the physical display.
8. Date and time
The display supports setting date/time.
Reverse engineer and implement:
Also investigate whether the display can dynamically include fields such as:
inside displayed messages.
9. Brightness
Reverse engineer and implement brightness control.
Determine:
Expose brightness as a typed Java concept once the valid values/range are understood.
10. Remaining Sign Manager functionality
Inspect Sign Manager and document every meaningful operation it exposes for the ASC 434.
The final Java driver should aim to cover the hardware rather than only the operations already known when this issue was created.
Anything discovered while investigating Sign Manager should be added to the protocol documentation.
Reverse-engineering strategy
Use three complementary approaches.
A.
templog.datdifferential analysisThis should be the preferred first approach.
Create controlled experiments in Sign Manager where exactly one property changes.
Example:
Compare the generated
templog.datfiles and identify the changed control sequence.Repeat this for each feature.
Other useful comparisons:
Always change only one property at a time where possible.
B. Inspect
Msgeditor.exeStatic inspection of
Msgeditor.exehas already successfully exposed useful parts of the protocol.This approach should continue to be used.
Useful targets include calls to the PComm API:
In particular, follow callers of:
to understand how outgoing blocks are generated.
Follow:
and related functions to understand:
Relevant readable strings already found in
Msgeditor.exeinclude protocol fragments such as:The executable has therefore already proven to be directly useful for understanding the Sigma protocol.
Disassembly should especially be used for features that cannot easily be observed from
templog.dat, such as:C. Physical-device experiments
Every inferred protocol feature should eventually be verified against the physical ASC 434.
Sign Manager should be treated as the known-working reference implementation.
The direct Linux transmission already proves that the protocol can be reproduced independently.
Keep experiments small and preferably change only one variable at a time.
Be especially careful with:
because these may alter persistent device state.
Protocol documentation
The reverse-engineered protocol must be documented as part of this work.
Do not leave important protocol knowledge hidden only inside Java implementation code.
Document at least:
Clearly distinguish between:
Suggested internal architecture
Keep the following concerns separate:
Do not expose raw protocol strings such as:
to normal callers.
Raw frames may still be useful internally and for diagnostic/debug tooling.
The public API may eventually contain concepts such as:
where these concepts are justified by the actual device protocol.
Do not invent abstractions prematurely.
First understand the corresponding hardware/protocol behavior, then model it in Java.
Error handling
The driver must not silently ignore communication failures.
Expected failure categories should eventually include:
Errors should retain enough context to diagnose whether the problem occurred at:
Diagnostics
Provide enough diagnostics that serial/protocol failures can be investigated without returning to Sign Manager.
Useful diagnostic information includes:
It should be possible to enable logging of raw transmitted and received bytes.
Raw protocol traffic should not be logged unconditionally during normal operation.
A hex-oriented diagnostic representation similar to:
would be useful while reverse-engineering and debugging.
OpenSpec
Capture the driver capability and externally visible behavior in OpenSpec as part of the implementation.
The specification should cover at least:
Protocol implementation details that are not part of the public API should live in appropriate protocol documentation rather than unnecessarily leaking into the public specification.
Out of scope
For this issue:
Msgeditor.exefrom Java.templog.datas the production protocol API.stty,printforcat.Hello World!transmission.Z00is the only valid address.Wine and Sign Manager are reverse-engineering/reference tools only.
Acceptance criteria
The work is complete when:
Hello World!example can be reproduced from Java without Wine.Known-good reference
The following is currently the smallest known working native Linux example:
This has been tested successfully against the physical Sigma ASC 434 and displays:
Use this as the initial known-good baseline when implementing the Java transport and protocol encoder.
Reference artifacts
Known useful reverse-engineering artifacts:
Known SHA-256 for the recovered Sign Manager installer:
The combination of:
provides a practical path toward fully documenting the protocol and implementing a complete native Java driver.