[Solved] What data type to store phone numbers?

Getting Started
1

Hi Guys,

I’m trying to save an array of phone numbers (let’s say 10 or 20) in the (retained) Backup-RAM of the Particle Electron. To save memory I’d scrap the leading “+” and only store numbers beginning with the country code (eg 49 for germany).
I’m using retained as the content should be available after sleep and the numbers should be changed over the air.

Using the String data type would be the worst (if even possible) solution, as it always consumes a bunch of bytes in memory.

Using retained char phone[16] would be possible, but this also consumes 16 bytes for a number that could saved in a 8-byte unsigned integer. In Addition, I’ve no Idea how to create a multi-dimensional array of chars (like phones[20][16])

Can give me a hint how to solve this issue?

kind regards

2

The easiest would be char phones[20][16] (but that would only store 15 digits since you should also have a zero-terminator).

Otherwise you could use

  • uint64_t (64bit unsigned integer) to store up to 18 digits (without leading zeros)
  • uint32_t[2] (same as above)
  • BCD (each nibble in a byte represents a digit)
  • …

But each of these would require some extra effort to unpack the data to get to the seperate digits again.

Also, how often do your phone numbers change? If this is not too frequent, you might rather use EEPROM than retained since on complete power loss even retained variables will be gone while EEPROM will still persist. You just need to be aware of the risk of flash wear when changing the data too frequently.

3

Hi,

thank you for your fast response!

Didn’t even know that a multi-dimensional array work that easy :smile:

The use case is an alarm tool, SMS (what I need the phone number for) is just in addition in case that the internet connection between the user and the tool is down for any reason. The device goes into deep sleep every 2 minutes and if there is nothing to worry about it doesn’t even turn on the cellular. The tool is powered by a 4.5W Solar panel and a little bigger lipo battery (3400mAh 18650 cell), so it should never loose the retained memory.

In case it looses the retained memory, the device will connect to the network and get all it’s config (threshold, phone numbers,…).

I might use EEPROM, but is not really required and, that’s the main reason, I’m not so familiar with it :smile:

I’ll try to use the uint64_t as an array, that way I can store over a hundred numbers in the 4 KB(yte?) RAM. Leading zeros are not required, as all numbers should start with a + and the country code, where the “+” will be added during time of sending the SMS.

thank you!!!

1 Like
4

okay, that was too quick. I don’t get the uint64_t converted to a String or char:

sprintf(str, "%llu", val);

sets str to “lu” :frowning: I didn’t found any other working solution in this forum,…

5

That format specifier seems broken, or not implemented since not even a warning when compiling.

Why not just use the char arrays?

if you are really needy for space, you could just write a function to convert the number to a string on the fly… but then you may need to add a byte for the width of the number.

6

If you want your numbers a strings anyway, I’d also go with string direct.

And as @BulldogLowell said, it’s the sprintf() that doesn’t support uint64_t, but you can always go the mathematical way via integer divisions/modul of powers of 10 :wink:

If you want to stick with sprintf() you can go with uint32_t[2] and sprintf(str, "%u%09u", nr[x][0], nr[x][1]); you just have to make sure to fill nr[x][1] exactly to 9 digits (no more, no less).

7

even the conversion to String() fails:

uint64_t val = 1234567890;
String test = (String)val;

Error:

call of overloaded 'String(uint64_t&)' is ambiguous

As the number must not start with a zero it would be possible without length thus leading zeros. But I’m afraid it’s much easier to limit the number of numbers to <20 and use a char array.

Thank you guys!

8

Thanks @ScruffR @BulldogLowell for the help!

9

Thank you, that way I found a solution!

// returns the phone-number as a char-array with a leading +
char* getPhone(uint64_t number)
{
    uint32_t numberPart[2];
    numberPart[0] = number % 1000000000;
    numberPart[1] = floor(number / 1000000000);
    char str[22];
    sprintf(str, "+%u%09u", numberPart[1], numberPart[0]);
    // Particle.publish("Phone Number", String(str));
    return str;
}

thank you guys!!!

1 Like
10

you won’t need floor() since integer divisions do that anyhow.

3 Likes
11

@joky Which 4.5w solar panel are you using?

Also, are you connecting the solar panel directly to the Vin and GND pins, so the PMIC handles the battery charging?

I also bought a few 18650 cells to use with the electron for a GPS based drone tracker in case it ever goes missing.

12

It’s a nice way to pack it in and it works.

Thinking about it… phone numbers are strings, not really integers. Especially if you are dealing with mixed-width numbers.

But you are not, so this is a point with no point. :wink:

13

Hi @RWB,

just go to ebay or aliexpress and search for “4.5w solar”. The one I ordered is monocrystalline and cost about 6,50 EUR.
Yes right. I used a battery holder from keystone and soldered one single pin next to the battery connector.

regarding numbers:
At least in europe the usage of country codes is widely known, so every number begins with +49, +44 or +1. Leading zeros would be a show stopper for storing phone numbers that way, but if the number starts with a number (and adding the + right just before sending an SMS) it should be all fine.

I’m not sure how that works anywhere else but I think this solution should work globally,…

regarding GPS: You can also track the position using GSM positioning. Not the same as GPS of corse, but just cost a few lines of code. Some M2M-SIM providers even show you the approx. position of the SIM.

regards

14

If you did not have memory constraints then using a char array would be the clear winner.
As all of your numbers begin with country code (no leading zeros) then having leading zeros would not be an issue as you could just code to ignore the leading zeros after the conversion to a char array. This would mean that you’re system would already work for variable length phone numbers.

1 Like