STM32F030 custom board

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

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

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

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.

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.

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.

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

Did you factor in the variations in vcc and accuracy on the temp measurement?

simonf wrote:Did you factor in the variations in vcc and accuracy on the temp measurement?

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.

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.

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.

Pretty impressive results. Which TCXO did you use? Where did you source it?

ahull wrote:Pretty impressive results. Which TCXO did you use? Where did you source it?

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.

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

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

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 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 ;-( )

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

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