Does anyone have an example of a 232 code that you have used with RTI XP-8
and a pantel 32". I am having no luck.Any Help would be appreciated.

This is what the Pantel website said the power off is.
0xEA ox05 0x27 0x01 0x17
but it doesnt work, also tried same code in an RP-6 just to be safe because this is my first XP-8.

Please contact our tech support and we can assist you.

Thank you!

Joe Pantel

Hi Joe, you need to amend your documentation to include the fact that you need to add a carriage return / line feed (0x0D 0x0A)for your RS-232 commands (except the power on, which works without it). Also, what's up with the really funky DB-9 pinout? Its so odd...

That pin out is weird. Why not 2,3,5

tsvisser: I'm the author of Pantel's serial integration document. You are mistaken about the CR/LF. No carriage return or linefeed is required after any of the control commands. The protocol is binary, not ASCII.

As for the serial pinouts, they are... what they are. :) The pins are simply reversed on that unit. A simple adapter can be made by crimping two IDC DE-9 connectors onto a piece of ribbon cable -- one forwards, one backwards.

Most of the time, when someone is having trouble controlling the displays, if their serial cable is wired right and the baud rate is set correctly, the problem is that they're not putting the hex (binary) codes into their control system correctly. As explained in the manual, some systems want hex represented as, for example, 0xEA, while others are looking for \EA (that's a backslash, not a forward slash), and still others \xEA, and a few will take, simply, EA. I don't recall what RTI expects (\xEA, I think), but that's probably The_Chad_AA's problem.

Note that some systems allows have a separate way to input hex codes vs. ASCII codes; those usually just want straight hex separated by spaces. For example, power off would be "EA 05 27 01 17". I think the MSC-400 works like this.

Systems that only allow you to enter a string generally use one of the forms with a backslash or simply don't support hex codes. The backslash format is an "escape code". It means, "instead of the next character, send the binary code represented here". That's why you don't want spaces. So you'd want something like "\xEA\x05\x27\x01\x17".

This is a really terse explanation, I know. Let me know if I should explain this better and more slowly.

here is power off for rti


hex button clicked
115200 8N1

F0 F9 FE 01 00 00 00 00 00 00 08 FF

Hi Jordan, welcome to the forums. It is true that some of us do need some basic pointers with respect to serial control and ASCII/HEX/BINARY concepts, but the majority of the active users here are quite comfortable interfacing with devices via RS-232/422/485 and we were commenting specifically on the Pantel product. To be technically correct, the serial protocol has nothing to do with the command set, but is in fact a description of the communications method. RS-232 protocol, specifically, is the baud rate, start bits, stop bits, parity, and software or hardware flow control... nothing else. The command language is the description of the language one uses to send data to and interpret data back from the device.

You and I both know that a machine only really works with binary. We can choose to express data in hexadecimal or even ASCII representations of that binary data, which is especially useful since our brains do not work in binary. Of the 256 possible values of an 8 bit binary number or 1 byte, only about 95 of those or so are easily expressed as ASCII as those characters can be literally typed in on our computer keyboards without utilities or keyboard escape sequences. Many times we have to express binary values that are:
1) not convenient or impossible to type literally on our keyboards
2) are more exact and less susceptible to errors in reading, such as using (Crestron escape method) "\x20" for space instead of " " which might be missed when reading in the Crestron IDE (thank you Sharp).
3) will have to be utilized in a checksum calculation and it is just easier to keep everything represented as hex
etc...

I can only recount from recent personal experience where a Pantel unit was not responding to the commands as documented in the Pantel Rev. 1.1 RS-232 guide. Once I added the carriage return line feed, it started to respond. Now I admit that this could have been due to some other reason. I'm not trying to tell the author of the command language what he programmed, but I am just telling you what I experienced. Perhaps the extra 2 bytes of data forced through the checksum byte which had previously been held in some buffer and not transmitted / received? why? flow control issue?

I would like to take this opportunity to give some feedback on the RS-232 protocol and pinout of the connector that Pantel chose. Technically, the only true "standard" for RS-232 exists on DB-25. Of course this connector was abandoned in the computer lab and the CE industry for the most part uses DB-9, sometimes DIN, barrier strip / phoenix / molex, etc. It would be de facto true to say that DB-9 is more or less the standard, though, and when using DB-9, it would be expected that pin 5 is ground and the transmit / receiver lines would be pins 2 and 3. Also, the default settings of a Crestron serial port in the Crestron IDE is 9600 8 N 1 none and I find that most manufacturers have chosen that as their default protocol too... as it helps us programmers since we don't have to modify the default settings and probably helps your help desk too, as you don't have to deal with novices who don't know much yet and just make a silly mistake. If the cable is female to female, it is generally expected that the connection is nulled or swapped between pins 2 and 3. If the cable is male to female, it is generally expected that the connection would be straight through. If you decide to use hardware flow control, it should be expected to be on pins 7 and 8 and the same conventions follow with respect to straight through / nulled for RTS/CTS lines. Those manufacturer's that stray from this, although not technically wrong, since we are nitpicking about a "standard" that is a departure and bastardization of the DB-25 standard, are subject to a little under breath swearing, muttering, or otherwise cursed out.

that's actually the power on command.

tsvisser: I will try to ignore your condescending tone and answer just the facts of your post. Before I do so, let me, for the record, bow down before your impressive 1,075 posts since March of 2002. Now that I've kissed your ring, can you please communicate like a peer and not attempt to lecture me? I promise not to whiz on your tree.

I am not the author of the Pantel firmware or the designer of their hardware. I wrote the serial documentation for them. I was not in control of the the implementation of the protocol, the pinouts on the connector, or anything else. By the time I received the Pantel equipment so I could document it, it was fully designed and manufactured -- it was "read-only" so far as I was concerned. If you've never been involved in the creation of a new piece of consumer electronics, it's hard to understand the process, but suffice to say, I was the last guy with his hands on the devices.

That said, while it may be a "quirky" control interface, what with the non-standard pinouts and the packet-based binary protocol (which is actually pretty powerful, but, for some reason, nobody reads far enough in the manual to even know it's there), it's not a bad product and it's easily the best outdoor display I've worked with. Joe Pantel, the owner of the company, is a very customer- and integrator-focused guy and this unit was in their very first line of products for their then-brand-new company. All in all, I think they did a bang-up job. I've given them some feedback for future iterations of the products, and they were receptive. But please keep in mind that to make a piece of specialty consumer electronics equipment, you need to rely on a number of off-the-shelf modules and integrated circuits ("chips"), and you're often not in control of, for example, the serial protocol that some module you need to use implements. These "OEM" components generally originate in Asia, where AV integration is not common, so the serial protocol is almost always an afterthought (ditto for discrete IR codes).

Also, please don't lecture me about the technical details of asynchronous serial interfaces. I design consumer and industrial electronic components and systems for a living and am well-versed in the ins and outs of these things, as they're the bread and butter of my field. I'm not terribly interested in addressing your description point-by-point (or picking it apart, as you've done to me), but I guess I'll talk about a few things in the hope of helping anyone who's reading this thread and trying to learn something from you and I. Please don't take this to mean I think you don't already know this stuff. I just want to make sure the info as attached to the thread available to people.

1. A protocol is an agreed-upon communication scheme between two or more parties. There is a signaling protocol "spoken" on the physical wire, generally called "asynchronous serial" that involves sending 0s and 1s (actually, "marks" and "spaces") in a way that allows one device to send bytes of data to another. Start bits and stop bits (the "framing"), data bits, the parity bit (if present), and baud rate (the speed of the marks and spaces) are all part of that protocol. There is also a physical interface which defines electrically how devices are connected and how they represent marks and spaces to each other. RS-232, RS-485, RS-422, etc. are all implementations of the asynchronous serial protocol that use different physical interfaces. This is more than anyone wanted to know, though.

However, once you've got bytes moving between your equipment, those pieces of equipment needs to be able to understand the meaning of those bytes. They also have a "protocol" that describes what different sequences of bytes mean. This is what you're calling the "command language", and that's a valid description of what it is in this case. But it's just a special case of a protocol. The Pantel protocol (or any other protocol, for that matter) operates "on top of" the asynchronous serial protocol, just like English can be written in ASCII, which can in turn be sent on a serial line as bytes. These things are all "protocols", so let's not confuse people with contrived terminology.

2. Adding CR/LF to messages in the Pantel protocol is unnecessary, but won't break anything. The Pantel protocol is packet-based, so there's always a clear beginning and end to a command or response packet. "Noise" bytes outside the packets will be ignored. There is no flow control or fixed-byte-count buffering in the unit, so while it's true that CR/LF won't hurt things, adding them also won't help. Note that there _are_ timing restrictions in the protocol in that some packets can't be sent back-to-back without first accepting the display's response to the previous packet (or at least pausing the transmission while it sends it, even if you're just ignoring it -- the manual covers all this). The time wasted sending superfluous CRs and LFs might ameliorate this as a side-effect, but it's not a reliable solution and is not recommended.

3. Everyone -- you, me, Pantel, everyone -- is aware that the DE-9 connector on the display is wired in a totally non-standard way. It is in fact backwards, flipped 180 degrees. Pin 1 is 5, 2 is 4, and so on. This is related to the process of getting the units built and was not a conscious choice Pantel made. The pre-integrated module they had to use (for design reasons not worth going into) have the connectors soldered to the board and the traces on the boards are laid out in such a way that the pinouts are wrong. This is almost definitely a "mistake" someone made, but that someone doesn't work for Pantel; they work at some supplier to some other supplier up the chain. Pantel has said they'll be paying attention to it in future products, but even so, it may not be something they're in a position to control without greatly impacting the cost of the unit.

If you've ever struggled with a seemingly-stupid aspect of a product made by a company who should know better, this is almost always the explanation.

I'm concerned at this stage that someone might think I'm speaking for Pantel -- I'm not. I was an outside contractor on this project and I was not involved in or privy to the design process in any way. However, I do have some experience with projects of this type, so it's easy for me to understand how this can happen and try to convey it to you.

4. Just to be complete, it's unlikely anyone reading this has ever actually encountered a DB-9 connector in their entire life. I know I haven't. The connector most people call a "DB-9" is actually a "DE-9". The "D" is for "D-subminiature", the family of connectors with this basic shape. The "9" is the number of contacts (pins). The "E" is the shell size. B-size shells are what you find on older 25-pin serial interfaces and PC parallel ports. "E" is the smaller size used for 9-pin serial ports, and for 15-pin VGA ports (which are correctly called "DE-15" and not "DB-15HD" as is common). The Wikipedia page on "D-subminiature" connectors has a clear diagram of shell sizes right at the top.

Anyway, there it is. I don't know why your response stuck in my craw (okay, I kinda do), and I'm not trying to perpetuate a flame war. I only sent my last post to make sure the correct information was attached to this thread so future searchers would find it, and, a small bit of ego reconstitution aside, I'm posting this for the same reason. I'm not a regular reader of Remote Central (though I think it's a great site), and I don't expect I'll even keep following this thread, but if anyone wants more info on the Pantel stuff, please feel free to PM me.

++J

Hi Jordan,

My welcome to you to this forum was genuine and I apologize if I have come off as being snide or condescending. That certainly was not my intent. We are a group of people who spend time talking to machines more than we do people and sometimes when we have an audience willing to listen to us other than a group of circuit boards with DB-9 connectors, I suppose we like to make our points heard.

I had assumed that the collaborative nature of product development made it a complex compartamentalized process and I did not mean to accuse you specifically for that. You confirmed that and thought it was a valuable opportunity to communicate to someone not only with the company, but very close to the issues that us integrators deal with. **edit, my incorrect assumption given your contractor status**

You are, I'm sure, more expert than myself on serial communications. The different physical and communication layers are for the most part, abstracted from us, so our viewpoints are different and I acknowlege that my explanation was either too simplistic given the audience I was addressing or outright wrong, in which case you have the full right to add corrections.

Again, welcome to the forums. We really do appreciate manufacturer participation and value what you have to offer.

The fact remains that the display would not operate correctly until the Cr/Lf was added.

jordancoleman you seriously need to stop taking yourself so seriously. The "condescending tone" was only seen by you. Are you paranoid?

Just so you know the CI's here have been grateful that Joe Pantel is on here. I for one push the Pantel TV's whenever I can because I feel that the company is a great company. Despite your condescending tone, assuming that the people here wouldn't want to know or wouldn't be smart enough to understand what you are talking about, a lot of us like to know as much as we can about our jobs.

So jordan the next time you think that you want to use your condescending tone keep that crap for someone else. But if you just want to pass some knowledge on to us then bring it on.

When in doubt, whip it out?

Got it. Thanks Guys