Skip to content

Comparison against third-party PTP GM solutions - #29

Open
andrepuschmann wants to merge 5 commits into
jclark:mainfrom
andrepuschmann:comparison
Open

Comparison against third-party PTP GM solutions#29
andrepuschmann wants to merge 5 commits into
jclark:mainfrom
andrepuschmann:comparison

Conversation

@andrepuschmann

Copy link
Copy Markdown

Hey @jclark,

I am currently experimenting with a CM4-based PTP GM using your guide and are also carrying out some benchmarks against third-party PTP GM solutions, as well as with some cheaper and some more expensive GPS modules.

I've compiled a few words describing my current test setup and some initial results. I'd be happy to hear your thoughts.

Thanks
Andre

@jclark

jclark commented Dec 29, 2023

Copy link
Copy Markdown
Owner

Maybe I've misunderstood, but it seems like the page added by your pull request is an evaluation of the Qulsar Systems Qg 2. I didn't see any comparison with the CM4. Am I missing something? Although this is interesting, it doesn't seem a good fit for this repo.

It seems like a key consideration for your application is holdover. Whether you continue to get a PPS after loss of satellite signal is configurable for U-blox receivers via the lockedOtherSet flag in UBX-CFG-TP5. However, I don't know if the PPS you get from a cheap GPS without a lock is better that what the computer can do on its own. If you want good holdover inexpensively, then my suggestions would be:

  • M8F (TimeBeat sells a module): the M8F has a mini-GPSDO internally
  • a cheap GPSDO like the BG7TBL together with a RS232-USB cable

A complementary approach is to have multiple GMs so you can handle the loss of a single GM: for this, it's important that a GM advertises less accuracy when it loses the pulse (which ts2phc cannot do).

@andrepuschmann

Copy link
Copy Markdown
Author

Hey @jclark - sorry for the confusion. I should have explained better. I do plan to add measurements using the CM4-based PTP GM to this PR of course.
But since I am still waiting for the M8F GPS module I wanted to collect some measurements using a commercial GM that is often used and recommended in telco (5G) applications. Feel free to ignore the PR (even close it) until I have data from the CM4-based GM.
The main purpose of the (early) PR was to receive feedback regarding the methodology.

Regarding your other points, you're right in saying that one of my main concern is holdover. The reason for this is that I often find myself running indoor demos in places without proper GPS reception, e.g. in a conference center or just in an ordinary office building.

Actually I am currently also considering a mobile, battery-backed device so I can "get the lock" outside and then literally carry it to the telco network deployment and distribute it from there.

@jclark

jclark commented Dec 29, 2023

Copy link
Copy Markdown
Owner

Ah, that makes sense now.

I suggest structuring it like this:

  • add generally useful explanation of how users can perform their own measurements to measure.md
  • create a new directory (e.g. experiments) with one page per experiment (I can add mine here also)

I agree with trying to do the measurement end-to-end. Other things that can be interesting:

  • how do switches affect things? (will you need a switch in your application?)
  • how well synchronized are clients to each other?
  • how well synchronized are two instances of the same GPS models? different GPS models? different GPS brands?

With the CM4, how are you planning to replicate the ability of the commercial GM to expose a PPS output? I bought a BG7TBL TS-3 for this (https://www.aliexpress.com/item/1005005752946614.html). It has 2 PPS outputs from a single M8T, so I can feed one into the GM and one into the oscilloscope. I have tried this yet. Previously I just compared with the client with another GPS.

@andrepuschmann

Copy link
Copy Markdown
Author

@jclark Sorry for the late response. You're comments all make a lot of sense. I'll adjust my PR accordingly over the coming days.

With the CM4, how are you planning to replicate the ability of the commercial GM to expose a PPS output? I bought a BG7TBL TS-3 for this (https://www.aliexpress.com/item/1005005752946614.html). It has 2 PPS outputs from a single M8T, so I can feed one into the GM and one into the oscilloscope. I have tried this yet. Previously I just compared with the client with another GPS.

Good question. For my application I might even use an external GPSDO with PPS output to tame the CM4. So far I've tested with the TM4313 and that gives good results with frequency stability due to it's built-in OCXO. Do you know if the BG7TBL TS-3 also uses a OCXO?

@jclark

jclark commented Jan 12, 2024

Copy link
Copy Markdown
Owner

The TS-3 gives you the time-pulse from the U-blox LEA-M8T as is, and that just has a TCXO.

I'm curious about the TM4313. It's potentially a good option.

  • what's the GPS?
  • does the serial output just give you the GPS serial output?
  • is the PPS signal 0-3.3V?

@jclark

jclark commented Jan 12, 2024

Copy link
Copy Markdown
Owner

I found this https://tomverbeure.github.io/2023/07/09/TM4313-GPSDO-Teardown.html which answers most of my questions. It says there that the PPS output is 5V. Have you connected this to the CM4 without problems? That's good to know: I think it is spec'ed for 3.3V (but I may be misremembering).

@andrepuschmann

Copy link
Copy Markdown
Author

I've not connected the PPS of the TM4313 to the CM4 just yet. Unfortunately, the PPS level is 5V so I need to level shift first. See also here https://twitter.com/AndrePuschmann/status/1745470050402783232 for some measurements that I plan to integrate into this PR here for better visibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants