FIRST QUESTION: binary vs. text/string:
Short answer: It depends on your situation/preference.
Longer answer: Some of the considerations:
The Byte Budget vs. Readability
"Binary" format usually requires fewer bytes of storage. An Integer 32 or Float variable uses 4 bytes. Integer 64s use 8 bytes.
The string representation of that same data would normally take more bytes, since 1 character = 1 byte.
For example, let's suppose you want to send some floating-point values. If you send/save just the values, that's 4 bytes each. If you're sending that file via a cell modem and the cell phone bill comes out of your budget, just sending those raw/binary bytes might be the best way to go.
However, we were talking about spreadsheets and csv and humans looking at this data, in which case it might be easier to troubleshoot (and import into Excel), if you build your file with strings maybe something like:
Since each of those characters takes 1 byte, that would mean each data point shown above would be 2 characters before the decimal point, 2 after, plus the decimal and the comma. That's 6 bytes per value vs. the 4 mentioned above.
If you are using floats, when you convert them to a string, you might have some rounding error depending on your data.
If you do go with binary, I'd recommend downloading a hex viewer like HexEdit. If you try to look at your file with other tools, you'll see weird characters. Firefox makes looking at your text file easy, since it's built-in ftp client is nice (binary on left, text on right):
For my 3-value example of 22.22, the 12 bytes in the file for "binary" (built using TransmitNumTable) would be:
[INDENT]8f c2 b1 41 8f 8f c2 b1 41 8f 8f c2 b1 41 8f [/INDENT]
Vs. 18 byes of string representation. Note:
32 hex = ASCII character 2
2e hex = ASCII character . (period)
2c hex = ASCII character , (comma)
[INDENT]32 32 2e 32 32 2c 32 32 2e 32 32 2c 32 32 2e 32 32 2c [/INDENT]
If the values were integer 32s, set at 22 (decimal) they would've been:
[INDENT]16 00 00 00 16 00 00 00 16 00 00 00[/INDENT]
(Forgive me if I've totally confused you, I'd be happy to elaborate further if needed. This form 1755 will tell you even more detail than you ever wanted to know about the bits/bytes in your float variables.)
I think it's a good idea to make sure you've finished writing the file (close the comm handle) then send it--keep track of the order so you're not accessing/sending before you're done recording.
However, I'm not sure why you mention the microSD card since you also mentioned sending the file via email or accessing it over the network. Why not just use the on-board file space rather than a card that could get removed? Check out this doc, form 1646 for details on how much space you have where.
But it sounded to me like you'd have 32 x 11 values. Even if you have a fancier string than my example with 10 characters per value, that's only 3520 bytes--so I wouldn't think you'd need the extra space on a microSD card. Did I miss something there?