Re: ESR Meter - Roll your own - ESRrev0.JPG

[John Popelish]

Well, the problem is that there's a dichotomy (or maybe a trichotomy)
in the wish lists.

First we have the service tech's unit:

- range up to 10 or 100 ohms

10 ohms would be a practical upper limit for anything I
would need.

with 0.01 resolution
- measurement frequency the equivalent of 100kHz
- no need to distinguish between impedance and ESR
- accuracy is of little importance, 10% is more than good enough,
we are looking for order of magnitude changes

Up to this point, I would be happy with an analog movement
with a logarithmic scale.

- must be able to measure in-circuit, and preferably without
concern about polarity, so voltage should be low (say < 200mV) and
current should be 50-100mA RMS maximum.

Could we say 200 mV peak to peak, open circuit, from a 10
ohm source?

- two wire probe is probably all that's practical, we have to beat
the convenience of tacking a known-good cap across the part and
trying it out

I think there are clips that make two contacts, one on each
side of the contact point. That makes in circuit, 4
terminal operation practical, if we can find or construct them.

- it's reasonable to expect the meter to survive connection to a large
capacitor charged to ~400VDC without complaint

That might be the toughest spec to meet, unless the initial
hook up is always a discharge period, and you then push a
button to excite the measurement. Still probably the most
complicated part of the design.

- should be simple/cheap/reliable/rugged and easy to use
- a "Pike" model is possible that would analyze the cap and deliver
a go/no-go indication (or possibly two for low-Z and regular caps)

Just green, yellow and red sections on that analog scale.

Then we have the SMPS designer's unit:

That one might need the digital readout.

 

[Spehro Pefhany]

Fred Bloggs wrote:
John Larkin wrote:
Fred Bloggs wrote:
John Larkin wrote:
Fred Bloggs wrote:
John Larkin wrote:

That's about right, but it's still going to be simpler than
most of the goofy and truly terrible "esr" meters we've seen
here lately. You may as well measure leakage and dielectric
absorption while you're at it; code is cheap.

Granted they are amateurish junk, but your designs and ideas
are so *ugly* they are borderline grotesque. When you have
something artful to suggest that will be the day....

You don't approve of my products? Show us some of yours.

As they say, I don't have to be a chef to know the food stinks...

Show us something you've designed.

You show us an esr meter that doesn't require a VMX crate.

I suggest we have an esr-meter design contest. However, to
make it usenet friendly, and accessible to the readers, all
entries must be made in ASCII drawings, annotated with text.

Why not make it a group project, for real? I'd be willing to do the
first cut at schematic and algorithms. What we really need is someone
to hack the real code; I hate to program, and I'm going to do it most
of the weekend likely [1], so I'm not going to volunteer for that
part!

I'll volunteer, on provision that you, and anyone else contemplating a
serious contribution, read a few things so as to understand the
problem domain (testing, and in particular in-circuit testing of
e-caps) better.

It looks logical that it would be your task to do that research and
post a concise summary of requirements.

John

Well, the problem is that there's a dichotomy (or maybe a trichotomy)
in the wish lists.

First we have the service tech's unit:

- range up to 10 or 100 ohms with 0.01 resolution
- measurement frequency the equivalent of 100kHz
- no need to distinguish between impedance and ESR
- accuracy is of little importance, 10% is more than good enough,
we are looking for order of magnitude changes
- must be able to measure in-circuit, and preferably without
concern about polarity, so voltage should be low (say < 200mV) and
current should be 50-100mA RMS maximum.
- two wire probe is probably all that's practical, we have to beat
the convenience of tacking a known-good cap across the part and
trying it out
- it's reasonable to expect the meter to survive connection to a large
capacitor charged to ~400VDC without complaint
- should be simple/cheap/reliable/rugged and easy to use
- a "Pike" model is possible that would analyze the cap and deliver
a go/no-go indication (or possibly two for low-Z and regular caps)

Then we have the SMPS designer's unit:

-








Best regards,
Spehro Pefhany

 

[Spehro Pefhany]

On Sat, 14 Jul 2007 10:07:11 -0700, the renowned John Larkin

Fred Bloggs wrote:
John Larkin wrote:
Fred Bloggs wrote:
John Larkin wrote:
Fred Bloggs wrote:
John Larkin wrote:

That's about right, but it's still going to be simpler than
most of the goofy and truly terrible "esr" meters we've seen
here lately. You may as well measure leakage and dielectric
absorption while you're at it; code is cheap.

Granted they are amateurish junk, but your designs and ideas
are so *ugly* they are borderline grotesque. When you have
something artful to suggest that will be the day....

You don't approve of my products? Show us some of yours.

As they say, I don't have to be a chef to know the food stinks...

Show us something you've designed.

You show us an esr meter that doesn't require a VMX crate.

I suggest we have an esr-meter design contest. However, to
make it usenet friendly, and accessible to the readers, all
entries must be made in ASCII drawings, annotated with text.

Why not make it a group project, for real? I'd be willing to do the
first cut at schematic and algorithms. What we really need is someone
to hack the real code; I hate to program, and I'm going to do it most
of the weekend likely [1], so I'm not going to volunteer for that
part!

I'll volunteer, on provision that you, and anyone else contemplating a
serious contribution, read a few things so as to understand the
problem domain (testing, and in particular in-circuit testing of
e-caps) better.

It looks logical that it would be your task to do that research and
post a concise summary of requirements.

John

Well, the problem is that there's a dichotomy (or maybe a trichotomy)
in the wish lists.

First we have the service tech's unit:

- range up to 10 or 100 ohms with 0.01 resolution
- measurement frequency the equivalent of 100kHz
- no need to distinguish between impedance and ESR
- accuracy is of little importance, 10% is more than good enough,
we are looking for order of magnitude changes
- must be able to measure in-circuit, and preferably without
concern about polarity, so voltage should be low (say < 200mV) and
current should be 50-100mA RMS maximum.
- two wire probe is probably all that's practical, we have to beat
the convenience of tacking a known-good cap across the part and
trying it out
- it's reasonable to expect the meter to survive connection to a large
capacitor charged to ~400VDC without complaint
- should be simple/cheap/reliable/rugged and easy to use
- a "Pike" model is possible that would analyze the cap and deliver
a go/no-go indication (or possibly two for low-Z and regular caps)

(oops, I guess ^N with the wrong window in focus will do that)

Then we have the SMPS designer's unit:

- 0.001 ohm resolution
- reasonable accuracy (say 1% or better)
- must measure actual ESR
- able to measure relatively low value ceramic caps as well
as e-caps
- Kelvin measurement
- variable frequency measurement (maybe 100Hz to 1MHz)
- milliohmmeter for inductors
- no need for in-circuit but should not be damaged by cap
charged to ~50V
- reasonable cost


and hey, if we're dreaming

- complex and real impedance of inductors, resistors and caps over
that range
- ditto with DC bias on capacitors 0-10V and current on inductors
0-2A


Ideally, perhaps, kind of like a low-accuracy version of this guy:
http://cp.literature.agilent.com/litweb/pdf/5989-4435EN.pdf


Best regards,
Spehro Pefhany

 

[John Larkin]

This is a 68332 uP, and a fixed dictionary wouldn't be bad, just a
couple of hundred bytes in rom maybe. My whole application program,
tables and all, comes in under 10K bytes!

If you have a 68332 'going spare' for this, then your approach is prety
spot on. You could check the streams to see if repeat-pattern was common
enough to encode.
- and you could define the count via a dictionary/table as well.
[eg 5 bit index into 32 x 16 bit values ]

-jg

Here's a byte histogram of a typical Spartan 3 config file. Most of
the config bits are zero. I read one Xilinx appnote about the rad
hardness of sram-based FPGAs, and they got the upset rate calculation
down by noting that most config bits actually don't matter!


80,413 NONZERO BYTES


============== SORTED =================

NNN Byte Hex Frequency

0 0 0 181,476
1 255 FF 5,809
2 1 1 5,390
3 128 80 3,991
4 4 4 3,867
5 8 8 3,815
6 16 10 3,785
7 32 20 3,653
8 2 2 3,364
9 48 30 3,282
10 64 40 3,139
11 12 C 1,941
12 3 3 1,587
13 192 C0 1,472
14 36 24 1,038
15 112 70 1,009
16 20 14 936
17 10 A 824
18 144 90 706
19 40 28 699
20 24 18 678
21 9 9 631
22 80 50 626
23 160 A0 602
24 5 5 573
25 96 60 571
26 6 6 558
27 14 E 558
28 56 38 503
29 18 12 498
30 176 B0 487
31 19 13 480
32 60 3C 461
33 28 1C 454
34 129 81 449
35 153 99 449
36 136 88 441
37 13 D 411
38 34 22 408
39 33 21 405
40 195 C3 399
41 68 44 389
42 224 E0 383
43 204 CC 381
44 44 2C 366
45 130 82 358
46 170 AA 354
47 72 48 351
48 7 7 345
49 132 84 345
50 17 11 324
51 52 34 312
52 140 8C 308
53 65 41 299
54 240 F0 294
55 200 C8 290
56 120 78 279
57 66 42 274
58 29 1D 271
59 131 83 267
60 139 8B 242
61 49 31 236
62 30 1E 218
63 254 FE 218
64 157 9D 217
65 58 3A 216
66 45 2D 212
67 196 C4 207
68 138 8A 194
69 199 C7 191
70 51 33 191
71 227 E3 188
72 74 4A 188
73 26 1A 182
74 168 A8 181
75 50 32 180
76 37 25 173
77 122 7A 173
78 152 98 173
79 187 BB 172
80 85 55 166
81 252 FC 164
82 184 B8 161
83 156 9C 152
84 165 A5 146
85 22 16 146
86 193 C1 144
87 238 EE 139
88 42 2A 139
89 148 94 139
90 104 68 137
91 76 4C 135
92 88 58 134
93 137 89 133
94 59 3B 132
95 92 5C 130
96 11 B 129
97 84 54 122
98 102 66 119
99 208 D0 118
100 124 7C 115
101 71 47 114
102 15 F 112
103 250 FA 108
104 35 23 106
105 62 3E 103
106 41 29 101
107 251 FB 98
108 25 19 96
109 188 BC 96
110 21 15 95
111 54 36 93
112 61 3D 92
113 207 CF 91
114 116 74 89
115 55 37 88
116 143 8F 88
117 57 39 86
118 126 7E 85
119 90 5A 83
120 236 EC 83
121 226 E2 80
122 100 64 80
123 211 D3 77
124 146 92 77
125 221 DD 76
126 241 F1 76
127 82 52 75
128 203 CB 72
129 145 91 72
130 243 F3 70
131 194 C2 69
132 81 51 66
133 142 8E 66
134 46 2E 63
135 180 B4 63
136 67 43 61
137 239 EF 60
138 27 1B 60
139 70 46 60
140 253 FD 59
141 97 61 59
142 154 9A 58
143 186 BA 57
144 197 C5 55
145 134 86 55
146 53 35 54
147 108 6C 54
148 69 45 53
149 191 BF 52
150 99 63 52
151 38 26 52
152 158 9E 52
153 98 62 52
154 172 AC 52
155 247 F7 50
156 179 B3 49
157 190 BE 48
158 113 71 47
159 248 F8 47
160 141 8D 46
161 175 AF 45
162 115 73 45
163 201 C9 45
164 225 E1 45
165 78 4E 45
166 114 72 44
167 162 A2 44
168 245 F5 43
169 189 BD 43
170 73 49 43
171 228 E4 43
172 135 87 42
173 133 85 42
174 216 D8 42
175 223 DF 41
176 202 CA 39
177 161 A1 38
178 87 57 37
179 185 B9 37
180 94 5E 36
181 23 17 34
182 31 1F 34
183 147 93 34
184 118 76 34
185 163 A3 33
186 77 4D 32
187 125 7D 32
188 174 AE 32
189 178 B2 32
190 86 56 31
191 106 6A 31
192 149 95 30
193 234 EA 30
194 198 C6 29
195 206 CE 29
196 242 F2 29
197 232 E8 28
198 164 A4 27
199 220 DC 27
200 244 F4 26
201 39 27 25
202 93 5D 24
203 177 B1 24
204 121 79 23
205 150 96 23
206 105 69 22
207 83 53 21
208 89 59 20
209 182 B6 20
210 110 6E 20
211 119 77 18
212 95 5F 18
213 63 3F 18
214 181 B5 17
215 117 75 16
216 212 D4 16
217 219 DB 15
218 101 65 15
219 230 E6 15
220 218 DA 15
221 43 2B 14
222 205 CD 14
223 209 D1 14
224 171 AB 13
225 75 4B 12
226 235 EB 11
227 169 A9 11
228 222 DE 11
229 79 4F 10
230 127 7F 10
231 123 7B 10
232 151 97 8
233 215 D7 8
234 47 2F 8
235 109 6D 8
236 173 AD 8
237 214 D6 8
238 166 A6 8
239 167 A7 7
240 213 D5 7
241 103 67 6
242 217 D9 6
243 233 E9 5
244 246 F6 5
245 111 6F 4
246 229 E5 4
247 210 D2 4
248 155 9B 3
249 91 5B 3
250 249 F9 3
251 231 E7 2
252 183 B7 2
253 159 9F 2
254 237 ED 1
255 107 6B 1

 

[Fred Bloggs]

On Sat, 14 Jul 2007 14:06:40 -0500, Spehro Pefhany


On Sat, 14 Jul 2007 10:07:11 -0700, the renowned John Larkin


Fred Bloggs wrote:

John Larkin wrote:

Fred Bloggs wrote:

John Larkin wrote:

Fred Bloggs wrote:

John Larkin wrote:

That's about right, but it's still going to be simpler than
most of the goofy and truly terrible "esr" meters we've seen
here lately. You may as well measure leakage and dielectric
absorption while you're at it; code is cheap.

Granted they are amateurish junk, but your designs and ideas
are so *ugly* they are borderline grotesque. When you have
something artful to suggest that will be the day....

You don't approve of my products? Show us some of yours.

As they say, I don't have to be a chef to know the food stinks...

Show us something you've designed.

You show us an esr meter that doesn't require a VMX crate.

I suggest we have an esr-meter design contest. However, to
make it usenet friendly, and accessible to the readers, all
entries must be made in ASCII drawings, annotated with text.

Why not make it a group project, for real? I'd be willing to do the
first cut at schematic and algorithms. What we really need is someone
to hack the real code; I hate to program, and I'm going to do it most
of the weekend likely [1], so I'm not going to volunteer for that
part!

I'll volunteer, on provision that you, and anyone else contemplating a
serious contribution, read a few things so as to understand the
problem domain (testing, and in particular in-circuit testing of
e-caps) better.

It looks logical that it would be your task to do that research and
post a concise summary of requirements.

John

Well, the problem is that there's a dichotomy (or maybe a trichotomy)
in the wish lists.

First we have the service tech's unit:

- range up to 10 or 100 ohms with 0.01 resolution
- measurement frequency the equivalent of 100kHz
- no need to distinguish between impedance and ESR
- accuracy is of little importance, 10% is more than good enough,
we are looking for order of magnitude changes
- must be able to measure in-circuit, and preferably without
concern about polarity, so voltage should be low (say < 200mV) and
current should be 50-100mA RMS maximum.
- two wire probe is probably all that's practical, we have to beat
the convenience of tacking a known-good cap across the part and
trying it out
- it's reasonable to expect the meter to survive connection to a large
capacitor charged to ~400VDC without complaint
- should be simple/cheap/reliable/rugged and easy to use
- a "Pike" model is possible that would analyze the cap and deliver
a go/no-go indication (or possibly two for low-Z and regular caps)

(oops, I guess ^N with the wrong window in focus will do that)

Then we have the SMPS designer's unit:

- 0.001 ohm resolution
- reasonable accuracy (say 1% or better)
- must measure actual ESR
- able to measure relatively low value ceramic caps as well
as e-caps
- Kelvin measurement
- variable frequency measurement (maybe 100Hz to 1MHz)
- milliohmmeter for inductors
- no need for in-circuit but should not be damaged by cap
charged to ~50V
- reasonable cost


and hey, if we're dreaming

- complex and real impedance of inductors, resistors and caps over
that range
- ditto with DC bias on capacitors 0-10V and current on inductors
0-2A


Ideally, perhaps, kind of like a low-accuracy version of this guy:
http://cp.literature.agilent.com/litweb/pdf/5989-4435EN.pdf


Best regards,
Spehro Pefhany

That's getting ridiculous. All we're after is ESR of Al e-caps.

 

[Nico Coesel]

[1] statistical analysis of some FPGA configuration patterns, leading
up to a fast, small compression/decompression algorithm. We need to
fit an application program and 6 megabits of Xilinx config stuff into
a 4 mbit Eprom.

I think Xilinx has some stuff on their site regarding compressing
FPGA patters. IIRC, they're quite compressible, easily (RLL or some
such).

I'm looking for something that will be fast and easy to decode at fpga
config time.

I just did some statistical analysis of a bunch of existing Spartan 3
bit streams. If you treat them as bytes, and histogram the byte codes,
there's some impressive stats, with code 0x00 of course dominant, then
0xFF, and the next 16 most common codes huge, tapering off pretty
hard. That makes sense, since LUT bits are usually zero, so simple
codes like 0x01...0x80 and simple 2-bit combos are most common. Block
ram is usually 0 in our designs, too. So a fixed dictionary should
work pretty well.

So it looks like a byte stream would do, with byte codes that say
stuff like...


00000000 end of file

001nnnnn make N zero bytes, N=1 to 31

010nnnnn make N 0xFF bytes, ditto

011nnnnn the following N bytes are raw, unencoded stuff

1nnnnnnn look up code N in dictionary, N = 1 to 127

where the dictionary is a list of the most common 96 single bytes
followed by the most common 32 byte pairs. Net compression in this
case is just about 1:1!

Something like that.

Now the question is, how much compression will this give? I suppose
I'll have to code it and see. I need less than 2:1 now, and that
shouldn't be hard.

Still working on this after 3 years?

The following site looks promising if you can read German:

http://www.sulimma.de/prak/ws0001/projekte/ralph/Projekt/index.htm

 

[Antonio Pasini]

Done something similar some time ago, to save some flash space for bitsream
on a relatively small micro.

Check this thread on this newsgroup:

http://tinyurl.com/2xkt52

or search with google groups for "compressing Xilinx bitstreams, some test
data".

There are some measures from my real design, and a link to the source code.

Please share your results with the group!

This is a 68332 uP, and a fixed dictionary wouldn't be bad, just a
couple of hundred bytes in rom maybe. My whole application program,
tables and all, comes in under 10K bytes!

If you have a 68332 'going spare' for this, then your approach is prety
spot on. You could check the streams to see if repeat-pattern was common
enough to encode.
- and you could define the count via a dictionary/table as well.
[eg 5 bit index into 32 x 16 bit values ]

-jg

Here's a byte histogram of a typical Spartan 3 config file. Most of
the config bits are zero. I read one Xilinx appnote about the rad
hardness of sram-based FPGAs, and they got the upset rate calculation
down by noting that most config bits actually don't matter!

 

[Spehro Pefhany]

That's getting ridiculous. All we're after is ESR of Al e-caps.

So you prefer the first set of rough specs? Any changes?


Best regards,
Spehro Pefhany

 

[Winfield Hill]

Is it intended to be used in-circuit?

Yes.

 

[John Larkin]

[1] statistical analysis of some FPGA configuration patterns, leading
up to a fast, small compression/decompression algorithm. We need to
fit an application program and 6 megabits of Xilinx config stuff into
a 4 mbit Eprom.

I think Xilinx has some stuff on their site regarding compressing
FPGA patters. IIRC, they're quite compressible, easily (RLL or some
such).

I'm looking for something that will be fast and easy to decode at fpga
config time.

I just did some statistical analysis of a bunch of existing Spartan 3
bit streams. If you treat them as bytes, and histogram the byte codes,
there's some impressive stats, with code 0x00 of course dominant, then
0xFF, and the next 16 most common codes huge, tapering off pretty
hard. That makes sense, since LUT bits are usually zero, so simple
codes like 0x01...0x80 and simple 2-bit combos are most common. Block
ram is usually 0 in our designs, too. So a fixed dictionary should
work pretty well.

So it looks like a byte stream would do, with byte codes that say
stuff like...


00000000 end of file

001nnnnn make N zero bytes, N=1 to 31

010nnnnn make N 0xFF bytes, ditto

011nnnnn the following N bytes are raw, unencoded stuff

1nnnnnnn look up code N in dictionary, N = 1 to 127

where the dictionary is a list of the most common 96 single bytes
followed by the most common 32 byte pairs. Net compression in this
case is just about 1:1!

Something like that.

Now the question is, how much compression will this give? I suppose
I'll have to code it and see. I need less than 2:1 now, and that
shouldn't be hard.

Still working on this after 3 years?

It was interesting three years ago. This month, it's mandatory.

John

 

[Ben Twijnstra]

[1] statistical analysis of some FPGA configuration patterns, leading
up to a fast, small compression/decompression algorithm. We need to
fit an application program and 6 megabits of Xilinx config stuff into
a 4 mbit Eprom.

I wrote the following two small C programs in 2001 for an Altera FPGA. You
can't get it much simpler, and from a whole bunch of config files it gets
about a 50% compression factor (plus or minus 15%).

You may need to set the 'most-common value' from 0x00 to 0xff - I don't have
a lot of Xilinx bitstreams here to check what's best.

You could actually check the 'golden' bitstream to count which byte value
occurs the most...

Good luck!



Ben

 

[John Larkin]

[1] statistical analysis of some FPGA configuration patterns, leading
up to a fast, small compression/decompression algorithm. We need to
fit an application program and 6 megabits of Xilinx config stuff into
a 4 mbit Eprom.

I wrote the following two small C programs in 2001 for an Altera FPGA. You
can't get it much simpler, and from a whole bunch of config files it gets
about a 50% compression factor (plus or minus 15%).

You may need to set the 'most-common value' from 0x00 to 0xff - I don't have
a lot of Xilinx bitstreams here to check what's best.

You could actually check the 'golden' bitstream to count which byte value
occurs the most...

Good luck!



Ben

That's interesting. It only squeezes long runs of zero bytes, but then
that's what you see in the Xilinx config files, too. It could also be
tweaked to do 0xFF's, but I'd have to check to see if that results in
net compression. A singular 0 (or FF) actually expands to two bytes!

Thanks,

John

 

[Winfield]

Here's a cute little digital delay generator...
http://www.highlandtechnology.com/DSS/T560DS.html

I like the product, I think.

Two things I don't like: 1) no date on your webpage
postings like this one, 2) no price, etc. If it's
in early preproduction stages, the page should say
so. If not, it should give further info, or links,
as would a bona fide product.

 

[Winfield]

It will be especially easy if we talk about functional
sections of the circuit, rather than starting out with the
whole system. Someone with lots of ASCII experience can
build up larger drawings as the component sub systems get
distilled. I have no use for contests, but arriving at a
practical design by group consensus is something I can
definitely learn from and probably build.

I like to see some individualism in the mix. A contest
isn't a bad start, because someone posts their beauty,
and it's dissected, with criticism and some improvements
suggested, and it evolves, and finally we get something
truly honed and perhaps even elegant. Watch and learn
if that's your preference but it's better to take part.

I like your idea of posting functional circuit pieces,
I'll use that for my circuit. It's an adaptation of a
design by Len Cox, from SiliconChip's Circuit Notebook,
http://www.siliconchip.com.au/cms/A_103805/article.html
Check it out.

 

[John Larkin]

I like to see some individualism in the mix. A contest
isn't a bad start, because someone posts their beauty,
and it's dissected, with criticism and some improvements
suggested, and it evolves, and finally we get something
truly honed and perhaps even elegant. Watch and learn
if that's your preference but it's better to take part.

I like your idea of posting functional circuit pieces,
I'll use that for my circuit. It's an adaptation of a
design by Len Cox, from SiliconChip's Circuit Notebook,
http://www.siliconchip.com.au/cms/A_103805/article.html
Check it out.

See my sketch in abse.

John

 

[Jasen Betts]

80,413 NONZERO BYTES


============== SORTED =================

NNN Byte Hex Frequency

0 0 0 181,476

2/3 of the data is empty of bits

1 255 FF 5,809

all bits set is next most common.

2 1 1 5,390
3 128 80 3,991
4 4 4 3,867
5 8 8 3,815
6 16 10 3,785
7 32 20 3,653
8 2 2 3,364
9 48 30 3,282
10 64 40 3,139

followed by one bit set.

11 12 C 1,941
12 3 3 1,587
13 192 C0 1,472
14 36 24 1,038

and two bits set....

are there any longer repeating patterns or is the data pretty random
byte by byte

 

[John Larkin]

I'm just not interested in designing anything, it's too much like work.

Work is writing manuals, writing test procedures, doing BOMs, solving
customer problems, marketing, meeting with financial droids, cleaning
my office. Designing is fun!

John

 

[krw]

Work is writing manuals, writing test procedures, doing BOMs, solving
customer problems, marketing, meeting with financial droids, cleaning
my office. Designing is fun!

Dunno, the way you've said you write manuals sounds a lot like
design. ;-) Writing test procedures can be some fun, if done the
same way. The rest of that crap is for the boss to do (and a clean
office is the mark of a sick mind). ;-))

 

[David DiGiacomo]

Yup, it should be 2/4 terminal. Somebody makes some sorta-affordable
Kelvin clips. I'll try to find the source.

Mueller does:

http://www.muellerelectric.com/kelvin_clips.html

Note, the big "Check Inventory" buttons on that page don't work, but the
box on the right does.

 

[John Larkin]

I like the product, I think.

Two things I don't like: 1) no date on your webpage
postings like this one, 2) no price, etc. If it's
in early preproduction stages, the page should say
so. If not, it should give further info, or links,
as would a bona fide product.

We like to have the customers contact us, so we don't post pricing or
manuals. Often the product in question isn't really what they need,
and we can chat them up about their actual application, and something
else may happen. I've gotten megabucks of business from situations
like that.


Dean: We want to use your V680 to measure tach signals.

Me: That won't work very well.

Dean: WHAT?!!!

Me: But explain your problem and we'll build exactly what you need.

Dean: WHAT?!!!


This isn't a shopping-cart sort of product anyhow. We don't really
want to sell onesies of this one, we want OEM business.

It's in regular production, automated test, the whole bit.

John