====== Sitemap ====== This is a sitemap over all available pages ordered by [[doku>namespaces|namespaces]].
Page Actions
Wiki Actions
User Actions
====== Differences ====== This shows you the differences between two versions of the page.
|
projects:tempdude [2009/12/31 18:10] fishy No longer using TCP. NAT at sensing locations is not an issue with sending UDP.. |
projects:tempdude [2010/02/03 22:34] (current) fishy |
||
|---|---|---|---|
| Line 8: | Line 8: | ||
| 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. | 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 ==== | ==== Feature outline ==== | ||
| Line 19: | Line 18: | ||
| * cross-platform toolkit for setting up | * cross-platform toolkit for setting up | ||
| * cross-platform logging server (service) | * cross-platform logging server (service) | ||
| - | * no NAT issues (that's why I am planning on using TCP...) | + | * no, or few, NAT issues (port forwarding may be needed on the server-side) |
| * based on "reference architecture" components | * based on "reference architecture" components | ||
| * lightweight data storage; RRD or SQLite most probable. | * lightweight data storage; RRD or SQLite most probable. | ||
| - | |||
| - | |||
| ===== System architecture ===== | ===== System architecture ===== | ||
| Line 39: | Line 36: | ||
| 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. | 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 ==== | + | ==== Firmware releases ==== |
| - | The following are ideas on how the device should operate in regard to configuration. Device-server communication is commented in a separate section.. | + | 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 | ||
| - | === Determine configuration status === | + | 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. | ||
| - | 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. | + | ==== System configuration operation ==== |
| - | + | ||
| - | === 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). | + | The following considers how the device operates in regard to configuration. |
| + | Device-server communication is commented in a separate section.. | ||
| - | === Configuration process === | + | === Hardware 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. | + | 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 === | === 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). | + | 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 === | === 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. | + | 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. |
| - | 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. | + | Device configuration is done using the UDPSet configuration tool, or a compatible tool. |
| - | This command sequence should be included during development, but disabled in normal operation. "Factory" initialization of the device will do this | + | * Configuration is initiated from the device, by pressing Button 0. |
| - | by setting an appropriate opconfig byte. | + | * 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. | ||
| - | === Structure of opconfig byte === | + | === Configuration tool === |
| - | The opconfig byte stored in EEPROM contains the following flags, LSB first: | + | 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. |
| - | 1. Configured, HIGH if configured, LOW if unconfigured | + | 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 |
| - | 2. TCP reset, HIGH if 0x2342 is allowed, LOW if disabled | + | Config REQ the 'Send config' button is activated and the config may be sent. |
| - | 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. | + | Note that the device times out waiting for config after 30 seconds. |
| - | === Configuration tool === | + | Download of UDPSet versions: |
| + | * {{:projects:tempdude-udpset-0.2.tar.gz}} | ||
| + | ==== LEMP1 ==== | ||
| - | 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. | + | 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}} | ||
| - | Most likely, a GUI tool will be developed. Attached is a mockup of how the tool may look.. | + | Compile tempsend using e.g. |
| - | {{ notater:tempdudeconfig.png }} | + | 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 ===== | ===== Development roadmap ===== | ||
| Line 94: | Line 146: | ||
| * **done** Get hardware | * **done** Get hardware | ||
| - | * PIC-MINI-WEB http://www.sparkfun.com/commerce/product_info.php?products_id=7829 | + | * **bought** 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 | + | * **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 | * 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 | + | * Not compatible :( |
| - | * DS18B20 tempsensor http://www.sparkfun.com/commerce/product_info.php?products_id=245 | + | * **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 | * **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 | + | * **v7.6** Microchip MPLAB IDE http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 |
| - | * compilers from Microchip. | + | * **MC18** compilers from Microchip. |
| - | * **done** Get fammiliar with hardware and development platform | + | * **done** Get familiar with hardware and development platform |
| * **done** Reprogram the device with stock program- and flash content | * **done** Reprogram the device with stock program- and flash content | ||
| - | * Remove unwanted components from program. Test programming of stripped code. | + | * **done** Remove unwanted components from program. Test programming of stripped code. |
| - | * Add DHCP client. Program device and verify DHCP operation. | + | * **done** Implement reading of a single attached temperature sensor |
| - | * Add simple TCP client, program and verify | + | * **done** Implement proof-of-concept LEMP1 server |
| - | * Verify that reload of stock software works | + | * **done** Add simple LEMP1 implementation |
| - | * Figure out how to read/write EEPROM, store and retrieve data on EEPROM | + | * **done** Add DHCP client. Program device and verify DHCP operation. |
| - | * Verify that reload of stock software works | + | * **done** Implement reading of multiple sensors |
| - | * Add TCP Server component that accepts connection, reads data and terminates. | + | * **done** Verify that reload of stock software works |
| - | * Implement 0x37 configuration | + | * **done** Figure out how to read/write EEPROM, store and retrieve data on EEPROM |
| - | * Implement IP Gleaning | + | * **done** Verify that reload of stock software works |
| - | * Implement IP Gleaning, 0x13 and 0x37 operation | + | * Implement LEMP1 server with data storage. |
| - | * Implement reset-on-switch | + | * WIP: Has proof of concept running, C-code dumping to file, perl-code dumping file to db |
| - | * Implement 0x2342 operation | + | * Design interface/connector-board |
| - | * Implement simple TCP client app sending dummy data | + | * Build and QA interface-board |
| - | * Add heartbeat LED | + | * Create encapsulation for the device. |
| - | * Implement reading of a single attached temperature sensor | + | |
| - | * Implement reading of multiple sensors | + | |
| - | + | ||
| - | ===== Progress ===== | + | |