Looking for a freelancer to code firmware for our project

[Lauraren]

Looking for a freelancer to code firmware for our project which will use data from a MEMS and a load cell, initially testing  (if possible) with a nRF52 development kit.

Before starting it would be very usefull to have a rough estimating of energy consumption, knowing that we need to collect at a rate of 100Hz data from the 3 channel gyro and accelerometer and load cell and then send the data every second, if this is the best solution to group data without delaying communication intervals to longer ones.

[hmolesworth]

Drop me an email with the MEMS and load cell devices you want to use, plus 832/810/840, or post them here. I'll give you a free estimate based on the many designs I have completed; I am freelance.

[Lauraren]

Hi, thanks for the reply.

We are developing a device that measures forces and inclination (angle).

For this project a specific load cell has been developed and it will provide data from three channels (10000ohm resitance and the other two 5000ohm resistance), that will need to be amplified.

Since we also need to measure the inclination of the surface on which the device is attached, we will choose a MEMS (depending on accuracy permitted by energy supply) to do this task.

To have a preliminary idea of energy consumption and preferable chip (I do not know which could fit best between the 3 models you asked me).

Data from these sensors will be collected at 100Hz and after doing some filtering /calculations we would need to send the resulting 100 x 5 float values at 1Hz via BLE to a smartphone.
We would like to use a CR2032.

As a first information that would help me decide, I would like an estimate only of the recording of the 3 force\s channels and the sending of all the values, both in terms of energy. I would also like to know if while sending the chip will also be able to do other tasks as recording from sensors.

Sorry for not being able to be very correct technically, but I am looking for this type of help because my competences are on the mechanical part.

[hmolesworth]

Your application seems straightforward and could probably use any of the three candidates from the nRF52 family. The 810 is the cheapest, being similar to the 832 with fewer peripherals, but more than enough for your purpose. The 832 sits in the middle and the 840 provides enhancements such as longer range using multiple symbol encoded transmission and Forward Error Correction (FEC) which you probably don't need. A lot depends on the target cost, and whether the device can have replacement coin battery or whether it is disposable (return to base for recycle). Cheapest - and most work - is to design with the nRF52 devices directly, not recommended until you are at pre-production with very large volumes. Easiest is to simply use one of the many modules, since they come complete with FCC approval and internal chip antenna and power components; I like the nRF52832 Rigado BMD-350 as it is tiny, but there are lots of other module manufacturers. The starting point is to purchase 2 x dev kits, one will be your "device" and the other will be an interim "gateway" to a laptop to enable testing of the device - and measuring power consumption - before migrating to using a smartphone App.
nRF52832 BMD-350 Module: here

nRF52832 BMD-350 Module Evaluation kit - $64 from Digikey: Eval

Power consumption depends on BLE settings and connection interaction with the smartphone, which is smartphone OS dependent. A continuous connection may be required, or repeated connect - disconnect. With the data rate you are looking for, and 100Hz sampling generating 100 x 5 32-bit floating point values per second requires only 2,000 bytes per second, but expect to add some additional metadata as the project proceeds, including some form of timestamp and device identification. The smartphone limitations as to allowed data throughput would also eventually have to be checked, as some throttle user requests. Does 100Hz sampling mean just that, or perhaps there is a requirement to oversample the load cells at a faster rate and only transmit averaged readings at 100Hz. The 3-axis accelerometer sample rate also needs to be determined; is this just a few samples per second or also 100 samples per second, more with oversampling.

Power required to handle the sensor depends on the sample rate and communication speed; there are examples allowing testing with a 3-axis accelerometer using (say) an Adafruit breakout board and I2C or SPI interface. SPI interface to the accelerometer is preferred to I2S as the transmission bursts are smaller using a higher frequency; there is also less cpu overhead. There is also a Nordic nRF52832 platform - the Thingy 52 - which has some of these devices fitted, though that might be a distraction. The load cell depends on excitation voltage, and whether it is synchronous or continuous excitation, and the actual sampling rate and sampling resolution required. The amplifier - if required - is another item, depending on whether you can use the internal 10/12/14-bit ADC on the nRF52832 or an external AFE is required, such as a 24-bit ADS1220. The number of channels depends on whether synchronous sampling of the load cells is required, or whether you can get away with sequential sampling. Switched capacitor sampling could also allow synchronous measurements with a single analogue AFE path.
Adafruit LIS3DH example

Processing power on the nRF52 is impressive; it is unlikely anything required in terms of signal processing will require more than a small percentage of wake time, which is of course the goal to improve battery life. Most hardware peripherals are DMA-driven and can use internal hardware events for control of timing and communication, meaning very little cpu wakeup time required. The CR2032 coin cell will be used as a trickle charge for the (say) 150uF capacitor bank which provides all the switching power requirements such as radio transmission. Provided all active components can run of (say) 1.7 volts, no regulators are required - as the nRF52832 internal DC-DC can be used - although bridge excitation may require a boost. Any piezoelectric beepers/haptics or LEDs also require defining, since they have particular voltage requirements.

Some discussion points:
 - Required CR2032 battery lifetime
 - Load cell oversampling (if required)
 - Bridge excitation voltage
 - Bridge temperature sensitivity
 - AFE/ADC resolution, accuracy and repeatability
 - Accelerometer sampling rate
 - LED or other user-interface device