ZoneMikel's Blog

Well I’ve studied a little more about this problem, one thing I should be using a “logic level” mosfet.

I have a few options, I can use a p mosfet or i can misuse a lm317 and regulate the current as described in the last post about battery charging.

Using a p mosfet if i have the charger+ coming into the “source” and the pic hooked up to the gate and the battery hooked up to the drain, then when the pic is high Vgs will be at -7v (Assuming we are providing 12v on chg+).

This really confused me before I thought I would have to somehow make a negative voltage and feed it into the gate of the p mosfet, but its not that bad. But all that matters is the Vgs or the voltage from Gate to Source. For example in a N channel mosfet the source is normally connected to ground so when gate is at 5v then 5v-gnd=5v so you turn it “on” with 5v. However, with a p channel mosfet the “source” is connected to a high line, lets say 5v then if you provide “low” or zero volts on the gate the (gate v) – (source v) is 0v-5v=-5v and in most this allows the current to flow. If your trying to turn on a p channel mosfet and allow a higher current to flow into something with a lower driving (gate) voltage then you can use a small driver as explained here, and here is a pic.

In my proposed battery charger I was using a NTR1P02T1 p channel mosfet. I was driving the gate with a normal pic line so it would be 5v or 0v. For this transistor to be “on” Vgs should be more or less -1v to -2.3v. If my voltage coming into the source was 12v and my voltage driving the gate was 5v Vgs would be -7, I dont think I can turn off the mosfet, I would need a driver circuit as above. Unless I had a pull up that went to the chargers positive pole, but this would sink 12v into the pic when the pic went to ground, oh nevermind that would not work it would still be either -12v or -7v depending on the pic being low or high on the gate. We definatley need a driver.

I think the way i was calculating the voltage by adding a resistor into the output line from the lm317 was changing the output of the lm317.

I need to experement more with one of these mosfets and see if i cant figure it out, which is bad because i only have a few left. Might have to scavenge off of some of the other boards.

Here are some pictures of jinx, you cant see much from the pictures since the components are smd. Anywho you get the jist.

This first picture shows the entire unit so far. I have had it running like this a few times, it runs through the grass in my yard pretty well but sometimes the grass gets caught in the track. Sometimes it freaks out and turns one motor on full speed, this normally causes one of the tracks to come off, and sometimes it just stops working and I have to reset it.I’m not worrying about these little “quirks” right now because the code/hw may still change. The main thing is making sure everything works more or less as expected. The best thing for these track vehicles is that the tracks turn opposite each other when the vehicle is turning. I was thinking maybe we could avoid a h bridge and have a hardwired circuit such that when only one side is on the other side automatically turns in the opposite direction, I think a h-bridge would be nessisary anyway though.

This picture shows the modules separatley. The one on the left is the “power/charge” module. The ones with the antenni are the wireless modules( i didnt make them!). The one in the middle is the mcu board, and the one on the right is a max232 circuit that converts the rs232 into uart and then sends it through the adapter to the wireless module.

Here are some more pictures . . .

Progress is coming along at a moderate speed. The power circuit has been redone at least 5 times and needs to be redone at least once more. The Hbridge circuit is simply a switch to ground for each motor so its not at all a full h bridge. The mcu circuit has had several modifictions, some things were unforseen and other things were just connected wrong.

In the power module (that i deleted by accident, get from us puter!) the “charge” connection is connected to the positive battery terminal via a P channel mosfet. When I fully charged the battery pack (2 at a time) using my sony battery charger the overall voltage of the pack was 8.08v, so thats 8.08v/ 6 = ~1.35v per cell. I gauge that the charger is putting out about 1.435v per cell to charge them.

So the plan is this, turn on charger for about a sec, turn off charger, check battery voltage. If the battery voltage is less than it was in the previous check stop, or if its like 8v or something. This is using the negative delta V property of nimh batteries.   I’m worried that since we are doing them all in series they may kinda compensate for the negative delta V but, the only way to know for sure is to just do it and record the output.

I’m watching it now and the code looks something like this

void chargeBattery(){
   set_adc_channel(13);       // vdivider hooked to battery (39/(47+39))*vin
   // reset vars, if not it will hold the last value
   battVolts = 0;
   chgVolts = 0;
 
   // turn off charge input and read battery
   output_high(CHGPIN);
   delay_ms( 1000 );
   battVolts = read_adc();
   printf("battVolts = %2x\n\r", battVolts);
 
   // turn on charge input and read charge voltage
   output_low(CHGPIN);
   delay_ms( 1000 );
   chgVolts = read_adc();
   printf("chgVolts = %2x\n\r", chgVolts);
}

I’m doing it this way to read the output and see what happens. On the input line that the pic is reading i have a voltage divider of (39k/(39k+47k))=.453, and we are using 8 bit ADC so the max value (vref = 5v) is 255 and zero is zero So to see the real voltage the calculation would look something like this

[(value/255)*5] / .453  and yes a quick check with the Multimeter and some calculations show this calculation and the pics ADC to be spot on to two decimal points.  I’m changing the code to reflect the actual voltage so its easier to read, later we will just read the value and pass it as a byte in the packet.

Summary
8.08v is (8.08*.453/5*255)= 186 or 0xBA in hex

After some testing it seems as if they charged, the pack was at 8.09v and a random cell was at 1.35v. I made some code to detect the negative v condition if no negative V just turn off in a hour, we will see how that works out. If it is charging there is no way its charging faster than 1A per hour because of the limitations of the lm317 and because the batteries arent getting hot at all !

This is my code for now I’ll see how it works. I need to test the amps coming through and see if the batteries actually hold the charge for a while. I know the seconds wont be “exact” but close enough.

// for battery charging and maintenece
#define CHGPIN PIN_A4
 
// global variables for this .h
int8 battVolts = 0;
int8 chgVolts = 0;
int16 ChgSec = 0;
 
void chargeBattery(){
   set_adc_channel(13);       // vdivider hooked to battery (39/(47+39))*vin
   // reset vars, if not it will hold the last value
   battVolts = 0;
   chgVolts = 0;
 
   // turn off charge input and read battery
   output_high(CHGPIN);
   delay_ms( 900 );
   // if negative delta v or one hour stop charging and go to idle state
   if(battVolts < read_adc() || ChgSec > 3600){
      printf("Battery Charged!, NDV detected in %u Seconds", ChgSec);
      state = '0';                        // return to idle state
   }else{                                 // continue charging
   battVolts = read_adc();                // latest battery voltage
   // turn on charge input and read charge voltage
   output_low(CHGPIN);
   delay_ms(50);
   chgVolts = read_adc();
   printf("\f -Charging Chg: %u Batt: %u time:%u ",chgVolts,battVolts,ChgSec);
   }
}

Hooking up a 10k resistor through the high output line from the charger to the power module i get 10.88v on the charger side and 10.77 on the jinx side, that means .11v voltage drop. So v=i*r , .11=i*10k then i must be .011uA ?

Update . .
Looks like the logic is sound and the program is working great, but i’m sure the circuit is wrong. I have the drain side of the mosfet on the positive terminal of the battery to be charged and the source side on the charger. I dont know if the mosfet is hooked up backwards (to do what i want it to do) or some other underlying problem but i calculate the current flowing into the battery when charging to be like 20mA and the power consumption of the mcu and transmitter is more like 50mA, either way something is wrong. I need to go back and evaluate the mosfet and how it is working then repair the power circuit.

Also I got a old version of the power circuit 2 i should check to see that everything is right on it.

… just reading on other sites ..

If you charge several cells in series, you need 1.5 V times the number of cells plus 3 V. For four cells, this means a supply  voltage of 9 V.
- so thats 6*1.5+3 = 12v, no need for the lm317 because i have 12v, we can use the lm317 to limit the current though

The well-known LM317 three-lead regulator is  designed to adjust its internal resistance between the IN and OUT leads to maintain a constant voltage of 1.25 V between  the OUT and ADJ leads. If we chose a value of (1.25 ÷ 0.180) = 6.94 Ω for R1, then exactly 180 mA will flow.
- for us if we have 1.25/.5 = 2.5Ω, that will allow about 500mA to flow through the battery to ground using the following schematic.

After battling with these modules for a few days (after burning up my first pair) I have finally gotten them to work. There is very little info out there on how they actually work so I’ll try and sum it all up here, I hope it helps someone.

GP-GC010
Cy2196R_chn
Cy2196R Datasheet (translated to english, thanks google)

What Model do I have ?

The boards i bought on ebay were supposed to be “GP-GC010″ and they give a link to the pdf for that model. However, after much headache I realized on the board itself is printed Cy2196R. The Cy2196R model is a little bit different than what they have for that “GP-GC010″ module. The funny thing is the “GP-GC010″ is not mentioned anywhere in the forums on the sure electronics website except to buy it but, the Cy2196R is mentioned several times. I dont know if they just thought the Cy2196R got a bad rap and renamed it so no one would know its the GP-GC010 or what but its really confusing. The datasheet for the GP-GC010 is crap and the datasheet for the Cy2196R is non existent in English. If you want the datasheet for the Cy2196R do a search for it in google then have google translate the Chinese pdf to English.

This was my main problem, I was reading the datasheet they provided instead of the real datasheet for my device. Its funny if you look at the datasheet for the GP-GC010 it even has a diagram interfacing with a cy2196TR. Why they changed the name IDK but I would not even bother with the GP-GC010 datasheet, just go straight to the Cy2196R datasheet. Unless your board does not say Cy2196R (or TR) on it.

Ok so how do i connect it ?

The main difference in the two datasheets is that with the GP-GC010 there is a “reserved pin” and a busy pin, and in the Cy2196R datasheet those same pins are CTS and RTS. Which in case you dont know are “Clear to send” and “Ready to send”. So basically the RTS is a output and CTS is input. The unit gets data till its 64byte buffer is full then it trips the RTS line, from this point it will wait for the CTS line to become active and then it will send the data. So if you dont hook these up right it never sends the data. The easiest way is just put the CTS pin to ground, this means its always clear for the transmitter to send. These lines are very useful for handshaking and trying to avoid collisions. For example if your currently receiveing data you could hold the CTS line because you dont want to transmit to a transmitter who may be transmitting data to you, thats if you plan on doing syncronous mode. I need to get my telecom book out and start thinking about all that.

Anyway here is the real pinout for the Cy2196R

pin1 – Vcc
*I would use about 4v here, their webpage says 2.2-5.4, GP-GC010 datsheet says 2.4-4.2v, Cy2196R datasheet says 3.4-5.4v
The data is very inconsistent, to be safe just always use between 3.5 and 4v

pin2 – ground

pin3 – RX this is whats being sent through the air, so this connects to whatever is transmitting at that unit (mcu tx pin) INPUT

pin4 – TX this is whats coming in through the air (mcu rx pin) OUTPUT

pin 5 – Enable (low for on, high for standby mode) to make it work just put it to ground INPUT

pin 6 – RTS (this gets low when the unit is ready to send) OUTPUT

pin 7 – CTS (when this goes low the unit is allowed to send) INPUT

pin 8 – FQ Set( this is for setting the channel, to set channel make it ground for the unit to run put it high) INPUT

the configuration i had working was just like in the diagram

Except i had pin 8 high, and i had no max202 the rx and tx pins went to my mcu. Thats all for now I gtg, I havent even connected it to anything to see if the data is coming through ok i just know the data is coming through (eg im getting output on the receiver when i transmit).

Update

Well after getting them to transmit I connected one to the pic and the other to a max232 signal level converter that is connected to the serial port. I had the pic transmit data to the computer basically. I did not use any pull up/down resistors in any of the tx/rx lines on the pic or the computer side. I got it to transmit from at least 100ft away, through walls and everything. The performance of these devices is great once you get them to work, since they are running at 19200 baud or 19.2k baud and the distance achievable is great. When I went about 100ft away and on the other side of my neighbors house i would start to get some garbage and the data seemed to come in bursts. But that was just using basic uart rs232 8n1, I plan on implementing packets of 64bytes with crc so errors will be ignored. I want to use 64 bytes because that is the buffer size of the modules.

I might look into setting the frequency (the channel) but thats kind of out of my scope for now.