Posts tagged with “RaspberryPi”

More TimeHats!

Back in April of this year, a renewed interest on the Time Nuts mailing list developed regarding my TimeHats. The first run of them back at the beginning of the year was fairly small, only 20 units, and only about 15 of them went to folks on the TimeNuts list. They developed a good reputation and I received some very positive public feedback - prompting more interest. I posted saying that I hadn't planned on making more than those initial 20, but that I hadn't yet developed a new revision, so if people were interested I could do another run of identical units, I just needed to know how many parts to order.

The interest ended up being more significant than I had anticipated. A lot more! To the tune of about 150 as it stands today. Due to the current global parts shortage I decided against taking any kind of pre-orders (though it would have helped financially) because I didn't know if I would run into any issues delivering units. At the moment I am waiting for the second big delivery of GPS receivers and antennas - 100 in total. I have already assembled, tested, and shipped about 50 units.

I took a number of pictures along the way as I have assembled them, so I wanted to post them here as a sort of "photo essay".

The first parts to arrive were the µSD cards, 70 of them.

Next up were the PCBs and RTC modules, as well as other little odds and ends like batteries, screws, standoffs, etc.

There's lots of processing that needs to be done, lots of intermediary steps. The holes in the PCBs are slightly too small for my M3 screws, so they have to be drilled out a big larger (I do this with stacks of boards, so it goes fairly quickly). The headers from both the RTC modules and GPS modules need to be removed, and in the case of the GPS modules, the holes must be clean and clear as they are re-used - in the case of the RTC modules we use the second header that is available.

Going with full-size 40 pin headers was a mistake, even though I got them very cheap. They took FOREVER to solder. The next go around I will use much smaller headers that only use the pins I need - in this case it's only a small handful clustered at the top.

Before the modules could be soldered onto their boards, they had to be tested, so I added two female headers to a PCB to make testing quick. A great thing about both of these modules is that they can be fully tested without rebooting the whole system, meaning testing is relatively fast.

Next, it was time to start assembling! This went pretty quickly.

And before long I had 97 boards waiting for GPS modules.

It took a while, but the GPS modules and antenna finally showed up! (And I'm still waiting for more.....)

Then they needed the same testing and processing as the RTCs did.

With both modules installed, proper testing could commence. This took a while.

But once completed, they got parked in the box and are ready to ship!

TimeHat ❤ Nokia FYGM

FYGM and TimeHat

For the past few monts GNSS-disciplined time servers have been taking up a large percentage of my hobby time. Building and distribuiting the TimeHat went very well, and it gave me a bit of extra capital to dig into a few things that I might not have been able to otherwise, like picking up some "real" GNSS timing modules! The unit I was most interested in was the Nokia FYGM, a GNSS timing receiver made to work with Nokia cell site equipment. The FYGM has a u-blox LEA-M8T, one of the better timing-focused u-blox modules available. Lots of people buy these (and other) timing modules from decomissioned cell sites through Chinese scrappers and recyclers just to harvest the receiver, but I wanted to keep them as "together" as possible.

Unlike typical hobbyist GNSS modules, the FYGM has a some extra hardware on it, namely an 8051 MCU. I have more information on this on the wiki, here, so I'll keep this short. To start, why not simply emancipate the M8T from this board? I have a few reasons:

  • I don't want to design a new carrier for the M8T
  • The original board has high quality power supplies for the M8T and active antenna
  • It also provides excellent antenna protection circuitry
  • The included aluminium case is really nice
  • The status LEDs (driven by the MCU) are useful
  • Once the board boots, it's not hard to get the MCU out of our way

That MCU, the 8051, started as being the biggest thorn in my side. Before I had one of these units in my hands all I had to go off of was ebay listing pictures and a couple of posts on the TimeNuts mailing list, but that was enough to get started. In addition to antenna input, the FYGM has one other connector - a 12 pin DIN amphenol-looking thing. Thankfully all of the FYGMs I have found for sale inclide a completed cable to mate with this (using an HDMI connector on the host device end, with CAT7 as the cable itself), otherwise this connector could be a real pain to deal with, becuase it's not an amphenol, or anything that seems to be generally available. Only 8 of the pins on this connector are used, Ground, DC in (taking anywhere from 12 to 35v), and then three RS422 differential pairs for Tx, Rx, and PPS. Two RS422 transceivers on the bottom of the module provide this signaling. My initial intention was to try and use these as-is, so I got some hardware to work with RS422 - more on that later.

Once I got an FYGM in my hands, I started tracing all of the connectors and headers. I was disappointed to learn that the RS422 transeivers' input does not come directly from the M8T, but rather it from the 8051. This meant that it probably wouldn't be spitting out UART signals directly from M8T, something that turned out to be true. On the bright side, the four pin connector adjacent to the M8T is, in fact, UART directly from the M8T, meaning that bypassing the 8051 seemed like a possibility, and it technically still is. The ten pin connector next ot the 8051 is a programming and debugging header for that device, so perhaps one day I can read its configuration out or even reprogram it to make it more useful to me. The more immediate use that header has is the exposed reset pin - dropping a jumper between it and ground causes the 8051 to not boot at all, so through the UART pins next to the M8T I can interface with it directly, and completely ignore the MCU. I didn't end up doing this though.

Why?

Well, to put it plainly, the engineers who developed this thing had some clue as to what they were doing - remember, this device is intended to be a highly precise GNSS time source for a clock in a cell site. If we can benefit from the work they put into developing this thing, why not? When the FYGM boots, the 8051 sends a number of strings to the M8T to put it into a configuration that makes it optimal for use in its intended purpose - which just happens to be the purpose I have for it! As far as I have been able to tell, once these strings are sent, the 8051 gets out of the way entirely, it simply takes UART from the M8T, process it, and spits it out over R422. Initially this was a disappointment, but... I don't need to use the RS422 - I can run the signals straight from that UART header to the host - and that's exactly what I ended up doing.

Early on I had started to design a Pi Hat with an HDMI port, a DC in jack for 12-35v, a 5v power supply for the Pi, and RS422 transeivers for the UART and PPS signals. As much as I like the aesthetic of this, it's just not reasonably feasible. Seeing as the UART from the M8T isn't connected directly to the RS422 transeiver on the FYGM, I would have to connect them directly with some bodge wires, but this means that the 8051 has to be taken out of the loop, and for the reasons described above, I don't want to do that anymore. What I ended up doing is pulling the pins out of the eight pin JST connector, everything but ground and DC in, and I am connecting to them directly to the UART signals out of the M8T. This also lets me do some sneaky stuff. It's kind of ugly, but it works well and allows me to continue to use the DIN connector which is solastic'd in place.

FYGM Open

Again, this is ugly - but it works. If you look closely you can see the sneakyness... As you can probably tell from the picture at the top of this post, what I have done is cut the included cable down to about a foot and run it straight onto one of the TimeHat boards, feeding in Tx, Rx, and PPS just as the MAX-M8Q modules do. Power comes in through that barrel jack zip tied to the cable. If you look closetly, though, you'll see something going to the 5v pins of the TimeHat, what's up with that? Well, I spent a while think about how best to handle powering this whole mess, and I really liked the idea of integrating the Pi and FYGM as closely as possible. The UART header on the FYGM has a pin for 3v3 input, so I could power the M8T directly. The 8051 and active antenna circuits have their power power regulators though, these are fed from 6.3v coming from the main power supply on the board.

The Pi has no easy way to source 6.3v, but you know what? Turns out it will run just fine on 6.3v! I haven't spent much time at all studying the power front end on the Pi, so I just threw 6.3v on the 5v rail and sure enough, it works just fine! This may very well impact something in a negative light, but I'm just going to let it roll for now - I'll update if it causes any problems, but I don't suspect that it will. Basically, what I'm doing is feeing 16v into the FYGM's main power supply, then pulling the 6.3v back out and into the 5v rail on the Pi along with the other signals mentioned earlier. How much power is safe to sync from this 6.3v rail? Probably not a lot - but - keep in mind that I have the Pis that I use in this role configured for very low power consumption - no WiFi, no BT, no GPU, no USB devices, and the CPU is clocked down about as low as it can go. Using a kill-a-watt, I measured the whole setup to pull a whopping 1.9 watts from the wall, including all the power supply overhead.

What does this mean as far as time server performance is concerned? Well, I don't know yet. I haven't done much of that measuring yet. I just recently got my GNSS antenna splitter, so I can finally start to compare receivers using the same signal source, which is a step in the right direction. What really needs to happen next, before I can start seriously start making this measurements, is getting a GNSS antenna mounted up above the roof line. I have my mast built and brackets in place, all that's left is to actually attach it to the house - I'm still working on figuring that out, more to come shortly, I hope.

That said, even in my "less than optimal" configuration, things are looking good. The Pi here is a Pi2, and that is on purpose. Can pairing a less-than-optimal Pi with a really good GNSS receiver help? Who knows! Here's what the chronyc sources output looks like at the moment:

FYGM chronyc sources

And here's what cgps looks like:

FYGM cgps

The 0.35 TDOP is what really stands out here. This receiver's antenna is in the basement, sitting on the ledge of a casement window. Using a high-mounted helical antenna sticking out of a 2nd story window I have seen TDOP below 0.2, so I expect this to improve well beyond the capabilities of the Pi once I get it mounted on the side of the house.

ADS-B and PiAware

I have run some form of an RTL-SDR based ADS-B receiver every since I first learned it was possible back in college. The idea of using a cheap ($10-20) USB radio to pick up aircraft transponder signals, and then use some open source software to decode and visualize it was beyond cool. A few years ago flightware came out with a program called "PiAware" where if you used their software (a combination of raspbian and dump1090 plus some of their own customizations) you could feed your data into their system to help augment their data, and in the process you got a free premium account.

I never used this because 1) I wasn't interested in a premium account, and 2) I ran my own customized version of dump1090 and didn't want to lose out on my sweet added features. Additionally, even though I know that the software can be run on any linux system, I had always felt that the Raspberry Pi was under-powered and not stable enough to run like this for an extended period of time. About a week ago, I decided to revisit the matter, mostly because of the premium account.

I've been doing a lot of testing with my company's real time & big data spatial processing tool, GeoEvent Server and I was under the impression that the premium account would give me an API key to access their feed. Turns out I was wrong, that has to be paid for separately regardless, but I decided to follow through with setting up PiAware anyway. I have an Raspberry Pi B 3 floating around doing nothing in particular, and I figured it should be beefy enough to handle the task at hand.

(picture of setup here)

My setup is simple but works well, it has been running for just a few days now. My number one question, as it always is with deployed RPis, is how well the SD card will hold up. I'm using a 32GB SanDisk Class 1 card, but you never know. My antenna is the official FlightAware branded ADS-B antenna, a dark green plastic tube about 2ft long with an N-connector on the bottom. I have it mounted on top of a tripod standing up in the attic. 20ft of low-loss coax connect it to the receiver - first to a band pass filter that kicks out FM and all the other RF noise, then to the FlightAware Pro radio itself - this is a standard RTL-SDR with a tuner and amplifier somehow "tuned" to 1090MHz. There is a "Pro Plus" version of this receiver now that has the band pass filter integrated, and I would very much like to see how it compares. The last piece is the Pi itself, the only other thing connected to it is a CanaKit 2.5amp PSU - it's hanging off the network via WiFi, also a test.

Performance has been good, the software barely taxes the resources of the machine, and it hasn't had any issues holding up to the network. Their updated version of dump1090 has a number of features that I had added to my own, so I have no qualms with using it now. It also still has the always-updated JSON endpoint with aircraft information which can be readily ingested into GeoEvent Server - more on that later!

Despite being mounted in an attic, surrounded by trees, the coverage is quite good. I find that 7am-1pm tends to be the busiest time.