Page 2 of 2

Re: STM32F030 custom board

Posted: Fri Oct 28, 2016 4:13 am
by ddrown
ahull wrote:You might find this interesting, (and the comments are worth reading too).
Also this... which relates to a Maxim ADC, but the underlying methods are probably relevant to your use case.

There is also this... which might be of interest.

Yeah, the ocxo parts are nice. But all the one's I've seen are 1 amp and up. I'm aiming for under 100mA usage (I'm currently around 10mA~20mA).

For the temperature measurements, I'm now questioning if it'll be useful to pursue better accuracy. Maybe it's better to measure other possible variables like air pressure and humidity.

My numbers from 5 hours of voltage measurements so far:

Voltage range seen on multimeter: 3.288V to 3.289V (0.03%)
Room temperature range: 78.5F to 75.5F
Frequency Range: -0.583ppm to -0.541ppm

Assuming the response to voltage change is linear (and it probably isn't but it's useful as a magnitude comparison), 200ppb per 5% would be 40ppb per 1% or 4ppb per 0.1%

It moved 42ppb in this time. I just noticed that a different TCXO's datasheet gives its aging spec as "only after running for 30 days" which makes me think that maybe it'll settle down after running for awhile. I have heard that crystal oscillators have a "burn-in" period and are better with age.

Re: STM32F030 custom board

Posted: Wed Nov 16, 2016 5:27 am
by ddrown
Checking back in after running this board for over a month now. After the strange second week, the frequency stabilized. I'm thinking it was an affect of aging.

Below is a graph of frequency error averaged over every 16 second interval


And the next graph is an Allan deviation comparison. Allan deviation measures frequency stability over various time periods. The clock all these sources are being compared against is the GPS system (which is more accurate than I can currently measure).


The Y axis is frequency stability, and the X axis is the time period length. Smaller numbers (down) on the Y axis are better. For reference, 1ppm = 10^-6. There's four different clocks being compared.

Purple "TCXO" clock line - this stm32f030 board
Dark Yellow "gmtimer-PPS" clock line - a Beaglebone Black with a hardware timer driver connected to a local GPS module
Light Blue "gpio-PPS" clock line - a Beaglebone Black with a gpio interrupt based driver connected to a local GPS module
Green "vps3-home" clock line - NTP (custom client) over the internet

The TCXO isn't synced to any system, so in long time spans, it drifts off of its proper frequency. Since all the other systems are synced to a GPS (directly or indirectly), they don't drift off after hours or days.

My goal for this module is to provide frequency stability to machines being synced over the internet. This would be combining two time sources: the green "vps3-home" line, and the purple "TCXO" line. At the "1 day" marker, the network source moves around by +/-0.320ppm and the TCXO source moves around by +/-0.08ppm.

You can see that in detail in this next graph, where each frequency sample is an average over 1 day.


From that graph, you can see that one day to the next, it mostly moves less than 0.08ppm.

My next step is to feed this better frequency stability into a Raspberry Pi or other SBC. I'll be using the gpio interrupt driver for that, and the limits on that driver's accuracy and precision are given by the blue "gpio-PPS" line. I'll need to combine the local frequency stability over the short term with the long term frequency stability from the network. I have some ideas for this, but I haven't written the code yet.

I'm pretty happy with this result. My GPS module is only accurate to 1e-8 at 1 second anyways, and my measurement precision limitation at 1 second is 2.1e-8. At around 10 seconds, my measurement precision limitation is 2.1e-9. So the TCXO is pretty much right at my measurement limit for very short timescales. I wasn't expecting that at all.

Re: STM32F030 custom board

Posted: Wed Nov 16, 2016 9:44 am
by ahull
Pretty impressive results. Which TCXO did you use? Where did you source it?

Re: STM32F030 custom board

Posted: Wed Nov 16, 2016 4:34 pm
by ddrown
ahull wrote:Pretty impressive results. Which TCXO did you use? Where did you source it?

I used this one from digikey:

Part of this result is from the narrow temperature range it experienced. Quick temperature changes and temperature extremes would have a worse result. But my application is in an office, so this should be OK.

Re: STM32F030 custom board

Posted: Tue Jan 10, 2017 2:53 am
by ddrown
To investigate temperature measurements in more detail, I setup a blue pill to sample the internal Vref, the internal Temperature sensor, and a TMP36 (10mV/C analog sensor) on PA0 every second and log it via USB serial. This data is averaged over 60 seconds worth of samples.


Blue is the TMP36 and Green is the internal temperature sensor. The internal temperature sensor is shifted up by 1.054F to make the relative movements easier to see.

After letting it run overnight, I opened a window and started recording temperature values by hand from a third sensor - a "Acu-Rite weather station". Those values have been shifted up by 2F. The temperature outside is around 6F colder than the room, so you can see all the sensors falling in response.

I suspect the difference in relative temperature changes between the stm32f103 internal sensor vs the TMP36 come from the packaging. The stm32f103 LQFP48 package has a 55 C/W theta JA spec, while the TMP36 TO-92's datasheet has 162 C/W theta JA. So temperature changes should cool down/heat up the stm32f103 package quicker.

My next tests along these lines is to setup a BME280 and add its data.

The Vref data measuring the stm32's supply voltage looks like this:


I've set the expected Vref voltage to 1.206 V (datasheet Vref: min 1.16V / typ 1.20V / max 1.24V) after calibrating it with the Vdd measured by my multimeter (3.321V). I haven't experimented with varying the Vdd, but that could be interesting too.

Re: STM32F030 custom board

Posted: Thu Jan 12, 2017 3:02 am
by ddrown
Adding some more filtering to the Vref value (average of 1024 seconds of data collected 1/second) and comparing it to temperature is interesting:


The full vref axis on that graph is 1.8mV, which is just over 2 LSB (+1 count@3.3V = 0.8mV) of the ADC! That's probably where most of the artifacts come from. But I do seem to be getting valid data within +/- 200uV, which is pretty cool.

I also assume both my voltage supply and the internal bandgap voltage reference are moving, just not at the same speed. I think this works out to be roughly 300ppm/degC. I think this voltage regulator is specified to be +/-0.5% (5000ppm) over its full temperature range, but it's not a linear relationship.

The bme280 sensor gives really nice data, and I'm not even using its oversampling or filtering modes.

Temperature compared between the three sensors (all on the same breadboard):


Pressure data matches well against my phone (which seems to have a BMP280). My weather station and the wunderground website disagree with the bme280 by almost 30hPa, which is odd. But they all track relative changes pretty well.


Lastly the humidity data. I don't care about it, but I'm collecting it anyway. So here's a graph!