Masking the bits during serial transmission

A serial port has a fixed bit length per data byte. It is 7 or 8 bit and must be known beforehand to both, sender and receiver.

If you really don't want to send all bits, you can go and generate a bit chain that is sent 8 bits at a time. Of course you need to know how many bits you are sending. If it is a fixed size, e.g. 12 bit per value, you can make soem bit-manipulations and end up with 3 bytes of 8 bits for each two 12bit sample values.

If the number is variable, you'll need to add a (presumably 4 bit) bit counter that will tell the receiver how manit of th efollowign bits belong to one value. so it makes only sense if you're sending less than 12 bit average data length.

Anyway, you can always only send a full pack of 8 bits at a time over a serial connection. If you don't have tha tmany bits to send, you'll have to pad them somehow, e.g. adding some 0' bit coutners which fill up 4 bits, but do not produce an output value later.

At the risk of sounding like an idiot, I took the question to mean something more basic.  Your ADC might be varyied in bit resolution (12, 10, 8) but you may need even fewer bits sent (ie, looking for change in sensor output to 4 bits resolution or more for less sensitivity or something)?  Jens-Michael is right about fixed transmission standards. But are you asking how to make the unecessary bits become zeros?  That's just using "lessBits &= ~allBits" putting zeros in allBits when you want a bit to drop in lessBits. 

You're either happy or laughing... either way good luck.  I just started 2 weeks ago but managed to transmit ADC off a sensor by radio to control a device through SPI using the CC430.  I actually don't know C, so I know whatever you're doing, it's possible and addictive!

John

John DAmours said:

But are you asking how to make the unecessary bits become zeros?

There's also a way to combine both: do a right-shift. If you have sampled 8 bits but only the upper 6 are of interest, you can do a shift. It's basically a divide by a power of two.

So doing "X = X>>2" shifts all bits right by two, so bit 8 becomes bit 6, bit 2 becomes bit0. The upper two bits are filled with zero. Then you can pack the bits and further reduce transmission time.

Thanks for both of your replies.

I question what I meant to ask here is suppose I'm using a temperature sensor interfaced to a 8 bit ADC and I read a digital value 16 (00010110 in Bin)  from it at time t1. At time t2 I get a value 17 (00010111).

In these two cases only the D0 bit varies. Hence it would be sufficient if I send the D0 bit alone to the receiver to recover the value. This is the basic concept of my research work.

I'm able to implement the coding in MATLAB successfully. The problem occurs only while transmitting through the serial port of the Hardware module. How to I send this one bit alone.

Since you are doing research work. You probably know that you need less than 1 bit to convey such a message. You need 1 bit only in the rare case when those two possible alternatives are evenly distributed.

So you want to send the difference rather than the absolute value (just like MPG does). Valid idea. You need, however, to frame the information somehow. If you receive a packet that has a certain size, then you know by the fact that the package has this size and was delivered as a packet, that no more or less than the packet content belongs to it. (sounds trivial at first).
But if you pass this data through a stream, you'll need to somehow add the information about the length of each information packet to this stream too. Or you have to know it.

One approach would be to use the delta straming algorithm. Then you don't send the difference but only a 'direction change' bit in the stream. If the bit is set, the value is incremented, if it is clear, the value is decremented. If you reached the value, you 'jitter' around it with a 01010101 pattern etc. If both sides start with the same start value and there are no transmission errors, this works quite good. It reduces data size while allowing small high-frequency and large low-frequency changes. It was used originally for sound output (where you usually have large low-frequency and small high-frequency changes).

Since a remote connection is more unstable and not synchronized compared to a function call within a computer with all bits attached, there is the problem of synchronizing both sides to a consistent value, so tha they won't drift apart. MPG (or most other video or audio formats with differential compression) does it by including a 'complete' image every now and then. Sinc eyou don't have a 'header' for each bit to indicate whether it is a differenctial bit or a complete 8 bit synchronizing value, this can become a bit tricky. There might be a magic number (but then, you need to mask any bit sequence that coincidentally generates this number)

There is, however, still the problem of the serial transmission.  You can only transmit exactly 7 or 8 bits over an UART type serial connection. No single bits. So you have to wait until you have 8, pack them and send them.

And if you want to send more than 1 bit, but a variable number, then you need to add the information of how many bits there are in this particular value change.

sidd said:

Hence it would be sufficient if I send the D0 bit alone

The above 'delta' mechanism has the expert knowledge that the difference between one value and the last is always 1, plus or minus, at the expense of requiring 128 bits to cover the largest possible value change (whcih would be 16 times as much as required for just sending the value) but the advantage of only requiring 1/8 if the change is small. It depends on the expected signal whether this is a good or bad algorithm for this purpose.

sidd said:

The problem occurs only while transmitting through the serial port of the Hardware module. How to I send this one bit alone.

You could use SPI. It's basically a synchronous connection where there is a clock signal and a data signal. Each clock pulse,. a data bit is transmitted. The MSP hardware SPI will also implement 8-bit-chunks (there are some MSPs with an USI module where the size could be 1..16 bit), but if you want to send single bits, it is easiest to implement it in software: use two GPIO ports, set one port to the bit value and then toggle the other to signal that the next bit value is on the port.

On the PC side, you can catch thsi if you don't use the RX&TX lines of a serial port, but rather DSR and CTS. For a proper timing, however, it would require a kernel driver that implements collecting th ebits and when called for data will return a buffer with all recently received bits together with a bit counter.

Personally, I think this project is of rather pure academical use. But who knows, perhaps it will lead to something useful.

Interesting approach, but I have to question the savings.  In order to convey which bit changed, you'd need minimum 3 or 4 bits. That would be a savings only if on the ave < 2 bits changed at any given interval.  Anything with more change would cost you data unless you tested for higher payloads and switched to conventional (send the whole byte). Maybe that's your approach?  

But hardware today isn't wired for this. So create your own protocol where, in your world, you send either 4, 8 or other # of bits, and latch each bit in manually through conventional General I/O ports (no standard serial interface).  It would be interesting to know if this is possible at a savings in data.  As another thought, my Digital Pot has a function for stepping up or down like an up/down counter, but uses 16 bits to say this (SPI protocol).  Your protocol could do better on something like that, good luck.

John