($40 GPSDO working well now, my mistake)

[texaspyro]

It has the GPS control messages in the strings... they are the $PFEC sort of things.  There is also $XXGLL messages... I bet the XX gets patched to match the NMEA GLL messages.

[cdev]

The embedded OS is something called Nios II that runs on the Altera FPGA

[CJay]

The embedded OS is something called Nios II that runs on the Altera FPGA

Did a little looking around and NIOS appears to be a softcore RISC CPU design, not an OS as such, there's a few references to disassemblers which may be useful if we have a ROM dump from the TruePosition board?

https://www.adveda.com/

https://github.com/KarmaQueen/Nios-II-Disassembler

There are also tools in the Altera toolchain that might e useful, I *think* the toolchain includes a C/C++ compiler with the NIOS core but I'm far from an FPGA expert (I can usually recognise an FPGA from a few paces but that's about it)

[cdev]

I am hoping to use a UG-2864HSWEG01 OLED display I have.

Its quite popular. Its display is controlled by an embedded controller chip, the SSD1306,

Below are the documentation on the Furuno GPS receiver used in it, and the OCXO in my board.

[pigrew]

There are also tools in the Altera toolchain that might e useful, I *think* the toolchain includes a C/C++ compiler with the NIOS core but I'm far from an FPGA expert (I can usually recognise an FPGA from a few paces but that's about it)

Right. There are actually two Altera PLDs on the board. An Altera MAX EPM3064ATC100-10. This IC has an internal EEPROM, and its firmware likely cannot be read-back out of the device. This is what I'd consider a CPLD, with a reasonable number of macrocells, each of which is effectively big lookup table.

The second is a Altera APEX EP20K160ETC144-2X, which is a FPGA. It has a large number 6400 tiny logic elements. This is where the soft-processor would live. It loads its configuration from an external EEPROM or flash. Generally the soft-core's programming will be loaded from FPGA's RAM which would have been previously set by the configuration RAM.

I'm not sure exactly what the structure of the ROM is in the altera binary. We may need to extract it somehow before decompiling it. As far as I know, the binary configuration format is not published.

[pigrew]

SCALEFACTOR probably maps the desired frequency control word to the EFC DAC setting... basically the "P" term in a PID controller.

The value makes sense if it is Hz/mV. The training tunes the OCXO by 500*(4.096 V)/2^16=31.25 mV. and I measured a frequency shift of about 0.12 Hz. My Bliley OCXO gives a value of about 3.663019e-3. This is within its datasheet specification of 2.5 Hz/V Min to 5.5 Hz/V Max.

[cdev]

I think the $TRAINOCXO may have significantly sped up my TP's time interval from power on/cold start to first attainment of GPS lock and 1pps.

Also, I like the Z3801A's LED  layout (below)

[pigrew]

I think the $TRAINOCXO may have significantly sped up my TP's time interval from power on/cold start to first attainment of GPS lock and 1pps.

I'm still getting occasional unlocked events, even after the OCXO tuning, anecdotally every five hours or so.

I've started playing with the $SETGAIN parameter. It seems to be in units of hundreths. Sending "$GAIN 95" will echo back with $GAIN 0.95. It seems like the gain can be set to both positive and negative values, and the values can be in the thousands. Setting too large (positive) of a value will cause a loss-of-lock (-10.00 or 10.00), and the tuning voltage will go haywire. Sending "$SETGAIN" will return a value, but I'm not convinced that it'll return the current value. I think that it'll just set the value to whatever happens to be in some memory location at that moment.

Setting the gain to be -1.00 does seem to make the system unstable (As I'd expect if it were a multiplier of the P in a PID controller).

I think gain is only applied when status=0.

I've also been seeing slight oscillations in the system response of the GPSDO. PPSDBG:4 (phase?) would always stick at around +4 or -4, and rarely settle on 0. I'm going to set my gain to 0.25, and see if I can maintain a lock all night.

I never found a way to set the SCALINGFACTOR to a value, it seems to only be settable via OCXO training, but the GAIN is likely multiplied by the SCALINGFACTOR, so that's good enough.

In other news, I found (and fixed) a bug in my display-controller causing the USB serial port to screw up. The controller is pretty stable now. It also shows the duration of the current lock. It's convenient that it automatically sends the $PROCEED and $PPSDBG commands when needed.

Also, I like the Z3801A's LED  layout (below)

Feel free to edit the display controller's code and do whichever setup you'd like. It'd be fairly easy to set GPIO ports based on the GPSDO state (unless you wanted more complicated logic?).

[cdev]

Thats what I was thinking I might try to do.

If I can figure out how the process works!  I have an ST-link 2 coming soon so I should be working with the IDE verson and not your released binary.

You shouldn't feel bad about your criticism of the STM32 Blue Pill's USB setup. You are by no means the only person making those complaints, I have read them quite a few times now.

SO now I have two more BPs coming also in the mail so I will be a little more adventuresome. I am just quite cautious about damaging things sometimes.

Economists would call it "risk aversion".

I have to start thinking about which of my many wall warts, etc. I should use for the power supply. I think the $TRAINOCXO is meant to entrain the board to specific case environments and power supply conditions, so the more stable that is the better. 

So what are folks feelings on case ventilation? Closed case with no ventilation holes seems to be common in commercial units.

My unit came shipped to me with some nice closed cell polyethelene foam that had a square hole the size of the oven already cut in it. So I trimmed that a bit and put a little top on it with scotch tape and tried putting it around the oven to see if it increased stability. It was hard for me to tell because right now I am not parsing the output in any way.

It is clear though that when I have my little desk fan going and the cardboard box my GPSDO is currently in is open the board seems to go out of lock more.

Antenna placement is still everything. When I am using an outdoor antenna (stuck in the middle of my back yard because that the best place for sky view) the GPSDO almost never goes out of lock.  When the antenna is indoors, even next to the window (like it is now) every once in awhile it will lose lock and go into holdover and start counting seconds.

So any ability to adjust the gain might be helpful when the antenna is indoors.

So, just turned it on, after it being off for the night, it is starting to get much cooler here, fall weather and the ambient temperature was around 20 C even though its sitting in a sunny window area. I wonder if the scalingfactor also takes the ambient temperature into account? If it only has one temperature sensor I guess it really cannot, except at the very beginning of being on.

I've read elsewhere that the typical OCXO is influenced somewhat by both barometric pressure and humidity - more so than I had realized.

I recently ordered two barometric pressure sensors that also measure temperature and one that measures all three, temperature, pressure and humidity.

I would like to have some means of allowing all of the various parameters to be captured and recorded on my only always on computer, a Raspberry Pi. One way of doing it is by parsing a UART stream - console-like.. another way is by saving the data to a file in some delimited format and then grabbing it somehow at regular intervals.. that can also be done with HTTP and often thats the easiest way. (My old school means of doing it is by using any command line program that can accept and fetch a URL- encoding the parameters in the one line request. So thats a good excuse to give the GPSDO some basic network capabilities.. if its possible. (No security is needed as it would just be requesting a public web page) Any of dozens of methods just about would work.



Telling it about what to expect from small voltage shifts as far as frequency based on past performance under similar conditions is probably what the entrainment is all about.


I'm attaching a image I saved of a nice case implementation.. simple, seems to balance cost of case and size of display and LEDs well.  This one uses an LCD.

Something even more informative in a small space could be done with a graphics OLED with icons or very small graphs.. perhaps..

Dont really need to know location as much as other parameters - but thats easy to change.


Quote from: pigrew on Yesterday at 23:17:38>Quote from: cdev on Yesterday at 18:41:31

I think the $TRAINOCXO may have significantly sped up my TP's time interval from power on/cold start to first attainment of GPS lock and 1pps.

I'm still getting occasional unlocked events, even after the OCXO tuning, anecdotally every five hours or so.

I've started playing with the $SETGAIN parameter. It seems to be in units of hundreths. Sending "$GAIN 95" will echo back with $GAIN 0.95. It seems like the gain can be set to both positive and negative values, and the values can be in the thousands. Setting too large (positive) of a value will cause a loss-of-lock (-10.00 or 10.00), and the tuning voltage will go haywire. Sending "$SETGAIN" will return a value, but I'm not convinced that it'll return the current value. I think that it'll just set the value to whatever happens to be in some memory location at that moment.

Setting the gain to be -1.00 does seem to make the system unstable (As I'd expect if it were a multiplier of the P in a PID controller).

I think gain is only applied when status=0.

I've also been seeing slight oscillations in the system response of the GPSDO. PPSDBG:4 (phase?) would always stick at around +4 or -4, and rarely settle on 0. I'm going to set my gain to 0.25, and see if I can maintain a lock all night.

I never found a way to set the SCALINGFACTOR to a value, it seems to only be settable via OCXO training, but the GAIN is likely multiplied by the SCALINGFACTOR, so that's good enough.

In other news, I found (and fixed) a bug in my display-controller causing the USB serial port to screw up. The controller is pretty stable now. It also shows the duration of the current lock. It's convenient that it automatically sends the $PROCEED and $PPSDBG commands when needed.
Quote from: cdev on Yesterday at 18:41:31

Also, I like the Z3801A's LED  layout (below)

Feel free to edit the display controller's code and do whichever setup you'd like. It'd be fairly easy to set GPIO ports based on the GPSDO state (unless you wanted more complicated logic?).

[pigrew]

I've also been seeing slight oscillations in the system response of the GPSDO. PPSDBG:4 (phase?) would always stick at around +4 or -4, and rarely settle on 0. I'm going to set my gain to 0.25, and see if I can maintain a lock all night.

At gain=0.25, I did lose lock once over-night, but the tuning voltage didn't change much at all during the unlocked period. I still saw oscillations with a period of about 5000s and a tuning voltage amplitude of 200 uV. At 3 V per Hz, this would be about 0.6 mHz. The oscillations are in most of the reported in multiple parameters (both tuning voltage and phase). This is "Good Enough" for all of the uses I have for a frequency standard (I only want need 0.5 ppm accuracy).

Oddly (at least to me), using a larger gain (such as 2.00) has removed the oscillations I see in the tuning voltage. Of coarse, I don't want to make the gain to high, as the OCXO should have better performance than the PPS signal in the short term. If I didn't see it adjusting the tuning voltage, I would have figured that it was just due to GPS inaccuracies, however the voltage oscillation seems to imply that something is wrong.

Re: Thermal environments and case:

The crystal seems to want a very stable temperature, though it should be able to hold temperature steady best if it isn't too well  insulated. I'm still working on a case, I have it in a cardboard box for a moment. I would tend to not provide vents in the can, as I've noticed that drafts will cause frequency shifts.

I stole a power input section from a wireless router board which used 12VDC input. It provides a LC filter, fuse, and a 3.3V DC-DC converter.

[cdev]

Does this mean that USB-to-serial using the USB micro connector on the Blue Pill can be used along with the display controller?

If so that would be absolutely great.

[pigrew]

Does this mean that USB-to-serial using the USB micro connector on the Blue Pill can be used along with the display controller?

If so that would be absolutely great.

Exactly.

The stm32 is programmed to a usb-serial converter, but also display the status and send $proceed and $ppsdbg when needed.

[cdev]

Reading Time-nuts about GPSDOS, seems this may be what some of the settings incremental states and gain, delay, etc.  are about. "Microtonal" adjustments in phase and frequency back towards exact lock during recovery? Similar to how NTP adjusts time when there is a correction needed. Slowly.

https://www.febo.com/pipermail/time-nuts/2012-December/072265.html
[time-nuts] GPSDO recovery from holdover

Said Jackson saidjack at aol.com
 Sat Dec  1 17:42:58 UTC 2012

Hi Hal, We selected 10 steps upon customer request.

The counter resolution is 16.667ns on the FF-IIA boards, so we end up pretty close to UTC. "Slowly" is determined by the PLL parameter serv:phaseco.

By default we add very little frequency error, so drifting say 100ns can take a couple of hours if the ocxo is stable ( not warming up anymore). The settings vary per oscillator type, and are more aggressive for single oven units than SC cut DOCXO units. The user can "crank up" the gain and thus reduce the adjustment time, by increasing that parameter, all the way until the loop becomes unstable. We made it so slow for two reasons: one we wanted the best frequency accuracy, and drifting the phase requires adding a frequency error, so we want to keep that error as small as possible. Two: we indicate this phase offset via pushed or polled software command with 0.1ns resolution, so the customer can adjust for it if desired by delay line or via software calculation.

Or the customer can simply set the gain higher for faster phase corrections.. Bye, Said Sent from my iPad On Nov 30, 2012, at 8:36 PM, Hal Murray <hmurray at megapathdsl.net> wrote: > > saidjack at aol.com said: >> New JLT GPSDOs step back in 10 Steps over 10 seconds if more than 250ns off, >> then adjust the last ns slowly. > > Thanks/interesting. > > How/why did you pick 10? > >> If within 250ns, they just slowly slew back. > > How fast is "slowly"? >

[cdev]

Current status:

It was running for a bit - but the display had missing pixels. Then it froze.


Its possible I may have damaged the display when attempting to move some resistors at the beginning.

Or maybe its just connected improperly. It took some experimentation with resistor and capacitor values to get it to show up as an i2c device..

Do you think its the i2c frequency? Pigrew, as far as I can tell, my specific display does not have a large inductor on it..

So, its possible it doesnt have an  internal DC-DC converter.


Here is a web page I just found on archive.org about it..

https://web.archive.org/web/20140812013022/http://geekonfire.com/wiki/index.php?title=I2C_OLED_Panel%28128x64%29

[cdev]

This project is making me realize just how little I know about programming and microcontrollers. Basically almost nothing. But hopefully that will change.

Thanks to Pigrew  I've been introduced to an incredibly affordable little board and development tools. He's been very helpful in answering my often I suspect very stupid questions.

The GPS controller works, and its quite inexpensive to build. Under $10 in parts, apart from the GPSDO and its stuff.

I will take some pictures in a bit of my build which so far has used an unmodified Blue Pill board. (although I think I may also modify it because I'm phobic about USB power problems)  I am going to use a new blue pill board I have because this one is set up for fooling around and "dupont cables" and thats not how I want a permanent device to be. Wires will fall off unless they are anchored more securely.

[cdev]

Works!

[don.r]

So I just wanted to make a nice little 10MHz distribution box with a little OCXO and now.... I have a TruePosition unit up and running waiting to go in to my enclosure.... works like a charm on as little as 9.3V. The project rabbit hole gets deeper as I'm thinking of using one of my newly acquired ESP32 units and have a WiFi accessible GPSDO. Why oh why can't things be simple? 

[texaspyro]

Precision thingies like a GPSDO seldom get along well with nearby transmitty thingines...  It doesn't take much to influence/degrade a device trying to operate in the sub part-per-billion to part-per-trillion range.   

[cdev]

My GPSDO is running well but it still does not have a good case. I'm trying to make up my mind on the case.

[cdev]

Latency wifi adds would seem to me to make it much less accurate...

If you can use real ethernet cards, and wired ethernet you could perhaps use PTP if the hardware is supported by ethtool. or its equivalent on whatever platform you use.

Simplex radio PPS.

Raspberry pi supports PTP for receiving (software PTP) but not transmitting..
...

I'm thinking of using one of my newly acquired ESP32 units and have a WiFi accessible GPSDO. Why oh why can't things be simple? 

If you sent a pps signal via RF to preserve the rise time it would have to be simplex CW or FSK, not packetized.

[don.r]

I would simply use it for control/monitor purposes. It will be hardwired to the distribution box. I have a case (an old set top box) that has a shield wall before the front panel so I could stick the ESP32 behind the front panel and maybe put the GPDSO in a separate can as well. Not sure it it would affect the timing circuits of the GPSDO but we'll find out!

[cdev]

for the shell, sure, that makes sense..

[don.r]

It has a nice Delta PSU with half a dozen different outputs including a 9V 1A output which should be OK with a slight boost to 9.5V. Comes with a front panel with buttons and a seven segment display. Not bad for $5 from the thrift store. I've finally found a use for it. 

[cdev]

How did you determine that 9.5 volts was your unit's optimal voltage?

[don.r]

I kept testing it from a cold start at lower and lower voltages. At 9.4V the unit starts no problem but the 10MHz waveform starts to become distorted. No issues at 9.5V. The digital portion works fine down into the 8V range but the OCXO is not working.