Fion,
I had a quick view onto your code. Have seen some problematic issues. But I have not seen a basic fault. So it probably has to do with the way you control your device. So you may try to correct these points:
1. It makes no sense to open, configure, use and close your serial port for every single value (inside your large while loop). Move the configure and the close node out of that loop!
2. IMHO the same holds true for the RTS/CTS control thing. It might be a specific way how your device is to be controlled, but I suspect this to be the cause of your problem. I'd try to delete the first unassert_RTS and wait_until_RTS_is_set (the little while loop in the upper end of the big while).
3. In between the assert_RTS and read_2_bytes I'd insert a byte_at_serial_port node and feed that result (if it is at least 2) into byte_count of VISA_read.
4 You should insert a wait_ms somewhere in your large while, best in the case when byte_at_serial_port was < 2.
Wait 1 ms, as it takes about 2bytes / (2880/s) = ~0,7 ms to transmit the two bytes for a single measurement with your baud rate.
5. If your device would provide its measurements continuously, you would get a complete set of 10 measurements every ~7ms, from which you calculate your heart rate. Although your device will probably not deliver _so_ fast, this is much to short for a heart rate calculation. You'd need at least about 2 to 5 _seconds_ to yield reliabel results. Why not adding some timing into your loop in order to not rely onto your device?
6. Furthermore, I am not sure if an SpO2 measurement is a good source for heart rate calculation at all.
7. You may cast your two read bytes to a U16 instaed all those array manipulations.
8. Your large while and the remainder of your code is running in parallel. So your strip chart _might_ be cleared befor the first data arrive. But this might as well happen _while_ or after that! Please enforce the proper sequence of operation, either by using a sequence or by implementing some data dependencies.
9. As questionabel as your style is, it has no problem with byte order. If you read your data continuosly (as I'd suggest), you should add some precaution to enforce the proper byte order. Either your device sends out some specific characterisation of the high and low byte. Or you have to process a pair and check if this yields to an acceptabel result or not. If not you should dismiss one byte and retry with 'moved' pairs.
10. The little while right to the large one operates much too often. Either include a wait_1000_ms or so or let its content run once, _after_ the large while has finished.
11. It is very bad style to have any loop running to poll something and not to have at least a little wait in it. This takes all CPU cycles that it can get, just to poll. In your case you would not loose anything with a wait_100_ms. This would give all the other parallel running processes the chance to run smoothly as well.
Just my 0.02 €!
Greetings from Germany!
--
Uwe
