Quote Originally Posted by zonemikel View Post
So what should i use in place of enumeration to have a simple '.' sort of system to call on hexadecimal numbers that i need to have set in one place and use in multiple places ?
I'm under the impression that you want to use the enumeration elements as flags, with the ability to combine values? If so, you just need to add the [Flags] attribute, and you can use bitwise operators. But in your methods, you wouldn't have a byte parameter, but a TXMask parameter.
One more thing: assuming that you are talking about flags, instead of hard-coding the value of TXMask.Test, it's better to use previously defined enum members. It's also a common practice to provide members representing potentially frequently used flag combinations.

Code:
[Flags]
public enum TXMask : byte
{
    Battery = 0x01,
    Accel = 0x02,
    Sonar = 0x04,
    Line = 0x08,
    Gps = 0x10,
    Move = 0x20,
    Test = Battery | Accel | Gps | Move,     // == 0x33
    SonarLine = Sonar | Line     // just to illustrate the point - maybe it doesn't make sense in your app
};
Then you can simply use the flags in a method, as BigEd781 instructed you.
Search MSDN library for the FlagsAttribute class to learn more; the example provided there uses [FlagsAttribute] instead of [Flags], but this is equivalent.

Quote Originally Posted by zonemikel View Post
I dont use enums or c# much but i thought they were to represent lists of numbers as actual values so your code could look nicer, similar to #define in c
As a side note, in C++ there are enumerations also, however, C++ allows for implicit conversions.

As for C#:
Quote Originally Posted by BigEd781 View Post
[...] there is no implicit conversion back and forth, and that is a good thing, trust me.
Exactly. The C# approach is better, but it's a bit hard to explain why, especially if you look at enumerations as if these were just some named numbers. Among other things, this prevents some nasty, hard to track-down bugs. And if you look at enums as concepts, then it makes sense not to be able to mix up two unrelated concepts together. For example, you can't write something like
Fruit anApple = Toys.PlasticApple,
and not get warned by the compiler.