Problems sending Hex with Serial.println


I am having problems with sending hex codes from the Arduino serial port to a 3 LED controller I built, which i’m using as a dimmer kit.

The DC dimmer kit is at

It works great when I program it from windows PC, so the hardware is OK.

When I connect the Arduino TX and GND to the kit RX and ground, and send it these commands, nothing happens.

What I am wondering is this: am I sending the HEX correctly? The dimmer kit manual says only to “send hex codes”, but I think what is actually being sent is ascii in hex… anyway I am a bit confused and would appreciate any help anyone can give me.

below is the code I tried as a first test from Arduino.

Thanks in advance!


[code]byte commandStart = 0xFE; 
byte moduleAddress = 0x4C; // MODULE ADDRESS IS 76 
byte setIntensity = 0x42;
byte channel1= 0x01;
byte intensity100= 0x99;

void setup(){


void loop (){
Serial.print(commandStart, HEX); // first command byte
Serial.print(moduleAddress, HEX); // send module address
Serial.print(setIntensity, HEX); // set channel intensity command 
Serial.print(channel1, HEX); // select channel 1 
Serial.print(intensity100, HEX); // set intensity



It works great when I program it from windows PC

Care to share the PC code?

What i'm really interested in is the Arduino coding (the windows software comes with the kit).

It's not relevant for me but if you're interested here's the link for the windows software:

Sorry, when you said "When I program it", I just assumed...

Look closely at the difference between Serial.print() and Serial.write()

If you need to send number expressed as hex in ASCII, use Serial.print(num,HEX)

If you need to sent the number raw (In all it's hexadecimal glory) use Serial.write(num)

(In all it's hexadecimal glory)

Or even its binary glory.

Thanks! that worked!

How exactly does hex coding work?

I changed the "setIntensity" and got different types of fades which are not consistent.. 0x42 is the original Intensity (of the LED's) 0x43 intensifies then quickly turns off.. then begins to intensify again 0x20, 0x50, 0x60, 0x70 all do the same thing: a really nice fade in and fade out but then at the end when it's very dim it does a little flicker.. I don't understand how the sequences work.. When I change it back to 0x42 instead of fading like before it just stays lit at a high intensity..

I hope this makes some kind of sense, I'm still really new to this.

Thanks again for your help!

It's like this: All data in the computer is actually in binary. But unless you're a Binar (That race seen only once in Star Trek:TNG(Or was it twice? (Look! Triple nested! Yeah, I'm that hard core.))) it makes little sense.

So. All bytes are 8 bits. Binary. 0b00000000 to 0b11111111 That's the same as 0o000 to 0o377 in octal, which is even MORE non-human readable than binary. Binary is a "base 2" number system, Octal is "base 8" Hexadecimal is "base 16" and an 8 bit value is in the range of 0x00 to 0xFF. Modern humans use a base 10 system, so an 8 bit value has the range of 0 to 255.

Did you know that the ancient Sumerians used a base 60 system? It's true! Check it! With one hand, count by placing your thumb on each finger joint in series... Index finger first... 1, 2, 3... Then to the base of the middle finger... All in all, 12 counts! Now count sets of 12 on the other hand by holding up one finger for each count of 12. Total? 60! Scholars believe that's why we have 60 seconds in a minute and 60 minutes in an hour today.

Anyway, numbers are numbers. Bytes can be represented in any number system you want. The total range is always 256. (Note that decimal doesn't have a "0 and a letter" in front of it... That's because we're biased towards base 10 numbers.)

Back to hex. 0x00 is 0. 0x7F is half way through the scale (127 decimal) 0xFF is the last number before it's bigger than a byte. I have no idea why 0x42 (66 in decimal) seems to be the magic number. Perhaps Douglas Adams knows.