Communicate with ZACwire interface?

[mooseo]

Hi,

I'm using some new relative humidity sensors that come with either analog or digital outputs. I've played with the analog version, and they seem to work well. I'd like to deploy a number of them in an experiment and was thinking that using the digital output version might be better (if only because I can get lots of  digital inputs for less money... like a USB 6501 for <$100).

The problem is that the digital output uses an interface that I'm not familiar with... something called ZACwire. The spec sheet for the sensor has a bit of sample code for using them with a microcontroller, but porting that to Labview seems a bit intimidating. 

Does anyone have experience with this ZACwire Communication Protocol? Any sample code reading it in Labview? 

The data sheet for the chips is here:

http://www.gesensing.com/products/chipcap_datasheet.htm

Thanks for any suggestions. 

mike

[ColeTrain]

mooseo,

The decoding we need to do here with the digital wire is Manchester decoding.  The humidity measurement is 8 bit while the humidity is 10 bit.  As far as how to do this in LabVIEW, the easiest implementation I can think of is using real-time.  Is that an option for you?  I will work on some test code and will see what I can come up with, real-time or not.

[mooseo]

Hi Cole,

Thanks for your thoughts. I would have to say that real-time might be a problem only because I have no experience programming that way. It would be nice if I could just drop the data from these sensors into a logging program I have built for temperature... I'm guessing that my current code will have to be completely re-written.

I could probably live with that since it might be an interesting exercise. In practice, though, I don't have much need for real-time since I gather data at very low rates (~1 hz). So if a non real-time solution comes to mind, that would probably be better. 

Would it be possible to have the logging program spawn a real-time vi that takes a data point and passes it back, or is this contrary to the whole idea?

Thanks!

mike

---

ColeTrain wrote:

mooseo,

The decoding we need to do here with the digital wire is Manchester decoding.  The humidity measurement is 8 bit while the humidity is 10 bit.  As far as how to do this in LabVIEW, the easiest implementation I can think of is using real-time.  Is that an option for you?  I will work on some test code and will see what I can come up with, real-time or not.

---

existing programs won't work with real-time 

[ColeTrain]

mooseo,

There is nothing to special about real time except for we know when it is executing.  Otherwise, the programming is very similar.  I have been trying to think of the best way to decode these digital signals, but there are a few limitations that are holding me up.  

1) How do we know we're reading on the proper clock edge (in software) if your device doesn't export the closk at all.

2) How can we make sure that we're sampling the proper part of the exported byte?  

Even if you are sampling at just 1 Hz, there will be 8 edges for every point that we will have to read and decode.  The real time suggestion just came more from the fact that we would know we're sampling at the proper times of the signal, but if we're sampling at a slow rate, we can just do this with a timed loop.  However, I still can't think of how to over come the previous two questions I laid out there.  Does anyone else have any ideas? 

About Manchester Encoding:

-- Each bit is transmitted in a fixed time (the "period").
-- A '0' is expressed by a low-to-high transition, a '1' by a high-to-low transition.
-- The transitions which signify 0 or 1 occur at the midpoint of the clock period.
-- Transitions at the start of a period are overhead and do not signify data.  These are neccesary when a series of 0's or 1's repeat.

 

(Image and description pulled from community page submitted by BullDozier)