Yet another DIY GPSDO - yes, another one

[thinkfat]

Today, I decided to disable the SBAS option which initially had shown a reduction of the ionospheric errors that normally account for most of the 7 to 8ns phase wander in the output from my G3RUH based GPSDO since I suspected this was the 'low hanging fruit' most likely to suffer the attentions of the Russian military's electronic countermeasures division.

 After allowing ten minutes for things to settle down, I did see a significant improvement over the 5ns pk-pk phase wander in between the randomly spaced 'transient events' over the past 3 weeks or so. IMO, the 1mHz frequency accuracy you mentioned can easily be attained with a modernised version of the G3RUH design (in peace time at least!) but bearing in mind that a 1mHz offset requires a sustained 100ps per second phase drift rate (one full cycle slip at 10MHz over a 1000 second interval), you can be the judge of that by examining the 10 screenshots taken over a 20 minute time period started just after the GPSDO had recovered from its loss of SBAS assistance (or hindrance!) that I've attached to this reply.

I've experimented with using SBAS, too, reasoning that it would help timing accuracy as much as it does for positioning, but I found, like you, that it doesn't help a lot. On the contrary, when I logged the TIC output from my GPSDO over a day or so, I would frequently see phase jumps of the GPS/GNSS time signal against the OCXO in the 15-20 ns range that went away when SBAS was disabled. Now I only enable it during survey-in for faster convergence of the true position. I generally found it to be a bad idea to have too many GNSS constellations enabled in a receiver and I stay clear from GLONASS in particular. GPS and Galileo coexist nicely, though, and help with having good coverage even if you antenna position is compromised.

[Johnny B Good]

@thinkfat

 I'm in total agreement with all of your observations. I had some doubts over the SBAS issue until I disabled it just over 12 hours ago  but not any more from what I'm now seeing in the 'scope traces. 

 I'd read about similar doubts over SBAS about two years ago (possibly one of your postings) but I was still making do with fake M8N modules back then when I tried testing the use of SBAS before deciding that on balance, it wasn't doing me any favours. The only reason as to why I decided to enable it again was on account I'd acquired a set of three genuine M8T modules for cheap from an Amazon seller (late last year afaicr) and had upgraded the MK II gpsdo with one and three weeks ago thought it might be worth trying the effect of SBAS once more with a timing module.

 The test initially suggested this was providing a benefit during the first week but since I was still fine tuning the temperature controlling algorithm, I was probably not able to see these wobbles through those induced by my own testing until more than a week had gone by when I actually witnessed one such event taking place. I'd forgotten about the (seemingly non-) issue of SBAS hindrance by then and started hypothesising about the possibility of electronic countermeasures being used in the Ukraine as a more palatable  alternative to my LPRO starting to 'go bad'.

 At the time, overlooking the possibility that using the SBAS option was the cause as now seems to be the case, the only way I could prove whether it was the LPRO or some weirdness with the GPS, was to buy another rubidium oscillator, hence my purchasing, literally, the last SA22C in the shop.  https://tinyurl.com/258vuuhj

 It was quite a shock to discover that the supply of salvaged LPROs and the slightly less desirable second best FEI rubidium oscillators had completely dried up, leaving only the overpriced Temex units with their failing electrolytic caps which I wouldn't give tuppence for, let alone the 500 dollar and up prices being asked. I guess I've only just discovered the reason for the apparent waning of interest in DIYing a rubidium oscillator based home lab frequency standard.

 Anyway, here's another sequence of screen grabs taken overnight which seem free of the SBAS nonsense. And, btw, just in case there is any confusion as to what the scope traces are displaying (I didn't explicitly describe them afaicr), the CH1 (yel) is the gpsdo output triggering the timebase (hence it remaining fixed in place despite the 4 to 5ns wobbles it's imposing on the LPRO trace shown in blue on CH3.

 Basically, the LPRO is acting as a referee by which to judge the wobbly behaviour of the gpsdo due to mostly ionospheric disturbances that the correction data provided by the gps SV's are unable to fully cancel out. It has the benefit of not being molested by ionospheric disturbances and all the other smaller imperfections of the GPS system as a time transfer system - only the more mundane issues that plague all free running oscillators (temperature, pressure, psu voltage variations etc plus, of course, calibration error).

 A rubidium oscillator offers the electronic hobbyist the best chance of generating a reference at least stable enough for the hour or so it takes to observe the disciplining action of all (bar lab grade) gpsdos. In my case, with the effects of temperature and pressure variations being almost completely mitigated, it is more than good enough for the task, even if calibration is not absolutely perfect when the calibration reference happens to be the DUT itself

[Johnny B Good]

 Well, it seems the funny business with the GPS looks very much like it was a consequence of enabling SBAS (hindrance) so my thanks for reminding me of your experience testing out its worth. Disabling it certainly appears to have restored the status quo as the following seven screen grabs covering the remaining  four hours of the day (and 40 minutes more) seem to indicate.

 I'll resist the urge to twiddle with the calibration knob until at least tomorrow afternoon simply to give the GPS a chance to show its hand.

[Carsten]

Since we seem to keep hijacking André's thread for topics only peripherally related to his project, how about opening a separate GNSS timing discussion thread?

I've experimented with using SBAS, too, reasoning that it would help timing accuracy as much as it does for positioning, but I found, like you, that it doesn't help a lot. On the contrary, when I logged the TIC output from my GPSDO over a day or so, I would frequently see phase jumps of the GPS/GNSS time signal against the OCXO in the 15-20 ns range that went away when SBAS was disabled.

For the ZED-F9T I'm tinkering with u-blox explicitly warns that using SBAS can degrade timing performance, which is why it's disabled by default.

Now I only enable it during survey-in for faster convergence of the true position.

As a superior alternative to SBAS, you can use an RTK reference for survey in, if your receiver supports it. The majority of German states provide these free of charge thanks to open data laws.

[Johnny B Good]

 Did anyone notice a complete 3 or 4 minutes long black out of GPS a few minutes ago (around 14:15 UTC 2022-08-17)?

 I wasn't monitoring with U-blox's ucentre at the time - just spotted my gpsdo's 4 per second PPS indication of loss of sync and the consequent wiping out of the rubidium trace against that of the gpsdo with the infinite persistence that normally shows a 30ns band over 24 hour and longer periods.

 I connected the usb link and fired up ucentre to check the state of play, by which time service had been resumed with 5 satellites above the 30 deg elevation threshold, suggesting it hadn't been a case of no in service satellites being available to appear above the threshold as has happened in the past when I'd been testing with 45 and 50 degree elevation mask angles.

 It took some 5 or 6 minutes to settle back down after the GPS SV's had come back on line, leaving the earlier phase difference between the ruby and the gpsdo within a ns of their previous state recorded just an hour earlier as can bee seen in the attached screen shots (time stamped in BST).

 Please note that the 3 or 4 ns drift between the last two screen shots are typical of the +/- 3ns disciplining 'wobble' caused largely by the combination of imprecise wide area ionosphere correction data carried in the GPS message packets and in my case, the limited averaging time of a simple G3RUH based design of gpsdo.

[EDIT]

 I've double checked the antenna connections and it looks like it may well have been a connection issue with the cheap Banggood sourced Wilkinson splitter (modified with a DC-block) and/or the half meter SMA ended cables I've kept in line ever since I'd tested out a second M8T module a fortnight or so back in readiness to experiment with a long time constant version of the G3RUH setup to discipline the ruby to deal with its long term ageing drift (circa 1E-13 to 1E-14 per day).

 Although antenna connection issues with my setup would appear to be the most likely cause of this loss of GPS signal event, I'd still appreciate any reports that it wasn't due to the GPS system itself dropping out during the time period in question.

 In the meantime, I'll use the time honoured method of retensioning the suspect SMA-F contacts with the aid of a jeweller's loupe and a pin.

[MIS42N]

Did anyone notice a complete 3 or 4 minutes long black out of GPS a few minutes ago (around 14:15 UTC 2022-08-17)?

I have a log for that period that would show loss of fix, not even a glitch.

[Johnny B Good]

Did anyone notice a complete 3 or 4 minutes long black out of GPS a few minutes ago (around 14:15 UTC 2022-08-17)?

I have a log for that period that would show loss of fix, not even a glitch.

 Thanks for confirming my belated suspicions.

 I have in times past seen half the constellation plunged into an out of service status (blue in u-centre's sky map plot) yet still generating strong signals (40 to 52 dB C/No figures) so a GPS rather than an antenna connection issue in those cases.

 My initial thought this time round being that this was yet another one of those (mercifully) rare events or maybe the more common situation where the odd out of service SV had grown from its ever present count of one or two to three or more and had all congregated in the cone of view set by the elevation mask (now a more encompassing 30 deg) with no in service SVs in that privileged patch of the sky to provide a valid timing lock.

 By the time I'd linked my gpsdo to my desktop pc's winXP VM via the required 5 metre long USB A to micro B link cable, the problem had gone away. It was only after posting my report and query that it occurred to me to manipulate the connections to the antenna splitter whilst monitoring the signals with u-centre to check for a pesky intermittent connection (so often the most difficult of faults to pin down) to see if I could find a more likely cause for the event that I eventually spotted a strong hint of its true nature - a bad contact in one or more of the three SMA-F connectors used by that Wilkinson combiner/splitter.

 Apart from the SMA antenna socket on the gpsdo itself, all other patch cables are terminated with SMA-M plugs both ends. I've let this 'sleeping dog lie' until just this moment since I've only modded that one splitter with a DC blocking cap and wanted to minimise disruption to the GPS reference.

 In hindsight, Gawd knows why, disruption is disruption and the gpsdo always resumes its original phase relationship with the ruby +/- a soupcon of disciplining wander and the imperceptible ruby drift over the twenty minutes or so that it takes to retension the contacts and allow it to settle back down after everything has been reconnected.

 When I first observed this phenomena using cheap M8N modules, my initial thought had been "What a remarkable coincidence that it should phase lock so close to its earlier phase relationship with my free running OCXO despite the PLL operating at just 1% of its frequency against the 100KPPS output from the M8N.".

 My instinctive thought had been to expect it to resume lock with a completely random phase offset but since I've observed exactly the same behaviour time after time over the past two years or so (and with better and better repeatability as each upgrade was applied), I have to assume that this is the mark of a true phase lock loop despite the seeming opportunity for a divide by 100 to add an element of randomness to the amount of phase offset upon resuming phase lock.

 I don't know for sure but I suspect disrupting the GPS signal on an FLL based GPSDO against a stable enough independent reference such as a DOCXO or Rubidium oscillator will show a random phase offset upon re-establishing lock with the GPS timing signals. If I'm correct in this hypothesis, it would make for a simple test to check whether a GPSDO is using a PLL or an FLL algorithm to discipline its LO. 

[MIS42N]

When I first observed this phenomena using cheap M8N modules, my initial thought had been "What a remarkable coincidence that it should phase lock so close to its earlier phase relationship with my free running OCXO despite the PLL operating at just 1% of its frequency against the 100KPPS output from the M8N.".

 My instinctive thought had been to expect it to resume lock with a completely random phase offset but since I've observed exactly the same behaviour time after time over the past two years or so (and with better and better repeatability as each upgrade was applied), I have to assume that this is the mark of a true phase lock loop despite the seeming opportunity for a divide by 100 to add an element of randomness to the amount of phase offset upon resuming phase lock.

 I don't know for sure but I suspect disrupting the GPS signal on an FLL based GPSDO against a stable enough independent reference such as a DOCXO or Rubidium oscillator will show a random phase offset upon re-establishing lock with the GPS timing signals. If I'm correct in this hypothesis, it would make for a simple test to check whether a GPSDO is using a PLL or an FLL algorithm to discipline its LO. 

Isn't that how PLL work? I confess to not really understanding them, but I think of it like taking two square waves and exclusive or (XOR) them. Both low or both high, low output. opposite phase, high output. If they are out of phase by 1/4 the period of the frequency, 50% output when averaged. If that output is used as the disciplining voltage, and the control voltage required is 50% of the pulling range, then the system will settle with the two inputs offset by that 1/4. If there is an interruption, on resumption the two waves will be offset by something different, but if it is between 0 and 1/2 the period it will be in range for the PLL to take over and drag one of them back to the 1/4.

So only if the two drift apart more than 1/4 the period the frequency the PLL uses for comparison, will it jump to a different cycle to lock.

The system I use is a sort of PLL with a 1 second period. Assuming the OCXO free running with the last known control voltage is within 1 part per million (which is pretty relaxed) then it will take several days for the two to drift apart so far that (in theory) they can't be bought back in phase. In practice if the GPS gives a minute of "no fix" the GPSDO system forces a reboot. Only happened once. What happened was the 1pps is supposed to arrive inside a 1ms window, and is ignored otherwise. The OCXO I was using developed an internal fault and the control voltage input went from high impedance to 5 kohm, the circuitry couldn't correct so the OCXO drifted off eventually going outside the window. Game over.

[Johnny B Good]

@MIS42N

 Your description of the way an XOR gate phase comparator (PC1 in the case of the 74HC/HCT4046 - see attached datasheet) is pretty well spot on. In the case where the PLL is comparing the reference and VCO or OCXO frequencies directly (in our case 10MHz) without the complication of a divide by 100 (1000 in the original G3RUH design), the process is exactly as you've described.

 What I couldn't quite get my head around is how, despite this complication, it manages to return to within a ns or two of its original phase offset against a highly stable independent reference after half an hour or more of interruption (either by loss of the GPS/GNSS timing signals or simply from an interruption of power - the result is exactly the same).

 One thing I've realised is that I've sort of got the effect of the divide by 100 ass about face as far as the OCXO goes. To slip out of phase, it has to drift by 50 cycles or more before the PLL sees its input stretched to the breaking point at 100KPPS. Even then, if it slips out of phase, it doesn't matter about which particular cycle of the 10MHz corresponds to the locked state (loss of the GNSS timing data or a cold start upon a resumption of power event), the resulting traces will (and do) look exactly the same.

 That just leaves me the puzzle as to how the PLL "chooses" the exact same pulse out the 100,000 pulses synchronised exactly (give or take the 48MHz clock jitter) when an M8T (or N) is programmed to output 100KPPS. Clearly the PLL can't make such a "choice" so I'm obviously missing something (probably something blindingly obvious in my case) here.

 Having taken a break from writing this reply, I've had time to mull over this "conundrum" a little more and I think the key fact I've overlooked on this side of the problem is that the 100KPPS I'm using is locked and synchronised to the GPS top of the second PPS pulse and that any one particular pulse out of the 100,000 will, like the ones generated by the OCXO's divide by 100 circuit, be aligned to the original PPS top of the second pulse, any of which will repeat the same phase displacement relative to an independent high stability 10MHz reference.

 My first instinct had been to expect any random but fixed offset between the GPSDO's output and an independent reference of similar stability (circa 3.32 x 10E-14) after each restart of the GPSDO. The surprising fact that the offset was anything but random after such interruptions left me with a puzzle I couldn't quite figure out without spending the time to properly analyse just what was going on, time quite frankly ICBA to spend in finding an explanation for this observed behaviour so it was just left as an unsolved puzzle until now. It just shows how wrong "instinct" can be when it comes to puzzles like this.

 As for my hypothesis that an FLL based GPSDO will show a random but fixed phase offset after such interruptions, I'll leave that to be tested by those who've built one of Andrew's low cost DIY gpsdos and just happen to have a suitable independent high stability 10MHz reference oscillator to hand (very few if any, I rather suspect in this case ).

[MIS42N]

Having taken a break from writing this reply, I've had time to mull over this "conundrum" a little more and I think the key fact I've overlooked on this side of the problem is that the 100KPPS I'm using is locked and synchronised to the GPS top of the second PPS pulse and that any one particular pulse out of the 100,000 will, like the ones generated by the OCXO's divide by 100 circuit, be aligned to the original PPS top of the second pulse, any of which will repeat the same phase displacement relative to an independent high stability 10MHz reference.

I think you have your answer right there. Your 10MHz hasn't drifted perceptibly, and your 100kpps gets pulled back to match the 1pps as soon as it is available. Resume normal service.

[thinkfat]

@MIS42N

 Your description of the way an XOR gate phase comparator (PC1 in the case of the 74HC/HCT4046 - see attached datasheet) is pretty well spot on. In the case where the PLL is comparing the reference and VCO or OCXO frequencies directly (in our case 10MHz) without the complication of a divide by 100 (1000 in the original G3RUH design), the process is exactly as you've described.

 What I couldn't quite get my head around is how, despite this complication, it manages to return to within a ns or two of its original phase offset against a highly stable independent reference after half an hour or more of interruption (either by loss of the GPS/GNSS timing signals or simply from an interruption of power - the result is exactly the same).

 One thing I've realised is that I've sort of got the effect of the divide by 100 ass about face as far as the OCXO goes. To slip out of phase, it has to drift by 50 cycles or more before the PLL sees its input stretched to the breaking point at 100KPPS. Even then, if it slips out of phase, it doesn't matter about which particular cycle of the 10MHz corresponds to the locked state (loss of the GNSS timing data or a cold start upon a resumption of power event), the resulting traces will (and do) look exactly the same.

 That just leaves me the puzzle as to how the PLL "chooses" the exact same pulse out the 100,000 pulses synchronised exactly (give or take the 48MHz clock jitter) when an M8T (or N) is programmed to output 100KPPS. Clearly the PLL can't make such a "choice" so I'm obviously missing something (probably something blindingly obvious in my case) here.

 Having taken a break from writing this reply, I've had time to mull over this "conundrum" a little more and I think the key fact I've overlooked on this side of the problem is that the 100KPPS I'm using is locked and synchronised to the GPS top of the second PPS pulse and that any one particular pulse out of the 100,000 will, like the ones generated by the OCXO's divide by 100 circuit, be aligned to the original PPS top of the second pulse, any of which will repeat the same phase displacement relative to an independent high stability 10MHz reference.

 My first instinct had been to expect any random but fixed offset between the GPSDO's output and an independent reference of similar stability (circa 3.32 x 10E-14) after each restart of the GPSDO. The surprising fact that the offset was anything but random after such interruptions left me with a puzzle I couldn't quite figure out without spending the time to properly analyse just what was going on, time quite frankly ICBA to spend in finding an explanation for this observed behaviour so it was just left as an unsolved puzzle until now. It just shows how wrong "instinct" can be when it comes to puzzles like this.

 As for my hypothesis that an FLL based GPSDO will show a random but fixed phase offset after such interruptions, I'll leave that to be tested by those who've built one of Andrew's low cost DIY gpsdos and just happen to have a suitable independent high stability 10MHz reference oscillator to hand (very few if any, I rather suspect in this case ).

I'm not quite sure how your failure case would look like exactly, but a simple XOR PLL obviously cannot deal with a GNSS outage situation at all. As soon as the time signal stops, the control voltage would either become 0 or "VDD", depending on the state of the XOR output. Keeping the time signal running with no GNSS coverage is useless of course, as the output would not be more accurate or stable than the receivers internal reference.

But of course the phase of the output would return to exactly the same offset as before, why wouldn't it? That offset is pretty much defined by whatever duty cycle of the phase comparator (and thus \$V_{tune}\$) represents the target frequency exactly. It would change over time with the aging of the OCXO.

[Johnny B Good]

@MIS42N

 quoted text snipped for brevity to make up for my far from brief reply

I'm not quite sure how your failure case would look like exactly, but a simple XOR PLL obviously cannot deal with a GNSS outage situation at all. As soon as the time signal stops, the control voltage would either become 0 or "VDD", depending on the state of the XOR output. Keeping the time signal running with no GNSS coverage is useless of course, as the output would not be more accurate or stable than the receivers internal reference.

But of course the phase of the output would return to exactly the same offset as before, why wouldn't it? That offset is pretty much defined by whatever duty cycle of the phase comparator (and thus \$V_{tune}\$) represents the target frequency exactly. It would change over time with the aging of the OCXO.

 Not only ageing but also a surprisingly sensible ambient temperature effect on the frequency stability of the OCXOs I'm using (I now see the point of using DOCXOs  ) This manifests itself as a shift of a few hundred μV on the median operating point of the gps disciplining voltage variations holding the ocxo on frequency.

 Looking at the datasheet for the 74HC(T)4046A, it seems the other two PDs (PDs 2 and 3) are really only appropriate to keeping a full frequency range VCO locked to a reference frequency - PD1, the XOR detector is the only one suited to this application, keeping an OCXO with its extremely tiny tuning range (a few ppm at most) locked to the averaged long term timing stability of a GNSS. Also, according to the data sheet, the output will rest at half the Vdd voltage in the presence of noise (which includes the 4Hz PPS frequency I'd programmed the U-Blox to emit during  a loss of GPS timing lock) or absence of input to the Sig input pin.

 I'd thought I might be able alter the duty cycle of this 4Hz pulse to more closely approximate the required EFC to hold the unlocked OCXO frequency closer to the 10MHz than it otherwise does but this proved to be ineffective since it effectively equates to the "noise" condition regardless of duty cycle.

 The simple XOR detector (and its software equivalent) is the best option in this case. Of course, the phase displacement whilst locked will vary due to both ageing and temperature effects but by how much is a question I've yet to try and find an answer to.

 I'm primarily interested in the magnitude if this phase displacement due to the 3 to 5 degree changes in room temperature since, if this amounts to more than 2 or 3 ns's worth, it'll confuse my frequency stability measurements against the GPS reference since comparing the variation of phase between the ruby and the GPSDO is the only practical way I have to measure frequency drifts at 10MHz that are now down in the μHz range.

 My impression of this temperature related shift in phase is that it is well below 5ns, quite possibly less than a ns or two at most but that's only a 'gut feeling' from my observations so far.

 I've figured out a way to test my collection of OCXOs for this temperature effect. It's really only a matter of bread boarding a test circuit using a 74HC4046A and a couple of 74HC390s, to divide the ruby and the OCXO frequencies down to 100KHz, , including the LPF values in the feed to the LMV538 cmos RRO opamp that drives the OCXO's EFC pin, to simulate the setup used in my gpsdo but without the troublesome variations inherent to any GNSS derived timing signal.

 That setup will give me a fixed phase relationship for a constant temperature applied to the OCXO under test (I could actually use another OCXO held to a constant temperature instead of the ruby), allowing me to test its temperature sensitivity independently of all the other effects in the gpsdo itself. It's just a matter of getting a "round tuit" to set it up.

 Although the effect of ambient temperature on the GPSDO's OCXO seems an insignificant one (it gets swamped by the disciplining process), I might find an example in my collection (seven in total) with a much lower tempco that I can swap out to reduce this effect even further.

 That being the case, I've even more motivation than merely satisfying prurient curiosity as to the magnitude of this phase offset variation with temperature, to actually put the effort into carrying out this test. I might discover a particularly good example with excellent immunity to ambient temperature changes that will allow me to use an even longer time constant PLL filter to reduce the disciplining induced phase shifts even further.

[geggi1]

Hi!
I have been following this tread for a while and got two questions.
1. Is there a PCB layout for this project?
2. You have made the design on a STM32F411 Blackpill. Would it be possible to run this on a Bluepill with a propper STM32F103T8C6?

The reason I'm asking about the Bluepill is that i bought a bunch of them when they where 2-3$

[nealix]

There is not yet a PCB board layout.   The author of the thread has taken the summer off, possibly traveling or work related.

I do not know if it would work on the blue pill.   I don't think the code is using all the CPU power of the black pill, in fact
I know that it does not.   Larger LCD's might eat up more CPU, but if you stick to a small OLED or even skip an LCD and
use the serial output, I don't know why it could not work.   The key might be that the schematic shows 10MHz OCXO
feeding straight into the CPU on a GPIO pin.  So that means your STM CPU of choice needs to be fast enough to run all
the program code, but also do so in time to count the next 10MHz cycle coming into the GPIO pin.   The other thing
different about the two CPU types;  You would need to check that the blue pill has the same counters and interrupt
handlers, or else modify the code.

The two main problems with the project at the moment is that the global supply chain issues have made the STM chips
almost impossible to obtain, and the author of this thread has gone missing.

That said, building the most recent version of the code and the schematic on a bread board, it works JUST FINE
using the existing FLL code and keeps within .002 Hz of frequency, which is far more than good enough for
home radio and lab usage, without the complication and endless hours of fussing around with the lars PLL for example.

This thing works as it currently is, and works well.

When and if Andrew returns to this thread he started, I was going to ask him for the PCB design library files (Kicad symbol and footprint),
for the blackpill, and then was going to have a try at learning Kicad and creating a PCB board.

Hope that helps as far as status goes.

Neal

[AndrewBCN]

Hi geggi1,

Hi!
I have been following this tread for a while and got two questions.
1. Is there a PCB layout for this project?

Not yet, no. For various reasons : lack of time, the fact that the hardware has not yet stabilized, and also the fact that it works well enough on a $5 breadboard.

2. You have made the design on a STM32F411 Blackpill. Would it be possible to run this on a Bluepill with a propper STM32F103T8C6?

The reason I'm asking about the Bluepill is that i bought a bunch of them when they where 2-3$

No, it won't work on a Bluepill without extensive modifications to the firmware. Also it works on both the STM32F401 and STM32F411 Black Pills, which are available respectively under $5 and under $10.

[Scrachi]

Hi,
Outstanding project thanks for sharing!
I'm currently building one myself and for now all seems running as expected, just a refreshing issue with the spi lcd so I've revert back to the I²C version. Also I've modified the psu circuit to update it with a LM7805 and adding the couple diode and polyfuse for the protection.

About the PCB, someone are currently working on one ? If not I will trying to do one myself and if it seems not too ugly I will share.


Thanks.

Mick

[Scrachi]

Hi,

Here is a v1 of the PCB including :
- LM7805 base psu
- AHT20 sensor
- INA219 current sensor
- SSD1306 LCD
- picDIV 1PPS output
- 10Mhz sine output
- Some status led
- ...




As a newbie on PCB designing... do not hesitate to punch me if any thing is wrong   


I will sent it for production and share the sources after testing if all is OK.


Mike

[TomD]

Hello team,
first I am following the project for a while and have to say thank you for Andrew and all contributor!!!
Now I have ordered and received nearly all parts. So I would like to start this week with a bread-board test (just waiting for the 20K and 10microH part).
But I recognize that my GPS module has no 1pps signal out (see pic below). The module had a green LED blinking each second when the sats are received in a proper way.

Question: Can I take the 1pps signal from there? It is not buffered and came from PIN3 of the NEO-M8N-chip.
The NEO-M8N data sheet said about PIN3:
Parameter Symbol Min Typical Max Units Condition
Digital IO pin low level output voltage V OL 0.4 V I OL = 4mA
Digital IO pin high level output voltage V OH VCC–0.4 V IOH = 4mA

So just 0,4V for Low level but missing info for High level.

Any good advice?
Many thanks in advance !!!

[Scrachi]

Hi Tom,

Just checked on mine, the pps output pin is directly connected to NEO-M8N's PIN3 so I guess you can pickup the signal directly on NEO-M8N's pin3.


Mick

[TomD]

Hi Mick,
thank you for the fast reply and the good news so I didn't need any ops or buffer at that point.
Your PCB looks good to me! Good job!!!
Just one comment, I didn't know the size of the PCB but I would suggest to have it 100mm on one side so it could directly used for some cases (EURO-PCB).

Again thank you and lot of success with your project.

One question to Andrew.
I recognize Frequency Counter on page 3 of the KIDCAD.pdf. Is this still 'work in progress'? Not clear how it will work? I read the messages but couldn't found so much about...
If I had a wish free, (I am HAM radio operator) so I would like to see an option that allow higher/ other frequencies.. like 25/50/100 MHz. More or less a high quality signal generator.   

Thank you Andrew, again for your great project. 

[Scrachi]

Just one comment, I didn't know the size of the PCB but I would suggest to have it 100mm on one side so it could directly used for some cases (EURO-PCB).

Hi Tom,
Good point! The pcb was 91X94mm, I've updated it to 100X94mm

Thanks.

Mick

[TomD]

Team, I have a problem to compile the v 0.05j. Nearly all options are of (marked //), just the OLED is on. (Issue solve by reload of the STM32 package)

Arduino: 1.8.19 (Windows Store 1.8.57.0) (Windows 10), Board: "Generic STM32F4 series, Generic F411CEUx, BMP (Black Magic Probe), Enabled (generic 'Serial'), None, Low/Full Speed, Smallest (-Os default), None, Newlib Nano (default)"

The bold text is in red. I tried also v6 with same result. All libraries are loaded.

Have anyone an idea? Sorry my Arduino knowledge is basic level.
One remark the 'blink-sketch' runs on the board.

But just on the compiling level I run on following errors....

exit status 1
Fehler beim Kompilieren für das Board Generic STM32F4 series.

(I changed the bold area (in Arduino IDE it is red))

[AndrewBCN]

Hi Tom, hi everybody, and sorry for the long silence, I have been just overwhelmed with work.

...
Question: Can I take the 1pps signal from there?
...

Yes!

[AndrewBCN]

Team, I have a problem to compile the v 0.05j.
...

Did you select Black Pill STM32F411 CEU6 ?

[TomD]

Hi Andrew, welcome back 

thank you for the quick response.
- Yes, I have a STM32 F411 CEU6 but I guess it doesn't matter because I just test to compile (without sending to the MCU)
- I already successful install the sketch 'blink' and a blue LED blinks every second 
- I check all libraries several time and deselect  all options except the OLED

So what could the statement 'undefined reference to `Serial1' in the error message mean? The required libraries are installed...

Maybe the Arduino IDE set up is wrong (see pic below) can you please verify?

Many thanks in advance.