Jump to content
rharmon@sandia.gov

My Lack Of Knowledge On Hex???

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Bryan

Share this post


Link to post
Share on other sites

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...

 

Share this post


Link to post
Share on other sites

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 by Bryan

Share this post


Link to post
Share on other sites

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 by Bryan

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 by Rolf Kalbermatter

Share this post


Link to post
Share on other sites
1 hour ago, LogMAN said:

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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 by Rolf Kalbermatter

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.