BS2 SERIN trying to read ASCII string input

JimK

I·have a weather sensor http://www.sparkfun.com/commerce/product_info.php?products_id=8311·which from what I understand from their doc has a Serial output as a single visible ASCII string at 9600bps 8-N-1.· Every second a new set of readings is seen as 6 cells separated by commas.· See attached code for more details on the cells.

A sample line looks like: #21.81,081.28,026.5,079.70,083534,000001$

When I first saw this sensor it seemed somewhat like a GPS sensor the way it returns ASCII output and thought I could use WAIT("#") and SKIP to parse the string apart.· I have tried 3 different code subroutines (attached) with little luck and was wondering if anyone could offer suggestions of what I might be doing wrong.·

From reading the SERIN doc I also was wondering if it may be easier to use a BS2P with·the SERIN SPSTR· option to read the entire string at once and parse it in memory ? I followed the recommend wiring example on their site supplying input voltage in the pins marked GND 4-7V and using the TX and RX to the Stamp pins.· I am not using any pull up/down resistors and do not know if that is an issue?· In my code the best I could get was subroutine "TRY3" which always returns the first 20 bytes although I have know idea how it knows·sync to the starting deliminter of the # ?· The other two subroutines return random data in the debug window.

Any thoughts or suggestions greatly appreciated.· Thanks

Post Edited (JimK) : 9/13/2008 1:32:28 PM GMT

Bruce Bates

Jim -

Data formatters take a fair amount of time to execute. Add to that 9600 baud is the high end limit for any Stamp short of a BS2px. It _may_ be possible with slower Stamps but I'd almost guarantee it with a BS-2px you will have no problems.

Sorry about that

Just make sure to buy whatever Stamp you are going to purchase before this weekend is up. Great sale that Parallax has on all the 24 pin Stamps - $49.00 EACH!

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Involvement and committment can be best understood by looking at a plate of ham and eggs. The chicken was involved, but the pig was committed. ANON

JimK

Thanks Bruce - I'll put in an order for a BS-2px today.

Tracy Allen

Your "Try3" subroutine works most of the time because it does not eat up that extra instant of processing time required by the WAIT("#") modifier. The STR modifier by itself has the fastest byte-to-byte timing. With the string being transmitted once per second, STR by itself it will usually succeed, but would fail if it happened to hit the SERIN command right in the middle of a transmission. The same issue will occur for the SERSTR command on the BS2p or BS2px, but it is not hard to adjust your program timing or parsing algorithm to hit it right every time. At least SPSTR will give you space for the entire string.

An alternative is an external serial buffer. For example, the uFPU from Parallax has a built-in serial buffer as well as the capability to auto-Parse the input string. Plus the math horsepower to do a lot of the (non-trivial) calculations for the sensors.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

JimK

Thanks Tracy for the suggestions.· I did order a uFPU both the v2 and 3.1 from Parallax a few weeks ago thinking I would need it to convert the barometric reading from Pascal to the more traditional inches but did not realize it has string processing functions as well.· After reading the doc it looks like the v3.1 chip is the one to use ?

Tracy Allen

Yes, v3.1 is the one that has the serial functions.

The data is not in the form of an NMEA string, so you cannot use the uFPU NMEA parser directly. But there are other STRxxx commands that can position the string pointer on a field after a delimiter on your list (the # and the ,) and convert the field to a number. The uFPU can then help with other math like computation of dew point from RH & temperature or altitude from pressure and temperature.

I'm curious how you are doing the interface to the USB slave from the Stamp. It might however be possible to hack the unit to bypass the FTDI USB interface and to take the i/o directly into the Stamp from the ATMEGA.

I see that they include the ATMEGA .c source code. That's nice. You can see how they did the data capture and the calculations and with a little more work you could, for example, change the string format to NMEA. A nice device.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

JimK

Hi Tracy,

The weather board also offers· RX,TX pins which is how I am using it.· It seemed very similar to reading a GPS sensor with a serial string output every second but I did not know about the timing issues on the BS2.· I have read a GPS sensor before using WAIT and SKIP and assumed this would work the same. What I liked about the sensor was it offers temp, humidty and barometric pressure on one board. I do have a uFPU v3.1 and will start reading the doc on that.· Thank you again for the tip of using the string functions.· I never would have thought of using a math co-processor for string manipulation.

Jim

lenswerks

Jim,

Do you know if the SF board header you are connecting to is compatible with the BS? It is designed for use with their Bluetooth module which I think is 3.3V.

Donnie

Tracy Allen

Hi Jim,

The GPS at 4800 baud may give just enough time after a character for the Stamp to interpret and do the other necessary work to process the WAIT or SKIP or DEC or other modifiers. At 9600 baud it doesn't work. An extra stop bit or pacing delay can make all the difference.

Sparkfun kindly provided the source code, and the the main loop is transparent:

            printf("#");
            print_decimal(humidity, 2, 4);
            printf(",");
            print_decimal(temperature, 2, 5);
            printf(",");
            print_decimal(scp_temperature, 1, 4);
            printf(",");

            scp_temperature *= 90;
            scp_temperature /= 5;
            scp_temperature += 3200;
            print_decimal(scp_temperature, 2, 5);
            printf(",");
            print_decimal(pressure, 0, 6);
            printf(",");
            counter++;
            print_decimal(counter, 0, 6);        
            printf("$\n");

If you have the ATMEGA tools, I guess you could recompile that with a millisecond delay between each command. There is a delay routine available too in the source code,
void delay_ms(uint16_t x)
Or put the delay at start and end of the subroutine,
void print_decimal(uint32_t number, uint8_t place, uint8_t pad)

That would allow the Stamp to process the string using WAIT and SKIP etc., still leaving it at 9600 baud bit rate. Or, if using it with the uFPU, the i/o routine could be rewritten as an NMEA string in order to take advantage of the uFPU's NMEA autoparsing.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

JimK

Hi Donnie,
You are correct the header for the bluetooth has pwr,gnd,rx,tx but there is another header for power marked 4-7V which is what I am using with 5 volts, and just using the rx and tx pins on the other header. They have a sample wiring diagram which is where I found this. Hope this helps.
Jim

JimK

Hi Tracy,
Thanks for the additional thoughts on the processing issues I am seeing. I think for now I will try the uFPU 3.1 chip since I am new to this and the ATMEGA, compiling is probably over my head at this point. In addition I think I will need the uFPU to carry out the conversion for the barometric presure reading from pascals to inches.
Jim