Showing posts with label Ben-David. Show all posts
Showing posts with label Ben-David. Show all posts

Tuesday, March 12, 2013

Final Blog Post



I really enjoyed this class. It was very interesting and brought up a lot of very interesting points. It was great seeing different perspectives regarding the future of the construction industry and listen to guest speaker that we would otherwise would not have had to chance to hear. This class has a lot of implications to my specific field (HVAC) in my opinion, especially in terms of building automation and BIM.
I think this course is a bit too sporadic for a three hour night class. We jumped between topics quite often and it was hard to stay focused. Maybe splitting this class up to twice a week would make it easier to concentrate. Also, some of the exercises, especially the Google Doc ones, got very hectic most of the times. I did enjoy having the class split out to different groups for most of the exercises, though. It was very beneficial to collaborate and hear other people’s opinions.
I do feel like I learned a lot in this course and I think I will definitely keep an eye out for innovations similar to the ones discussed in class. It is indeed a fast industry and with plenty of potential to exhibit “science fiction-like” characteristics very soon.
And by the way, I did really like you ties, especially the one with the Philadelphia map on it.

Tuesday, February 19, 2013

Temperature Sensors - Thermocouple


As the other groups mentioned, resistive temperature detectors (RTD), simple mercury thermometers, and more technologically advanced infrared sensors are all used to sense temperature. I would like to discuss a different type of temperature measurement – thermocouples. As Elda mentioned, thermocouples tend to be less accurate than RTDs, but they are still widely used in industry. They are simple and easy to understand. They have some advantages too which include a wide temperature range, robustness, rapid responsiveness, and lack of self heating.
Like most scientific inventions, the thermocouple was invented by accident. An Estonian physician accidentally discovered the ability to sense temperature by the effect of joining two different metals together. When two different metal wires are joined together and a temperature difference exists along them, they generate voltage, which is indicative of the temperature difference. Figure 1 presents a simple thermocouple diagram: the junction where the metals meet is called the measurement junction, or the hot junction. That point should be exposed to the temperature we would like to measure. The wires should then be placed in what’s referred to as the reference junction, or the cold junction. At that point the wires are generally inserted in a bath of ice water to maintain a constant 0 degrees Celsius. Thermocouples measure the relative temperature between the two junctions, and therefore the reference junction must be known, and is usually kept at 0 degree Celsius.

Figure 1: Thermocouple Diagram

The metals used are indicative of the sensitivity, temperature range, and voltage range measured by the thermocouple. Table 1 has this information about the common types of thermocouple. The types also indicate the error in measurements. As mentioned before, the error in measurement can be significant when using thermocouples. Figure 2 shows the possible error for four different thermocouples for the temperature range of 0 to 400 degree Celsius.

Table 1: Types of Thermocouples

Figure 2: Error in Thermocouple Measurements

What is actually measured when using a thermocouple is the voltage created by the difference in temperature. In order to interpret this date, one needs to know how to convert the voltage data to meaningful temperature data, which is, again, dependent on the type of thermocouple. The seedback coefficient is the voltage change per degree Celsius in μV per degree Celsius, and it is represented in Table 2 for the different thermocouple types at 25 degree Celsius. The seedback coefficient is not constant, though, which makes the fitted graphs used to interpret the temperature nonlinear. Software needs to collect the voltage data and have a function imbedded within it used to convert these measurements to useful temperature data.

Table 2: Seedback Coefficient at 25 Degree Celsius


References:
http://cds.linear.com/docs/Application%20Note/an28f.pdf
http://www.analog.com/library/analogDialogue/archives/44-10/thermocouple.pdf

Monday, February 11, 2013

SQL - overview


Just like Elda and john said, SQL is a programming language used to sort through relational databases. It is commonly regarded as “the standard computer database language”[1]. It is used in personal computers, cell phones, entertainment systems, and many other devices. What is very useful about it is that it is very standardized and thus able to communicate with just about any computer database. SQL is used to organize and retrieve information stored in computer databases. SQL logic is pretty intuitive, and is represented by the figure below:


When information from the database needs to be retrieved, SQL makes a request to the database management system (DBMS), which returns the requested information.  SQL is not the DBMS itself, though; it is simply a language used to communicate with it. In practice, SQL is much more involved than that. Its functions include data definition, data retrieval, data manipulation, access control, data sharing, and data integrity.
I would like to elaborate on John Scanlon’s comparison of SQL to other computer language: SQL can be used for databases only. It has only about 40 statements to control and manage the database and it is not a complete language like C++ or Java. This is why it can be embedded in other language but the opposite scenario is impossible.
Because it is short, it is very easy to learn and use and has a very steep learning curve. As John mentioned, it is rather primitive, which makes for a great advantage for amateur users who need to manage databases.

Source:
[1] Weiberg, Groff, Oppel, Davenport, SQL: The complete Reference, 2010, 3rd Ed. 

Monday, February 4, 2013

Tem Project


As an HVAC major, I wanted to choose a project that focuses on this aspect of intelligent buildings. Reading about the Nest thermostat in the building of the term intrigued me to research the capabilities of thermostats. It might seem like a primitive control system but it is the first integration of an “intelligent” system into a building.
After my project partner, David Morrison, and I spoke and brainstormed with my friend from Drexel Smart House, Michael Magee, we finalized the scope of the project as the exploration of the capabilities of integrated thermostats. For this project, we will use an Arduino microprocessor to collect temperature and humidity data from different spaces. Sensors will be placed in each of the four corners of the rooms we will use for this study and temperature and humidity differences will be measured. The data will also be compared in the static thermostat controlling each of the spaces measured. This data will be analyzed to draw conclusions about the effectiveness of the thermostat. Location of thermostat, location of diffuser, size of space, and type of air conditioning system in the space will be taken into account.
After the data will be analyzed thoroughly, we will draw conclusions regarding the implications of the study in relation to intelligent buildings. Some implications include actually including multiple thermostats in each space to create an integral system, providing automated diffusers that spread air more evenly, adding automated fans to mix the air better thermally, etc. The project will draw conclusions to help provide a more even thermal comfort throughout spaces and give suggestions as to how to integrate it into intelligent buildings.

Friday, February 1, 2013

Project: Physical Temperature Measurements

I am working with Tom Ben-David on creating a network on sensors in a room that will hopefully provide a better reading of the temperature in the room, and provide for a greater analysis of how a room acts. This type of strategy has not been widely implemented as there is not too much data on this subject. However, this has not been that practical of a solution for that long. A research paper by Lin details life in 2002, where one sensor per room was not that common, and they were exploring the use of a temperature sensor in each room as an alternative to one temperature sensor per zone. This is still how most homes operate, but as sensor prices drop, can we can more efficient use out of our HVAC systems. Can we also provide better comfort to ALL of the occupants, not just the occupants who live in the spaces with temperature sensors in them. If by adding more sensors to a room, can we then even adjust an HVAC system to make sure all occupants in one room are happy. Think of the many times you sat right under a vent and were too cold, while your companions were too hot just a couple feet away. With more sensors, hopefully an HVAC system will know how to respond to such an event happening.

Our idea is to create the physical sensors will be Arduino hardware. The Arduino hardware will report a humidity and temperature back to a central database where this information will be able to be complied over a time range. Knowing where these sensors are placed in the room, and what is near each sensor (ie: a window or diffuser that would account for a change in temperature). Hopefully with knowing the location of the 4 sensors, and the different types of data they provide, we will be able to make a general consensus as to wether a multi-temperature-sensor room is a viable option and would provide for a more intelligent building.

I found Jeanine's topic very interesting, and applicable to the same type of model we are looking to design. In her post, she talks about how they are going to be selecting sensors to improve the students comfort in the library. We are also interesting in achieving a similar goal, however not with such a specifica building. I am excited to see how well their findings coincide with the findings in our report about ventilation rates.

Monday, January 21, 2013

Interoperability


Interoperability is a crucial aspect of BIM, especially due to the complexity of buildings nowadays and the idea that building function as one cohesive machine, rather than a collection of systems. In practice, there are many designers working on each building: an architect, a structural engineer, an electrical engineer, a mechanical engineer etc. These people and their systems need to be able to communicate with each other not only on site, but also during the design process. Therefore it is necessary for computer generated building systems created with different programs to be compatible and read by other interfaces.

Elda did a great job briefing about the technical aspect of interoperability in her post. Rather than repeating what she had already said, I would like to touch more of the impact interoperability has on BIM. In order to make buildings more efficient, many building systems are cross-disciplinary. A contractor might want to save cost by providing cheap envelope, but overall the building can turn out more expensive with a larger HVAC system and larger energy consumption. By providing interoperable design methods, the designers can see how their systems will work together in real life. As the BIM Handbook states, is it possible to conduct ANSI calculations using IFC with proper labeling. This can make design more efficient and help in providing ideal solutions in terms of energy management, cost reduction, and systems’ effect on one another. As we move forward to an era of more intelligent buildings, BIM interoperability is necessary to ensure compatibility and communications between systems and avoid errors due to miscommunication and complexity.

It is true that there are still problems with IFC and other formats, such as complex curve interpretation and other problems in translation, but I believe these problems will be solved in the near future. Autodesk software seem to be the most common type of software used today in the industry, which is a step towards standardization; but as long as other programs are used there has to be a way in which files can be translated from one program to another with as little errors as possible for an efficient interoperable BIM design.