I was trying to think about how we can assess the number of values coming into the burst. As we noted the other day, I believe as long as the burst actually triggers, we should have 30 values. However, I think this would be useful if we choose to sample at a higher rate or building some timing to allow for less values. I noticed the MonitorComms instruction. It seems that it acts like the W function in the terminal emulator. Perhaps we can create a BIG string variable to read in ALL of the incoming burst data, then parse it and count how many based on the # symbol using some string manipulation functions. Not necessarily high on the priority list, but I think it could be useful.
I was trying to think about how we can assess the number of values coming into the burst. As we noted the other day, I believe as long as the burst actually triggers, we should have 30 values. However, I think this would be useful if we choose to sample at a higher rate or building some timing to allow for less values. I noticed the MonitorComms instruction. It seems that it acts like the W function in the terminal emulator. Perhaps we can create a BIG string variable to read in ALL of the incoming burst data, then parse it and count how many based on the # symbol using some string manipulation functions. Not necessarily high on the priority list, but I think it could be useful.