Defcon Kaklkaklkekl (Wiki)

**This is an old revision of the document!** ----

====== TEMPDude ====== - **Project to create an easy-to-deploy Ethernet enabled temperature sensor**. ===== Concept ===== Most reasonably-priced solutions for network enabled, computerized temperature logging involves connecting a simple temperature sensor directly to a computer, most commonly to a serial port. To centralize temperature logging, software is used on the computer to either read multiple such sensors attached to the computer, or read one or more locally attached sensors, and sending the data off to a central server of some kind. Porblems with this approach is that a complete computer is needed at each location where temperatures are to be logged, and most commonly at least two levels of software are deployed; the sensor reading part, and the logging server. The alternative to this approach is to use industry- or datacenter-grade temperature logging systems. This commonly involves a device that sensors are connected to, that in turn is connected to an Ethernet. These solutions are normally SNMP based, thus they are normally polled for data, and only transmit data when a preset alarm condition is triggered. The transmit of data is the commonly sent as an SNMP trap and/or an email alert. Problems with this approach may include: a normal household internet connection is typically behind a NAT that has its global IP assigned using DHCP, and such it will be troublesome to poll a device from a central logging service using SNMP. The devices are also typically not what can be called reasonably priced. What I want to accomplish is a solution where a central logging service is set us as the only user-installed software component, and fairly low-priced Ethernet-enabled temperature logging devices are deployed onto a DHCP-enabled network, where they immediately start reading attached temperature sensors, and actively sending the logged data to the logging service. ==== Feature outline ==== The following are set as feature-goals: * deployment of device as easy as plugging into power and DHCP-enabled ethernet * each should be able to monitor/read one to four (or eight) connected sensors * each device should have a cost below $75 * well documented set-up and configuration * cross-platform toolkit for setting up * cross-platform logging server (service) * no, or few, NAT issues (port forwarding may be needed on the server-side) * based on "reference architecture" components * lightweight data storage; RRD or SQLite most probable. ===== System architecture ===== After looking around at various embedded hardware platforms that give a combination of Ethernet connectivity and general purpose I/O, the following options were what I came up with: * Embedded computer platform, e.g. Gumstix, PC104 or simmilar. Previously I have developed a gumstick based device that does the same job, but that came at a hefty price: ~$180 per node. Looking at embedded computer alternatives, this is still pretty much the case. * Ethernet-to-RS232 device. This approach cut the cost, but I was unable to find a device that would provide enough features without becoming bulky, and also becoming a custom job * Arduino-based. There exists solutions that make the Arduino series of devices ethernet enabled. These allow a reference architecture basis for the project, but does not cut the cost low enough. * Microhip PIC TCP/IP stack based. The [[http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2505&param=en535724|Microchip TCP/IP stack]] is indeed a reference arhitecture, and there also exists reference implementations of the hardware. Striking "gold" with this approach, I fould that Olimex has development boards that implements the architecture and the stack, at a cost well below my "high-water" price-mark. So the hardware platform that I have selected for this project, is the Microchip reference architecture for their TCP/IP stack, implemented in the first iteration on [[http://www.olimex.com/dev/|Olimex]] PIC-*WEB series devices. {{ notater:pic-mini-web.jpg?200 }} The software platform is to be based on the Microchip TCP/IP stack on the device. The first edition of the server-side software will be a simple TCP server written for GNU/Linux. ==== System configuration operation ==== The following are ideas on how the device should operate in regard to configuration. Device-server communication is commented in a separate section.. === Determine configuration status === After programming the device should read a byte of configuration data from EEPROM (opconfig). The configuration will contain a flag indicating whether the device is in an "unconfigured" state or not. === Configuration mode === If the device is unconfigured, it should use a MAC-address stored in program memory, and stop in an IP gleaning phase. Setting the IP-address of the device using an ARP directed PING should set the device ready for base configuration, where the device starts listening on a given TCP port (4919 decimal , 0x1337 hex). === Configuration process === Configuration is the done by connecting to the configration port. The device will on connection respond "START\n". The connecting part starts configuration by sending a predefined identification byte (0x13), followed by the three last bytes of the desired MAC adress for the device, followed by a software version byte, and the predefined identification byte (0x13). The device reads the leading byte to decide whether the conenction is a configuration request, continues to read the MAC and version data, and upon reciept of the terminating byte verifies valid data, and stores the four bytes to EEPROM. The "unconfigured" flag is removed, before the device sends the string "OK\n" over the TCP connection. It will then continue to listen. The connected party should then send another predefined identifier byte (0x37), followed by four bytes representing an IP address, and two bytes representing a port number, terminated by the next identifier again (0x37). The device should recieve these data, verify validity, store them as the default values for logging server address in eeprom, and ack by sending "OK\nEND\n". The device will then close the connection, reset itself (reboot), and boot up as a configured device. === Normal boot === On a configured boot, the device will read its MAC address data from EEPROM. It will then attempt DHCP configuration of IP address. After DHCP configuration is complete, the device will start reading connected sensors, and sending data to the IP address and port configured in EEPROM using TCP. The device will also respond to ICMP PING, and will be listening for incoming connections on the configuration port (4919). === Configuration after normal boot === The device will after a normal boot be listening for incoming connections on the configuration port (4919). Upon connection to the configuration port, the configured device will respond "OK\n", and start waiting for an identifying byte. The connected part should then send the identifier for setting the server IP and port (0x37) followed by the six configuration bytes, and the terminating byte. The device should recieve these data, verify validity, store them as the default values for logging server address in eeprom, and ack by sending "OK\nEND\n". The device will then close the connection, and reboot. Alternatively, the identifying byte sent may be 0x23, followed by 0x42, and a byte to store into the opconfig byte of the EEPROM. These bytes indicate a "clear configuration, set opconfig" request. Upon receipt of these, the device should set its configuration byte to the recieved opconfig byre, clear the first bit, thus entering the unconfigured state, send "RESET\nOK\n", close the connection, and reset. This command sequence should be included during development, but disabled in normal operation. "Factory" initialization of the device will do this by setting an appropriate opconfig byte. === Structure of opconfig byte === The opconfig byte stored in EEPROM contains the following flags, LSB first: 1. Configured, HIGH if configured, LOW if unconfigured 2. TCP reset, HIGH if 0x2342 is allowed, LOW if disabled 3. Heartbeat enable, HIGH if onboard LED should blink on data transmit, LOW if visual indicator is disabled 4. Switch function, HIGH if onboard switch causes an immediate send of data, LOW if switch causes a reset to unconfigured. 5. Reset denies 0x2342. Determines if bit 2 is set HIGH or LOW on a hardware reset, when bit 4 is set LOW. HIGH sets bit 2 LOW. The upper 3 bits are currently unused. === Configuration tool === The described processes above are to be seen as a protocol description, and not steps that are to be manually performed. As part of the toolset for the device, a configuration tool will be developed, that performs the configuration of the device automatically. Wether this tool will be a GUI tool, or a plain command line tool is not yet decided, but the tool will include functionallity to configure both unconfigured and configured devices. Most likely, a GUI tool will be developed. Attached is a mockup of how the tool may look.. {{ notater:tempdudeconfig.png }} ===== Development roadmap ===== This section will be updated as I get more experience with the tools used, and as I decide on how to progress. Se below for progress... * **done** Get hardware * PIC-MINI-WEB http://www.sparkfun.com/commerce/product_info.php?products_id=7829 * PIC-PG1 http://www.sparkfun.com/commerce/product_info.php?products_id=9 * PIC-ICSP http://www.sparkfun.com/commerce/product_info.php?products_id=8108 * Microlab IDC2 http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046 * DS18B20 tempsensor http://www.sparkfun.com/commerce/product_info.php?products_id=245 * **done** Get development software for the Microchip-side of development * Microchip MPLAB IDE http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 * compilers from Microchip. * **done** Get fammiliar with hardware and development platform * **done** Reprogram the device with stock program- and flash content * Remove unwanted components from program. Test programming of stripped code. * Add DHCP client. Program device and verify DHCP operation. * Add simple TCP client, program and verify * Verify that reload of stock software works * Figure out how to read/write EEPROM, store and retrieve data on EEPROM * Verify that reload of stock software works * Add TCP Server component that accepts connection, reads data and terminates. * Implement 0x37 configuration * Implement IP Gleaning * Implement IP Gleaning, 0x13 and 0x37 operation * Implement reset-on-switch * Implement 0x2342 operation * Implement simple TCP client app sending dummy data * Add heartbeat LED * Implement reading of a single attached temperature sensor * Implement reading of multiple sensors ===== Progress =====