Considering the data packets structure described in the MCU data sheet:
Number of samples defines how many data packets (i.e. batches of 8 bytes) should the API call to the read(…) method retrieve from the device (on the receiver) before returning.
Sampling rate defines how often the data packets are generated on the device (e.g. 1000Hz means that one data packet will be generated each millisecond, 100Hz means that one data packet will be generated every 10 milliseconds, and so on)
Both of these parameters work together in what concerns the transmission performance and reliability, as they influence the data throughput on the channel and processing demand on the receiver. In fact, another relevant parameter are the number of analog channels being acquired (by default are all 6).
For example if read(1) is used together with a sampling rate of 1000Hz, the device sends one sample at a time, making this a highly resource-intensive task for the receiver where in-between calls to read(1) no more than 1 millisecond should elapse, otherwise samples start to build up in the sending buffer and an overflow may occur.
The CRC errors, in principle, should be related with this. For example, a print(...) statement introduces time delays in-between calls to the read(...) function (even if it is a seemingly simple task), it may be contributing to a buffer overflow, which in turn leads to inconsistencies in the data packets (8 byte sequences), resulting in a CRC mismatch.
This being said, many applications may also try to use a new facility introduced in the (r)evolution firmware to enable reading the state of the device only upon request of the receiver.
Contrary to the streaming mode, where the device continuously sends data at a steady rate, in the status check mode the device replies to each state request with a single status packet (described in the MCU data sheet).
It is important to highlight that while in streaming you have an accurate, guaranteed and known period in-between samples (e.g. 1 millisecond), in the status check mode the period will most likely be variable, rendering unfeasible signal processing tasks that involve spectral analysis of the data.
Should you consider experimenting with the status check mode, please make sure that you are using the Python API version that has been adapted to make the most out of the BITalino (r)evolution firmware:
The BITalino Team