EttiWiki - User contributions [en]

Weather monitor

2013-04-07T11:16:55Z

Christian: /* Querying the Database */ removed minor detail

The basic idea of the '''weathermon''' project is to obtain, record and monitor the weather at my home. All weather data sent from wireless sensors is to be stored in a database, from which different graphs are generated that can be monitored on a PC, over the Internet and on a smartphone.

= System Overview =
# Weather data is measured by sensors outside and inside the house. These sensors transmit all measured values via radio link.
# Transmitted values are received by a weather station and displayed for convenience.
# Transmitted values are also received by a small USB device which sends them to the PC connected.
# The PC reads received measurements and stores them in a database.
# From this database a web server serves all measurements to clients for display.

== Sensors ==
The sensors and the weather station come as a set from [http://www.elv.de ELV]:
* Outdoor sensor: [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html ELV Funk-Kombi-Wettersensor KS300-2]
* Indoor sensor: [http://www.elv.de/funk-temperatur-luftfeuchteaussensensor-s-300-th-fuer-z-b-elv-ws-200-300-elv-ws-300-pc-usb-wde1-und-ipwe-1.html Funk-Temperatur-/Luftfeuchteaußensensor S300 TH]
* Weather station: WS300

== Receiver ==
[[File:USB-WDE1.jpg|thumb|200px|USB-WDE1 Receiver from ELV]]
For receiving the 868,35 MHz signals the following device from ELV is used:
* [http://www.elv.de/usb-wetterdaten-empfaenger-usb-wde1-komplettbausatz.html USB-Wetterdaten-Empfänger USB-WDE1]

== Database ==
Data from weather sensors is stored in a Round Robin Database (RRDB) at different resolutions. This means, while high-resolution data is stored for the last 90 days, it also gets accumulated into daily data which is then kept for 10 years.

The database used is called [http://oss.oetiker.ch/rrdtool/ RRDtool] by Tobi Oetiker. It handles storing data at fixed intervals while updates come randomly, accumulating data and creating graphs. The latter is not used, instead a browser-based charting API is used to create dynamic charts.

== Server ==
The server's job is to run the database and web server, so that clients can connect with a browser and retrieve and display all weather data.
* The server is a standard Linux PC, but not a common desktop machine. Instead, a [http://www.raspberrypi.org/ Raspberry PI] is used.
* The server runs an [http://tomcat.apache.org/ Apache Tomcat] web server.

= Interfaces =
== Protocol between Receiver and Server ==
The USB-WDE1 contains a [https://www.silabs.com/Support%20Documents/TechnicalDocs/cp2102.pdf CP210x] serial-to-USB chip from Silicon Labs. Fortunately, Linux already contains a driver for that chip, so all that is needed is to plug the USB-WDE1 into the USB port. One can verify the driver is loaded correctly with ''lsmod'':
<pre>pi@raspberrypi ~ $ lsmod
Module Size Used by
cp210x 11783 0
usbserial 34545 1 cp210x
</pre>
From then on the USB-WDE1 will transmit a serial ASCII string whenever a new measurement has been received. This can be verified with the following commands:
<pre>stty -F /dev/ttyUSB0 9600
cat /dev/ttyUSB0</pre>

The ASCII string sent by the USB-WDE1 can look like this:
<pre>$1;1;;;;;;-3,8;;;;;;;;94;;;;-4,2;98;0,0;36;1;0</pre>
Which means:
* Temperature sensor address 5: -3.8°C
* Humidity sensor address 5: 94%
* Outside temperature: -4.2°C
* Outside humidity: 98%
* Wind speed: 0.0 km/h
* Rain intensity: 36 rocker switch impulses (equals 8.8mm/m²)
* Immediate rain detected

== Protocol between Server and Clients ==
* REST with JSON

= Software Components =
== Filling Database ==
Serial data coming from the receiver must be interpreted and then stored into the database.

I wrote a short C program which basically does the following:
* Open serial port and set communication settings.
* Wait for and read a line from the USB-WDE1.
* Split the semi-colon-separated values into separate strings and replace the decimal separator (, with .).
* Call the <code>rrd_update_r()</code> function to enter these values into the RRDB.

The complete C code can be found here: '''[[File:weathermon.c]]'''.

To compile it I use the following short <code>Makefile</code> (note that it makes heavy use of predefined rules). Using an extra <code>Makefile</code> was only necessary for including the <code>librrd.so</code> library.

<pre># predefined rule that compiles .c files into .o files: $(CC) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)
# predefined rule that links binary files from .o files: $(CC) -c $(CPPFLAGS) $(CFLAGS)

LDLIBS = /usr/lib/librrd.so

weathermon : weathermon.c</pre>

== Querying the Database ==
For fetching data from the database I decided to use the '''java-rrd''' library. In contrast to other Java implementations for interfacing an ''rrdtool'' database, this has the following advantages:
* It uses ''rrdtool'' itself, so it is 100% compatible with the database file format. Other implementations re-implement ''rrdtool'' but use a slightly different file format. As I use the original ''rrdtool'' to enter data into the database, the Java components must be compatible with it.
* It doesn't use '''JNI''' framework, which would cause the software to be not platform-independent any more. As I develop under Windows but run the server with Linux, this was no option either.

The '''java-rrd''' library is written by Peter Stamfest. The original announcement can be found here:
* http://www.mail-archive.com/rrd-developers@lists.oetiker.ch/msg03866.html
Very helpful is the brief introduction by Manuel Aldana:
* http://www.aldana-online.de/2011/07/03/accessing-rrdtool-files-data-with-java/

This library uses rrdtool's ''pipe mode'': It calls <code>"rrdtool -"</code> which causes rrdtool to wait for commands from stdin and output its responses to stdout. This mode is also very fast, because the rrdtool instance only needs to be started once and from then on serves all requests.

The tricky part is to configure the place of the database file differently depending on which machine it runs on (development machine or server). I decided to use Tomcat's ''Context Parameters''. I configured the context in <code>META-INF/context.xml</code> which resides in the deployable WAR file and is copied to a machine-specific directory upon first deployment. There I can modify it to fit the corresponding machine configuration. To access this context parameter in the source code I have to do the following:
<pre>@javax.ws.rs.core.Context
public void setServletContext(ServletContext context) throws IOException {
servletContext = context;
String rrdbdir = servletContext.getInitParameter("rrdbdir");</pre>

== REST Server ==
The web server implements a [http://en.wikipedia.org/wiki/Representational_state_transfer REST] service which clients use to query data from the database. It is implemented in Java and uses the [http://jersey.java.net/ Jersey] framework.

A very good introduction to implementing REST services with Jersey can be found here:
* http://www.vogella.com/articles/REST/article.html

Basically, you only need to do the following:
* setup the deployment descriptor (<code>WEB-INF/web.xml</code>)
* implement the service class with using the correct annotations

The '''web.xml''' needs to contain the following information:
<pre><?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
<display-name>weatherserv</display-name>
<servlet>
<servlet-name>Jersey REST Service</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>at.ettisoft.weatherserv</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>Jersey REST Service</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
</web-app></pre>

* The servlet container is implemented by Jersey, therefore the node <code>web-app/servlet/servlet-class</code> must point to ''com.sun.jersey.spi.container.servlet.ServletContainer''.
* This container expects the parameter <code>com.sun.jersey.config.property.packages</code> to point to the service classes at ''at.ettisoft.weatherserv''

Weather monitor

2013-04-01T13:15:33Z

Christian: /* Querying the Database */ added detail where to set copyXML

The basic idea of the '''weathermon''' project is to obtain, record and monitor the weather at my home. All weather data sent from wireless sensors is to be stored in a database, from which different graphs are generated that can be monitored on a PC, over the Internet and on a smartphone.

= System Overview =
# Weather data is measured by sensors outside and inside the house. These sensors transmit all measured values via radio link.
# Transmitted values are received by a weather station and displayed for convenience.
# Transmitted values are also received by a small USB device which sends them to the PC connected.
# The PC reads received measurements and stores them in a database.
# From this database a web server serves all measurements to clients for display.

== Sensors ==
The sensors and the weather station come as a set from [http://www.elv.de ELV]:
* Outdoor sensor: [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html ELV Funk-Kombi-Wettersensor KS300-2]
* Indoor sensor: [http://www.elv.de/funk-temperatur-luftfeuchteaussensensor-s-300-th-fuer-z-b-elv-ws-200-300-elv-ws-300-pc-usb-wde1-und-ipwe-1.html Funk-Temperatur-/Luftfeuchteaußensensor S300 TH]
* Weather station: WS300

== Receiver ==
[[File:USB-WDE1.jpg|thumb|200px|USB-WDE1 Receiver from ELV]]
For receiving the 868,35 MHz signals the following device from ELV is used:
* [http://www.elv.de/usb-wetterdaten-empfaenger-usb-wde1-komplettbausatz.html USB-Wetterdaten-Empfänger USB-WDE1]

== Database ==
Data from weather sensors is stored in a Round Robin Database (RRDB) at different resolutions. This means, while high-resolution data is stored for the last 90 days, it also gets accumulated into daily data which is then kept for 10 years.

The database used is called [http://oss.oetiker.ch/rrdtool/ RRDtool] by Tobi Oetiker. It handles storing data at fixed intervals while updates come randomly, accumulating data and creating graphs. The latter is not used, instead a browser-based charting API is used to create dynamic charts.

== Server ==
The server's job is to run the database and web server, so that clients can connect with a browser and retrieve and display all weather data.
* The server is a standard Linux PC, but not a common desktop machine. Instead, a [http://www.raspberrypi.org/ Raspberry PI] is used.
* The server runs an [http://tomcat.apache.org/ Apache Tomcat] web server.

= Interfaces =
== Protocol between Receiver and Server ==
The USB-WDE1 contains a [https://www.silabs.com/Support%20Documents/TechnicalDocs/cp2102.pdf CP210x] serial-to-USB chip from Silicon Labs. Fortunately, Linux already contains a driver for that chip, so all that is needed is to plug the USB-WDE1 into the USB port. One can verify the driver is loaded correctly with ''lsmod'':
<pre>pi@raspberrypi ~ $ lsmod
Module Size Used by
cp210x 11783 0
usbserial 34545 1 cp210x
</pre>
From then on the USB-WDE1 will transmit a serial ASCII string whenever a new measurement has been received. This can be verified with the following commands:
<pre>stty -F /dev/ttyUSB0 9600
cat /dev/ttyUSB0</pre>

The ASCII string sent by the USB-WDE1 can look like this:
<pre>$1;1;;;;;;-3,8;;;;;;;;94;;;;-4,2;98;0,0;36;1;0</pre>
Which means:
* Temperature sensor address 5: -3.8°C
* Humidity sensor address 5: 94%
* Outside temperature: -4.2°C
* Outside humidity: 98%
* Wind speed: 0.0 km/h
* Rain intensity: 36 rocker switch impulses (equals 8.8mm/m²)
* Immediate rain detected

== Protocol between Server and Clients ==
* REST with JSON

= Software Components =
== Filling Database ==
Serial data coming from the receiver must be interpreted and then stored into the database.

I wrote a short C program which basically does the following:
* Open serial port and set communication settings.
* Wait for and read a line from the USB-WDE1.
* Split the semi-colon-separated values into separate strings and replace the decimal separator (, with .).
* Call the <code>rrd_update_r()</code> function to enter these values into the RRDB.

The complete C code can be found here: '''[[File:weathermon.c]]'''.

To compile it I use the following short <code>Makefile</code> (note that it makes heavy use of predefined rules). Using an extra <code>Makefile</code> was only necessary for including the <code>librrd.so</code> library.

<pre># predefined rule that compiles .c files into .o files: $(CC) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)
# predefined rule that links binary files from .o files: $(CC) -c $(CPPFLAGS) $(CFLAGS)

LDLIBS = /usr/lib/librrd.so

weathermon : weathermon.c</pre>

== Querying the Database ==
For fetching data from the database I decided to use the '''java-rrd''' library. In contrast to other Java implementations for interfacing an ''rrdtool'' database, this has the following advantages:
* It uses ''rrdtool'' itself, so it is 100% compatible with the database file format. Other implementations re-implement ''rrdtool'' but use a slightly different file format. As I use the original ''rrdtool'' to enter data into the database, the Java components must be compatible with it.
* It doesn't use '''JNI''' framework, which would cause the software to be not platform-independent any more. As I develop under Windows but run the server with Linux, this was no option either.

The '''java-rrd''' library is written by Peter Stamfest. The original announcement can be found here:
* http://www.mail-archive.com/rrd-developers@lists.oetiker.ch/msg03866.html
Very helpful is the brief introduction by Manuel Aldana:
* http://www.aldana-online.de/2011/07/03/accessing-rrdtool-files-data-with-java/

This library uses rrdtool's ''pipe mode'': It calls <code>"rrdtool -"</code> which causes rrdtool to wait for commands from stdin and output its responses to stdout. This mode is also very fast, because the rrdtool instance only needs to be started once and from then on serves all requests.

The tricky part is to configure the place of the database file differently depending on which machine it runs on (development machine or server). I decided to use Tomcat's ''Context Parameters''. I configured the context in <code>META-INF/context.xml</code> which resides in the deployable WAR file and is copied to a machine-specific directory upon first deployment (<code>Server/Service/Engine/Host@copyXML</code> must be <code>true</code> in <code>/etc/tomcat7/server.xml</code>). There I can modify it to fit the corresponding machine configuration. To access this context parameter in the source code I have to do the following:
<pre>@javax.ws.rs.core.Context
public void setServletContext(ServletContext context) throws IOException {
servletContext = context;
String rrdbdir = servletContext.getInitParameter("rrdbdir");</pre>

== REST Server ==
The web server implements a [http://en.wikipedia.org/wiki/Representational_state_transfer REST] service which clients use to query data from the database. It is implemented in Java and uses the [http://jersey.java.net/ Jersey] framework.

A very good introduction to implementing REST services with Jersey can be found here:
* http://www.vogella.com/articles/REST/article.html

Basically, you only need to do the following:
* setup the deployment descriptor (<code>WEB-INF/web.xml</code>)
* implement the service class with using the correct annotations

The '''web.xml''' needs to contain the following information:
<pre><?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
<display-name>weatherserv</display-name>
<servlet>
<servlet-name>Jersey REST Service</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>at.ettisoft.weatherserv</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>Jersey REST Service</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
</web-app></pre>

* The servlet container is implemented by Jersey, therefore the node <code>web-app/servlet/servlet-class</code> must point to ''com.sun.jersey.spi.container.servlet.ServletContainer''.
* This container expects the parameter <code>com.sun.jersey.config.property.packages</code> to point to the service classes at ''at.ettisoft.weatherserv''

File:Weathermon.c

2013-03-28T20:20:53Z

Christian: first version of this file

first version of this file

File:USB-WDE1.jpg

2013-03-28T20:15:48Z

Christian: picture of weather data receiver USB-WDE1

picture of weather data receiver USB-WDE1

Weather monitor

2013-03-27T20:47:42Z

Christian: /* Receiver */ link to picture

Weather monitor

2013-03-27T20:24:39Z

Christian: /* Filling Database */ link to source file

The basic idea of the '''weathermon''' project is to obtain, record and monitor the weather at my home. All weather data sent from wireless sensors is to be stored in a database, from which different graphs are generated that can be monitored on a PC, over the Internet and on a smartphone.

= System Overview =
# Weather data is measured by sensors outside and inside the house. These sensors transmit all measured values via radio link.
# Transmitted values are received by a weather station and displayed for convenience.
# Transmitted values are also received by a small USB device which sends them to the PC connected.
# The PC reads received measurements and stores them in a database.
# From this database a web server serves all measurements to clients for display.

== Sensors ==
The sensors and the weather station come as a set from [http://www.elv.de ELV]:
* Outdoor sensor: [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html ELV Funk-Kombi-Wettersensor KS300-2]
* Indoor sensor: [http://www.elv.de/funk-temperatur-luftfeuchteaussensensor-s-300-th-fuer-z-b-elv-ws-200-300-elv-ws-300-pc-usb-wde1-und-ipwe-1.html Funk-Temperatur-/Luftfeuchteaußensensor S300 TH]
* Weather station: WS300

== Receiver ==
For receiving the 868,35 MHz signals the following device from ELV is used:
* [http://www.elv.de/usb-wetterdaten-empfaenger-usb-wde1-komplettbausatz.html USB-Wetterdaten-Empfänger USB-WDE1]

== Database ==
Data from weather sensors is stored in a Round Robin Database (RRDB) at different resolutions. This means, while high-resolution data is stored for the last 90 days, it also gets accumulated into daily data which is then kept for 10 years.

The database used is called [http://oss.oetiker.ch/rrdtool/ RRDtool] by Tobi Oetiker. It handles storing data at fixed intervals while updates come randomly, accumulating data and creating graphs. The latter is not used, instead a browser-based charting API is used to create dynamic charts.

== Server ==
The server's job is to run the database and web server, so that clients can connect with a browser and retrieve and display all weather data.
* The server is a standard Linux PC, but not a common desktop machine. Instead, a [http://www.raspberrypi.org/ Raspberry PI] is used.
* The server runs an [http://tomcat.apache.org/ Apache Tomcat] web server.

= Interfaces =
== Protocol between Receiver and Server ==
The USB-WDE1 contains a [https://www.silabs.com/Support%20Documents/TechnicalDocs/cp2102.pdf CP210x] serial-to-USB chip from Silicon Labs. Fortunately, Linux already contains a driver for that chip, so all that is needed is to plug the USB-WDE1 into the USB port. One can verify the driver is loaded correctly with ''lsmod'':
<pre>pi@raspberrypi ~ $ lsmod
Module Size Used by
cp210x 11783 0
usbserial 34545 1 cp210x
</pre>
From then on the USB-WDE1 will transmit a serial ASCII string whenever a new measurement has been received. This can be verified with the following commands:
<pre>stty -F /dev/ttyUSB0 9600
cat /dev/ttyUSB0</pre>

The ASCII string sent by the USB-WDE1 can look like this:
<pre>$1;1;;;;;;-3,8;;;;;;;;94;;;;-4,2;98;0,0;36;1;0</pre>
Which means:
* Temperature sensor address 5: -3.8°C
* Humidity sensor address 5: 94%
* Outside temperature: -4.2°C
* Outside humidity: 98%
* Wind speed: 0.0 km/h
* Rain intensity: 36 rocker switch impulses (equals 8.8mm/m²)
* Immediate rain detected

== Protocol between Server and Clients ==
* REST with JSON

= Software Components =
== Filling Database ==
Serial data coming from the receiver must be interpreted and then stored into the database.

I wrote a short C program which basically does the following:
* Open serial port and set communication settings.
* Wait for and read a line from the USB-WDE1.
* Split the semi-colon-separated values into separate strings and replace the decimal separator (, with .).
* Call the <code>rrd_update_r()</code> function to enter these values into the RRDB.

The complete C code can be found here: '''[[File:weathermon.c]]'''.

To compile it I use the following short <code>Makefile</code> (note that it makes heavy use of predefined rules). Using an extra <code>Makefile</code> was only necessary for including the <code>librrd.so</code> library.

<pre># predefined rule that compiles .c files into .o files: $(CC) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)
# predefined rule that links binary files from .o files: $(CC) -c $(CPPFLAGS) $(CFLAGS)

LDLIBS = /usr/lib/librrd.so

weathermon : weathermon.c</pre>

== Querying the Database ==
For fetching data from the database I decided to use the '''java-rrd''' library. In contrast to other Java implementations for interfacing an ''rrdtool'' database, this has the following advantages:
* It uses ''rrdtool'' itself, so it is 100% compatible with the database file format. Other implementations re-implement ''rrdtool'' but use a slightly different file format. As I use the original ''rrdtool'' to enter data into the database, the Java components must be compatible with it.
* It doesn't use '''JNI''' framework, which would cause the software to be not platform-independent any more. As I develop under Windows but run the server with Linux, this was no option either.

The '''java-rrd''' library is written by Peter Stamfest. The original announcement can be found here:
* http://www.mail-archive.com/rrd-developers@lists.oetiker.ch/msg03866.html
Very helpful is the brief introduction by Manuel Aldana:
* http://www.aldana-online.de/2011/07/03/accessing-rrdtool-files-data-with-java/

This library uses rrdtool's ''pipe mode'': It calls <code>"rrdtool -"</code> which causes rrdtool to wait for commands from stdin and output its responses to stdout. This mode is also very fast, because the rrdtool instance only needs to be started once and from then on serves all requests.

The tricky part is to configure the place of the database file differently depending on which machine it runs on (development machine or server). I decided to use Tomcat's ''Context Parameters''. I configured the context in <code>META-INF/context.xml</code> which resides in the deployable WAR file and is copied to a machine-specific directory upon first deployment. There I can modify it to fit the corresponding machine configuration. To access this context parameter in the source code I have to do the following:
<pre>@javax.ws.rs.core.Context
public void setServletContext(ServletContext context) throws IOException {
servletContext = context;
String rrdbdir = servletContext.getInitParameter("rrdbdir");</pre>

== REST Server ==
The web server implements a [http://en.wikipedia.org/wiki/Representational_state_transfer REST] service which clients use to query data from the database. It is implemented in Java and uses the [http://jersey.java.net/ Jersey] framework.

A very good introduction to implementing REST services with Jersey can be found here:
* http://www.vogella.com/articles/REST/article.html

Basically, you only need to do the following:
* setup the deployment descriptor (<code>WEB-INF/web.xml</code>)
* implement the service class with using the correct annotations

The '''web.xml''' needs to contain the following information:
<pre><?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
<display-name>weatherserv</display-name>
<servlet>
<servlet-name>Jersey REST Service</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>at.ettisoft.weatherserv</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>Jersey REST Service</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
</web-app></pre>

* The servlet container is implemented by Jersey, therefore the node <code>web-app/servlet/servlet-class</code> must point to ''com.sun.jersey.spi.container.servlet.ServletContainer''.
* This container expects the parameter <code>com.sun.jersey.config.property.packages</code> to point to the service classes at ''at.ettisoft.weatherserv''

Weather monitor

2013-03-27T20:13:11Z

Christian: /* Filling Database */ added predefined make rules

The basic idea of the '''weathermon''' project is to obtain, record and monitor the weather at my home. All weather data sent from wireless sensors is to be stored in a database, from which different graphs are generated that can be monitored on a PC, over the Internet and on a smartphone.

= System Overview =
# Weather data is measured by sensors outside and inside the house. These sensors transmit all measured values via radio link.
# Transmitted values are received by a weather station and displayed for convenience.
# Transmitted values are also received by a small USB device which sends them to the PC connected.
# The PC reads received measurements and stores them in a database.
# From this database a web server serves all measurements to clients for display.

== Sensors ==
The sensors and the weather station come as a set from [http://www.elv.de ELV]:
* Outdoor sensor: [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html ELV Funk-Kombi-Wettersensor KS300-2]
* Indoor sensor: [http://www.elv.de/funk-temperatur-luftfeuchteaussensensor-s-300-th-fuer-z-b-elv-ws-200-300-elv-ws-300-pc-usb-wde1-und-ipwe-1.html Funk-Temperatur-/Luftfeuchteaußensensor S300 TH]
* Weather station: WS300

== Receiver ==
For receiving the 868,35 MHz signals the following device from ELV is used:
* [http://www.elv.de/usb-wetterdaten-empfaenger-usb-wde1-komplettbausatz.html USB-Wetterdaten-Empfänger USB-WDE1]

== Database ==
Data from weather sensors is stored in a Round Robin Database (RRDB) at different resolutions. This means, while high-resolution data is stored for the last 90 days, it also gets accumulated into daily data which is then kept for 10 years.

The database used is called [http://oss.oetiker.ch/rrdtool/ RRDtool] by Tobi Oetiker. It handles storing data at fixed intervals while updates come randomly, accumulating data and creating graphs. The latter is not used, instead a browser-based charting API is used to create dynamic charts.

== Server ==
The server's job is to run the database and web server, so that clients can connect with a browser and retrieve and display all weather data.
* The server is a standard Linux PC, but not a common desktop machine. Instead, a [http://www.raspberrypi.org/ Raspberry PI] is used.
* The server runs an [http://tomcat.apache.org/ Apache Tomcat] web server.

= Interfaces =
== Protocol between Receiver and Server ==
The USB-WDE1 contains a [https://www.silabs.com/Support%20Documents/TechnicalDocs/cp2102.pdf CP210x] serial-to-USB chip from Silicon Labs. Fortunately, Linux already contains a driver for that chip, so all that is needed is to plug the USB-WDE1 into the USB port. One can verify the driver is loaded correctly with ''lsmod'':
<pre>pi@raspberrypi ~ $ lsmod
Module Size Used by
cp210x 11783 0
usbserial 34545 1 cp210x
</pre>
From then on the USB-WDE1 will transmit a serial ASCII string whenever a new measurement has been received. This can be verified with the following commands:
<pre>stty -F /dev/ttyUSB0 9600
cat /dev/ttyUSB0</pre>

The ASCII string sent by the USB-WDE1 can look like this:
<pre>$1;1;;;;;;-3,8;;;;;;;;94;;;;-4,2;98;0,0;36;1;0</pre>
Which means:
* Temperature sensor address 5: -3.8°C
* Humidity sensor address 5: 94%
* Outside temperature: -4.2°C
* Outside humidity: 98%
* Wind speed: 0.0 km/h
* Rain intensity: 36 rocker switch impulses (equals 8.8mm/m²)
* Immediate rain detected

== Protocol between Server and Clients ==
* REST with JSON

= Software Components =
== Filling Database ==
Serial data coming from the receiver must be interpreted and then stored into the database.

I wrote a short C program which basically does the following:
* Open serial port and set communication settings.
* Wait for and read a line from the USB-WDE1.
* Split the semi-colon-separated values into separate strings and replace the decimal separator (, with .).
* Call the <code>rrd_update_r()</code> function to enter these values into the RRDB.

The complete C code can be found here ('''TODO''').

To compile it I use the following short <code>Makefile</code> (note that it makes heavy use of predefined rules). Using an extra <code>Makefile</code> was only necessary for including the <code>librrd.so</code> library.

<pre># predefined rule that compiles .c files into .o files: $(CC) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)
# predefined rule that links binary files from .o files: $(CC) -c $(CPPFLAGS) $(CFLAGS)

LDLIBS = /usr/lib/librrd.so

weathermon : weathermon.c</pre>

== Querying the Database ==
For fetching data from the database I decided to use the '''java-rrd''' library. In contrast to other Java implementations for interfacing an ''rrdtool'' database, this has the following advantages:
* It uses ''rrdtool'' itself, so it is 100% compatible with the database file format. Other implementations re-implement ''rrdtool'' but use a slightly different file format. As I use the original ''rrdtool'' to enter data into the database, the Java components must be compatible with it.
* It doesn't use '''JNI''' framework, which would cause the software to be not platform-independent any more. As I develop under Windows but run the server with Linux, this was no option either.

The '''java-rrd''' library is written by Peter Stamfest. The original announcement can be found here:
* http://www.mail-archive.com/rrd-developers@lists.oetiker.ch/msg03866.html
Very helpful is the brief introduction by Manuel Aldana:
* http://www.aldana-online.de/2011/07/03/accessing-rrdtool-files-data-with-java/

This library uses rrdtool's ''pipe mode'': It calls <code>"rrdtool -"</code> which causes rrdtool to wait for commands from stdin and output its responses to stdout. This mode is also very fast, because the rrdtool instance only needs to be started once and from then on serves all requests.

The tricky part is to configure the place of the database file differently depending on which machine it runs on (development machine or server). I decided to use Tomcat's ''Context Parameters''. I configured the context in <code>META-INF/context.xml</code> which resides in the deployable WAR file and is copied to a machine-specific directory upon first deployment. There I can modify it to fit the corresponding machine configuration. To access this context parameter in the source code I have to do the following:
<pre>@javax.ws.rs.core.Context
public void setServletContext(ServletContext context) throws IOException {
servletContext = context;
String rrdbdir = servletContext.getInitParameter("rrdbdir");</pre>

== REST Server ==
The web server implements a [http://en.wikipedia.org/wiki/Representational_state_transfer REST] service which clients use to query data from the database. It is implemented in Java and uses the [http://jersey.java.net/ Jersey] framework.

A very good introduction to implementing REST services with Jersey can be found here:
* http://www.vogella.com/articles/REST/article.html

Basically, you only need to do the following:
* setup the deployment descriptor (<code>WEB-INF/web.xml</code>)
* implement the service class with using the correct annotations

The '''web.xml''' needs to contain the following information:
<pre><?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
<display-name>weatherserv</display-name>
<servlet>
<servlet-name>Jersey REST Service</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>at.ettisoft.weatherserv</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>Jersey REST Service</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
</web-app></pre>

* The servlet container is implemented by Jersey, therefore the node <code>web-app/servlet/servlet-class</code> must point to ''com.sun.jersey.spi.container.servlet.ServletContainer''.
* This container expects the parameter <code>com.sun.jersey.config.property.packages</code> to point to the service classes at ''at.ettisoft.weatherserv''

Weather monitor

2013-03-27T19:59:13Z

Christian: /* Filling Database */ C program and Makefile

The basic idea of the '''weathermon''' project is to obtain, record and monitor the weather at my home. All weather data sent from wireless sensors is to be stored in a database, from which different graphs are generated that can be monitored on a PC, over the Internet and on a smartphone.

= System Overview =
# Weather data is measured by sensors outside and inside the house. These sensors transmit all measured values via radio link.
# Transmitted values are received by a weather station and displayed for convenience.
# Transmitted values are also received by a small USB device which sends them to the PC connected.
# The PC reads received measurements and stores them in a database.
# From this database a web server serves all measurements to clients for display.

== Sensors ==
The sensors and the weather station come as a set from [http://www.elv.de ELV]:
* Outdoor sensor: [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html ELV Funk-Kombi-Wettersensor KS300-2]
* Indoor sensor: [http://www.elv.de/funk-temperatur-luftfeuchteaussensensor-s-300-th-fuer-z-b-elv-ws-200-300-elv-ws-300-pc-usb-wde1-und-ipwe-1.html Funk-Temperatur-/Luftfeuchteaußensensor S300 TH]
* Weather station: WS300

== Receiver ==
For receiving the 868,35 MHz signals the following device from ELV is used:
* [http://www.elv.de/usb-wetterdaten-empfaenger-usb-wde1-komplettbausatz.html USB-Wetterdaten-Empfänger USB-WDE1]

== Database ==
Data from weather sensors is stored in a Round Robin Database (RRDB) at different resolutions. This means, while high-resolution data is stored for the last 90 days, it also gets accumulated into daily data which is then kept for 10 years.

The database used is called [http://oss.oetiker.ch/rrdtool/ RRDtool] by Tobi Oetiker. It handles storing data at fixed intervals while updates come randomly, accumulating data and creating graphs. The latter is not used, instead a browser-based charting API is used to create dynamic charts.

== Server ==
The server's job is to run the database and web server, so that clients can connect with a browser and retrieve and display all weather data.
* The server is a standard Linux PC, but not a common desktop machine. Instead, a [http://www.raspberrypi.org/ Raspberry PI] is used.
* The server runs an [http://tomcat.apache.org/ Apache Tomcat] web server.

= Interfaces =
== Protocol between Receiver and Server ==
The USB-WDE1 contains a [https://www.silabs.com/Support%20Documents/TechnicalDocs/cp2102.pdf CP210x] serial-to-USB chip from Silicon Labs. Fortunately, Linux already contains a driver for that chip, so all that is needed is to plug the USB-WDE1 into the USB port. One can verify the driver is loaded correctly with ''lsmod'':
<pre>pi@raspberrypi ~ $ lsmod
Module Size Used by
cp210x 11783 0
usbserial 34545 1 cp210x
</pre>
From then on the USB-WDE1 will transmit a serial ASCII string whenever a new measurement has been received. This can be verified with the following commands:
<pre>stty -F /dev/ttyUSB0 9600
cat /dev/ttyUSB0</pre>

The ASCII string sent by the USB-WDE1 can look like this:
<pre>$1;1;;;;;;-3,8;;;;;;;;94;;;;-4,2;98;0,0;36;1;0</pre>
Which means:
* Temperature sensor address 5: -3.8°C
* Humidity sensor address 5: 94%
* Outside temperature: -4.2°C
* Outside humidity: 98%
* Wind speed: 0.0 km/h
* Rain intensity: 36 rocker switch impulses (equals 8.8mm/m²)
* Immediate rain detected

== Protocol between Server and Clients ==
* REST with JSON

= Software Components =
== Filling Database ==
Serial data coming from the receiver must be interpreted and then stored into the database.

I wrote a short C program which basically does the following:
* Open serial port and set communication settings.
* Wait for and read a line from the USB-WDE1.
* Split the semi-colon-separated values into separate strings and replace the decimal separator (, with .).
* Call the <code>rrd_update_r()</code> function to enter these values into the RRDB.

The complete C code can be found here ('''TODO''').

To compile it I use the following short <code>Makefile</code> (note that it makes heavy use of predefined rules). Using an extra <code>Makefile</code> was only necessary for including the <code>librrd.so</code> library.

<pre>LDLIBS = /usr/lib/librrd.so

weathermon : weathermon.c</pre>

== Querying the Database ==
For fetching data from the database I decided to use the '''java-rrd''' library. In contrast to other Java implementations for interfacing an ''rrdtool'' database, this has the following advantages:
* It uses ''rrdtool'' itself, so it is 100% compatible with the database file format. Other implementations re-implement ''rrdtool'' but use a slightly different file format. As I use the original ''rrdtool'' to enter data into the database, the Java components must be compatible with it.
* It doesn't use '''JNI''' framework, which would cause the software to be not platform-independent any more. As I develop under Windows but run the server with Linux, this was no option either.

The '''java-rrd''' library is written by Peter Stamfest. The original announcement can be found here:
* http://www.mail-archive.com/rrd-developers@lists.oetiker.ch/msg03866.html
Very helpful is the brief introduction by Manuel Aldana:
* http://www.aldana-online.de/2011/07/03/accessing-rrdtool-files-data-with-java/

This library uses rrdtool's ''pipe mode'': It calls <code>"rrdtool -"</code> which causes rrdtool to wait for commands from stdin and output its responses to stdout. This mode is also very fast, because the rrdtool instance only needs to be started once and from then on serves all requests.

The tricky part is to configure the place of the database file differently depending on which machine it runs on (development machine or server). I decided to use Tomcat's ''Context Parameters''. I configured the context in <code>META-INF/context.xml</code> which resides in the deployable WAR file and is copied to a machine-specific directory upon first deployment. There I can modify it to fit the corresponding machine configuration. To access this context parameter in the source code I have to do the following:
<pre>@javax.ws.rs.core.Context
public void setServletContext(ServletContext context) throws IOException {
servletContext = context;
String rrdbdir = servletContext.getInitParameter("rrdbdir");</pre>

== REST Server ==
The web server implements a [http://en.wikipedia.org/wiki/Representational_state_transfer REST] service which clients use to query data from the database. It is implemented in Java and uses the [http://jersey.java.net/ Jersey] framework.

A very good introduction to implementing REST services with Jersey can be found here:
* http://www.vogella.com/articles/REST/article.html

Basically, you only need to do the following:
* setup the deployment descriptor (<code>WEB-INF/web.xml</code>)
* implement the service class with using the correct annotations

The '''web.xml''' needs to contain the following information:
<pre><?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
<display-name>weatherserv</display-name>
<servlet>
<servlet-name>Jersey REST Service</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>at.ettisoft.weatherserv</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>Jersey REST Service</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
</web-app></pre>

* The servlet container is implemented by Jersey, therefore the node <code>web-app/servlet/servlet-class</code> must point to ''com.sun.jersey.spi.container.servlet.ServletContainer''.
* This container expects the parameter <code>com.sun.jersey.config.property.packages</code> to point to the service classes at ''at.ettisoft.weatherserv''

Weather monitor

2013-03-27T19:46:11Z

Christian: /* Protocol between Receiver and Server */ ASCII string format

The basic idea of the '''weathermon''' project is to obtain, record and monitor the weather at my home. All weather data sent from wireless sensors is to be stored in a database, from which different graphs are generated that can be monitored on a PC, over the Internet and on a smartphone.

= System Overview =
# Weather data is measured by sensors outside and inside the house. These sensors transmit all measured values via radio link.
# Transmitted values are received by a weather station and displayed for convenience.
# Transmitted values are also received by a small USB device which sends them to the PC connected.
# The PC reads received measurements and stores them in a database.
# From this database a web server serves all measurements to clients for display.

== Sensors ==
The sensors and the weather station come as a set from [http://www.elv.de ELV]:
* Outdoor sensor: [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html ELV Funk-Kombi-Wettersensor KS300-2]
* Indoor sensor: [http://www.elv.de/funk-temperatur-luftfeuchteaussensensor-s-300-th-fuer-z-b-elv-ws-200-300-elv-ws-300-pc-usb-wde1-und-ipwe-1.html Funk-Temperatur-/Luftfeuchteaußensensor S300 TH]
* Weather station: WS300

== Receiver ==
For receiving the 868,35 MHz signals the following device from ELV is used:
* [http://www.elv.de/usb-wetterdaten-empfaenger-usb-wde1-komplettbausatz.html USB-Wetterdaten-Empfänger USB-WDE1]

== Database ==
Data from weather sensors is stored in a Round Robin Database (RRDB) at different resolutions. This means, while high-resolution data is stored for the last 90 days, it also gets accumulated into daily data which is then kept for 10 years.

The database used is called [http://oss.oetiker.ch/rrdtool/ RRDtool] by Tobi Oetiker. It handles storing data at fixed intervals while updates come randomly, accumulating data and creating graphs. The latter is not used, instead a browser-based charting API is used to create dynamic charts.

== Server ==
The server's job is to run the database and web server, so that clients can connect with a browser and retrieve and display all weather data.
* The server is a standard Linux PC, but not a common desktop machine. Instead, a [http://www.raspberrypi.org/ Raspberry PI] is used.
* The server runs an [http://tomcat.apache.org/ Apache Tomcat] web server.

= Interfaces =
== Protocol between Receiver and Server ==
The USB-WDE1 contains a [https://www.silabs.com/Support%20Documents/TechnicalDocs/cp2102.pdf CP210x] serial-to-USB chip from Silicon Labs. Fortunately, Linux already contains a driver for that chip, so all that is needed is to plug the USB-WDE1 into the USB port. One can verify the driver is loaded correctly with ''lsmod'':
<pre>pi@raspberrypi ~ $ lsmod
Module Size Used by
cp210x 11783 0
usbserial 34545 1 cp210x
</pre>
From then on the USB-WDE1 will transmit a serial ASCII string whenever a new measurement has been received. This can be verified with the following commands:
<pre>stty -F /dev/ttyUSB0 9600
cat /dev/ttyUSB0</pre>

The ASCII string sent by the USB-WDE1 can look like this:
<pre>$1;1;;;;;;-3,8;;;;;;;;94;;;;-4,2;98;0,0;36;1;0</pre>
Which means:
* Temperature sensor address 5: -3.8°C
* Humidity sensor address 5: 94%
* Outside temperature: -4.2°C
* Outside humidity: 98%
* Wind speed: 0.0 km/h
* Rain intensity: 36 rocker switch impulses (equals 8.8mm/m²)
* Immediate rain detected

== Protocol between Server and Clients ==
* REST with JSON

= Software Components =
== Filling Database ==
Serial data coming from the receiver must be interpreted and then stored into the database.

== Querying the Database ==
For fetching data from the database I decided to use the '''java-rrd''' library. In contrast to other Java implementations for interfacing an ''rrdtool'' database, this has the following advantages:
* It uses ''rrdtool'' itself, so it is 100% compatible with the database file format. Other implementations re-implement ''rrdtool'' but use a slightly different file format. As I use the original ''rrdtool'' to enter data into the database, the Java components must be compatible with it.
* It doesn't use '''JNI''' framework, which would cause the software to be not platform-independent any more. As I develop under Windows but run the server with Linux, this was no option either.

The '''java-rrd''' library is written by Peter Stamfest. The original announcement can be found here:
* http://www.mail-archive.com/rrd-developers@lists.oetiker.ch/msg03866.html
Very helpful is the brief introduction by Manuel Aldana:
* http://www.aldana-online.de/2011/07/03/accessing-rrdtool-files-data-with-java/

This library uses rrdtool's ''pipe mode'': It calls <code>"rrdtool -"</code> which causes rrdtool to wait for commands from stdin and output its responses to stdout. This mode is also very fast, because the rrdtool instance only needs to be started once and from then on serves all requests.

The tricky part is to configure the place of the database file differently depending on which machine it runs on (development machine or server). I decided to use Tomcat's ''Context Parameters''. I configured the context in <code>META-INF/context.xml</code> which resides in the deployable WAR file and is copied to a machine-specific directory upon first deployment. There I can modify it to fit the corresponding machine configuration. To access this context parameter in the source code I have to do the following:
<pre>@javax.ws.rs.core.Context
public void setServletContext(ServletContext context) throws IOException {
servletContext = context;
String rrdbdir = servletContext.getInitParameter("rrdbdir");</pre>

== REST Server ==
The web server implements a [http://en.wikipedia.org/wiki/Representational_state_transfer REST] service which clients use to query data from the database. It is implemented in Java and uses the [http://jersey.java.net/ Jersey] framework.

A very good introduction to implementing REST services with Jersey can be found here:
* http://www.vogella.com/articles/REST/article.html

Basically, you only need to do the following:
* setup the deployment descriptor (<code>WEB-INF/web.xml</code>)
* implement the service class with using the correct annotations

The '''web.xml''' needs to contain the following information:
<pre><?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
<display-name>weatherserv</display-name>
<servlet>
<servlet-name>Jersey REST Service</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>at.ettisoft.weatherserv</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>Jersey REST Service</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
</web-app></pre>

* The servlet container is implemented by Jersey, therefore the node <code>web-app/servlet/servlet-class</code> must point to ''com.sun.jersey.spi.container.servlet.ServletContainer''.
* This container expects the parameter <code>com.sun.jersey.config.property.packages</code> to point to the service classes at ''at.ettisoft.weatherserv''

Weather monitor

2013-03-27T19:31:32Z

Christian: /* Protocol between Receiver and Server */ USB-to-serial chip

The basic idea of the '''weathermon''' project is to obtain, record and monitor the weather at my home. All weather data sent from wireless sensors is to be stored in a database, from which different graphs are generated that can be monitored on a PC, over the Internet and on a smartphone.

= System Overview =
# Weather data is measured by sensors outside and inside the house. These sensors transmit all measured values via radio link.
# Transmitted values are received by a weather station and displayed for convenience.
# Transmitted values are also received by a small USB device which sends them to the PC connected.
# The PC reads received measurements and stores them in a database.
# From this database a web server serves all measurements to clients for display.

== Sensors ==
The sensors and the weather station come as a set from [http://www.elv.de ELV]:
* Outdoor sensor: [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html ELV Funk-Kombi-Wettersensor KS300-2]
* Indoor sensor: [http://www.elv.de/funk-temperatur-luftfeuchteaussensensor-s-300-th-fuer-z-b-elv-ws-200-300-elv-ws-300-pc-usb-wde1-und-ipwe-1.html Funk-Temperatur-/Luftfeuchteaußensensor S300 TH]
* Weather station: WS300

== Receiver ==
For receiving the 868,35 MHz signals the following device from ELV is used:
* [http://www.elv.de/usb-wetterdaten-empfaenger-usb-wde1-komplettbausatz.html USB-Wetterdaten-Empfänger USB-WDE1]

== Database ==
Data from weather sensors is stored in a Round Robin Database (RRDB) at different resolutions. This means, while high-resolution data is stored for the last 90 days, it also gets accumulated into daily data which is then kept for 10 years.

The database used is called [http://oss.oetiker.ch/rrdtool/ RRDtool] by Tobi Oetiker. It handles storing data at fixed intervals while updates come randomly, accumulating data and creating graphs. The latter is not used, instead a browser-based charting API is used to create dynamic charts.

== Server ==
The server's job is to run the database and web server, so that clients can connect with a browser and retrieve and display all weather data.
* The server is a standard Linux PC, but not a common desktop machine. Instead, a [http://www.raspberrypi.org/ Raspberry PI] is used.
* The server runs an [http://tomcat.apache.org/ Apache Tomcat] web server.

= Interfaces =
== Protocol between Receiver and Server ==
The USB-WDE1 contains a [https://www.silabs.com/Support%20Documents/TechnicalDocs/cp2102.pdf CP210x] serial-to-USB chip from Silicon Labs. Fortunately, Linux already contains a driver for that chip, so all that is needed is to plug the USB-WDE1 into the USB port. One can verify the driver is loaded correctly with ''lsmod'':
<pre>pi@raspberrypi ~ $ lsmod
Module Size Used by
cp210x 11783 0
usbserial 34545 1 cp210x
</pre>
From then on the USB-WDE1 will transmit a serial ASCII string whenever a new measurement has been received.

== Protocol between Server and Clients ==
* REST with JSON

= Software Components =
== Filling Database ==
Serial data coming from the receiver must be interpreted and then stored into the database.

== Querying the Database ==
For fetching data from the database I decided to use the '''java-rrd''' library. In contrast to other Java implementations for interfacing an ''rrdtool'' database, this has the following advantages:
* It uses ''rrdtool'' itself, so it is 100% compatible with the database file format. Other implementations re-implement ''rrdtool'' but use a slightly different file format. As I use the original ''rrdtool'' to enter data into the database, the Java components must be compatible with it.
* It doesn't use '''JNI''' framework, which would cause the software to be not platform-independent any more. As I develop under Windows but run the server with Linux, this was no option either.

The '''java-rrd''' library is written by Peter Stamfest. The original announcement can be found here:
* http://www.mail-archive.com/rrd-developers@lists.oetiker.ch/msg03866.html
Very helpful is the brief introduction by Manuel Aldana:
* http://www.aldana-online.de/2011/07/03/accessing-rrdtool-files-data-with-java/

This library uses rrdtool's ''pipe mode'': It calls <code>"rrdtool -"</code> which causes rrdtool to wait for commands from stdin and output its responses to stdout. This mode is also very fast, because the rrdtool instance only needs to be started once and from then on serves all requests.

The tricky part is to configure the place of the database file differently depending on which machine it runs on (development machine or server). I decided to use Tomcat's ''Context Parameters''. I configured the context in <code>META-INF/context.xml</code> which resides in the deployable WAR file and is copied to a machine-specific directory upon first deployment. There I can modify it to fit the corresponding machine configuration. To access this context parameter in the source code I have to do the following:
<pre>@javax.ws.rs.core.Context
public void setServletContext(ServletContext context) throws IOException {
servletContext = context;
String rrdbdir = servletContext.getInitParameter("rrdbdir");</pre>

== REST Server ==
The web server implements a [http://en.wikipedia.org/wiki/Representational_state_transfer REST] service which clients use to query data from the database. It is implemented in Java and uses the [http://jersey.java.net/ Jersey] framework.

A very good introduction to implementing REST services with Jersey can be found here:
* http://www.vogella.com/articles/REST/article.html

Basically, you only need to do the following:
* setup the deployment descriptor (<code>WEB-INF/web.xml</code>)
* implement the service class with using the correct annotations

The '''web.xml''' needs to contain the following information:
<pre><?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
<display-name>weatherserv</display-name>
<servlet>
<servlet-name>Jersey REST Service</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>at.ettisoft.weatherserv</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>Jersey REST Service</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
</web-app></pre>

* The servlet container is implemented by Jersey, therefore the node <code>web-app/servlet/servlet-class</code> must point to ''com.sun.jersey.spi.container.servlet.ServletContainer''.
* This container expects the parameter <code>com.sun.jersey.config.property.packages</code> to point to the service classes at ''at.ettisoft.weatherserv''

Weather monitor

2013-03-17T15:06:13Z

Christian: /* REST Server */ added details about Jersey

The basic idea of the '''weathermon''' project is to obtain, record and monitor the weather at my home. All weather data sent from wireless sensors is to be stored in a database, from which different graphs are generated that can be monitored on a PC, over the Internet and on a smartphone.

= System Overview =
# Weather data is measured by sensors outside and inside the house. These sensors transmit all measured values via radio link.
# Transmitted values are received by a weather station and displayed for convenience.
# Transmitted values are also received by a small USB device which sends them to the PC connected.
# The PC reads received measurements and stores them in a database.
# From this database a web server serves all measurements to clients for display.

== Sensors ==
The sensors and the weather station come as a set from [http://www.elv.de ELV]:
* Outdoor sensor: [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html ELV Funk-Kombi-Wettersensor KS300-2]
* Indoor sensor: [http://www.elv.de/funk-temperatur-luftfeuchteaussensensor-s-300-th-fuer-z-b-elv-ws-200-300-elv-ws-300-pc-usb-wde1-und-ipwe-1.html Funk-Temperatur-/Luftfeuchteaußensensor S300 TH]
* Weather station: WS300

== Receiver ==
For receiving the 868,35 MHz signals the following device from ELV is used:
* [http://www.elv.de/usb-wetterdaten-empfaenger-usb-wde1-komplettbausatz.html USB-Wetterdaten-Empfänger USB-WDE1]

== Database ==
Data from weather sensors is stored in a Round Robin Database (RRDB) at different resolutions. This means, while high-resolution data is stored for the last 90 days, it also gets accumulated into daily data which is then kept for 10 years.

The database used is called [http://oss.oetiker.ch/rrdtool/ RRDtool] by Tobi Oetiker. It handles storing data at fixed intervals while updates come randomly, accumulating data and creating graphs. The latter is not used, instead a browser-based charting API is used to create dynamic charts.

== Server ==
The server's job is to run the database and web server, so that clients can connect with a browser and retrieve and display all weather data.
* The server is a standard Linux PC, but not a common desktop machine. Instead, a [http://www.raspberrypi.org/ Raspberry PI] is used.
* The server runs an [http://tomcat.apache.org/ Apache Tomcat] web server.

= Interfaces =
== Protocol between Receiver and Server ==
== Protocol between Server and Clients ==
* REST with JSON

= Software Components =
== Filling Database ==
Serial data coming from the receiver must be interpreted and then stored into the database.

== Querying the Database ==
For fetching data from the database I decided to use the '''java-rrd''' library. In contrast to other Java implementations for interfacing an ''rrdtool'' database, this has the following advantages:
* It uses ''rrdtool'' itself, so it is 100% compatible with the database file format. Other implementations re-implement ''rrdtool'' but use a slightly different file format. As I use the original ''rrdtool'' to enter data into the database, the Java components must be compatible with it.
* It doesn't use '''JNI''' framework, which would cause the software to be not platform-independent any more. As I develop under Windows but run the server with Linux, this was no option either.

The '''java-rrd''' library is written by Peter Stamfest. The original announcement can be found here:
* http://www.mail-archive.com/rrd-developers@lists.oetiker.ch/msg03866.html
Very helpful is the brief introduction by Manuel Aldana:
* http://www.aldana-online.de/2011/07/03/accessing-rrdtool-files-data-with-java/

This library uses rrdtool's ''pipe mode'': It calls <code>"rrdtool -"</code> which causes rrdtool to wait for commands from stdin and output its responses to stdout. This mode is also very fast, because the rrdtool instance only needs to be started once and from then on serves all requests.

The tricky part is to configure the place of the database file differently depending on which machine it runs on (development machine or server). I decided to use Tomcat's ''Context Parameters''. I configured the context in <code>META-INF/context.xml</code> which resides in the deployable WAR file and is copied to a machine-specific directory upon first deployment. There I can modify it to fit the corresponding machine configuration. To access this context parameter in the source code I have to do the following:
<pre>@javax.ws.rs.core.Context
public void setServletContext(ServletContext context) throws IOException {
servletContext = context;
String rrdbdir = servletContext.getInitParameter("rrdbdir");</pre>

== REST Server ==
The web server implements a [http://en.wikipedia.org/wiki/Representational_state_transfer REST] service which clients use to query data from the database. It is implemented in Java and uses the [http://jersey.java.net/ Jersey] framework.

A very good introduction to implementing REST services with Jersey can be found here:
* http://www.vogella.com/articles/REST/article.html

Basically, you only need to do the following:
* setup the deployment descriptor (<code>WEB-INF/web.xml</code>)
* implement the service class with using the correct annotations

The '''web.xml''' needs to contain the following information:
<pre><?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
<display-name>weatherserv</display-name>
<servlet>
<servlet-name>Jersey REST Service</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>at.ettisoft.weatherserv</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>Jersey REST Service</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
</web-app></pre>

* The servlet container is implemented by Jersey, therefore the node <code>web-app/servlet/servlet-class</code> must point to ''com.sun.jersey.spi.container.servlet.ServletContainer''.
* This container expects the parameter <code>com.sun.jersey.config.property.packages</code> to point to the service classes at ''at.ettisoft.weatherserv''

Weather monitor

2013-03-17T14:54:46Z

Christian: /* Querying the Database */

Weather monitor

2013-03-17T14:47:26Z

Christian: /* Querying the Database */ added configuration of database directory

Weather monitor

2013-03-17T14:34:33Z

Christian: /* Querying the Database */

Weather monitor

2013-03-17T14:33:57Z

Christian: move description of how database is queried to separate section

Weather monitor

2013-03-17T14:23:59Z

Christian: /* REST Server */

Weather monitor

2013-03-17T14:18:19Z

Christian: /* REST Server */

Weather monitor

2013-03-17T12:57:50Z

Christian: /* REST Server */

Weather monitor

2013-03-17T12:56:50Z

Christian: added Interfaces and /* Software Components */

Weather monitor

2013-03-07T07:31:07Z

Christian: /* Server */

Weather monitor

2013-03-06T14:27:04Z

Christian: /* Database */

Weather monitor

2013-03-06T14:26:27Z

Christian: /* Database */

Weather monitor

2013-02-22T20:27:43Z

Christian: added sensors

Weather monitor

2013-01-31T13:14:30Z

Christian: first few lines

LED Sternenhimmel

2012-05-29T16:05:15Z

Christian: /* Lösungsidee 1: Controller umpolen */ zweite Lösungsidee

In diesem Projekt geht es um das Bauen eines farbigen Sternenhimmels für unseren Wellness-Bereich (Badezimmer). Die Decke soll etwas abgehängt werden um Halogenstrahler versenkt einbauen zu können, und bei dieser Gelegenheit lässt sich auch gut ein dezenter Sternenhimmel einbauen.

= Idee =
Die Idee kam mir, als ich in einem Baumarkt [http://www.amazon.de/Osram-79643-Leds-Deco-Basis/dp/B003VM8RYK/ref=pd_sim_sbs_ce_3 dieses Set] entdeckte. Mittels einer kleinen, schicken IR-Fernbedienung kann man dort jede gewünsche Farbe einstellen und hat auch automatische Farbwechselprogramme zur Auswahl. Meine Idee war, statt der LED-Streifen einzelne RGB-LEDs anzuschließen, die ich in der abgehängten Decke meines zukünftigen Badezimmer montieren würde.

= Einkauf =
Bevor ich den Plan mit der abgehängten Decke umsetze, wollte ich zuerst einen Prototyp bauen. Also mussten zuerst alle notwendigen Teile für den Prototyp gekauft werden.

== LED Controller ==
Da das Set durch die LED Streifen relativ teuer war, hab ich versucht, den RGB-Controller einzeln zu bekommen. Das Set ist eigentlich von [http://www.paulmann.com Paulmann], die wohl Marktführer auf diesem Gebiet sind. Der Controller heißt dort '''yourLED RGB-Control''' [http://www.paulmann.com/index.php?Land_ID=1&Sprache_ID=1&1Menu_ID=84&Anwendung_ID=22&EcatAction=Artikel&Katalog=2460&Kapitel=7777&Artikel=70202#top]. Gefunden habe ich ihn dann bei [http://www.leuchtenprofi.at/product_info.php?products_id=725&XTCsid=45694b0d9d33e1394ec62c1cc302fd94 leuchtenprofi.at] für günstige 29,90 EUR:

[[File:RGB controller.jpg|none|300px]]

Die Fernbedienung ist etwas größer als die ursprüngliche im Baumarkt, dafür bietet sie mehr Möglichkeiten. Man kann z.B. jede einzelne Farbkomponente heller oder dunkler machen.

== RGB Leuchtdioden ==
Da RGB-Leuchtdioden relativ teuer sind, kaufte ich zuerst nur 10 Stück. Bei Conrad fand ich die günstigsten: [http://www.conrad.de/ce/de/product/185388/LED-FULL-COLOR-RGB-KLAR/0212268&ref=list Full Color RGB Lamp] von Kingbright (Datenblatt siehe [http://www.produktinfo.conrad.com/datenblaetter/175000-199999/185388-da-01-en-FULL_COLOR_RGB_LED_KLAR.pdf hier]).

= Erste Inbetriebnahme =
Da ich davon ausging, dass der Controller eine (regelbare) Konstantstromquelle ist, hab ich für einen ersten Test einfach die Leuchtdiode ohne Vorwiderstand angeschlossen. Leider ohne Erfolg, nichts leuchtete.

Also das Multimeter ausgepackt und erst mal nachgemessen: Die Spannung auf den Pins beträgt ~5V, leider hab ich kein Oszi, sonst hätte ich das genauer feststellen können. Allerdings ist mir dabei ein Riesenproblem aufgefallen. Der Controller besitzt 1 Pin als gemeinsamen Pluspol, und 3 Pins als Minuspole für die drei Farben:
{| border="1"
! Pin !! Bedeutung
|-
| 1 || Pluspol (+)
|-
| 2 || Minuspol grün
|-
| 3 || Minuspol rot
|-
| 4 || Minuspol blau
|}

Unglücklicherweise sind die Leutdioden aber so geschaltet, dass immer zwei Farben eine Kathode (Minuspol) teilen. Das heißt: diese Leuchtdioden lassen sich nicht mit diesem RGB-Controller betreiben.

[[File:kingbright_schematic.png|none|200px]]

(E steht für rot, G für grün und MB für blau)

Um trotzdem einen ersten Funktionstest machen zu können, verzichtete ich vorerst auf die blaue Leuchtdiode und schloss nur die rote und grüne an. Leider leuchteten beide Farben sehr schwach und die grüne Leuchtdiode leuchtete orange statt grün. Zudem wurde das Leuchten nach wenigen Sekunden immer schwächer und die Leuchtdiode heizte sich stark auf.

Um weiterzukommen, sah ich mir erst mal die Innereien vom RGB-Controller an.

= LED Controller Aufbau =
<gallery>
File:RGB_controller_case.jpg|The Gehäuse ist nur mit 4 Noppen an den Längsseiten verschlossen
File:RGB_controller_top.jpg|Oberseite der Leiterplatine
File:RGB_controller_bottom.jpg|Unterseite der Leiterplatine
</gallery>

Herzstück des RGB-Controllers ist ein [http://www.stc-51.com/stc11f01.php STC11F04 Mikrocontroller] mit 4k Flash und 256 Bytes SRAM (Datenblatt: [http://www.stc-51.com/datasheet/STC11F-10Fxx-english.pdf]). Dieser läuft mit 20 MHz und hat einen [http://www.atmel.com/dyn/products/product_card.asp?part_id=4706 24C02C EEPROM] mit 256 Byte zur Seite gestellt. Versorgt wird die ganze Schaltung von einem 78L05 Linearregler.

Interessant für meinen Anwendungsfall ist vor allem der Ausgangsteil: Der besteht nämlich aus drei [https://www.onsemi.com/PowerSolutions/product.do?id=NTD60N02RG 60N02] MOSFETs (Datenblatt: [http://www.onsemi.com/pub_link/Collateral/NTD60N02R-D.PDF]), die für jede der drei Farben die Masse durchschalten oder sperren.

Das heißt, die Betriebsspannung von 12 Volt (laut Aufdruck, durch den Linearregler kann sie zwischen 5-48V betragen) wird direkt zu den Leuchtdioden durchgeschaltet. Das ist für eine Leuchtdiode natürlich viel zu viel, als Maximalwerte sind im Datenblatt 4.5V bei Blau und 2.5V bei Rot und Grün angegeben. Das erklärt wahrscheinlich die starke Erwärmung, das schwächer werdende Leuchten und die falsche Farbe (orange statt grün). Die Erkenntnis daraus: '''Die LEDs dürfen nur mit Vorwiderstand angeschlossen werden!'''

== Lösungsidee 1: Controller umpolen ==
Eine Möglichkeit, die LEDs mit der gemeinsamen Kathode doch noch mit diesem Controller zu betreiben, ist, den Controller umzupolen. Man könnte eine Leiterbahn durchtrennen und anders verbinden, sodass die MOSFETs nicht Masse durchschalten, sondern die Betriebsspannung.

Leider führt diese Idee '''nicht zum Ziel''': die verwendeten MOSFETs besitzen eine interne Diode zwischen Source und Drain, sodass der Transistor nicht verkehrt betrieben werden kann. Das heißt, dass diese MOSFETs nur bei einer positiven Drain-Source Spannung sperren, in Gegenrichtung sind sie immer durchlässig. Das wäre für diese Idee aber notwendig.

== Lösungsidee 2: invertierende Schaltung ==
Das vom Controller kommende Signal kann mit einer geeigneten Schaltung invertiert werden. Dazu sind 3 weitere Treiber-Transistoren notwendig.

Diese Variante werde ich bei Gelegenheit einmal ausprobieren.

[[Category:Electronics]]

LED Sternenhimmel

2011-11-05T11:50:58Z

Christian: /* LED Controller Aufbau */ hinzugefügt: Controller umpolen

In diesem Projekt geht es um das Bauen eines farbigen Sternenhimmels für unseren Wellness-Bereich (Badezimmer). Die Decke soll etwas abgehängt werden um Halogenstrahler versenkt einbauen zu können, und bei dieser Gelegenheit lässt sich auch gut ein dezenter Sternenhimmel einbauen.

= Idee =
Die Idee kam mir, als ich in einem Baumarkt [http://www.amazon.de/Osram-79643-Leds-Deco-Basis/dp/B003VM8RYK/ref=pd_sim_sbs_ce_3 dieses Set] entdeckte. Mittels einer kleinen, schicken IR-Fernbedienung kann man dort jede gewünsche Farbe einstellen und hat auch automatische Farbwechselprogramme zur Auswahl. Meine Idee war, statt der LED-Streifen einzelne RGB-LEDs anzuschließen, die ich in der abgehängten Decke meines zukünftigen Badezimmer montieren würde.

= Einkauf =
Bevor ich den Plan mit der abgehängten Decke umsetze, wollte ich zuerst einen Prototyp bauen. Also mussten zuerst alle notwendigen Teile für den Prototyp gekauft werden.

== LED Controller ==
Da das Set durch die LED Streifen relativ teuer war, hab ich versucht, den RGB-Controller einzeln zu bekommen. Das Set ist eigentlich von [http://www.paulmann.com Paulmann], die wohl Marktführer auf diesem Gebiet sind. Der Controller heißt dort '''yourLED RGB-Control''' [http://www.paulmann.com/index.php?Land_ID=1&Sprache_ID=1&1Menu_ID=84&Anwendung_ID=22&EcatAction=Artikel&Katalog=2460&Kapitel=7777&Artikel=70202#top]. Gefunden habe ich ihn dann bei [http://www.leuchtenprofi.at/product_info.php?products_id=725&XTCsid=45694b0d9d33e1394ec62c1cc302fd94 leuchtenprofi.at] für günstige 29,90 EUR:

[[File:RGB controller.jpg|none|300px]]

Die Fernbedienung ist etwas größer als die ursprüngliche im Baumarkt, dafür bietet sie mehr Möglichkeiten. Man kann z.B. jede einzelne Farbkomponente heller oder dunkler machen.

== RGB Leuchtdioden ==
Da RGB-Leuchtdioden relativ teuer sind, kaufte ich zuerst nur 10 Stück. Bei Conrad fand ich die günstigsten: [http://www.conrad.de/ce/de/product/185388/LED-FULL-COLOR-RGB-KLAR/0212268&ref=list Full Color RGB Lamp] von Kingbright (Datenblatt siehe [http://www.produktinfo.conrad.com/datenblaetter/175000-199999/185388-da-01-en-FULL_COLOR_RGB_LED_KLAR.pdf hier]).

= Erste Inbetriebnahme =
Da ich davon ausging, dass der Controller eine (regelbare) Konstantstromquelle ist, hab ich für einen ersten Test einfach die Leuchtdiode ohne Vorwiderstand angeschlossen. Leider ohne Erfolg, nichts leuchtete.

Also das Multimeter ausgepackt und erst mal nachgemessen: Die Spannung auf den Pins beträgt ~5V, leider hab ich kein Oszi, sonst hätte ich das genauer feststellen können. Allerdings ist mir dabei ein Riesenproblem aufgefallen. Der Controller besitzt 1 Pin als gemeinsamen Pluspol, und 3 Pins als Minuspole für die drei Farben:
{| border="1"
! Pin !! Bedeutung
|-
| 1 || Pluspol (+)
|-
| 2 || Minuspol grün
|-
| 3 || Minuspol rot
|-
| 4 || Minuspol blau
|}

Unglücklicherweise sind die Leutdioden aber so geschaltet, dass immer zwei Farben eine Kathode (Minuspol) teilen. Das heißt: diese Leuchtdioden lassen sich nicht mit diesem RGB-Controller betreiben.

[[File:kingbright_schematic.png|none|200px]]

(E steht für rot, G für grün und MB für blau)

Um trotzdem einen ersten Funktionstest machen zu können, verzichtete ich vorerst auf die blaue Leuchtdiode und schloss nur die rote und grüne an. Leider leuchteten beide Farben sehr schwach und die grüne Leuchtdiode leuchtete orange statt grün. Zudem wurde das Leuchten nach wenigen Sekunden immer schwächer und die Leuchtdiode heizte sich stark auf.

Um weiterzukommen, sah ich mir erst mal die Innereien vom RGB-Controller an.

= LED Controller Aufbau =
<gallery>
File:RGB_controller_case.jpg|The Gehäuse ist nur mit 4 Noppen an den Längsseiten verschlossen
File:RGB_controller_top.jpg|Oberseite der Leiterplatine
File:RGB_controller_bottom.jpg|Unterseite der Leiterplatine
</gallery>

Herzstück des RGB-Controllers ist ein [http://www.stc-51.com/stc11f01.php STC11F04 Mikrocontroller] mit 4k Flash und 256 Bytes SRAM (Datenblatt: [http://www.stc-51.com/datasheet/STC11F-10Fxx-english.pdf]). Dieser läuft mit 20 MHz und hat einen [http://www.atmel.com/dyn/products/product_card.asp?part_id=4706 24C02C EEPROM] mit 256 Byte zur Seite gestellt. Versorgt wird die ganze Schaltung von einem 78L05 Linearregler.

Interessant für meinen Anwendungsfall ist vor allem der Ausgangsteil: Der besteht nämlich aus drei [https://www.onsemi.com/PowerSolutions/product.do?id=NTD60N02RG 60N02] MOSFETs (Datenblatt: [http://www.onsemi.com/pub_link/Collateral/NTD60N02R-D.PDF]), die für jede der drei Farben die Masse durchschalten oder sperren.

Das heißt, die Betriebsspannung von 12 Volt (laut Aufdruck, durch den Linearregler kann sie zwischen 5-48V betragen) wird direkt zu den Leuchtdioden durchgeschaltet. Das ist für eine Leuchtdiode natürlich viel zu viel, als Maximalwerte sind im Datenblatt 4.5V bei Blau und 2.5V bei Rot und Grün angegeben. Das erklärt wahrscheinlich die starke Erwärmung, das schwächer werdende Leuchten und die falsche Farbe (orange statt grün). Die Erkenntnis daraus: '''Die LEDs dürfen nur mit Vorwiderstand angeschlossen werden!'''

== Lösungsidee 1: Controller umpolen ==
Eine Möglichkeit, die LEDs mit der gemeinsamen Kathode doch noch mit diesem Controller zu betreiben, ist, den Controller umzupolen. Man könnte eine Leiterbahn durchtrennen und anders verbinden, sodass die MOSFETs nicht Masse durchschalten, sondern die Betriebsspannung.

Leider führt diese Idee nicht zum Ziel: die verwendeten MOSFETs besitzen eine interne Diode zwischen Source und Drain, sodass der Transistor nicht verkehrt betrieben werden kann. Das heißt, dass diese MOSFETs nur bei einer positiven Drain-Source Spannung sperren, in Gegenrichtung sind sie immer durchlässig. Das wäre für diese Idee aber notwendig.

[[Category:Electronics]]

LED Sternenhimmel

2011-11-05T11:26:19Z

Christian: /* LED Controller Aufbau */ Datenblatt für Mosfet

LED Sternenhimmel

2011-11-05T11:16:47Z

Christian: /* Inbetriebnahme Prototyp */ umbenannt

In diesem Projekt geht es um das Bauen eines farbigen Sternenhimmels für unseren Wellness-Bereich (Badezimmer). Die Decke soll etwas abgehängt werden um Halogenstrahler versenkt einbauen zu können, und bei dieser Gelegenheit lässt sich auch gut ein dezenter Sternenhimmel einbauen.

= Idee =
Die Idee kam mir, als ich in einem Baumarkt [http://www.amazon.de/Osram-79643-Leds-Deco-Basis/dp/B003VM8RYK/ref=pd_sim_sbs_ce_3 dieses Set] entdeckte. Mittels einer kleinen, schicken IR-Fernbedienung kann man dort jede gewünsche Farbe einstellen und hat auch automatische Farbwechselprogramme zur Auswahl. Meine Idee war, statt der LED-Streifen einzelne RGB-LEDs anzuschließen, die ich in der abgehängten Decke meines zukünftigen Badezimmer montieren würde.

= Einkauf =
Bevor ich den Plan mit der abgehängten Decke umsetze, wollte ich zuerst einen Prototyp bauen. Also mussten zuerst alle notwendigen Teile für den Prototyp gekauft werden.

== LED Controller ==
Da das Set durch die LED Streifen relativ teuer war, hab ich versucht, den RGB-Controller einzeln zu bekommen. Das Set ist eigentlich von [http://www.paulmann.com Paulmann], die wohl Marktführer auf diesem Gebiet sind. Der Controller heißt dort '''yourLED RGB-Control''' [http://www.paulmann.com/index.php?Land_ID=1&Sprache_ID=1&1Menu_ID=84&Anwendung_ID=22&EcatAction=Artikel&Katalog=2460&Kapitel=7777&Artikel=70202#top]. Gefunden habe ich ihn dann bei [http://www.leuchtenprofi.at/product_info.php?products_id=725&XTCsid=45694b0d9d33e1394ec62c1cc302fd94 leuchtenprofi.at] für günstige 29,90 EUR:

[[File:RGB controller.jpg|none|300px]]

Die Fernbedienung ist etwas größer als die ursprüngliche im Baumarkt, dafür bietet sie mehr Möglichkeiten. Man kann z.B. jede einzelne Farbkomponente heller oder dunkler machen.

== RGB Leuchtdioden ==
Da RGB-Leuchtdioden relativ teuer sind, kaufte ich zuerst nur 10 Stück. Bei Conrad fand ich die günstigsten: [http://www.conrad.de/ce/de/product/185388/LED-FULL-COLOR-RGB-KLAR/0212268&ref=list Full Color RGB Lamp] von Kingbright (Datenblatt siehe [http://www.produktinfo.conrad.com/datenblaetter/175000-199999/185388-da-01-en-FULL_COLOR_RGB_LED_KLAR.pdf hier]).

= Erste Inbetriebnahme =
Da ich davon ausging, dass der Controller eine (regelbare) Konstantstromquelle ist, hab ich für einen ersten Test einfach die Leuchtdiode ohne Vorwiderstand angeschlossen. Leider ohne Erfolg, nichts leuchtete.

Also das Multimeter ausgepackt und erst mal nachgemessen: Die Spannung auf den Pins beträgt ~5V, leider hab ich kein Oszi, sonst hätte ich das genauer feststellen können. Allerdings ist mir dabei ein Riesenproblem aufgefallen. Der Controller besitzt 1 Pin als gemeinsamen Pluspol, und 3 Pins als Minuspole für die drei Farben:
{| border="1"
! Pin !! Bedeutung
|-
| 1 || Pluspol (+)
|-
| 2 || Minuspol grün
|-
| 3 || Minuspol rot
|-
| 4 || Minuspol blau
|}

Unglücklicherweise sind die Leutdioden aber so geschaltet, dass immer zwei Farben eine Kathode (Minuspol) teilen. Das heißt: diese Leuchtdioden lassen sich nicht mit diesem RGB-Controller betreiben.

[[File:kingbright_schematic.png|none|200px]]

(E steht für rot, G für grün und MB für blau)

Um trotzdem einen ersten Funktionstest machen zu können, verzichtete ich vorerst auf die blaue Leuchtdiode und schloss nur die rote und grüne an. Leider leuchteten beide Farben sehr schwach und die grüne Leuchtdiode leuchtete orange statt grün. Zudem wurde das Leuchten nach wenigen Sekunden immer schwächer und die Leuchtdiode heizte sich stark auf.

Um weiterzukommen, sah ich mir erst mal die Innereien vom RGB-Controller an.

= LED Controller Aufbau =
<gallery>
File:RGB_controller_case.jpg|The Gehäuse ist nur mit 4 Noppen an den Längsseiten verschlossen
File:RGB_controller_top.jpg|Oberseite der Leiterplatine
File:RGB_controller_bottom.jpg|Unterseite der Leiterplatine
</gallery>

Herzstück des RGB-Controllers ist ein [http://www.stc-51.com/stc11f01.php STC11F04 Mikrocontroller] mit 4k Flash und 256 Bytes SRAM (Datenblatt: [http://www.stc-51.com/datasheet/STC11F-10Fxx-english.pdf]). Dieser läuft mit 20 MHz und hat einen [http://www.atmel.com/dyn/products/product_card.asp?part_id=4706 24C02C EEPROM] mit 256 Byte zur Seite gestellt. Versorgt wird die ganze Schaltung von einem 78L05 Linearregler.

Interessant für meinen Anwendungsfall ist vor allem der Ausgangsteil: Der besteht nämlich aus drei T60 N02RG MOSFETs, die für jede der drei Farben die Masse durchschalten oder sperren.

Das heißt, die Betriebsspannung von 12 Volt (laut Aufdruck, durch den Linearregler kann sie zwischen 5-48V betragen) wird direkt zu den Leuchtdioden durchgeschaltet. Das ist für eine Leuchtdiode natürlich viel zu viel, als Maximalwerte sind im Datenblatt 4.5V bei Blau und 2.5V bei Rot und Grün angegeben. Das erklärt wahrscheinlich die starke Erwärmung, das schwächer werdende Leuchten und die falsche Farbe (orange statt grün). Die Erkenntnis daraus: '''Die LEDs dürfen nur mit Vorwiderstand angeschlossen werden!'''

[[Category:Electronics]]

LED Sternenhimmel

2011-10-23T20:39:58Z

Christian: /* Inbetriebnahme Prototyp */ Oszi erwähnt

In diesem Projekt geht es um das Bauen eines farbigen Sternenhimmels für unseren Wellness-Bereich (Badezimmer). Die Decke soll etwas abgehängt werden um Halogenstrahler versenkt einbauen zu können, und bei dieser Gelegenheit lässt sich auch gut ein dezenter Sternenhimmel einbauen.

= Idee =
Die Idee kam mir, als ich in einem Baumarkt [http://www.amazon.de/Osram-79643-Leds-Deco-Basis/dp/B003VM8RYK/ref=pd_sim_sbs_ce_3 dieses Set] entdeckte. Mittels einer kleinen, schicken IR-Fernbedienung kann man dort jede gewünsche Farbe einstellen und hat auch automatische Farbwechselprogramme zur Auswahl. Meine Idee war, statt der LED-Streifen einzelne RGB-LEDs anzuschließen, die ich in der abgehängten Decke meines zukünftigen Badezimmer montieren würde.

= Einkauf =
Bevor ich den Plan mit der abgehängten Decke umsetze, wollte ich zuerst einen Prototyp bauen. Also mussten zuerst alle notwendigen Teile für den Prototyp gekauft werden.

== LED Controller ==
Da das Set durch die LED Streifen relativ teuer war, hab ich versucht, den RGB-Controller einzeln zu bekommen. Das Set ist eigentlich von [http://www.paulmann.com Paulmann], die wohl Marktführer auf diesem Gebiet sind. Der Controller heißt dort '''yourLED RGB-Control''' [http://www.paulmann.com/index.php?Land_ID=1&Sprache_ID=1&1Menu_ID=84&Anwendung_ID=22&EcatAction=Artikel&Katalog=2460&Kapitel=7777&Artikel=70202#top]. Gefunden habe ich ihn dann bei [http://www.leuchtenprofi.at/product_info.php?products_id=725&XTCsid=45694b0d9d33e1394ec62c1cc302fd94 leuchtenprofi.at] für günstige 29,90 EUR:

[[File:RGB controller.jpg|none|300px]]

Die Fernbedienung ist etwas größer als die ursprüngliche im Baumarkt, dafür bietet sie mehr Möglichkeiten. Man kann z.B. jede einzelne Farbkomponente heller oder dunkler machen.

== RGB Leuchtdioden ==
Da RGB-Leuchtdioden relativ teuer sind, kaufte ich zuerst nur 10 Stück. Bei Conrad fand ich die günstigsten: [http://www.conrad.de/ce/de/product/185388/LED-FULL-COLOR-RGB-KLAR/0212268&ref=list Full Color RGB Lamp] von Kingbright (Datenblatt siehe [http://www.produktinfo.conrad.com/datenblaetter/175000-199999/185388-da-01-en-FULL_COLOR_RGB_LED_KLAR.pdf hier]).

= Inbetriebnahme Prototyp =
Da ich davon ausging, dass der Controller eine (regelbare) Konstantstromquelle ist, hab ich für einen ersten Test einfach die Leuchtdiode ohne Vorwiderstand angeschlossen. Leider ohne Erfolg, nichts leuchtete.

Also das Multimeter ausgepackt und erst mal nachgemessen: Die Spannung auf den Pins beträgt ~5V, leider hab ich kein Oszi, sonst hätte ich das genauer feststellen können. Allerdings ist mir dabei ein Riesenproblem aufgefallen. Der Controller besitzt 1 Pin als gemeinsamen Pluspol, und 3 Pins als Minuspole für die drei Farben:
{| border="1"
! Pin !! Bedeutung
|-
| 1 || Pluspol (+)
|-
| 2 || Minuspol grün
|-
| 3 || Minuspol rot
|-
| 4 || Minuspol blau
|}

Unglücklicherweise sind die Leutdioden aber so geschaltet, dass immer zwei Farben eine Kathode (Minuspol) teilen. Das heißt: diese Leuchtdioden lassen sich nicht mit diesem RGB-Controller betreiben.

[[File:kingbright_schematic.png|none|200px]]

(E steht für rot, G für grün und MB für blau)

Um trotzdem einen ersten Funktionstest machen zu können, verzichtete ich vorerst auf die blaue Leuchtdiode und schloss nur die rote und grüne an. Leider leuchteten beide Farben sehr schwach und die grüne Leuchtdiode leuchtete orange statt grün. Zudem wurde das Leuchten nach wenigen Sekunden immer schwächer und die Leuchtdiode heizte sich stark auf.

Um weiterzukommen, sah ich mir erst mal die Innereien vom RGB-Controller an.

= LED Controller Aufbau =
<gallery>
File:RGB_controller_case.jpg|The Gehäuse ist nur mit 4 Noppen an den Längsseiten verschlossen
File:RGB_controller_top.jpg|Oberseite der Leiterplatine
File:RGB_controller_bottom.jpg|Unterseite der Leiterplatine
</gallery>

Herzstück des RGB-Controllers ist ein [http://www.stc-51.com/stc11f01.php STC11F04 Mikrocontroller] mit 4k Flash und 256 Bytes SRAM (Datenblatt: [http://www.stc-51.com/datasheet/STC11F-10Fxx-english.pdf]). Dieser läuft mit 20 MHz und hat einen [http://www.atmel.com/dyn/products/product_card.asp?part_id=4706 24C02C EEPROM] mit 256 Byte zur Seite gestellt. Versorgt wird die ganze Schaltung von einem 78L05 Linearregler.

Interessant für meinen Anwendungsfall ist vor allem der Ausgangsteil: Der besteht nämlich aus drei T60 N02RG MOSFETs, die für jede der drei Farben die Masse durchschalten oder sperren.

Das heißt, die Betriebsspannung von 12 Volt (laut Aufdruck, durch den Linearregler kann sie zwischen 5-48V betragen) wird direkt zu den Leuchtdioden durchgeschaltet. Das ist für eine Leuchtdiode natürlich viel zu viel, als Maximalwerte sind im Datenblatt 4.5V bei Blau und 2.5V bei Rot und Grün angegeben. Das erklärt wahrscheinlich die starke Erwärmung, das schwächer werdende Leuchten und die falsche Farbe (orange statt grün). Die Erkenntnis daraus: '''Die LEDs dürfen nur mit Vorwiderstand angeschlossen werden!'''

[[Category:Electronics]]

LED Sternenhimmel

2011-10-23T12:25:03Z

Christian: /* LED Controller Aufbau */

In diesem Projekt geht es um das Bauen eines farbigen Sternenhimmels für unseren Wellness-Bereich (Badezimmer). Die Decke soll etwas abgehängt werden um Halogenstrahler versenkt einbauen zu können, und bei dieser Gelegenheit lässt sich auch gut ein dezenter Sternenhimmel einbauen.

= Idee =
Die Idee kam mir, als ich in einem Baumarkt [http://www.amazon.de/Osram-79643-Leds-Deco-Basis/dp/B003VM8RYK/ref=pd_sim_sbs_ce_3 dieses Set] entdeckte. Mittels einer kleinen, schicken IR-Fernbedienung kann man dort jede gewünsche Farbe einstellen und hat auch automatische Farbwechselprogramme zur Auswahl. Meine Idee war, statt der LED-Streifen einzelne RGB-LEDs anzuschließen, die ich in der abgehängten Decke meines zukünftigen Badezimmer montieren würde.

= Einkauf =
Bevor ich den Plan mit der abgehängten Decke umsetze, wollte ich zuerst einen Prototyp bauen. Also mussten zuerst alle notwendigen Teile für den Prototyp gekauft werden.

== LED Controller ==
Da das Set durch die LED Streifen relativ teuer war, hab ich versucht, den RGB-Controller einzeln zu bekommen. Das Set ist eigentlich von [http://www.paulmann.com Paulmann], die wohl Marktführer auf diesem Gebiet sind. Der Controller heißt dort '''yourLED RGB-Control''' [http://www.paulmann.com/index.php?Land_ID=1&Sprache_ID=1&1Menu_ID=84&Anwendung_ID=22&EcatAction=Artikel&Katalog=2460&Kapitel=7777&Artikel=70202#top]. Gefunden habe ich ihn dann bei [http://www.leuchtenprofi.at/product_info.php?products_id=725&XTCsid=45694b0d9d33e1394ec62c1cc302fd94 leuchtenprofi.at] für günstige 29,90 EUR:

[[File:RGB controller.jpg|none|300px]]

Die Fernbedienung ist etwas größer als die ursprüngliche im Baumarkt, dafür bietet sie mehr Möglichkeiten. Man kann z.B. jede einzelne Farbkomponente heller oder dunkler machen.

== RGB Leuchtdioden ==
Da RGB-Leuchtdioden relativ teuer sind, kaufte ich zuerst nur 10 Stück. Bei Conrad fand ich die günstigsten: [http://www.conrad.de/ce/de/product/185388/LED-FULL-COLOR-RGB-KLAR/0212268&ref=list Full Color RGB Lamp] von Kingbright (Datenblatt siehe [http://www.produktinfo.conrad.com/datenblaetter/175000-199999/185388-da-01-en-FULL_COLOR_RGB_LED_KLAR.pdf hier]).

= Inbetriebnahme Prototyp =
Da ich davon ausging, dass der Controller eine (regelbare) Konstantstromquelle ist, hab ich für einen ersten Test einfach die Leuchtdiode ohne Vorwiderstand angeschlossen. Leider ohne Erfolg, nichts leuchtete.

Also das Multimeter ausgepackt und erst mal nachgemessen: Die Spannung auf den Pins beträgt ~5V, allerdings ist mir dabei ein Riesenproblem aufgefallen. Der Controller besitzt 1 Pin als gemeinsamen Pluspol, und 3 Pins als Minuspole für die drei Farben:
{| border="1"
! Pin !! Bedeutung
|-
| 1 || Pluspol (+)
|-
| 2 || Minuspol grün
|-
| 3 || Minuspol rot
|-
| 4 || Minuspol blau
|}

Unglücklicherweise sind die Leutdioden aber so geschaltet, dass immer zwei Farben eine Kathode (Minuspol) teilen. Das heißt: diese Leuchtdioden lassen sich nicht mit diesem RGB-Controller betreiben.

[[File:kingbright_schematic.png|none|200px]]

(E steht für rot, G für grün und MB für blau)

Um trotzdem einen ersten Funktionstest machen zu können, verzichtete ich vorerst auf die blaue Leuchtdiode und schloss nur die rote und grüne an. Leider leuchteten beide Farben sehr schwach und die grüne Leuchtdiode leuchtete orange statt grün. Zudem wurde das Leuchten nach wenigen Sekunden immer schwächer und die Leuchtdiode heizte sich stark auf.

Um weiterzukommen, sah ich mir erst mal die Innereien vom RGB-Controller an.

= LED Controller Aufbau =
<gallery>
File:RGB_controller_case.jpg|The Gehäuse ist nur mit 4 Noppen an den Längsseiten verschlossen
File:RGB_controller_top.jpg|Oberseite der Leiterplatine
File:RGB_controller_bottom.jpg|Unterseite der Leiterplatine
</gallery>

Herzstück des RGB-Controllers ist ein [http://www.stc-51.com/stc11f01.php STC11F04 Mikrocontroller] mit 4k Flash und 256 Bytes SRAM (Datenblatt: [http://www.stc-51.com/datasheet/STC11F-10Fxx-english.pdf]). Dieser läuft mit 20 MHz und hat einen [http://www.atmel.com/dyn/products/product_card.asp?part_id=4706 24C02C EEPROM] mit 256 Byte zur Seite gestellt. Versorgt wird die ganze Schaltung von einem 78L05 Linearregler.

Interessant für meinen Anwendungsfall ist vor allem der Ausgangsteil: Der besteht nämlich aus drei T60 N02RG MOSFETs, die für jede der drei Farben die Masse durchschalten oder sperren.

Das heißt, die Betriebsspannung von 12 Volt (laut Aufdruck, durch den Linearregler kann sie zwischen 5-48V betragen) wird direkt zu den Leuchtdioden durchgeschaltet. Das ist für eine Leuchtdiode natürlich viel zu viel, als Maximalwerte sind im Datenblatt 4.5V bei Blau und 2.5V bei Rot und Grün angegeben. Das erklärt wahrscheinlich die starke Erwärmung, das schwächer werdende Leuchten und die falsche Farbe (orange statt grün). Die Erkenntnis daraus: '''Die LEDs dürfen nur mit Vorwiderstand angeschlossen werden!'''

[[Category:Electronics]]

File:RGB controller bottom.jpg

2011-10-23T11:41:37Z

Christian:

File:RGB controller top.jpg

2011-10-23T11:41:15Z

Christian:

File:RGB controller case.jpg

2011-10-23T11:40:46Z

Christian:

LED Sternenhimmel

2011-10-23T11:14:26Z

Christian: /* Inbetriebnahme Prototyp */ Bild kleiner

LED Sternenhimmel

2011-10-23T10:38:58Z

Christian: /* Inbetriebnahme Prototyp */

File:Kingbright schematic.png

2011-10-23T10:14:00Z

Christian:

LED Sternenhimmel

2011-10-23T10:13:37Z

Christian: /* Einkauf */

LED Sternenhimmel

2011-10-23T09:46:57Z

Christian: /* RGB Leuchtdioden */

LED Sternenhimmel

2011-10-23T09:44:16Z

Christian: /* LED Controller */

LED Sternenhimmel

2011-10-23T09:38:53Z

Christian: /* LED Controller */

File:RGB controller.jpg

2011-10-23T09:32:26Z

Christian:

LED Sternenhimmel

2011-10-23T09:18:04Z

Christian: created page

PIC programmer

2011-10-12T20:03:53Z

Christian: created empty placeholder page

This is just an empty placeholder, this page is yet to be created

Main Page

2011-08-28T17:51:21Z

Christian:

'''Willkommen im EttiWiki!'''

Das EttiWiki ist eine Plattform zur Veröffentlichung der verschiedenen Projekte der Etti-Familie.

Jeder, also auch Nicht-Ettis, kann sich hier anmelden und zu Projekten beitragen. Kommentare, Verbesserungsvorschläge, aber auch Kritik ist immer willkommen!

Vandalen aufgepasst: Jede Änderung wird registriert und kann mit zwei Klicks wieder rückgängig gemacht werden - spart euch also die Mühe!

Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

== Getting started ==
* [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list]
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]

Geocaching-Ressourcen

2011-08-27T20:51:48Z

Christian: Links auf DOC und PPT-Datei entfernt, weil Wiki deren MIME-Typen falsch erkennt und den Upload blockiert

Für mein Hobby '''Geocachen''' musste ich im Laufe der Zeit ein paar Dateien erstellen. Damit nicht jeder jedesmal das Rad neu erfinden muss, möchte ich hier diese Dateien mit euch teilen. Hoffentlich helfen sie dem einen oder anderen.

= Geocaching-Notiz =
Die Geocaching-Notiz, oder auch ''Geocaching Stash Note'' genannt, wird jeder Geocacher schon fast auswendig kennen - eigentlich sollte sie in jedem Cache vorhanden sein.

Da ich einen kleinen Farb-Laserdrucker zuhause habe, wollte ich gern diese Notiz auch in Farbe haben (sieht hübscher aus). Komischerweise habe ich sie nirgendwo im Internet in Deutsch und in Farbe gefunden, deswegen habe ich kurzerhand eine eigene erstellt:

* PDF-Datei: [[File:Cachenote_german_color.pdf]]
* Original ist im Word-Format, schreibt mich einfach an wenn ihr es benötigt.

Die Word-Datei ist so angelegt, dass links der Text auf Deutsch und rechts auf Englisch steht. Dadurch wird erreicht, dass man durch einen zweiseitigen Druck zwei Exemplare erhält, wobei jeweils die eine Seite Deutsch und die andere Englisch ist.

= "Official Geocache" Aufkleber =
Mir gefallen diese dunkelgrünen Aufkleber sehr gut, nur sind sie nicht ganz günstig (€1,50) und ich hatte Probleme einen auf Englisch zu bekommen. Deswegen hab ich sie kurzerhand selber gemacht:

* PDF-Datei: [[File:Official_geocache_small.pdf]]
* Original ist im PowerPoint-Format, schreibt mich einfach an wenn ihr es benötigt (ja ich weiß, PowerPoint ist nicht gut geeignet dafür, es war mein erster Versuch, jetzt verwende ich bessere Programme *g*)

Interessanterweise konnte ich nicht rausfinden, welche Schriftart Groundspeak auf den offiziellen Aufklebern verwendet. Ich habe dann die Schriftart ''Gunplay'' genommen, die der offiziellen so nah wie möglich kommt.

[[Category:Geocaching]]

File:Official geocache small.pdf

2011-08-27T20:45:05Z

Christian:

File:Cachenote german color.pdf

2011-08-27T20:13:19Z

Christian:

Geocaching ressourcen

2011-08-27T20:07:54Z

Christian: created redirect page

#REDIRECT [[Geocaching-Ressourcen]]

Geocaching-Ressourcen

2011-08-27T20:07:06Z

Christian: created page

Für mein Hobby '''Geocachen''' musste ich im Laufe der Zeit ein paar Dateien erstellen. Damit nicht jeder jedesmal das Rad neu erfinden muss, möchte ich hier diese Dateien mit euch teilen. Hoffentlich helfen sie dem einen oder anderen.

= Geocaching-Notiz =
Die Geocaching-Notiz, oder auch ''Geocaching Stash Note'' genannt, wird jeder Geocacher schon fast auswendig kennen - eigentlich sollte sie in jedem Cache vorhanden sein.

Da ich einen kleinen Farb-Laserdrucker zuhause habe, wollte ich gern diese Notiz auch in Farbe haben (sieht hübscher aus). Komischerweise habe ich sie nirgendwo im Internet in Deutsch und in Farbe gefunden, deswegen habe ich kurzerhand eine eigene erstellt:

* PDF-Datei: [[File:Cachenote_german_color.pdf]]
* Word-Dokument: [[File:Cachenote_german_color.doc]]

Die Word-Datei ist so angelegt, dass links der Text auf Deutsch und rechts auf Englisch steht. Dadurch wird erreicht, dass man durch einen zweiseitigen Druck zwei Exemplare erhält, wobei jeweils die eine Seite Deutsch und die andere Englisch ist.

= "Official Geocache" Aufkleber =
Mir gefallen diese dunkelgrünen Aufkleber sehr gut, nur sind sie nicht ganz günstig (€1,50) und ich hatte Probleme einen auf Englisch zu bekommen. Deswegen hab ich sie kurzerhand selber gemacht:

* PowerPoint-Datei: [[File:Official_Geocache_small.ppt]] (ja ich weiß, PowerPoint ist nicht gut geeignet dafür, es war mein erster Versuch, jetzt verwende ich bessere Programme *g*)
* PDF-Datei: [[File:Official_geocache_small.pdf]]

Interessanterweise konnte ich nicht rausfinden, welche Schriftart Groundspeak auf den offiziellen Aufklebern verwendet. Ich habe dann die Schriftart ''Gunplay'' genommen, die der offiziellen so nah wie möglich kommt.

[[Category:Geocaching]]

USB SNES Controller

2011-06-16T09:09:19Z

Christian: /* Microcontroller */ link to microchip.com

[[File:snes9x_joypad.png|thumb|300px|gamepad configuration in an old version of [http://www.snes9x.com snes9x] - it's simply not fun to play SNES games on a keyboard]]
During my childhood I used to play many great games on the [[Wikipedia:Super Nintendo Entertainment System|Super Nintendo (SNES)]]. Many years later, I heard of [http://www.snes9x.com snes9x] and played a few of these games again on my PC. What always annoyed me was the controller: it was nearly impossible to play these games with the keyboard.

I bought a few [[Wikipedia:Gamepad|gamepads]] then, but still, they were missing some more or less important keys compared to the original SNES controller and the real "Nintendo feeling" never came up. (See, back then, USB did not exist yet. Instead, joysticks and gamepads had this [[Wikipedia:Game port|15-pin D-sub connector]] that you had to plug into your soundcard, and this ''Game port'' only permitted up to 4 buttons - an SNES controller has 8!)

Many years later, the idea struck me to program a microcontroller to interface with an original SNES controller on the one hand, and provide a standard [[Wikipedia:USB human interface device class|USB HID]] interface on the other hand, so that it could be used with any PC, any operating system and without the need for additional drivers.

The vision I had in mind was a circuit so small that I could hide it in a standard USB connector. The result would be an SNES controller with a USB plug. I did not want to modify the electronics within the controller itself so it would still be usable on a normal SNES.

= Components =
== SNES controller ==
I bought an old Super Nintendo on ebay and had a look on the controllers:

<gallery>
File:SNEScontroller_inside.jpg|the controller has standard rubber contacts like any TV remote
File:SNEScontroller_board.jpg|the board contains the contact plates and one IC
</gallery>

You can find all details on the controller's schematic, pin assignment and communication protocol on a separate page: [[SNES Controller]].

== Microcontroller ==
[[File:PIC18F2450_side.jpg|thumb|200px|PIC18F2450 microcontroller in DIL and QFN package]]
The microcontroller I chose for this project was one of the smallest PICs which has USB support: '''PIC18F2450''' with 28 pins.

For my project it offers the following advantages:
* USB 2.0 compliant
* Low Speed (1.5Mb/s) and Full Speed (12Mb/s)
* On-chip USB transceiver with on-chip voltage regulator
* On-chip pull-up resistors
* Low-power modes
* 16kB Flash memory

To program (flash) the microcontroller, one needs a programmer or debugger with In-Circuit Serial Programming (ICSP) support. There's either the official ones from [http://www.microchip.com Microchip], but since these were too expensive for this project, I chose to build my own, similar to [http://www.sprut.de/electronic/pic/brenner/index.htm#brenner5 Brenner5] from Sprut's homepage (you can find more details under [[PIC programmer]]).

== Code ==
All code files other source files can be found in the Subversion repository, hosted by [[File:googlecode_logo.gif|80px|link=https://code.google.com/p/usb-snes-controller|Google Code]]

:https://code.google.com/p/usb-snes-controller

For compiling and linking the code I use the '''MCC18''' compiler from [http://www.microchip.com Microchip]. It is available in a free evaluation version in which only a few optimizations have been disabled.

To compile the code, all that is needed is the directory <code>svn/trunk/src</code>. Edit the <code>Makefile</code> and set the correct directories there so MCC18 can be found. Then simply execute <code>make.exe</code>

The code is divided into three modules:
; main.c
: This module implements the main application logic: CPU initialization and SNES controller polling. In the central <code>while (1)</code> loop all controller buttons are polled cyclically every few milliseconds. The state of all buttons is recorded in the array <code>buttons</code>. If the state of one or more buttons changed since the last poll cycle, a new [[Wikipedia:USB_human_interface_device_class#Reports|HID report]] is generated and the ''usb.c'' module notified that the report changed.
; usb.c
: In this module all USB logic is implemented. Interrupts from USB are handled here and then processed by the appropriate <code>process_*()</code> functions, depending on what endpoint is targeted. This code contains a lot of <code>DEBUG_OUT()</code> macros which, when enabled, resolve to functions calls to ''debug.c''. These are there to help debugging and to see what is happening on the USB.
; debug.c
: In ''debug.c'' are functions for serial I/O. With a serial terminal (such as the [[LCD Terminal]]) one can see what transactions, etc. appear on the USB. When <code>DEBUG</code> is undefined (see ''debug.h'') these are all empty and don't cause any performance degradation.

= Prototype =
I created a first prototype on a hole pattern board for developing the code and easy debugging. The board layout was done with [http://www.cadsoft.de Eagle].

<gallery>
File:SNESUSB_prototype_design.png|prototype board design
File:SNESUSB_prototype.jpg|prototype on hole pattern board
</gallery>

To the left (CON3) you can see a [[Wikipedia:D-subminiature|DB-9 connector]] for connecting the controller (in the prototype I used a connector so I could easily change the controllers). The pin assignment is as follows:

{| border="1"
! DB9 pin !! wire color !! signal
|-
| 2 || red || Data
|-
| 3 || orange || Latch
|-
| 4 || yellow || Clock
|-
| 6 || white || +5V supply voltage
|-
| 8 || brown || Ground
|}

To the top (CON1) one can find the ICSP connector (In-circuit serial programming) for programming the microcontroller. This connector has the following pin assignment:

{| border="1"
! pin !! signal
|-
| 1 || +12V programming voltage (Vpp)
|-
| 2 || +5V supply voltage (Vdd)
|-
| 3 || Ground (Vss)
|-
| 4 || Data (PGD)
|-
| 5 || Clock (PGC)
|}

= Final Version =
When the experiments with the prototype were successful, I started to develop the final, miniaturized version.

All source files in Eagle format can be found in the Subversion repository in the directory <code>svn/trunk/board</code>:
:https://code.google.com/p/usb-snes-controller/source/browse/trunk/board

== Schematic ==
The board layout for the final version was done with Eagle, the first thing was to draw the schematic:
[[File:SNESUSB_schematic.png|none|300px]]

The wirepads to the left (labeled with YELLOW, ORANGE, RED, WHITE and BROWN) are the holes where the controller wires will be soldered. The wirepads labeled with PADx are solder pads where the wires for ICSP will be soldered: PAD1=PGC, PAD2=PGD, PAD3=VPP. Ground and supply voltage must always be connected through the USB connector.

USB requires a highly-accurate clock, which can only be retrieved from a crystal or a ceramic resonator. A crystal would be much too big for my small board, so I chose a '''CSTCC''' ceramic resonator from [http://www.murata.com muRata]. This has the additional advantage that it already includes the two load capacitors, which again helps to save board space.

The PIC18F2450 microcontroller is also available in a [[Wikipedia:Quad Flat No leads package|QFN]] package. Although this is quite difficult to solder (I tried several methods) it is the smallest possible alternative.

The only other external parts are two capacitors: C1 for smoothing the supply voltage and C2, which is required for USB 3.3V generation. Note that no pull-up resistors can be found in the schematic: the PIC18F2450 contains internal pull-ups for that purpose (this fact was completely omitted from the original data sheet ''39760a.pdf'', it can only be found in the errata ''80274a.pdf'')!

== PCB ==
As I said, I wanted the board to be so small that it could fit into the plug's casing. This made it quite difficult to route all signals, but in the end I succeeded:

[[File:SNESUSB_board.png|none|300px]]

The PCB layout is a double-sided layout with parts only on the top side (red), and traces on both sides, connected with vias (green). The solder pads for ICSP are on the bottom side (blue). To the right you can see five bigger holes, these are used to connect the wires of the SNES controller.

This kind of PCB is impossible to manufacture at home, so I enlisted the services of http://www.pcb-pool.com. This manufacturer also provides and Eagle rule-file, which helps you to avoid layouts that can't be manufactured. After a few days I got the results, and I can tell you, I was very satisfied:

<gallery>
File:SNESUSB_pcbpool.jpg|delivery from PCB-POOL
File:SNESUSB_board_top.jpg|final PCB, top side
File:SNESUSB_board_bottom.jpg|final PCB, bottom side
</gallery>

Soldering the parts on such a small PCB is a bit tricky, especially the QFN-packaged microcontroller. I tried several approaches, but the way that worked best was the following:
* apply solder paste to all pads - the solder resist between the pads ensures that no pads or vias get short-connected that shouldn't
* place the parts on the board, the solder paste holds them in place
* <u>carefully</u> heat up the PCB with a soldering torch (gas burner) until you see the solder paste becoming liquid

Here you can see the populated PCB with attached ICSP connector - this of course will be removed after programming:
<gallery>
File:SNESUSB_boardparts_top.jpg|populated PCB, top side
File:SNESUSB_boardparts_bottom.jpg|populated PCB, bottom side
</gallery>

== Finished Controller ==
After attaching the SNES controller, flashing the software, final tests and detaching the ICSP connector the controller is finished and ready for long gaming hours:

<gallery>
File:SNESUSB_final.jpg|SNES controller with attached USB connector
File:SNESUSB_final_play.jpg|controller in action
</gallery>

=== What is working: ===
* Hardware is running stable
* Controller draws about 18mA, heat dissipation is fine
* Controller is detected and working correctly in Windows

=== What can still be improved: ===
; Casing
: The original plan, to hide the electronics in the plug, proved to be too ambitious: The current PCB '''does''' fit into the plug's casing, but this results in the plug to become quite fragile. Furthermore, there is no strain relief on the controller cable any more, so any pull on the cable could cause the wires to be severed from the PCB. Also the current PCB is very dependent on one specific plug casing, which might be a problem if that casing is not available any more.
: A better solution would be to separate the electronics a few centimeters from the plug in its own casing (I got this idea from my USB headset). The problem there is that I would have to find a suitable casing.

; Solution for damaged ceramic resonators
: In some of my PCBs the ceramic resonator stopped working for some reason. The microcontroller runs fine with its internal oscillator, but does not run when switched to the external resonator. I can only assume the resonator is sensitive to heat changes and gets damaged in my solder process. Maybe improving that with a hot-air soldering torch could help.

; Pass USB compliance tests
: The USB Implementer's Forum provides a free compliance testing toolkit called '''USB Command Verifier''' (USB20CV), obtainable from http://www.usb.org/developers/tools/. USB20CV is the compliance test tool which evaluates High, Full and Low-speed USB devices for conformance to the USB Device Framework (Chapter 9), Hub device class (Chapter 11), HID class, and OTG specifications. Also included are mass storage class and USB video class specification tests. All USB peripherals are required to pass the Device Framework tests in order to gain certification.
: In first experiments, most of these tests failed. I guess this is due to mode switch commands, etc., that are not implemented (or only implemented as stubs). However it should be possible with minimal effort to get these running.

; Implement USB low-power modes
: When the PC enters suspended state where the USB is still powered, any USB device that is not configured for wakeup must also put itself into suspended state and use only a minimum amount of electric power.
: We could achieve this with several methods, for one we can disable power supply to the SNES controller (which saves about 4.2mA). We could also power down the microcontroller, or activate whatever power-saving possibilities the PIC has to offer.

; Support for [[Wikipedia:Nintendo Entertainment System|NES]] controllers
: The communication protocol of an NES controller is identical to a SNES controller (if I remember correctly). So with some luck it should already work, but due to the lack of a controller for testing, I can't say for sure.

[[Category:Electronics]]