OSCILLOSCOPE SIGNAL TIME  -  EXPERTs  PLEASE HELP!! - Page 1
Forum section: electronics / beginners

author: Ernest
author_rank: Newbie
timestamp: February 10, 2016, 02:49:26 pm
content: Hi All,I am carrying a project which involves the measurement of the time I receive a particular signal on oscilloscope.I have a radio connected to my oscilloscope. This radio is also hearing for some signals from a satellite.I want to measure the exact time I received this signal.I am expecting a signal amplitude rise when I receive this signal hits my radio. How can I measure the exact time I received this signal.Please adviceThank you.

author: HAL-42b
author_rank: Frequent Contributor
timestamp: February 10, 2016, 03:17:08 pm
content: 1 - What is your reference time signal? Signal generator? GPS? Rubidium?2 - How precise do you need to measure?

author: forrestc
author_rank: Unknown
timestamp: February 11, 2016, 02:41:59 pm
content: Quote from: Ernest on February 10, 2016, 02:49:26 pmHAL-42b asks good questions. Especially about the precision needed. For example, I have resources here that I could tell you down to about a millionth of a second when a specific signal arrived.How accurate you want to be will dictate your solution.I will point you in a general direction I'd probably head if it was me: Get an arduino, and get your signal hooked to it. If you need more accuracy than you can get with internal timers on the arduino, add a GPS module which has 1PPS and use that to synchronize time to a relatively high accuracy. That should definitely get you to within 1/100th of a second or so, if not closer.A more hacky approach would be to get an electronic stopwatch and modify it so that your signal 'pushes' the start button. Then you'd have the time since the signal was received.-forrest

author: han
author_rank: Frequent Contributor
timestamp: February 11, 2016, 03:17:22 pm
content: Is exact time is like DD:MM:YYYY HH:MM:SS ?If yes, you have to use system that sync to GPS and use Real time software that can make time-stamp for every event..maybe use software like labview or develop your own.and sync your pc to GPS or NTP server

author: German_EE
author_rank: Super Contributor
timestamp: February 11, 2016, 11:12:47 pm
content: As you are in Japan you also have the option of using the JJY time signals on 40 KHz and 60 KHz. These are based on a caesium clock in Tokyo and are therefore very accurate.

author: Brumby
author_rank: Unknown
timestamp: February 11, 2016, 11:27:19 pm
content: These are important questions:Quote from: HAL-42b on February 10, 2016, 03:17:08 pmAnswer them first.

author: uncle_bob
author_rank: Unknown
timestamp: February 11, 2016, 11:28:02 pm
content: Quote from: Ernest on February 10, 2016, 02:49:26 pmHiAs mentioned above, "exact time" can mean a lot of different things. To some, that might mean which second did the signal come in. For others, exact means traceability to UTC within 100ns. For others, being able to do 10,00X better than that to their own time scale is still not very accurate.Depending on just where you fit in this empire of things, the answer to your question will be a bit different.That's the first layer.Next layer is your scope. How are you triggering the sweep? Is it free running? Do you need to calibrate the sweep as well as log the start of the sweep?Then there is the signal. How does the signal show up? Is there a receiver involved or is this antenna direct to scope? If there is a receiver do you also need to compensate for the receiver delay? The same applies to things like coax delays.Often the logging of the signal is the easy part.Bob

author: Muxr
author_rank: Super Contributor
timestamp: February 12, 2016, 01:04:35 am
content: Oscilloscopes don't exactly measure absolute times. For example if you want to measure a rising edge time delta between two signals down to nanoseconds or even picoseconds scopes are excellent at that. But measuring absolute time will require some creativity and a good known real time clock source reference.If you are controlling the source and you just want to measure the delay between sending the signal and the time it bounces back from the satellite for instance, scope would be an excellent tool for that. But it will not tell you the actual real absolute time it occurred at. It will only give you a delta.In this context the oscilloscope is not an atomic clock, it's a pretty precise stopwatch. You will have to sync this stopwatch to some real time event in order to get meaningful absolute timestamps.

author: uncle_bob
author_rank: Unknown
timestamp: February 12, 2016, 01:10:27 am
content: HiI really think we could use some guidance from the original poster. I *hope* all of this has not scared anybody away. I think that all who have posted are simply trying to better understand the question.Bob

author: ConKbot
author_rank: Super Contributor
timestamp: February 12, 2016, 06:33:19 am
content: Again, more input from the ts is needed. Without further qualification though, a good gps time receiver with a pps out, signal condoning to covert your received signal to an edge, and a dual input counter to measure the time between the edges (a scope with sufficient analysis on board could work too, no where near as accurate as a good counter). Serial to pull the gps time from the reciever, gpib/lxi and whatever script of choice to pull the pps to signal edge delay from your instrument, and you have the real time that the edge occurred at.This could range from extreme overkill (need it within a second? Set the clock on the scope with network interface and use the trigger time reported when you export the trace) to way imprecise (beyond my expertise if you need better)

author: uncle_bob
author_rank: Unknown
timestamp: February 12, 2016, 06:11:34 pm
content: Quote from: ConKbot on February 12, 2016, 06:33:19 amHiNext level up is to go with an L1/L2 GPS and do common view correlation against the various ground reference stations out there. There are a few zigs and zags in the process. One is that you get the better data two days after the fact. Effectively you are doing the same thing a surveyor does and extracting time rather than location.Bob

author: Ernest
author_rank: Newbie
timestamp: February 13, 2016, 12:00:01 am
content: Hi All,Thank you very much for the reply.Actually, the resources I have available to measure this time are my Digital Oscilloscope, GPS (PPS signal) , the Radio(sdr), LABVIEW program.The accuracy of my measurement should be in microseconds. That means I take the microseconds of the arrival of the signal.First of all I have an Idea of synchronizing my system with the GPS. Which to me also mean using the GPS (PPS signal) as the reference signal.I am thinking of using the GPS(PPS) signal as an external trigger of the signal. WILL THIS WORK?I am not very skilled in using the oscilloscope, but how can I use the available GPS(PPS) signal to my oscilloscope to get this precise time.My assumed set up is connect antenna to radio, connect radio to oscilloscope channel, connect GPS to external trigger.Actually, the whole project is to measure time difference of arrival of this satellite signal at different locations about kilometers away.Each station will have the same oscilloscope and GPS setup and the radios will be hearing to receive this signal which will be sent at the same time to all the stations. Each station oscilloscope will pick up the signal and measure the arrival time of the signal and then we know the time difference of arrival. Therefore I need GPS to synchronize the timing of the stations. DOES CONNECTING GPS TO EXTERNAL TRIGGER AS REFERENCE AT EACH STATION SYNCHRONIZE THE STATIONS?As mentioned earlier, I expect a peak rise when I receive this CW signal. How then can I know the exact time of the Peak rise on oscilloscope.PLEASE ADVICE!!Thank you very much.

author: HAL-42b
author_rank: Frequent Contributor
timestamp: February 13, 2016, 01:18:46 am
content: Connecting 1pps to each station does synchronize the stations to the second. But which second? To your scope all seconds look the same. You need a separate way to determine that. You need to use RS232 on the GPS to record the time on a computer.I think you can use the trigger function of the scope to do this, provided the memory depth is enough to capture an entire second.Another way to measure is to use frequency counter in interval measurement mode. This will tell you how many milliseconds passed between the last pps and the signal.

author: uncle_bob
author_rank: Unknown
timestamp: February 13, 2016, 02:01:17 am
content: HiOk, so let's do some math.Light runs at 3x10^8 m/s. In one microsecond, it's gone 3x10^2 meters. Yes, at km sort of distances you can see us sort of deltas.So the sat is straight up in the sky. It arrives here and somewhere 1 km down the road at exactly the same time. The distance to the sat is essentially identical (straight up) at both locations. If it was dead on the horizon, we would get a 1 km delta. At zero degrees all the ground clutter would keep us from getting a signal. You need to play a bit with trig to work out what angles you can actually triangulate at one km and one us.So, if you trigger your scope once a second, and watch for "stuff" you will be collecting data for a full second. If you are after 1us, you probably want at least 10 samples over that period. Make sure that your scope will actually grab 10 mega samples. Some will, some will not. Once you have the data, you need to get it out of the scope. Doing that in under a second is vital (another batch of data is on it's way). Some scopes will dump this fast, some will not. Some have trouble grabbing new data while dumping old data (they want to dump first and then grab new data). The simple solution to that is to use two scopes. One grabs data while the other dumps data. They ping pong back and forth. One gets the even seconds. The other gets the odd seconds.If you want your sites to all stay in sync to a reasonable level, you will need timing grade GPS receivers. Be aware that a few very highly respected stores are selling units that simply are not what they say they are. Get something like a uBlox LEA-8T for your GPS. It will need a good antenna and time to do a self survey.Next up is an error budget. You can't have ten things all contributing a microsecond of error and have the full system deliver a microsecond. A very common way to look at it is to push each error down to 1/10 of your budget. That would be 100 ns. The alternative is a formal error analysis.Lots of fun !Bob

author: forrestc
author_rank: Unknown
timestamp: February 13, 2016, 11:18:23 am
content: Quote from: Ernest on February 13, 2016, 12:00:01 amI would go an entirely different direction. Without going into details, let's just say that I have some background in doing this type of work (if you want my CV I can give it).Figure out how to tie a GPS module to a microcontroller with a high precision clock and some sort of timer capture peripheral. I personally use a GPS module with a 1PPS output and NMEA outputs. The NMEA will tell you which second you're in, the 1PPS will tell you alignment.I'm most familiar with the microchip PIC controllers. As a specific example, the PIC18f26K22 with a 16Mhz clock will run at 64Mhz internally. The counters should be able to increment at this rate or at almost this rate.Because you're measuring difference of arrival, you can take some shortcuts. You really don't care if you're clock is exactly on UTC time to the microsecond. What you do care is that both clocks are running on UTC time with exactly the same offset. As a result, I'd do the following:1) Set up a timer to freerun at either the maximum achievable rate, or a slightly slower rate if the higher rate is too fast for whatever reason.2) Set up a normal/low priority interrupt to capture timer overflows and increment a counter so you effectively expand the 16 bit timer to a much higher value.3) Use one serial port hooked to the NMEA output of the GPS, a second to a usb->serial chip to a PC.4) In the main loop of the program, receive the NMEA data and parse it for the hours minutes seconds. store this in a temporary global variable and set a flag that this has been updated.. This is non-critical timing wise so the main loop is ok for this.5) Set up a non-maskable interrupt which is triggered by the leading edge of the 1PPS signal. In this interrupt routine, capture the timer value (including the number of overflows), paying attention to potential overflows occuring while in the interrupt routine itself, and storing it into another temporary global variable. Also, copy the nmea time value which was captured in #4 into a second temporary value, clearing the flag mentioned in #4 and setting another one. What you're doing here is storing the H:M:S of the pulse along with the internal timer value into a variable for the main program to use.6) Also in the main loop of a program, once you see the data appear from the NMI (#5), output this data to the serial port toward the pc. Be as compact as possible. This will be logged by the PC using a standard serial program. The idea is that you'll get an output which tells you the timer value (including the overflow count).7) Hook your signal to a CCP peripheral. the CCP peripheral will automatically capture the timer value when the signal changes. Set an interrupt on CCP capture events, and then in that interrupt routine, do the same thing as #5, except capture the value from the CCP, again paying attention to potential rollover events.Also in the main loop of the program ooutput the captured data from #7.If you get this all correct, what you will effectively end up with is a serial output stream with events 'timestamped' using the 64Mhz oscillator clock (which should be a XTAL). You'll have 1PPS pulse events and also signal events. The 1PPS events will occur exactly once a second (assuming you have a good quality GPS with a good quality 1PPS signal), so you can use the difference between them as a measurement of exactly what frequency the clock is running at in the microcontroller. For example, if you find the counts for the 1PPS signal are exactly 64,000,000 counts apart, then you can assume there's 64,000,000 counts per second, and use that as a divisor in math related to your actual signal reception times.The above description is based on a specific microcontroller I'm familiar with. I will point you toward another resource I've recently become aware of and that's the micropython project. Seehttps://micropython.org/store/#/storefor the boards themselves. There's also docs on this site. It appears this MIGHT work for you as well - you'd do a similar procedure, but the code would be in python - although I'm not sure the timer resolution will be high enough for you. Other controllers may work as well.

author: Ernest
author_rank: Newbie
timestamp: February 21, 2016, 10:03:31 am
content: Hi All,Thank you very much for the directions. I have considered themHowever now there is something different I want to do on m oscilloscope.I want to do IQ signal analysis. IQ derived from Quadrature Amplitude Modulation.So I want to ask that how can I see both I and Q components from a source on my oscilloscope.Do I need a special oscilloscope. I f yes which one?Else how can I do this?Thank you

author: tggzzz
author_rank: Super Contributor
timestamp: February 21, 2016, 10:44:47 am
content: Quote from: Ernest on February 21, 2016, 10:03:31 amSure. Put the I on one channel and the Q on the other.If you want to see the angle-amplitude representation, then this is easy with an old analogue scope with "timebase" set to X-Y mode.If you want to try it on a digitising scope, itmaybe more difficult, depending on the scope. Before buying a scope for that purpose, you would be well advised to check it will work well withthat modelscope.

author: uncle_bob
author_rank: Unknown
timestamp: February 21, 2016, 01:15:06 pm
content: Quote from: Ernest on February 21, 2016, 10:03:31 amHiAre the signals already demodulated? If not, what you need would be called a vector signal analyzer. HP and R&S are the likely candidates for digging one up. They are fairly modern gear so not exactly cheap, even on the surplus market.Bob

author: Stonent
author_rank: Super Contributor
timestamp: February 21, 2016, 04:27:43 pm
content: * Advise

author: MSO
author_rank: Contributor
timestamp: February 21, 2016, 05:27:25 pm
content: It would probably be much easier to synchronize the stations using GPS disciplined oscillators at each station. Use the 1PPS signal to clock an NTP service on a PC to obtain timestamps. Alternatively, you could also use 1 GPSDO at one station and use the NTP via a network to synchronize all the stations. The latter method is cheaper but will result in latency errors. If you need better than ~5 millisecond accuracy, you'll need to replace the NTP service with network cards that use hardware time stamping to reduce latency errors.Using a trigger of some sort from the receiver to obtain and record the timestamp of the signal event on a PC would be trivial. Controlling the oscilloscope, capturing the IQ stream are not something I'm familiar with, but I would think it would be much simpler to handle those task separately from station synchronization.Edit:I wasn't able to recall the specific protocol used to obtain sub-microsecond accuracy as I wrote this post, so I looked it up afterward. The most accurate time protocol that I'm aware of is defined in IEEE 1588."The protocol enables heterogeneous systems that include clocks of various inherent precision, resolution, and stability to synchronize to a grandmaster clock. The protocol supports synchronization in the sub-microsecond range with minimal network bandwidth and local clock computing resources. The protocol enhances support for synchronization to better than 1 nanosecond. The protocol specifies how corrections for path asymmetry are made, if the asymmetry values are known. The grandmaster can be synchronized to a source of time external to the system, if time traceable to international standards or other source of time is required. The protocol provides information for devices to compute Coordinated Universal Time (UTC) from the protocol distributed time, if the grandmaster is traceable to international standards and is able to access pending leap second changes. Options are also provided to allow end devices to compute other time scales from the protocol distributed time scale."For more information see:http://www.nist.gov/el/isd/ieee/intro1588.cfm

author: uncle_bob
author_rank: Unknown
timestamp: February 21, 2016, 05:54:52 pm
content: Quote from: MSO on February 21, 2016, 05:27:25 pmHiIf you go 1588, remember that you will need a grand master clock as well as your slave clocks (PC's) to get the full benefit out of the protocol, you also will need 1588 enabled switches / hubs / routers. Your normal home grade (or even business grade) gear is not yet 1588 capable by default.Without the bells and whistles (and yes there are a few more), 1588 and NTP produce pretty similar results at similar data rates.Bob