Implementation‎ > ‎

Wireless Sensor Network

The Wireless Sensor Network



The wireless sensor network consists of 20 temperature sensors and 4 Bluetooth enabled Gumstix in total. This will be partitioned to assign 5 individual temperature sensors to each Gumstix device.  This is due to the Gumstix having a maximum capacity of 5 sensors connected to it at one time. These will be wired to the Gumstix to ensure good connectivity.

 

Reasons for the temperature sensors being wired are that this allows a more trustworthy, cheap and simple form of connectivity. If the sensors were wirelessly connected to the Gumstix then this would throw up a great deal of problems. There would be the problem of having to power each sensor and that of battery life. This would require the user to constantly keep replacing the batteries (or recharging) each sensor and would be very costly, awkward and time consuming. Mains power would not be a solution as that would require wires, meaning that the whole point of making the sensors “wireless” would be lost. Another reason not to make the sensors wireless is the amount of airborne traffic this would create. This would cause lots of interference and wireless network problems, with each individual sensors broadcasting its findings constantly. It would also add a lot of overhead in terms of the time it takes to send a temperature reading and also synchronisation issues concerning when all of the individual temperature readings are received by a particular Gumstix node.


Having wired sensors in this case are not a problem (in fact, due to the reasons listed above, it is an advantage) as the wires can be kept neatly out of the way with cable ties. For the in lab demonstration, the wires that connect each sensor to the Gumstix are relatively short and therefore do not allow much flexibility as to where they would be placed. If we were to go into manufacturing of our system, the length of these wires would be greatly increased, allowing for a wider spread of sensor placement and therefore a greater covering of temperature knowledge.


Gumstix


It was decided not to do any of the processing on the Gumstix devices as this could cause a slowdown in processing the data. Also, if the data is only sent out in a raw form then the base station has greater scope of what it can do with it, whereas if it was received in a processed form, parts of information concerning it could be lost. This helps in terms of extending the system at a later date, as only the base station code would need to be changed (assuming no different types of sensors needed to be added).

Each Gumstix uses a python configuration file to get its setup parameters. These include the address and port of the base station that it will be sending to. The id of the Gumstix is also defined as a parameter, allowing the base station knowledge of which Gumstix is attempting to communicate with it.

The key parameter is a timeframe interval (in seconds) that each Gumstix will collect and send out temperature data. This allows the temperature data to be sent at regular intervals. Due to it being a configuration parameter rather than hard coded into the system, this enables the user the ability to change the interval between which new temperature data is broadcast be the system.

For our demonstration, it was chosen to use an interval of one second to show it was working, rather than having to wait half an hour or so (as would most likely be what the user would set the time lapse to in everyday use of the system) for every update.

 

It was chosen to use UDP as the protocol in which to send the data as this allowed for very little overhead. It was not vital to know whether the packets had been received by the base station so the choice not to use TCP was for this reason.

If the system is to be expanded in the future to be large enough where packet loss becomes an issue then the system could easily be changed over to TCP in order to deal with this problem. However at the present time, UPD more than suites the needs of the project and requires less overhead and therefore is the better solution.

 

The sent UDP packet contains a string of data of the following format:

 

NODE; nodeID

TIME; timestamp

SENSOR; senseID ; tempVal

SENSOR; senseID ; tempVal

SENSOR; senseID ; tempVal

SENSOR; senseID ; tempVal

SENSOR; senseID ; tempVal

 

Where:

  • nodeID is the id of the gumstix, defined in its configuration file.
  • timestamp is the current time and date
  • senseID is the id of the sensor relative to that particular node. Sensors are by default numbered 0 to 4.
  • tempVal is the temperature value currently read from the temperature sensor

 

This format has been chosen as it does not process the information in any way but instead sends it in a clear manner that both easily readable for the base station machine its self (for in use of the system) and also human readable, to help with debugging.

Comments