Wattmon firmware part 2

In the last post I described part of the workings of the os. I will now briefly go over the communication aspect.

Any modular system needs to be able to interact with its components reliably. Rather than reinventing the wheel I decided to use an industry standard that is still widely used today: Modbus RTU. I came to this conclusion after looking at many protocols, uLan being the runner up.  The downside of uLan is that it is 9 bit which makes it difficult to work with when interacting with a pc. I used it on my previous ebike management system and it is a pretty cool protocol, allowing multi-master communications. 
I decided on an IEE-485 bus which supports multiple nodes over a twisted pair cable. One of my requirements for the devices on the bus was that they should be powered by the master, making it very easy to install. Therefore, an RJ45 socket was used, where power (5v and gnd) are provided in addition to d+ and d-. A 500 mA resettable fuse on the wattmon box assures safety to the power section.
Modbus devices are described to wattmon through device description files, which are ini files with a fixed format.  New devices which are wattmon compliant can be automatically detected with a scan, whereas non-wattmon modbus devices need to be manually added to the main device.ini file after which they will be picked up by the polling engine.  The wattmon polled will automatically poll each modbus device at a predefined interval and update internal registers for the scripting engine to use.
In addition to the modbus port, I included a cc1100 wireless 433mhz transceiver  which runs a custom protocol. I looked at various existing protocols but found none that does exactly what I want. Devices need to be connected reliably, which means that a stack with transmission control was required.  I also wanted to be able to transmit different types of data, from short request-reply data such as an encapsulated modbus packet, to a type of stream that could be used to update remote display devices. This is not yet implemented fully but will probably use bencoded data which is currently used in the BitTorrent network.
An onboard serial port is also available for debugging or can also be accessed via a 3-pin header and connected to external devices.  All serial i/o can be controller through file operations in uPHP such as fopen, fread, fwrite and fclose.
More to come...


Comments | Add yours
  • No comments found
Add comment