Re: [time-nuts] Input filter for data logger
Bruce wrote: Oops I meat to say: Thats a MOSFET variant of a fairly standard JFET-BJT feedback amplifier. I think you were right the first time. Vlad said in his first post that the input device is a 2N5485 (JFET). I'm not sure why Vlad designed the input squarer that way. If the FET/BJT amp feeds a 74AC gate, which Vlad said it does, the gate is doing all of the effective squaring. The discrete components are just adding noise. The circuit will have lower noise and jitter if the FET, BJT, and diodes are left out and the input signal is just cap-coupled into the gate, with its input biased to half-supply by a voltage divider from V+. Note that with AC logic, the gate may oscillate with an open input and/or no signal, if the termination resistor is too large. HC logic is much less prone to this. A small improvement in the phase noise of this circuit can be made by filtering the gate input bias divider (well, it could be a larger improvement if you have noisy power rails...). This can be easily accomplished by using a string of four resistors for the divider rather than two, and bypassing the added nodes to ground with *low-leakage* electrolytic capacitors (see attached diagram). Best regards, Charles ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Input filter for data logger
> I'll need to experiment with this. I think the drawback cold be for the > signal with long pulse width (more than one second). > __|~~~ I'm not sure I understand. If you're building some kind of time interval counter or timestamp counter the duration is only limited by how many digits or bits you allocate to your timestamp. Longer than one second should be very easy. >> That's a software problem for sure. Do you use interrupts? Or some >> library code for formatting and output? > > STM32 has an internal counter which counting MCU ticks (I clocked my > stone by 40Mhz. So, it will be 40 mln. ticks per second). I am using > this ticks number to get microseconds as signal capture event has > occurred. That sounds fine. > My other timer generate interrupt each second. This is used to start > count the microseconds over again. So, its pretty simple. This could be trouble. You'll have to check for timing windows in your code. It's usually better to let counters free-run rather than to start / stop / reset them all the time. > I'll need to dig this issue deeper, since its occurred only when I was > using DDS generator as a signal source. I know DDS chips sometimes > generates some spurs. But not sure if this is related. > If I raise the input freq. to 1Mhz, the STM32 become unresponsive, since > number "capture" interrupts is too high. The signal capture interrupt > routine doing nothing more than one assignment : "cur_tick = > DWT->CYCCNT" Make sure this assignment is atomic (a single load/store pair, not multi-byte or multi-word instruction sequence); very timer and cpu dependent. You don't want unresponsive. When you get an event, capture the timer, format your output, and do the serial transmit. Only when that's all finished then re-enable for the next event. This avoids lock-up. And it means your CPU saturates at the point where your output rate is a maximum. So it's self regulating. Note if you do all your event processing in the interrupt handler and cur_tick is not used at main level, you don't have to worry about atomic loads and stores either. Another way around all of this is to use capture/compare registers. Most uC have this feature. This way your precise timing is not at all dependent on interrupt latency or what language you write in. > has no 32bit timers. Using 40Mhz clock, I can't go low than 610Hz > without some tricks, like using pre-scaler or cascading the timers. I > tried those methods but results was not impressive. Probably because of One solution is to use h/w timers for the low bits and s/w overflow counters for the high bits. For example a 64-bit counter could be made using a 16-bit timer and a 48-bit overflow count. This is an overflow every 1.6 ms, which is easy to deal with using either interrupts or polling. > my software implementation. I am using DMA and other timer to capture > 1PPS events. It works OK for me. But in that case I just need one > number. Which ideally should be 23040 in my case (4000 % 65536 = > 23040). I don't care about number of overflows and anything else in this > case. If I am getting something different from magic number - its time > to tweak DAC to control OCXO. Right, if this is just for a GPSDO then you can consider modulus tricks like this. If you're making a more general purpose time interval counter or time stamping counter then you can't rely on that trick. I'm not sure of the context for this thread. It sort of seemed like you were building a counter. Then again, even if this is a GPSDO I would not want to rely on magic number tricks. What happens if the user decides to change antenna length in order to move the 1PPS by hundreds of us? The magic trick will now cause great trouble. You can avoid that with a FLL instead of PLL version of GPSDO and ignore what look like glitches. But this is now adding hack upon hack. My advise is just implement a 0 to 1.x second TIC. It can't be that hard to do that in a STM32. /tvb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Input filter for data logger
26.5837255 26.23559295 26.5941842 However, it is some "spikes" in the data flow (see above the number "26.23559295", which suppose to be something as "26.58..."). I can't understand the reason for that. That's a software problem for sure. Do you use interrupts? Or some library code for formatting and output? I think I found the problem and the solution (partially). Since I am using capture interrupt which change the value "on-the-flight" - its appeared that some capture event could happen when USART doing its work (printing). So, I put the "lock" there. If USART is already printing, then the interrupt routine will not change the value. It seems its helps to some degree. At least I have normal data flow. No strange numbers any more. However it make me think that I definitely loosing something, when USART is busy to print. -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Input filter for data logger
On 2017-11-19 20:20, Mark Sims wrote: Here are Wenzel's input circuits: http://www.wenzel.com/documents/waveform.html The TAPR TICC uses a slightly modified version of the two transistor circuit. Also check out the LPRO-101 manual for their versions of the single CMOS gate squarer. One thing they do is add an RC filter to the CMOS gate power supply. Thanks for the link. Actually I am using Wenzel two transistors in my other project. Works great. This time I tried to use LPRO-101. But that one is to "square" outputs from MV89 OCXO. MCU like it. I am wandering, if it can it be an issue, if I am using the same 74AC04 for all three purposes: 1. 1PPS to control the DAC 2. OCXO to feed the MCU 3. Input from DUT -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Input filter for data logger
Assuming the STM32 is set to trigger on the rising edge, a 2x output will occur if there is bounce from a falling edge. Normally this is not desirable, but there are cases where measuring both rising and falling edge improves resolution. For example I have a version of the picPET that timestamps both edges (this gives you pulse width and duty cycle information). The CNT-91 counter also does this in raw timestamp mode. I'll need to experiment with this. I think the drawback cold be for the signal with long pulse width (more than one second). __|~~~ 26.5837255 26.23559295 26.5941842 However, it is some "spikes" in the data flow (see above the number "26.23559295", which suppose to be something as "26.58..."). I can't understand the reason for that. That's a software problem for sure. Do you use interrupts? Or some library code for formatting and output? STM32 has an internal counter which counting MCU ticks (I clocked my stone by 40Mhz. So, it will be 40 mln. ticks per second). I am using this ticks number to get microseconds as signal capture event has occurred. My other timer generate interrupt each second. This is used to start count the microseconds over again. So, its pretty simple. I'll need to dig this issue deeper, since its occurred only when I was using DDS generator as a signal source. I know DDS chips sometimes generates some spurs. But not sure if this is related. It sounds like you have two problems: 1) h/w signal conditioning before the STM32, and 2) a s/w timing issue in your code or in how you use the USART. To separate them, try a clean square wave directly into the STM32 over a range of frequencies from slow to fast to faster than the STM32 can keep up. If I raise the input freq. to 1Mhz, the STM32 become unresponsive, since number "capture" interrupts is too high. The signal capture interrupt routine doing nothing more than one assignment : "cur_tick = DWT->CYCCNT" Which means that I am getting current number of ticks. USART will print the number as event will be detected. The speed is 115200. And I am not using interrupt for this. BTW, the good news is that your time stamping output looks like the picPET -- http://leapsecond.com/pic -- which means that you can use TimeLab to directly capture and/or display all your data (phase, frequency, adev, etc.). I think I'll need to order few picPETs to use them as a reference for my project. Let me know if you could ship to Canada. As an example, the old PIC I'm using is limited to 125 samples per second (mostly due to RS232 transmit time at 19,200 baud), but with an 8-bit event count you can directly measure frequencies up to 256 times greater (32 kHz). With a 16-bit event counter that number climbs to 8 MHz. All this without a pre-scaler. I was try to use DMA to keep counter value. And then I was counting number of overflows. However, I noticed this is more complex computations is necessary to get microseconds from this comb. STM32F103 has no 32bit timers. Using 40Mhz clock, I can't go low than 610Hz without some tricks, like using pre-scaler or cascading the timers. I tried those methods but results was not impressive. Probably because of my software implementation. I am using DMA and other timer to capture 1PPS events. It works OK for me. But in that case I just need one number. Which ideally should be 23040 in my case (4000 % 65536 = 23040). I don't care about number of overflows and anything else in this case. If I am getting something different from magic number - its time to tweak DAC to control OCXO. -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Input filter for data logger
On Sun, 19 Nov 2017 22:56:41 + Anguswrote: > >> The MV89 is a beast of an OCXO and uses more power at warm-up than any > >> other > >> I know of. But it is spec'ed ~1W for steady state. Which means the > >> outside of the OCXO should be about hand-warm. If it's too hot, then > >> the heater circuit is probably broken and running at full-throttle. > > > >If so, I think something is not OK with my MV89. It is probably 110 > >degrees or so. > > They do run hot, so if that's 110 DegF and not DegC it's OK (depending > on ambient...) The data sheet says 4.2W at 25 DegC. Oops.. I miscalculated the power consumption of the MV89.. Sorry about. Today doesn't seem to be a good day for me to answer questions it seems. Attila Kinali -- You know, the very powerful and the very stupid have one thing in common. They don't alters their views to fit the facts, they alter the facts to fit the views, which can be uncomfortable if you happen to be one of the facts that needs altering. -- The Doctor ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Input filter for data logger
On Mon, 20 Nov 2017 11:47:09 +1300 (NZDT) Bruce Griffithswrote: > That's a fairly standard JFET BJT negative feedback amp that's not usually > unstable. Uh.. uhmm.. sorry about that... I'm electronically challenged, it seems. Attila Kinali -- You know, the very powerful and the very stupid have one thing in common. They don't alters their views to fit the facts, they alter the facts to fit the views, which can be uncomfortable if you happen to be one of the facts that needs altering. -- The Doctor ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Input filter for data logger
The performance of virtually all CMOS gate sine to CMOS converters degrades significantly once the signal at the gate input exceeds the supplies sufficiently to cause the input protection circuitry to conduct. This effect is very easy to measure with HCMOS. Bruce > > On 20 November 2017 at 14:20 Mark Simswrote: > > Here are Wenzel's input circuits: > http://www.wenzel.com/documents/waveform.html > > The TAPR TICC uses a slightly modified version of the two transistor > circuit. > > Also check out the LPRO-101 manual for their versions of the single CMOS > gate squarer. One thing they do is add an RC filter to the CMOS gate power > supply. > > I use this version (with a 74HC86 as the input gate) on my HP-531xx time > interval calibrator circuit. Wenzel says an HC gate works better than AC > logic if you don't need to handle higher freqs. It provides surprisingly good > performance for such a simple circuit. > > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Input filter for data logger
Here are Wenzel's input circuits: http://www.wenzel.com/documents/waveform.html The TAPR TICC uses a slightly modified version of the two transistor circuit. Also check out the LPRO-101 manual for their versions of the single CMOS gate squarer. One thing they do is add an RC filter to the CMOS gate power supply. I use this version (with a 74HC86 as the input gate) on my HP-531xx time interval calibrator circuit. Wenzel says an HC gate works better than AC logic if you don't need to handle higher freqs. It provides surprisingly good performance for such a simple circuit. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Input filter for data logger
I have four MV89As. Two are excellent and run at a case temp around 43C/110F. One tends to jump frequency when you move it, it also sits around 43C/110F though. The final one has a broken temp controller. Mounted inside a large block of expanded polstyrene insulation, it reached 92C/198F before I realised something was not right. The best MV89A has been running continuously for 18 months and has drifted LF by 1.2ppb in that time, compared with two GPSDOs and the GB3MHZ GPS-locked beacon on 1296.830MHz The two bad ones were cheap and were still soldered to bits of hacksawed PCB. Neil On 19/11/2017 22:56, Angus wrote: On Sun, 19 Nov 2017 16:10:54 -0500, you wrote: The MV89 is a beast of an OCXO and uses more power at warm-up than any other I know of. But it is spec'ed ~1W for steady state. Which means the outside of the OCXO should be about hand-warm. If it's too hot, then the heater circuit is probably broken and running at full-throttle. If so, I think something is not OK with my MV89. It is probably 110 degrees or so. They do run hot, so if that's 110 DegF and not DegC it's OK (depending on ambient...) The data sheet says 4.2W at 25 DegC. BTW if anyone is thinking of visiting www.morion.com.ru this might not be a good day - when I tried earlier the AV claimed it was infected and the script blocker went nuts, so they did seem to have got infected by something. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Input filter for data logger
t...@leapsecond.com said: > Note the picPET outputs a h/w event counter along with the timestamp. This > can be ignored but the counter helps identify noisy inputs, allows one to > distinguish between fast and too-fast inputs, and was very useful during > development to validate the accuracy of the device. The event counter also lets you catch lost events in the downstream gear that is capturing/logging data from the picPET. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Input filter for data logger
On Sun, 19 Nov 2017 16:10:54 -0500, you wrote: >> The MV89 is a beast of an OCXO and uses more power at warm-up than any >> other >> I know of. But it is spec'ed ~1W for steady state. Which means the >> outside of the OCXO should be about hand-warm. If it's too hot, then >> the heater circuit is probably broken and running at full-throttle. > >If so, I think something is not OK with my MV89. It is probably 110 >degrees or so. They do run hot, so if that's 110 DegF and not DegC it's OK (depending on ambient...) The data sheet says 4.2W at 25 DegC. BTW if anyone is thinking of visiting www.morion.com.ru this might not be a good day - when I tried earlier the AV claimed it was infected and the script blocker went nuts, so they did seem to have got infected by something. Angus. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Input filter for data logger
Hi Vlad, > However, the logger measure it TWICE ! I think its because of that > signal form. Here is the output (in microseconds): Assuming the STM32 is set to trigger on the rising edge, a 2x output will occur if there is bounce from a falling edge. Normally this is not desirable, but there are cases where measuring both rising and falling edge improves resolution. For example I have a version of the picPET that timestamps both edges (this gives you pulse width and duty cycle information). The CNT-91 counter also does this in raw timestamp mode. > 26.5837255 > 26.23559295 > 26.5941842 > However, it is some "spikes" in the data flow (see above the number > "26.23559295", which suppose to be something as "26.58..."). I can't > understand the reason for that. That's a software problem for sure. Do you use interrupts? Or some library code for formatting and output? > I would assume, some improvement needs to be done for the data logger > input. I am using 2N5485 and 74AC04 elements there. Any advises will be > appreciated ! Thanks ! It sounds like you have two problems: 1) h/w signal conditioning before the STM32, and 2) a s/w timing issue in your code or in how you use the USART. To separate them, try a clean square wave directly into the STM32 over a range of frequencies from slow to fast to faster than the STM32 can keep up. BTW, the good news is that your time stamping output looks like the picPET -- http://leapsecond.com/pic -- which means that you can use TimeLab to directly capture and/or display all your data (phase, frequency, adev, etc.). Note the picPET outputs a h/w event counter along with the timestamp. This can be ignored but the counter helps identify noisy inputs, allows one to distinguish between fast and too-fast inputs, and was very useful during development to validate the accuracy of the device. As an example, the old PIC I'm using is limited to 125 samples per second (mostly due to RS232 transmit time at 19,200 baud), but with an 8-bit event count you can directly measure frequencies up to 256 times greater (32 kHz). With a 16-bit event counter that number climbs to 8 MHz. All this without a pre-scaler. /tvb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Input filter for data logger
Oops I meat to say: Thats a MOSFET variant of a fairly standard JFET-BJT feedback amplifier. Bruce > On 20 November 2017 at 11:47 Bruce Griffiths> wrote: > > > Hoi Attila > > That's a fairly standard JFET BJT negative feedback amp that's not > usually unstable. > > The unity gain version has been employed as the input stage of various > high impedance oscilloscope preamps. > > Bruce > > > > > > On 20 November 2017 at 11:21 Attila Kinali wrote: > > > > On Sun, 19 Nov 2017 16:10:54 -0500 > > Vlad wrote: > > > > > > > > > > Here is my schematic: > > > > > > http://www.patoka.ca/OCXO/LOGGER/IMG_20171119_155907272.jpg > > > > > > > > > > Ok.. I am surprised, this doesn't oscillate. > > > > You have a two stage amplifier, where the second stage > > has a negative feedback path into the first stage. > > > > When a pulse comes in, the jfet will turn on and conduct > > current through its drain and source resistors. When the > > current reaches something around 6-8mA the pnp will start > > conducting. But the collector current of the pnp goes into > > the source resistor of the jfet. This will increase the > > voltage on the source, thus decreasing the gate-source > > voltage, thus turn the jfet off, which in turn will turn > > the pnp off, which in then will stop conducting, thus > > no current into the source resistor, thus the jfet will > > start conducting again... I guess you get it. > > > > > > > > > > I did some simple tests for this. In it seems it was OK up to > > > 10Mhz. > > > > > > > > > > > > > > But guessing from what you showed, I would say that > > > > your amplifier > > > > circuit isn't stable and has some gain peaking at > > > > around 10MHz. > > > > There are two ways to proceed: Either optimize your > > > > circuit or > > > > simplify it using modern components to the input signal > > > > you expect. > > > > > > > > > > > > > > The main purpose for this circuit is to protect the MCU input > > > and make > > > some sine to square conversion. > > > > > > > > > > Use a biased 74AC04. That's the easiest. And you will have very > > little noise degradation. > > > > I would think that the MCU can probably take more abuse than the > > 74AC. Modern ASICs have quite a bit of protection circuits on > > their inputs. I am not sure whether the 74-families have seen > > upgrades on their protection circuits in the last 30-40 years. > > > > Attila Kinali > > > > -- > > You know, the very powerful and the very stupid have one thing in > > common. > > They don't alters their views to fit the facts, they alter the > > facts to > > fit the views, which can be uncomfortable if you happen to be one > > of the > > facts that needs altering. -- The Doctor > > > > ___ > > time-nuts mailing list -- time-nuts@febo.com > > To unsubscribe, go to > > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > and follow the instructions there. > > > > > ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Input filter for data logger
Hoi Attila That's a fairly standard JFET BJT negative feedback amp that's not usually unstable. The unity gain version has been employed as the input stage of various high impedance oscilloscope preamps. Bruce > > On 20 November 2017 at 11:21 Attila Kinaliwrote: > > On Sun, 19 Nov 2017 16:10:54 -0500 > Vlad wrote: > > > > > > Here is my schematic: > > > > http://www.patoka.ca/OCXO/LOGGER/IMG_20171119_155907272.jpg > > > > > > Ok.. I am surprised, this doesn't oscillate. > > You have a two stage amplifier, where the second stage > has a negative feedback path into the first stage. > > When a pulse comes in, the jfet will turn on and conduct > current through its drain and source resistors. When the > current reaches something around 6-8mA the pnp will start > conducting. But the collector current of the pnp goes into > the source resistor of the jfet. This will increase the > voltage on the source, thus decreasing the gate-source > voltage, thus turn the jfet off, which in turn will turn > the pnp off, which in then will stop conducting, thus > no current into the source resistor, thus the jfet will > start conducting again... I guess you get it. > > > > > > I did some simple tests for this. In it seems it was OK up to 10Mhz. > > > > > > > > > > But guessing from what you showed, I would say that your > > > amplifier > > > circuit isn't stable and has some gain peaking at around > > > 10MHz. > > > There are two ways to proceed: Either optimize your circuit or > > > simplify it using modern components to the input signal you > > > expect. > > > > > > > > > > The main purpose for this circuit is to protect the MCU input and > > make > > some sine to square conversion. > > > > > > Use a biased 74AC04. That's the easiest. And you will have very > little noise degradation. > > I would think that the MCU can probably take more abuse than the > 74AC. Modern ASICs have quite a bit of protection circuits on > their inputs. I am not sure whether the 74-families have seen > upgrades on their protection circuits in the last 30-40 years. > > Attila Kinali > > -- > You know, the very powerful and the very stupid have one thing in common. > They don't alters their views to fit the facts, they alter the facts to > fit the views, which can be uncomfortable if you happen to be one of the > facts that needs altering. -- The Doctor > > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Input filter for data logger
On Sun, 19 Nov 2017 16:10:54 -0500 Vladwrote: > Here is my schematic: > > http://www.patoka.ca/OCXO/LOGGER/IMG_20171119_155907272.jpg Ok.. I am surprised, this doesn't oscillate. You have a two stage amplifier, where the second stage has a negative feedback path into the first stage. When a pulse comes in, the jfet will turn on and conduct current through its drain and source resistors. When the current reaches something around 6-8mA the pnp will start conducting. But the collector current of the pnp goes into the source resistor of the jfet. This will increase the voltage on the source, thus decreasing the gate-source voltage, thus turn the jfet off, which in turn will turn the pnp off, which in then will stop conducting, thus no current into the source resistor, thus the jfet will start conducting again... I guess you get it. > I did some simple tests for this. In it seems it was OK up to 10Mhz. > > > But guessing from what you showed, I would say that your amplifier > > circuit isn't stable and has some gain peaking at around 10MHz. > > There are two ways to proceed: Either optimize your circuit or > > simplify it using modern components to the input signal you expect. > > The main purpose for this circuit is to protect the MCU input and make > some sine to square conversion. Use a biased 74AC04. That's the easiest. And you will have very little noise degradation. I would think that the MCU can probably take more abuse than the 74AC. Modern ASICs have quite a bit of protection circuits on their inputs. I am not sure whether the 74-families have seen upgrades on their protection circuits in the last 30-40 years. Attila Kinali -- You know, the very powerful and the very stupid have one thing in common. They don't alters their views to fit the facts, they alter the facts to fit the views, which can be uncomfortable if you happen to be one of the facts that needs altering. -- The Doctor ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Input filter for data logger
The MV89 is a beast of an OCXO and uses more power at warm-up than any other I know of. But it is spec'ed ~1W for steady state. Which means the outside of the OCXO should be about hand-warm. If it's too hot, then the heater circuit is probably broken and running at full-throttle. If so, I think something is not OK with my MV89. It is probably 110 degrees or so. Can you show us what _your_ circuit looks like instead of some bad (literal) screenshot? Here is my schematic: http://www.patoka.ca/OCXO/LOGGER/IMG_20171119_155907272.jpg I did some simple tests for this. In it seems it was OK up to 10Mhz. But guessing from what you showed, I would say that your amplifier circuit isn't stable and has some gain peaking at around 10MHz. There are two ways to proceed: Either optimize your circuit or simplify it using modern components to the input signal you expect. The main purpose for this circuit is to protect the MCU input and make some sine to square conversion. If you only want to time-stamp input pulses and you can ensure that those pulses are between 0 and 5V, then I'd use a 74LVC1G34 or 74LVC1G04, depending on whether you want inversion or not (do not use the 74LVC1G14 as the hysteresis will increase the noise level) I was using 74AC04 just because it was readily available in my junk box. ;-) -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Input filter for data logger
Hi Based on what I’ve seen off of eBay, a properly working surplus MV89A is a rare beast. The ones that are “ouch” to the touch do indeed have malfunctioning oven circuits. Out of a few dozen purchased I don’t think I found one that fully met the specs that it did when shipped. That easily could have been a function of only buying from the cheapest sellers ….. Bob > On Nov 19, 2017, at 11:40 AM, Vladwrote: > > > Hello, > > I am doing another fun project. It is data logger at this time. The "heart" > is MV89A OCXO and the "brain" is STM32. > "The box" has 1PPS input to control DAC which will control OCXO. BTW, this > M89A is pretty hot to touch. My other OCXO's not that much warmed. Is it > normal for this Morion model ? > I woul ask an advise regarding following issue. I have signal generator which > produce the square wave. The freq. is 192Hz. > > http://www.patoka.org/OCXO/LOGGER/IMG_20171119_104659813.jpg > > However, the logger measure it TWICE ! I think its because of that signal > form. Here is the output (in microseconds): > > http://www.patoka.org/OCXO/LOGGER/IMG_20171119_104838190.jpg > > In average delta is .0026041 s, which is almost equal to 384 Hz (192x2) > > For the input I am using the schema similar as HP was using in one of their > counters: > > http://www.patoka.org/OCXO/LOGGER/IMG_20171110_123201987.jpg > > > I tried another source (DDS sine generator, referenced from GPSDO) and that > beast produce exact number of events: > > 26.5404621 > 26.5473008 > 26.5525067 > 26.5577297 > 26.5629260 > 26.5681280 > 26.5733305 > 26.5785262 > 26.5837255 > 26.23559295 > 26.5941842 > 26.5993546 > 26.6045699 > 26.6097716 > 26.6149911 > 26.6202076 > 26.6254149 > 26.6306244 > 26.6358103 > 26.6410386 > 26.6462491 > > > However, it is some "spikes" in the data flow (see above the number > "26.23559295", which suppose to be something as "26.58..."). I can't > understand the reason for that. > The "delta" is .0052 s, which is almost equal to 192 Hz. But data flow is not > that "smooth" though. > > In square wave mode, "school grade" Wavetek generator produced exact 192 > events with no issues. (Except its output frequency is not that stable) > > 21.0578286 > 21.0630547 > 21.0682807 > 21.0735070 > 21.0787330 > 21.0839591 > 21.0891852 > 21.0944112 > 21.0996372 > 21.1048632 > 21.1100892 > > However, if I switch Wavetek to sine, my logger detected twice number of > event (384) > > 97.0185559 > 97.0214570 > 97.0237852 > 97.0266822 > 97.0290048 > 97.0319054 > 97.0342336 > 97.0371408 > 97.0394552 > 97.0423578 > 97.0446802 > 97.0475836 > 97.0499131 > 97.0527969 > 97.0551313 > 97.0580259 > 97.0603560 > 97.0632648 > 97.0655869 > > I would assume, some improvement needs to be done for the data logger input. > I am using 2N5485 and 74AC04 elements there. Any advises will be appreciated > ! Thanks ! > > > -- > WBW, > > V.P. > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Input filter for data logger
On Sun, 19 Nov 2017 11:40:27 -0500 Vladwrote: > I am doing another fun project. It is data logger at this time. The > "heart" is MV89A OCXO and the "brain" is STM32. > "The box" has 1PPS input to control DAC which will control OCXO. BTW, > this M89A is pretty hot to touch. My other OCXO's not that much warmed. > Is it normal for this Morion model ? The MV89 is a beast of an OCXO and uses more power at warm-up than any other I know of. But it is spec'ed ~1W for steady state. Which means the outside of the OCXO should be about hand-warm. If it's too hot, then the heater circuit is probably broken and running at full-throttle. > I woul ask an advise regarding following issue. I have signal generator > which produce the square wave. The freq. is 192Hz. > > http://www.patoka.org/OCXO/LOGGER/IMG_20171119_104659813.jpg > > However, the logger measure it TWICE ! I think its because of that > signal form. Here is the output (in microseconds): > > http://www.patoka.org/OCXO/LOGGER/IMG_20171119_104838190.jpg > > In average delta is .0026041 s, which is almost equal to 384 Hz (192x2) > > For the input I am using the schema similar as HP was using in one of > their counters: > > http://www.patoka.org/OCXO/LOGGER/IMG_20171110_123201987.jpg Can you show us what _your_ circuit looks like instead of some bad (literal) screenshot? But guessing from what you showed, I would say that your amplifier circuit isn't stable and has some gain peaking at around 10MHz. There are two ways to proceed: Either optimize your circuit or simplify it using modern components to the input signal you expect. I personally, would go for simplification, unless you want something special. If you only want to time-stamp input pulses and you can ensure that those pulses are between 0 and 5V, then I'd use a 74LVC1G34 or 74LVC1G04, depending on whether you want inversion or not (do not use the 74LVC1G14 as the hysteresis will increase the noise level) If you want to measure sine input as well, then you have to AC couple and add some bias voltage when using an LVC gate. -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil Stephenson ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Input filter for data logger
Look at the falling edge of your square wave - I'd guess there is some undershoot and it's triggering the extra counts. With the back to back limiting diodes in that circuit, I don't think the ringing shown in your scope trace will matter, however, ringing around the 0V level will matter. I've seen similar with HP 5335A and 5370A counters with inputs set to DC and the level pots set to preset. Change it to AC, or tweak the level pots and the problem goes away. You can probably see the effect on the scope by setting the trigger level somewhere around 0V - sometimes it will trigger on the rising edge and sometimes on the undershoot on the falling edge. On Sun, Nov 19, 2017 at 8:40 AM, Vladwrote: > > Hello, > > I am doing another fun project. It is data logger at this time. The > "heart" is MV89A OCXO and the "brain" is STM32. > "The box" has 1PPS input to control DAC which will control OCXO. BTW, this > M89A is pretty hot to touch. My other OCXO's not that much warmed. Is it > normal for this Morion model ? > I woul ask an advise regarding following issue. I have signal generator > which produce the square wave. The freq. is 192Hz. > > http://www.patoka.org/OCXO/LOGGER/IMG_20171119_104659813.jpg > > However, the logger measure it TWICE ! I think its because of that signal > form. Here is the output (in microseconds): > > http://www.patoka.org/OCXO/LOGGER/IMG_20171119_104838190.jpg > > In average delta is .0026041 s, which is almost equal to 384 Hz (192x2) > > For the input I am using the schema similar as HP was using in one of > their counters: > > http://www.patoka.org/OCXO/LOGGER/IMG_20171110_123201987.jpg > > > I tried another source (DDS sine generator, referenced from GPSDO) and > that beast produce exact number of events: > > 26.5404621 > 26.5473008 > 26.5525067 > 26.5577297 > 26.5629260 > 26.5681280 > 26.5733305 > 26.5785262 > 26.5837255 > 26.23559295 > 26.5941842 > 26.5993546 > 26.6045699 > 26.6097716 > 26.6149911 > 26.6202076 > 26.6254149 > 26.6306244 > 26.6358103 > 26.6410386 > 26.6462491 > > > However, it is some "spikes" in the data flow (see above the number " > 26.23559295", which suppose to be something as "26.58..."). I can't > understand the reason for that. > The "delta" is .0052 s, which is almost equal to 192 Hz. But data flow is > not that "smooth" though. > > In square wave mode, "school grade" Wavetek generator produced exact 192 > events with no issues. (Except its output frequency is not that stable) > > 21.0578286 > 21.0630547 > 21.0682807 > 21.0735070 > 21.0787330 > 21.0839591 > 21.0891852 > 21.0944112 > 21.0996372 > 21.1048632 > 21.1100892 > > However, if I switch Wavetek to sine, my logger detected twice number of > event (384) > > 97.0185559 > 97.0214570 > 97.0237852 > 97.0266822 > 97.0290048 > 97.0319054 > 97.0342336 > 97.0371408 > 97.0394552 > 97.0423578 > 97.0446802 > 97.0475836 > 97.0499131 > 97.0527969 > 97.0551313 > 97.0580259 > 97.0603560 > 97.0632648 > 97.0655869 > > I would assume, some improvement needs to be done for the data logger > input. I am using 2N5485 and 74AC04 elements there. Any advises will be > appreciated ! Thanks ! > > > -- > WBW, > > V.P. > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/m > ailman/listinfo/time-nuts > and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Input filter for data logger
Hello, I am doing another fun project. It is data logger at this time. The "heart" is MV89A OCXO and the "brain" is STM32. "The box" has 1PPS input to control DAC which will control OCXO. BTW, this M89A is pretty hot to touch. My other OCXO's not that much warmed. Is it normal for this Morion model ? I woul ask an advise regarding following issue. I have signal generator which produce the square wave. The freq. is 192Hz. http://www.patoka.org/OCXO/LOGGER/IMG_20171119_104659813.jpg However, the logger measure it TWICE ! I think its because of that signal form. Here is the output (in microseconds): http://www.patoka.org/OCXO/LOGGER/IMG_20171119_104838190.jpg In average delta is .0026041 s, which is almost equal to 384 Hz (192x2) For the input I am using the schema similar as HP was using in one of their counters: http://www.patoka.org/OCXO/LOGGER/IMG_20171110_123201987.jpg I tried another source (DDS sine generator, referenced from GPSDO) and that beast produce exact number of events: 26.5404621 26.5473008 26.5525067 26.5577297 26.5629260 26.5681280 26.5733305 26.5785262 26.5837255 26.23559295 26.5941842 26.5993546 26.6045699 26.6097716 26.6149911 26.6202076 26.6254149 26.6306244 26.6358103 26.6410386 26.6462491 However, it is some "spikes" in the data flow (see above the number "26.23559295", which suppose to be something as "26.58..."). I can't understand the reason for that. The "delta" is .0052 s, which is almost equal to 192 Hz. But data flow is not that "smooth" though. In square wave mode, "school grade" Wavetek generator produced exact 192 events with no issues. (Except its output frequency is not that stable) 21.0578286 21.0630547 21.0682807 21.0735070 21.0787330 21.0839591 21.0891852 21.0944112 21.0996372 21.1048632 21.1100892 However, if I switch Wavetek to sine, my logger detected twice number of event (384) 97.0185559 97.0214570 97.0237852 97.0266822 97.0290048 97.0319054 97.0342336 97.0371408 97.0394552 97.0423578 97.0446802 97.0475836 97.0499131 97.0527969 97.0551313 97.0580259 97.0603560 97.0632648 97.0655869 I would assume, some improvement needs to be done for the data logger input. I am using 2N5485 and 74AC04 elements there. Any advises will be appreciated ! Thanks ! -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.