String of 1's and 0's converted to Binary

Projects Programming
1

I have created a function that packs the data down from 40 sensors in to a binary representation.

The representation can be 4, 7, 8 or 16 bits.
there is a 3bit prefix attached to the result so each reading form the sensor ends up something like..

001 1101 = sensor value of -13.

010 1011110 = sensor value of +94

100 10110101 = sensor value of +181

111 1011101011011010 = sensor value of -47834
110 1011101011011010 = sensor value of +47834

These "bytes" are all stuffed in to a string and tailed on to each other the application at the receiving end looks at the first 3 bits and extracts the data in the correct manner.

Since I have 40 sensors the values transmitted are only the delta from the first sensor in the chain so mangling the binary data in this way reduces the size of the sent packet really well as the transmission system I am using (Iridium Sat Link) charges per 50Bytes of data so the smaller i get this the better.
Using this process the average packet ends up being about 47 to 48 bytes.

Now the part I am having issues with and partly due to my lack of skill. I have had to assemble the final packet as a string to ensure that all the pseudo bytes are not signed.

I am trying to work out how to convert the String back to binary format as the Modem requires the data to be sent in binary format. If i try and pipe the string to the modem it treats is as text.

Has anyone got any suggestions as to how best to do this?

Regards
Boris

2

Start with a value of zero.

If the character is a zero, multiply the value by two.
If the character is a one, multiply the value by two and then add one.

Of course, this happens AFTER skipping the prefix. Use the prefix to tell you how many bits to process and anything else that the prefix tells you.

3

vaj4088:
Start with a value of zero.

If the character is a zero, multiply the value by two.
If the character is a one, multiply the value by two and then add one.

I may not have explained myself overly well.

The issue I am having is sending the data to the Iridium modem, it needs to be sent as a binary packet not as a string. If i send it as a sting converts it and becomes larger than what it should be.

What I think I have to do is traverse the string and shift each byte in to a byte array, then use the byte array in the modem function.

4

So you recive bits (how you can recive single bits on a Arduino, that works on bytes is stramge, but ok) you for... Reasons, transformed it in strings that contiens only 0 and 1, now you want to trasform the string you have into bytes anx you don't know how?

5

vangalvin:
The issue I am having is sending the data to the Iridium modem, it needs to be sent as a binary packet not as a string. If i send it as a sting converts it and becomes larger than what it should be.

what's the media you using to send the data to the modem? serial? bluetooth? RF???

also we know nothing about the 'binary packet' you talking about... it is purely a binary stream? or receive one byte at a time???

you missed those info out and IMHO they are KEY to helping you out generating the binary stream you are after!!!

6

Silente:
So you recive bits (how you can recive single bits on a Arduino, that works on bytes is stramge, but ok) you for... Reasons, transformed it in strings that contiens only 0 and 1, now you want to trasform the string you have into bytes anx you don't know how?

Not quite, I have 40 sensors that deliver 16 bit values. lets say sensor 1 gives me a value of 2304, sensor2 gives me a value of 2309. thats a difference of -5.

The first value is sent as a full 16bit value. 1100000011111110010 (16 bits with the 3 bit prefix. the first 2 bits tell the receiving application to read 16 bits after the 3 bit prefix and that its a + value.

If its a negative number I flip bit 3 on the 3bit prefix. and the number 5 will fit in to 4 bits so i flip the first two bits of the 3bit prefix to 00.

My prefix is then 001 meaning the application the arduino is sending to reads the first 3 bits and knows that it only needs to read the next 4 bits to get the number. it then checks bit 3 of the to see that it is a negative number so it needs to add that to the first value.

0010101 (7 bits)

What this means is instead of sending 32 bits i'm only sending..
11000000111111100100010101 (26 bits)
not much of a saving however when you have 40 sensors that have only a small variation the saving is HUGE.

If the value will not fit in the 4 bits it tries to fit it in 7 bits, then 8 bits, then 10 bits and finally 16 bits.
the unusual bit size was based upon what the most common values the sensors output.

All the bits need to then be sent to the Modem in binary format.

I think what I am going to have to do is create a bit shift routine that passes the bits in to an uint8_t array then send that to the modem.

7

sherzaad:
what's the media you using to send the data to the modem? serial? bluetooth? RF???

also we know nothing about the 'binary packet' you talking about... it is purely a binary stream? or receive one byte at a time???

you missed those info out and IMHO they are KEY to helping you out generating the binary stream you are after!!!

Ha, sorry. late nights are catching up :confused:

The packets need to be stored in a uint8_t tx buffer. sendSBDBinary(const uint8_t *txData, size_t txDataSize);

The modem is connected to the Arduino via serial.

8

vangalvin:
Ha, sorry. late nights are catching up :confused:

The packets need to be stored in a uint8_t tx buffer. sendSBDBinary(const uint8_t *txData, size_t txDataSize);

The modem is connected to the Arduino via serial.

ok... but still trickling info to us!

since 'txData' is the function in a uint8_t array, using the examples from your first post, does it mean:

001 1101 = sensor value of -13. <----- to be put in 1byte ie txData[1]??

010 1011110 = sensor value of +94 <----- to be put in 2bytes ie txData[2]??

100 10110101 = sensor value of +181 <----- to be put in 2bytes ie txData[2]??

111 1011101011011010 = sensor value of -47834 <----- to be put in 3bytes ie txData[3]??
110 1011101011011010 = sensor value of +47834 <----- to be put in 2bytes ie txData[3]??

is that what is expected?

asking coz you mention in your OP a '3 bit' header

so using the second example, how would '010 1011110' be expected to be represented in 2 bytes?

is it 00000001 01011110?

or 00000010 01011110?

or something else...?

9

generally with basic binary you could simply trim the zeros off the front of the number to get the smallest representation. if you wanted to allow for positives and negatives you could add an extra bit to represent that.

as i'm sure you know any transmition you are using is going to want to send bytes (8 bits at a time).

what you are talking about is very possible but you would need to collect all the bytes then break them down through code into a series of bits or bools and reassemble them based on your own custom algo.

you mention putting an additional 3 bits before each number to represent how many bits a number is going to use? this doesn't seem like this could save too much since you would add to the length transmission.

i would thing this would only help you if you had the possibility of very very high numbers. regardless of what sensors you are using... arduino pins only read the fidelity of 10 bits. so you cant have high enough fidelity to justify adding a "key" of three bits to each number.

if you really want to save you self length by manually bit twiddling would be to represent your numbers in an consistant smaller number of bits.

for example: arduino pins only register 0 to 1023. if this was your range you could have your code break down and understand 10 bits at a time. which would be smaller than what the standard 16 bit number two bytes usually represent.

I admire your though and i thing most programmers do not question standards enough, but the particular question you are asking has been pondered and answered and challenged by computer scientist for many years to send numbers in the most proficient way possible.

the only way to profficiently trim would be to send all your numbers in the lowest amount of bits that the highest number needs to represent

10

sherzaad:
ok... but still trickling info to us!

since 'txData' is the function in a uint8_t array, using the examples from your first post, does it mean:

001 1101 = sensor value of -13. <----- to be put in 1byte ie txData[1]??

010 1011110 = sensor value of +94 <----- to be put in 2bytes ie txData[2]??

100 10110101 = sensor value of +181 <----- to be put in 2bytes ie txData[2]??

111 1011101011011010 = sensor value of -47834 <----- to be put in 3bytes ie txData[3]??
110 1011101011011010 = sensor value of +47834 <----- to be put in 2bytes ie txData[3]??

is that what is expected?

Using this line....
010 1011110 = sensor value of +94 <----- to be put in 2bytes ie txData[2]??
^^^ ^^^^^^^
prefix 94 in binary

Lets say we have txdata[0], txdata[1], txdata[2], txdata[3] etc.. that are uint8_t's
txdata[0] txdata[1] txdata[2] txdata[3] txdata[4] txdata[5]
11010111 01011011 01000111 01010101 11101001 0110101
^ ^ ^ ^
3bits <16bits> 3bits<4bit>3bits <7bits>3bits <8bits>

11010111010110110100011101010101111010010110101

txdata[0], [1] and part of [2] contain the 16bit's representing the number 47834

part of txdata[2] and [3] contain the 4 bits that represent -13

part of txdata[3] and [4] contain 7 bits that represent 94

part of txdata[4] and [5] contain 8 bits that represent 181

I hope that clarifies it a little better.
essentially the uneven bit lengths are packed tight together with the 3bit delimiter.

11

taterking:
generally with basic binary you could simply trim the zeros off the front of the number to get the smallest representation. if you wanted to allow for positives and negatives you could add an extra bit to represent that.

as i'm sure you know any transmition you are using is going to want to send bytes (8 bits at a time).

what you are talking about is very possible but you would need to collect all the bytes then break them down through code into a series of bits or bools and reassemble them based on your own custom algo.

you mention putting an additional 3 bits before each number to represent how many bits a number is going to use? this doesn't seem like this could save too much since you would add to the length transmission.

i would thing this would only help you if you had the possibility of very very high numbers. regardless of what sensors you are using... arduino pins only read the fidelity of 10 bits. so you cant have high enough fidelity to justify adding a "key" of three bits to each number.

if you really want to save you self length by manually bit twiddling would be to represent your numbers in an consistant smaller number of bits.

for example: arduino pins only register 0 to 1023. if this was your range you could have your code break down and understand 10 bits at a time. which would be smaller than what the standard 16 bit number two bytes usually represent.

I admire your though and i thing most programmers do not question standards enough, but the particular question you are asking has been pondered and answered and challenged by computer scientist for many years to send numbers in the most proficient way possible.

the only way to profficiently trim would be to send all your numbers in the lowest amount of bits that the highest number needs to represent

Genius!!! I had not thought about just dumping the 7 leading 0's that would be a heck of a lot faster than looping thought the string and shifting the value in the a new array. Thanks for that.

I did try and represent the readings with a range between 0 and 1024 however I ended up loosing too much resolution. Normally i would not bother with trying to skimp and scrape on the data but in this situation the only means of communications from the device is going to be via the Iridium network. once its installed it will be about a year before anyone is able to get to the site again.

I think I will try exactly what you have suggested and just trim the zero's off.

It has taken me about week of trying just about every method you can imagine in order to get the byte count down. even implemented an LZH compression routine as an option but that still ended up being 3 * 50 byte packets. I tested this last night and ended up getting down just under the 50 byte mark so it worked but now i need to pass the data to the sat modem.

12

unfortunately i'm sure your modem will expect and only understand 8 bits at a time. the standard to about any communication protocol deals with bytes. so you will be most definatly be numbers to your modem as bytes (numbers between 0 and 255).

here is a code here is a code example that uses basic binary math to take ints and turn them into sets of 10 bits. (i use bools arrays for this).

this example then stream all the 0's and 1's into a function that devides them at every 8 and converts them to a standard byte.

40 ints would normaly use 80 bytes.

but the outcome of this code produces a byte array of only 50 that would be ready to send to your modem.

obviously you would need the exact opposite math in your reviving code to put the numbers back together again.

// pick some numbers to send

int orig [40]= {
213,1,1200,821,1023,45,83,83,93,83,
213,1,1200,821,1023,45,83,83,93,83,
213,1,1250,821,1023,45,83,84,93,83,
213,1,1200,821,1023,45,83,83,93,83};

int bc;
// length is 10 devided by 8 multiplied by 40 rounded up

byte buff[50];
bool bit10[10];
bool bit8 [8];
int idx;
void setup() {
  
 Serial.begin(9600);
  int i, i2;
 
   idx=0;bc=0;i =0;
  while(i<40){
    
  getbits(orig[i]);
  i2 = 0;
  while(i2<10){
    Serial.print(String(bit10[i2]));
    pushbits(bit10[i2]);
    i2++;} 
  i++;}
  //writes zeros into the left over spaces
  while(idx<50){pushbits(false);}
Serial.println("");
// display the byte array
  i = 0;while(i<50){Serial.println(String(buff[i])+",");i++;}

  

}
int powers [10] = {1,2,4,8,16,32,64,128,256,512};
void getbits(int b)
  {byte i=10; int n;
  while(i>0){i--;
    n=b/powers[i];b-=n*powers[i];
    if(n==0){bit10[i]=false;}else{bit10[i]=true;}
   }}

void pushbits (bool b){
  bit8[bc] = b;
 bc++;if(bc==8){
  buff[idx]=getbyte8();
 
  bc=0;idx++;
  } }

  byte getbyte8 (){
    byte ret = 0; byte p = 1;
    byte i = 0;
    while(i<8){
      if(bit8[i]){ret+=p;}
      i++;p*=2;}
      return ret;
    }
    
void loop() {}

if you have 40 numbers to send at 10 bits each. this is 400 bits. devided by 8 and you should be able to pack your 40 numbers in exactly 50 bytes. if you use 11 bit numbers you could send numbers as high as 2047 but your byte array would then be 55 long though. but either way it's much better than 80 bytes in standard representation!

13

taterking:
if you have 40 numbers to send at 10 bits each. this is 400 bits. devided by 8 and you should be able to pack your 40 numbers in exactly 50 bytes. if you use 11 bit numbers you could send numbers as high as 2047 but your byte array would then be 55 long though. but either way it's much better than 80 bytes in standard representation!

I will give that a try, my main concern was loosing the accuracy when rounding the numbers. but I guess there has to be a trade off somewhere. the sensors are on an active volcano and they need to record the temperature from the potential -50.999 degrees at the surface to the +125.999 degrees in the bore hole. its actually the subtle changes in the 3 decimal places that are going to show permeation of the heat in to the surrounding rock.

Its a shame we are stuck with only being able to use Iridium as other sat services are a lot cheaper. heck even using an audio link I can get more data sent and received at a much lower cost but none of the other sats have coverage of the area.

Early this morning I did have a play with this in C++, its a little ugly and i still need to work out how to ensure that the last 8bits are dealt with. the bit at the moment is on the right and needs to be on the left .

When i tested it on the real readings even with a large peak in temperature on some of the sensors I was able to get the packet down to 47bytes at full resolution.

#include <iostream>
#include <string>
#include <bitset>
#include <iomanip>
using namespace std

int main() {
  string bitstring = "101100010010001010111100001011101100010011111111111111101";
                           //10110001 00100010 10111100 00101110 11000100 11111111 11111110 1

int streamLength = bitstring.length();
int packetLength = streamLength / 8;
unsigned char ByteArray[packetLength] = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0} ;
int bitLength = 8;
int byteNum = 0;
int bitNum = 0;

for (unsigned i=0; i<streamLength; ++i){

        string bitRep = bitstring.substr(i, 1);    //do this character by character
        if(bitRep == "1"){
            ByteArray[byteNum] = (ByteArray[byteNum] << 1)+0x1;         //shift a 1 in to the byte
        }else{
            ByteArray[byteNum] = (ByteArray[byteNum] << 1)+0x0;         //shift a 0 in to the byte
        }
        bitNum++;
        if(bitNum == 8){
            bitNum = 0;
            byteNum++;
        }    
}

for (unsigned i=0; i<packetLength; ++i){
    std::bitset<8> x(ByteArray[i]);
    std::cout << x << " ";
}
std::cout << '\n';
  return 0;
}
14

another idea to shorten you numbers... if you have a sensor that usually reads 100 degrees. only send the fluctuation. so if you get a reading of 103.... only send the three. and add the 100 back home:)

for your other sensors if they where averaging somthing like -10 degrees... and you get a reading of -8 you would just send a 2 and subtract the -10 at home for that particular sensor!!!
maybe this concept would help you shorten your data?????

another idea would be to "map" the expected range. for example if you have a sensor that you think will produce a range between 110 degrees to 130 degrees..... you could have your 10 bit number represent how far between those two temperatures you are.

for example lets say you get a reading of 121.
subtract the lower boundry of 110 and you get 11.

11 devided by your range of 20 gives you .55
which tells you that you are 55 percent of your expected range!
multiply 1023 by .55 and send the result.

(actually i think it might really be 1024 * .55 and subtract 1 but you get the point)

if your sensors have different range expectations just use a different ranges for each of them.
the shorter the range... the more fidelity you would have.

15

taterking:
another idea to shorten you numbers... if you have a sensor that usually reads 100 degrees. only send the fluctuation. so if you get a reading of 103.... only send the three. and add the 100 back home:)

for your other sensors if they where averaging somthing like -10 degrees... and you get a reading of -8 you would just send a 2 and subtract the -10 at home for that particular sensor!!!
maybe this concept would help you shorten your data?????

another idea would be to "map" the expected range. for example if you have a sensor that you think will produce a range between 110 degrees to 130 degrees..... you could have your 10 bit number represent how far between those two temperatures you are.

for example lets say you get a reading of 121.
subtract the lower boundry of 110 and you get 11.

11 devided by your range of 20 gives you .55
which tells you that you are 55 percent of your expected range!
multiply 1023 by .55 and send the result.

(actually i think it might really be 1024 * .55 and subtract 1 but you get the point)

if your sensors have different range expectations just use a different ranges for each of them.
the shorter the range... the more fidelity you would have.

I did think about using map in a similar way and I agree it would have been a lot easier however the research team wanted the actual data reported every hour although we may end up with an average for the day due to the budged constraints.

Actually the method you describe would work really well with a lookup table and would get prety close in respect to a representation of the data.

The expected range is likely to be down to -55 at the surface and an average of around 90 to 120 degreesC

16

Unless there are a lot more cases where the number fits into 7 bits than 8 bits it seems strange to me that you would have 4, 7, 8, and 16-bit values. Wouldn't 11 or 12 bits instead of 8 cover the range more evenly?

Note: Since you send a sign bit separately, 15 bits would hold the largest possible 16-bit signed value.

17

vangalvin:
I did think about using map in a similar way and I agree it would have been a lot easier however the research team wanted the actual data reported every hour although we may end up with an average for the day due to the budged constraints.

Actually the method you describe would work really well with a lookup table and would get prety close in respect to a representation of the data.

The expected range is likely to be down to -55 at the surface and an average of around 90 to 120 degreesC

From running the sensors it appears there are quite a few instances where they fit in to 4 and 7 bits quite well. Using this method I managed to get the packet size down to an average of 47 to 49 bytes.

In order of frequencey.
7bits were the most frequent.
4bits were the second most frequent
8bits were the third
16bits only appear once or twice and that was only if there was a temperature spike

18

Well I managed to get some of the code to convert the mashed up string of 1's and 0's in to binary by bit twiddling. it definatly seems to save a huge amount of space when stored on the CF and transmitted via the sat link. Prety sure that there is probibly easier ways to this and maybe doing it from the part of the code that reads the sensors would trim things down a little.

However for testing purposes this is what I ended up with.
THe only issue I seem to be having is that when I am storing the data in an array I have to first flip the bits as when I created the byte the bits are stored around the wrong way. that was not too hard to do.

The next issue however is some of the bits end up being stored as a negative number and I am not sure as to why this is hapening. If i do a println on the data I get the correct value, but storing it in an int8_t it ends up as a negative value.

#0 Byte Value: 11111111111111111111111110111100 Byte Value REV: 10111100 Compared to: 10111101
#1 Byte Value: 11111111111111111111111111001110 Byte Value REV: 11001110 Compared to: 11001110
#2 Byte Value: 110010 Byte Value REV: 110010 Compared to: 00110011

String original = "1101110111001110001100111000010111001001100111110100011111000001111100100111101100011111100011100000010111001000001110001101001111101100111110110011111001011100010010111000101100111011010111000110101110000110011100001010111000110001110001001011100100000111000110001110001001011100101010111000000000111100100111000110001110010011011100001000111000001101110000111011100001010111000010001110011010";

void setup() {
  Serial.begin(115200);
  Serial.println("BitShift Test");
  //Get the lenth of the string
  int sLength = original.length();
  int sBytes = (sLength / 8)+1;   //how many bytes are in the string
  
  int8_t data[sBytes] = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0};;
  int updateByte = 0;   //we want to start at 0
  
  int8_t bytes[sBytes];  //create a byte array in the char
  int bnum = 0; //marker telling us what byte we are up to in the string
//  Serial.print("String Length: "); Serial.print(sLength);
//  Serial.print(" Bytes: "); Serial.println(sBytes);

for(int i=0; i<sBytes; i++){
    //get the bytes from the string
//    Serial.print("Start Bit: ");Serial.print(bnum);Serial.print(" data: ");
    String sBits = original.substring(bnum, bnum+8);
    String mk8bit = (sBits + "00000000").substring(0, 8); //this makes sure the value is 8bit's long
//    Serial.println(mk8bit);
    for(int y=0; y<7; y++){         //loop 8 times
      //String oneBit = mk8bit.substring(y, y+1);
      int oneBit = mk8bit.charAt(y);
      //now bitshift the values in to the data array data
      if(oneBit == 48){
        bitWrite(data[updateByte], y, 0);  //flip the bit at y to a 0
        //Serial.print(":0");
      }else if(oneBit == 49){
        bitWrite(data[updateByte], y, 1);   //flip the bit at y to a 1
        //Serial.print(":1");
      }else{
        Serial.println(oneBit); 
      }
    }//we have done the byte now go to the next one
    //the bits are inserted backwards so they need to be flipped
    int flipped = flipByte2(data[updateByte]);
    bytes[updateByte] = flipped;
    uint8_t blip = flipped;
    Serial.print("#");
    Serial.print(i);
    Serial.print(" Byte Value: ");
    Serial.print(bytes[updateByte], BIN);
    Serial.print(" Byte Value REV: ");
    Serial.print(flipByte2(data[updateByte]), BIN);
    Serial.print(" Compared to: ");
    Serial.println(mk8bit);
    //Serial.println("");
    updateByte++;
    bnum = bnum + 8;
}
}

void loop() {
  // put your main code here, to run repeatedly:
}

byte flipByte2(byte c){
  char r=0;
  for(byte i = 0; i < 8; i++){
    r <<= 1;
    r |= c & 1;
    c >>= 1;
  }
  return r;
}
19

Well.. I feel so dumb now..
after hours of looking at the code and scratching my head trying to work out where my mistake was I have up and wend and had another coffe. came back and it nearly bit me as soon as I looked at the code again.

Of couse its going to throw back a - number when you flip the first bit on an int8_t :stuck_out_tongue:

20

johnwasser:
Unless there are a lot more cases where the number fits into 7 bits than 8 bits it seems strange to me that you would have 4, 7, 8, and 16-bit values. Wouldn't 11 or 12 bits instead of 8 cover the range more evenly?

Note: Since you send a sign bit separately, 15 bits would hold the largest possible 16-bit signed value.

Sorry to be a pain in the rear John, would you mind casting an eye over this and see if you can see where I have screwed up.

I tested the code tonight and it was working a treat. the full 16bit's were dropped to a delta based on the first value and added to the byte array. Most of the time the values were around 47 byte mark. I swear it was working!

And then came the.....
Stack smashing protect failure!
abort() was called at PC 0x400ddbfc on core 1

Now in the main routine I am calling the function like this..

uint8_t packedData[50];
twiddlebits(packedData, jPack);

jPack is a string of 0's and 1's.

twiddlebits takes the string value and packs it in to an unit8_t.

I cant see where there would be a buffer overflow.

#include <ArduinoJson.h>
#include "twiddle.h"

uint8_t *twiddlebits(uint8_t packedData[50], String original){
  int sLength = original.length();      //Get the length of the sting being sent
  int sBytes = (sLength / 8)+1;         //how many bytes are in the string +1 allows for partial bits
  uint8_t data[sBytes] = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0};    //the array we are going to stick the data in to
  //uint8_t bytes[sBytes];                //Because the bits are reversed we need to reverse them and before sending
  int updateByte = 0;                   //The first byte in the array (our start potition)
  int bnum = 0;                         //the bit marker, how many bits are we up to

// Chop the sting in to 8 chars, flip each bit to a 1 or 0
for(int i=0; i<sBytes; i++){
    //get the bytes from the string
//    Serial.print("Start Bit: ");Serial.print(bnum);Serial.print(" data: ");
    String sBits = original.substring(bnum, bnum+8);
    String mk8bit = (sBits + "00000000").substring(0, 8); //this makes sure the value is 8bit's long
//    Serial.println(mk8bit);
    for(int y=0; y<8; y++){         //loop 8 times
      //String oneBit = mk8bit.substring(y, y+1);
      int oneBit = mk8bit.charAt(y);
      //now bitshift the values in to the data array data
      if(oneBit == 48){
        bitWrite(data[updateByte], y, 0);  //flip the bit at y to a 0
        //Serial.print(":0");
      }else if(oneBit == 49){
        bitWrite(data[updateByte], y, 1);   //flip the bit at y to a 1
        //Serial.print(":1");
      }else{
        Serial.println(oneBit); 
      }
    }//we have done the byte now go to the next one
    //the bits are inserted backwards so they need to be flipped
    int flipped = flipByte2(data[updateByte]);
    packedData[updateByte] = flipped;
    //uint8_t blip = flipped;
    //Serial.print("#");
    //Serial.print(i);
    //Serial.print(" Byte Value: ");
    //Serial.print(bytes[updateByte], BIN);
    //Serial.print(" Byte Value REV: ");
    //Serial.print(flipByte2(data[updateByte]), BIN);
    //Serial.print(" Compared to: ");
    //Serial.println(mk8bit);
    //Serial.println("");
    updateByte++;
    bnum = bnum + 8;
}
  return packedData;
}

byte flipByte2(byte c){
  char r=0;
  for(byte i = 0; i < 8; i++){
    r <<= 1;
    r |= c & 1;
    c >>= 1;
  }
  return r;
}