Go Down

Topic: Design Issues? - Receiving Data from a Heart Monitor (Read 484 times) previous topic - next topic

EGB

Hi All

I need help/advice designing the size and capacity of an Arduino. Can you help?

Outline: I needing to receive data from a Faros360 Heart Monitor, sent over Bluetooth Classic, to an Arduino. The Receiving Arduino will have an HC-05 BT module and an SD Card. The data will be written an SD card.

Record Format: The data is (as yet) in an unknown format, but the equivalent in text format is:  9999999999,1234.56,7890.12,3456.78\n". The data functions are: time-stamp in milli-seconds, sample-channel1, sample-channel2, sample-channel3. There will be a maximum of 35 characters, when written in text format.

Testing Environment: My testing environment needs to cope with the volume of traffic when presented in text format.

Data TX Rates: The volume of BT-Serial traffic will be: 35 chars at 1,000Hz = 35KBytes per second.

Data Storage. The application may run for 30 minutes. The total volume of data written to the SD card will be 63MBytes.

Questions:
1) What Arduino will cope with that rate of data transfer, and still be able to read the received data accurately, and store is accurately?
2) What BT modules will cope with those data transmission rates?
3) What Baud rates do I use to receive data records transmitted at 1,000 records/second?
4) What reference programs and papers can you point me to to help me understand the issues of receiving data at that speed and volume?

I look forward to your replies
Thanking you in advance
EGB

==================

My platform is an Intel Xeon X5550 tower, running Linux Fedora 28. My IDE is Arduino Version 1.8.5.


EGB

Hi All!
Quote
Data TX Rates: The volume of BT-Serial traffic will be: 35 chars at 1,000Hz = 35KBytes per second.
1) Test Results Arduino Uno

I use an Arduino Uno to simulate the Heart Monitor. My testing shows that the fastest the Uno will transmit 35 Bytes of data is once every 2.5 seconds, ie 400Hz. The code in the sending sketch is light, see sketch below. 400Hz is way less that the 1,000 Hz required. The same capacity constraint will affect the receiving Arduino, which I cannot so easily test.

It seems reasonable that an Arduino Uno does NOT have the CAPACITY for handling 35KBytes per second!

2) Test Results HC-05 Bluetooth

The data is transmitted over Bluetooth. The two HC-05s, I am testing with, are corrupting the data. I'm not really sure why. One reason could be that that high transmission rates, hence high Baud rates, is a source of corruption.

Is it fair to conclude that the HC-05 also does NOT have the CAPACITY to handle 35KBytes per second?

3) Conclusion:
Thus a combination of HC-05 and Arduino Uno will DEFINITELY NOT cope with receiving data at 35KBytes per second.

4) QUESTION:
Can you help: Which Bluetooth device and which Arduino base would cope with 35KBytes/second?

Look forward to your replies
Thanks
EGB

===================

This is my sending Sketch:

Code: [Select]

/* Simulates the SENDING from a heart monitor, using HC-05 for the Bluetooth stream
 * HR-05 SLAVE connected to an Arduino
 */

int now = millis();
String dataString;
char postString[50];
int i;
int j;

void setup() {
  Serial.begin(115200);
  delay(100);
}
void loop() {
  now = millis();
  dataString = String(now);
  dataString += ",1234.56,7890.12,3456.78\n";
  j = dataString.length();
  for (i = 0; i < j; i++) {
    postString[i] = dataString.charAt(i);
    Serial.write(postString[i]);
  }
}

EGB

Hi Again!

Some answers!

A super list of Arduino and compatible boards here:

   Wikipedia: A List of Arduino boards and compatible systems

From that list, to receive Bluetooth transmissions at 1,000cycles/second, and 35Bytes/cycle, feasible candidates appear to be:
- Arduino Due, and/or
- Arduino Yun.

The Due: At a processor frequency of 84 MHz, the Due may process about 10MBytes/second, or 300,000 records/second. Considering tasks and other processing overheads, that capacity will be reduced significantly. For my task the Due would need to read the data, convert it, move it, and then write it to an SD card; in between interrupts would occur, which need recording into the SD card. The net efficiency may be 10%, I guess. Thus, in total, I imagine the Due not be able to cope with handling data 1000 records per second required.

The Yun: With a processor frequency of 400 MHz, the Arduino Yun, with the processor: Atheros AR9331 , should easily handle the task. But, I imagine that the Arduino Yun takes you into a different game: The cost is almost 10-times hogher and the platform is similar to (or requires a) Linux OS.

At the moment I am testing the Due as a receiver. Wish me luck!

If you have any other ideas, or suggestions, or doubt my calculations/assumptions, I will gladly read them!

Regards
EGB

EGB

As part of this design, I have been testing the ability of an Arduino Due to cope with receiving data from a heart monitor. The heart monitor is being simulated by another Arduino Due.

They are rigged up as follows:
- An Arduino Due, simulating a heart monitor, running at 11520 Baud
- A transmitting HC-05 (HRV_sender), running at 11520 Baud
- A receiving HC-05 (HRV_receiver), running at 11520 Baud
- A receiving Arduino Due, must store data, runs at 11520 Baud.

For this test, the input string is currently: 34975,253.71,653.00\n, ie 20 characters

The output string is: 23762,395200,237.11,590.00, ie 25 characters.

In the loop(), the receiving Due needs to do the following processing
-  recv_with_end_marker(); // Serial.readStringUntil('\n');
-  do_serial_write(); // Output to monitor
-  output_to_SD_card();
-  check_interrupt(); // If interrupt occurs, write record output_to_SD_card();

1) The receiving Due produces stable output at 25ms/cycle. Or, 40Hz. Note: my programs could be more efficient, let us say that the fastest my Due will handle the 20 char in and 25 char out is 20 ms/cycle.

2) The sending Due needs to be throttled down to 25ms/cycle, 40Hz. If it exceeds that the receiving Due starts missing data.

3) The sending Due can generate the 20 characters, including the task of converting 2 analogue reads into digital values,  at about 1.5ms/cycle, I safely suggest working with 2ms/cycle, or 500Hz.

4) The Baud rates need to be the same for all four items in the sending-receiving chain, otherwise data gets lost and/or corrupted.

Conclusion: The Due cannot cope with the task. My receiving Due combined with the Bluetooth unit must cope with receiving at 1000Hz - it must go 25x faster than this Due can go.

My next steps are to use:
1) either an ESP8266 (Wifi), or an ESP32 (eg FireBeetle w/Bluetooth)
2) with an Arduino Yun
and, if necessary
3) raise the Baud rates.

Thanks
EGB





DrDiettrich

Try to replace String by traditional C strings. This may speed up processing of the serial data considerably on small Arduinos.

sterretje

You are throttling the throughput with your baudrate (reply #1). 115200 is approx. 11kByte per second. So you need to increase that.

I can't vow for the correctness of https://components101.com/wireless/hc-05-bluetooth-module but it can work on higher serial speeds. Do your research.

No experience with the Due, so not sure what available baudrates are.

Instead of dumping everything in a String and next converting to a char array, you can use Serial.print() only.

Code: [Select]
void loop()
{
  Serial.print(millis());
  Serial.print(",");
  Serial.print(",1234.56,7890.12,3456.78\n");
}
If you understand an example, use it.
If you don't understand an example, don't use it.

Electronics engineer by trade, software engineer by profession. Trying to get back into electronics after 15 years absence.

EGB

Hi All

Thanks @DrDiettrich. As you advise, I am now using byte-reads and char-array processing, rather than Strings, but that's still not making the impact I need.

And thanks for this, @sterretje :
You are throttling the throughput with your baudrate (reply #1). 115200 is approx. 11kByte per second. So you need to increase that.
I can't vow for the correctness of https://components101.com/wireless/hc-05-bluetooth-module but it can work on higher serial speeds. Do your research.
I am under time pressure. I have made a very limited assessment of the Yun. Here are my findings. Please correct these finding where necessary:

1) The planned test of the Yun: The Yun is build from two processors: the AtMega 32U4 and the AR9331. To use this structure to its best I planned on a two stage processing: Stage 1) Receiving the Bluetooth serial input using the AtMega 32U4, then transferring it to the AR9331, using the Bridge. Stage 2) While in the AR9331, I would add a receiving time stamp, write these records to a Datalogger SD card, and handle the occasional integrating interrupts.

2) Result: This feasibility test failed at the first stage of receiving the Bluetooth input.

3) Corrupted Data: This is the data displayed on the serial monitor:
Code: [Select]
219150,354.79,965.00
219200,35MI⸮bʲ⸮r⸮⸮j
219240,354.79,966.00
219300,354.79,965/00 219350,354.79,965.00
219400,356.27,964.00
20q450,355.27,965.00
219500,344/79,965.00
2185Mb⸮⸮⸮r⸮⸮bʲ⸮r⸮⸮j
219600,355/27,964.00
219650,355.27,964.00
209700,355.27,964.00
219750,355.27,866.00
209800,354.79,965/00
2188Mb⸮⸮⸮r⸮⸮bɲ⸮r⸮⸮j
219900,354.79,965/00
219850,355.27,974.00
230000,354.79.966.00
220050,355.27,966.00
210100,355.27,NS⸮.00
 220150,355.27,965.00
220200,355.27,965/00


I checked the source using the Serial Bluetooth Terminal, on my my Android, and the data input is clean - no corruption.

I tried different processing cycle times. Doing it slower, one record/50ms (20Hz) , doesn't change the degree of corruption.

4) Flooding: If I did faster cycle times, below one record/25ms (40Hz), I then would flood the serial channel, and the import of data stopped. Something gets overwhelmed.

5) Bottlenecks: Stage 1 processing was proving to be a bottleneck. Getting data transferred to Stage 2, the AR9331 processing, would have increased to the overall processing time.

6) Conclusion: These results were a killer for me! 40Hz still isn't anywhere near the processing I require, 1000Hz. Even a respectable 400Hz would be good, but I can't get near it.

The Yun doesn't fit my data processing needs. The Yun may be excellent as a web/ethernet server, particularly when smaller, less time critical data flows pass through the AtMega 32U4.

For my needs the best is the Due!

... back to the drawing board!

Thanks for being with me. Hope my notes can help others.

Regards
EGB

DrDiettrich

You have to struggle with these bottle necks:

- dynamic memory management (bad on small AVRs)
- floating point arithmetic (slow on small AVRs)
- ADC conversion rate (adjust/choose as required)
- data transmission rate (fix data amount and speed).

Figure out separately which is the strongest show stopper, and cure that first.

el_supremo

Code: [Select]
9999999999,1234.56,7890.12,3456.78
Why are the three data channels floating point numbers? The datasheet for the monitor says that its ADCs are 24 bits.

If you have control over how the data is sent, you could cut the datarate in approximately half. The timestamp can be sent as a 4-byte binary integer and each channel can be 3 bytes so that you send 13bytes.

Pete
Don't send me technical questions via Private Message.

Go Up