Maker Pro
Maker Pro

need help with simple 3v to 34v transistor relay/switch

KrisBlueNZ

Sadly passed away in 2015
Nov 28, 2011
8,393
Joined
Nov 28, 2011
Messages
8,393
The ZXMP6A13F isn't really suitable; the Rds(on) is far too high. In fact it isn't even specified at Vgs=3V or lower. The closest specification is at Vgs=4.5V where it is 0.6 ohms; at 3V it would be more than an ohm, and you would lose significant voltage across it. When you're working at 3V you need every millivolt you can get!

On the other hand, the typical curves are better, so you could try it, and measure the voltage drop across it when the bell is turned ON. You might be lucky and hit on a component that's a lot better than the worst-case specifications.
 

sideburn

Jun 14, 2013
75
Joined
Jun 14, 2013
Messages
75
Ok I'll probably order the one you suggested since I have to wait for my replacement pickit3 anyway. I am still not sure if I did burn it up or not.. It was getting warm and was not able to program any pics anymore. I think I may have accidently connected 3v to RA6/COCKOUT instead of VDD while programming the chip.. i didn't catch it until later but it was programming it fine for a good long while and then it just quit on me.
 

KrisBlueNZ

Sadly passed away in 2015
Nov 28, 2011
8,393
Joined
Nov 28, 2011
Messages
8,393
I think I may have accidently connected 3v to RA6/COCKOUT instead of VDD while programming the chip.
If that's the right name for that pin, your PIC seems to have an new feature that I didn't know about...

I'm surprised the forum software didn't catch that and asterisk it!
 

sideburn

Jun 14, 2013
75
Joined
Jun 14, 2013
Messages
75
Back in business.. I got me replacement picKit3 today and was able to reprogram another PIC.. It turns out the original PIC I was using fried and then in turn fried the PICKit. I found this out by putting the PIC on my developer board and noticed the transistor connected to the power source immediately started getting hot.

Anyway, All is good again. My project is going to need some active high and active low inputs to the pic.

Is the best way to do this for active low to pull up the input from +3V through a 10K resistor to the input pin and then to trigger it, short the pin directly to GND?

And then for an active high pull down the input to GND through a 10K resistor and then to trigger it connect 3V directly to the input pin?
 

KrisBlueNZ

Sadly passed away in 2015
Nov 28, 2011
8,393
Joined
Nov 28, 2011
Messages
8,393
Yes, that's right. But the PICs (some of them, at least) have weak pullup and weak pulldown resistors built-in; you just need to enable them in firmware.
 

sideburn

Jun 14, 2013
75
Joined
Jun 14, 2013
Messages
75
Yes, that's right. But the PICs (some of them, at least) have weak pullup and weak pulldown resistors built-in; you just need to enable them in firmware.

RIght, I've read about that but didn't quite understand what it mean exactly. I guessthat means I can set a flag in my code and then I won't need any resistors. I am using a 16f628A and reading up on the specs here http://ww1.microchip.com/downloads/en/DeviceDoc/40044G.pdf

Trying to figure out what everything stands for what the R stands for in the i/o pins.. RA0, RA1, RB0 etc.. it also says some input pins can be analog. I assume can means I can input a variable voltage and somehow switch on the various values in my c code.

I'm just scratching the surface on pic programming.. so far I've got the bell ringer code working well and I can control it with various commands from a terminal on my computer using the chips UART. I think I may eventually use an analog input if I can and that way I can sent multiple commands using a single input pin.


I looked at the header file for the 16f226 and found this:


volatile bit nRBPU @ ((unsigned)&OPTION_REG*8)+7;

I read somewhere that bit 7 was weak pull-ups
I think this enables them on PortB but I am surprised I can not find any info on it.
I tried a google search on nRBPU and didn't find much.
I think I sorted it out.. PORTB has weak pull-ups only and you can set it with the above bitfield definition.
I'll give it a try tomorrow.
 
Last edited:

BobK

Jan 5, 2010
7,682
Joined
Jan 5, 2010
Messages
7,682
From section 5.2 of the datasheet:

Each of the PORTB pins has a weak internal pull-up
(≈200 μA typical). A single control bit can turn on all the
pull-ups. This is done by clearing the RBPU
(OPTION<7>) bit. The weak pull-up is automatically
turned off when the port pin is configured as an output.
The pull-ups are disabled on Power-on Reset.

So you simply clear the RBPU bit of the option register. In asm:

BCF OPTION, RBPU

Or in C

RBPU = 0;

Bob
 

sideburn

Jun 14, 2013
75
Joined
Jun 14, 2013
Messages
75
Oh setting it to 0 enables weak pull ups ? I had it backwards?
What about pull down?
 
Last edited:

sideburn

Jun 14, 2013
75
Joined
Jun 14, 2013
Messages
75
I have been. I didn't catch anything on a pull down ability.
Maybe I'm missing something. Very well could be.
 
Last edited:

sideburn

Jun 14, 2013
75
Joined
Jun 14, 2013
Messages
75
You want to switch the supply to the boost converter on and off? But it doesn't have a disable input. You would have to switch one of the power rails, using a MOSFET. Generally you switch the positive rail. The problem is your 3V supply rail; you need a special MOSFET that will saturate with only 3V gate-source bias, such as the AO3415 (http://www.digikey.com/product-detail/en/AO3415/785-1010-1-ND/1855952) which costs USD 0.48 and has an Rds(on) of about 50 milliohms at 3V Vgs..

I've drawn up a quick schematic on how I will be triggering the 34v booster with the MOSFET. Does this look correct?
 

Attachments

  • Screen Shot 2013-06-23 at 1.56.05 PM.png
    Screen Shot 2013-06-23 at 1.56.05 PM.png
    47.5 KB · Views: 146

KrisBlueNZ

Sadly passed away in 2015
Nov 28, 2011
8,393
Joined
Nov 28, 2011
Messages
8,393
Not quite. The MOSFET should be in the +3.7V feed to the boost converter. Connect the boost converter's negative rail to your circuit's main negative rail. Connect the MOSFET with its source to +3.7V and its drain to the positive supply input connection of the boost converter.

You could also add a resistor, e.g. 33k, from the MOSFET's gate to its source, to make sure that it turns OFF when the PIC is not driving that pin - during reset, for example.

When your firmware drives the pin low, the MOSFET will see -3.7V on its gate relative to its source, and will turn ON and pass the 3.7V supply rail through to the boost converter.
 

sideburn

Jun 14, 2013
75
Joined
Jun 14, 2013
Messages
75
Hmm I had it that way But I though a P channel MOSFET needed a positive current on the gate to trigger it. I thought it was like an NPN transistor.

I guess I had it backwards and thats what an N Channel MOSFET is.. Do both types take a positive trigger for the gate?

I'll make the change. Thanks.
Do you know much about PICs? I was wondering if I constantly check the USART for stream of characters (RCIF and RCREG) would chew up more battery vs using an input pin.

I can solve my issue either way but using the serial port would be easier because I wont have to do any hard wiring a signal wire form the pic to the other device.
 

KrisBlueNZ

Sadly passed away in 2015
Nov 28, 2011
8,393
Joined
Nov 28, 2011
Messages
8,393
Right, you had it backwards. An N-channel MOSFET is comparable to an NPN bipolar transistor, and a P-channel MOSFET is comparable to a PNP.

But MOSFETs are voltage-controlled, not current-controlled.

Polarities and directions of arrows are all reversed for a P-channel MOSFET or PNP transistor when compared with an N-channel MOSFET or NPN transistor. Electrode names and functions do not change.

An N-channel MOSFET is turned on by positive voltage on the gate relative to the source.
An NPN transistor is turned on by positive voltage and current flow into the base and out the emitter.

A P-channel MOSFET is turned on by a negative voltage on the gate relative to the source.
A PNP transistor is turned on by negative voltage and current flow out of the base and in the emitter.

I don't really understand your question. If you need to receive serial data, you should use the USART. It is possible to receive serial data on a general I/O pin using a technique called a software UART, but if you already have enough real USARTs for all the signal(s) you want to receive, you should use it/them.

A USART will produce an indication (RCIF in your case) when a character is received; this signal should also be able to generate an interrupt; this is probably an option that's enabled by a control register. For applications where you need the data reception process to run in the background, and when data is being received rapidly, an interrupt-driven architecture is used.

With an interrupt-driven receive architecture, when a byte is completely received by the USART, the USART indicates this on the RCIF flag, and triggers an interrupt. This interrupts the MCU core and causes it to suspend execution of the code that it was previously running, and execute a section of code called an interrupt handler.

The interrupt handler reads the received byte, clears the RCIF flag (if this isn't automatically done by the USART when the received byte is read), and does something with the received byte. It may simply store the byte in a buffer somewhere in RAM, ready to be processed by other code. Or the interrupt handler may decode or interpret the received byte and take some kind of action, such as transmitting a byte in response, setting a flag, incrementing a counter, etc. Then the interrupt handler returns, and execution of the main code continues.

Some interrupt handlers require interaction with the main code. The type that puts data into a buffer needs the main code to poll the buffer and remove data that has been put there by the interrupt handler. Otherwise, the buffer will become full and the interrupt handler will have to throw away bytes.

Some interrupt handlers implement a whole communication protocol. These make use of state machines or coroutines so that the interrupt handler knows "where it's up to". These systems can operate almost completely independently of the main (non-interrupt) code. Communication with the other code can be through flags (semaphores), counters, queues and other programming structures. These interrupt handlers usually have multiple interrupt sources that they can use; for example, when the interrupt code is transmitting a stream of bytes, it will make use of the USART's transmit ready interrupt to trigger each byte transmission.

If the USART is only receiving characters slowly, and your main code doesn't need to do anything complicated, a polling loop is the normal solution. Your code is written as a loop. Within the loop, inputs are checked, decisions are made, and outputs are updated, as appropriate. The USART received data signal is one of the inputs that needs to be checked. There are a few variations on the theme of a loop-based architecture, and which is best depends on what functions the code needs to perform.

If you give more information about the received serial data, I can be more specific.
 

sideburn

Jun 14, 2013
75
Joined
Jun 14, 2013
Messages
75
But MOSFETs are voltage-controlled, not current-controlled.

Right, oops.. i knew that.. ha..

A P-channel MOSFET is turned on by a negative voltage on the gate relative to the source.

Ok, I was originally planning on making that output active high, but I can work around this. I'll set that output to 1 at startup and then set it to 0 when I need to turn on the boost converter.

I don't really understand your question. If you need to receive serial data, you should use the USART. It is possible to receive serial data on a general I/O pin using a technique called a software UART, but if you already have enough real USARTs for all the signal(s) you want to receive, you should use it/them.

A USART will produce an indication (RCIF in your case) when a character is received; this signal should also be able to generate an interrupt; this is probably an option that's enabled by a control register. For applications where you need the data reception process to run in the background, and when data is being received rapidly, an interrupt-driven architecture is used.

With an interrupt-driven receive architecture, when a byte is completely received by the USART, the USART indicates this on the RCIF flag, and triggers an interrupt. This interrupts the MCU core and causes it to suspend execution of the code that it was previously running, and execute a section of code called an interrupt handler.

The interrupt handler reads the received byte, clears the RCIF flag (if this isn't automatically done by the USART when the received byte is read), and does something with the received byte. It may simply store the byte in a buffer somewhere in RAM, ready to be processed by other code. Or the interrupt handler may decode or interpret the received byte and take some kind of action, such as transmitting a byte in response, setting a flag, incrementing a counter, etc. Then the interrupt handler returns, and execution of the main code continues.

Some interrupt handlers require interaction with the main code. The type that puts data into a buffer needs the main code to poll the buffer and remove data that has been put there by the interrupt handler. Otherwise, the buffer will become full and the interrupt handler will have to throw away bytes.

Some interrupt handlers implement a whole communication protocol. These make use of state machines or coroutines so that the interrupt handler knows "where it's up to". These systems can operate almost completely independently of the main (non-interrupt) code. Communication with the other code can be through flags (semaphores), counters, queues and other programming structures. These interrupt handlers usually have multiple interrupt sources that they can use; for example, when the interrupt code is transmitting a stream of bytes, it will make use of the USART's transmit ready interrupt to trigger each byte transmission.

If the USART is only receiving characters slowly, and your main code doesn't need to do anything complicated, a polling loop is the normal solution. Your code is written as a loop. Within the loop, inputs are checked, decisions are made, and outputs are updated, as appropriate. The USART received data signal is one of the inputs that needs to be checked. There are a few variations on the theme of a loop-based architecture, and which is best depends on what functions the code needs to perform.

If you give more information about the received serial data, I can be more specific.


Yeah, I have yet to try out interrupts.. But here is what I've got going on.
I've pretty much written all of the code already. Basically what I've got going on here is I have a GSM/GPRS break out board. And I am using the PIC16F628's built in USART to send commands to it..

Now I want to detect if there is an incoming call and ring that bell.
The breakout board has nothing connected to the RI (ring) pin on the GSM module though, so I will have to solder a wire to that pin and run it over to an input pin on my PIC.

But, when you do have an incoming call, I noticed that the GSM module is sending out through its serial i/o the word "RING".

So I was thinking instead of running a wire, I could just monitor the incoming i/o through the USART on the PIC chip and watch out for the word "RING" and I'll know theres a call coming in and then fire up the bell ringer.

When the ring times out or the caller hangs up, the serial prints out "NO CARRIER".. I can check for that and turn off the bell.


The code would be something like this:

// wait to receive character
while(!RCIF);

while(RCREG != '\0')
buff[i++]=RCREG;

if(strcmp(buff) == "RING")
RingBell();


So my main question is, would sitting in a while loop monitoring RCIF kill my battery faster than checking the value of an input pin like:

#define RING_IN PORTAbits.RA4

while(!RING_IN); //wait for the ring signal off the GSM RI pin that's connected to RA4 on the PIC.
 
Last edited:

sideburn

Jun 14, 2013
75
Joined
Jun 14, 2013
Messages
75
Not quite. The MOSFET should be in the +3.7V feed to the boost converter. Connect the boost converter's negative rail to your circuit's main negative rail. Connect the MOSFET with its source to +3.7V and its drain to the positive supply input connection of the boost converter.

You could also add a resistor, e.g. 33k, from the MOSFET's gate to its source, to make sure that it turns OFF when the PIC is not driving that pin - during reset, for example.

When your firmware drives the pin low, the MOSFET will see -3.7V on its gate relative to its source, and will turn ON and pass the 3.7V supply rail through to the boost converter.

I've updated the schematic. I'm a little confused how driving the pin low will make the MOSFET see -3.7v. I was figuring, with that 33k resistor connected to the +3.7v on the source side would cause the pin going low (to 0 volts) make the gate still see a little positive voltage, not a negative one at all.. I can't visualize how thats inverting the voltage.

Not saying I'm right of course.. I know I'm wrong, just not picturing how it does that in my head.

Updated schematic attached. Is that better?
 

Attachments

  • Screen Shot 2013-06-23 at 11.27.22 PM.png
    Screen Shot 2013-06-23 at 11.27.22 PM.png
    31.4 KB · Views: 149

KrisBlueNZ

Sadly passed away in 2015
Nov 28, 2011
8,393
Joined
Nov 28, 2011
Messages
8,393
Ok, I was originally planning on making that output active high, but I can work around this. I'll set that output to 1 at startup and then set it to 0 when I need to turn on the boost converter.
Right.

But, when you do have an incoming call, I noticed that the GSM module is sending out through its serial i/o the word "RING".

So I was thinking instead of running a wire, I could just monitor the incoming i/o through the USART on the PIC chip and watch out for the word "RING" and I'll know theres a call coming in and then fire up the bell ringer.
Seems like it would be simpler to just watch the ring indicator from the modem... assuming it's used. The modem may or may not drive that pin; you'll have to read the documentation or try it out to find out for sure.
So my main question is, would sitting in a while loop monitoring RCIF kill my battery faster than checking the value of an input pin ...
There's no difference. A loop that polls the state of an I/O pin and a loop that polls the state of the USART's received data flag are no different in terms of power consumption.

The only way to save power is to switch to a sleep mode. Then you need a signal to wake the PIC up from sleep mode. This interrupt can come from a rising or falling edge on an interrupt-capable I/O pin, or from the USART received character interrupt. But I wouldn't worry about using sleep mode initially. Get it working and see how long the battery lasts first.

I've updated the schematic.
Yes, that's right now.
I'm a little confused how driving the pin low will make the MOSFET see -3.7v. I was figuring, with that 33k resistor connected to the +3.7v on the source side would cause the pin going low (to 0 volts) make the gate still see a little positive voltage, not a negative one at all.. I can't visualize how thats inverting the voltage.
Remember that the MOSFET responds to the voltage on the gate relative to the source. You have the source connected to your +3.7V rail. So when the PIC's output pin is high, the gate-source voltage is 0V, and when the PIC's output is low, the gate-source voltage is -3.7V and the MOSFET conducts.
 

sideburn

Jun 14, 2013
75
Joined
Jun 14, 2013
Messages
75
Right.


Seems like it would be simpler to just watch the ring indicator from the modem... assuming it's used. The modem may or may not drive that pin; you'll have to read the documentation or try it out to find out for sure.

Yeah.. The problem is the ring indicator pin (RI) is not being used on the breakout board and there are no pins to connect to it. I would have to solder a wire directly to the GSM module. Not a big deal.. but its an SMD module andthe pins are tiny. So Actually I am thinking it might be easier, and definately more durable to not run a wire and just monitor the serial data.

Its this one--> http://imall.iteadstudio.com/wireless/gsm-gprs-and-wifi/im120525010.html
Yu can see that the header ont he board only has RST P RX TX DT DR and + - pins on it.. I'm not sure what the "P" pin is for but it's not RI.

There's no difference. A loop that polls the state of an I/O pin and a loop that polls the state of the USART's received data flag are no different in terms of power consumption.

The only way to save power is to switch to a sleep mode. Then you need a signal to wake the PIC up from sleep mode. This interrupt can come from a rising or falling edge on an interrupt-capable I/O pin, or from the USART received character interrupt. But I wouldn't worry about using sleep mode initially. Get it working and see how long the battery lasts first.

Yeah, I saw that the pic had a sleep mode. I didn't want to bother with that yet, like you said.. That would be the final touches. I didnt think it would would make a difference wether i polled on an i/o pin vs the USART but thats good to know for sure. Thanks.

Yes, that's right now.

Remember that the MOSFET responds to the voltage on the gate relative to the source. You have the source connected to your +3.7V rail. So when the PIC's output pin is high, the gate-source voltage is 0V, and when the PIC's output is low, the gate-source voltage is -3.7V and the MOSFET conducts.


Yeah thats confusing me.. I need to figure out how to visualize it.. breaking it down to how it is in terms of diodes or the actual P and N type materials and whats going on there..
Ive been looking at the diagrams on the datasheet trying to sort it out. Its pretty much the same as a transistor isnt it? just different tolerances?

I kind of get it.. The current can't flow from the drain side (basically the negative side) through to the source (positive side) until there is a 0 or negative voltage on the N type material between the two P type materials.. So I can picture the gate having 0 voltage i guess.. But are you saying that if I were to put my volt meter on the PIC's output pin when I set it high, I will read zero volts?
And the gate going to -3.7v is just throwing me off.. Haha.. Thanks for putting up with me by the way. I kind of feel like a moron right now
 
Last edited:
Top