So I got back to Carnegie Mellon University Sunday afternoon and it dawned on me that my schedule for this semester sure is hectic(61 units)(schedule can be found here ). I hope I still have time for alot of cool projects . Progress on WCTU is coming along slower than I had hoped because for lack of better terms the two students I am “working with” lack motivation. This has left me to implement their sub-systems but hey I guess more experience for me right? Now that I am back on campus focus will shift for refining the (now usable) client code and dummy device to designing and fabricating a real device.
Originally I had planned on making two versions of the device. One powered by an ATMEGA(low cost) and one powered by an Overo Air Com(high cost). Due to time constraints focus will be placed on developing the Overo version because it has wireless built in as opposed to having to interface the ATMEGA with the MRF24WB0MA. Furthermore since the Overo is an embedded linux environment code development and debugging is easier. The ATMEGA version will still be created, just at a later time.
The last thing I will comment on it the protocol used to transmit data. At first, I had hoped to use a UDP connection to connect the client to the device. Since web browsers can only communicate over TCP(unless I used a intermediate TCP to UDP server) UDP was ruled out. Having decided to use TCP, it made sense to then look into the incorporation of websockets. After researching the topic, it turned out websockets would reduce the amount of data the client would have to send to the device as well as reduce latency. Therefore, it was decided a websocket TCP connection would be used however what would be transmitted still remained in question.
Originally I had thought of sending data in fixed positions in the transmitted string but that would not be dynamic. Next, I decided to implement a communication system where a “command string” was placed at the beginning of the main string and its paramaters would follow separated by spaces. This proved to work out well because the messages were easy to construct, understand, and were somewhat dynamic. Messages could be of variable size and based upon whether the client or device was sending the message, what the message type was, and the number of parameters different actions would be performed. This system is still not fully dynamic though because the client and device have a preprogrammed contract built into them where the client assumes the device has one input and output channel as well as what voltage, frequency, etc it can read or output. Currently, I am working on an initialization system where the device will communicate to the client upon connection what channels it has, their parameter limits, etc.
Also, originally the only two values the client could request was battery voltage and output waveform settings. The input waveform and output waveform were sent to the client by default. This design was inefficient because if the client was not displaying the waveforms, the data would still be sent. The new API is highly simple and flexible. Once the client connects to the device it receives a battery voltage and output waveform settings message. Whenever any of these two values are changed, the device automatically sends out the updated values to all connected clients. There are two methods
void setInputWaveform(boolean value) and
void setOutputWaveform(boolean value) which each set whether or not the device will send data to that particular client.
void SetOutputWaveform(string type,int voltage,int frequency,int offset,int pwm) unlike the previous two methods is device specific not client specific. When a client changes the output waveform, that change applies to all clients.
The beauty of the API is in the callback function though. The user upon connecting to the device through DeviceManager sets a callback function with the parameters (int deviceId,string type,string params) that is called whenever the client receives a message from any device. This method allows the user/designer to customize the API to perform specific actions upon receiving certain messages.
Here is the github repository but be warned the code is largely in flux right now and if you pull the repository the documentation may be out of date and/or the code may be broken. Also, the c_interface is currently halted as the python_interface is easier to prototype with(python interface is the one you want to check out).