[Tfug] OT: PIC ADCs and differential inputs

Bexley Hall bexley401 at yahoo.com
Wed Oct 21 09:38:19 MST 2009


Hi Adrian,

> > "Hobby".  Therefore you are really only looking at "one off"
> > and don't need a "mass produced" solution (different sets
> > of economies at work).
> >
> > How are your space, time and cost constraints?
> > (time as in development time and "measurement time")
> 
> It is a "hobby" project for work, mostly for my own learning.
> Time constraints  are "when I get around to it", cost is whatever
> I feel like spending on my own learning.
> For all practical purposes, this is a one-off. If it works 
> well... it may become a "dozen or two"-off, paid for by
> work, at which point I may design a dedicated board.
> Of course.. at that point I may just add a 
> real differential ADC chip read off I2C/etc. by the PIC.

By then, you will *know* what the real issues are (were)
("Make one to throw away")

> Until then its just rough breadboarding with what I have on hand.

> > > Measuring a single 48V power suppply is pretty straight
> > > forward, simple resistor divider network referenced to ground.
> > > But measuring multiple 48V where the ground reference of each
> > > is behind a diode creates a potential short circuit loop.
> > > Trying to then measure a 100mV current shunt with a 48V
> > > offset at the same time is pretty useless as there is no
> > > dynamic range in the
> > > ADC (works out to about 60mV per LSB at 10bit).
> >
> > The easy/cheap way that I have always done this is to use
> > a VFC (e.g., VCO) and just trade time for precision.
> 
> Hmmm.. It is all DC I am trying to measure (at the moment),
> and I was probably going to put a resistor/cap front end filter

"anti-aliasing"

> on it to remove high frequency switching noise from the PS/load. I
> hadn;t thought of a VCO, but it would probably work pretty well.

I like using synchronous VFC's (slightly different beast than
a VCO).  I've always built them out of semi-discrete components
(a flip-flop, FET/analog switch, comparator and capacitor)
but this ends up taking a fair bit of real estate.  You may
be better off hacking together something cruder.

I'd look into a CMOS 555 for the VCO.  Drive the emitter side of
an iso-optilator from the output.  Let the detector feed into
a counter/timer channel on the PIC (i.e., you're dealing with
counts and inverse counts instead of "volts").  You can then 
locate these on the two "subsystems" that are isolated (diode)
from your main DAS (probably put the DAS on the "48V bus"?).
This allows your main DAS to sit on a "normal" ground suitable
for the other things that it might talk to (enet).

The VCOs can either look at differences (e.g., across the
shunt) *or* can deal in "absolutes" (and your software can
form the differences algebraically).  E.g., reference each
circuit to a "local" ground; measure the supply side of
the shunt with one and the load side of the shunt with the
other.  This gives you *three* readings:
- voltage available *at* load (load side of shunt)
- voltage available *on* battery (supply side of shunt)
- current into/out of battery (K * difference)
You can then power each VCO from the "local" 48V (feeds
a small 3 terminal regulator, etc.) -- remember, you just
need enough power for the (CMOS!) 555 and the iso-optilator
so this is a tiny power requirement!

Where this approach is a win in small quantities is that
you can afford to calibrate it (something that would be
costly in a mass produced market).  Depending on the
VCO chosen, this could be very linear (a characteristic
of the synchronous VFC design that I like).  So, a simple
two point calibration would give you gain and offset
(i.e., y = mx + b) figures (for each VCO).

> I had thought about building a pseudo-differential 
> switching front end, but discarded it as I didn;t really
> want to try and mess with the timing issues at this point.
> 
> [snip]
> > Your bigger problem is the different ground references.
> 
> Yep... At some point you can pretty much guarantee the -48V
> side will be grounded to the rack by some piece of equipment. My

Is this CO talking battery?  Or power for PoE?

> measuring box will sit in the rack, so its case may become that 
> ground potential.
 
> > If you had control over the design (I assume you don't)
> > that you are instrumenting, you could move the shunts to the
> > ground legs and do ground referenced measurements.
> 
> I don't... Basically, that is the solution I came up with.
> Move the shunts to 
> the ground legs of the supplies and remove the diodes on
> the ground to create 
> a common supply reference. But then I would have to float
> that reference up a 
> volt or two relative to the measurement board ground so I
> can measure current 
> thru the shunt, in both directions, otherwise during
> battery charging the 
> shunt voltage becomes negative.

Yes, I neglected to see this  :<  Though it is obvious from
your schematic.

> Making sure the measurement board ground is 
> isolated from the chassis becomes important then...
> 
> > For a hobbyist project, get a couple of dirt cheap PICs
> > and put one on each measurement point.  Then let them
> > talk to "something" that handles the data however you want
> > to handle it.
> 
> Yep... The big advantage in starting out was that I am
> using a Olimex "PIC-WEB" board. Built in ethernet, web, telnet,
> SMTP, SNMP, etc. from the TCP/IP stack provided by MicroChip.

*Don't* put that anyplace where someone/thing hostile can talk 
to it.  These stacks are typically "toys" and won't stand up to
any sort of "attack".  Also, look through the sources to
see if they use any heavy handed techniques that could
interfere with your data acquisition.  (like disabling interrupts
for long periods of time, etc.)

> I haven;t tried recompiling yet, but 
> the source looks *mostly* straight forward and simple to
> strip down to the bare minimum I need/want.

Unless you *need* to talk to it via a web browser, etc.
I would just make the PIC send out UDP packets "blindly"
(i.e., have something *external* assume the responsibility 
for "catching" them so the PIC is simple/dumb/robust).
If you ever have to talk to the PIC (to give it calibration
factors, for example), you could shut down the data acquisition
activities for that time so you don't have to juggle things.

> The disadvantage is that the ADC references are 
> already hard-wired for the onboard temp/etc. sensors.
> 
> My second plan of attack was to get a stand-alone
> differential ADC or two on a 
> serial bus and do the measurement there.

Yes, but you'll still have to isolate that somehow.
And, unless it is a single (differential) channel device,
you'll have to be able to send "commands" (even if it is a
single "channel select bit") back to it over that isolated
interface.

> If it ever scales up to 
> the "dozen-off" model that might infact be a better plan as
> I could then 
> integrate additional remote sensors dozens/hundreds of feet
> away.



      




More information about the tfug mailing list