# Given hardware specs: How do I calculate the data bandwidth [bits/s] of this system?

I'm currently trying to buy a hardware that is supposed to extract your brain waves. In other words, a data transmitter.

I am looking at the hardware spec and I am uncertain as to how I should calculate the data bandwidth i.e. how many bits the system is able to send per second.

https://emotiv.com/product-specs/Emotiv%20EPOC%20Specifications%202014.pdf

I'm primarily confused between sampling rate and the resolution. What does resolution mean in this context?

Each channel produces 128 samples per second.

Each sample has 14 bits of information (but maybe 16 bits are transferred somewhere? that's not clear).

There are 14 channels.

So it looks like the total bandwidth is

$$14\times14\times128=25.088\mathrm{kbps}$$

Maybe 28.672 kbps are actually transferred, depending whether those 2 "discarded" bits in each sample are discarded before or after transferring them.

Edit

As Dave points out, there is a note that indicates the internal sample rate is 2048 Hz (really, 2048 sps). Given that the 14 channels are sampled sequentially, this indicates that likely there are 2 unused channel sampling slots, ans so the overall bandwidth being generated by the sampler is

$$16\times16\times128=32.768\mathrm{kbps}$$

Of this, two sampling channel slots and 2 bits per sample are not useful data. Whether they are actually transferred over whichever interface you are asking about is not clear.

• There a note that says (2048 Hz internal), so it's likely that the average data rate could be as much as 2048 samples/second * 16 bits per sample = 32768 bits/second. Oct 31 '14 at 12:29

Without diving deep into the nuances of information theory, bandwidth, in bits per seconds, for a sampled signal is bits per sample x samples per second. So if you get 128 samples per second and each sample is 14 bits, that becomes 128x14=1792 bps per channel.

But that is not the whole picture. Firstly, it's very practical to use multiples of eight bits for the sample data (so that you don't need to shift it around excessively in your software) so you probably should use 16 bits per sample instead of the 14. That brings the requirement up to 128x16=2048 bps per channel.

Secondly, in a practical application, you should allow bandwidth for framing (some idle time between data chunks), protocol and channel coding (some packet ID information before each packet, perhaps a checksum, stuff like that) and error correction (in case you need to use an unreliable link for the data), retransmissions, future expansions on the product, and such. It's difficult to say how much bandwidth you should allow for this, but I think the bandwidth should be at least twice what your payload needs, preferably more. Personally I'd like to have the data link's capacity to be 10 times that what I need to transmit, because a lot can happen during a product's lifetime and it may be much easier to alter the protocol (add new packet types etc) than changing the speed of the link when you already have an installed base of devices at customers' locations around the world.