This is actually a continuation of another project, a high precision 10MHz GPS disciplined oscillator (GPSDO), also described on my blog here.
Everything that I discuss here will eventually be posted in a dedicated Github project, available here.
This is very much a work in progress, so keep in mind that things will change, so please come back often to keep track of the developments.
Monitoring, measuring and logging
During the development of my GPSDO's, I actually built three complete units, I wanted to monitor, measure and
log the results so I could analyze the data later, and in different
ways. Most of the changes take place over a long period of time, mostly several days, so it's easier to look at changes when you can graph the
data. I have been doing that for many months now, but I wanted more.
My additional design goals
1. I wanted to move away from the RPi's currently sitting on top of my GPSDO's, and being fed by an additional 5V wall-wart supply.
2. When I wanted to look at the NEO performance with u-center, or reprogram them, I needed to open-up the enclosure and add a serial to USB connector and cable. Or leave that cable connected through a slit in the enclosure. This is cumbersome, so I also wanted the RPi to have access to the NEO serial data, as a minimum just listening, but with the option to program it through the RPi as well, although this is way more complicated to realize.
3. What is also cumbersome at the moment, is that I have to open-up the enclosure to de-solder/solder the 10uF capacitor on the reset pin of the Arduino, to avoid a general reset when you plug the USB cable in, just to reprogram the firmware. Even if I added a jumper, which I should have done, I don't want to open up the enclosure. It really disturbs the performance of the GPSDO. A simple on-off switch on the front- or back-panel could do that job.
4. I found a high precision counter project for the 10MHz, and I wanted to integrated that into the GPSDO.
5. With the additional information of the 10MHz counter and the NMEA data, I also wanted to add a very small OLED display to the front-panel, so I can show the 10MHz count, the number of satellites in view and maybe the DAC or temperatures, whatever...
6. I'm also considering adding two more SMA connectors for the 1PPS and 10MHz outputs, but then isolated with a transformer. I have noticed losses of lock when I fiddled with the BNC cables connected to the current outputs. These outputs are DC coupled to the circuitry, and the whole GPSDO is floating from earth ground. To counter that from happening at the moment, I always have one BNC cable between the GPSDO and the external trigger input from my scope, which is earth grounded.
To put everything inside the GPSDO enclosure, I needed a smaller foot print for the RPi itself, so I choose to use the model Zero-W. The "W"stands for wireless, which is what I needed to get access to the internet and add email functionality. I also wanted to power the Zero with the already available 5V supply inside the GPSDO. I hope that the aluminum enclosure has enough openings for the WiFi to work.
To put everything inside the enclosure, I'm designing a small additional PCB that will house the counter hardware, a connector to fit the RPi Zero and the isolation circuitry for the additional 1PPS and 10MHz outputs.
Bit-banging my way out of a predicament
Monitoring the GPSDO status report
Since the beginning, I used a Raspberry Pi Model 2B (the "classic" first model, because I have several of them) to capture the output of the status report from the firmware of the GPSDO and add a timestamp in front of every line. After capturing that data into a file, an email program sends that just before the end of a day to my PC for further processing in Excel.
I used two separate Python scripts to do that. They are on the Github site.
Because I will most likely need to move this serial monitoring away from the "real" UART and use bit-banging, the serial monitoring code needs to undergo some serious treatment. I have not yet started that.
Measuring the accuracy of the GPSDO 10MHz output
Raspberry Pi serial port caveat
Save the file and close the editor.
sudo systemctl disable hciuart
Logging the NMEA sentence from the GPS module
Because of the limited number of serial UART's available on the RPi family, I needed to find a kind of SoftwareSerial that would let me use any of the available GPIO ports of the RPi. There are three libraries available that I know of, but I selected to use the pigpio library from Joan, who has been very active on the RPi front right from the start. He or she, is very skilled, active and helpful, so this library is where I started the adventure with. This library has support for bit-banging of the GPIO pins to act as serial TxD and RxD ports.
As I mentioned earlier, the pigpio bit-banging software reads the serial data in irregular chunks in the form of Python bytearrays, which you need to piece together again. Sounds trivial, but was not so easy to do to make it work with different data from different sources.
After some inspiration and a lot of testing, I figured out a way to do this reliably, and the script now reads the data of the counter and the NMEA sentences without problems for more than a day. Good enough for me.
The code is on the Github.
If you can find a more reliable or a more clever way of doing this, please chime in and post your solution.
The OLED display
The little 0.9" diagonal display will easily find a place on the front-panel. I already worked out how to program it. The script is on the Github.
The hardware circuitry
Putting it all together
I'm first going to produce a prototype on perf board that will go inside the Bliley enclosure. With PuTTY I can get access to the RPi and work on the programs without disturbing the GPSDO. Once that works to my satisfaction, I will work on the PCB layout and also work out where and how I'm going to place it inside the enclosure, and how and where to mount the OLED screen.
For the prototyping stage, I already mounted the 0.9" display on the front-panel, and created holes for the isolated 1PPS and 10MHz SMA connectors. The toggle switch for the capacitor on the reset pin of the Arduino took it's place in one of the ventilation holes. I had at least one too many ventilation holes for the Bliley, because it does not get as hot as the Trimble, meaning that the fan was running on the lowest RPM when the room temperature got low during the night. I would like to keep the fan regulated at all times. With the additional heat that the counter/RPi board will generate, I will need to re-visit this anyway.
Below are pictures of the carries board with the counter circuit and the isolation transformers. This is just a prototype I quickly put together to see if it all works, and fits. The carrier board will slide up-side down in the slot on the top cover of the enclosure. The RPi will fit on top of the connector, and will also hang up-side down. The green "counting" LED from the counter you see in the bottom-right corner will show through one of the ventilation holes.
I didn't need access to all the GPIO pins of the Zero, so I just used a 2x12 connector I had plenty of.
I have added two SMA connectors for the isolated outputs, and added a switch that can be used when programming the Nano. I also added the 0.9"OLED display. Eventually, when everything is really, really finished, I will also make a new front-panel. When working with the fan regulation, I already butchered a front-panel and drilled some 6mm holes here and there. One of them is now used for the programming switch. For this additional requirements, I added room for the display and for two more SMA connectors.
Below is how you can see the position of the boards relative to the front-panel. The carrier board will slide into the rails of the top cover of the enclosure.
Major setback!
I build the prototype but the wireless connection of the Raspberry Pi Zero-W is disturbed in a big way I first thought was caused by the 10MHz on the carrier board. The 10MHz is needed as a clock for the counter, and I also need it there to provide the floating outputs. Even when the board is still outside of the enclosure, the wireless connection is terrible and unusable. After some more fiddling, I found that it's not just the 10MHz feed, because I disconnected it and even removed the counter chip. The Zero wireless connection is still hopeless, even without the cover of the enclosure installed, which will make it worse. The antenna for the wireless connection on the Zero is just a small track on the PCB. That antenna must be disturbed by the signals coming from the GPSDO. With this setup, I have no room for a USB wireless dongle, because the isolation of the OCXO is in the way. It would probably draw too much power anyway.
If it's not the 10MHz, the other source could be the 5V ocxo supply. As a test, I fed the carrier board with my bench supply, and bingo, that seems to work better. I also see no issues when running ifconfig and iwconfig on the RPi, so I may be on to something.
There is a lot of ripple and more than 1V of high frequency noise riding on the ocxo 5V supply. I tried to filter this, but no big success, with the enclosure open, this stuff is seemingly coming from everywhere. I am now going to try a dedicated and separate LM7805. It must be mounted on the enclosure because of the heat developed by the current for the RPi, and also the 12 to 5V voltage drop. I will need to try that first and see if it's acceptable.
I tried this morning by giving the board a separate 5V supply with extra filtering but no dice. It's definite, the Raspberry Pi and the GPSDO are not playing ball together. The RPi even disturbed the Arduino Nano. Looks like the two camps are bitter enemies within the same enclosure.
Back to the drawing board
I need to find another solution.
Swapping the Raspberry Pi to another processor will not help I think. As soon as you add the wireless capability, I'm pretty sure we'll run into the same problem. Besides, maybe it's better to not have a wireless transmitter blasting inside the GPSDO box at all.
I do not want to add software (in assembler, yikes) to the counter code and make it drive the OLED display. Besides, it would not allow me the freedom to display what I want easily. I will also need an i2r library to drive the display as well. I've already decided that I'm not going in that direction. That means that I need to remove the display from the GPSDO box and move it to wherever the RPi and the counter find a new home.
The only viable alternative I see at the moment is to use another enclosure and put the counter, the display and the RPi in it. I'm considering just adding a small board inside the GPSDO with just the hardware to provide the floating outputs.
Because I'm going to use a separate enclosure, I need some inputs from the GPSDO to make it function. The required signals are: 10MHz and 1PPS for the counter, TxD from the Nano and TxD from the Neo for the RPi monitoring.
The 10MHz and 1PPs could come from the SMA or BNC outputs already on the front-panel of the GPSDO. I will feed these to the front-panel of the new box. The Nano TxD, RxD and Gnd signals are already available on the front-panel of the GPSDO, but the NEO signals are only available on a header inside the GPSDO enclosure. I would like to move all the serial connections to the back of the GPSDO enclosure, and do the same for the new enclosure, to keep these wires out of the way and short. I'm considering using a flat cable and 2.54mm connectors. I'm also considering powering the new enclosure with the same 12V power I already use for the GPSDO. This 12V comes from a home-built UPS so everything will be on all the time, even when there is a power failure.
Splitting things up in two parts
The
new enclosure has to be plastic to allow the wireless connection to
function. Because of the plastic, I can't use a regular 7805, because with the amount of current for the RPi, it needs cooling. I will have to use a Buck switching regulator. Because of the required Buck regulator, the ones I ordered turned out to be too small. I overlooked the large size mounting holes that eat-up a lot of real-estate, so I needed to order larger ones.
The additional board for the GPSDO
First results with the prototype
I
built the first prototype on proto-board (see above) and initially worked on
getting the software up and running. I then moved the whole contraption
in position on top and next to my Bliley GPSDO, with the OLED display
literally hanging in free air, and tried it all since then. In this
version, I do not have the inverting buffers in the 10MHz and 1PPS
signal lines going to the counter. This also means that the counter is
triggering on the wrong edge of the 1PPS signal.
Here are some results:
This
is just a daily sample of the number of satellites in view by the M8T
NEO. I've seen some dips down to 8, but mostly, it is very stable around
12. Plenty for a good fix I think. There is no correlation between the
fewer number of satellites and the aberrations I see in the TIC and DAC reports on
the GPSDO. What is very interesting is that every day for several weeks,
this picture looks the same, with the glitches in exactly the same
spots. This must be due to the constellation coverage of the sky above
me, so a simple one-time look at u-center is not sufficient to determine
the true coverage.
2020-11-15 00:00:09,058 INFO gate 10000s counter 10000000.0000
2020-11-15 02:46:53,055 INFO gate 10000s counter 10000000.0000
2020-11-15 05:33:37,049 INFO gate 10000s counter 10000000.0000
2020-11-15 08:20:21,055 INFO gate 10000s counter 10000000.0000
2020-11-15 11:07:05,053 INFO gate 10000s counter 10000000.0000
2020-11-15 13:53:49,055 INFO gate 10000s counter 10000000.0000
2020-11-15 16:40:33,056 INFO gate 10000s counter 10000000.0000
2020-11-15 19:27:17,054 INFO gate 10000s counter 10000000.0000
2020-11-15 22:14:01,061 INFO gate 10000s counter 10000000.0000
Above is a daily log of the counter measuring the Bliley GPSDO, set at the maximum gate period of 10,000 seconds or, 2,77 hours. It can only provide 4 decimal digits while the Bliley is another 2 digits more accurate/stable, see below.
As you can see, the Trimble may show other counter results. I'll be able to test that when the PCB come in and after I've modified the Trimble GPSDO to provide the NEO serial data on the back-panel.
The Counter/Logger Version 2


These boards are now in production and next week I should have them. The Gerber files are on my Github. I needed to order five, and will build two myself. One is already reserved by another user, so I will have two more available that I will sell at cost + postage. Use the comment section below to show your interest.
I have not drilled the back-panel yet so the DC connector is floating around for the time being. I had a very hard time fitting the OLED display, because it has no mounting capabilities at all. In the end I used some double sided sticky tape and some double sided sticky foam tape to fix it. The blue foam you see in the picture presses the display to the front-panel. It's pretty ugly but it works.
In order to make room, I had to bend the pins on the OLED display to move it away from the RPi. I also had to bend the 5V DC-DC regulator because it is a few mm too tall. An alternative for this regulator is to use the R-78E5.0-1.0 or the TSR 1-2450 DC-DC convertors, they are a bit more expensive but come in a lower package.
To make a bit more room for the SMA connectors, I used a file to remove a few mm of the front-end of the PCB. Depending on the 3mm LED for the counting action, you may have to make some room on the PCB as well. The LED leads must be bend as flat as possible. I found it best to put the front-panel in position to the PCB, and then lower it into the slots of the enclosure. Carefully move the display wires and the two SMA cables away from the mounting stud so they do not get pinched when you screw the top down.
For several days (off and on) I have tried to find a few problems in the second version, connected to the Bliley GPSDO. For some strange reason, I could not get the NMEA log to work. That turned out to be caused by a bad connection of the jumper wire from the GPSDO to the counter board. It did not fit well, so it fell off which was difficult to see. Not so difficult to find and easy to fix.
The second problem was more serious because it involved the logging of the counter. For the life of me I could not get the serial monitoring to work so I tried everything. Exasperated, I took the unit away from the GPSDO and put it on my bench and used long cables to connect the 10MHz and 1PPS signals to it. I also programmed the counter with the 10 second version, which allowed me to debug the problem a little easier. When I traced the serial signal with my scope, I noticed that it did not get to the RPi. That turned out to be a solder joint issue on the RPi connector and was easy to fix. However, that did not solve the problem. The digital RS-232 signal coming from the counter is a negative going signal, and it never got below 2V, meaning that the GPIO pin never saw a low. I measured the two resistors used in the divider I used to get from 5V levels to 3V3 for the RPi, but they were OK. For some reason the signal was pulled up. I then replaced the serial 1K2 resistor with smaller values, but had to go down to 100 Ohm before it got below 1V. Even removing the 3K3 resistor to GND did nothing, so I tried and tried without luck. By then I started to suspect the RPi Zero, and when I replaced it with the one from the Trimble, it started to work. Even swapping the SD cards made no difference, so it was not software related but a bad GPIO port on the RPi Zero. Funny, because all the other functions worked. I may have zapped the port, but that would be the first time. I have worked with RPi's since the very beginning and never had this happen to me before.
The third issue I have is with the WiFi connection, it is very, very slow. As an example, after logging in through PuTTY, it sometimes takes a minute or so before I get a prompt. Sometimes I get no prompt at all, although the RPi is functioning. I suspect there is something wrong with the WiFi antenna or at least that part of the RPi. Remember that this was the reason I took the RPi Zero out of the GPSDO enclosure, thinking the 10MHz noise would be the problem. It may have been a bad RPi Zero all along. All in all, the WiFi would not have worked inside the metal enclosure of the GPSDO anyway, so the current approach is better.
I confirmed that the GPIO-23 port is defective. To continue, I cut the trace to GPIO-23 and moved the signal to GPIO-27, it now all worked as it should.
I re-ordered another RPi Zero, but due to the holiday season, I have no idea when I'm going to get it.
The replacement Zero came in and after re-doing the modification, I installed it and everything works as expected.
With this, I think I'm going to call it a wrap. There's nothing at the moment that I would like or need to do.
Github site with all files is here: https://github.com/paulvee/GPSDO-Monitoring
No comments:
Post a Comment