Defcon Kaklkaklkekl (Wiki)

====== 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. ==== Firmware releases ==== The firmware code is heavily limited by the fact that it is limited my Microchip's licensing. This means, you may only "use, modify, copy and distribute" the Microchip code "when embedded on a Microchip microcontroller [...]". My code however, you are free to use under a four-clause BSD license, as long as you filter the Microchip code away :P Firmware version 1.0 is available! * Want to hack, or add it to your own PIC-MINI-WEB?: {{:projects:tempdude-firmware-1.0.zip}} * A known bug exists: the destination port number is fixed at 13579. Config does work for IP but not port. ==== System configuration operation ==== The following considers how the device operates in regard to configuration. Device-server communication is commented in a separate section.. === Hardware configuration process === The device should support reprogramming of default IP-address and MAC address, and this should be possible using a network connection. The method for doing this has not yet been implemented, but previous ideas have been scrapped due to complexity. === Normal boot === On a normal boot, the device reads its MAC address data from EEPROM. It then attempts DHCP configuration of IP address. The device starts reading connected sensors, and sends data using LEMP1 (documented separately). The device will also respond to ICMP PING. === Configuration after normal boot === The configurable options in normal operation are the destination IP address and port number of LEMP1 operation. Device IP address is assigned over DHCP during boot. Device configuration is done using the UDPSet configuration tool, or a compatible tool. * Configuration is initiated from the device, by pressing Button 0. * When the button is pressed, LED0 is turned off, the device sends out an UDP packet using broadcast to port 13580 containing the byte-pattern '0xFE8001'. * The device starts listening for a configuration packet sent to the device using UDP to port 13580. Packet contents are: * Config packet cookie, 0x4040 * Server destination IP address as four bytes, highest octet fist, lowest octet last (e.g. the address 10.0.255.1 is sendt as 0x0A 0x00 0xFF 0x01) * Server destination port number, highest byte first ( e.g. 13579 is sendt as 0x350B) * The terminating byte 0x3B * Upon receiving a valid packet, the device sends an ACK package on the form '0x404006'. * The device applies the recieved parameters, and sends a final summary of used settings, replicating the config packet, but using '0x2020' as magic cookie, and '0x06' as terminating byte. (e.g. a summary of server setting 10.0.255.1:13579 is acked as '0x20200A00FF01350B06'). * If a config packet is not received after waiting for 30 seconds, the device times out, LED0 is turned on, and operation resumes. === Configuration tool === A configuration tool other than UDPSet may be written and used according to the previous description. The tool is to listen for UDP broadcast on port 13580. Configuration is to be sent after receiving Config REQ '0xFE8001'. Configuration is prepended by the sequence 0x4040, then the four IP quads as separate bytes, leftmost byte first, next the port number as two bytes, MSB first, and finally the terminating byte '0x3B'. The device will respond with a Config ACK on the form '0x404006', and an echo of the config, with lead-in replaced by 0x2020 and lead-out replaced with 0x06. UDPSet is a really simple Qt4 application, with a basic dialog GUI. This interface lets you enter the IP address and port number of your LEMP1 server that the device is to send data to. The 'Send config' button is inactive until the Config Req magic cookie is received. Upon receiving the Config REQ the 'Send config' button is activated and the config may be sent. Note that the device times out waiting for config after 30 seconds. Download of UDPSet versions: * {{:projects:tempdude-udpset-0.2.tar.gz}} ==== LEMP1 ==== Writeup of the LEMP1 protocol is still a todo. BUT, a software-based reference implementation exists as tempsend.c, available here: {{:projects:tempsend.c.txt}} Compile tempsend using e.g. gcc tempsend.c -o tempsend Command syntax for tempsend is: <code> -s <ip of LEMP server> -p <portnumber of LEMP server> -i <node id> Node ID is five bytes, written as hexadecimal digits. Software Node ID _should_ start with 01, and the last byte should be a sensor index. i.e. 01 for a single sensor system. Example of valid Node ID string: 0100FF0201 -v <value as float> The value is parsed from string to double, and should be within the range 155.0 to -55.0 </code> To give an example command, let's send -14.5 degrees centigrade to a LEMP1 server running at 10.0.3.4 port 13579 (default port) using 0x0102030401 as sensor id: tempsend -s 10.0.3.4 -p 13579 -i 0102030401 -v -14.5 A node about sensor ID's: ID's are typically locally significant to the LEMP server you are reporting to, but the following guideline should be followed: * The sensor ID is to be built up of * one byte manufacturer ID, using 0x01 for software agents. * Three bytes Node ID * One byte sensor index * The first byte should always be 0x01 for software sensors. * The next three bytes should be locally unique for each monitoring station * The last byte should be a sensor index for sensors attached to the monitoring station. So, having a monitoring station with five sensors, reporting using software agent, the sensor ID's can be something like 0100FF0201 0100FF0202 0100FF0203 0100FF0204 0100FF0205 where 00FF02 is the "unique" Node ID. ===== 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 * **bought** PIC-MINI-WEB http://www.sparkfun.com/commerce/product_info.php?products_id=7829 * **bought** PIC-PG1 http://www.sparkfun.com/commerce/product_info.php?products_id=9 * Did not need this one.. * PIC-ICSP http://www.sparkfun.com/commerce/product_info.php?products_id=8108 * Not compatible :( * **borrowed** Microlab IDC2 http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046 * **bought** PIC-ICD2 http://olimex.com/dev/pic-icd2.html * **boughtx4** DS18B20 tempsensor http://www.sparkfun.com/commerce/product_info.php?products_id=245 * **done** Get development software for the Microchip-side of development * **v7.6** Microchip MPLAB IDE http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 * **MC18** compilers from Microchip. * **done** Get familiar with hardware and development platform * **done** Reprogram the device with stock program- and flash content * **done** Remove unwanted components from program. Test programming of stripped code. * **done** Implement reading of a single attached temperature sensor * **done** Implement proof-of-concept LEMP1 server * **done** Add simple LEMP1 implementation * **done** Add DHCP client. Program device and verify DHCP operation. * **done** Implement reading of multiple sensors * **done** Verify that reload of stock software works * **done** Figure out how to read/write EEPROM, store and retrieve data on EEPROM * **done** Verify that reload of stock software works * Implement LEMP1 server with data storage. * WIP: Has proof of concept running, C-code dumping to file, perl-code dumping file to db * Design interface/connector-board * Build and QA interface-board * Create encapsulation for the device.