If anyone is curious, this page documents my initial prototyping efforts ..

Load cells

I 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 display

The 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 link

With 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 supply

How 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

Configuration

Could use a jumper to put the Roving Networks board into ad-hoc mode, and configure through Telnet on port 2000
Or 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