Please send us a message for The Billboard by clicking HERE!!!

I have been given the task of writing a driver for a sdi-12 encoder,
this will be done in a machine language using ladder logic. Has this been
done before and are there any examples of this?
Any help in this matter would be greatly appreciated
Thank you
John Benton
Technical Supervisor

John,

Due to the many timing constraints of the SDI-12 protocol the use of ladder logic in developing
a complete SDI-12 driver is not recommended, nor do we know of any examples. A more
cost-effective solution would be to purchase existing equipment to render the interface between the
encoder and the host. RS-232 to SDI-12 converters are on the market which would serve you well
in this capacity. All you would have to do is provide the proper ASCII string to the converter (ex: aM0!
where 'a' is the address) which would then be relayed to the encoder using the correct protocol. Some
converters even follow-up with the D command to retrieve the data automatically. In this case, a single
ASCII string is all that would be required to perform a measurement.

By using a converter your code would not be responsible for the onerous details of the protocol (waking
the sensors, byte-to-byte timing, receipt of service request, retries, etc...) but rather simply sending
and receiving ASCII strings. 

I work for Allen-Bradley Company, a major supplier of industrial controls and programmable
logic control systems. A customer has recently asked us to consider development of an interface
for our industrial logic controllers to SDI-12 protocol. We do have several products in which we
can implement custom ASCII drivers written in C or BASIC, but all of thosehave RS-232 or
RS-422 interfaces.

I read a recent posting on the SDI-12.org discussion billboard in which an RS-232 to SDI-12
interface was recommended, but a supplier was not specified. I've searched all the websites
linked to your site and not found anything like this. Can you recommend a maker for such an
interface?

Thanks for your time,

Ken Roach

Rockwell Automation / Allen-Bradley
Seattle District Office
kiroach@ra.rockwell.com
 

Ken,

I can only hope that the appearance of your letter on the Billboard will generate some interest and a few responses.

Section 5.2 of the SDI-12 Standard seems a bit ambiguous regardingretries. The last
paragraph of section 5.2 says " Because the data recorder is the master of the SDI-12
bus, it is not required to issue a retry. The requirement is for a data recorder to support
retries."
My question is this: If a data recorder is the "master" on the SDI-12 bus, who else can/will
issue the retries that the data recorder is supporting? I know that the "Transparent mode"
entry in the included Glossary refers to a computer, terminal or modem sending commands,
but will there always be one or more of these on the bus?

Perhaps it's obvious from my question that I don't have much experience with SDI-12, but
there may be others who could benefit from a little clarification on this point as well.

Thanks in advance for your help,

Dan Baker

Dan,

To be conformant with the latest version of the SDI-12 protocol the data recorder MUST issue
retries if one of the three conditions listed in section 5.2 arises as shown in the flow control diagram
of Appendix B.

>"Because the data recorder is the master of the SDI-12 bus, it is not required to issue a retry. The
> requirement is for a data recorder to support retries."

This statement simply says that because the recorder is the master and not the slave, it controls the
conditions for which retries are issued. Conformance, therefore, need not imply that the recorder
issue a retry for all conceivable situations, but rather only those listed in section 5.2.
As stated in section 5.2: "Under extraordinary conditions, not as normal operating procedure,
the data recorder has the option of not issuing retries." These "extraordinary conditions" or not defined
and are left to the discretion of the programmer. However, if you do not issue a retry under "normal
operating conditions" your recorder is not guaranteed to successfully communicate with a conformant
sensor. This is because some sensors might require wake-up times that would rely on retries in order to
properly read the incoming command.

> My question is this: If a data recorder is the "master" on the SDI-12 bus, who else can/will issue the
>retries that the data recorder is supporting? I know that the "Transparent mode" entry in the included
> Glossary refers to a computer, terminal or modem sending commands, but will there always be one
>or more of these on the bus?

The specification assumes that the recorder is ALWAYS the master. You appear to be unclear on the
concept of "transparent mode" which in turn led you to think that in order to conform with the spec
something other than the recorder must issue a retry. Please NOTE: ONLY the recorder is the master
and ONLY the recorder issues retries as described above. While in "Transparent mode" a ASCII string,
which consists of a SDI-12 command, is sent from the computer to the recorder. The recorder then
transmits this command onto the SDI-12 bus, wakes the sensors, etc ... The recorder, as master, must
perform all that is required of it to obtain a valid response from the sensor as detailed in the SDI-12
specification, including retries. This response is then relayed to the computer which completes the cycle.

We are already a SDI-12 user for some sensors, especially river level measuremen.  We now intend to use
SDI-12 sensors in some special applications to measure river level and we have some technical
questions and would appreciate it if you could help us. Following are the questions:
What is the maximum cable-length possible between SDI-12 sensors and a data-logger?

Is there available in the market SDI-12 modems? If so, could you recommend a manufacturer?

Thank you very much and have a nice day.

Luis Tarciso:
<luis@simepar.br>
 

Luis,

According to section 1.0 of the SDI-12 specification (version 1.3 available on-line in PDF form), the maximum distance between a SDI-12 sensor and logger is 200 feet.  With multiple sensors this distance is reduced substantially.

I regret that I do not know of such a device.  However, your request may be met by responses from manufacturers reading your posting.

I have searched thru everything I can think of, but I can't find a SDI water temp sensor. Can you help me?

Earl Dixon
703-406-2800

Brock Hileman
brockh@autoelect.com

Perhaps you should call Earl Dixon, he may have found something.  I cannot recommend a manufacturer.

The SDI-12 standard verions 1.2 and 1.3 is deficient in the handling of exclamation mark. It is possible
for the data recorder to send a command with an imbedded exclamation mark, which causes the sensor
to reply while more characters are being sent by the data recorder. This results in line contention and
invalid data could be processed. Most conditions are caused by improperly formatted commands.
e.g. (for our proprietary sensor)
0! valid reply as "0<cr><lf>"
0!!  unexpected reply "0<cr><lf>" or sometimes reply parity error
0!!! reply framing error
0!!!! reply "a" (one character)
0A!! no repsonse (trying to set address to exclamation mark)
0X!! no repsonse (extended command, we have not implemented X command)

Recommend changing the standard:
1. Move the last two sentences in 4.2 to the end of section 4.3. "Other printable characters can be used
as addresses. They are not, however, defined in this specification."

2. Change section 5.2 Retries, paragraph "Invalid responses include...", from "The sensor must wait..." to
"The data recorder must wait...". Add new sentence "Invalid commands must be ignored by sensors".

3. Add to section 4.2, "The exclamation mark (!, 0x21) cannot be sent in a command except as
command terminator."

Alternatively:
4. Add to section 4.4, "A command is terminated by 8.33 msec of marking". Change the SDI-12 Data
sensor flow chart, in the bubble box after detecting valid address byte, from "look for ! or .33 msec
marking while loading the command" to "Accumulate data bytes until 8.33 msec marking or maximum size
exceeded". The valid command decision box would then verify the last byte is an exclamation mark.

On another issue:
Suggest amending the Appendix D revision for version 1.3 to add "5) Change the maximum response size
to 35/75 characters. (section 4.4)"

David Lee
System Tester
Sentek Pty Ltd
77 Magill Rd
Stepney
South Australia

Respectfully,
Michael M. Shoemaker
Mike.Shoemaker@noaa.gov

HOME