Question about ADC frequency

Well, 9600bps are 9600bps. This are only 960 bytes per second. Period. You cannot send more, including any binary-to-text conversion, linefeeds etc. Also, if you do not decouple conversion from sending, you'll waste additional time.

Using SPI, however, you use a much higher data rate than 9600bd. (and even with 9600Bd, the throughput is 20% higher as SPI requires only 8 bit per byte while UART requires 10)

It's not the conversion speed that's limiting your sampling frequency, it's the transfer of the results.

In theory, you can write to an SD card with about 500KB/s, which is about 500* faster than the 9600bd UART. If you decouple writing from sampling (double-buffering and DMA background write/interrupt state machine for initing the transfer), you can reach really high sampling rates.

The SD16, however, won't output 100.000 useful samples per second. It always requires at least 32x oversampling (It needs to feed the digital filter or you'll only get 1 bit effective resolution). With OSR=32, you'll get only 9 or 10 effective (usable) bits and you'll get a valid result at all only if the input frequency is by a factor 8 smaller than (Fsd16/OSR) and the filter is continuously stuffed. (digital filter settling time)

The ADC12 gives sampling frequencies of up to 130ksps (for up to 75kHz input frequency), but for lower frequencies, it's precision does not grow. ADC12 sampling results are independent from each other.
The SD16 gives better results the slower you sample (higher OSR) and the lower the input frequency is. The digital filter used to get the result form the oversamplied bitstream needs some settling time. SD16 conversions depend on the previous one. So it makes no sense taking just one sample. YOu'll need to take at least four and use the forth as the first usable. Or let it run continuously, and then picking one sample from the middle. Just start-sample-stop won't give a reliable result.
Both have different signal targets and different usages.

On the 1611 with ADC12, I do 12.000 conversions per second (actually more, but I use only 12.000) from 12 different channels. Every millisecond one sample per channel. Inclusive processing, it only takes about <5% of the CPU. I don't write them, however. I just check for changes, add resulting values to counters etc.
It shouldn't be a problem to write them to SD card anyway (which in fact is a long-term goal I'll have to implement some day)

As a short fix, I'd go for 115200bps on the usart.
Then, decouple sampling and sending/writing to SD card. Do it in an ISR or use DMA (if available) with alternating buffers.
Know the file system driver you're using, so you can avoid flash writes (which have to be done 512 byte-wise) at an unpleasant time. e.g. buffer 512 bytes locally and then push them at once into the file system. And be sure that the actual writing process is done in the background, so you can continue sampling data witout waiting for the flash write to be completed.

Real-time-programming is different from PC application programming. Time won't wait. :)

OKY said:

So the data size written into SD per second is only in the order of 70 bytes or so (including date time values) . So, in this case, the writing into SD is not the problem, isn't?

Well, not really. As I often say, If you are set to zero Oxygen for just 5 minutes, you're dead, no matter how much is supplied afterwards or before.

Writing to an SD card is done in chunks of 512 bytes. Also the file system will write in clusters of multiples of 512 bytes. This is more than a coincidence.

If you write to a file system driver, it will take the first 70 bytes. An the second ones and the third ones etc. They are written into a ram buffer and the function almost immediately returns. But if you write your 70 bytes the eight time, a 512 byte block has been filled. Now the file system driver will write this block to the SD card. All in a whole. And maybe it will also update teh allocation table or whatever.

Your application code is trapped in the middle of writing these 70 bytes for a loooong time (several milliseconds), then the remaining, unwritten 22 bytes are placed in the buffer for the next block write and the function returns. So every 7 ot 8 seconds you'll have a relatively long break in teh execution of your main loop, completely destroying the continuity of the data acquisition.

OKY said:

So when I use DMA, can I avoid waiting time of uALFAT writing and can execute ADCs?

No, you can just reduce it as the transfer to the card goes much faster (yet the actual writing time of the block into the SD cards flash takes the same time). It reduces the problem and maybe shift it into a bearable region. It depends on your requirements.

To ensure proper operation even during a write access, you need to do all the data acquisition and time-critical processing decoupled from the writing.

e.g. collect data completely in ISRs and store it in a buffer large enough for 2 seconds of data. Every second, your main is triggered, does the necessary calculation over the first half of the buffer, then writes it to the sd card. next second, main is striggered by a timer ISR, calculates over the second half of the buffer (while the data aqcuisition happens in the first half of the buffer now), writes to the file and goes to sleep. And so on and so on.
This way, you have a full second to do any calculation and any write access before you'll be called again. But of course you'll need lots of ram.

You can also do the calculations inside the SD16 ISR when data comes in (if it is only adding-up the values or maybe simple multiplication). Then you'll have only two value sets. When the timer ISR kicks in, it switches the SD16 ISR from set 1 to set 2, wakes main and main can do any longer operation (such as a division) on set 1, write the data to disk, clear set 1 and sleep again.

This mechanism is called double-buffering. To go back to the oxygen example above, this is why divers often have two oxygen bottles. They can change one while breathing from the other, not being pressed to finish the change before they go unconscious. Else one bigger bottle would be cheaper and weight less.

OKY said:

What I may make mistake seems treatment of interrupt. During the SD card writing, the ADC interrupt should be repeated also. However, if I set GIE=true during the SD writing with higher ADC frequency (>125 per second OSR=128), it seems that the SD writing get stopped in the middle. This may be possibly some trouble in the serial data communication interupted by the high frequency ADC interrupt.
Is it problematic to set GIE=true during the SD treatment (SD FileOpen, FileWrite, FileClose)?

It shouldn't be a problem. The advantage of being SPI master is that you provide the clock. If you slow down the clock, the slave will slow down its communication too. You can stop in the middle of a bit and it shouldn't do any harm. Only that you may not be faster than the slave supports.
In any case, an ISR should do as much as necessary but as few things as possible. How much is necessary is up to you to decide.
After all, you'll need to finish all other ISRs before the one with the highest frequency is triggered again.

OKY said:

Can I obtain 19-bit effective resolution by averaging 1024 times (2 to the power of 10) of OSR32 data?

Well, not exactly. The formula is one more bit for every 4 times oversampling. Another 1024 oversampling would get you additional 5 bits. But only under certain circumstances.
On individual conversions of a static signal, oversampling only acts as a low-pass You won't get additional bits. If you have a 12 bit ADC, you won't get 13 bits by averaging 4 samples. You'll only averaging the noise, making more of the 12 bits usable while reducing the bandwidth by a factor of 4 (well, a static signal already has zero frequency, so this doesn't matter).

If you apply a high-frequent signal to the static signal, you will, however, really adding additional bits to the sample dones. Since if the static signal was already near the edge to the next sample value, the high-frequency signal will shift it over the edge for some and keep it below for other samples. In the average, you'll gain additional bits beyond the ADC resolution. You will not, however, reduce the signal-to-noise ratio of the individual conversions.

The SD16, however, uses a 1-bit second order sigma-delta converter with a digital filter. Each clock cycle, s ingle bit is generated (don't ask me about how it is generated and what it actually means). This bit is fed into the digital filter and decimated. After 32 bits have been fed into the filter, the filter may output a result. it is, however, not too accurate. Using higher OSR gives better result, a better signal-to-noise ratio and at OSR=1024, the result has almost 16 usable bits. (SNR ~92dB, where 90dB is 15 bit and 96dB is 16 bit). Hence the name SD16 (Sigma-Delta-16bit).

Simply averaging the results would not increase accuracy as the digital filter already selected the usable part of the generated sampling value, based on the OSR. You'll only reduce the bandwidth.

OKY said:

Is the Fsd16 32"32768Hz, when I use 32kHz crystal? And do you mean for OSR32,  32 " 32768 / OSR32 / 8 = 4096 is the upper limit of ADC per second for the 9 or 10 effective bits?

No, if Fsd16 is 32768 Hz, then the maximum sampling frequency is 32768/32 =1024 samples per second (but for all channels simultaneously if supported - some SD16 have only one channel selected at a time and only one SD16MEM register). For OSR=1024 it is 32 samples then.
But if you are sampling any waveform, you'll need at least two samples per wave, the maximum bandwidth is 512 bzw 16 Hz. The additional factor 4 was the digital filter settling time. If the signal is changing faster than the settling time, you'll get aliasing-like effects too. So with 32768Hz Fsd16 you shouldn't sample anything above 128Hz with 9 significant bits or 4 Hz with 16 bits. If you obey this limit, then you'll get 1024 or 32 samples per second (except for the first three after changing the SD16 settings).

After all it's a complex task and I don't fully understand the mechanics myself (and those who do will surely nod now). Luckily I only have MSPs with ADC12 (while this may change in future), and the ADC12 is rather straightforward for high-frequency low-resolution sampling.