DS18B20 -Convert Serial to HEX

[prankenandi]

Hello,

I'm a beginner with Arduino and programming in general, so my apologies if this is a silly question.

For the last couple of days I've been working with DS18B20. So far I have a basic understanding and work with it.

However, reading lots of introductions they always convert the serial number of a DS18B20 from "int" to "hex".

For example, from
sensor_1 = {40, 203, 2, 7, 214, 1, 60, 109}
to
sensor_1 = {0x28, 0xCB, 0x02, 0x07, 0xD6, 0x01, 0x3C, 0x6D}

For addressing a certain sensor I tried both and both works fine.

Now my question is, why is it advantageous to convert to hex?

Thanks in advance!

[anon73444976]

There is only binary, and hex is easier for humans to read as binary than decimal is.

[anon57585045]

Also, hex or binary format can emphasize or highlight the fact that individual bits in a value are important, instead of irrelevant to the representation of some ordinal number like 7. In addition to making the bits easy to decipher.

[prankenandi]

aarg:
Also, hex or binary format can emphasize or highlight the fact that individual bits in a value are important, instead of irrelevant to the representation of some ordinal number like 7. In addition to making the bits easy to decipher.

OK, so it's just because of a better readability.
Thanks in advance!

[anon57585045]

prankenandi:
OK, so it's just because of a better readability.
Thanks in advance!

... and a more meaningful representation...

[wildbill]

In this particular case, the format is largely irrelevant - you have to find out the addresses of your sensors and put them into your code. After that you can forget about what they actually are.

[anon57585045]

they always convert the serial number of a DS18B20 from "int" to "hex"

Do they? I would really like to see that. How did it become an "int" in the first place?

[DVDdoug]

There is only binary, and hex is easier for humans to read as binary than decimal is.

So yeah... Everything in the computer/processor is binary and by default numbers are converted to and from decimal by C/C++. But you can optionally show the values (or input the values) as hex or binary.

Not every binary variable/value directly represents a "number"... For example, decimal 65 (=hex 41 =binary 00100001) might represent the number 65 or it could represent [u]ASCII[/u] letter "A" or it might be part of a color or a microprocessor instruction, etc. The software has to know the context/use to know what it represents. If you open a file with a hex editor you'll see the hex values and any values that can be represent ASCII will also show the ASCII character. Every place there is a 41 hex, you'll see "A" and the hex editor doesn't know if it represents an "A" or not.

Characters can get confusing because, for example, the ASCII character for the number "1" (which is printed/displayed) is represented by the decimal value 49 (you'll see that on the ASCII chart). Again, that's normally handled automatically in the background by C/C++ so when you print-out a variable with the value 1, you never know it's converted to 41 before being printed/displayed and you just see the "1". But, if you have the character "1" in a text file, it's stored as the value 41.

Also, hex or binary format can emphasize or highlight the fact that individual bits in a value are important,

Here's an example - I make lighting effects where the on/off state of an LED or light is represented by one bit in a variable. That makes things like chasing/sequencing super-easy, and it actually makes everything easier.

Say I have a string of 16 LEDs and ever-other LED is on so the "status" variable looks like this in binary:
0101010101010101 (binary)

That's kind of hard for humans to read & write (especially if it's not such a simple pattern like that). In hex that pattern looks like this:
5555 (hex) I did that conversion in my head.

In decimal it looks like:
21845 (decimal) I had to use a calculator.

So, here's the advantage to hex... Every nibble (group of 4 bits) converts exactly to one hex digit. Every time you see 5, the pattern is 0101. By memorizing 16 hex-to-binary conversions you easily can learn to convert variables of any size between hex and decimal in your head! About half of those conversions are super-easy to remember and you already know zero and one. At one time, I made some flash cards to teach myself to make the 16 conversions.

Converting between decimal and binary is not so easy and it requires a calculator (except for some small numbers that you can remember.

You can do a TON of programming without using hex or binary. But when experienced programmers do need to work with bits or binary they use hex. (It's a lot more common with "low level" programming (microcontrollers) than when you're developing an application for Windows or a phone, etc.)

[prankenandi]

DVDdoug:
So yeah... Everything in the computer/processor is binary and by default numbers are converted to and from decimal by C/C++. But you can optionally show the values (or input the values) as hex or binary.

Not every binary variable/value directly represents a "number"... For example, decimal 65 (=hex 41 =binary 00100001) might represent the number 65 or it could represent [u]ASCII[/u] letter "A" or it might be part of a color or a microprocessor instruction, etc. The software has to know the context/use to know what it represents. If you open a file with a hex editor you'll see the hex values and any values that can be represent ASCII will also show the ASCII character. Every place there is a 41 hex, you'll see "A" and the hex editor doesn't know if it represents an "A" or not.

Characters can get confusing because, for example, the ASCII character for the number "1" (which is printed/displayed) is represented by the decimal value 49 (you'll see that on the ASCII chart). Again, that's normally handled automatically in the background by C/C++ so when you print-out a variable with the value 1, you never know it's converted to 41 before being printed/displayed and you just see the "1". But, if you have the character "1" in a text file, it's stored as the value 41.
Here's an example - I make lighting effects where the on/off state of an LED or light is represented by one bit in a variable. That makes things like chasing/sequencing super-easy, and it actually makes everything easier.

Say I have a string of 16 LEDs and ever-other LED is on so the "status" variable looks like this in binary:
0101010101010101 (binary)

That's kind of hard for humans to read & write (especially if it's not such a simple pattern like that). In hex that pattern looks like this:
5555 (hex) I did that conversion in my head.

In decimal it looks like:
21845 (decimal) I had to use a calculator.

So, here's the advantage to hex... Every nibble (group of 4 bits) converts exactly to one hex digit. Every time you see 5, the pattern is 0101. By memorizing 16 hex-to-binary conversions you easily can learn to convert variables of any size between hex and decimal in your head! About half of those conversions are super-easy to remember and you already know zero and one. At one time, I made some flash cards to teach myself to make the 16 conversions.

Converting between decimal and binary is not so easy and it requires a calculator (except for some small numbers that you can remember.

You can do a TON of programming without using hex or binary. But when experienced programmers do need to work with bits or binary they use hex. (It's a lot more common with "low level" programming (microcontrollers) than when you're developing an application for Windows or a phone, etc.)

Thank you for the detailed Answer!

[GolamMostafa]

1. There is one more advantage (see Step-3) of representing the DS18B20's address (actually it is an identification code) in hex base. Every sensor contains a 64-bit (8-byte) data as its identification number which has been coded into its ROM Memory as per following conceptual layout (Fig-1).

Figure-1:

2. Before the sensor is put into operation, the user reads the 64-bit (8-byte) ROM code from the sensor and saves in a byte type array. The codes are:

byte dsAddr[8];
ds.search(dsAddr);        //64-bit ROM code are saved in the array as 8-bit chunk; LSbyte first

3. Now if the user wants to print the contents of dsAddr[] array of Step-2 and compare/check against Fig-1, then the hex format is very convenient over the decimal format.

4. The contents of dsAddr[] array can be printed on Serial Monitor by executing the following codes:

for(int i=0; i<8; i++)
{
    byte y = dsAddr[i];
    if(y < 0x10)
    {
        Serial.print('0');    //show leading zero on Serial Monitor
    }
    Serial.print(y, HEX);
    Serial.write(0x20); //insert space between two bytes
}

[anon73444976]

GolamMostafa:
1. There is one more advantage (Step-3) of representing the DS18B20's address (actually it is an identification code) in hex base.

And that advantage is . . ?

[GolamMostafa]

TheMemberFormerlyKnownAsAWOL:
And that advantage is . . ?

As a non-native, it is sometimes a difficult task to accommodate "forward referenced'" message in the current line. Hope that the OP will read all the steps of Post-9 and then will be able to see the advantage of the hex representation.