Here is an example of what might be sent. "hex:4;ffa500>" or "ref>" the first command takes in an index and color, while the second command refreshes the leds. However, I have seen this run at a high frame rate with these before so I know it's possible. I'm just trying to figure out how it worked back then and how I can recreate it without the weird workarounds. Like I said in the title baud rate is not the issue here. if I did my math right at 500,000 baud there should be around 20 microseconds between each character. That times a max command length of 15 characters times the 17 commands to update the leds gives me around 5.1 milliseconds. That kind of delay is a worst case scenario and it still gives a theoretical 192fps. what needs to be faster is the serial processing. I know the code that parses it isn't the problem as I've seen that run fast before and that has had no modifications. The part that is slowing it down is my serial receive methods. Interestingly enough the custom version of Serial.readBytesUntil() method I posted in my initial post and the built in readBytesUntil() methods yield almost the exact fps of 7.18 except in the conditions I described above.