Jinx end of summer update

-Where are we now and what do we do next ?

Jinx Main Board

I realized that the main board would be about 4  layers of very hard to construct printed circuit board. Then when you realize there is a error it could easily make the whole board useless, given you were able to create it in the first place.

To solve this problem I made a simplified version of the main board. It consist of only: MCU, ISCP, Power connector, Transmitter connector and 3 analogue inputs. there are also two voltage dividers, one for reading the voltage of the battery pack the other to set Vref.

Problems:

“Keep On” line is unable to turn off the circuit
“Charge Pin” may have the same problem (Or it may be solved by the latest power circuit)
Voltage divider that is supposed to be so we can check battery voltage is connected to the vout pin on the 7805, need to connect to the battery
ISCP pinout is not exactly like the pinout on our “Pickit 2″ programmer (mclr,vdd,vss,pgd,pgc,aux)
Need voltage drop resistors for the wireless module
Need 1k resistors on tx and rx lines (check current board to see if it employs them, because current board is working fine)
Vref voltage divider is really just a pot, we need a resistor somewhere to make it a divider
TX and RX lines are swapped to what they should be on the wireless module (picTX->wireRX … picRX<-wireTX)
We might want to add more io pins to the wireless module for stuff like (enable, RTS, CTS)

What To Do ?

Fix problems and remake the circuit, maybe add connectors for accelerometer and such. Also make a symbol in multisim so it looks right and is easier to work with, like you did in the usb transmitter. Some parts of the board may have been damaged while sinking +12v so I might have to make another board before I continue with testing.

Charge and Power Circuit

This circuit was revised several times, about 7. It still turns on by itself but that problem may lie in the input to the “keep on” pin. The alt power jumper is really more of a motor kill jumper, for it to supply power to anything it would need to have a ground pin. Other than that It works really good !

The charging part still needs some testing but here is how it *should* work. The P channel mosfet turns on to allow current to flow from the positive terminal of +12v to the positive terminal of the battey. This P channel mosfet “U7″ is controlled by a small signal NPN transistor “Q1″. When negative delta V is detected “Q1″ shuts off turning of the P mosfet and consequently turning off the charger. “U1″ lights up when the circuit is charging and “U5″ lights up when the circuit is on (and dimly when its not).

I should point out the P mosfet is unable to turn off without the help of the NPN. This is because Vgs for “U7″ is (5-12)=-7 when the Pic “charge” pin is high and -12v when “charge” pin is low. The -12v burns up the pic. The solution is to add a NPN transistor and a pull up to the +12v. So, when the NPN is off the current must flow through “R1″ to +12v making Vgs(12-12)=0, and when the NPN is on it allows the whole thing to go to ground turning on the P mosfet fully. This protects the Pic and ensures the line to be fully off or on, we should use this type of arrangement wherever needed.

PicC Code

void chargeBattery(){
   set_adc_channel(13);       // vdivider hooked to battery (39/(47+39))*vin
   ChgSec++; // tick tock
   // turn off charge input and read battery
   output_high(CHGPIN);
   delay_ms( 200 );
   // if negative delta v or one hour stop charging and go to idle state
   // and if it has been charging at least five minutes.
   if((battVolts < read_adc() || ChgSec > 3600) && ChgSec > 600){
      printf("\f Charged to: %u in %Lu sec", read_adc(), ChgSec);
      battVolts = 0;
      chgVolts = 0;
      state = '0';                        // return to idle state
      ChgSec = 0;                         // reset charge timer
   }else{                                 // continue charging
   battVolts = read_adc();                // latest battery voltage
   // turn on charge input and read charge voltage
   output_low(CHGPIN);
   delay_ms(800);
   chgVolts = read_adc();
   printf("\f Chg: %u Batt: %u time:%Lu ",chgVolts,battVolts,ChgSec);
   }
}

What to do ?

Pretty much we just need to test the actual charging and make sure we are charging the batteries when we send a high to the “charge” line. It would also be nice to check the actual current flowing and get a guesstimate how long it takes to charge the circuit. If we had another analogue line hooked into the connector we could get the voltage drop across a resistor to allow us to check the exact current flowing from the charger to the battery, or from the battery to the circuit but the resistor would have to be large and it is not necessary. I’m just waiting for the batteries to get really low before charging.

USB Transmitter

In order for everything to be wireless we have to convert the UART levels from the wireless “cy2196″ to +/-12v levels so the computer can understand them over the serial port. The traditional way to do this is by using level converters, either by making them with transistors or buying a IC like the max232. However, this method is bulky. You need a computer with a serial port, and then you still need to power your circuit. FTDI has a wonderful solution to these problems, it is a all in one chip that plugs right into your usb and converts the levels for you. It costs about $4. Using this chip I was able to make the transmitter small and now we need just one connector. The drivers are readily available but for most Windows 7 systems, it installs automatically.

This chip would also allow direct usb/uart communication if our project was more professional we could actually forgo the whole “virtual serial port” thing and have a “device” just like everything else you plug into your usb port. This adds a unnecessary level of complication and is not essential to the overall project, unless someone is experienced in this I would not recommend us doing that (yet?).

There is a program you can download from the FTDI website that allows you to configure stuff inside the chip. For example you can configure the CBUS pins to be RX/TX led drivers. The way it is setup now CBUS0 is RX or TX, this is the default configuration.

Basically this circuit is a interface from the FT232 chip to the CY2196 wireless circuit.

What to do ?

Nothing. This circuit worked great. It was insanely hard to solder it and make it as small as it is. Had I known it was going to work so well I could have soldered the pins from the CY2196 directly into the circuit board for the FT chip making it about the size of a thumb drive. I didnt want to commit a $10 chip until I was sure it worked though. I should point out that one of the caps burnt up, I believe it was the 4.7uF, maybe I had it plugged in backwards. I just removed it and never added another one. If we ever do re-create this we should check the 4.7uF polar cap very closely. Oh and the pads were not big enough to solder too, I remember now they were all almost under the chip. I think It was the wrong footprint.

H Bridge

After burning up all the IC’s we bought from mouser (like $10), I started looking into other ways to control the motors. The simplest way is to just put one side of the motor to ground and control the other side with a Mosfet, so basically one side goes to high the other is a switch. This works great and you can see the circuit I created above, but its just one direction, which is terrible we cant even go backwards. I tried several things, even tried making a h-bridge using npn and pnp transistors from RC car parts I had lying around. The best option is a little chip that sells on ebay for $2.50 the L298N. This integrated circuit has 2 Full h-brigdges inside the chip and is controlled directly via logic level lines. It has the logic circuitry to eliminate “shoot through” which is what destroyed the other ICs. This is the best way, the price is great, the features are awesome.

What to do ?

I need to wait for them to arrive and then build them a PCB to connect to the jinx main board and the motors.

Accelerometer

The digital accelerometer is the way to go. We can have interrupts based off acceleration thresholds. We can also just read the data out of the accelerometers memory. Plus it is a good thing to have I2C setup for other chips also. The chip has several different modes, we will have to determine which one works best for us. The chip takes readings 125 times a second so we should be able to get plenty of data out of it quickly. Instead of rewriting this I’ll just copy/paste from my notes.

first you must transmit a “start” which is in i2c_start() then you send the address of the accel $1D with the write bit set to ‘0′ for a write (idk) and then the accel sends a ack. Then you send the address you wish to read (8bit), the accel sends ack. Then you send the start again , the address of the accel ($1D) with the w/r bit set to 1 for a read from the register you set in the write.  the accel transmits a ack and then the data in the register. Then you transmit a i2c_stop().
Maybe the read/write bs is taken care of if you call i2c_read(byte) or byte=i2c_write()
something like this
i2c_start(); // Start condition
i2c_write(0×1d);// Device address
i2c_write(0xFF);// register we want to read ?
i2c_start(); // start again
datain = i2c_read(); // read from the register you selected
i2c_stop(); // Stop condition

What to do ?

I plan on making a pcb that is catered to this board then putting it upside down and soldering it as shown in the circuit above (from the datasheet). I will make it in such a way that it plugs in “right side up”, then we can put some epoxy on it so it does not get disturbed. If its upside down and the PCB is made in such a way that the solder joints are very close it should be do able. The other option is using a pan or toaster oven and doing solder reflow, but I think this way is more practical and will come in handy for tons of other people trying to do the same thing.

Jinx Flowchart (Partial)

Packet Structure

C# comm.cs Class

I’ve written a class to communicate with the robot and to debug/control it. Others should be able to use this class to interface with the robot. This should allow the people who are working on the interface and software to be able to just call these functions when they need them, they dont have to go behind the curtain too much. The class is very young as of writing this, but it is working well. Some bottom down type decisions need to be made before we can say that this class is ready to be used. These are the functions.

     public comm()
        public bool openPort(string port)
        public bool closePort()
        private void DataIn(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
        { // in get out quick ?
            try
            {
                foreach (char c in _serialPort.ReadExisting())
                {
                    rxBuffer += c;
                    RX_Bytes++;
                }
            }
            catch { }
            //loadNextRXPacket();
            //sendTXPacket();
        }
        public string loadNextRXPacket()
        {
            // get index of next '11'
            int i = rxBuffer.IndexOf(Dw.RXHeader);
            // if we found the packet and the buffer contains a whole packet
            if (i != -1 && rxBuffer.Length >= (i+Dw.RX_PacketSZ))
            {            // stuff from that index till rxPacketSZ into current packet
                currentRXPacket = rxBuffer.Substring(i, Dw.RX_PacketSZ);
                //rxBuffer = rxBuffer.Remove(i, Dw.RX_PacketSZ); // erase packet from buffer
                rxBuffer = "";
                validRXPackets++;
            }else { return null; }
            return currentRXPacket;
            //return null;
        }
        public string getCurrentRXPacket(char spacer)
        public int getNumberValidRX()
        public int getBytesReceived()
        public string getCurrentRXPacket()
        public void setcurrentRXPacket(string data)
        public byte getRXServerID()
        public byte getRXBatteryInfo()
        public byte getRXJinxID()
        public byte getRXFlags()
        public byte getRXPacketNumber()
        public string getRXBuffer(char spacer)
        public void sendData(string dataOut)
        public void sendTXPacket()
        public void moveJinx(char direction)
        public string getTXPacket(char spacer)
        public byte[] getTXPacket(int dumb)
        public void setTXFlag(byte mask)
        public void clearTXFlag(byte mask)
        public byte getTXFlag()
        public string toHexChar(byte hexByte)
        public string toHexChar(char hexChar)
        public string toHexChar(string hexString)

Plan for semester 2

Now that I’ve moved into the software world a little bit there are some things that have become troublesome and need to be addressed. I dont want to forget them so i’m writing them down here.

1.) if you transmit and receive at the same it destroys both. Hopefully we can transmit a packet and then after a short delay receive the other and create a cycle.
eg. jinx tx -> computer rx -> delay 200ms -> computer tx -> jinx rx -> delay 200 ms -> (goto start)
this would be a great place for a flowchart. The time taken to transmit the packet should all be taken into account, also if there were a error the packet would be discarded and the cycle would be broken so we need to either throw out the packet and transmit anyway or have a timer that checks to see if we have not received a packet for a second, however this would cause delays.
Just blindly transmitting and receiving will not work unless its really slow.

2.) the ‘0×3F’ problem, when we count in a char it gets to 0×7F and then goes to 0×3f for a period then starts over again at 00 ..

3.) What part of the program sends the packet ? What part of the program sets the motor speed ? I’ve found that setting the motor speed in the interrupt works great but there is no error checking or anything.

Looking at the cost of power mosfets or bjts it dawned on me that its pretty expensive to make your own h-bridge. I had abandoned the ic h-bridge because they kept burning up on me and they were expensive. But if your transistors cost .50c each and you need 8 of them to make two h-bridges than that is $4 just for the transistors.

Lets look at the actual cost breakdown

BJT H-Bridge

Cost per transistor: .18c, Vbe(sat) current: IDK datasheet is hard to find but we can assume driving transistors would be needed.
512-KSA473YTU_Q and 512-KSC1173YTU_Q, they are at EOL
So .72c for one H-bridge and about .10c more for small signal driving transistors maybe .5c for resistors and we have .87c not bad for a repairable H-bridge. When they burn up its always one transistor burns out, so if you can replace that for .18c that is much more preferable than having to scrap the whole circuit.

Oh and its not just that, if your using power mosfets you might need some small signal transistors to drive the power transistors. Since the pic MCU can only source/sink 25mA of current and you normally need about 100mA to run the power transistors. That could be remedied with mosfets but the mosfets are more expensive.

If we didnt go with the “cheepest” option and actually got transistors that had a datasheet we could get the 512-MJE210STU and 512-MJE200STU they have 5A ccc and max 8v emitter base voltage which is much better than the ones above, but these cost .26c each.Oh wow, the Vbe(sat) needs about 1A to get that 5A flowing, we would need a power bjt to drive our power bjt, then a small signal to drive that ! What a nightmare.

The integrated mosfet H-bridge ZXMHC3A01N8TC only costs $1.14. The down side to the IC is that when you burn up one mosfet inside the chip you cant repair it (well you could but it would be a pain, and you would need the expensive mosfets anyway).

So its $4 plus more work or $2.28 and less repair ability. Also there are power considerations, since the bjt’s will need a current flowing of about 100mA just to keep them on/off plus about 10mA for the driving transistor, with two h-bridges thats about .4 A just to run the h-bridge. Without a way to “shut off” the h bridges entirely when your no using the motors or some more circuitry to ensure both transistors are off you might be pulling a heavy load even though the motors are not turning with bjt’s.

As far as mosfet h-bridges these look very promising 512-FDS8333C_Q they are n channel and p channel in one small package for .28c each. The product is at eol. So that is about .14c per transistor. They can handle up to 4.1A, they wont need tons of driving circuitry. You would only need two of them to make a h-bridge so thats $.56 per h-bridge and they are semi repairable. This is the best option !!

Looking at it from a mathematical standpoint we can make 17 h bridges for the price of 10 IC h bridges, so its cheeper and more repair able. But the lowest shipping option from mouser is about $7 so until we want to order more stuff we should not order them.

Looking all over the place I’ve found that power mosfets of the type that would be easy to use to make H bridges are pretty pricey, not quite as pricey as a H bridge IC but still about .50 cents a piece. I realized lots of things must have H bridges in them, pretty much everything that has a motor that goes forward and backward will have the necessary transistors to make a decent h bridge. The only down side is that you might not be able to find a pair of h bridges so one side of jinx will have a different set of transistors, I hope this does not affect the speed too much.

I stripped some out of some RC car circuitry that I have laying around, there are some very useful chips on those if you ever want to do RC stuff. Anyway I didnt find mosfets I found normal pnp and npn transistors. Maybe if I looked up these transistors instead of mosfets I would find that they were cheaper? A quick search on mouser reveals that npn/pnp transistors that will do 3A are around .20 cents, so if we want to order parts we should do it npn/pnp not mosfet. I dont want to order them now because shipping will be around $6 dollars. Also the reader should note you cant stack npn/pnp’s and they arent quite as friendly.

So what I got from my RC car circuits were

2x B772 and 2x D882
2x KTA1273 and 2x KTC3205

There were other power transitors on the circuits but they were for the steering motor and had much smaller continuous amps allowed.

Researching these I find

B772’s cost: .40c ; max coll current: 3A ; VCEO max: 30v ; VBEO : 5v ; Saturation @ 100mA ; PNP; Pins: ECB
D882’s cost: .52v; same as above ; NPN ; Sat @ 100mA ; Pins: ECB
KTA1273 and KTC3205 are complementary, the first is pnp the 3205 must be npn. These are harder to find but from what I can see we might need as much as 500mA to drive the base, and they only allow 2A current. Besides that they are the same as the ones above. Pinout 3205: ECB, KTA1273 pinout : ECB

If we are driving with a pic than v/r=i so 5/r=.1, a 50 ohm resistor would do the trick. For 5oomA a 10ohm resistor would do it. I doubt seriously that the pic would be able to drive such a current so we could drive them with a 3904/3906 and should be able to get 10mA to their base using a 500 ohm resistor on the base of the small signal transistor to give about 10mA. I think the pic can do about 20mA so it should be able to handle turning on the small signal which will turn on the power transistors @ 100mA.

So we figured out most of the resistors and such, the values we will need. Thinking about it now there is no 5v tap on the connector for the H bridge so the small signal transistors wont work well since the battHV is around 7v. We might need a jumper with the regulated 5v because thats all the small signals can take, or we could do alternate power in of 5v … for now IDK. I do know we will need 12 transistors and at least 12 resistors, also some diodes like in our last mosfet h bridge to protect things.

I want to make a small test first and allow one of the motors go to ground and use the different transistors to see if the speed is a lot different. I dont want to go through all this work and then have the right side go twice as fast as the left or something. So tommorrow I’ll see how d882 vs 3205 works out before I make a huge circuit. I might have to dig out some other transistors from somewhere if that does not work.

till then : )

. . . continued … now is then

I tested the npn’s together turns out the 3205 makes the motors turn a little faster than the d882, maybe the d882 is giving the motors too much current and is not optimal and thats why they go slower. the difference is not really that much though so I plan on going ahead and making the circuit. I started to draw out the circuit and then i googled it to make sure i was doing it right and found this picture which is the same exact thing I was drawing, except of course different power transistors.

In the original site it says that the resistors are all 1k, i’m going to go by this and substitute my scavenged transistors. If i had $10 i would get one of these  LMD18200.

Conclusion

FAIL ! I did one of the h bridges, it is of course 8 transistors. When i wired it up on a protoboard and hand wired the switches it worked fine but attaching it to the pwm on the pic seemed to make it really hot and it only went in one direction. It is a real pain to make the circuit due to all the transistors (16 for the full circuit). For some reason even when the pic outputted a low on both the select lines the npn transistors were getting hot enough to melt the solder. Nice to know they will get hotter than molten solder and still work, or maybe they dont.

Anyway its too much time spent for such a poor product I think i’m going to order one of those LMD18200, it looks like the way to go ! Just a little pricey but with all the time and parts wasted so far it is much less expensive.

Looking on ebay i found this “L298N L298 Dual Full Birdge Dirver” (sic), it is only $3.50 it has dual motor driver on each chip and shoot through protection, also sense for amps etc. It is much cheaper than the other but very similar in features. Now I just have to wait 2 weeks for it to come from shanghi. Mouser also sells them but they are $4.44, and it would have that $7 shipping as usual.

Till then … no reverse we will have to move onto other things.

After hooking everything up manually I found I could actually get up to 1.2A flowing into the batteries. That would allow me a charge time of just a few hours.

Hooking up everything with the jinx mainboard and the power module did not yeild the same results. Since I’m charging with 12v and controlling the P channel mosfet via the pic when the pic outputs a high to turn the mosfet off it still has a Vgs of about -7v which *should* still leave it on. And when I output a low it is sinking 12v to the pic, I think this messed up pin_ra4 on my pic so I switched it to pin_ra5. Pin ra4 was not outputing as it should have.

So, to avoid sinking so much to the pic I used a small 2n3904 driver. This worked well and I was able to switch the p channel mosfet on and off. None of my dmm’s can measure amps so to measure amps I have to insert a 10 ohm resistor and check the voltage drop across the resistor to calculate the amperage. I measured a voltage drop of only about 300mA when everything was hooked up through the pic, this might be because the batteries were becoming more charged ? Also the analoge to digital conversion seemed to be off in the pic, where it was spot on before now I measure it on my dmm at like 8.5 and the pic measures 7.5. The pic always records the voltage on the battery as going down so it trips the negative delta v detection and stops charging. I put a timer in it so it waits 6 minutes at least before turing off due to NDV.

Also I discovered that the current can flow from drain to source, so I had to add a diode so that the battery would not flow back into the charger when the charger was “off”.

With the mosfet and the diode there are a few voltage drops, I’m not sure how they will affect the charging.

I’ve redesigned the pow/chg circuit and will remake it when I remake the transmitter circuit. From there we will see how it goes.

After all this I measured the voltage of the batteries at 8.54v which is higher than they were when charging on the sony charger. Also they were a little warm, so maybe they were charging and fully charged and thats why the pic detected negative delta v.

It would be nice to be able to log the voltage drop across a resistor and calculate the exact mA going into the battery at all times. That way we could see how fast it goes in at first and predict exact charging time.

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.

I printed out the bluprints and cut the pieces today for the body. I found the very big or very small plexiglass cuts are the hardest but overall its pretty easy. I printed out one of the bluprints wrong and made the sides about 15mm too small which sucks but oh well. I hope I’ll be able to fix it up somehow later because as it is now the frontmost wheel is back too far which will give too much slack in the track.

Welding the plexiglass pieces was pretty easy too. It bonds quick so they dont move and then it gets really hard after a few minutes. The first shape I made was a L shape and after about 15 minutes it was almost like one solid piece. The solvent should not be used to fill in gaps but as long as most of the edge is straight enough 80% of the piece bonding is still really strong.

As far as the placement of the idler wheels and such I’m not able to really test them because I’m still waiting for the motor box.

The circuit board fits inside well, should be plenty of room.

While I’m waiting for the motor and gearbox to show up I’m going to remake some of the modules. Hopefully when the motors show up I can make something that I can drive around.

I hope to make a blog entry on how I made the 3d model and upload all that, I spent a long time designing all this in cad software before cutting anything. I have the whole track and wheel set you see in the picture in cad (solidworks) if anyone needs it. I recreated all the pieces to scale.