That circuit is used by several ring tester projects. I've built exactly that circuit and it works fine for me. The only critical components are C2 and C3 (PP film caps). Have you double-checked your PCB? Have all components the correct value? Have you checked the signal at the counter output (checking at the DUT might load the signal too much)?
OK Madires. Could you give me links to projects where this scheme is applied? Can you post a photo of how you check the pulse transformer? I would like to see your waveform on the Counter output at the same time. There's one more thing I can't figure out. If I connect your circuit to Probe 1,2,3. How will I test the rest of the components? The tester already sees the input resistance of the circuit as a connected resistor.
Strateg58: please don't be rude. Remember madires and the other people do this for free for helping others. And they(we) normally design and test each proposal before proposing it.
To use the ring tester hardware option, you need to enable and later use the proper entry on the menu:
/*
* ring tester (LOPT/FBT tester)
* - uses T0 directly as counter input
* - uncomment to enable
* - select the pulse output: either dedicated pin or probes
* - see RINGTESTER_PORT in config-<MCU>.h for dedicated pin
*/
#define HW_RING_TESTER
//#define RING_TESTER_PIN /* dedicated pin */
#define RING_TESTER_PROBES /* probes */
(Of course the add-on circuit had to be connected/disconnected according to the measurement intended).
Regarding the waveforms, I made a simulation with some approximate values.
(If madires would like to share with me(us) the exact pulse-train parameters, I could further improve the sim), but regardless, I think the attached prove the point.
EDIT:
Updated sim, with "ring pulses" clearly visible.
OK Madires. Could you give me links to projects where this scheme is applied? Can you post a photo of how you check the pulse transformer? I would like to see your waveform on the Counter output at the same time. There's one more thing I can't figure out. If I connect your circuit to Probe 1,2,3. How will I test the rest of the components? The tester already sees the input resistance of the circuit as a connected resistor.
Please see Dumidan's post on page 282 (based on Bob Parker's ring tester). There are two options to connect the ring tester. The first one is to use dedicated pins (RING_TESTER_PIN). And the second one is to use the standard probe pins (RING_TESTER_PROBES), i.e. the ring tester is connected temporarily to the probe pins and T0 as long as the ring tester function runs. After that you simply remove the ring tester, end the ring tester function and return to the normal probing.
Regarding the waveforms, I made a simulation with some approximate values. (If madires would like to share with me(us) the exact pulse-train parameters, I could improve the attached graph, but regardless, I think the attached prove the point).
The trigger pulse is 2ms.
I propose a new version of the addition of the TTester circuit for measuring quartz and ceramic resonators in the range of 100 kHz - 20 MHz. The Chinese version HCF4060BE with a supply voltage of 6V and the use of an internal divider, allows you to measure quartz up to 20 MHz. Malaysian variant up to 16 MHz. I did not manage to lower the frequency for sentries (32768 Hz).
I was looking whether this frontend variant could further improved. However, according to the datasheets, and some experiments I conducted on breadboard, as Yuriy_K inferred
it highly depends on the particular IC-vendor available/choosed.
I don't know the makers of what he tested, and what results obtained from 5V, but the originals National CD4060B and Philips HEF6040B I found on my local market can only reach a few MHz if powered by the 5V of our CTester. It could go faster if powered by 12V, though. Therefore we could implement a boost converter and a filter for that, but IMO that would overcomplicate the frontend design. Or maybe it could be powered by the 9V of some CTesters, if that's the case.
Anyways, I found a manufacturer-recommended design and values for 32MHz. Perhaps somebody with a faster IC could test it and let us know.
And for eye candy, I also attach a 4MHz/16 waveform from the Philips on a breadboard, with the recommended design I posted earlier.
Or you could use the
74HC4060 version which can go to 28-30Mhz 4.5V or a bit more at 5V.
Anyways, I found a manufacturer-recommended design and values for 32MHz. Perhaps somebody with a faster IC could test it and let us know.
Hmmm... The image you linked (CD4060B Crystal Oscillator - 32MHz.png) is for 32
Khz and not 32
Mhz
Apologies, my old eyes. I removed the misleading picture while looking for an updated one.
And regarding the 74HC4060 you linked, it seems a better IC for the task. Still, I can't find it locally, so maybe somebody already has it and can implement/tune a test circuit for high frequencies. Design considerations I suggest: As this is intented for test gear, a wide bandwidth and low power is desired, to allow testing of as many xtals as possible, and not overdriving some of those.
An oscilloscope with a 0.027uf capacitor
I just flashed my BSIDE ESR02 Pro with 1.51m (+ the cap.c fix) and I can't get the unit to calibrate and get weird values on certain terminals.
First I'm getting a reported ~50uF between terminals 2-3 with nothing connected to the unit. Putting an actual capacitor on 2-3 gives a reasonable value (but not on 1-2 nor 1-3 -- though resistors work).
I figured it was a calibration issue, so after measuring a 2.2uF cap 4x times I went to the Adjustment menu but it failed here:
a6 c0 12 13 23
32 29 157
I'm guessing c0 for 2-3 is too large.
Any ideas?
My build config is here:
https://github.com/roger-/bside-firmware/tree/main/modified
Yes, the limit is 100pF. Could you please run a self-test and post the values?
Yes, the limit is 100pF. Could you please run a self-test and post the values?
Is the Test menu supposed to give values at the end? Mine doesn't, but after running it Show Values gives:
Ri-: 20.4 R
Ri+: 23.1 R
C0: 43 pF
R0: 0.14 R
Vref: 1093 mV
Vcc: 5001mV
AComp: 0mV
No, the self-test simply runs each test five times. I'm interested in the values of T1, T2, T3, T5 and T6.
No, the self-test simply runs each test five times. I'm interested in the values of T1, T2, T3, T5 and T6.
Ah, got it. Here are the values I get:
T1: 1093 mV
T2: 13 18 23
T3: -44 -88 -49
T4: (none shown)
T5: 0 0 0
T6: 4995 4995 4996
I think 50uF is too much for nothing connected. Please double check the cap.c you're using for the make is dated around dec 2023.
You could also check with older m-firmware, or k-firmware, to confirm/discard whether there's a hardware issue (the easier to fix: white solder residues).
In the meantime I found something curious: it looks the second number and pin of the 1.51m results text are shiftted 1bit upward. Is this intentional, or something that requires checking?
Ah, got it. Here are the values I get:
T2: 13 18 23
T3: -44 -88 -49
These results are poor, especially in the T3 test. The results in tests T2-T3 should be close to 0 and not differ from each other by more than 5 units. Check the values of the measuring resistors 680 Ohm and 470 kOhm.
You can compare the results of your tests with similar tests of other participants on page 369.
You also need to remove all the conductors that you connected for the ICSP interface and repeat selftest!
In the meantime I found something curious: it looks the second number and pin of the 1.51m results text are shiftted 1bit upward. Is this intentional, or something that requires checking?
No, could be some display glitch.
In the meantime I found something curious: it looks the second number and pin of the 1.51m results text are shiftted 1bit upward. Is this intentional, or something that requires checking?
No, could be some display glitch.
This is the principle of constructing a color pixel matrix. Blue is on top, Green is in the middle, Red is at the bottom. The Blue image is raised 1/3 of a pixel relative to the Green, and the Red is 2/3 lower than the Blue. It's almost a line down... Look at the photo.
That would explain it, but in my case, the shift looks like exactly 1 pixel, and only happens on that particular screen.
Anyways I will flash another color set to check.
Feliciano Is this 1 pixel shift visible when you use your 8x16_alt_hf font?
Will there be the same effect if you use a different font?
Seems Yuriy_k observation about the RGB construction is the answer, but in my display is more noticeable than others (specially with a relatively small font). You can notice "the ladder" on the color line when using a terminals sequence R-G-B with the original 8x16_hf font. (And in fact that also explains the ghosting on the purple of my previous images with my custom font).
Thanks, guys.
Yea, my TC1 screen definitely exhibits this same color shift as Feliciano's. I guess we can't really complain since the tester was less than $25 when I bought it.
On another note, I did change my firmware so that it upscales capacitance, resistance and zener readings. No more 9700nF capacitors and 6800mV zeners for me.
This height issue should go away if you rotate your display 90 degrees in firmware... I wonder if this means that the little screens were manufactured to be used as vertical ones.