If anyone is curious, this page documents my initial prototyping efforts .. Load cellsI
had never played around with load cells before, but I believe these
were likely 50KG half bridge sensors, very similar to the load sensors
SparkFun sells http://www.sparkfun.com/products/10245. Schematic for the way they are connected is as follows <insert schematic here>. The wires from each cell are soldered onto a small single sided PCB, which connects to the main PCB using a 4 way 0.1" pin header for the excitation and signal connections. The original spec for
the donor scales was 0 - 180kg at 100g resolution, giving 1800 data
points or 11 bit ADC resolution (assuming output is amplified to the
full range of the ADC). With the sensors energised at 3.3V, the measured
output was ~0.03mV/kg, requiring 3uV resolution to meet original spec
with no amplification, and 5.4mV output at full capacity (extrapolated).
Initial thoughts on ADC choices were as follows (note: may be running directly from battery, if so will require ratiometric operation with external Vref on ADC); Atmel AVR - ATmega ADC is 10 bit, with 200x gain. - Could potentially achieve an extra bit of resolution with oversampling and decimation, and 11bit @ 200x gain would use full range of 1.1v vref and a 5uV LSB.
- However, resolution drops to 6 bits(?) with maximum gain! So definitely not suited to the job... TI MSP430 - SD16 ADC is 16bit with 32x gain. - against a 1.1v reference (1v min Vref), 16bit resolution gives 0.5uV LSB. - provides approx 10 LSB per 100g graduation. Linear LTC2433 - 16bit external ADC, with no gain - goes down to 100mV Vref, 16bit resolution gives 1.5uV LSB TI ADS1231 - 24 bit external ADC with 128x gain (also 18bit ADS1131 option) - minimum Vref is 1.5v, although reference circuits tie to bridge +/- - against a 3.3v reference, with no gain gives 0.2uV LSB, with 128x gain gives 1.5nV per LSB! - also has automatic low side bridge switching, will power up the circuit only when measuring - looks SPI compatible , although the signals are named differently Initial testing I happened to have an MSP430F2013 eZ430-F2013 lying around which I'd never really used, so this was hooked up for the initial testing. Was a bit of a learning curve to set up the development environment, and required bit banging the serial output. but it did the job. This setup was very noisy so needed significant oversampling to get a consistent output - presumably just due to the (lack of) layout. After this, I reverted to an AVR, and used an external ADS1131 ADC on a SOIC-16 breakout..... My first realisation was that using the AVR hardware SPI was a bit of a drag on my STK500 development kit. The ISP (in system programming) interface uses the same AVR pins, and was interfering with the SPI signals, necessitating plugging & unplugging the ISP header cables each time I wanted to update the code. This got tiresome very quickly, so I chose to bit-bang the SPI comms on some unused pins.The 18bit
ADS1131 (and it's 24bit relative the ADS1231) have SPI-like serial
interfaces, however they're a little unusual. (In fact the TI parametric
search tool doesn't even list the ADS1131 as a SPI part). The relevant
pins on the ADC are labelled PDWN, SCLK, and DRDY/DOUT. - PDWN is used to power down by holding it low, so can be considered an inverted SS (pulled high by the master to enable) - SCLK is a straightforward serial clock - DRDY/DOUT is the equivalent of the MISO pin, with the additional function that it indicates data readiness before the transfer begins So the process for reading a single value from the ADC would be as follows; - assert PDWN to wake the ADC - wait for DRDY/DOUT to be pulled low, indicating data is ready - output the serial clock pulses on SCLK, reading each bit on DRDY/DOUT on the falling edge of the clock signal - once all the data bits have been read, output (at least) one more serial clock pulse to force DRDY/DOUT pin high - clear PDWN to put the ADC back into sleep mode The
additional serial clock pulse is useful when polling DRDY/DOUT for
readiness, as without being forced high by this extra pulse, it would
remain at the level of the last bit to be read. Note: If DRDY/DOUT is left low, there is a brief high/low transition each time new data is ready. So if using a falling edge triggered interrupt to signal new data, this step would not be necessary. The ADC has two speed settings, 10 and 80 samples per second, that are determined by the level on an input pin. As expected the faster sample rate is a little noisier, but has a much shorter delay from powering up to retrieving the data. Surprisingly, the readings from the ADC were incredibly consistent, even with the same rats nest of breadboards & jumper cables that I'd been using with the MSP430. (Perhaps the STK500 power supply is less noisy than the eZ430-F2013?). Being a little
unsure about converting the signed 18bit values to a 32bit signed int, I
initially just read the most significant 16bits straight into a signed
16bit int, which was enough to meet the target resolution of 100g.
However, my fears of "twos compliment notation" and "sign extending"
were unjustified, and it turned out to be straightforward to deal with
the full 18bit value. Note: is really just a case of ensuring
the value of the sign bit (bit 18 in this case), is replicated
throughout the higher bits (bits 19 to 32). Driven from 3.3V
(but should be ratiometric), this provides approximately 15LSB per 100g
of weight when retrieving the full 18 bits of resolution. LCD displayThe LCD display was connected to the PCB using a zebra strip, or elastomer connector. I'd not had any experience of these connectors before, but is a flexible rubber strip comprising alternate layers of conductive and insulating material. With no solderable connections on the glass, the final design would need to re-use this strip. Observing the waveforms with a scope, the display turned out to be 1:4 mux with 1/3 bias, and would therefore require an LCD driver. However, one good piece of news was that the display did have a segment for stones (as well as KG and LB). Initial thoughts on LCD driver were as follows; TI MSP430 - series 4 with on-board LCD driver NXP PCF8566 - I2C interface - available in DIP40 for prototyping Initial testing With no way to make connections on the LCD itself, I soldered a ribbon cable directly to the original PCB pads, and reassembled the scales with the zebra strip in place. Generating an AC square wave from a pair of AVR pins, I was able to map out the segments on the panel.By this point I had already decided to use an AVR and external ADC, so I breadboarded an NXP LCD driver chip in a DIP40 package for the initial testing. Although successful, there was some ghosting at times, so will design the final board with a solder jumper to enable the AVR to generate (slower) signal timing if necessary. Wireless linkWith a wide range of options, the Roving Networks serial to WiFi modules appeared to offer a good starting point. They include DHCP and NTP clients, and even an HTTP client mode which makes posting data to a web server trivial. The module configuration parameters can either be set over the serial link, or from a telnet connection. Their range includes the RN-XV, a module with an XBee footprint which would be useful for the initial prototyping. This module is almost a drop in replacement for an XBee module, the basic pins are the same (ground, power, tx, rx), but there are some pin differences for sleep/wake etc. The provision of resistor dividers to the 1.2V inputs of the on-board RN-171 SMD module make the whole thing 3.3V tolerant. Not enough
room in the original case for the XBee footprint mounted on headers.
Could either solder directly to the board, or use the SMD module RN-171
(or RN-131). The RN-171 is smaller, but has no antenna connector, RN-131
is larger but has U.FL and chip antenna on-board. Difficult to
impedence match the antenna trace for 50ohm on a 2 layer board, but
unlikely to be much of an issue if sited right next to module. Power supplyHow to power the board?Coin cell Can't supply enough current for the wireless transmission, could potentially use a large cap ? Some of the IC's have a 2.7V minimum voltage, coin cells drops to around 2V, so would need a boost regulator Fits on the PCB, and suits the existing battery cover. 3xAA Would need an external enclosure, presumably stuck to the underside of the glass Cheapest and ugliest option ;) 3.6v Lithium AA Not enough room in the original case for even one AA cell on top of the PCB Could potentially route a gap in the PCB and mount the battery on the midline (as per some remote controls) Would probably be difficult to get in/out through the existing battery cover (possibly 1/2 AA size) LiPo Small pouch style battery should fit under/over the PCB Highest cost - plus charger IC and USB connector (would need to be vertical for access through the battery cover) Use low quiescent current 3 or 3.3V LDO Nicest but most expensive option ConfigurationCould use a jumper to put the Roving Networks board into ad-hoc mode, and configure through Telnet on port 2000Or if providing a USB connection for battery charging (see above), could use for config also Either FTDI-X chip, or USB AVR (ATmega32U4?) If using AVR, could use LUFA bootloader, and code based on LUFA serial converter to interface with the wireless module when USB cable is inserted |
Projects > Weigh-Fi wireless scales >