SimCenter Firmware Status v1
Custom firmware for DecaBox and RS232 Driven DMX Engine
The firmware issues and their statuses are summarized in the table below. You can click the name to
jump to a longer description.
Number Name
1
Debug messages should be off by default on RS232 Driven
DMX Engine.
Status
Done. Tested by Michael.
2
DecaBox is streaming at 120-150 characters per second
instead of 22 Hz.
John is looking into it and
expects to have a revision ready
at end of 12/18/2013.
3
Out of bounds channel number returns “Error[cr]” and
“Done[cr]” instead of “Done[cr]”.
John is looking into it and
expects to have a revision ready
at end of 12/18/2013.
4
Out of bounds blocksize is not checked by either r or R
command.
John is looking into it and
expects to have a revision ready
at end of 12/18/2013.
5
Out of bounds combination of channel number and
blocksize does not return “Error[cr]”.
John is looking into it and
expects to have a revision ready
at end of 12/18/2013.
Page 1 of 6
1 Debug messages should be off by default on RS232 Driven DMX
Engine
The RS232 Driven DMX Engine sends too many messages back. We wanted it to send “Done[cr]” back
for the R and r commands but it sends back much more. For example, if you send it “R001@7[cr]” then it
responds with:
lower:
size:
upper:
Done[cr]
1[cr]
7[cr]
7[cr]
It should only send “Done[cr]” back. If you then send the data with the r command, for example
“rZZZZZZZ”, then it responds with:
got Z A5[cr]
6 to go.[cr]
got Z A5[cr]
5 to go.[cr]
got Z A5[cr]
4 to go.[cr]
got Z A5[cr]
3 to go.[cr]
got Z A5[cr]
2 to go.[cr]
got Z A5[cr]
1 to go.[cr]
got Z A5[cr]
0 to go.[cr]
block copy[cr]
Done[cr]
Again, it should only respond with “Done[cr]”. It is probably left over debug messages? Could you send
us a version with those extra messages removed?
John replied that the debug mode was left on. It can be turned off with the command “Debug Off[cr]”.
He created a new firmware version that has it off by default. Michael has confirmed that the debug
mode is off by default in the new version.
Page 2 of 6
2 DecaBox is streaming at 120-150 characters per second instead of 22
Hz.
The DecaBox in streaming mode only sends 120-150 characters per second (CPS) when using RealTerm. I
have changed the baud rate to 115200 so that should not be the limiting factor. We wanted to able to
sample all the DMX channels at 22 Hz or better which corresponds to 11,264 Bytes/Second (22 Hz * 512
Channels * 1 Byte/Channel ). That means the DecaBox is streaming about two orders of magnitude
slower than what we wanted.
John has verified that it is slower than expected and is working on a new firmware version.
Page 3 of 6
3 Out of bounds channel number returns “Error[cr]” and “Done[cr]”
instead of “Done[cr]”.
Section 5.4 in the specification says the channel number XXX must be within 1 and 512 but when I
execute the following command:
R513@1[cr]
I get the following response:
Error[cr]
Done[cr]
I expected to only get “Error[cr]” back.
John is working on it.
Page 4 of 6
4 Out of bounds blocksize is not checked by either r or R command.
I noticed was that the blocksize is not checked. The specification section 5.4 says “In raw mode, a block
of up to 254 channels is represented by byte values.”. I understand that either the R or r command
checks that the blocksize is within [1;254]. That is currently not checked by either of them. If I send:
R001@511[cr]
rzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzz
I get two “Done[cr]” messages instead of at least one error message. I think it would be easiest if the R
command does the blocksize bounds checking. I have suggested that we make the R command do the
checking. For example:
Host sends
DecaBox
response
Comments
R001@511[cr]
Error
Out of bounds because 1+511 >
254. No changes to the raw
mode settings.
Page 5 of 6
5 Out of bounds combination of channel number and blocksize does not
return “Error[cr]”.
The specification says:
5.6
Boundary conditions
If offset and blocksize exceed 512, only values for channels up to 512
are written. An Error is returned.
Example (each row is one command sent during the same session)
Host sends
DecaBox Input
Buffer
DecaBox
response
Comments
R510@5[cr]
R510@5[cr]
Done
Command received and processed
r12345
r12345
Error
Command received and
processed. Channels 510 to 512
are updated, remaining data is
ignored. Input buffer is
flushed. Error is returned.
When I execute those examples I get “Done[cr]” for both commands. So that’s a mismatch between the
specification and implementation. I think the bigger problem is that the specified error handling is
confusing. The bad input is introduced with the first command but it is the second command that is
specified to return the error. That is more complicated than it needs to be and more difficult to code
against.
I have suggested that we change the specification to the following:
Host sends
DecaBox
Comments
response
R510@5[cr]
Error
Out of bounds because 510+5 > 512.
No changes to the raw mode settings.
Page 6 of 6