Disclaimer
The opinions expressed herein are my own personal opinions and do not represent anyone else's view in any way, including those of my employer.
© Copyright 2010
The opinions expressed herein are my own personal opinions and do not represent anyone else's view in any way, including those of my employer.
© Copyright 2010
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); } }
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.
Just noting some things that are wrong with the board so far. I’m happy to find these now instead of when i have twenty of these boards in my hands.
Basic notes, just stuff i found through further study that i dont want to forget.
Pin 7 on the wireless module is “reserved” and in the datasheet it says you can leave it disconnected or “can be pulled up by a resistor to vcc”. I dont know why they have it connected to a mcu pin on their diagram in the datasheet
The pic transmits it signal on the 4th pin on the wireless connector on the jinx mcu board, so it transmits on the tx pin. This is common sense but it can sometimes get confusing what is transmitting and what is receiving.
Power Circuit 2
I revised the power circuit to use all N mosfets. I thought I could just not allow the battery or charger to the ground so it would not make the loop needed for current to flow. Unfortunatley I had the indicator lights hooked into the same transistor as the batt / charger, this caused the loop too be made anyway. Then I decided to not allow the 7805 to go to ground using a transistor, this partially worked. The problem with it was even if the 7805 is not connected to ground it still lets a little current flow, barley enough to light a led dimly. So its a better solution but not a perfect one. I guess I’ll have to rework it again.
In the latest power circuit I had the switch switching the gate of the mosfet to ground not to the high of the battery as it should be. Its fixed in the multisim document but not on the ultiboard circuit.
In the rs232 circuit the tx / rx were backwards compared to the ones on the jinx mainboard, also the lights seem to be on all the time and just blink when sending. This is only for plugging directly into the mainboard but it is convenient to have them this way.
For the rcr and rct we need filter caps and an antenna the antenna can be just a straight wire of 170mm length. Also the transmission should be inverted so the transmitter is normally off, it also has to be converted on the receiving end. This is just for rcr/rct which we wont be using in the final design.
The power supply for the transmitter is at 5v which is fine for the rcr/rct but will burn up the expensive transducers that we will be using in the final design. We can get some voltage drop by using diodes. We could use a jumper to switch between the 5v or 4v.
Put diodes and other things on the basic hbridge circuit, look at the latest circuit there was no ultiboard circuit. Its written in the lab notebook though.
Solder the jumpers/headers upright straight to the board dont drill holes or bend the pins at 90 degrees it just makes it more fragile.
If the copper pad is too small around where a pin is to be soldered to the board it will eventually come loose and make a bad connection ! Make the pads big.
On the wireless module connector pin5 is enable if we want to turn off the wireless module with the pic we should control that with the pic, right now its just connected to ground. Also pin 6 is rts it will let us know when the buffer is full and allow us to drop the cts line so it can send the info, as is its just connected to a “busy” light. As far as i can tell no pull up/down is needed on the output from the pic to the wireless. Since we might only set the channel every once in a blue moon we might want to make pin8 (fqset) a manual switch. The website says you cant change the channel anyway but we might be able to, anyway it does not warrant a mcu pin.
Transmit and recieve on the mcu board should be switched since pin3 rx and pin4 tx are swapped with pin3 rx and pin4 tx on the wireless module. The mcu tx pin should go to rx (pin3) on the wireless module and the mcu rx should go to tx(pin4) on the wireless module. We will switch it in software for now … DONT FORGET!
When the motors turn on it draws too much power and the mcu wigs out, the solution is to put a large cap between vdd and ground to reduce the dip. Be sure to include a 100uF cap just after the 7805 on the power circuit. This worked well and eliminated that problem.
The voltage divider part is connected to the +5v from the 7805 and should be connected to the batHV+ instead. I fixed it manually on board but we need to fix it before the boards are made again.
BattHV might be a little to HV for the tiny tamaya motors we are using, maybe some diodes to get a vdrop and reduce junk coming back into the circuit ? We have 8v we want about 3-6v i would think. We want the reduction on the Hbridge module not the power module, this way we still are able to see the exact battery power and maybe use it for other things?
The first thing I did was hook this up to the connector on the jinx mcu board … this provides 5+V to the module. I saw a little bit of smoke and it bubbled up a little. I thought I had ruined it but it turns out it still functions, not sure if perfectly but it does tx/rx.
First lesson, it needs MAX 4.2v so you cannot use your 5v source !! It can run off of +2.4V to +4.2V and it needs 100mA. So If you were to use a voltage divider it might work. I used a lm317 to get a voltage source of about 3v. But if you wanted to do a voltage divider you could use a 47 ohm resistor as r1 in a voltage divider that would give you 5/47=106mA. In the basic voltage divider formula Vin*(rk/(rk+r1))=vout solving for 3v gives us 70 ohm as rk. That should give us 100mA and 3 v but you still have to make sure you wont burn up your resistors and in turn burn up the whole module.
I programed the pic to transmit at 19200 baud then I looked at the output from the other wireless module through the scope. Looks like the signal went through just fine.
The only weird thing is on either module connecting the scope to the rx or tx both give the output from the pic. So if i was transmitting on the tx pin on one module then on that same module i connected the scope to the rx pin (pin3) i would see the same signal I’m sending out. Also on the module thats receiving the signal through the air is outputting it on the tx and rx pins.
It says nothing in the datasheet about full duplex or anything so looks like we will have to experiment to figure it all out. This puts thoughts into my head about ack signals and such, I need to start thinking about how the two devices are going to communicate.
There is some scewyness with the compiler and enhanced pwm, so just to get all the p1a,b,c,d to work i had to use the code in this ccs post.
From there I wanted to know how the values are set to actually make the frequency you want. First you have to realize that the pwm is really just a result of a interrupt on overflow for timer2. So, whatever you set timer2 to be will be your fq of your pwm. To set up timer2 you use the command
setup_timer_2 (mode, period, postscale)
The mode is simply a divisor of your main clock frequency it can be 1,4 or 16. You should also note that since this is timer2 it also automatically divides your main clock by 4, each timer has its own “dividend” of the main clock, in timer2’s case it is 4. The postscale is the amount of times you will allow timer2 to overflow before you interrupt, so if you had everything setup for 500Hz and you wanted to actually use 1kHz you could just change postscale to 2 and it would interrupt every 2 times it overflows.
The hard one to figure out is the period, we all know what the period is but how do we set it in ccs? Well the max value is 255 and the min is 0 being that it is a 8 bit value (i think). So, 255 represents the max period which would be Tosc/(4*mode), you can figure out what that is. Just playing around half of 255 would represent half of Tosc/(4*mode). Anyway forget loosing yourself in all this there is a nice page here that oultines the whole thing and gives a nice formula
How to calculate the required values of the TIMER2: 
that (PR2-TMR2) is really the value you put for “period” in the function for ccs. A quick example at 4MHz main clock on the 887 to get 1kHz we would use
setup_timer_2(T2_DIV_BY_16, 124, 1); // Set 1000 Hz PWM freq
so with that example we have a 1kHz frequency and this is where our timer2 would interrupt and our pwm would turn on/off to drive our motors. But, thats just part of the equation how about the duty cycle ? Turns out thats pretty easy to do (hard to find info on) you just take your period (for timer2 interrupts) and multipy it by the % you want of the duty cycle. So, if we have 1kHz and we want 25% thats (1/1000)*.25 which gives you 250uS then you times that by (1/Tosc) * “mode divisor” in our case 250uS*(1/4M)*16 which gives me 125. I’m not sure if their value is wrong or my calculations but this is what they (ccs) give in the help file
value*(1/clock)*t2div
But you can just forget all that, since you’ve already calculated the value for “period” in setup_timer_2 you can just multiply that value by the desired % … for example 25% of our period 124 is 31 so we can set the duty at 25% with the instruction
set_pwm1_duty(31); // Set PWM for 25% duty cycle
With this code I got the pwm working great, it would wait a few seconds then increase in increments to 90% afterwards it would go to 0% duty then start over again. Here is my code
code here . . .
after hooking it up to the hbridge circuit I made a short video of it switching speeds, at the end of the video there is a unhappy ending when the hbridges burn again. I really need to go back and redesign the Hbridge circuit to make sure shootthrough is never a possibility. The lines float or something happens and it burns up the hbrigdges quickly. I almost want to make my own hbridge so i would have a better idea whats going on but I dont have any mosfets that will handle the motors.
So enhanced mode pwm, and switching lines on/off pwm worked great ! Hbridge still burns up 
With all the headaches involved with the circuit the main reason it needed to be started before I work on the body is so that I can see how big the circuit board will be before i make the body. So basically what kind of rectangle am I going to need to accomodate in the middle for the circuit board.
Now I know the circuit board will be max about 72×63mm, or at least thats what it was on the board where I had everything on it. But we should give ourselves some space around that just to be sure. 73mm is 2.87 inches so we will call it 3inches. And 63mm is 2.4 inches so we will call that 2.75. So, we have a rectangular board that is 3×2.75 inches, thats not bad at all.
There is another element to the board size, since we have the modules that plug in at a 90 degree angle from the actual board our space must be pretty high to accomodate them. This works out ok if you think of a Johnny 5 type robot with a rectangular base. So our space where the board sits must also be at least 1.5 inches tall to accomodate the modules.
So to sum it all up
Circuits
MCU board (2.8in by 2.4in)
Modules max height from bottom of header to top of board 1.5 in
Body
at least a 3in x 2.75in x 2in to accommodate the circuit.
Before I dissapear in the confines of ultiboard and multisim again I thought I had better write something. The Power circuit and the Ping Circuit were great sucesses. I’m glad I decided to use this modular design, I see now that the all in one mainboard was really a bad idea. Once everything is working I can send off to have a “all in one” board created for about $2.50 each if i buy 20 of them. So the goal now is to get everything working bare bones then improve as much as i can and then order some professionally made boards. I want these boards to be a good starting point for any robot that we decide to use in the future. So a robot that moves on tracks might have the same circuitry as a robot that moves over water, or flies etc.
The H-Bridge circuit works . . . but, I finally see why they were using and gates to make sure it NEVER allowed one side of the h bridge to be totally on. Even if you just let the selects float it can burn up some of the mosfets on the little chips. So make sure the selects are always tied to something, I still dont know how but just from floating one of the mosfets burned up inside the chips. I think i’ll be able to repair it though simply soldering a normal mosfet on top of the chip. But i do need to order some more h bridges … ~ None the less it works fine like it is but I may add some protection circuitry to future modular h bridges.
The accelerometer and the multiplexer module are etched but on a back burner. Since they aren’t really essential to the project (yet) I’m putting them to the side while I see if i’ll even be able to use them. I’m realizing with the mcu board that I’m gonna have to remove some stuff to get something I can actually make.
The MCU board was again a nightmare, even at 70 connections i had to do double sided boards and reduce the trace width to about .3mm and the trace clearance to about .15mm. When I did that I got about 64 of 70 connections connected, but there were about 25 vias. After etching the board (which was attractively small) there were a bunch of places that had traces connecting. I could fix the traces connecting but there was also the problem of the vias being really small, when you drill them it just obliterates the pad and you would have to do some fancy stuff just to connect them, plus some of the vias are under the mcu itself which will cause all kinds of problems. From messing with this for the last week I can kinda tell when im jumping in a bottomless pit and pull out early. I realize a lot of these connections are things that we wont even be using, for example the multiplexer circuit wont be used, at least not in this design and the “extra pins” connector is just that extra pins. So I’ve decided to remove as much fluff as i can to get something I can make at home.
I’m not abandoning all the connectors at all, I have full plans of implementing everything but like I said above I want to test as much as I can at home then send the board off and get about 20 of them made professionally. I think the best you can hope for with home etching is about 50 connections and .4mm traces and .2mm clearances, but .3mm clearances are so much better. What I’ve noticed also is that the trace/clearance size does not make that much of a difference sometimes, sometimes its just you have to many wires crossing. I’m going back over the pinout of the chip and the connectors I have maybe by re routing some stuff I can clear up a lot of clutter. In the original design I never took into consideration the placement of the connectors and the pins on the MCU, I’m seeing that that was a bad error. However, if i can limp by on this design (for testing) i should be able to get the professional boards made which can handle everything on one board.
So I’ve creatied a “jinx mcu circuit barebone” circuit to try and get something I can easily make. I’ve reduced it to just the mcu, hbridge, wireless and power circuit so when i finish I should have a glorified RC car with no sensors. But we will see how that goes. I’m still working on the barebone mcu board and hopefully I’ll be able to etch it and test it a little today.
One more thing I should point out, I’ve decided to make all the modules connect at a 90 degree angle from the mainboard, this makes things a lot simpler. I just have to remember to bend the connectors to a 90 degree angle before soldering them into the modules. Instead of the robot being short and fat it will be more tank like with a semi tall body, looks like the board will be about 2 inches tall and maybe 4 inches wide. That still may change though.
The two sided big jinx mainboard was kinda a disaster. With traces just .3mm thick and clearances of .1mm I think I was pushing it a little. I made the board but there were lots of problems, the outer traces got eaten by the echant was the main problem.
I had been thinking about doing a more modular design, but I had already started the other board and expected it to work. Anyway a modular design was kinda a fallback plan B sort of thing. It is actually better than the one board approach.
The modules are
The advantages of this modular design are
I made each board have a male header that goes out from the bottom, on the main mcu board there are female headers to plug these boards into. Most of the boards have 6 or less pins connecting to the mcu board. If the boards connect to anything else (motors, batteries, etc) they have male headers on the top of them. This should allow us to make the modules stack on top of the mcu board and make the overall board smaller. By doing this we reduced the connections on he mcu board from 130+ to 70 ish.
I created all of the boards quickly in multisim then made the pcbs for all except the MCU and Multiplexer board. They are all etching as I write this.
Multisim
While creating the mainboard in mutisim I discovered a lot of errors in the thinking. For one I was using N channel mosfets and not allowing things to go to ground where I should have been using P channel. One example of this was the voltage input jack for charging, had I simply not allowed it to go to ground it would have still went through the batteries to ground. So I replaced the two N’s with P’s, this actually helped clear up some stuff. One thing it cleared up was the on push button, this button would have needed ~1v to turn on had it been a N channel so this would have required some voltage divider and a constant drain on the batteries to provide this 1v, but with the P channel all we need is the tactile switch to go to ground. Also another thing that was wrong was we had the mosfet that keeps the circuit on before the place where the battery taps in, this would mean the motors would flow through this mosfet which isnt rated high enough this would burn it up. All these modifications will have to be updated in the architectural design and the pinouts and such. Another thing i had to move the mosfet that turned off the circuit to before the 7805, i dont want the 7805 running constantly.
I also had some trouble with footprints. I had to make a footprint for the pots i ordered from ebay, also some things didnt really have the pins mapped right. Like the Voltage Regulator, pin1 vin, pin2 gnd, pin3 vout and that is how it was shown on the symbol but then when you sent it to ultiboard the footprint had things going to the wrong pins. I had to go through and make sure all those things were ok. I pretty much just spot checked a few things to make sure the pins were going where they should.
I tried to make the multisim design as “pretty” as possible but that proved impossible. I added all the male headers and other circuits into sub circuits but even that was not enough. The circuit has so many connections you cant really tell what goes where, well i take that back you can but it takes a lot more than just glancing at it to see where the wires go. I’m not sure what can be done about this except being very careful. I tried to move one of the components after wiring it all up and it made all kinds of messed up connections all over the place causing me to start again from scratch. I tried to make some of the connections more clear by making them at a angle, when two things overlapped I set one at a angle.
Ultiboard
Things didnt get much funner when I moved everything over to Ultiboard. I spent a long time trying to figure out how to get the “autoroute” and “autoplace” to my liking. If you autoplace the components it kind of just throws them around without any order, this might be great for connections but it makes a really nasty confusing board. I wanted the connectors to be on the outer ridge and the components to be more on the inside, also the led’s and buttons should be in a easy to find place. To acomplish this I put everything where I wanted it and then locked it in place. Since I’m going to be having a double sided board I allowed smd mirroring, then I allowed ultiboard to autoplace the components. There are a lot of things that are needed to know to get this done without taking all day, it just comes from experience working with the software and reading the help files (and user guide on your c drive).
After that I wanted to route things on both sides but it always seemed to autoroute more on one side. I found that you can fix this by selecting the nets in the spreadsheet (on the bottom if enabled) then where it says something about what side to route on you click that and then click top and bottom, make sure its not grayed and checked make sure its clearly checked (by checking it a few times). This causes the mode of routing for the nets to be 111 for a double sided board and then it will create a ton of vias and route a lot on both sides of the board. I had to reduce my trace width to about .3mm which is pretty small, also I had to reduce the clearance in the traces to about .1mm i think. The traces get spaced out well by changing the density factors in the autorouting settings. I recommend reading the ultiboard documentation (or help file) thats here \pathtoNI\documents\ultiboard usermanual.pdf . You really have to read that to know what all the “cost factor” things are when setting the settings for the autorouting and autoplacement.
Auto routing got me almost all of the 130+ connections, then I added a few jumpers and added a little fluff around the places I know I’ll have to work magic later. I paid special attention to the accelerometer area because I wont be able to solder jumpers to this area later. At the least if you see parts of the ratsnest where you will need to solder jumpers later make sure there is a nice copper trace there to solder too. I think I’ll have to add about 10 jumpers but they are all in places where I can get to. At least the board has some order to it and it will be easy to work with when/if everything works.
There are lots of errors I’m ignoring especially around the lga-14 footprint since its pads are closer than the clearance for the boards. I’m hoping to make the traces a lot fatter with a marker after transferring to the board, we will see how it goes.
Oh just a quick note. I was looking for a way to print out all the connections to test them by hand however I could not find it anywhere in multisim. But, if you export the circuit from multisim to orcad pcb (transfer -> export to pcb layout) then save as a orcad .asc file it creates a file that you can open in wordpad. In that file you can easily see what is connected where, its very useful for checking everything.
This has been abandoned.
This board was very hard (impossible?) to make. I thought of a better way of doing this using several small boards instead of one big one. You can read about the modular board here.
Categories
Tag Cloud
Blog RSS
Comments RSS
Void « Default
Life 
Earth 
Wind 
Water 
Fire Light 
Previous Entries
Last 50 Posts
Back