Loading...
Serial and IR Automation Specifications and
Programming Guide
for iScan VP20, VP30, VP50 and VP50PRO
Revised - December 2007
Document Contents
0 |
Preface......................................................................................................................... |
3 |
|
|
0.1 |
Information Warranty Statement ........................................................................ |
3 |
|
0.2 |
Document Scope and Limitations....................................................................... |
4 |
|
0.3 |
Document Conventions....................................................................................... |
4 |
|
0.3.1 |
Model Compatibility................................................................................... |
4 |
|
0.3.2 |
Product Introduction ................................................................................... |
5 |
|
0.3.3 |
VP20 (MM604)........................................................................................... |
5 |
|
0.3.4 |
VP30 (MM603)........................................................................................... |
6 |
|
0.3.5 |
VP50 (MM605)........................................................................................... |
6 |
|
0.3.6 |
VP50PRO (MM606) ..................................................................................... |
7 |
|
0.4 |
How does automation work? .............................................................................. |
8 |
|
0.4.1 |
Interface Compatibility ............................................................................... |
8 |
|
0.4.2 |
How is data encoded in digital form? ......................................................... |
8 |
|
0.4.3 |
What is Binary?........................................................................................... |
9 |
|
0.4.4 |
What is HEX? ............................................................................................. |
9 |
|
0.4.5 |
What is ASCII?......................................................................................... |
10 |
|
0.5 |
A brief dialog about remote controlling a VPxx series video processor .......... |
11 |
|
0.6 |
A dialog about input video memories............................................................... |
12 |
1 |
RS-232 Control ......................................................................................................... |
14 |
|
|
1.1 |
The RS-232 Physical Connection ..................................................................... |
14 |
|
1.1.1 |
The Anchor Bay RS-232 Protocol ............................................................ |
15 |
|
1.1.2 |
A Dialog on Checksums ........................................................................... |
15 |
|
1.2 |
Control Commands ........................................................................................... |
15 |
|
1.2.1 |
Example RS-232 Command Packets ........................................................ |
20 |
|
1.3 |
Query Commands ............................................................................................. |
23 |
|
1.4 |
Responses.......................................................................................................... |
24 |
2 |
IR Control ................................................................................................................. |
27 |
|
|
2.1 |
The NEC IR Protocol (Factory Remote) .......................................................... |
27 |
|
2.2 |
The Anchor Bay IR Protocol (Discrete Control) .............................................. |
28 |
|
2.2.1 |
Discrete IR Control Examples .................................................................. |
31 |
3 Automation Command IDs and Values .................................................................... |
42 |
||
|
Appendix A – Decimal-Binary-HEX-ASCII Conversion Table |
Page 53 |
|
|
Appendix B – IR Control White-Paper by Barry Gordon |
Page 59 |
|
|
Appendix C – Help and Support |
Page 68 |
|
2
0 Preface
Thank you for purchasing a DVDO iScan VPxx Series video processor. We believe the iScan will become a favorite device in your multimedia presentation system due to picture quality, ease of use, and the level of control the iScan gives you or your customer over the processed signal. This document is intended to cover the supplemental control functionality that is available for the iScan VP20, VP30, VP50, and VP50PRO.
0.1 Information Warranty Statement
The information presented within this guide is known to be accurate at the time of publication. However, we at Anchor Bay continually strive to improve our products by offering new functionality and features which may in some cases require modification of or addition to the information contained within this document. As always, one should periodically check our website (www.anchorbaytech.com) for updates to our software and the support documentation. Anchor Bay (Anchor Bay Technologies, Inc.) or its subsidiaries, agents, and/or investors may not be held liable for technical inaccuracies or omissions that affect an installed system or device. Responsibility for correct operation of the iScan product within the installed system lies with the installing or integration party (i.e. a Home Theater Installer or the end-user or “customer”).
The iScan VPxx video processors are capable of outputting more types of video signals than many display devices can support. Typically, the menu based user controls have some safety features that prevent most users from executing a command or function that would result in a loss of picture or damage to the display device (typically CRTs fall into this category), or may overwrite settings without any prompt. Direct access to the control system via discrete commands may circumvent these safeties in some cases. Careful planning should be used when configuring the iScan within the system to ensure that it behaves within the design constraints of the installed system and the capabilities of the installed support hardware. If you have just read this and don’t understand what it means – PLEASE contact an authorized DVDO product installer for consultation and installation help. Not getting a picture from the iScan does not necessarily indicate a failure of the iScan device – the display device may not support the selected output format, or there may be some other circumstance which would need to be investigated and remedied to resume viewing operation of the presentation system.
If you are having trouble with this document, or the operation of the iScan VPxx device, please first refer to the User’s Manual included with your device. If you are still not able to resolve your issue, please call our Technical Support Hotline 9AM-5PM Pacific Time, at (U.S. Domestic) 1-866-423-3836 extension 333 or (International) 1- (408)-395-4455 extension 333. Alternatively you may contact our support group at help@anchorbaytech.com.
3
0.2 Document Scope and Limitations
This document will cover the necessary information required to construct and transmit a serial (RS-232) or Infrared (IR) control signal to a DVDO iScan VPxx model video processor. These two basic mediums of control, are intended to convey the intentions of the user or automation system into the processes that operate the iScan. This document will cover the naming conventions, syntax, electrical specifications, and some troubleshooting that may be required for implementation in an installed system.
This document will NOT cover specific automation systems such as Crestron, AMX, Control4, Vantage, Elan, Universal Remote, RTI, Xantec, Niles, Russound, etc., or any programming within these systems. Correct selection of the automation system is the responsibility of the installer, and we do not offer troubleshooting for these systems beyond verification of the correct function of our iScan unit, and protocol confirmation.
This means, if a device is able to communicate with an iScan using another software platform (i.e. our firmware update procedure), the unit is deemed to be working correctly and the problem exists beginning at the wiring and proceeding into the code within the automation platform. In this case, contacting the manufacturer of the automation system is required.
Anchor Bay recommends contacting the automation system manufacturer before conducting the installation to see if they have a driver or control module pre-built for our products. If not, asking them to start work on one will help you (as an installer or enduser) by having their Engineers develop a driver or module that is guaranteed to work with their hardware (the more requests they get, the higher a priority it will be for them). If they do not have a complete library, they may have many of our control codes already in their database. Having this information on-hand will greatly ease the installation of our products. If they have any questions, please refer them to our support line, we will be glad to work with them.
0.3 Document Conventions
0.3.1 Model Compatibility
This document is intended to cover the iScan VP20, iScan VP20 with ABT102 daughter card, iScan VP30, iScan VP30 with ABT102 daughter card, the iScan VP50, and the iScan VP50PRO. This document does not cover the iScan Ultra, iScan HD, or iScan HD+.
This document is intended to be used with the latest versions of software for each of the respective models – this is so that the most current features which have been released are listed, and to encourage our customers to use the latest features and bug-fixes that are available (we use the latest version to develop from – please do not report any bugs for old software). Please check our website (www.anchorbaytech.com) for the latest version of software for your product.
4
0.3.2 Product Introduction
This section is a brief introduction with pictures of each of the models of the iScan VPxx series – it is only intended as a brief “spotters guide” to iScan units. Please refer to your product’s user’s manual or our website for more in-depth product information at www.anchorbaytech.com/products/systems (replacement user’s manuals may be obtained in PDF form at the same website by clicking on the “support” tab and selecting “documentation”).
If you are trying to send a command to the iScan and it won’t accept it – make sure you possess the model you think you have by using this spotter’s guide, and then doublecheck in the command table in the following chapters, that the command is in fact supported for the model you are attempting to use.
0.3.3 VP20 (MM604)
iScan VP20 Front
iScan VP20 Back
This model is based on our iScan VP30 product, but has one less HDMI input and no analog RGBHV input or analog video out (RGBHV or Component). This device is commonly found in entry-level systems where input count is not as critical as getting the best possible processing with legacy source devices. This device may be further enabled with our ABT102 Deinterlacing add-on card for even better processing of interlaced SD content.
5
0.3.4 VP30 (MM603)
iScan VP30 Front
iScan VP30 Back
This model is our high-end entry-level product with the full four HDMI complement, the RGBHV/Component 3 input and Analog video output – with available options like an SD-SDI input and the ABT102 Deinterlacing add-on card for exceptional reproduction of interlaced SD content.
The VP30 also features more in-depth user controls and greater input flexibility, allowing it to be an excellent addition to a high-end home theater system, corporate media presentation system, or digital signage applications.
0.3.5 VP50 (MM605)
iScan VP50 Front
iScan VP50 Back
The iScan VP50, like the VP30, includes a wide selection of inputs and user controls, while further adding our Anchor Bay VRS processing for HD content (1080i Deinterlacing) and added Gamma adjustment controls.
6
0.3.6 VP50PRO (MM606)
iScan VP50PRO Front
iScan VP50PRO Back
The iScan VP50PRO is the first Video Processor to achieve the THX certification for Video Processors, setting the benchmark for video processing. This device is also the first HDMI 1.3 compatible video processor with the same outstanding Anchor Bay VRS HD and SD content processing algorithms of the preceding models, while adding even further configuration and calibration controls for ISF calibration and the new HD-SDI inputs (2x) and 12-volt triggers (2x) for driving external devices like anamorphic lenses and screen masking. This makes the iScan VP50PRO the ultimate in configurable and controllable high-end video processing – all of which can be harnessed through the same automation protocol we have had in the previous models. This makes it easy for systems integrators to upgrade from one iScan VPxx model to the newest to keep their customer’s systems at the cutting edge.
7
0.4 How does automation work?
The iScan line of DVDO brand video processors are designed to enable control and flexibility over various input and output signal configurations – as well as our proprietary algorithms to improve several aspects of video quality and enable new capabilities that legacy devices by themselves are not able to achieve. This product has many features (covered in the User’s Manual) which are intended to make day-to-day use of our video processing product easier in systems from “simple” up to “complex and fully integrated” home-theaters, or “corporate/industrial” applications. It is up to the user or system’s integrator to “turn on” or otherwise set up the unit (and select appropriate auxiliary hardware) to enable this functionality within a given media presentation system. With the exception of some automatic functions which are user selectable (at the time of this writing: Input Selections, Deinterlacing Modes, and Output Profiles), the unit must be prompted by user action to do a specific function or provide a given signal path.
This user function can be initiated by an external device, like a Home Automation controller, Control Sequencer, or Learning/Macro-Infrared-Remote-Control. These execute the “user action” as part of a predefined “routine” or “script”. Home Automation controllers, sequencers, or macro-remotes can control many devices at once, making a task like switching from one source device to another on three pieces of equipment occur with one user input action (this also reduces the amount of remote controls a given system has on a table). The iScan can accept either RS-232 based serial automation commands, or infrared remote control commands to enable very precise and “intelligent” control of the unit’s behavior.
0.4.1 Interface Compatibility
Our devices have been designed to work with industry standardized control systems based on either “EIA232”-“RS-232C” asynchronous bidirectional serial character data transfers, or NEC or ABT-proprietary based Infra-Red (IR) one-way serial character data transfers operating at a 38.38kHz carrier frequency. The control sets for both methods are based on the same command IDs and control values for the sake of simplicity and ease of overall protocol mastery.
0.4.2 How is data encoded in digital form?
Digital electronics are very good with math and numbers – but they do not know how to “think” or talk in human-readable sentences. Because of this, programmers have created a “look-up-table” of standard characters which humans understand, and numerical equivalents for those characters which the device understands. There are several different ways to place characters in a table, and many different geographic locations which have special characters that need to be encoded. For the sake of standardization and compatibility, we have selected the UTF-8 standard which is backwards compatible with the ASCII standard of encoding characters to a numeric table (ASCII only uses 8-bit values between 0 and 127 - the specifics of these two standards are not covered, as numerous references for these are available at public libraries or the internet).
8
0.4.3 What is Binary?
The digital world is all ones and zeros. By placing ones and zeros in a standardized pattern we can encode data that can be exchanged between multiple devices. The lowest level of encoding data is “binary notation”. In this notation, a “bit” represents the “true” or “false” presence of the numeric value at that bit location. Therefore, if the bit representing a “4” was “true”, one would add the “4” to the total of the “byte” (the total size of the number). For our systems and the character-set we are using, we have an “8- bit” byte (meaning there are 8 value “places” representing numbers that are added to each other to generate the final number which the “byte” represents).
There are two ways to notate and send binary data – LSB and MSB. These stand for “Least Significant Bit” and “Most Significant Bit” respectively, and these labels refer to which bit in a given byte is sent first (basically this means that data can be notated left toright or right-to-left – and the data can be sent with the largest value first, or the smallest value first). In this document, we will use the standard of notating MSB 8-bit bytes for sentence (string) construction (largest-to-smallest, left-to-right), and LSB for the communication scheme (RS-232/IR standards).
As an example, the decimal (“0-9”, “10-19”, etc.) notation number of “65” is:
Bit |
7 |
Bit 6 |
Bit 5 |
Bit 4 |
Bit |
3 |
Bit |
2 |
Bit |
1 |
Bit |
0 |
Value = 128 |
Value = 64 |
Value = 32 |
Value = 16 |
Value = 8 |
Value = 4 |
Value = 2 |
Value = 1 |
|||||
0 |
|
1 |
0 |
0 |
0 |
|
0 |
|
0 |
|
1 |
|
If you add: 64 + 1, you get “65”. This is the basis for all future dialog within this guide.
0.4.4 What is HEX?
So you’re probably saying “It’s going to take me forever to figure out how to send Binary data from a PC to an iScan,” or “Boy, do I have to learn binary notation to use the iScan Automation Protocol?” Well the short answer is “no”, you will want this basic ground-work to understand that electronic devices communicate this way – but there is a short-hand for Binary which you will need to learn. It reduces the characters you have to type by ¼ (thus you would type only two characters instead of eight to represent an “8-bit byte”). This is the HEX Notation. HEX is a different “base” number set – where “binary” has two possibilities for each character (0 and 1), the very familiar “Decimal” has ten possibilities (0, 1, 2, 3, 4, 5, 6, 7, 8, 9), and “Hexadecimal” (or “HEX” for short) has 16 possibilities (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A(10), B(11), C(12), D(13), E(14), F(15)). This “shorthand” was selected since decimal doesn’t easily calculate into binary (where each additional bit is a multiplier of two of the previous bit). With HEX, each character represents a “nybble” of a byte (or four bits). Each “byte” is split into two “nybbles” (a high nybble and a low nybble), so that a byte can be conveyed using the same MSB notation with fewer characters to mean the same thing, in a terminal application which accepts HEX.
9
As an example, using “65” again – the HEX equivalent is “41h”. So what’s the “h” at the end? There are two commonly accepted ways to identify HEX notation in a sentence (or “string”). One is with the use of a “0x00” notation, where the two last zeros represent the two HEX characters, or with “00h” showing that this is a two nybble-byte in HEX notation. This can get confusing the more you learn – so take a moment to highlight this section or put a Post-It flag on this page for future reference.
0.4.5 What is ASCII?
Okay, we started this digital primer with the idea that we wanted to send our data from one place to another in a way that the machines could understand. But now what happens if we (humans) want to read it? Well back to the ASCII Look-Up-Table concept that we brushed on at the beginning. If you remember, we replaced a human-readable character with a number so that the machine can understand it. We use the reverse of that table replacement to “extract” the data that was transferred from one device to another.
Recall that binary, decimal, and HEX - all represent different ways to write numbers. ASCII characters represent the Human-readable equivalent of that given number. For example, again using decimal number “65” (binary number: “00100001”, HEX number “0x41” or “41h”) – the ASCII table equivalent is a capital “A”. All four of these numbers mean exactly the same thing to a machine using an ASCII table – capital “A”.
A simple ASCII to HEX conversion table is provided at the end of this document in Appendix A.
10
0.5 A brief dialog about remote controlling a VPxx series video processor
Please be honest with yourself and ensure that you have understood the previous sections. If you’re not confident about how binary = HEX = decimal and relates to ASCII, then you may want to check out the internet for more information on digital information technology – or contact our Technical Support Hotline at (U.S. Domestic) 1- 866-423-3836 extension 333, or (International) 1-408-395-4455 extension 333. Alternatively you may contact our support by email group at help@anchorbaytech.com.
•The first thing this writer suggests when learning the following automation protocol – is to realize that this is a machine talking to another machine – not a human talking to another human. The automation protocol is written for maximum efficiency, clarity, and robustness of communication between two machines - all while allowing for future expansion without requiring us to re-write the protocol every time new features/products come out (thus commands that work in the new version of software should work in just about every other previous version/product – which has the exact same functional control).
•The second thing this writer suggests is learning and understanding the HEX notation
– and how to convert decimal numbers and basic ASCII characters (0-9 and A-Z capitals) into HEX notation. The serial interface works in bytes, and understands numbers – so the closer you can get to understanding this type of communication – the easier this will be for you.
11
0.6 A dialog about input video memories
Due to the number of inputs and different types of input formats and ever further numerous types of source devices, we at Anchor Bay added input memories, which allow the user/system-integrator to configure very specific “effects” for a specific input format on a specific input connection. This means that a single input can have many different settings within the same control – just based on the input format that it is receiving.
As an example, at the time of this writing, for HDMI on the VP50PRO we support:
VGA |
720p-50Hz |
SVGA |
720p-60Hz |
XGA |
1080i-50Hz |
SXGA |
1080i-60Hz |
576i-50Hz |
1080p-23.98/24Hz |
576p-50Hz |
1080p-25Hz |
480i-60Hz |
1080p-50Hz |
480p-60Hz |
1080p-59.97/60Hz |
Each format has its own memory, with individual picture controls, aspect ratios and zooms/pans, processing modes, etc. This can easily make the job of setting up an iScan very involved, as we offer an incredible amount of control over just about every aspect of the processed signal. We have put in functions to our automation protocol which allow an automation controller full access to these parameters – so care must be taken to avoid errors.
Keep in mind that not all inputs support all input types – for example, Composite and S-Video inputs are limited to 480i-60Hz or 576i-50Hz based on the source and the region the iScan is used in.
12
This page intentionally left blank
13
1 RS-232 Control
1.1 The RS-232 Physical Connection
RS-232 connections come in several styles which are accepted in the consumer electronics industry. The most common is the 9-pin D-Subminiature connector found on the back of most computers, and is the one that we use on the iScan VPxx products.
The female serial port, found on the back panel of an iScan VPxx video processor.
In this interface, there are a few different signals which must be supported. These are (all pin numbers are for the iScan):
RX – Data Receive (pin 3) |
CTS – Clear To Send (pin 7) |
TX – Data Transmit (pin 2) |
GND – Signal Ground (pin 5) |
RTS – Request To Send (pin 8) |
|
We do not use the “DSR – Data Set Ready”, “DTR – Data Terminal Ready”, “CD - Carrier Detect” or “RI – Ring Indicator” pins for the iScan VPxx series.
These signals are associated with specific pin numbers based on what type of device the serial port is attached to. There are two types of serial device Data-Terminal- Equipment (DTE) and Data-Communications-Equipment (DCE). A DTE is your computer or an automation system – basically a controlling device. A DCE is a modem, or in this case the iScan. Some manufacturers chose to wire their RS-232 port as a DTE, but we have elected to wire our unit as a DCE. This determines a critical difference in the serial cable wiring to get the unit to communicate with the automation controller or PC. If your automation controller is based on a PC, the serial port is likely to be wired as a DTE port (please check with your automation controller vendor for clarification). This allows the use of a very common straight-through “extension” cable to be used to complete the communication connection (like the type which is shipped with the iScan unit).
When a dissimilar port type is used in a serial connection (for example DTE-to-DCE or vise versa), a straight-through cable is usually all that is needed. However, when similar port types are used, a cross-over cable is required (for example DCE-to-DCE or DTE-to DTE). Please double check the type of connection that you are using before connecting the cable.
14
1.1.1 The Anchor Bay RS-232 Protocol
In this portion of the document, we will discus the three types of control communications that occur between the iScan and the controlling device.
1.1.2 A Dialog on Checksums
Checksums are a way for a receiving device to double check the communication that occurred between the transmitting device and the receiver. In most systems, Checksums are not needed – however some installations absolutely require them (for example: industrial control or corporate teleconference systems). If you don’t already know what a checksum is - you probably will not need it for your application. The system will work fine in 99.999% of systems without the use of checksums. If you need to use a checksum due to customer/job requirements, the calculation and checking calculations are provided in the following sections.
1.2 Control Commands
The “Control Command” is probably why you are reading this document right now. This is a sequence of data which tells the iScan to do something. Until the controller or PC sends an instruction to do something, the iScan will happily do its primary job – processing video.
This writer believes that the easiest way to understand what is occurring is to think of a “serial command” as a public address announcement you might hear in an airport:
“May I have your attention please, John Doe, please pickup the white courtesy phone and press 0. Thank you.”
Essentially the same thing is done with an automation control sentence (or string): “Attention this is a command which is this long and the command controls this
function >>pause<< this is the value I want to set >>pause<< [checksum – optional] I’m done talking”
Hopefully this looks easy. However please remember, electronics don’t speak in fancy human readable sentences, they speak in numbers. This is where human-readable ASCII character look-up-tables and HEX notation come into play, and a lot of confusion can too. Now in the ASCII table there are some basic “characters” which represent some of the bold words above:
“Attention” = Start Text or STX in ASCII >>pause<< = Null or NUL in ASCII
“I’m Done Talking” = End Text or ETX in ASCII
Every ASCII character is a single “byte” (one 8-bit number each) which has been specified to mean what is shown above. Now remember that the ASCII table is meant to convert numbers to human readable characters and vise versa.
15
Also, each of the above “characters” has a related HEX notation number to go with it:
“Attention” = Start Text or STX = 0x02 in HEX notation >>pause<< = Null or NUL = 0x00 in HEX notation
“I’m Done Talking” = End Text or ETX = 0x03 in HEX notation
It is up to the individual programmer to determine which method is easiest to understand – but if you haven’t chosen your programming style yet, this writer recommends sticking with HEX notation. One thing that should be avoided at all costs is mixing HEX notation with ASCII characters – as you may see in the next set of examples, mixing numbers and ASCII will get you very confused very fast (You’re not a computer, so you can’t be expected to keep track of it all). This document will be written from here to the end slanted to illustrate HEX notation, as it demands the use of “bytes” and is easiest for new-comers to get used to recognizing characters which need to be converted from human readable text characters to machine readable numbers.
Let’s take another look at that sentence:
“Attention this is a command which is this long and the command controls this function >>pause<< this is the value I want to set >>pause<< [checksum – optional] I’m done talking”
Now let’s replace the words we know with the HEX notation equivalents:
“0x02 this is a command which is this long and the command controls this function 0x00 this is the value I want to set 0x00 [checksum – optional] 0x03”
We at Anchor Bay have specified the byte value for the “is a command” text’s replacement as a portion of our protocol specification. We have defined a command as two ASCII characters of “3” and “0”. In HEX notation this comes out to two bytes: 0x33 and 0x30 (these must be in this order!). Note that the “is a command” is represented by these two bytes (each 8-bits, or two nybbles).
Let’s look at the sentence again, replacing what we know:
“0x02 0x33 0x30 which is this long and the command controls this function
0x00 this is the value I want to set 0x00 [checksum – optional] 0x03”
This gives us enough to have a “wrapper” for all RS-232 control commands:
0x02 0x33 0x30 [length byte 1] [length byte 2] [Command ID byte 1] [Command ID byte 2] 0x00 [Value x-Bytes] 0x00 [checksum – optional] 0x03
16
Before we start listing Command ID bytes, lets look at the “this long” portion of our sentence. For this, count the two command ID bytes (count the bytes, don’t add the values!), add the count of the two NUL bytes (again, don’t add the values), add the count of the value bytes (this really should sink in now - don’t add the values themselves). This equals the “byte-count” for the command sentence (string) – we are always counting bytes. Below is an example of the bytes we want to count:
Byte 1 |
Byte 2 |
Byte 3 |
Byte 4 |
Byte 5 |
Command ID 1 |
Command ID 2 |
NUL |
Value Byte n |
NUL |
HELPER-RULE: There will always be two command ID bytes and two NUL bytes – and there should always be at least one value byte for a command. This means that you should never have a byte count below “5” for a command. You must also always use two bytes to convey the bytecount value; so an example would be “05” or 0x30 0x35.
For now let’s look at the most simple control of the iScan product – turning its power “on”. The Command ID for the power control (“controls this function”) is “A” and “1”
– hey, if you were reading this from the beginning you’ll recognize capital “A” as HEX 0x41. The people who wrote the ASCII Look-Up-Tables were nice enough to realize that humans would occasionally use the table – so they lined up decimal numbers to the 0x30 HEX range (i.e. 0=0x30, 1=0x31, 2=0x32, etc.). This means that the “1” we need is 0x31.
So the command ID bytes for the power control are (in HEX) 0x41 0x31.
Let’s look at the sentence again, replacing what we know now:
“0x02 0x33 0x30 which is this long 0x41 0x31 0x00 this is the value I want to set 0x00 [checksum – optional] 0x03”
Now let’s look at the value we want to set this to – in the table in Section 3 you will see the commands and the values that are possible. Looking up Power, we see that the values for OFF and ON are “0” and “1” respectively. We already know how to convert the “1” to HEX notation and since we do want to turn the unit “on”, this is the value we’re going to use. “The value” = 0x31.
Let’s look at the sentence again, replacing what we know:
“0x02 0x33 0x30 which is this long 0x41 0x31 0x00 0x31 0x00 [checksum – optional] 0x03”
If you’ve read this far and understand what’s happening - Great! Now the only things we are missing are the Checksum and the length-count bytes. Since the checksum must be the last thing we calculate, we’ll do the length first: Two bytes for command ID + one byte for NUL + one byte for value + one byte for NUL = 5 bytes or “05”. Converting the count to HEX notation we get 0x30 and 0x35.
17
Let’s look at the sentence again, replacing what we know now:
“0x02 0x33 0x30 0x30 0x35 0x41 0x31 0x00 0x31 0x00 [checksum – optional] 0x03”
If you recall, unless your application calls for it specifically – YOU DO NOT NEED A CHECKSUM!!! If your application doesn’t need it, you are done with the sentence construction (just remove the optional placeholder for the “checksum - optional”):
Let’s look at the sentence again, with out the optional checksum placeholder: “0x02 0x33 0x30 0x30 0x35 0x41 0x31 0x00 0x31 0x00 0x03”
Now there is one more detail which you will need to figure out about your automation system: “How or does it accept HEX notation?” Some systems are smart enough to recognize the “0x” as a prefix for a HEX notation number. Others are not. This writer is aware of an example application called “RS232 Hex Com Tool” which does not recognize the “0x” as a prefix. This means that the operator/user/programmer must determine how to enter the data correctly – due to the broad spectrum of programming styles across all of the varied automation systems this is not covered in this guide nor is it the responsibility of Anchor Bay to tell you (the reader). Contact your automation system vendor for clarification on data entry to their system.
As it happens, in the above examples, the byte itself was highlighted with BOLD typeface to bring attention to the actual value for the byte. This highlighted data is also what that particular application expects, with a [space] or [comma] to separate the bytes. Thus the same “power-on” command would be:
02 33 30 30 35 41 31 00 31 00 03 for “power-on” with no checksum
If you are unsure if the automation computer or other machine is working with the serial cable, the “RS232 Hex Com Tool” program is available for download (shareware – free trial for 30 days, purchase for a small fee) on the web at: http://www.rs232pro.com/. Anchor Bay does not warrant the function of this utility or endorse its purchase – this is simply a reference to one of many options available for testing. The open-source Tera Term Pro utility used for upgrading iScan VPxx products is also capable of sending HEX or ASCII strings with some minor programming – but we do not support this use of the program and attempts to use Tera Term Pro as an automation controller should only be taken on by experienced programmers with some basic coding/programming background.
18
The checksum. This is the last part other than the Command ID Table and Value Table you might need to create a command string. Again, unless your customer/job requirements demand/specify it – YOU DO NOT NEED A CHECKSUM!! Assuming that you absolutely need to have a checksum due to a customer/job requirement, the checksum is fairly easy - add the value of every byte from the beginning of the string (at
STX) to the last “NUL” just before the ETX (0x03). For the “Power On” command, this would be: 02 33 30 30 35 41 31 00 31 00
So you would add: 0x02 + 0x33 + 0x30 + 0x30 + 0x35 + 0x41 + 0x31 + 0x00 + 0x31 +0x00 = 0x16D
HINT: You can use the scientific calculator in Windows to figure this out in HEX.
Now we only deal with 8-bit values for bytes – and you can see (if you recall the discussion about nybbles and bytes) that the checksum value is three hex characters or three “nybbles”. This means the result is a 12-bit value. How we take care of this is very easy – drop (truncate) the nybbles above the two lowest nybbles. If you do this to the
0x16D value you get 0x6D. If you are writing a software program – an easy way to do this is to “AND” the checksum value with 0xFF in HEX or “255” in decimal.
If you’ve really been paying attention you’ll remember that the checksum is two bytes – we made it easy to figure out these two by simply taking the 6 and the D (which are part of a HEX notation number from our calculation) and using them as ASCII standins. So assume these two characters are ASCII and convert them down to HEX (“6” becomes 0x36, “D” becomes 0x44). This is a form of data expansion – and is intended to reduce the possible valid bit patterns which can be expected at these two byte locations to 16 possibilities.
For a last look at turning on the power for the iScan, let’s look at the whole string including the checksum (underlined):
0x02 0x33 0x30 0x30 0x35 0x41 0x31 0x00 0x31 0x00 0x36 0x44 0x03
That is all there is to Command Packets. If you are still unclear on how this is supposed to work, or you believe you are doing this correctly, but still have no success controlling the iScan, please contact our Technical Support group.
19
1.2.1 Example RS-232 Command Packets
This section contains the most commonly requested automation command-type strings (no checksums are provided):
Power
On
0x02 0x33 0x30 0x35 0x41 0x31 0x00 0x31 0x00 0x03
Off
0x02 0x33 0x30 0x35 0x41 0x31 0x00 0x30 0x00 0x03
Input
Composite 1
0x02 0x33 0x30 0x35 0x41 0x43 0x00 0x31 0x00 0x03
Composite 1
0x02 0x33 0x30 0x35 0x41 0x43 0x00 0x32 0x00 0x03
S-Video 1
0x02 0x33 0x30 0x35 0x41 0x43 0x00 0x33 0x00 0x03
S-Video 2
0x02 0x33 0x30 0x35 0x41 0x43 0x00 0x34 0x00 0x03
Component 1
0x02 0x33 0x30 0x35 0x41 0x43 0x00 0x35 0x00 0x03
Component 2
0x02 0x33 0x30 0x35 0x41 0x43 0x00 0x36 0x00 0x03
Component 3/RGBHV
0x02 0x33 0x30 0x35 0x41 0x43 0x00 0x37 0x00 0x03
HDMI 1
0x02 0x33 0x30 0x35 0x41 0x43 0x00 0x38 0x00 0x03
HDMI 2
0x02 0x33 0x30 0x35 0x41 0x43 0x00 0x39 0x00 0x03
HDMI 3
0x02 0x33 0x30 0x36 0x41 0x43 0x00 0x31 0x30 0x00 0x03
HDMI 4
0x02 0x33 0x30 0x36 0x41 0x43 0x00 0x31 0x31 0x00 0x03
SDI 1
0x02 0x33 0x30 0x36 0x41 0x43 0x00 0x31 0x32 0x00 0x03
SDI 2
0x02 0x33 0x30 0x36 0x41 0x43 0x00 0x31 0x34 0x00 0x03
AUTO Input Select
0x02 0x33 0x30 0x36 0x41 0x43 0x00 0x31 0x33 0x00 0x03
Input Preset (recall – not save)
4x3 Full Frame
0x02 0x33 0x30 0x35 0x43 0x31 0x00 0x31 0x00 0x03
4x3 Letterbox
0x02 0x33 0x30 0x35 0x43 0x31 0x00 0x32 0x00 0x03
16x9 Full Frame
0x02 0x33 0x30 0x35 0x43 0x31 0x00 0x33 0x00 0x03
4x3 Stretch
0x02 0x33 0x30 0x35 0x43 0x31 0x00 0x34 0x00 0x03
20
Preset 1
0x02 0x33 0x30 0x35 0x43 0x31 0x00 0x35 0x00 0x03
Preset 2
0x02 0x33 0x30 0x35 0x43 0x31 0x00 0x36 0x00 0x03
Preset 3
0x02 0x33 0x30 0x35 0x43 0x31 0x00 0x37 0x00 0x03
Preset 4
0x02 0x33 0x30 0x35 0x43 0x31 0x00 0x38 0x00 0x03
Preset 5
0x02 0x33 0x30 0x35 0x43 0x31 0x00 0x39 0x00 0x03
Preset 6
0x02 0x33 0x30 0x36 0x43 0x31 0x00 0x31 0x30 0x00 0x03
Preset 7
0x02 0x33 0x30 0x36 0x43 0x31 0x00 0x31 0x31 0x00 0x03
Preset 8
0x02 0x33 0x30 0x36 0x43 0x31 0x00 0x31 0x32 0x00 0x03
Preset 9
0x02 0x33 0x30 0x36 0x43 0x31 0x00 0x31 0x33 0x00 0x03
Preset 10
0x02 0x33 0x30 0x36 0x43 0x31 0x00 0x31 0x34 0x00 0x03
Deinterlacing Mode
Auto
0x02 0x33 0x30 0x35 0x34 0x39 0x00 0x36 0x00 0x03
Film
0x02 0x33 0x30 0x35 0x34 0x39 0x00 0x30 0x00 0x03
Video
0x02 0x33 0x30 0x35 0x34 0x39 0x00 0x31 0x00 0x03
Forced 3:2
0x02 0x33 0x30 0x35 0x34 0x39 0x00 0x38 0x00 0x03
Forded 2:2
0x02 0x33 0x30 0x36 0x34 0x39 0x00 0x31 0x30 0x00 0x03
2:2 Odd
0x02 0x33 0x30 0x35 0x34 0x39 0x00 0x33 0x00 0x03
2:2 Even
0x02 0x33 0x30 0x35 0x34 0x39 0x00 0x32 0x00 0x03
Game Mode 1
0x02 0x33 0x30 0x35 0x34 0x39 0x00 0x34 0x00 0x03
Game Mode 2
0x02 0x33 0x30 0x35 0x34 0x39 0x00 0x35 0x00 0x03
21
Loading...