I did what you suggested in other way around: readings in ISR and sending in the loop. I will definitely experiment with your suggestion.
It depends on how you want to "clock" the sending of the sampled data.
If you send the sampled data readings from the ISR then it will be sent at specific
time intervals regardless of how often the actual real samples are done.
If you send the data in the foreground, then more than likely the messages sending the sampled
data will not be on specific time intervals, while the ISR is updating the contents of
what is being sent at the specific time interval.
Worst case, is that the foreground is hammering out messages much more often than the
data is being sampled. (Although you could add extra code to ensure that messages only
were sent out at specific intervals)
But if the messages don't have to be on any specific timing then why bother
with an ISR? Just sample the data and send it as fast as you can.
I tend to think the other way around. Sample the data as needed or as fast as you can
and essentially maintain a "cache" of the sampled readings.
The ISR then pushes this "cache" to a receiver on periodic intervals
or sets some flag to tell the foreground to send all the accumulated samples.
Another option would be to sample each sensor and send its value immediately
after sampling slowly building up the full message as you go.
There are many ways to skin the cat.
BTW, if your receiver is a HOST with USB support, you could switch something like
a Teensy board which would allow you push serial messages over native USB at USB speed
instead of at TTL serial BAUD rate speeds.
(baud rate is ignored when using serial over native USB).
Again, it would be useful to have more information about your overall system goals/needs
to be able to make suggestions of how to attack the problems, as perhaps some
of them might go away by considering alternate approaches.