The Perfect is the Enemy of the Good.

A project log for 22-bit Capacitance to Digital Converter

A new capacitance displacement sensor interface for my seismometer with improved performance and low cost.

Bud BennettBud Bennett 07/13/2019 at 04:587 Comments

The seismometer has been running for a couple of days with the new C2D converter. I made some changes to the original setup to accommodate the C2D converter:

  1. The 15 inch long cabling from the sensor to the C2D converter was too long. I thought that the amount of parasitic capacitance to ground was excessive. I shortened the cables both the EXC and CAP leads to about 6 inches. The CAP leads were set about 1/4" apart and covered with copper foil tied to earth ground. The EXC leads do not have any shielding.
  2. The Raspberry Pi unit was moved into the inside of the enclosure with the seismometer due to the shorter cable lengths. It is just resting on the glass plate near the cap sensor.
  3. I removed the foam insulation and copper foil shielding from the C2D sensor to make it easier to assemble to the Raspberry Pi. The C2D must be connected to the cabling while the seismometer and C2D are outside of the enclosure, otherwise it is too difficult to connect the cabling. (See note about NP0 capacitors below.)

The reason that the Raspberry Pi was previously mounted outside the enclosure was to avoid the heat of the RPi from causing temperature variation inside the enclosure. Going forward I expect to put the RPi inside a small metal enclosure to both shield it and reduce the rate of temperature variation that it can produce.

There were some problems with the code crashing early on, but those are now fixed and there is data for 24 hours to evaluate. There's good news and bad news. First the good news: the new C2D converter is between 2X and 4X lower noise than the AD7745. The bad news: I was expecting 10X-30X improvement.

This morning (2019-07-12) the seismometer recorded a 4.9 magnitude quake in central California:

The quake was nearly 700 miles( 1100km) distant. I don't ever remember getting a clear record of a < 5 magnitude quake in California before. But there are problems.

The above waveform is the raw data from the seismometer sensor over a 24 hour period. The daily peak-peak variation in the data is nearly 150,000 counts. I believe that all of this is due to temperature variation of the mechanical system of the seismometer. The spring and frame are metal, which tends to expand and contract with temperature. 150k counts is about 1% of the range of the seismometer -- it's not really a problem. But the jagged artifacts near the 23:00 hour are a real problem. They cause the baseline of the waveform to jiggle and tend to obscure the data unless the corner of the high-pass filter is moved upward, which would decrease the sensitivity of the seismometer at lower frequencies.

Checking the Damping:

I thought that the damping mechanism may need to be re-tuned so I performed another step response test with the following result:

It looks fine (when sampled at 2 Hz).

Reducing the Rate of Temperature Swing:

Now I'm thinking that the glitching is caused by the seismometer mechanism responding to the change in temperature within the enclosure, and if the temperature variation could be reduced it would reduce/eliminate the glitching. One way to do this is to increase the thermal mass within the enclosure. The simplest approach that I could think of to increase the thermal mass was to stack 24  12 oz. diet cola cans along both sides of the frame. I did this yesterday morning. It will require several days to let the seismometer settle to a new equilibrium before I will know if there is any improvement.

A Note About NP0 Capacitors:

I had thought that NP0 capacitors exhibited zero temperature variation. The C2D was showing a bit of variation which was obviously due to temperature. It turns out that NP0 capacitors can have up to ±30ppm/C of temperature coefficient. In my system this translates to 500 counts per °C. So in addition to shielding the board from electrical interference I must also insulate the board to prevent even small rapid temperature variations from affecting the output. Slow temperature changes will be removed by the high-pass filter, so that is OK. 

The board is mounted directly onto the GPIO header on the Raspberry Pi. The RPi heats and cools with various demands of it's programming. There are noticeable glitches when the webpage server is accessed and the increased loading causes a temperature change that is visible in the waveform. A simple foam enclosure around the C2D board may fix this issue, but it might require that the board be distant ( a few inches) and use a short cable to connect to the RPi (and still have an insulating enclosure). 

Next Steps:


Paul Versteeg wrote 07/15/2019 at 06:49 point

Hey Bud,How about segmenting your processor tasks. The RPi currently runs tasks that will vary the temperature quite a lot. If you would use an ESP8266 to run the C2D convertor, it could then communicate over WiFi with the RPi further away over something like MQTT. The code for the ESP would be a controlled tight loop that will not differ enough to cause the larger heat differences of the RPi. If you would use the ESP 32 version, it could even run micro-Python so you don't need to change the code much.

  Are you sure? yes | no

Bud Bennett wrote 07/15/2019 at 13:50 point

I'm not familiar with any of that Paul. But I'll check it out. The ESP8266 will have to run the ascii2mseed and ringserver code (Linux). I use a power line ethernet right now because the WiFi signal is pretty weak in that corner of the garage. The longer range of MQTT would be better -- using a USB WiFi adapter on the RPi-B+ caused it to disconnect a lot. It will take me some time to check this out. In the meantime the diet cola seems to be working, but after two days still hasn't reached a steady state.

  Are you sure? yes | no

Paul Versteeg wrote 07/15/2019 at 14:03 point

You can still let the RPi connect through Ethernet to your router, and let the ESP and the RPi use MQTT over WiFi among themselves.

  Are you sure? yes | no

Bud Bennett wrote 07/14/2019 at 17:47 point

Hi Bob,

I'm pretty sure that it's temperature effects in the mechanical system. The AD7745 exhibited the same phenomenon. The sun and the moon are the only things that create this kind of diurnal effect. The problem isn't that the temperature changes in 24 hours (11.6µHz). It's that micro changes in temperature cause high rate of change temperature artifacts that are detectable by the electronics within the desired bandwidth. I thought about having the AD7745 detect the local temperature on the PCB -- it has enough resolution  and good proximity -- but I don't know exactly where the mechanical sensitivity to temperature is in the system (and I don't really want to go back to the poorer sensitivity of the AD7745). The path of least resistance, for now, is diet cola.

The problem could be caused by many other things: some mechanical coupling between the platform and the outside world, etc. Chasing down 1-3ppm effects is difficult and time consuming.

  Are you sure? yes | no

Bharbour wrote 07/15/2019 at 16:06 point

Could you just heat the enclosure enough to swamp out the source of the micro changes? Sort of like an ovenized crystal oscillator. As well insulated as your enclosure is, a few watts would probably do it. A small I2C temp sensor would provide feedback for the the temp control system. A Maxim DS1721 or Analog Devices ADT7410.

  Are you sure? yes | no

Bud Bennett wrote 07/15/2019 at 17:47 point

I tried that several years ago with a thermistor and PID controller. It made it quite a bit worse -- I think it created convective currents. If the diet cola doesn't work then I may reconsider that approach.

  Are you sure? yes | no

Bharbour wrote 07/14/2019 at 15:54 point

Hi Bud,

If you put a temperature sensor near the system, you could probably correct that offset change in software. If nothing else, comparing the temperature to the data should tell you if the offset is from the mechanical system or the electronics.


  Are you sure? yes | no