What you are looking for is a way to safely interleave transmitting characters while at same time responding to the interrupts. You can wrap the sending of bytes with

noInterrupts();
swSerial.write("somethinglongyaddayadda"); // takes 50-60 ms
interrupts();

That will protect the write() operation from being interrupted and ruined by you sensor interrupt handler. But as you note, that will block the ability to process the the sensor every 2.5 ms. During the noInterrupts() period you would miss readings.

To achieve the interleave of both operations, you should transmit the message one character at a time. Implement a transmit queue to hold the outbound string. When it has characters, send them 1 at a time, wrapping each interrupt protection:

...inside loop...
if(txQueue is not empty) {
  noInterrupts();
  swSerial.write(one character from Q); // takes ~1 ms
  txPointerHead += 1;
  interrupts();
}
// at this point the interrupts are enabled 
// and the sensor will be processed if available
// if the interrupt occurred in the middle of the above, 
// the level is still set and the interrupt handler will be invoked
  

The 1 ms is ideal and not accounting for overhead, but it is unlikely the 1 character write time could stretch out to 2.5 ms. As long as the write time stays under 2.5 ms, you will never drop a sensor reading.

Note that this interleave means that the characters will have larger inter-character delay. The serial ports will not care about that. But if the processing of the sensor data takes too much time, you will not be able to keep up with your 10 messages per second goal.

Some options I see to improve:

1. Use a higher baud rate. The baudrate of the serial port is not related to the bluetooth data rate, so you might as well use the 115.2k. That will reduce the blocking time. The baud rate doesn't even need to be the same on both ends. The BT module isn't a simple modem; it is packetizing characters wrapping them in encryption and transmitting. The receiver unbundles the packets and pushes out its serial port at the receivers baud rate.

2. Use hardware serial. Using a hardware serial port greatly reduces the time because all write() does is put one character into a register. The time for that is microsecond domain. After the byte is put in the transmit register, the UART handles the clocking of the bits so the microcontroller is free to do other tasks.

What you are looking for is a way to safely interleave transmitting characters while at same time responding to the interrupts. You can wrap the sending of bytes with

noInterrupts();
swSerial.write("somethinglongyaddayadda"); // takes 50-60 ms
interrupts();

That will protect the write() operation from being interrupted and ruined by you sensor interrupt handler. But as you note, that will block the ability to process the the sensor every 2.5 ms. During the noInterrupts() period you would miss readings.

To achieve the interleave of both operations, you should transmit the message one character at a time. Implement a transmit queue to hold the outbound string. When it has characters, send them 1 at a time, wrapping each interrupt protection:

...inside loop...
if(txQueue is not empty) {
  // do not need noInterrupts() or cli() as these are inside write();
  swSerial.write(one character from Q); // takes ~1 ms
  txPointerHead += 1;
}
// at this point the interrupts are enabled 
// and the sensor will be processed if available
// if the interrupt occurred in the middle of the above, 
// the level is still set and the interrupt handler will be invoked
  

The 1 ms is ideal and not accounting for overhead, but it is unlikely the 1 character write time could stretch out to 2.5 ms. As long as the write time stays under 2.5 ms, you will never drop a sensor reading.

Note that this interleave means that the characters will have larger inter-character delay. The serial ports will not care about that. But if the processing of the sensor data takes too much time, you will not be able to keep up with your 10 messages per second goal.

Some options I see to improve:

1. Use a higher baud rate. The baudrate of the serial port is not related to the bluetooth data rate, so you might as well use the 115.2k. That will reduce the blocking time. The baud rate doesn't even need to be the same on both ends. The BT module isn't a simple modem; it is packetizing characters wrapping them in encryption and transmitting. The receiver unbundles the packets and pushes out its serial port at the receivers baud rate.

2. Use hardware serial. Using a hardware serial port greatly reduces the time because all write() does is put one character into a register. The time for that is microsecond domain. After the byte is put in the transmit register, the UART handles the clocking of the bits so the microcontroller is free to do other tasks.