under hood of HTU21DF sensor part 2

Schematic view of sensor with Pins:

image

  • GND: Ground
  • VDD: Voltage for Sensor between 3.6 to 5 Volts DC
  • SCK: Serial Clock Input is used to synchronize communication between master(microcontroller) and HTU21DF sensor.
  • Data: Serial data pin is used to transfer data in and out of sensor and device.

Communication Sequence with Sensors:

  • Start Sequence: A single bit. To initiate transmission start bit has to be issued by microcontroller.
  • Stop Sequence: A single bit again to indicate completion of transmission of data (along with CRC) and if required release holding of SCK.
  • Sending Command: After start bit to indicate initiation transmission, next is to send command to sensor identified by sensor address (similar to MAC address)
    • Device Address of HTU21DF address in hex 0x40 (in Decimal system = 64)
    • Device address is 7 bits wide with last bit capturing type of operation (Read / Write)
    • Thus controller will send initiate communication to HTU21DF Sensor as below for both read and write operations

As I2C protocol specifies, Start –> Address of Sensor (With Read / Write intent)

Read Operation:

image

Write Operation:

image

HTU21DF sensor responds (as its address is 0x40) with ACK (Acknowledgement). Then controller sends command to HTU21DF sensor. Commands their Hex and Binaries are below.

image

In comment section above there are “Hold Master” and “No Hold Master”. As detailed in previous post, I2C protocol provides options where sensor may choose to control serial clock (SCK).

Hold Master ensures control of SCK is with Sensor and controller can not perform any other actions with other sensors if available but is kept in waiting state till sensor measurement is complete. On the other hand, No Hold Master implies, control is SCK is with master (controller) and controller is free to communicate with other sensor. Additionally a polling is done with read command to check if measurement is done.

HOLD MASTER is analogous to synchronous programming and NO HOLD MASTER is equal to Asynchronous programming but with polling. May be NO HOLD MASTER is good for situations where there are more sensors on board.

Post measurement, data is sent by Sensor 2 bytes MSB(Most Significant Byte) followed by LSB (Least Significant Byte) and a checksum.

Additionally on LSB, last 2 significant bits are reserved for transmitting status information. In LSB (Bit 1 is used to indicate temperature / Humidity). 0 Temperature and 1 Humidity.

Communication Flow:

Step 1: Start (Initiate) session to Sensor (Slave in this case HTU21DF)

Step 2: Issue Write intent to sensor indicated by address

image

Step 3: Sensor sends ACK to master

Step 4: Issue “Measure Humidity with HOLD” command

image

Step 5: Sensor sends ACK

Step 6: Issue read intent to sensor with address of sensor.

image

Step 7: Sensor takes control of SCK line and makes master (microcontroller) wait till measurement is complete.

Step 8: Send Data. Post measurement sensor uses 14 bits (of data) + 2 bits (status) to send measured data using SDA line as output from device. Data is divided into 2 sections Most Significant Byte (MSB) and Least Significant Byte (LSB). First sent is MSB followed by LSB.

image

In above example, relative humidity is measured as 31827 (add numbers on right column (except status bits). Status column 1 indicates measurement is humidity (0 implies temperature).

Step 9: HTU21DF sensor provides CRC8 checksum. is computed by sensor and sent as an additionally redundant byte for data verification.

In this manner communication takes place between master (microcontroller) and I2C compliant sensor like HTU21DF.

Next section we will understand formulae for RH (relative humidity), Temperature and also verify data integrity from device using checksum provided in checksum Byte.

Appreciate if readers review and correct mistakes

Till then….

Abhyast..

Advertisements

under hood of HTU21DF sensor part 1

There is so much to learn and so many moving parts in technology now a days, am always reminded of what I do not know, rather than what I know. Hope that clarifies my very basic knowledge and would be glad if someone corrects mistakes in this post. In this post I am trying to learn Sensors to do a side project in my company. So this is a idiots guide to sensor specifically HTU21DF sensor.

HTU21DF is a digital sensor for capturing “Humidity” and “Temperature”. Sensor provides signal in I2C (I Squared C)  format. I2C is a serial communication protocol that communicates over Two Wire Interface (TWI). In this post, let us learn about I2C / TWI Protocol.

I2C / TWI Protocol:

  • A Micro-controller will have limited number of pins.
  • But sensor that a micro-controller can serve are many but limited by pins.
  • A two wire interface bus is built around 2 lines
    • 1 SCL – Clock (Synchronizes data transfer between master & sensors)
    • 1 SDA – Data (Carries data)
  • These two wires / bus helps connect multitude of sensors to Microcontroller.

Schematically I2C bus along with sensors is something as below, in which each sensor is Slave is connected to microcontroller using two wires (bus) one for Signal Clock and other for Signal Data

image

With 7 Bit address, 128 devices (sensors+ Masters) can be added to controller and with 10 bit addressing 1024 devices can be used using serial bus. Every sensor has unique address on bus, that master uses to communicate to that sensor.

Data Protocol:

Chunk 1: 

  • S= Start Bit.
  • A0 to A6 are address bits for Sensors for data transfers
  • A7 type of operation (Read / Write) that master will perform on slave.
  • Followed by Acknowledge bit used by slave to acknowledge receipt of previous sequence of bits from master.

image

After ACK, master device hands over control of SDA link to sensor with address in Address bits.

Chunk 2:

image

Post ACK, are bits for internal registers for sensors. For example temperature  / humidity sensors will have internal registers to capture either address  / data. When detailing HTU21DF we will deal again with these internal registers.

Chunk 3:

Data being transmitted either from Master to Slave to Slave to Master depending upon RW bit set in Chunk 1 and finally ends with a Stop bit to indicate communication between Slave and Master ends.

image

Above outlines how I2C protocol works on a Two Way Interface using Serial Bus Architecture.

Next up is understanding specific sensor, HTU21DF in terms of “Address”, “Internal Registers” and “Data Format” packet.

Immediately following up with next blog that utilizes these concepts with sensor..

–Abhyast

Event Based ARchitecture

Learning and understanding any technology (aka, rampup), more abstract from design principle and technical implementation, more transfrable , reusable knowledge. Or simply put, understand product or solution to its utmost depth (bordering academics), so that knowledge thus gained is valid across technologies and stands perinial.

Am given a task to understand, compare “Complex Event Processing” engines like

  • Apache Storm
  • Amazon Kinesis
  • Azure Stream Analytics

Started with reading an excellent article on Event Driven Architecture by Brenda M. Michelson https://dl.dropboxusercontent.com/u/20315902/EventDrivenArchitectureOverview_ElementalLinks_Feb2011.pdf.

Have I experienced Brenda’s architecture, hence this blog.

In an “Event Based Architecture”, EVENT is a central abstraction and basis of everything that happens post event. EVENT is highly generalized, to include anything that happens, be it due to sensors or smart devices, shop floor machines,  business transactions (order or inventory management systems) through services and solutions or could be due envoirment. Also EVENT concept is all encompassing, anything that happens under “Universal Model” till BIG BANG can be viewed as event. Philosophically, Life is a sequence of notable, forgettable sequence or layers of events.

One implicit assumption with EVENT being base  is,  “event” occured / took place in the past, detected and captured. “EVENT BASED ARCHITECTURE” deals with what to do with an event and how to handle events when scale is necessary.

Question should not be whether events occur, but more apt questions are

  • Do we / can we capture all events that occur?
  • If yes, are they interesting and what can be learnt?
  • How to learn from event and what action (if required) to be taken?

Events are Sensed (Sensor) / Probed (Labs) / Detected , analyzed and consumed.

Event:

  • An “Event” is a notable thing that happens that could be either internal or external to scoped system. Scoped System is field of interest could be Organization or any other entity.
  • Event term is generally used to indicate “Occurance” and “Specification” of a notable thing. Specification of what of Event including “Event Header” and “Event Body” while in Occurance captures when of event.
  • Specification of Event needs to be as complete as possible for downstream applications to analyze and act on event.

Event Header: //More Generic in Nature. For all events
{
    Event ID: <Unique Identification Number>  ,
    Event Type: <Type of Event>
    Event Name: <Name of Event>
    Event Timestamp: <When was Event generated>,
    Event Origin: <Event generated by>
}

Event Body:
{
    Other Event Details:
    {
        //Specific to Scope of work.
        //Standardization across Event Generators / Consumers necessary
        Event Code:
        Event Description:
       
    }
    Event Deviation Details:
    {
        Current Reading:
        Threshold Reading:
        Min Reading:
        Max Reading:
    }
}

 Event Generators: Events are generated by source. Source is a generic abstraction to include anything from Software Application, Service, Sensors, Transmitters, Business Process. Every events may not be necessary in all cases, only interested events (like deviations from threshold) may be necessary for downstream applications, provided thresholds or deviation boundaries are well defined. Each event is evaluated and from a universal set of all events, subset of notable events are filtered to be further processed by downstream applications. As indicated, evaluation and filteration of events is based on context and type of work.

Event Channel: Messaging backbone to transports events for processing by downstream entities. Event channel may need to persist state and ensure events are durable and not lost during transit.

Event Processing: Upon receiving events, events are evaluated against processing rules (analyze phase) and actions are initiated as prescribed (act phase). Evaluation of events and actions are defined as required at event processing layer and is completely indepdent of needs of event generators. For Event processor, how to evaluate an event and what action to take is primary concern rather than who / what raised event. Similarly, Event Generators are concerned only with raising an event and event processing is a black box to them.

This decoupling is achieved best only when event generators, provide all necessary data points related to events so that event processors  are not stuck due to lack of data.

Relationship between Event Generators and Event Processors:

Event generators and Event consumers are very loosely coupled and only intermidate channel is connecting point between them.

Due to loose coupling

  • Event generators or Event Processors can be scaled out independent of each other.
  • A lag could be introduced between time event was generated and when it was processed.

Event processing patterns are of three types.

  • Simple Event Processing
  • Stream Event Processing
  • Complex Event Processing

Frankly speaking, I have not yet got grasp of Stream Event Processing in given examples, still trying to understand in my own terms what are use cases for each and explain in more detail.

Once I get my head around these three patterns of Event Processing, will put out my thoughts and ideas..

Till then..

Abhyast..