-1

I have this as hex = 81869400 and I need this in decimal = 948681000

In the description I can see that the coding is a BCD8. I have invested a lot of time but cannot find the way.

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
Gamsner
  • 117
  • 1
  • 9
  • 1
    There are several methods you could use. But if I convert hex 81869400 to decimal, it is 2173080576. Where does 948681000 come from? – Ronald Jul 25 '20 at 20:36
  • This are values from an energy meter and the payload is MBUS coded – Gamsner Jul 25 '20 at 20:45
  • 1
    That still doesn't change the fact that the decimal value of hex 81869400 => 2173080576. So, how do you get the value 948681000? – Ronald Jul 25 '20 at 20:48
  • There i a display on the meter which shows that. And there is aswell a billig system which shows that. – Gamsner Jul 25 '20 at 20:49
  • 2
    Uh, don't know exactly *what* is shown to you, but its certainly not twice the same value in different formats. Either you are overlooking something, or ... wait! The second value is not a decimal, it is little-endian versus big-endian apart from one extra zero in your second value which absolutely does not belong there. Now, please share your code, so I can help you convert the value to what you need. – Ronald Jul 25 '20 at 21:01
  • I have no code, but another examples: 44410500 -> 54144000 – Gamsner Jul 25 '20 at 21:11
  • 1
    Without code I'm not able to help you any further. See [ask] and [mre]. The only thing I can see that each pair of digits is displayed in reversed order. Maybe you can do something with that information. – Ronald Jul 25 '20 at 21:18
  • thanks anyway, I will try to find it based on that infrmation – Gamsner Jul 25 '20 at 21:20
  • You did help me... It nothing to enode or parse, Its just a flipping around as you mentioned... AABBCCDD has to become CCBBAADD and thats it. Thanks again – Gamsner Jul 25 '20 at 21:28
  • All is well that ends well ;-) – Ronald Jul 25 '20 at 21:35
  • Is 948681000 really the correct answer. This looks as though you need to transpose the bytes. 81 86 94 in reverse is 94 86 81. I guess you are reading bytes using an integer on a little endian machine (Intel) causing the bytes to be reversed. I would suggest processing the data as bytes. – Bruce Martin Jul 25 '20 at 23:56
  • could it be that the first number is simply a hexadecimal number? in this case each digit of the hexadecimal number can be either a digit from 0 to 9 or a letter from A to F. In your case no letters appear, but the conversion procedure, in your case it can be to multiply each digit starting from the right for power with 16 as base and digit position as exponent, proceeding to the left to the last digit, obtain a series of addends that summed give you the result. I have not performed verification calculations because (BCD8?) I give you only an idea. – Paolo Fassin Aug 17 '20 at 00:33
  • BCD processing could use 2 nibble of a byte to contain 2 values from 0 to 9. Many CPU INTEL AMD supports assembly instruction to implement sum, multiply etc. – Paolo Fassin Aug 17 '20 at 00:42
  • the weight of bits of BCD nibble can be also the format of BCD encoding (example; BCD 8421). – Paolo Fassin Aug 17 '20 at 00:48

1 Answers1

1

Found the solution thanks to some comments. BCD coding means the value is not in hex but in decimals coded "looking" its hex or binary, but its not.

So it was just needed to have the right ordering. Then in another part of the message there was a factor mentioned.

By ordering and factor it was possible to create the correct values.

Gamsner
  • 117
  • 1
  • 9