TL;DR A current carrying wire produces a magnetic field. By measuring the strength of the magnetic field with a Hall Effect sensor we get an electrical signal (PWM) corresponding to the current in the wire. This signal can be "read" in software to calculate the current flowing from the battery box. In future, the problems we experienced can be mitigated by upgrading hardware and planning/standardizing the pinout more carefully.
Overview
The goal of current sensing is to monitor the current coming from the battery box, this is a good indication of how depleted the batteries are. This information is important for Plutus to monitor and maintain the health of the batteries.
Hall Effect Sensors
A Hall Effect Sensor has been used in both MSX and MSXI to monitor the current leaving the battery box. This type of sensor works by changing its voltage output in response to a magnetic field (B) making it a type of transducer. A current carrying wire will produce an electric field according to Ampere's Law (ignoring Maxwell's correction)
| Mathinline | ||
|---|---|---|
|
or in differential form
| Mathinline | ||
|---|---|---|
|
...
In essence, this means that since a Hall Effect sensor can read the strength of the magnetic field and convert it into a voltage by assuming values for l and S by restricting the wire gauge and choosing the length over which the sensor reads. This is translated to a pulse width modulated signal (see next section) to produce a duty-cycle which we can read in software this duty-cycle is then mapped to a current using a function provided by the sensor manufacturer.
More on Hall Effect Sensors and how they actually work:
Pulse Width Modulation (PWM)
A pulse width modulated signal or (PWM) is a method of relaying an analog result through a digitally readable signal. This is achieved by generating a square wave of alternating high/ON (typically 3.3 or 5 V) and low/OFF (0 V) signals. This essentially simulates an average voltage between the high and low value corresponding to the value of the effective analog signal. The portion of a wavelength (λ) that is spent at an ON or high state is the pulse width and the percentage of "active time" per wavelength is the duty-cycle. For example; a signal that is in the high state only 1/4 of the time is said to have a duty-cycle of 25%. The frequency (f) of the incoming signal is the inverse of the period (T) which is equivalent to wavelength for a time varying signal.
...
Where y is the signal strength.
Additional Readings:
Software
For MSX the duty-cycle was calculated instantaneously, this was improved in MSXI by using a time-averaged duty-cycle to reduce noise and improve accuracy. The duty-detected using rising and falling edge detection, essentially this means that the I/O pin we are monitoring the signal on alerts the software through an interrupt vector whenever the signal switches from low to high (rising) or high to low (falling). These vectors trigger code to read the internal clock time of the signal change to a pair of ring buffers one for rising and one falling. By computing the duration between two rising events we can determine the period of a cycle. By computing the duration between the first rising and next falling event the active time can be determined. Dividing the active time by the period we can determine the duty cycle. By averaging these results we can get a good idea of the average duty cycle for a short period, this is the mapped to the current value using the manufacturer's function. In MSX these values were not averaged and as a result, the accuracy was lower.
Reflections and Improvements
The major difficulty experienced in implementing current sensing in MSXI was an internal timing issue. Specifically, the interrupt vectors to trigger the rising and falling behavior were not always interleaving as rising, falling, rising, falling. Instead one of the events would often skip leading to the two ring buffers falling out of sync yielding completely unexpected duty-cycles and by extension, current values. This issue plagued the initial implementation for weeks while we sought to understand the issue; it was particularly bad above 100 Hz and the sensor we were using operated at 125 Hz. It didn't help that the Timer A module we used in prototyping on the MSP430F5529 launchpad had different behavior than the Timer B module that was connected on the Plutus board. Going forward it would be ideal to use the same modules for both prototyping and real-boards, in this case it was a hardware limitation of the launchpad and original design of Plutus.
...