STM32F030 custom board

ddrown
Mon Oct 17, 2016 2:25 am
I created a devboard based on the STM32F030F4P6 chip because I wanted to experiment with a TCXO.

Image

I have details and more pictures here: stm32f030 devboard

I learned through this that 0603 parts are my limit. I’ve never done anything that small before, and they took some time to figure out how to handle them.


ahull
Mon Oct 17, 2016 1:44 pm
I’m impressed 0603 is where I start to sulk, if you so much as blink, they vanish. Sneeze, and you need to start again :D
I need to wear two pairs of x3 reading glasses just to have a sporting chance of placing them.
The hands are steady enough, but the eyesight is not quite what it was when I was 21 :roll:

ddrown
Mon Oct 17, 2016 5:04 pm
ahull wrote:I’m impressed 0603 is where I start to sulk, if you so much as blink, they vanish. Sneeze, and you need to start again :D
I need to wear two pairs of x3 reading glasses just to have a sporting chance of placing them.
The hands are steady enough, but the eyesight is not quite what it was when I was 21 :roll:

RogerClark
Mon Oct 17, 2016 9:09 pm
Like Andy, I bought a pair of x3 reading glasses for a few dollars and use them for all circuit work nowadays.

I also bought some x10 headgear from AliExpress, but its totally useless, as the focal distance is about 2cm, which makes it impractical to get that close to the OCB while wearing the contraption. It came with interchangable lenses going up to x50, but they are even less usable.

I also have a cheap USB microscope, but the lag on the display make it impractical to use for placing components, However its Ok for just doing inspection

A x10 jewellers loop is also very handy to have, especially for looking at markings on devices, and for doing inspections e.g. looking for solder bridges etc


ahull
Mon Oct 17, 2016 11:57 pm
I’ve also got one of these….
http://www.ebay.co.uk/itm/15X-Head-Band … Sw~gRV0y~8
…very cheap, and fairly good, so long as you avoid poking your eye out while trying to figure out how to wear it.

Image

I’ve got a little more hair than the dummy in the photo, and the sprung steel band is inclined to grab your hair/beard/collar or fly off and land in your coffee. :roll:

They are good for inspection and very close up work, but the focal distance is too short to solder with, as you risk setting fire to your nasal hair. :lol:


RogerClark
Tue Oct 18, 2016 12:06 am
I have some of these

http://www.ebay.co.uk/itm/Eye-Glasses-L … SwQupXUTSp

Image

But they are useless, the lens diameter is too small.


ddrown
Wed Oct 26, 2016 10:41 pm
10 days later, I have some data now. I hooked a GPS reciver’s pulse per second (spec: within 10ns of UTC) to an input capture timer and saved cycle counts for every second. The timer is running (after a 4x PLL on the HSE) at 48MHz.

The frequency graph (in ppm or 1/1000000 units) is below. You can see it stayed within a 0.770 ppm range, which is acceptable for my TCXO, which has a spec of +/- 2.5ppm.

Image

I also created a video of how the frequency changed over time and its relationship to temperature. Each frame is 2 hours of data. The X’s and +’s are the individual cycle counts compared to the room temperature. You can see there’s not much frequency change with temperature change, it’s mostly horizontal movement. There is however an slow drift upwards (maybe it’s aging? The spec for aging for this TCXO is 1ppm/year). There’s also a jump down at hour 297. I think I want to try this again with a better spec TCXO.

https://dan.drown.org/stm32/hourly-temp.webm


simonf
Thu Oct 27, 2016 7:49 pm
Did you factor in the variations in vcc and accuracy on the temp measurement?

ddrown
Thu Oct 27, 2016 9:23 pm
simonf wrote:Did you factor in the variations in vcc and accuracy on the temp measurement?

ahull
Thu Oct 27, 2016 10:59 pm
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.


ddrown
Fri Oct 28, 2016 4:13 am
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.


ddrown
Wed Nov 16, 2016 5:27 am
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

Image

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).

Image

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.

Image

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.


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

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

ddrown
Tue Jan 10, 2017 2:53 am
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.

Image

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:

Image

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.


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

Image

The full vref axis on that graph is 1.8mV, which is just over 2 LSB (+1 [email protected] = 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):

Image

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.

Image

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

Image


ddrown
Mon Feb 13, 2017 1:28 am
I redesigned my stm32f030 board to be smaller and have less components. This time instead of assembling it myself, I had Macrofab make the board and place the components. After parts+labor+shipping, it came out to be $34.32 for 2 boards.

top: old version, bottom: new version
Image

I used them to measure the accuracy of two “TCXO” RTCs: the DS3231 and the PCF2129: https://blog.dan.drown.org/rtc-comparison/

I really like these graphs of the PCF2129’s frequency vs temperature:

Image
Image

They’re from two different runs, and you can see it switching in different amounts of load capacitance based on the temperature. In this way, it can keep its internal frequency to a smaller range (and have more accurate time in the long term vs not adjusting for temperature).


RogerClark
Mon Feb 13, 2017 1:59 am
Thanks for posting

BTW.

Whats also interesting is that you used MacroFab to phsically make the board

There demo seemed to make this cost effective for SMD prototypes (as I’m not very good at SMD and never managed to get my oven to work correctly ;-( )


ddrown
Mon Feb 13, 2017 5:08 am
RogerClark wrote:Thanks for posting

BTW.

Whats also interesting is that you used MacroFab to phsically make the board

There demo seemed to make this cost effective for SMD prototypes (as I’m not very good at SMD and never managed to get my oven to work correctly ;-( )


RogerClark
Mon Feb 13, 2017 6:57 am
Thanks Dan

It can take 2 to 3 weeks just to get PCB’s, so a month for the whole lot isn’t that bad


ddrown
Fri Feb 24, 2017 3:10 am
Update! I wrote two long things on my blog: https://blog.dan.drown.org/frequency-sy … se-in-ntp/ + https://blog.dan.drown.org/temperature-compensation/

But some highlights:

Test system:

Image

Frequency vs temperature:

Image

Remaining error after removing the fit line from the previous graph:

Image

When the temperature goes down:

Image

My supply voltage goes up by 4mV:

Image


Bingo600
Thu Mar 23, 2017 8:23 pm
These are actually nice OCXO’s
http://www.ebay.com/itm/NEW-10MHz-OCXO- … 2308905189

DS
http://www.microcrystal.com/images/_PDF … r/OCXO.pdf

Uses less than [email protected] , [email protected] (10 sec) , they’re 5v supplied

This one seems to have somewhat same specs
http://www.ebay.com/itm/10MHz-OCXO-DIP- … 2868381695
http://www.golledge.com/pdf/products/ocxos/scocxovt.pdf

/Bingo


ddrown
Thu Mar 23, 2017 8:50 pm
Bingo600 wrote:These are actually nice OCXO’s
http://www.ebay.com/itm/NEW-10MHz-OCXO- … 2308905189

DS
http://www.microcrystal.com/images/_PDF … r/OCXO.pdf

Uses less than [email protected] , [email protected] (10 sec) , they’re 5v supplied

This one seems to have somewhat same specs
http://www.ebay.com/itm/10MHz-OCXO-DIP- … 2868381695
http://www.golledge.com/pdf/products/ocxos/scocxovt.pdf

/Bingo


ddrown
Mon Jul 03, 2017 1:54 am
I’ve been letting these boards run to see what happens. The TCXO’s aging spec is 1ppm/year, which is about 0.083ppm/month (it’s not a linear thing, but this is a decent estimation). I set the calibration on June 7th (a little less than a month ago), and it’s changed in frequency by about 0.060ppm since then. Since this is a 12MHz TCXO, 0.060ppm is a 0.72Hz change.

First, an image of the TCXO’s raw frequency vs the temperature compensated frequency. You can see the compensated frequency is much less noisy and much closer to 0ppm.

Image

Zooming in to just the temperature compensated frequency:

Image

99.9% of all samples were between -0.030ppm and -0.072ppm, a 0.042ppm range. This range is my clock’s uncertainty. The situation is slightly better than that, as 24 hour periods have a smaller range. You can see the aging is around 0.015ppm/week (1ppm/year is roughly 0.019ppm/week).

The new boards also have a LSE, but it’s just a regular crystal. I’m using TIM14 to compare the LSE frequency to the TCXO.

Some notes about measuring the LSE:

  • To lower the interrupt rate, I used the MCO to get LSE/128, and then TIM14’s input capture divides that by /8 to get a final interrupt rate of 32Hz.
  • TIM14 is a 16 bit timer, and TIM2 is a 32 bit timer. I used both to measure the exact difference in length of 1 second between the LSE and HSE.
  • The RTC’s frequency adjustment is in steps of 0.954ppm units. So I used dithering to average out the error. I set a new RTC adjustment every 30 seconds
  • I configured the RTC to have 1/1024 second units (slightly better than 1 millisecond)

The green is the difference in frequency between the LSE and HSE. I compared against the temperature compensated frequency from the HSE. The purple is the RTC frequency adjustment value used.

Image

The RTC clock was set to a 0 second offset at the start and left to run only on frequency control. The offset of the RTC clock was compared to the GPS module’s PPS. The blocky nature of the purple line comes from the 1/1024 second unit limitation. I’ve included three frequency error lines to show the ranges of frequency error.

Image

Bonus pictures:

Temperature change between every 64 second reporting period.

Image

Coin cell battery verses temperature (adjusted for changes in supply voltage).

Image


Leave a Reply

Your email address will not be published. Required fields are marked *