 |
 |
| View previous topic :: View next topic |
| Author |
Message |
carl
Joined: 06 Feb 2008
Posts: 240
Location: Chester
|
| Shutdown Problem with External Reg/PIC and ADC |
 Posted: Tue Oct 11, 2011 5:26 am |
 |
|
Hi There,
I need a little help if possible.
The problem is related to my previous threads:
http://www.ccsinfo.com/forum/viewtopic.php?t=45743&highlight=
http://www.ccsinfo.com/forum/viewtopic.php?t=46204&highlight=
Prerequisite:
The PIC is powered on its own supply.
The PIC controls (on and off) the boost converter.
The ADC and other circuitry is powered from the boost converter.
The Program works perfectly when the boost converter is always 'on' output_low(SHUTDN2).
The Program fails to work when the boost converter is varied 'on/off' output_low(SHUTDN2)/output_low(SHUTDN2).
I am using an external boost convereter with shutdown. The problem is not with the converter - but trying to incorporate the 'shutdown code' CORRECTLY in the program.
The converter is 'OFF' when a high is applied to the 'shutdown pin' and 'ON' when a low is applied to the 'shutdown pin'. I have been using 'output_high(SHUTDN2)' and 'output_low(SHUTDN2)' in various guises, but I cannot get it to work - and it is corrupting the ADC. The 'Relevent' code is below | Code: |
#include <16F628A.h> // Device
#fuses INTRC, NOWDT, NOPROTECT, NOPUT, NOBROWNOUT, NOLVP,
#use delay(clock=4000000)
#define PIC_SCK PIN_A0
#define PIC_SDO PIN_A1
#define PIC_SDI PIN_A7
//##############################################################################
#define SHUTDN2 PIN_A2 // high powers down Boost Converter
#define NumOfBytes 4 // 4 bytes in a transmitted packet
#define BUF_MAX NumOfBytes
byte rf_buf[BUF_MAX]; // array of bytes read by the transmitter module
//##############################################################################
//#use spi(MASTER, IDLE=0, SAMPLE_RISE, CLK=PIC_SCK, DO=PIC_SDO, DI=PIC_SDI, BITS=8, MSB_FIRST, baud=9600)
#use spi(MASTER, IDLE=0, SAMPLE_RISE, CLK=PIC_SCK, DO=PIC_SDI, DI=PIC_SDO, BITS=8, MSB_FIRST)
#define LTC2480_READ_TEMP 0b11100000
//#define LTC2480_READ_TEMP 0b10000000
signed int32 read_LTC2480(int8 config)
{
int32 adc_code; // Raw adc data
int8 te0, te1, te2;
while(input(PIN_A7)) {} // Wait for end of conversion. The longest
// you will ever wait is one whole conversion period
// Now is the time to switch any multiplexers because the conversion is finished
// and you have the whole data output time for things to settle.
te2 = spi_xfer(config); // Read first byte, send config byte
te1 = spi_xfer(0); // Read 2nd byte, send speed bit
te0 = spi_xfer(0); // Read 3rd byte. ‘0’ argument is necessary
// to act as SPI master!! (compiler
// and processor specific.)
adc_code = make32(0, te2, te1, te0); // Reassemble the full code word.
return adc_code; // End of read_LTC2480()
}
//##############################################################################
void sendIt(int32 wye) {
// break-up the 32bit variable "y" into 4 bytes & load each byte
// into the transmitter array, rf_buf[]
rf_buf[0] = make8(wye,0); // load 1st byte of 'y' into rf_buf[0]
rf_buf[1] = make8(wye,1); // load 2nd byte of 'y' into rf_buf[1]
rf_buf[2] = make8(wye,2); // load 3rd byte of 'y' into rf_buf[2]
rf_buf[3] = make8(wye,3); // load 4th byte of 'y' into rf_buf[3]
// transmit the loaded array
sendPacket();
} // sendIt()
//##############################################################################
void main(){
signed int32 x =0;
signed int32 y =0;
signed int32 z =0;
setup_comparator(NC_NC_NC_NC);
setup_ccp1(CCP_OFF);
setup_timer_0(RTCC_INTERNAL);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
//############################################################################
output_low(SHUTDN2); // pin_A2, enable Boost Converter
//############################################################################
while(1) {
output_low(SHUTDN2);
x = read_LTC2480(LTC2480_READ_TEMP); // Read ADC
y = ((x >> 4) & 0xFFFF); // Shift Right to remove the first 4 control bits and mask to only output the 16bit number.
z = ((x >> 20) & 0x1); // shift the 'sign bit' and mask, so that only the sign bit will be available to read.
if (z!=0){ // If the sign bit is positive (meaning that -in is greater than +in) then carry on, otherwise skip.
y = (0 - (y^0xFFFF)); // invert the count and turn into a negative number
output_high(SHUTDN2);
//#########################################################################
sendIt(y); // instead of printing send "y" data to the transmitter
delay_ms(300); // sets the transfer rate/time
//#########################################################################
output_low(SHUTDN2);
delay_ms(10);
}
else if (z==0){
// If the sign bit is negative (meaning that -in is less than +in) then just output the actual count 'y' without any manipulation
output_high(SHUTDN2);
//#########################################################################
sendIt(y); // instead of printing send "y" data to the transmitter
delay_ms(300); // sets the transfer rate/time
//#########################################################################
output_low(SHUTDN2);
delay_ms(10);
}
}
} |
When looking with a scope - the CLK and PIC_SDO lines are active when the power is still applied to the ADC, but when I look at the PIC_SDI line - it is not working because the power is not present at the ADC.
So, the reading of the data always occurs in the 'turning off state'.
I cannot understand how to implement this code - its getting me annoyed and the idea seems simple. All i want to do is:
power on
take adc reading
power off
do something....
power on
take adc reading
BUT WHAT IS ACTUALY HAPPENING IS:
power on
take adc reading
power off
do something....
power on
Cannot maintain power on and correctly take ADC Reading
Any help would be appreciated
Carl |
|
 |
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Tue Oct 11, 2011 6:35 am |
|
|
There's a number of problems. A powered down device will kill the SPI bus, it may even physically damage the PIC and any other still powered SPI devices. I think you're already seeing this.
| Quote: |
the idea seems simple. All i want to do is:
power on
take adc reading
power off
do something....
power on
take adc reading
|
Its that word "simple" again... there's more to this than meets the eye. What you need to be implementing is something more like:
power on
Wait for power supply to settle.
Initialise ADC.
Wait for it to get to its ready state.
Trigger a reading
wait for completion
take adc reading
power off, somehow preventing ADC from overloading the SPI bus due to its clamp diodes...
do something....
etc.
Also I'm confused about your use of PIN_A7. The ADC doesn't produce a "conversion done" signal that I can see from the data sheet. Also you are not driving the SPI chip select (/CS) to the ADC. As you've put the comment from the latter on the former I suspect you may be getting confused. The ADC expects /CS from the PIC, its not a signal to the PIC.
RF Developer |
|
|
carl
Joined: 06 Feb 2008
Posts: 240
Location: Chester
|
|
| Posted: Tue Oct 11, 2011 7:15 am |
|
|
Hi RF_Developer,
Thankyou for your detailed response.
The CS line is now tied to ground - so the ADC is permanantly on. Initially I had been controlling this with a pic pin. Sorry I didnt mention that.
I'm using Pin_A7 (PIC_SDI or ADC_SDO) which incorporates the 'end of conversion' and is in the datsheet (desciptively and also in the code sample at the back as PIn_C4). Extract(s) from datasheet:
| Quote: | while(input(PIN_C4)) {} // Wait for end of conversion. The longest
// you will ever wait is one whole conversion period
The serial data output pin (SDO) is Hi-Z as long as CS is
HIGH. At any time during the conversion cycle, CS may be
pulled LOW in order to monitor the state of the converter.
Once CS is pulled LOW, SCK goes LOW and EOC is output
to the SDO pin. EOC = 1 while a conversion is in progress
and EOC = 0 if the device is in the sleep state.
When testing EOC, if the conversion is complete (EOC
= 0), the device will exit the low power mode during the
EOC test. In order to allow the device to return to the low
power sleep state, CS must be pulled HIGH before the first
rising edge of SCK. In the internal SCK timing mode, SCK
goes HIGH and the device begins outputting data at time
tEOCtest after the falling edge of CS (if EOC = 0) or tEOCtest
after EOC goes LOW (if CS is LOW during the falling edge
of EOC).
|
I understand what you are saying but cannot even do this | Quote: | wait for completion
take adc reading
|
It just wont let me read the ADC - because at the moment the read takes place - the power down is occurring. |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Tue Oct 11, 2011 8:58 am |
|
|
Ahhh, my reading of the data sheet is that unless you are using internal SCLK mode, and hence the PIC is running as an SPI slave, its raising /CS that triggers the next conversion. If you hold /CS low all the time it'll just do one conversion, send the result back and then stop.... waiting... for you to trigger it again by raising /CS.
Would it be fair to say you may not be very familiar with SPI? A "normal" SPI transaction is to activate /CS for the chip on the bus you want to talk to; send and receive data as required, then deactivate the chip (raise /CS). This chip is SPI compatible but the EOC thing is an add on: you can select it by lowering /CS, test the data bit BUT NOT by clocking it in the SPI manner, then doing the SPI transfer if its ready. If not you can raise /CS and let the ADC get on with its conversion. There is a problem in that you need to both have the SPI peripheral reading the data AND you reading the state of the relevant pin through normal I/O. You might have to use input_state() instead of input, and you may have to mess with the TRIS selects for the relevant pin. I'm not sure which will work best.
Also this extra to SPI thing may not be compatible with other SPI devices on the bus, but it seems likely you are just talking to this ADC and so you shouldn't have that sort of problem.
You haven't set the SPI speed, and you may - because you've specified all the pins - be using a software SPI instead of the actual hardware. The ADC works with SPI clock of up to 4MHz by BAUD=4000000, or lower - certainly its often easier to see what's happening during development to run much slower: the ADC will run quite happily down to 10kHz SPI clock.
So, once you've sorted the SPI issues, you need to do something like:
power on
Wait for power supply to settle.
Initialise ADC.
Wait for it to get to its ready state.
Trigger a reading by raising /CS
every now and then wait for completion by dropping /CS, checking the state of the pin. If Ready then
take adc reading
power off, somehow preventing ADC from overloading the SPI bus due to its clamp diodes...
else
raise /CS
do something....
etc.
I'd actually get this running by leaving the power on all the time. Something like this:
power on
Wait for power supply to settle.
Initialise ADC.
Wait for it to get to its ready state.
Trigger a reading by raising /CS
Main loop:
Drop /CS
Check the state of the pin.
If ADC Ready
{
take adc reading
}
raise /CS // Do this regardless of whether we took a reading or not.
do other stuff....
Note, no delays in the main loop. Only in the initialisation stuff.
RF Developer |
|
|
carl
Joined: 06 Feb 2008
Posts: 240
Location: Chester
|
|
| Posted: Tue Oct 11, 2011 9:33 am |
|
|
Hi RF_Developer,
THanks again for your feedback. I have commented on your points below, however as I said previously - the ciruit works fully and succesfully if the power is maintained at all times. So the 'set-up' or way in which the 'bulk' of the code is written is good - but not when trying to implement the power down. I also didn't say that the whole idea of the power down will be happening every half a second or so to conserve power - so:
1) power on for 500ms
2) Take ADC reading
3) do something
4) Power off for 500ms
5) do something else not ADC/SPI related
| Quote: | Ahhh, my reading of the data sheet is that unless you are using internal SCLK mode, and hence the PIC is running as an SPI slave, its raising /CS that triggers the next conversion. If you hold /CS low all the time it'll just do one conversion, send the result back and then stop.... waiting... for you to trigger it again by raising /CS.
|
If CS is permanantly low, the ADC will continuously output a reading
when CLK is started from the PIC. This is how I currently have it configured. I could use a pin and control CS independantly, but the idea was to control it via the Converter because other parts will also be powered down. ONLY ONE ADC AND ONE PIC USE ONE SPI LINE.
| Quote: | Would it be fair to say you may not be very familiar with SPI? A "normal" SPI transaction is to activate /CS for the chip on the bus you want to talk to; send and receive data as required, then deactivate the chip (raise /CS). This chip is SPI compatible but the EOC thing is an add on: you can select it by lowering /CS, test the data bit BUT NOT by clocking it in the SPI manner, then doing the SPI transfer if its ready. If not you can raise /CS and let the ADC get on with its conversion. There is a problem in that you need to both have the SPI peripheral reading the data AND you reading the state of the relevant pin through normal I/O. You might have to use input_state() instead of input, and you may have to mess with the TRIS selects for the relevant pin. I'm not sure which will work best.
|
I am new to SPI - but have been using it now for the last couple of months - and the program works successfully as it is currently configured - I can confirm that just using 'input' works well. In reagrds to the CS - this will remain permanantly low. | Quote: |
Also this extra to SPI thing may not be compatible with other SPI devices on the bus, but it seems likely you are just talking to this ADC and so you shouldn't have that sort of problem.
|
Correct, only one device on the bus. | Quote: |
You haven't set the SPI speed, and you may - because you've specified all the pins - be using a software SPI instead of the actual hardware. The ADC works with SPI clock of up to 4MHz by BAUD=4000000, or lower - certainly its often easier to see what's happening during development to run much slower: the ADC will run quite happily down to 10kHz SPI clock. |
I have omitted the speed for now - and it works fine. if not stated it will default to the fastest the line can handle or is available. the final speed is still to be decided, but this is not a factor concerning the problem. | Quote: |
So, once you've sorted the SPI issues, you need to do something like:
power on
Wait for power supply to settle.
Initialise ADC.
Wait for it to get to its ready state.
Trigger a reading by raising /CS
every now and then wait for completion by dropping /CS, checking the state of the pin. If Ready then
take adc reading
power off, somehow preventing ADC from overloading the SPI bus due to its clamp diodes...
else
raise /CS
do something....
etc.
I'd actually get this running by leaving the power on all the time. Something like this:
power on
Wait for power supply to settle.
Initialise ADC.
Wait for it to get to its ready state.
Trigger a reading by raising /CS
Main loop:
Drop /CS
Check the state of the pin.
If ADC Ready
{
take adc reading
}
raise /CS // Do this regardless of whether we took a reading or not.
do other stuff....
Note, no delays in the main loop. Only in the initialisation stuff.
RF Developer
|
THis is the important stuff I need to understand. But I cant see how messing around with the CS will play any part in the code. Basically as soon as I implement the shutdown (for whatever time) | Code: | if (z!=0){ // If the sign bit is positive (meaning that -in is greater than +in) then carry on, otherwise skip.
y = (0 - (y^0xFFFF)); // invert the count and turn into a negative number
output_high(SHUTDN2);
//#########################################################################
sendIt(y); // instead of printing send "y" data to the transmitter
delay_ms(300); // sets the transfer rate/time
//#########################################################################
output_low(SHUTDN2);
delay_ms(10);
|
The data from the ADC is not read bacause the 'time period' of when the data is read is exactly the same as the 'power down' starts. And it doesn't seem to matter what I do its always the same. |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Wed Oct 12, 2011 1:51 am |
|
|
| carl wrote: |
Basically as soon as I implement the shutdown (for whatever time)
| Code: | if (z!=0){ // If the sign bit is positive (meaning that -in is greater than +in) then carry on, otherwise skip.
y = (0 - (y^0xFFFF)); // invert the count and turn into a negative number
output_high(SHUTDN2);
//#########################################################################
sendIt(y); // instead of printing send "y" data to the transmitter
delay_ms(300); // sets the transfer rate/time
//#########################################################################
output_low(SHUTDN2);
delay_ms(10);
|
The data from the ADC is not read bacause the 'time period' of when the data is read is exactly the same as the 'power down' starts. And it doesn't seem to matter what I do its always the same. |
OK, so you are using "External Serial Clock, CS = 0 Operation" mode as illustrated in Figure 8 on page 22 of the datasheet? Is that correct?
The ADC takes a long time to convert,hundreds of milliseconds (about 165ms in 50Hz 1x speed mode apparently). It *must* be powered up all that time. It starts a conversion as soon as you've read the result of the previous one. You are using the ADC in a continuous conversion mode, therefore it must be powered up continuously. You certainly CANNOT power it down after reading a conversion. Unless, of course your are shutting it down altogether. It will handle its own power saving. So if you run it continuously you will get a result every 165ms or thereabouts. Two of which give you 330ms. Reading the result is not the same as doing the conversion, maybe that's where the confusion is.
I cannot see any advantage in powering down the ADC and a *lot* of problems. Every time its powered back up it will *have* to be reconfigured. If you are going to do something like:
while (true)
{
power up
wait for PSU to settle.
Configure ADC
Wait for it to start-up
take a few readings
power down ADC
wait 30 seconds while doing other stuff
}
then yes, powering down the ADC might make sense.
If you do still want to do this powering down thing, then I repeat: you must take account of the time the PSU takes to run up and settle, and you must reconfigure each time, and that takes time, a lot of time probably, as in 500ms or more at a guess, as this ADC is likely to do various calibration activities at start-up.
What you can't expect to do it read data and then power down the ADC immediately. Nor can you power up the ADC and expect it to be ready with data on the next line of code.
I wouldn't sit in code waiting for this ADC to complete its conversion. Yes, its fine for a test, and fine for datasheet application code, but its not good for most real applications where you would probably like to do other tasks while your waiting, succ as communications, other readings, control tasks and so on. That's why I suggested the "take a look at the EOC and go round the loop again if its not ready" method. That allows you to do other useful things. After all you've got 165ms to wait, which really is eternity to a PIC.
Anyway, I've tried to help as much as I can. I can't add much. There's a basic lesson here: if something is not working the way you've done it, try another way. In this case if its not working with your power down scheme, then don't power down, at leat not in the same way. Try something different. Be flexible and be creative. Try and understand what the hardware is really doing and work with it, not against it, and powering down an ADC while its trying to convert is certainly working against it.
RF Developer |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9225
Location: Greensville,Ontario
|
|
| Posted: Wed Oct 12, 2011 5:27 am |
|
|
I know some 'features' are nice and 'conserving energy' seems to be a mantra but...
You might want to grab a pencil and paper and see what energy savings you're really going to get over say a 1 week period as opposed to just using a couple of AA LI-Ion batteries.Microchip did a great study for 'low power RTC in a chip' a decade+ ago and it was clear that while savings could be had in chip selection, clever coding,etc. it was actually more cost effective to just use a bigger( greater aHr) battery.All too often you can get lured by 'smaller is better' but it ends up costing you more in R&D time($$$),testing($$$$),etc. and the end product is delayed,allowing the competition to gain your marketshare.
Having gone down that road decades ago, I learned that 'smaller' is not better and that some 'features' are only good on paper. |
|
|
carl
Joined: 06 Feb 2008
Posts: 240
Location: Chester
|
|
| Posted: Wed Oct 12, 2011 6:44 am |
|
|
Thankyou both for your help.
The idea is that being able to shut down 'several' different sections of a design with only ONE control line is advantagous when compared to individulaly having to use seperate lines for each 'shutdown' feature for each seperate I.C.
So if the only parts concerned were a PIC and ADC, then doing it in this way would be silly. BUT if you had a PIC, ADC, A.I., Transmitter, something else, something else...... then in my opinion it would save lots of power, reduce pin count, reduce tracking etc.
I understand what you mean RF_Developer about the 'power up time' and this is what I tried fiddling about with first - but no matter how long I power it up for it doesn't work. For instnce if I change the code below for 5000ms it should have powered up, initialised and 'ready to take the reading' - but it doesn't. it starts to read the data 'at the end of the 5000ms'. I am obviously doing something wrong, but cant work in out. | Code: | output_high(SHUTDN2);
//#########################################################################
sendIt(y); // instead of printing send "y" data to the transmitter
delay_ms(300); // sets the transfer rate/time
//#########################################################################
output_low(SHUTDN2);
delay_ms(5000); |
I know that my alternative is to individually use seperate control lines ofr each part (including the CS for the ADC), but it is not the 'ideal solution' ESPECIALLY BECAUSE I THINK IT IS MORE TO DO WITH HOW I AM APPLYING THE SHUTDOWN CODE.
And I agree under normal circumstances Temtronic, it would be better tio increase the available power rather than squeeze every bit of code and power saving measuers. However not all apllications are flexible to change - especially Intrinsically safe applications which is what this is. The battery is already huge 'ER34615 http://www.tenergybattery.com/index.php?page=shop.browse&category_id=14&option=com_virtuemart&Itemid=27&vmcchk=1
I need to use this battery, and also have things like a load cell connected to this application (5mA IF CONTINUALLY POWERED!!!!). So powering down for 500ms every second would half the power consumption of this alone.
In conclusion, thanks again for all your help - but if you can see any floors in how my 'shutdown code' is being applied that would be great.
Carl |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Wed Oct 12, 2011 9:04 am |
|
|
can't you then simply leave the ADC powered -
and just shut off the load cell bias power?
have you done an analysis of what your power demand is for each component?
also
if any PIC lines to the LTC chip are high by default-
powering down the ADC may very well be causing unintended conduction from the pic I/O system that is potentially excessive or maybe even damaging.
have you carefully measured inline current consumption for the whole circuit when running and when shut down to verify:
1- actual power saving
2- a spike in current when you shutdown the ADC?
considered other ADC chips?
16 bit parts like the ads8320 mange their OWN shutdown between readings and are great at conserving power AND taking very fast readings when powered up. i think you can find 24 bit parts from TI that follow the same low power conserving approach too.
Last edited by asmboy on Thu Oct 13, 2011 6:56 am; edited 1 time in total |
|
|
carl
Joined: 06 Feb 2008
Posts: 240
Location: Chester
|
|
| Posted: Thu Oct 13, 2011 2:49 am |
|
|
HI ASM,
can you elaborate more on this | Quote: | and just shut off the load cell bias power?
|
I have looked at using a buffer with enable, but these simple I.C's drop considerable voltage when load is applied. I am also looking into load switches (with very low resistance) - I may be able to get one that only drops a few mV at 5mA load.
Or do you have an alternative option to cotrol the load cell (turn it on and off via the pic) without it dropping voltage when'ON'.
THanks
Carl |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Thu Oct 13, 2011 6:54 am |
|
|
use a P mosfet - high side switch
if the load cell voltage is greater than Pic Vcc
only 3 parts are needed or
if the same or close to pic V cc -then just 1 part ;-))
is your load cell using 10 v ??
let me know the bias volts you are using - and i will show simple schematic to add very low drop ( .1v or less when ON ) hi side switch |
|
|
SherpaDoug
Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA
|
|
| Posted: Thu Oct 13, 2011 7:15 am |
|
|
I am joining this thread late, but be sure to get your A/D reference voltage from the switched side of the load cell power, or use another A/D channel to monitor this voltage so you can compensate for voltage loss in the switch.
Also see if your load cell prefers to run from a current source instead of a voltage source. Many load cells are better temperature compensated while operating from a current source.
_________________
The search for better is endless. Instead simply find very good and get the job done. |
|
|
carl
Joined: 06 Feb 2008
Posts: 240
Location: Chester
|
|
| Posted: Thu Oct 13, 2011 7:30 am |
|
|
Hi ASM,
Thanks for the reply.
As I thought you would use a power switch rahter than a buffer - excellent.
I have two designs:
1) Everything is powered from the same voltage 3.6V.
2) Only the pic is powered from 3.6V and everything else is 5V.
And believe me the 3.6V version will be 3.6V and Its good - no need to explain all the downsides of reduced headroom/resolution - I am happy with the design.
The load cell has 1000Ohm bridge. Therefore current consumption @3.6V = 3.6mA. And at 5V you get 5mA.
because the aim of both designs is to be ratiometric, I need the output from the switch to be nearly the same as the input. I understand that this depends on the internal switch resistance - the lower the better.
I have looked at STMPS2141 part (90mOhm). So am I correct in saying that Ron = V/I. Therefore if I want the V(volt drop) = 1mV, then
Ron = 0.001/0.005 = 200mOhm MAX.
And STMPS2141 has a 90mOhm resistance - so volt drop will actually be a lot lower:
0.09 x 0.005 = 0.00045V Volt drop - excellent!!!!!!!!!!
But am I correct?????
Carl |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Thu Oct 13, 2011 7:56 am |
|
|
that part ought to work
BUT ANY good low Ron P fet will work as well or better
with source connected to bias supply
drain to load cell and
GATE to PIC -
when pic control is LOW FET conducts
when gate is raised to Vcc - FET is off
i think you will find there are small P fet Low volt parts that can do less than
90 mohms
the Si5419DU
is only 33 mohms in your zone of voltage switching |
|
|
carl
Joined: 06 Feb 2008
Posts: 240
Location: Chester
|
|
| Posted: Thu Oct 13, 2011 8:30 am |
|
|
Thanks ASM,
I have got the idea now. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
