i have a GPS NTP Time server synchronizing my PC.
HOW am i able to compare 1PPS of the GPS receiver with clock pulse of my PC to see how much accurately it is synced to the GPS time?(with an oscilloscope maybe!)
I've designed experiments of this sort before. In my case, I wrote a device driver that would -- inside the kernel -- watch the PC's clock in a tight loop waiting for it to roll over to a new second. As soon as it did, I would raise one of the pins high on the PC parallel port. Then I attached that pin of the parallel port and the PPS signal output of the GPS receiver to an oscilloscope and had it measure the time difference between the two pulses.
Related
I've been trying to find any way to do hardware timing control on the Raspberry Pi but have been unable to find anything.
I need to be able to generate stable timing over the GPIO pins on the RasPi (e.g. to communicate with an FPGA at high-bandwidths) and need upwards of a 10-100MHz clock on the GPIO pins.
Everything I've seen so far uses delays to achieve timing, which is a really bad way of doing timing. For one, you don't get timing guarantees and get clock jitter; on top of this, I can't get a 10-100 MHz clock uwith usleep.
How do I get an interrupt or some other hardware-controlled timing for GPIO?
I have two B210 radios sharing a 10MHz external master clock and 1pps time signal. I have noticed that each time I start a receive stream simultaneously on both radios they are out by a random but quantised phase variation.
For example if the internal master clock rate is set to 16MHz and the sample rate is 1Mhz then the phase difference is a random multiple of Pi/6. Note this is between different B210 radios - there is no such variation between the two RF channels of the B210.
I need the radios to be in phase lock, not just frequency lock, for the measurements I am making. My work around at the moment is to inject a calibration signal into all the radios at the start of each capture to measure this difference then compensate for it by adjusting the samples in software.
Is there something I have missed in the UHD API which allows me to lock the radios together so they do not have this variation?
There is no way of providing the phase synchronisation between radios as they have different local synthesizers.
From USRP Driver Manual:
After tuning the RF front-ends, each local oscillator may have a random phase offset due to the dividers in the VCO/PLL chains. This offset will remain constant after the device has been initialized, and will remain constant until the device is closed or re-tuned.
More here http://files.ettus.com/manual/page_sync.html
On a 32 bit microcontroller , I want to measure exection time of a code for different operating frequencies of microcontroller. First of all I used Periodic timer (PIT), but it did not provide high resolution, because if I operate PIT at high frequency then its counter got overflow. So I shifted to System timer (STM), because it can run at system clock. but at different operating frequencies of microcontroller, STM give same execution time of code. Could any of you help me in this matter. Thanks
I realize this is an old question, but if this doesn't need to be done in the system "real time," I would just toggle a port pin when entering and exiting the function and use an oscilloscope to measure the time. I'm assuming that you just want to do this for software testing.
If you need to do it "real time" (in the application code), then you'll need to multiply your STM timer value by the microcontroller clock's period. The timer value for the function execution should always be the same (with some exceptions) regardless of the micro's clock frequency. (i.e. the timer's speed will change with clock frequency in the same way your code's execution speed will change)
How can I receive a time signal with an unmodified RTL-SDR USB TV Dongle here in Europe?
RTL-SDR Dongles are able to receive the frequency range 52-2200MHz.
Here in Europe, radio-controlled clocks receive DCF-77, a time signal broadcast on 77KHz, but as 77KHz is a bit lower than 52MHz, that's out.
The GPS L2 signal is at 1575.42 MHz, so that's within the dongle's range, but the signal is way too weak to be received with the TV antenna. An active GPS antenna is needed, and for providing the antenna with the power, I'd need to make some modifications to the electronics which I don't really want to do.
In the old age of analog TV broadcasting, we had Teletext / Videotext here in Germany, which contained a time signal, but these times are long gone.
ADS-B reception with a dongle works like a charm, but unfortunately they did not put in time or date bits into the data packets.
So: Does anybody have any idea where in the spectrum that can be received by an unmodified RTL-SDR dongle there is a time signal that could be easily decoded?
I'm well aware that getting time over the network via NTP, or via a GPS modem via NMEA 0183 would be way easier, but I'm curious and just want to play around with that dongle a bit. Precision is not important. +/- 2 seconds is fine. And I'd like to do it the SDR-way, so using the dongle in the originally intended way (as a DVB-T receiver using the original software) defeats the purpose (i.e. learning and DIY)
The GPS L2 signal is at 1575.42 MHz, so that's within the dongle's range, but the signal is way too weak to be received with the TV antenna. An active GPS antenna is needed, and for providing the antenna with the power, I'd need to make some modifications to the electronics which I don't really want to do.
Well, first of all, GPS is really weak, but it still works under the noise floor; that's something important to realize – I've seen it more than one time that people are worried because they can't see GPS on a PSD display. You won't; you'll need signal processing to recover it from all the noise.
The modifications aren't all that complicated; basically, you need a capacitor to let through the AC component to the RTL dongle, and a voltage source to feed the active antenna; the required component is usually called a bias-T.
Nevertheless, an active antenna will be necessary – your RTL dongle probably won't have a Noise Figure low enough to receive GPS signals on its own.
In the old age of analog TV broadcasting, we had Teletext / Videotext here in Germany, which contained a time signal, but these times are long gone.
True; haven't looked at local FM stations, but RDS might be the way to go – it can contain a clock/time signal; the German Wikipedia claims that mainly publicly owned stations transmit that information field.
Have a look at gr-rds; it's a GNU Radio implementation of the Radio Data System. If you don't have a working GNU Radio installation (yet), you might try out the GNU Radio LiveSDR Image, which contains a ready-to-use gr-rds.
I'm using tsmp77000 IR Sensor module for air conditioner remote control system.
datasheet
I instructed remote controller device of the air conditioner to sensor module and i saw voltage outputs(active low) on the oscilloscope. Then, i need to transmit this signals with IR transmitter led for control air conditioner. But, there is voltage outputs, there isn't frequency graph. How to i convert to pwm output of this signal? Frequency, duty cycle?
And I saw frequency value on the ossiloscope, but it is 833Hz. Whereas,range of IR receiver sensor module is 20-60kHz.
Thank you!
Here is a good explanation of how IR remote signals work by Adafruit: https://learn.adafruit.com/ir-sensor/ir-remote-signals
The 833Hz you are seeing on the oscilloscope are most likely the "wide" bands. If you zoom in, you should see that each pulse is actually made up of many, faster, PWM pulses.
Your best bet will be determining the frequency of the fast IR pulses, setting your PWM pin to that frequency, and then manually enable/disable the PWM pin for the appropriate time intervals, as per the oscilloscope reading.