Sizing data acquisition application

Dave S.

I have a data acquisition project that I am trying to choose the right processor for.

The concept is to install equipment on a small, shallow boat and sweep an area in an orderly but arbitrary fashion collecting time, position, and depth information.

There are lots of GPS units that have serial interfaces; the Parallax unit has a 1/s update rate. I can source a small "smart" acoustic depth sensor with a similar but asynchronous 1/s update rate that has an RS-485 interface.

For reasonable accuracy I expect to have a second, fixed station to collect GPS information (again asynchronously) during a survey.

Conceptually, I can use a BS2 (I think) to collect GPS information and depth information (which I will have to time-tag somehow) and write the data out to a memory stick.

It would be helpful to have a small operator display to show time, depth, speed, and course.

In post-processing, I can normalize the position and depth information (which is why I think I need to time-tag the depth data), curve-fit the normalized data in two-dimensions, and generate iso-depth curves (the marine version of topographic maps). Also in post-processing I will correct for state of tide (the US convention is to show depths on charts relative to mean low water - essentially average low tide). Data from the fixed station can be used to perform differential GPS corrections in post-processing (I've actually done that before). Finally, a graphical "chartlet" of the surveyed area is generated. Note all the heavy computation is done in post processing on another platform.

A BS2, GPS, small LCD, and USB data-logger cost roughly $190 (ignoring development environment); I'm still collecting costs for a watertight enclosure, the depth sounder, and power supply.

Is this within the computing power and I/O capacity of a BS2? I've looked at PC/104 SBCs but they seem like overkill for a datalogging application.

thx, dave

Post Edited (Dave S.) : 6/17/2008 3:25:16 PM GMT

Mike Green

The biggest issues you will run across:
1) All Basic Stamps have limited variable storage (26 bytes). That's probably enough for simple datalogging. The Parallax GPS unit has a controller that reduces the amount of data that the Stamp has to deal with at any one moment which helps a lot. The GPS unit provides real time/date information which you can use for time stamping.
2) All Basic Stamps can do only one thing at a time. When they're receiving data from one device, any data from another device is ignored. Fortunately, only your depth sensor is really asynchronous. The Stamp can use that as the "master" for its measurement cycle and query the GPS unit and manage the LCD display and datalogger between depth measurements.

If you want to do more local processing, rather than just simple data logging, consider using a Propeller since it can do fairly fast floating point and has much more memory. There are I/O drivers available for the GPS unit, LCDs, PC-compatible SD card use, and general serial I/O and all of the I/O is done in parallel with other processing.

stamptrol

· Dave,

·· Sounds like you're doing something similar to the one I worked on.

·· http://forums.parallax.com/showthread.php?p=560623

·· To overcome the storage issue, we sent the data ashore by wireless link and stored the data using Hyperterminal's capture function. We used the mobile gps string to get a time stamp. The remotely controlled catarmaran was electrically powered, directional control via r/c setup talking to a Stamp.

·· PM with any questions.

· Cheers,



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk

http://www.siskconsult.com
·

Dave S.

Tom,

Thanks for your link. I agree the applications are analogous. I may get pretty far from the mother ship (my 40' sailboat) exploring creeks, so the wireless link seems less robust than spooling data to a file on a memory stick. I should think the processing requirements are similar.

Mike,

I appreciate your thoughts. I agree that using the depth sounder as the master "tick" makes sense. Unfortunately polling the GPS doesn't tell me what time it is, only what time the latest fix was taken. That may seem like splitting hairs, but I already have to deal with the fundamental (in)accuracy of GPS (figure 15m uncorrected, 3 - 5m w/ differential corrections, and 1 - 3m w/ WAAS (not supported by the Parallax unit as near as I can tell, but a GPS mouse for about the same price does)). For a survey speed of 5 knots (about 2.5 m/s) and asynchronous update rates of 1/s for both sensors timing is a first order source of error.

I clearly don't need real-time performance, but I do think I need to keep timing errors done to around 250 ms. Given a 2(ish)m positioning accuracy during initial data collection and another 2(ish)m positioning accuracy during use of the "chartlet" and ignoring calculation and data errors during normalization and tidal correction (<grin>) I think I get 25% reduction in RMS error by reducing timing error from 1s to 250 ms. Easy access to an RTC is one of the appeals of a full-up SBC, but the cost would go up a good bit.

sail fast, dave

N.B. I have found a couple of sources for WAAS GPS pucks that run on 5VDC and cost between $60 - 90, so I am inclined to use a WAAS solution over a DGPS one.

Post Edited (Dave S.) : 6/17/2008 7:22:02 PM GMT

Mike Green

If you want accurate times, you would be better off using a Propeller since that uses a crystal controlled clock and the clock is directly accessible unlike the Basic Stamps where there is a resonator or crystal controlled clock, but it's not directly accessible to the programs running on it. You could use an external real time clock, but most of those only provide a reading to the nearest second. With the Propeller, the limiting factor on clock accuracy would be temperature stability.

Post Edited (Mike Green) : 6/17/2008 7:17:55 PM GMT

Phil Pilgrim (PhiPi)

At the very least, be sure both GPS units are the same make and model. This will help (a little) to ensure that your differential position corrections come close to being accurate, but there's no guarantee. A problem arises during those intervals when one GPS acquires or drops a satellite before the other one does. This will cause their position calculations to be based on slightly different data, which could adversely affect any differential corrections during that interval. By sticking with identical GPS units, these "intervals of incoherency" might be minimized.

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 6/17/2008 8:48:07 PM GMT

Dave S.

I've been through the readily available literature on GPS accuracy and determined that WAAS with one receiver is cheaper than DGPS with two receivers, so a much cheaper solution with higher accuracy that avoids the incoherence that Phil noted.

I'm waiting to hear back from the depth sounder source with application notes. I've built a little simulator that more or less asynchronously generates $GGRMC and $DDPT sentences so I can work on timing. While I wait for the application notes I'm going to start on the post-processor to generate the "chartlets" and read the Stamp documents for the BS2 and Propeller to educate myself a bit.

Can anyone point me to examples for RS-232 and RS-485 (I need one each) interfaces?

dave

stamptrol

dave,

For rs232, there are several common chips available. I like the MAX233 because it doesn't need external capacitors for the neg.voltage generation.
RS485 uses the 75176 which is very easy to use as well. Use 1 for half-duplex, use two for a quasi-full duplex, 4-wire connection.

Keep us updated on your progress.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk

http://www.siskconsult.com
·

P Williams

Dave,

I am very interested in the depth sounder you refer to - any chance you could share your source?

Tx,

Peter