SERIN WAIT and STRWAIT argument options.....

ed e

Using WAIT to capture a known byte or series of bytes works fine. But what if the only known byte is exactly what you don't want to capture and you want to capture anything else?

I have an analog sensor that sends it's measurements serially. Each measurement is sent with four bytes, the first being "hundreds" the second "tens" the third "ones" and the fourth and final byte is a "CR" to terminate the transmission. With a small pause between measurements, the data flows continuously. So the majority of information sent is actually just zeros as we wait for the next event to measure.

My first approach was to capture the first measurement sent by writing an argument that looks for anything with the hundreds and tens greater than one before moving on in the program. My problem is that because of the nature of the analog sensor and the physics of inertia, the first measurement sent is not always the maximum measurement, which is what I want to capture and display.

From analyzing the data sent from the sensor, the maximum measurement might not occur until the second or third measurement sent.

The solution appears to have the BS2 WAIT for data that has the hundreds and/or tens bytes greater than one and then to capture a string of the first four measurements to be compared in the body of the program to have the maximum displayed.

My problem is writing a WAIT argument. I can't get past syntax errors. Are math arguments even allowed? And at 9600 Baud do you run a risk of missing other measurements if the BS2 takes too long to analyze the first two bytes?

So I thought I better put this out to the people who know. Any ideas?

Thanks

Chris Savage

Ed,

If the data packets are CR terminated, couldn’t you wait for a CR then grab the following bytes until the next CR?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

Unsoundcode

Hi Ed, the following equates to a WAIT

a VAR Byte
b VAR Byte
c VAR Byte

DO WHILE (a+b)<1
SERIN 16,16468,[noparse][[/noparse]a,b,c]
LOOP

Jeff T.

ed e

Hi Chris,

The only problem with waiting for a CR is that if the sensor only sends one measurement, which sometimes happens, followed by a CR, you'd never get the data needed. Also, keep in mind, the sensor is always sending data followed by a CR. Think of it as always measuring something, if there's nothing to measure it sends 0,0,0,CR. So what you might see if you analyzed the data sent is;

0,0,0,CR 0,0,0,CR 0,0,0,CR 0,6,4,CR 0,8,1,CR 0,0,0,CR 0,7,9,CR

or you might see;

0,0,0,CR 0,0,0,CR 0,0,0,CR 0,9,4,CR 0,0,0,CR 0,0,0,CR

Because the sensor is hand held there is no way to better the accuracy of the measurements. I was hoping to compensate for this within the software itself.

Though this is a microwave sensor it might help to think of the sensor as a voltmeter. If the leads aren't on a voltage source it would always display (or send) 0,0,0. If you touch the leads to an outlet you'd now see (or it would send) 1,2,0. I believe the microwave sensor sends a measurement every 10ms or so. It could even be 100ms, I never measured the pauses. Things become even more fun when you get values like 0,9,8,CR and 1,0,4,CR in a quick burst because now the leading zero is gone in one measurement and the tens digit is a zero in the other, but I can deal with that in code.

I was thinking of just maxing out the ram and grabbing all I can then analyzing it, looking for data that is greater than 0,0,0, to display but I run the risk of missing a valid measurement while the BS2 is analyzing whats already been captured since data is sent at 9600 baud.

So that's why I put this out there. It's a bit of a puzzle and I wanted to see if anyone else has tackled a similar problem.

Thanks,

ed e

ed e

Jeff,

You know, that just might work. I'll try it and let you know how I made out in a day or two.

ed