Shop OBEX P1 Docs P2 Docs Learn Events
Snow gauge - projaect about done - summary — Parallax Forums

Snow gauge - projaect about done - summary

PlitchPlitch Posts: 39
edited 2014-10-16 13:32 in General Discussion
I have asked a number of questions here and received helpful answers, so I thought I'd share the end of a project. Hopefully it might be of use to another user. It's quite lengthy and detailed. THANK YOU to all who patiently helped me along the way!

Project Background:

A nearby nature preserve helps restore and manage habitat for the endangered Karner Blue butterfly. The eggs of the butterfly, deposited on blue Lupine plants in July, winter over and hatch the next population of butterflies in the following June. The associated biologists are concerned that low snow cover might result in poor insulation and consequent freezing of eggs and low productivity and therefore have enlisted a significant number of volunteer “stick readers” who dutifully ski or snowshoe to several locations in the field to take depth readings on a frequent basis so that the scientists may attempt to correlate snow depth with egg survival over winter. The project has been under way for a few years.

In addition to a concern about the butterfly viability issue, I also have an interest in using volunteer hours as effectively as possible. I though that perhaps using some kind of automated snow measuring device might be more “volunteer manhour” effective than having volunteers reading yardsticks in the snow all winter.

Besides aiding in butterfly restoration and science, the nature preserve also offers many passive recreational opportunities like X-C skiing and snowshoeing on groomed trails. Our web site offers a page with the latest trail conditions during the winter, updated by the groomer after each session on the trails. There is also a link to a www.wunderground.com weather page which displays current weather data from a personal weather station located near the preserve trails. It occurred to me that having a graph or just a current reading from a trail-side depth measuring device would give members of the public, interested in using the trails, quite a bit of information about current weather and trail conditions in the woods of Wilton.

Requirements:

To produce an instrument that could be useful in the field, several requirements had to be met.

1. It must be capable of measuring snow depth autonomously
2. It must be accurate and consistent
3. It must be self powered
4. It must communicate wirelessly
5. It must be reproducible
6. It must be inexpensive
7. It must produce data that is easily used and universally accessible

Of course if one is locating an instrument right next to a building, some of these requirements are no longer relevant and the building and debugging project becomes much easier. Power, for example, may be supplied by wire from the building which eliminates the need for an independent power source. I decided that whatever technology I employed, the resulting project would be a prototype of a “field” unit so that any issues relating from engineering for the field requirements might be addressed.

Solutions:
There are a few available technologies to measure snow depth “robotically.”

One of the easiest and cheapest would be to point a camera at a measuring ruler and have the resulting image available on a distant PC or TV. A clerk would then enter the depth number periodically in a database. However, this requires human intervention, interpretation of the image may not be precise, and it’s easy to forget to read the ruler once in a while. In short, this might not be an improvement over having volunteers read sticks.

Another possibility is to use a weather station that collects and melts the snow and automatically posts a meltwater equivalent inches of precipitation which can then be translated back to inches of snow by applying a density multiplier. This method is commonly used, but not the best. In fact, the weather station at the nature preserve offices does this. The amount of snow intake to the instrument may be impacted by design and winds, and most importantly, snow density is not a constant, and a wet heavy snow will not “translate” from meltwater to depth of fallen snow in the same way as the equivalent amount of dry powder meltwater. Since the object of this experiment is to measure snow depth, the possibility of a significant error occurring as a result of using an “average” density translation is a serious problem.

It is also possible to not measure snow at all. Instead, measure temperatures at the surface of the ground under the snow, and at specific depths. Soil temperature technology is readily available for many existing weather instruments. Since the object of the experiment is to determine if eggs in a specific height range (up to 8 inches above the ground) might be impacted by temperature, direct measurement of temperature at various depths of snow might be a good indicator. A set of four or five probes set two inches apart along a vertical support could be interfaced to a weather station. This could produce an inexpensive result that would not be subject to “translation” errors as is snow depth - translating depth data to “freeze/no freeze” information makes assumptions about the insulating qualities of various density layers of snow. Measuring temperatures under snow cover makes no such assumption. However, this technology did not lend itself to long distance monitoring.

Finally, the use of ultrasonic ranging was considered. An ultrasonic device bounces a high frequency “click” off the ground, and measures the time for the echo to return to calculate the depth. It does directly, robotically, and “non-invasively” measure the depth of snow. The results can be easily collected. And it can be made autonomous and wireless. However, ultrasonic sensors are not cheap, nor are there a wide variety of ultrasonic snow measurement devices available. In fact, none fit all the criteria listed in the “Requirements” section.

After some conversations and analysis, I decided to try to build a prototype ultrasonic snow measuring gauge.

General Design:

A quick look at the existing ultrasonic snow gauges described on internet sites indicated that simply clamping an ultrasonic sensor to a horizontal arm extending from a post so that the sensor was “looking” down would allow the sensor to measure the distance to the ground or the distance to the snow. One concern in selecting a sensor was to find one that would be sensitive enough to detect soft powdery snowfalls which are not highly echo reflective.

The gauge would also have to be autonomously powered. While some examples of gauges are powered by the cable providing the data path (“1-wire” for example), the nature preserve design was to be completely wireless, so the only technology considered was solar, involving solar arrays (AKA solar panels), batteries, and charge controller electronics.

To be wireless and autonomous, the gauge would need to communicate by radio to send data to whatever “database” was out there.

Of course, the gauge would have to have a “brain.” This unit would be responsible for controlling the number of sensor readings taken per day (to control power use) and the way in which sensor readings were taken and averaged. In addition, it would store the data and control the radio to send it to the database.

At the receiving end of the system, a personal computer (PC) would be set up with a receiving radio and software to capture the incoming data to a database. Finally, the same PC would have to be equipped with software to allow the remote sharing of that data over the internet.

Equipment selection and building:

The simplest part of project construction was fabricating the frame. While the visible frame appears to be a wood frame that looks much like a “T” or inverted “L”, in fact it is a “C” shape. Unseen is the baseplate and a horizontal frame linking it to the vertical post. A ground level base representing “bare ground” height, which is simply a 4 foot by 4 foot piece of marine plywood painted white, was screwed to two treated 2” x 6” timbers so that the base surface would always be exactly the same distance and perfectly plumb compared to the sensor located on the upper cross arm. The upper cross arm had to be small enough not to significantly block falling snow, and a treated wood 1.25” x 1.25” was selected with a large metal rod brace under it to hold it rigid. In addition, the frame also supports a plywood base for the solar arrays and a board to support the metal box containing the electronics. The sensor is approximately 8 feet from the baseplate.

The “brain” of the gauge is a Basic Stamp PLC (Programmable Logic Controller)from Parallax. This unit was chosen since it is relatively cheap and owing to its industrial uses, is well protected from the environment with packaging and protective circuits. It is easily programmed (and re-programmed) using a variant of the BASIC language, and has both digital and analog inputs and outputs. The disadvantage of this unit is that it must be provided 24 volt DC (VDC) power, as are most control systems used in an industrial environment.
The Parallax Stamp PLC was equipped with a low power Basic Stamp 2e processor and a MAX1270 analog-to-digital converter which allowed maximum flexibility in processing sensor inputs. Programming and programming changes could be done on-site with a simple temporary RS-232 serial connection to a laptop computer.

Connecting the Basic Stamp PLC to the rest of the instrument is a printed circuit prototyping board (Radio Shack) which contains a few simple circuits. A relay controlled by the PLC turns the power (24 VDC) to the ultrasonic sensor on and off. A relay controlled by the PLC turns the radio power (12 VDC) on and off. There is a “voltage divider” circuit which reduces the battery voltage ( 0 – 30 VDC) to a range consistent with the PLC’s analog-to-digital converter range (0-5 VDC). This divider circuit allows the Stamp PLC to monitor and report battery voltage to determine the “health” of the power system.

One of the objectives in designing the software to run the gauge was to economize on power. To this end, the operating “cycle” of the gauge as controlled by the PLC software is:

* Wake up (or boot up on a cold start)
* Turn on the ultrasonic sensor
* Let it warm up 5 minutes
* Take a battery voltage reading – store for transmission
* Take 50 depth samples at 1 per second and average them
* Turn off sensor power
* Turn on radio power and let it get on line
* Send depth and battery voltage data
* Turn off radio
* Go to sleep for about three hours
* Go to the beginning and do again

In addition to the “normal” operating software, there are a few other routines (stored on the laptop) that allow rapid feedback at the instrument so that a “no snow” depth level – the sensor output voltage associated with the distance from the baseboard to the sensor can be set by software and the functioning of various parts of the instrument can be verified on site.

The PLC sends the raw sensor voltage, the snow depth in inches, and the battery voltage to the PC for recording in the database.

Selection of an ultrasonic sensor has been problematic. The first selection worked well at detecting the plywood base board, but steadfastly refused to recognize the depth of any snowfall. A lack of sensitivity is suspected to have caused the unit to be deaf to echoes from a snowy surface. This year it was replaced with a SensComp Mini-AE sensor which (thi model anyway) is designed to run on 12 to 24 VDC and outputs a 0- 10 VDC analog signal proportionate to the distance (depth of snow). This unit has adjustments for target distance as well as adjustments for sensitivity. Because of its position when mounted, it is impossible to use the pushbuttons to set zero, so this is still done under software control by setting the zero level in PLC memory. Sensitivity has been left at the factory default with good results so far. Since the use of ultrasonic echoes to measure distance is dependent of the speed of sound, the sensor has an automatic compensation for temperature to allow an accurate estimation of speed of sound and the resulting distance to target.

The ultrasonic sensor is sold as a bare unit. It was then wired and housed in a small watertight plastic box which was in turn mounted inside a weather station “pagoda” (Davis Instruments). This device is a slatted plastic housing which protects a weather instrument from the direct heat of the sun but allows air to naturally circulate, providing a good environment for measuring air temperatures accurately. The whole pagoda and sensor assembly is clamped to the cross arm with two “U” bolts. These can be used to set the unit perfectly plumb and level over the plywood baseplate.

Power to the gauge is provided by two 12 volt, 7 Amp hour gel-acid alarm system batteries. There is a “center tap” to provide 12 VDC to the radio power circuit, and both batteries are used in series to provide 24 VDC to the sensor and PLC “brain.” Power to the sensor and to the radio is controlled by the PLC operating two relays, one for the 24 VDC supply to the sensor and one for the 12 VDC supply to the radio modem. The PLC is always powered up, but can be put into a low power demand “sleep” mode for hours between readings and woken up by internal clock. The batteries are recharged by two 12 VDC, 5 watt (each) solar arrays wired in series to provide 24 VDC to a charge controller. This device prevents the charge rate from becoming too high and will also cut off power to the gauge in the event that a lack of sun has caused the batteries to become too discharged. When the batteries are recharged sufficiently by the sun, the charge controller will restore power to the gauge, the PLC (“brain&#8221[noparse];)[/noparse] will reboot, and the gauge will come back on line automatically. The solar arrays are mounted on the top of the gauge frame at an angle slightly more than the latitude of the site (and facing true South) to allow for improved performance during the winter months.

The radios (1 for sending gauge output, 1 for PC input) are both Xbee RS-232 Radio Frequency modems with a range of about 1 mile line of sight, or 300 feet indoors. If desired, these could be replaced with more expensive units with a significantly longer range, but otherwise identical characteristics. It is also possible to create a network of radio equipped devices, each with a unique ID attached to the radio. However, none of the "intelligence" of the radios is used in my prototype application - they just act like a long invisible cable for simple serial communications.

Inside a nearby office building, the receiving radio is attached to an old PC which is used in part to allow the snow gauge data to be accessible over the internet. To do this, a “serial port monitoring” software program captures the incoming voltage and depth data from the snow gauge (Advanced Serial Data Logger Lite – aggsoft.com). It adds a system date and time field (from the PC clock) and saves the complete record in an ASCII text formatted file ( snowlog.txt). The same PC also hosts an FTP server program ( Easy File Sharing FTP Server – www.sharing-file.com)that allows any registered person the ability to copy the snow gauge database file over the internet using any browser that can do FTP (File Transfer Protocol) file copies. This is most of the browsers in use today. Access to the database file via FTP is restricted by use of user names and passwords, but in general any person in any location with internet access (and a password) could easily access the database.

Currently each record (reading) in the file contains the date and time field, the raw sensor millivolts, the calculated depth of snow, the battery voltage, the software version number employed, and a comment field. This layout could be easily changed to suit requirements if necessary.

The file as copied to a user’s own PC via FTP is a simple “comma delimited text file.” As such, it can be imported into almost any spreadsheet program and used for further analysis.

Fine Tuning:

One of the problems introduced by using solar power is the variation between nighttime and bright sun voltage levels, which can move from 23 + VDC at night to 28+ VDC during the day. An analysis of the data from the gauge suggested that the high battery charge voltage condition (greater than 24 VDC) was being handled by power conditioning in the PLC, but the ultrasonic sensor was reporting erratic readings correlated to battery voltage. Adding a 24 VDC DC-to-DC converter allowed the switched power to the sensor (only) to be regulated to a constant 15 VDC. This has reduced the variation in output.

Recent multivariate analysis of the accumulated data on spreadsheets has determined there is no significant relationship between the solar panel output and variation in depth measurements, and also between the temperature and depth measurement. In other words the internal temperature compensation is working and the DC-to-DC converter has stabilized the sensor operating voltage.

The power relay circuits could be simplified by using 12 VDC for both the radio and the ultrasonic sensor. The reason for 24 VDC power to the sensor is because the original (replaced) sensor required 24 VDC. The Min-AE will work with 12 to 24 VDC, so just 12 VDC might work fine without the necessity of a regulator, although 12 VDC is the minimum allowed. However, the Stamp PLC does require 24 VDC and no alternative is available.

The “sleep” period that the PLC induces allows the unit to operate at a very low power level so that on average the batteries can recharge enough to operate all night without tripping the charge controller’s power down routine, causing the whole gauge to go dead until battery recharge occurs. With the current sizes of batteries and solar arrays, a 3 hour cycle (approximately) between depth readings has been selected. It would be nice if the BASIC Stamp or the PLC had a real time alarm clock built in so that the time period could be better programmed. A possible option would be to add a battery operated real time clock controlled power switch and simply turn all the electronics off (but of course allow battery charging) for 3 hour periods. When the power is restored, the PLC reboots anyway, so it would operate exactly as it does now.

If more than one gauge were to be set up, each could communicate with the receiving PC and maintain separate records in a database if a unique gauge ID field were included in the transmission from each gauge. This could easily be included in the PLC program for each unit, or it could be accomplished by progarmming each snow gauge radio in the field to a unique radio ID.

The relays have proven to be “noisy” and a bit unreliable. It would be worthwhile to find solid state switching circuits for both the 24 volt sensor and 12 volt radio power circuits to replace them. I am, however, an electronics moron, and would have to farm that design work out.


Program for Basic Stamp PLC with MAX1270 A/D Converter


'==========[noparse][[/noparse]TITLE}==================================================
' File..... StampPLC_snow_xx.BS2
' Purpose . Contol StampPLC based ultrasonic snow depth measuring station
' Author .. Pieter Litchfield
' Copyright 2007, 2008, 2009 - All Rights Reserved
'E-mail.... pvcl@plitch.com
'===================================================================
'
'
[noparse][[/noparse] Program Description ]
'
' This program reads a 0-10 volt input from an SensComp Mini-AE ultrasonic sensor and
' converts to a scaled digital value representing the inches of distance
' and then converts to inches of snow depth. The resulting snow depth
' is transmitted via radio modem in rs-232 format to a PC for recording
' and reporting.
'
' In addition, the voltage state of the batteries is read and sent at the
' same time as the snow depth is sent.
'
' The program also controls the power state of the various components
' to reduce power use when not engaged in actual measurements. Two relays
' provide 24 volt power to the ultrasonic distance sensor and 12 volt DC
' power to the modem. These are turned on and off before and after readings
' to conserve power since the unit is expected to use solar power.
'
'
[noparse][[/noparse] Revision History ]
' 0 Just text and formatting, no code
' 1 Added code for ADC 4/1/07
' 2 Revised ADC code to add PLC volt divider factor and millivolt scale 4/7/07
' 3 Added code to store zero depth value in eeprom on key press
' 4 Added modem and sensor relay power subroutines
' 5 Added long division routine to get snow depth to 4 places
' 6 Added code to scale sensor millivolts (0-5000) to battery volts (0-24)
' 7 Modified the voltage range to 0 - 50VDC 7/8/07
' 8 Changed to a sample of 10 readings from 5
' 9 Moved modem power on command to reduce possible electrical noise during sensor reading 7/17/07
' 10 Review & tidy up 8/5/07
' 11 Changed power up sequence for sensor and modem
' 12 Changed volts-per-inch factor to observed value 9-19-07
' 13 Longer warm up for sensor and added samples
' 14 Moved zero-snow-volts setting routine to seperate program 9-28-07
' 15 Trying for 4 hours between readings. no intro text transmitted
' 16 Added an equal weight averaging routine - last read & this read/2 10-20-07
' Added a comment field for edits on data fle later. 10-28-07
' Added an output field for mvolts raw reading 10-28-07
' 17 Changed averaging routine to 200 sample moving average with continuous history
' 18 Added rounding factor to averaging, changed warm uperiod 11-14-07
' Added write and read to eeprom - last sensor average for cold statup data
' number of sensor samples reduced to 100 - spreadsheet shows this to be enough
' to get a stable moving average
' 19 Increased delay between readings to 3 hours
' Reduced warm-up time to 3 minutes
' 20 modified A/D converter setup to allow 0-10 VDC output. Changed VPI
' to reflect 0-10 volts over 6 inches - 240 inches for use with Senscomp sensor.
' 21 Added Mvolts to output statement and changed to subtract current reading from
' no_snow_volts since sensor voltage is reduced with height using SensComp
' mini AE
' 22 Removed first CsADC in sensor reading subroutines to better zero readings.
' Did Not work, so replaced 02-19-09
' changed to favor current reading adresult averaging for test
'
'
[noparse][[/noparse]TEMPORARY PRODUCATION NOTES]
' after on site installation, the battery voltage will have to be compared with a meter to verify
' that the voltage scale is accurate - it assumes that the divided voltage (0-5)at the stamp is
' scaled to 0-50.
' Above was resolved by using an adjustable potentiometer in the voltage divider circuit
' and comparing the actual terminal voltage (approx 25 VDC) with the reported voltage
' and adjusting the potentiometer to get agreement.
'
' Note that the volts-per-inch (constant VPI) is based ON the factory seting of the
' ultrasonic sensor that produces a linear change in output voltage (0 - 10 VDC)
' over a range of 6 - 240 inches, thereby producing a constant voltage change
' per inch of distance to target.
'
'
'
[noparse][[/noparse] INITIALIZE ]
'
' {$STAMP BS2e} ' compiler directive
' {$PBASIC 2.5} ' compiler directive
'
'
[noparse][[/noparse] constants ]

awhile CON 15000 ' PAUSE used TO allow modem to come on line
a_long_time CON 60000 ' length of a long pause - 1 minute
a_second CON 1000 ' 1 second pause
briefly CON 10 ' pause interval when using ADC shifts
hour CON 10000 ' used to sleep for approx 3 hrs between readings
version CON 22 ' software version number
VPI CON 427 ' millivolts-per-inch of sensor scale
' 6-240 inches = 0 TO 10 VDC
Warm_up_minutes CON 5 ' number of minutes sensor on before readings
samples CON 50 ' number of depth samples per reading
'
[noparse][[/noparse] variables ]
'
adResult VAR Word ' raw data from analog to digital convers.
Accum VAR Word ' accumulates voltage readings for average
depth VAR Word ' snow depth as calculated, integer part
D VAR Word ' denominator of long division - volts per in
F VAR Word ' fractional accumulator of long division in depth
I VAR Byte ' calc
J VAR Byte ' index for long division loop, depth calc
Mvolts VAR Word ' depth sensor 0-5000 millivolts corrected
N VAR Word ' numerator of long division process
no_snow_volts VAR Word ' stored value for min volts - no snow distance
' corrected millivolts
VoltResult VAR Word ' battery voltage input from ADC
X VAR Word '.1,.01,.001,.0001 place holder in log division
'
'
[noparse][[/noparse] I/O Definitions ]
'
AinAdc PIN 5 ' A/D Data in
AoutAdc PIN 4 ' A/D Data out
ClkAdc PIN 0 ' A/D clock
CsAdc PIN 3 ' Chip Select for ADC
Dat PIN 2
Load PIN 1
modem PIN 15 ' modem power relay is on Dout 2
sensor PIN 14 ' sensor power relay is on Dout 1
'
'
[noparse][[/noparse] Initialization ]
' load zero depth value stored in eeprom one time on startup one time
'
READ 6, Word no_snow_volts

' set initial value in data accumulator for this round of readings
READ 2, Word Accum
'
' send reboot message
'
GOSUB modemon
DEBUG",", " REBOOT ",CR
GOSUB MODEMOFF
'
'
'
[noparse][[/noparse] PROGRAM CODE ]
'
' do forever
DO
'
' turn on ultrasonic sensor
GOSUB sensoron
'
FOR j= 1 TO warm_up_minutes 'warm up temp sensor
PAUSE a_long_time
NEXT
'
' get a battery voltage reading On analog channel 2
'
GOSUB ReadVolts
'
' get a snow depth sensor reading 50 times on analog channel 1
'
' Accum will have saved value from memory or last calculated value
'
FOR j = 1 TO samples ' get a set of sensor readings
'
PAUSE a_second 'PAUSE FOR a second before another sensor reading
GOSUB ReadSensor ' get a sensor reading
Accum = (( 9*adResult)+Accum+ 5)/10 ' average 9 times current plus 1 times history
' ' accum value retained for next session
NEXT
'
' end of sensor reading loop - accum has readings accumulated & averaged
'
'
GOSUB sensoroff ' turn off ultrasonic sensor
WRITE 2,Word Accum ' save current sensor resding in EEPROM
' turn on modem
'
GOSUB modemon ' in case of restart
'
Mvolts = Accum + Accum + (Accum ** 28967) ' x 2.4420 scale 4095 to 10000 millivolts
'
' convert distance to target to snow depth
' automatically scales inches per volt depending on no_snow_volts value each time
'
D=VPI ' denom. is sensor volts-per-inch of depth const.
N = No_Snow_Volts - Mvolts ' numerator is volts above whiteboard
IF Mvolts > No_Snow_Volts THEN N=0 ' no such thing as negative distance - assume it is zero
'
N=N*10
Depth = N/D ' integer result of division
X = 1000 ' placeholder for .1,.01,.001,.0001
F=0 ' F is the fractional part accumulator
'
FOR J=1 TO 4 ' 4 places
N=N//D*10 ' remainder *10
F=N/D*X+F ' accumulate next digit
X=X/10 ' next place holder
NEXT
'
' send depth in ASCII character to modem for transmission
'
DEBUG ", ",DEC4 mvolts,",", DEC Depth,".", DEC4 F, ", "
'
'output battery volts To modem for transmission To PC
'
n = voltresult * 10 ' increase scale to get more sign. digits
d = 1000 ' scale 0-50000 to 0-50 by using 1000 in denom
I=N/D ' I = integer result
X = 1000 ' placeholder for .1, .01, .001, .0001
F=0
' ' F is the fractional part accumulator
FOR J=1 TO 4 ' 4 places
N=N//D*10 ' remainder * 10
F=N/D*X+F ' accumulate next digit
X=X/10 ' next place holder
NEXT
'
' send voltage reading in ASCII characters to modem for transmission
'
DEBUG DEC I,".",DEC F, ",", DEC version, ", Comment", CR
'
' shut modem off
GOSUB modemoff
'
' put StampPLC to sleep for a while
'
SLEEP hour 'change constant hour to adjust length of time between readings
'
' end do forever
LOOP
'
'
[noparse][[/noparse] SUBROUTINES ]
'
'
[noparse][[/noparse] Get data from ADC chip from ultrasonic sensor ]
'
ReadSensor:
'
adResult = 0 ' zero reading variable
LOW CsAdc
PAUSE briefly 'select chip
SHIFTOUT AoutAdc, ClkAdc, MSBFIRST, [noparse][[/noparse]%11111000] 'Ch1 0-10 VDC
PAUSE briefly
HIGH CsAdc
PAUSE briefly 'trigger
LOW CsAdc
PAUSE briefly
SHIFTIN AinAdc, ClkAdc, MSBPRE, [noparse][[/noparse]adResult\12] ' get result
PAUSE briefly
HIGH CsAdc
'
' adjust ADC count for PLC input voltage divider
'
adResult = adResult + (adResult ** $D6C) MAX 4095 ' x -1.05243
'
' adResult now contains a number from 0 - 4095 which represenst a sensor voltage
' adResult still needs to be scaled to 0-10000 millivolts
RETURN
'
'
[noparse][[/noparse] Get data from ADC chip for battery voltage monitor ]
'
ReadVolts:
'
VoltResult = 0
LOW CsAdc
PAUSE briefly 'select chip
SHIFTOUT AoutAdc, ClkAdc, MSBFIRST, [noparse][[/noparse]%11100000] 'Ch2 0-5 VDC
PAUSE briefly
HIGH CsAdc
PAUSE briefly 'trigger
LOW CsAdc
PAUSE briefly
SHIFTIN AinAdc, ClkAdc, MSBPRE, [noparse][[/noparse]VoltResult\12] ' get result
PAUSE briefly
HIGH CsAdc
'
' adjust ADC count for PLC input voltage divider
'
VoltResult = VoltResult + (VoltResult ** $D6C) MAX 4095 ' x 1.05243
'
' adjust voltage (0-5000 mvolts) from scale of 12 bits (0-4095) to 0-5 volts
'
VoltResult = VoltResult + (VoltResult ** $3880) ' x 1.2207
'
RETURN
'

'
[noparse][[/noparse]turn sensor power ON ]
'
sensoron:
'
LOW sensor
PAUSE a_second
RETURN
'
'
[noparse][[/noparse]turn sensor power OFF]
'
sensoroff:
'
PAUSE a_second
HIGH sensor
RETURN
'
'
[noparse][[/noparse]turn modem power ON]
'
modemon:
'
LOW modem
PAUSE awhile
RETURN
'
'
[noparse][[/noparse]turn modem power OFF]
'
modemoff:
'
PAUSE awhile
HIGH modem
RETURN
'
'
[noparse][[/noparse]end of program]
'
END

Comments

  • Ken GraceyKen Gracey Posts: 7,392
    edited 2009-04-21 21:08
    Hey Plitch,

    Not a specific reply to your post, but I thought you might be interested in a water-resistant Ping))) sensor that we currently have in design at Parallax.

    This sensor works from 10 cm to 200 cm. Will have conformal coating and integrated wiring harness (not the 3-pin connector that is shown). We expect to have it by the end of summer in our inventory. At present we're in the final stages of design. Price will be $39.99.

    Ken Gracey
    Parallax, Inc.

    attachment.php?attachmentid=60294
    700 x 700 - 70K
  • PlitchPlitch Posts: 39
    edited 2009-04-22 00:25
    Ken:

    Thanks for the suggestion. I'll be curious to see how it will interface to the PLC which is a bit different than a Stamp prototyping board in its hardware and software interfaces to the real world.

    FYI, the cable required for my project is about 10 feet long, and I used twisted pair, foil shielded with bare drain line to ground to try to minimize any possible "noise." Out in the middle of a field, there probably isn't much.

    The Parallax sensor price is approximately 1/2 the price of the SensComp part, so that''s a good thing!

    I will attach a picture of my completed project.
    2112 x 2816 - 275K
  • MooneyguyMooneyguy Posts: 77
    edited 2014-10-16 10:36
    Great job!
  • idbruceidbruce Posts: 6,197
    edited 2014-10-16 12:13
    Plitch

    I did not have the time to read it all, because I am in the middle of machining something, but for what I was able to read, I must say that it was well written and interesting. Good job!

    Bruce
  • PublisonPublison Posts: 12,366
    edited 2014-10-16 13:13
    Of course, you guys know this post is over five years old. :)

    And the transducer that Ken elated to in Post #2 never saw the light of day. :)
  • idbruceidbruce Posts: 6,197
    edited 2014-10-16 13:28
    Now you tell me :)
  • MoskogMoskog Posts: 554
    edited 2014-10-16 13:32
    Publison wrote: »
    Of course, you guys know this post is over five years old. :)

    And the transducer that Ken elated to in Post #2 never saw the light of day. :)

    Yes, bad that ping-sensor never was available.

    Would be interesting to know how this project went, if it still is running.
Sign In or Register to comment.