Alternative to String to hold HEX values for Switch/Case

General
1

This project uses an Electron to receive data (over RF) from multiple remote sensors.
It stores the Serial Numbers for all the remote sensors in a String array.
My code works, but I’m trying to eliminate all Strings, per the many discussions on this forum.

The code from this Topic is used, but I’m looking for an alternative to String to hold the HEX Serial Numbers for the Switch/Case.

My PseudoCode:

//   Sensor Names:       ( Node #1     Node #2    Node #3             )
String cmd[256] = { "0", "416862f7", "416862fc", "416863b4", etc, etc };  // RF Serial #'s
String myCommand = "temp"; //   Used in Switch Case to find Correct Serial Number


void setup() {
  Particle.variable("snLOW", snLow);
}

void loop() {

// Update Serial # (snLow) from incoming sensor data, then:
myCommand = snLow ;

int i = -1;
      for (i = 0; i <= sizeof(cmd) / sizeof(cmd[0]); i++)  { // notice the less than or equal to comparison
        if (myCommand.equals(cmd[i])) // compare String myCommand and Array Element
          break;
      }
      switch (i)  {  
        case 0:      // Case 0 is not used, I don't use a Sensor Node # 0.
          break;

        case 1:      
        // prepare sensor data (Node #1) for Particle Publish
         break;        
        
        // Etc, etc....
}

I would love any recommendations on which direction to start searching/learning to optimize this, if possible.

Thanks in advance !

2

@Rftop, use a two-dimensional char array:

char cmd[256][9] = {  "0" , "416862f7", "416862fc", etc. etc. };

From your code, it seems the largest hex address is 8 chars to which you need to add the NULL string terminator. You can then use c-string commands like strcmp()and myCommand.c_str() to compare the char strings.

Another, more efficient way would be to store the HEX addresses as unsigned long values (aka uint32_t). This will only require an array of 2564 = 1024 bytes versus 2569 = 2304 bytes for the string method. All you need to do is convert the myCommand string value to an integer and do your switch accordingly.

2 Likes
3

Thanks for the quick reply @peekay123.
You are correct, my Hex Address will always be 8 characters.

I’m currently only testing 20 sensors.
I should have mentioned that I could be using a large number of HEX addresses, 50-100.
Does that impact the direction to take ?

Thanks again for the help.

4

@Rftop, I fixed my post to remove an excess of curly brackets (thanks @ScruffR). If you consider the amount of space taken by strings coupled with the processing required to compare strings, I would say using an integer array of hex values and doing a hex-to-int conversion is a better, more efficient way to go. You also don’t lose any readability using integers:

unsigned int cmd[256] = {  0 , 0x416862f7, 0x416862fc, etc. etc. };
3 Likes
5

Curious what your application is because it always made sense to me to use an Electron to provide an Internet connection where one is not available and then you could send in data from as many remote RF sensors as you desired vs using tons of Electrons.

With the RF95w radios, you can get up to a 1-mile range so that provides a pretty good area spread for some sensor applications.

What kind of RF radios are you using?

6

@peekay123, Thanks again. Using Integers never crossed my mind.

@RWB, I’m using a Xbee Mesh Network. I’m required to be sub-GHz.
It is fairly simple for One Electron to aggregate data from many remote Xbee Sensor Nodes
.
I’ve been interested in LoraWAN for a while and have a pile of radios in my office waiting for me to tinker with.
I’ve been watching the RF95 Topics you’re contributing to, and I’ll hopefully get my feet wet soon (for different projects however).
But at the moment, Digi makes the FCC issues easier in an Industrial Environment.
I haven’t personally found a FCC Certified Lora module that’s cheaper than an XBEE.

My Industrial Project has actually taken a different route and doesn’t use the XBee Serial Numbers anymore.
I still want to optimize my old code to eventually share, thus the reason for this Topic :slight_smile:

1 Like