My Lack Of Knowledge On Hex???

[rharmon@sandia.gov]

Once again my lack of knowledge on Hex is byte(ing) me....

According to documentation this is the hex string I'm supposed to use to communicate with my UPS.

Write

7E03 0218 009B

Read (UPS should return)

7E05 0318 B004 52

The command should be parsed as follows in my write example

Header (1 byte), 7E, Type (1 byte) 03 Polling Command, Length (1 byte) 02 # of bytes from Report ID to Data, Report ID (1 byte) 18 Inquire Input Voltage, Data (64 bytes max) 00 no data sent, Check Sum (1 byte) 9B Sum of bytes from Header to Data Overflow Ignored

So that all seems to make sense to me, but I can't get it to work.

So I gave up and ran their software and looked at what was crossing the comm port. This is what I saw

Write

7E 30 30 50 30 30 34 53 4F 4C 31

Read

7E 30 30 44 30 30 31 30

I understand this is not the same Report ID as my example, it is more than likely Report ID 50 which would be PresentStatus

What am I missing????

Thanks in advance...

Bob

[crossrulz]

Well, I'd say you've been lied to on the protocol.

Interestingly, all of the bytes (except for the initial byte) are alpha-numeric.  If I convert your hex values to ASCII I get:

Write: 00P004SOL1

Read: 00D0010

This still means nothing to me.  Just thought I would go through the exercise in case it sparks someone's thought process.

 

[Bryan]

Have you tried duplicating the same command/response with your LabVIEW code?  I'd be interested to know if you'd get the same result.  If so, I agree with crossrulz - that something is up with the protocol.

[Bryan]

I wonder if it's a mix of hex and ascii somehow based on what crossrulz said - like the 7F is supposed to be a hex byte (non-printable character), but the remaining values (including possibly the checksum) are to be the ASCII representations of the numbers... for instance:

7F 03 02 18 00 9B

Could really be sent as:

7F 30 33 30 32 31 38 30 30 39 42

(Again, I'm not sure if the checksum would have to be ASCII or Hex... you could try it both ways. )

 

Edited June 1, 2020 by Bryan

[rharmon@sandia.gov]

Bryan,

Not quite sure what you mean by duplicating the same command/response.

I just noticed something in my first post might be a little misleading

Although I did view this on the comm port for a write command

7E 30 30 50 30 30 34 53 4F 4C 31

This is what I sent on my labview code 7E30 3050 3030 3453 4F4C 31

When I send this from my labview code 7E30 3050 3030 3453 4F4C 31, I get back this 7E30 3044 3030 3130  from the UPS.

Not sure if that's important or not...

 

[Bryan]

Okay, sorry... I thought maybe you were monitoring THEIR software command/response by some method.  When I said "duplicating", I thought you hadn't tried it with your code yet, it sounds like you have.  So you're communicating with the UPS now?  Good!

I'm still wondering though if it's expecting hex values that would represent the ASCII characters for the ...03 02 18 00... and possibly the "9B".  

I'd be interested to see if you get any responses for the following commands.  They are what I was trying to explain above (though, probably not explained well... I'm not always good with the words putting together thing):

7F30 3330 3231 3830 3039 42

OR

7F30 3330 3231 3830 309B

Edited June 1, 2020 by Bryan

[Bryan]

I don't know if this explains what I'm trying to say better:

ASCII:  � 0  3  0  2  1  8  0  0  9  B
HEX:   7F 30 33 30 32 31 38 30 30 39 42

OR

ASCII:  � 0  3  0  2  1  8  0  0  ›
HEX:   7F 30 33 30 32 31 38 30 30 9B

 

Edited June 1, 2020 by Bryan

[rharmon@sandia.gov]

No response from either...

[LogMAN]

12 hours ago, Bryan said:

I don't know if this explains what I'm trying to say better:

ASCII:  � 0  3  0  2  1  8  0  0  9  B
HEX:   7F 30 33 30 32 31 38 30 30 39 42

OR

ASCII:  � 0  3  0  2  1  8  0  0  ›
HEX:   7F 30 33 30 32 31 38 30 30 9B

 

11 hours ago, rharmon@sandia.gov said:

No response from either...

There might be a typo in @Bryan's example. The first byte should be 7E instead of 7F (based on the previous data).

Still, this is guesswork at best and not much better than brute forcing every possible combination. You have proven that your code works, so this is a good time to talk with the supplier.
Maybe they can provide you an example or verify that the data you are sending is correct.

[Rolf Kalbermatter]

Your UPS seems to be a SmartOnline model. Looking at the NUTS source code I see that the protocol is constructed as follows:

~00<message type><3 bytes: decimal length><3 bytes: command><remainder: parameters>

So:

7E 30 30 50 30 30 34 53 4F 4C 31

as crossrulz pointed out translates to

~00P004SOL1

which means

- P for Poll
- 004 for message length
- SOL for relay status
- 1 relay number (my guess)

The answer is:

~00D0010

which means

- D for data
- 001 length
- 0 relay status

Try to send for lolz

~00P003IDN

A robust receiver implementatation will first read 4 characters. These should be either ~00D or ~00A. 

A means an acknowledge of the command without further data and D is a response with additional data. Anything else is an error and you should flush the buffer.

So if you receive ~00A you are done, otherwise you read the next three bytes and interpret it as a decimal number. This is the number of remaining bytes to read.

 

As you can see in those sources there are actually several protocols for Tripplite. The other seems to be the Omnivis type protocol which uses 

:<1 or 2 bytes: command><optional: extra parameters><carriage return>
  
:D\r     // request status message

even for their USB interfaces that are not HID based.

Edited June 2, 2020 by Rolf Kalbermatter

[Bryan]

1 hour ago, LogMAN said:

There might be a typo in @Bryan's example.

Yeah... that was my bad.  Sorry about that.  

[rharmon@sandia.gov]

Everyone... Thank you

I contacted the company today honestly tech support is trying to help but they don't understand the communications portion so they can't really help. He offered to ask the subject matter expert if he would be willing to talk to me. That was this morning, still no response so I'm beginning to feel hurt cuz he doesn't want to talk to me... Oh well I guess I'll get over it.

Bryan I noticed the typo right away so it didn't effect me, I just followed what you were saying and it helped.

Rolf thanks for the explanation, I think it may have really helped. Especially with the NUTS source code. I'm a labview guy so it's not going to be easy but there is a bunch of information in there... I might be able to piece it together. Especially with your explanation.

I sent ~00P003IDN and the response was ~00R I kind of expected some model number or something.

I think lessons learned here are the protocol document Tripp-Lite is sending out is wrong. The commands I'm sending don't even come close to the format the protocol document states.

Again, thanks to everyone who chimed in... I'm feeling optimistic I can get something accomplished here.

Bob

[Rolf Kalbermatter]

11 hours ago, rharmon@sandia.gov said:

I sent ~00P003IDN and the response was ~00R I kind of expected some model number or something.

Well ~00R means reject. That is of course not to helpful but it tells you that:

1) you can send commands to the device

2) It receives them and reacts to them

I checked the source code and it's my bad. The identification command is UID, so try that instead of the IDN. Must have been thinking of GPIB/SCPI when I wrote that part.

Now the next command to try is would be the ~00P003VER vor a version query.

Then the various status commands STA, STB, STI, STO. 

Edited June 3, 2020 by Rolf Kalbermatter

[Bryan]

@rharmon@sandia.gov I'm glad to hear that you're making progress!  Hopefully TrippLite is able to help. 

[rharmon@sandia.gov]

All,

Once again I want to thank everyone who chimed in to help me figure out this communications issue. I have attached a small project file that communicated with the Tripp-Lite SmartOnline UPS. If Tripp-Lite tells you to use communications protocol 4001then this software should work.

To say again, Tripp-Lite was not helpful. The protocol document they sent me in no way works. Not even close.

What was helpful.

1. Input from you guys who chimed in here. Huge help... Thanks.

2. https://github.com/networkupstools/nut/blob/master/drivers/tripplitesu.c   although I don't do C, reading the information here was very helpful

3. The Tripp-Lite Programmable MODBUS Card Owner's Manual. A colleague at work found this document and although it doesn't translate perfectly it was helpful.

4. My bullheadedness and refusal to give up when I knew it should be able to be done.

So obviously without input from Tripp-Lite I can give no guarantees on the accuracy of this code. I feel it's right. If anyone wants to try it and let me know how accurate you think it is... That would be helpful. Even better yet if you find errors please let me know.

Thanks again,

Bob Harmon

Tripp-Lite Project.zip