I write software for various hardware devices. Finding bugs, and resolving them is usually relatively easy if the issue can be replicated in a test environment with development hardware and full logging equipment setup. The problem however is when:
It is equipment using GSM, making use of various different phone networks, and cell towers that can not be easily replicated.
The issue only occurs on location in the field (i.e. live customers using the device).
It is an intermittent issue that can not be replicated on cue, ruling out simply going to the location for an hour setting up the relevant equipment and logging the issue.
Devices are in locations where it not particularly convenient / safe to setup and leave expensive testing equipment / laptops etc.
Testing equipment needs to run a Windows only application from a hardware manufacturer that needs “babysitting” (restarting if it stops logging).
I recently faced this issue. I tried a few options including blindly guessing at what the issue could be and implementing fixes for various possible issues, next tried working with the network operator (which got nowhere). Final solution I came up with was to build some custom / cheap (in comparison to the alternative) logging hardware to take the place of the hardware development board, Windows running laptop, hardware manufacturers software tool.
My first thoughts were that this could be done by using an Arduino with an SD Card data logging “shield” however after some further research I discovered the Spark Fun OpenLog. The OpenLog was a perfect fit since it:
Can be powered from 3.3V – 12V (could just piggy back it on the existing devices power supply).
Serial levels compatible with 2.8V CMOS levels of device.
Already setup to automatically log serial data to files on an SD Card.
Open source firmware that is freely available, meaning I could customise it to emulate the manufacturers software tool (eliminating the need for the extra hardware, and meaning I could deal with the reliability issues).
Development environment (see section “Compile Version 2″) that is simple / relatively straight forward to obtain / setup / use (Ardino IDE – even though it is not “Arduino” branded hardware as such).
Supports upto 16GB microSD cards (device outputs large logs).
There were a few steps involved in the process including, connecting the OpenLog to the device, building a programming cable for the OpenLog, and customising the OpenLog software to emulate the initialisation string of the Windows software tool.
I have never coded AVR C before however found it relatively straight forward to make the modifications I required to emulate the initialisation string of the Windows tool (primarily logging the string with Eltima Software’s Serial Port Monitor application, saving the data to a file on the SD Card and instructing OpenLog to read it back over the serial port, then drop back into logging mode.
A few issues I encountered along the way were:
OpenLog stops reading files if it encounters a NULL byte, however this should be fixed in the latest release.
Error trying to upload new software from the Arduino IDE to OpenLog due to the DTR pin needing to be connected to OpenLog to reset it just before programming. I substituted DTR for RTS (which my FTDI cable did have broken out).
Device I was logging data to was outputting [CTRL]+[Z] 3 times – the OpenLog escape sequence – I therefore modified the escape sequence to be 9 times rather than just 3.
Solder a x4 way header connector onto the logger GND, VCC, TXO, RXI (i.e. miss out the first pin labelled BLK, it is not required).
Solder a x1 way header connector onto the logger for the GRN pin (I used a 2 way with the other pin overlapping off the end of the board as I could not easily obtain a 1 pin)
Solder a x4 way housing connector onto the wires from the device (match up GND/VCC/TXO/RXI to appropriate pins on the device).
Note: A 5 or 6 way header soldered to all logger pins could just be used but I thought this approach best to avoid any mistakes (broken loggers) – that way there is a x4 way header to use when plugging into the printer and you are not left wondering which 4 pins should be connected.
FTDI Programming Cable
Modify the FTDI cable such that it has the following pinout (compatible with logger). Use a flat screw driver to release the pins from the existing socket.
GND
Black
VCC
Red
RXD
Yellow
TXD
Orange
RTS
Green
CTS
Brown – N/C
Notes
Arduino needs to be modified with a special version of HardwareSerial.cpp to work with OpenLog.
If your SD Card did not come pre formatted you may need to use the FAT32 microSD optimised formatting tool from SD Association.
I recently got round to completing a central heating / hot water automation project I had been meaning to do for a few years but previously issues over cabling, heat (i.e. possible damage to electronics), hardware choice, and various other installation issues had caused me not to do it until now.
Features:
Two channel (heating and hot water) support.
Temporary Override (ignore schedule for 30 min – 1 day), both overriding on, but also off.
Permanent Override (ignore schedule).
Web based interface for changing schedule / override settings.
Schedule support for any combination of weekdays.
Schedule support for one off custom schedules on specific dates only.
Setting date/time via NTP (with automatic support for time zones, and daylight savings – built into Linux server).
Support for override control via Cisco 7960 phones (already located around house / managed by Asterisk).
Wireless from control unit to programmer (linked to network).
Self contained system – does not require separate PC server running 24/7.
Hardware
In terms of hardware the system is comprised of:
A relay box containing two opto-isolated 230V 3A relays with CMOS level control.
A control box with Synapse RF Engine installed in Synapse Evaluation board connected to several lights/switches allowing for local control over on/off, override settings, and visual indication of on/off status (evaluation board is connected directly to relay box).
An ACME System Fox G20 Board (Atmel ARM processor, running Debian Linux), linked to another Synapse RF Engine, the controller behind the whole system, connected to wired network.
I chose to install the relay box it in parallel with the existing timer clock. During normal use the existing timer will be turned to its ‘permanent override: off’ setting, this means that if the custom system were to fail it’s a simple case of powering it down, and going back to using the regular programmer.
Relay Box
In terms of mounting the relay PCB in the box I chose to use to use some nuts and bolts, hot gluing the bolt to the base. I also put some small rubber feet on the board to keep it more secure. This allows the relay board to still be removed from the box if required at a later stage.
I secured cables going into the boxes with cable ties (one on the outside and one on the inside), not the most professional solution but having used various cable grips before none of which seemed particularly secure (prone to popping out again), and being time consuming to fit therefore this time I opted for a simpler solution.
Control Box
The control box had limited space this meant things fit nicely without moving but I also used some stick on cable holders to hold the PCB steady, and placed a blank PCB in the box to separate the switches from the Synapse Evaluation board preventing the possibility of shorts.
I used a standard labeller with stick on labels for marking controls on the box, this did not lead to as professional a finish as I would have liked however I could not immediately think of a better options without paying out for a possibly costly custom enclosure.
In terms of wiring in the control box, it is fairly straight forward, a TS7809 [pinouts] to regulate the 12V PSU to 9V, switches connected directly from ground to GPIO pins (for pinouts see Python file), LEDs each connected to GPIOs via transistors [wiring diagram].
Software
Fox G20
The Fox G20 runs a PHP schedule application which sends signals to the control box LEDs / relays, and also receives button press events for override support. It does this via a serial / wireless link (using Synapse modules) to the control box.
The Fox G20 was chosen since it offers (in software terms) something very similar to a regular Linux PC – support for web server, PHP, Cron jobs, RTC (with backup battery), serial ports, Ethernet, hard drive (memory card) all in a small form factor (web server, PHP, cron support were even already installed on the purchased memory card), meaning that time consuming / fiddly cross compiling etc was not required as they might with other hardware.
Getting the Fox G20 out of the box I was immediately very impressed with it and was able to get up and running within minutes, only thing that was not immediately clear was the root password (netusg20) but this was quickly located after a search of the wiki.
The Python script on the Synapse RF Engine mounted in the control box is responsible for sending out message over wireless serial when buttons are pressed, and processing messages turning them into GPIO on/off events to control the relays/LEDs.
A few of the decisions to build my own system include:
Cost of commercial solution.
Easily extendable as required (ability to just code new features in PHP).
Support for control via Cisco 7960 phones (at any location in the house) – phones that support XML browser via “services” menu.
Implementation of all existing features of current system easing user adoption (for other members of the household).
Ability to make system wireless, but also separate from existing servers (independent system).
Network support for NTP / timezones / daylight savings time.
Key components that may be damaged by heat (unavoidable due to location) easily replaceable (e.g. just slot in new Synapse Module, purchase new power adapter).
Easy to make remotely accessible (just code authentication support).
Implementation Notes
PHP was not particularly designed to be used as a long running process (which is how it is necessarily used on the Fox G20 to receive data from the serial port. For that reason I wrote a separate script called by Cron to check it is running, or if not start it back up again. This causes a slight usability issue with the physical control box in that it may be unresponsive for up to 60 seconds (if the PHP process stops, and is pending a restart) however in practice this seems to happen only once every 5 hours, and the control box is rarely used anyway so it would be unlucky for a user to try and use it during that time. It does not cause any issues with the schedule since any on/off events that happened when it was not running will be processed when it starts back up again.
I could have simplified things by having the Fox G20 board with WiFi module directly in the control box (removing the need for the Synapse modules) however did not do this due to possible issues with heat (cost of replacement), ease of access, and ease of hardware / software implementation (there does not seem to be a particularly simple/optimal way of supporting momentary push buttons in an event driven way, with the Fox G20 whereas there is with the Synapse).
I chose to implement support for permanent overrides on the control box via momentary/non locking toggle switches. These are not ideal as they do not offer the user any feedback on the current state directly, however it seemed like the best option due to already using up most of the GPIOs on the Synapse Engine, and increased built time, especially when they are a rarely used feature. I chose to use non locking switches such that the permanent override setting could be changed via the web interface, but another option may have been to use locking toggle switches and remove permanent override control from the web interface.
The Fox G20 PSU is supplied with a Euro plug, even if ordered in the UK, I therefore purchased a Euro to UK plug adapter, but another option would have been ordering a new 5V 1A PSU.
Currently the system is still relying on the existing hard wired thermostat. Synapse recently brought out a new motion/light/temperature sensor which I may add in support for in the future. The motion sensor could potentially be used to automatically turn off the system (disregarding the schedule) if no one is in the house resulting in cost savings. To switch over I would simply set the existing thermostat to a high temperature such that it is always on, allowing the Synapse sensor to have priority.
I only tested the blue LEDs initially which was a mistake since after implementation I found that the green LEDs were barely visible (I did not realise the greens require greater current), this meant the addition of some extra lower value resistors on the PCB that I had not originally planned for. Even so the green LEDs still ended up being significantly less bright than the blues however measuring current with a meter any lower resistor values (leading to a higher current) may have been out of spec possibly damaging / reducing the life of the LED. The reduced brightness is not ideal from a user point of view however is acceptable as the box is mounted inside a darkened cabinet.
The unit operates from two AA batteries and features:
1 Red LED
2 Green LEDs
1 Buzzer
2 Push switches
2 Toggle switches
Apart from the toggle power switch all LEDs/switches are software controllable via GPIO pins.
If the doorbell is rung, the bell sends a multicast RPC call which is picked up by the unit. One of the green LEDs is then turned on. Depending on the status of the (non power) toggle switch the buzzer is then turned on as well (the non power toggle switch is used to enable/disable the buzzer). One push button is used to reset the unit (turn back off the LED/buzzer). The red LED is used to indicate the power on/off status. The remaining extra push switch/LED are currently not used but built in for possible future functionality.
As part of a work project / possible home automation project requiring presence detection I recently purchased some WavetrendRFID readers, and tags.
Wavetrend has various hardware available including tags suitable for mounting on metal, plastic, personnel, and keyfobs with buttons. Tags also support RSSI such that it is possible to determine approximately how close a tag is to a reader.
On the software side the serial data from the RX300 could just be transparently forwarded to a server for processing, however if you have only a small number of tags, and are looking to trigger events on other nodes without depending on an external server processing the data in the middle the better option is to parse the tag data on the Synapse Engine itself.
See below for sample code to parse data from a Wavetrend RX300 reader and send logEvent RPCs to Portal (event log code can be replaced by your own code to e.g. trigger events depending on the tag ID or RSSI). Python code should also be easily adaptable for use on non Synapse hardware.
I recently purchased the Exspect EX864 iPhone Headphone Adapter which basically extends the existing 4 pin headphone socket (speaker/microphone) for your iPhone. It is useful if you have e.g. a large iPhone case such as the Otterbox Defender and are looking to connect a 3rd party device that would otherwise be blocked by the case, such as the ithlete Receiver.
After testing the device I found it worked in terms of passing through earphone audio but not in terms of passing through the microphone. Further testing with a multimeter showed that the 4th ring (sleeve) which is the microphone connection was not passed through.
Since the microphone is the sleeve connection (the only one easily accessible on the socket) I was able to run a wire down the side of the case from the top socket to the 4th ring on the plug, solder it in place, and finish it off with some heat proof tubing. It seems to work fine in terms of fixing the microphone problem.
Note: I also purchased the iFrogz Fritz Headphone Adapter which had the same problem as the EX864 in terms of the microphone connection not being wired through.
In the second part of my original Doorbell Control project I wrote some software to handle notifications for the doorbell being pressed in C#.
For the initial stage I chose to keep things simple and provide notifications (voice announcements) via the intercom feature of an existing SIP phone network running Asterisk (open source PBX software) with Cisco 7960 phones rather than going for a hardware approach.
The process is as follows:
Press on doorbell changes state of Synapse node GPIO resulting in multicast RPC being sent across the Synapse network.
Synapse node on the server running SNAPConnect picks up the multicast RPC, and triggers an XML RPC call to custom C# application.
C# application uses the Asterisk Manager interface on the Asterisk PBX server to trigger an internal call between each phones “intercom” line (intercom / “auto answer” lines connect the caller immediately and do not have to be “picked up”), and an internal extension that just plays back a pre-recorded custom audio file (in this case the phrase “doorbell”). Some non Cisco 7960 (non intercom supporting) analogue phones are also being notified by triggering call with a small timeout to produce a single quick half ring. The C# application is in addition logging events to a MySQL database.
Note: Software is based on the example SNAPConnect RPC code provided by Synapse. It is highly customised to my own requirements / setup. It is the provided primarily for those with C# knowledge looking to complete similar projects.
We have a fairly standard hard wired, 8V AC mains adapter powered push button doorbell. However due to some shortcomings I recently decided to upgrade it to provide additional capabilities but keeping the existing circuit as much as possible.
Requirements:
Sense Bell Press – Allowing for triggering of other events on press, such as additional remote ringers in other parts of the house, computer popup notification and possibly cameras / camera display (e.g. via scart triggering on TV) etc in the future.
Disable Bell Ringer – From either a remote physical switch or PC (for periods when we do not want to be disturbed by doorstep salesmen).
Ring Bell – Allowing the bell to keep ringing for a certain minimum duration even if the button is just pressed quickly to save missing callers who do not hold in the button for an adequate duration.
Additionally there was a self imposed requirement of interfacing to it in a way such that during reprogramming, or a hardware / software failure the original bell would still operate as normal.
Parts List
The Synapse RF Engine (YouTube) was chosen for this project, since Synapse hardware is easily scriptable via Python, and has inbuilt support for sending / receiving commands over a wireless network (with mesh networking if required) to either other remote Synapse Engines or a PC connected to a Synapse USB adapter.
Note 1: Due to space limitations only the circuit for the bottom MOSFET is shown, the other however is just a duplicate of the first, also see above for closeup diagram of the relay control part of the circuit.
Note 2: The pin spacing of the relay PCB terminals did not match that of my stipboard therefore I chose the non standard approach of soldering wires to the terminals and zip tying the relays to the board.
In order to allow the bell to still work even if the Synapse module was removed / non operational the original bell circuit was primarily kept intact but with a normally closed relay added to disable the bell ringer, a normally open relay added in parallel to the switch, and an opto-coupler added in parallel to the bell (before the relay) to sense the button press (even if the bell ringer itself is disabled).
A mcastRpc of “doorbell_ring_handle” is sent when the bell press is sensed, and the following two calls are made available “doorbell_ring(duration_ms)”, “doorbell_disable_ringer(status)”.
Future Projects
Future projects will handle the other end of the system, i.e. the remote ringers (PC and/or hardware based), bell enable/disable switch.
I was initially looking into off the shelf hardware, however was unable to find any readily available equipment (to the hobbyist market in low quantities) that was reasonably priced, and fit the requirements. Therefore partly as a personal project, and partly in preparation for a possible commercial product I decided to put together a prototype active RFID tracking System.
The solution I came up with is based on 3 main hardware components, and 5 software components. It utilises mesh networking meaning that only a single reader needs to be physically connected to a PC, all other readers just require power.
Hardware:
Tags – Carried around / placed on assets to be tracked.
Reader Nodes – Placed around the area where the assets need to be tracked in.
PC Reader – Connected to the PC, receives data from reader nodes and sends it to the PC.
The main hardware component used is the Synapse RF Engine, a 2.4 GHz transceiver module with built in support for running Python scripts, 2 UARTs, a number of GPIOs, and a 2.5uA low power mode.
Software:
Tags – Software running on the tag to send out a “ping” at a defined interval, then put the “tag” to sleep before sending another ping.
Reader Nodes – Software running on the reader node hardware to listen for tag “pings”, and after receiving a ping, send the tag ID, reader node ID, and received signal strength to the PC Reader.
PC Reader – Software running on the reader hardware to receive data over the air from the many reader nodes and forward it to the serial / USB interface.
PC Serial to HTTP data forwarder – Software running on the PC that listens for data from the serial / USB connected PC Reader, and forwards that data via HTTP to a server.
The software consists of Python used by the Tags, Reader Nodes, PC Reader. C# used by the “PC Serial to HTTP data forwarder”, and PHP, HTML, JavaScript, SVG used by the “Location tracking processing / display GUI”.
Video showing simulation of tracking between 8 rooms, using 5 tags. For real life demo showing a single tag moving between 3 rooms see below.
System Design
The system was originally designed around the principle of Trilateration. Reader Nodes are placed at fixed known positions around the room / rooms containing tags that need to be located. As long as a tag is within range of at least 3 reader nodes the tags position can be calculated by using the signal strength of the tag to each of the 3 nearest readers. However this approach turned out not to be very feasible since past around 2 meters the signal strength started fluctuating in a seemingly unpredictable way. It may be possible to predict / error correct for the fluctuations however I opted to go for a simpler approach of just plotting tags next to the reader with the highest signal strength (the one they are nearest to). This now means that readers need to be placed in each room (ideally centrally) where tags need to be tracked and it is only possible to determine a tag is in a room, and not its position in that room (although it is not used the original trilateration code has been left in the download).
Using a two part system of sending the tag data to a web server (via a locally run data forwarding application) then displaying it back to clients in the browser has a number of advantages:
Main application processing / display logic can be maintained in a single central location for one or more deployments.
Location display / viewing GUI is cross platform (can be accessed via most modern browsers the have support for SVG excluding Internet Explorer).
No software to install on client PCs viewing the map.
Multiple users can logon and view the map at the same time.
The use of mesh networking means that only a single device needs to be directly connected to a PC, all the others just need to be within range of any other unit that itself is either close to the PC, or close to another reader that is close to the PC. The makes setting up the system much easier as there is no need to wire each node to the PC / the network or have a PC next to each node. The nodes just require 3V power.
Note: I used a CR2032 battery from Rapid however both Farnel, and Future also have a selection available from various manufacturers.
Building The Tag
I choose the Teko Enclosure because of its compact, credit card size. Unfortunately however this meant that the RF Engine would not fit vertically inside. I could have used one of the alternate form factor modules (sold by companies such as Panasonic that also support the Synapse firmware) however having the pins broken out is actually useful for updating the tag Python software / firmware at a later date. I therefore decided to bend over the pins, allowing one side to be plugged into the evaluation board as normal (albeit it a much looser fit) and the other to be plugged into the IDC header via an extension cable. I tried a number of approaches to bending over the pins, including bending them all at once using pliers, and trying to bend them against a flat surface, neither proved very fruitful. In the end I found the best approach was individually bend each using the tip of the pliers.
In terms of wiring things are fairly straight forward, pin 24 on the modules goes to (-) on the battery holder, and pin 21 to (+) on the battery holder. I soldered to the top of the module to avoid obstructing the pins meaning they can still be plugged into the evaluation board/extension cable for reprogramming. I also used some heat shrink tubing to tidy things up.
To secure the module in the enclosure I used two small stick on feet on the module itself, and two larger stick on feet to wedge the battery holder into a corner of the enclosure.
Not being as adept as I could be with finding productions on Digikey’s site I took the approach of ordering two parts (3M1324-ND, SAM1242-12-ND) really designed for PCB mounting and soldering a ribbon cable to them. A better approach (if such parts exist) would have been to purchase connectors that can mount directly to ribbon cable (therefore requiring no soldering), and to purchase suitable sized ribbon cable to fit.
Note: If you are going to use the same approach I did and solder the connections then ensure the solder does not leak into the socket, otherwise it will not be possible to plug it in to the evaluation board.
Reader Node Hardware
Parts List
Per individual reader – at least 3 reader nodes are required
As with the tags in terms of wiring, the reader nodes are fairly straight forward, with pins 21 and 24 going to the appropriate connections on the DC plug.
As with the PC reader it would be possible to use the “SNAPstick USB Module Interface” to avoid the soldering work, and in this case a USB power supply e.g. plug form or cabled form would also be required.
Using the Maplin N53FK box I found the modules only just fitted alongside the DC Plug, I had to remove one of small plastic mounting stands in the box to make it fit. The other small mounting stand served to secure the module in the box with one row of pins on the module fitting between it and the outer case wall. After the module and DC plug were fitted inside the box some space remained between the top of the module and the top of the box, therefore I used a single packing peanut to secure things. Something like hot glue could also be used however the packing peanut means the modules can quickly and easily be removed and put back into the box, e.g. for reprogramming (however generally it would be possible to reprogram them over the air).
Note: If you are looking for additional range the Synapse RF100PC6 (including a transmit amplifier) or RF100PD6 (including a transmit amplifier and allowing connector of an external antenna) may be more suitable for the both the PC reader, and reader nodes.
To simplify the process of linking the 3V Synapse module to the PC (i.e. avoid using a MAX232 and the extra PCB / wiring that would involve) I used a 3V FTDI USB to serial cable. The USB end plugs straight into the PC and provides a virtual serial port, the other end connects to the UART pins on the Synapse module. In terms of power, to avoid the need for an external power supply I used an LP2950ACZ-3.0 Voltage Regulator to convert the 5V power provided by the USB port / FTDI cable to the 3V needed by the module. The LP2950ACZ-3.0 however is only rated for 100mA therefore I used two in parallel to provide 200mA (the Synapse RF Engine datasheet quotes a transmit current of 110mA and a receive current of 65mA).
To save some of the work involved in building the readers a SNAPstick USB Module Interface (as included in the evaluation kit), and a RF100P86 could be used instead however it would still require a suitable enclosure, and USB extension cable bringing the cost to ~50 GBP per reader.
The Python tag software is fairly straight forward, it performs 5 main functions:
Set transmit power level for the tags.
Initialise GPIOs to optimise current consumption in sleep mode.
Turn off relaying of messages for other devices in the mesh network (it will only be powered up for a small amount of time every specified interval therefore this would not be very useful, also it may use up extra current).
Send out a ping (via multicast RPC) to any reader nodes in range with the tag id, and a TTL of 1.
Go to sleep for e.g. 10 seconds.
Specifying a TTL of 1 on the multicast RPC call causes only readers that are directly in range of the tag to receive the ping, otherwise by default any nodes not in direct range of the tag would be forwarded the call from readers that were. This would mean it would not be possible to work out which reader actually communicated with the tag directly and which communicated 2nd hand.
The software is loaded onto the tag via the Synapse “Portal” application available for Windows, Mac, and Linux, also included with the evaluation kit.
When programming the tag you should plug it into the evaluation board rather than run it on battery and program it over the air because leaving the module on the workbench un-programmed, even for just a few minutes will quickly drain the small battery (15mA when idle according to the datasheet) and 40mA / 110mA when receiving / transmitting.
The reader node Python software is responsible for receiving a multicast ping from the tag, and then forwarding it back to the module connected to the PC, along with the signal strength of the tag that sent the ping, and the id of the reader itself. Thanks to the SNAP (Synapse Network Appliance) protocol the intricacies usually involved with using a mesh network are all abstracted away from the programmer meaning it can be done in only 2 lines of code (excluding comments, variables).
The PC Reader Python software handles receiving data from the reader nodes (which themselves receive data from tags). It initialises the serial port, connects UART 1 (itself connected to the FTDI cable, which appears as a virtual serial port on the PC side) to STDIN/STDOUT (i.e. meaning that any Python “print” statements cause that data to be sent over the UART to the PC), and then initialises it to 9600 baud. The software prints the tag ping data to the serial port (after decoding the hex values to plain text).
If the tag that sent the ping is in range of e.g. 4 reader nodes at that time, 4 lines will be received with the same tag id, but different reader ids, and varying signal strengths depending on which reader nodes the tag is closer to.
Note: There is not a command / function to send data to the UART, Python access to it is available only by e.g. cross connecting the UART with STDIN/STDOUT.
The data forwarding application listens for data on the virtual serial port created by the FTDI adapter, and sends it to a HTTP server via HTTP Post. The local “COM Port” (e.g. COM 6) and remote servers HTTP address (http://www.example.com/locationtrack/?p=clientapi&password=track111) running the server software should be specified. If no HTTP server API address is specified tag data will be logged to the screen only (useful for debugging / testing).
It does not simply pass data straight through to the web API however does some initial processing, firstly in order to minimise HTTP requests (improve performance), and secondly in order to group tag pings together based on a 1 second time limit (something that would be otherwise unnecessarily complex to do on the web application side). It is assumed a tag is in the same location when any reader reports seeing that particular tag within a 1 second window from when the tag was first seen by any reader.
The application includes an “Auto Connect” checkbox which will cause it to automatically open the connection to the serial port when the software is loaded.
Note: One of the selling points of using the Synapse module (Python / high level language / RPC) based solution is the ease of use of it, everything is very much simplified for the programmer over other options such as perhaps using a Nordik nRF24LU1, and controlling it over I2C with an AVR in “C”. However this does bring with it additional licensing costs if you use over 6 modules on a network at a time using Portal. Therefore I coded a custom client side data forwarding application, rather than loading a Python script into Portal to do this and using RPC calls which would have been a simpler solution. In terms of deployments using the C# application also simplifies things avoiding the need for Portal to be installed / configured, the C# application just requires setting the COM port and URL.
The .net framework is required to run this application, it is available from Microsoft Update or as a download from microsoft.com.
C# Express Edition is available for free from Microsoft for viewing / editing the source code.
Coded in PHP this part of the code is responsible for accepting data from the HTTP Data Forwarder, converting the signal data into a location on a map, saving the data to a MySQL database and displaying it to one of more users viewing the map. The frontend is coded in JavaScript and SVG (using the jQuery SVG plugin). AJAX is used to poll the server for tags that have moved and JavaScript / SVG is used to dynamically animate them to their new positions on screen.
When the map is first loaded the tags will animate from their last 2 positions coming to rest at the current live location. JavaScript code has been written to ensure that tags are not placed on top of each other but rather clustered around the closest reader.
Support is provided on GUI for adding maps (one or more), readers, tags, and users (who can login) to the system.
Video showing a single tag moving around the map plan diagram corresponding to its real world location in one of 3 rooms. The tag ping interval was set to 3 seconds.
Video showing failed attempt to use trilateration to determine the unknown position of tag using the known position of 3 readers, and signal strengths to them.
General Notes
I would suggest purchasing the Synapse Starter Kit (Future Electronics), since although modules are programmable over the air, a serial connection is required in some situations such as deleting running scripts that are in an infinite loop, or have disabled the RF interface used by the “Portal” software for uploading new software.
Synapse Wireless software, and documentation is available from the Synapse forum.
Download All
Includes all project files as linked individually above (Tag Python, Reader Node Python, PC Reader Python, C# Data Forwarder Source, Data Forwarder Binary, PHP Processing / Display application).
With the non trilateration approach of placing tags nearest to the highest signal strength reader, readers need to be carefully situated, particularly if they are in different sized rooms adjacent to each other in order to avoid false readings.
If building the readers again I would use a different type of DC socket, as the one chosen was fairly loose when used with the 3V adapter plugs.
I was expecting to achieve a longer battery life, as it stands battery life is around 1 week for a 10 second ping interval, and around 2 days for a 3 second interval on the CR2032. In terms of increasing battery life the main options would be decreasing the ping rate (therefore increasing the sleep time), or going for a different battery however this would likely require a larger form factor enclosure.
OpenBeacon Suitability
At first glance OpenBeacon hardware (as used at conferences such as the CCC’s 24C3) would appear to be an ideal choice, their website even mentions it is “meant to be used as a reference platform by hardware and software developers”, however the more I looked into it the more it did not seem suitable for my particular requirements:
Form factor of 20 EUR white tags is not particularly ideal (open circuit board / battery).
Keyring tags are available however they cost 25 EUR each + 5 EUR for the case, i.e. 30 EUR in total per tag.
USB readers are available for 85 EUR however require a PC by each reader, not particularly suitable for even a small deployment with e.g. 4 or 5 readers.
Ethernet readers are available but at a cost of 340 EUR’s they are somewhat expensive and still require a network cable to each, not ideal.
Readers are not able to provide received signal strength but rather rely on the tags broadcasting at a set (limited) number of power levels meaning a position can not be calculated as accurately as it may otherwise.
If you are interested in this project you may find these others also of interest: Parallel Track, a free (for personal non commercial use) server side vehicle tracking application coded in PHP designed to be used with Python supporting Telit hardware modules running the embedded TModSoft software (firmware). Track Any Mobile, a web application for mobile phone tracking using the MSC (MSISDN) available using an SS7 API provider.
I write software for various hardware devices. Finding bugs, and resolving them is usually relatively easy if the issue can be replicated in a test environment with development hardware and full logging equipment setup. The problem however is when:
