CI the string you created "%38%33%34%35%31%31%44%39" is incorrect. This is the hex for the ascii string rather the the byte values.

You should be able to create the string and paste it into another program using the ALT key method, unless some character set conversion issue kills it.

Let's see if this works for you. Paste this into a excel spread sheet cell, and then paste out the displayed contents into your terminal program.

=CONCATENATE(CHAR(131),CHAR(69),CHAR(17),CHAR(217))

Eric, THANKS,

I will try this, and post the results later today (Saturday)...

Harris

Eric, it was worth a try....but as copied from Excel, all the characters in the generated string did not paste correctly.

I also tried the slightly different string you had provided earlier, but as above, my computer would not copy and paste the symbols exactly as they were.

I guess I have to give up on this, but again, I appreciate the help.

Harris

I found this about send the codes with hyperterminal:

"You can also use an old DOS trick to send particular ASCII values that may not have control-key equivalents. Hold down the Alt key and type the decimal ASCII value on the keyboard's numeric keypad (not the number keys along the top of the keyboard), then release Alt. Precede the number with a 0 (zero). For example, to send ASCII 133, press and hold Alt, type 0 1 3 3 on the keypad, then release Alt.

Don't leave out the 0 (zero) preceding the number! If you do, the actual value sent can be changed in odd ways. For example, ASCII 14 sent as Alt-down 1 4 Alt-up works fine, but ASCII 15 sent as Alt-down 1 5 Alt-up gets translated to ASCII 164.

The smart customer who pointed out the necessity of the leading zero speculates that it has to do with Windows' conversion of character codes to the DOS character set."

So try:

ALT key method above with these codes:

0131
069
017
0217

Eric,

I just tried it, and indeed characters were generated but these were not the same as the ones I got from the Excel conversion or from the ones you had posted.

Something like an a with a carrot, a heart, 2 capital E's, a return symbol, and a capital Y.

Not sure if these would be a different command for the 990....

tried it again and got the following:

ƒEÙ


Is this string correct?


(nothing printed out when using the alt-017-alt command, although the 0131, 069, and 0217 commands did print, and resulted in the ƒEÙ string).

For alt 017 I get a left pointing arrow head. That should be the same thing you see when pressing control-q. If you don't see anything hitting control-q, then x-on, o-off protocol is probably turned on.

To turn off XON/XOFF , file->properties->settings->emulation and select ANSI.

That should disable xon/xoff and you should get a character when hitting control-q

Eric,

I am trying to get the codes in the Terminal mode of the Stargate HA controller I mentioned; unfortunately, using control-q doesn't allow any symbol to be printed.

In the regular HT program, I get a Heart, an E, a left arrow, and a capital Y.

This can't be copied to the Stargate controller, and as mentioned, the only characters I get with it are the ƒEÙ characters (with nothing shown for the 017 entry...even when pressing control q while entering the 017.

I think there is no way to get this to work as I needed...

The characters you see are somewhat irrelevant and will differ based on the text encoding used by any given program. Most programs for US Windows are going to use the Windows 1252 code page, which provides a paritcular mapping of glyphs (visible representations of characters) to binary values (bytes, or sequences of bytes if the encoding is multi-byte or variable byte.)

So if you spit out a sequence of bytes in any particular program, you might see different results according to whether they are using Windows 1252, Unicode, ASCI, Latin 1, etc... code pages. All that really matters is what the binary values are.

If you are trying to send some binary sequence from a small controller, and you can only issue ASCII characters and it's really only ASCII characters, then you may be screwed because ASCII doesn't define any characters with the high bit on. There are variations on ASCII that do and your controller might use such a variation.

Most such systems should provide some sort of 'escapement mechanism' by which you can generate untypable characters, such as the %xx scheme used in one of the examples above, where XX is the hex value you want to send or \xYY, where YY is the hex value you want to send. If it doesn't, you may be out o' luck.

Dean, thanks for the explanation.

If I understand correctly, if I pasted the above command, %38%33%34%35%31%31%44%39, into the controller, despite not seeing anything but this exact set of characters, it may work? Or, putting the characters ƒEÙ may work?

Is there any way to know if my controller sends the correct command (either of the two commands above, for MUTE) without actually seeing a change in the characters displayed in the controller?

Thanks...

(BTW, happy 2006!!!!)