ZoneMikel's Blog

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

• Mcu Board
• Power Board
• Ping Board
• Accelerometer Board
• Multiplexer Board
• H Bridge Board

The advantages of this modular design are

• Easier to make small one sided PCBs
• Easier to test modules separately
• Modules can be upgraded and replaced without effecting the rest of the modules
• Overall board size is smaller since they are stacked
• Much less connections on each board

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.

Before I actually start the mainboard in multisim I’ll write down some thoughts I had about improving it while they are fresh in my mind. One thing we could do to reduce the pins we are using is multiplex several inputs together. A lot of things connected to the board really dont need total control all the time. For example RA4 “charge on” could simply be hooked to a flip flop and toggled when needed instead of constantly supplying 5v and taking up RA4. If we had a situation like that then the flip flop could be connected to a multiplexer and selected and toggled only when needed, which isnt very often.

Things that could be multiplexed (some would require flip flops)

Ping Sending Pin, Keep On, Battery Voltage Sensor, Battery Temperature Sensor, Charge On, Set Wireless FQ and Wireless Enable.

So thats 7 pins that we could reduce to 3, we could actually use the same selects from our other multiplexer and just enable the multiplexer we need at the time. This would assume that we would not need real time polling of anything through the (future options) multiplexer. That would reduce the pins needed to just 1 (actually we could just use a pull up/down on the select to the multiplexer and free 7 pins without using any more pins, sorry just thought of that).  From 8 to 1 thats pretty good; however, we really dont have a need for this yet. If we were to do this then we would just have a bunch of pins we are not using on our MCU and we would have the added complexity of selecting our inputs and such. Also since this is the first run lets try and make it simple, but on future boards we may implement another multiplexer.

Also we can look at things that are never on at the same time and use the pins to do the same things. For instance we will not be running the motors while we are charging (i hope). So we could easily multiplex the hbridge select pins also, even though they are something that are used almost 100% during operation. We could write out every mode and see which modes are mutually exclusive, we could then multiplex them together to reduce pins. However, like i said before there is not really a need right now, and for the sake of simplicity we will go ahead with the current design. If we did do this now it would just result in a bunch of pins on the mcu not being utilized, at least two more IC’s added to the mainboard (muliplexer & flip flop), and since we are going to etch the board those pins would not get used in future uses anyway.

Well you know from my other post that I had some of the ‘7331 accelerometers, I also have some of the 7455 accelerometers. I’ve already spent my two 7331’s so unless I order more I only have the 7455’s. While browsing mouser I notice the 7331 is at EOL (end of life), so I took another look at the 7455.

The main difference between the two is the 7331 uses analog signals and the 7455 uses I2C protocol to relay the data. I’m really against “package” things, I dont want to just make things work together, I want to make the things. Originally I thought the 7455 was something like a packaged cots solution; however, it really isnt. Basically the 7455 does the digital to analogue conversion so your MCU  does not have to, it also has other benifits which I’ll try and sum up here. Another thing I’ve never messed with I2C and I love learning new things.

Summary comparison

7331
End of Life
Pins that go to MCU: 3
Total Pins it uses (from 14): 8
G-selects: 2

7455
New Product
I2C/SPI output
Programmable Interrupts
Pins that connect to MCU: 3 or 4 (or more, I’ll be using 4 I think)
Total Pins it uses: 10 to 11
G-selects: 3

In this case the “package” with the more bells and whistles actually lets you do a lot more. They are both about the same price btw.

Here is the basic connections to the MCU

I pretty much know nothing about I2C, looks kinda like token ring to me so I need to go read up on it. But, if we use this one and get the I2C working we can easily add more devices via the I2C (from what i gather). For this one device looks like we will need at least 3 pins but for the full features we will need 4. I want to get all the interrupts I can out of this thing. This way we can have interrupts instead of polling the device (as we would have had done in analogue). So, basically if there is a collision, free fall or acceleration it triggers a interrupt. To make sure we are going somewhere we can start the motors then check that there is acceleration, if we fall off something i guess we can cut off power to the circuit to minimize damage and if there is a collision we can stop and see where the collision was. But thats all for later what I need to focus on now is how to hook it up to the MCU, I’m going to have to go back and change the connections in the architectural document and I’m going to add a male header connection in case we want to add more I2C devices later.

The more I look into the h-bridge the more I got to wondering about things. For one the Vgs(th) for the p channel is -1v and that makes me wonder if somehow I need to make a negative voltage, I dont think so though. My lack of xp with mosfets was messing me up a little with these. Anyway in my investigations I found this very nice webpage on how to mess with H-bridges. The main thing you dont want to do is have both mosfets on one side “active” at the same time, this causes a short circuit and burns up at least one of the mosfets.

But before we get into that the chip i’m using is a ZXMHC3F381N8, it looks like this(thanks datasheetdir.com)



One suggested circuit is to make a little logic circuit so that you never have all of one side on at the same time. Here Q1 is like P1G, Q2 is like P2G and so on ‘Q’ is for the mosfet but “P1G” I imagine is p-chan 1 gate.

This circuit ties together the input of Q1 to that of Q3, and the input of Q2 to that of Q4. As a result, both Q1 and Q3 or Q2 and Q4 will never be on at the same time, since the N-Mos and P-Mos devices are active for opposite polarity signals (I.e. if ground is applied, the P-Mos will be active while the N-Mos will be off)

So, since the and gate is connected to Q3 a “N-Mos” it will only be active when high. And, the “P-Mos” will be inactive when high so we would simply have pwm to the active Q3. This would cause Q3 to become on/off at the pwm fq and cause the ground to be on/off at the fq. On the other side the PMos will be getting low so it will be active and Q4 will be getting low so it will be inactive, and since the input to Q4 is anded with a low signal it will always be low (for this 10 output) and remain inactive till the signal changes. Therefore we get pwm to ground on left side of motor and high on right side of motor. Another quick run through what if we have 11 that gives both pmos inactive and both nmos pw.

Oh I said there was a truth table in the datasheet, I lied …. let me make one

Tables, for clarity ill say P1S/P2S is HV+ and N1S/N2S is HV-, also MTRA is really P1D/N1D and MTRb is P2D/N2D. So the motors are connected to the drains and the high volt power is connected to the sources.

I hooked  the motor up with both sides to ground and then with both sides to 5v, neither of these seamed to “brake” the motor, I think both ground or both high will just coast.

To be sure about this I had better go ahead and make the circuit and test it out, I’ll do that a little later . . . I’m thinking to myself now if the pmos is active with ground and nmos is active with high then maybe we can just put the same line to both of them after all ?(thats what i end up concluding!) I’ll test it when I make the circuit.

PART II testing

Instead of making a whole circuit in ultboard and all that, since i’m just testing i used this method. Its a really easy way to make soic-8 into pdip, no etching or anything like that.

I burnt up two of my hbridges very quickly I think it is because i was hooking the gate up to 5v, and then I was just hooking up one gate which left the other floating and may have caused problems. Anyway on my third run i’ve put a push button to turn the circuit on and i put a little spit on the ic so when its going to burn up the spit evaporates quickly and I let go of the push button. If i hook the p and n gates together (one for each side) and put the gates to 1v it outputs five volts to each side of the motor (update! it had nothing to do with 5v to the gate I was hooking up the mosfets wrong !)

PART III why is everything going horribly wrong ?

When things go wrong I tend to leave them alone and just go “think about it” so thats what I did in this case. I only burnt up 2 h-bridges … thats $2 down the drain.

So far one thing that is wrong, I actually ordered the ZXMHC3F381N8TC it has the same datasheet so i’m not sure what the difference is. Reading up on mosfets i find there are two different types, depletion and enhancement mode they have different symbols too.

The “depletion mode” type are “normally closed” meaning they are active until you apply the correct Vgs to the gate at which point they open (open circuit). The Enhancement mode ones are “normally open” which means they are inactive until you apply the correct Vgs then they let the current flow through them. From looking at the symbols in the  datasheet we have “enhancment mode” mosfets in our hbridge.

The Vgs of our N-Channel (from datasheet) is 1v, so we should not get ground through it until we apply at least 1v to the gate. The Vgs of our P-Channel is -1V so it should not allow the positive voltage to flow until you apply -1v to the gate.

I also read more about the shoot through voltage, its what happens when you create a short circuit from the positive to negative voltage rails. So if i was to turn on the p and n channel mosfets on one side it would create a short circuit from hv power to ground. This burns up the chip. Its either this thats burning up the chip or the power going to the motor or the power going to the gates. Since the Vgs max is +/- 3v and I was using around +/- 1v i dont think that was it. The motor is super small and not straining at all so i doubt its the motor pulling tons of current. I’m very suspect to the shoot through condition being the culprit.

If i wanted to create the shoot through supossidly i would need to send gt 1v to the Nmos and lt -1v to the Pmos. However, when it was burning up was when I connected one side to ground or both p&n to -1v … which does not make much sense.

Next time i plan on testing each mosfet individually in the chip to see how (and if) they are working exactly.

Next Time . . .

Spent about another hour trying to figure out how the individual mosfets worked, then i realized what i thought was pin1 was pin8. After that i found that the mosfets work as they should. I used voltages of -2, gnd, 1v and 5v to test them what i got was this

N-Channel (-6v on, -2v on, 5v on) and (1v off, ground off)
P-Channel (1v on, ground on) and (-1v on, 5v off)

We can see that the N channel is active for 5v and inactive for ground, whereas the P channel is active for ground and inactive for 5v. So if we bind the N&P gates together giving one 5v will turn one on and the other off so we dont need any and gates or anything like that. Also we dont need negative voltage, the negative voltage seems to work as its positive counterpart does, but we needant worry about that since we are only using positive voltage sources

What I was doing wrong (i think) was connecting the gates from one side to the other sides mosfets, but if you follow this diagram you should be ok it was working great for me.

Since I did all this work just to test them I figured I midas well test them with the motors also. Applying 5v (from comp ps) as the positive voltage rail on the hbriges. I stalled the motors and put a very heavy load on them none of this even made the hbrige get hot. I seriously doubt given the motors and voltage we will be using that the hbridges will fail. It is much more likely that the motors will tear something up (mechanically) or that the motors themselves will burn up.

Made this in dia so there will be no confusion. Pretty much pin1 is always power pin2 is always ground. If there are 4 pins but only 3 are needed we will leave the other not connected for stability.

connections

The cheapest and really only available package for the accelerometers is LG-14 which is the package used for the MMA7331LT accelerometer that jinx is going to use. This acceleromter is really inexpensive at only $2.32 a pop, but the package is very difficult to deal with. I bought two of them, the first one shot out of my tweezers and was lost forever, the second one met its demise by what happens in the rest of this document.

Let me start off by saying if you want to use this then I’ve found a way to do it pretty easily. First use the artwork originally created in this post by its author.  It is also in the gallery for this post. Then use this instructables method or you can watch this video. Basically you HAVE TO use a diy home reflow soldering method. Basically you get solder paste (like glue) put it on the chip and board then put it in a toaster oven timing everything carefully.

If you dont want to do it that way you can put the chip upside down on the board with a little glue to hold it in place, then you can solder really small wires from the chip to the pads. Afterwords just use resin or expoxy and coat the whole thing so it is sturdy. The main pain in the neck with this method is that everything is upside down so you have to be extra careful with the pinning, and since its a accelerometer your axises will be off.

I tried to do it by just soldering and using a small butane torch. I dont think it worked. When I tested it it seems to output something but i’m not sure if its working or not. I have no confidence in the adapter and I dont want to use it in my design. I will use the footprint and all the stuff I made in the main board for jinx and will use the diy reflow process when I find a toaster oven ( and get more accelerometers ). This way its on the board and does not take up a lot of space. So, the adapter is out the window.

But someone else might want an adapter so I’ll post all this stuff here. I didn’t just make it a straight adapter, I added all the caps to it and only used the pins that are really connected to something. Only 8 pins are used on the 14 pin lga ic. So if you wanted to make an adapter you could use this circuit and just be sure to use the diy reflow process when you actually “solder” the ic to the board.

I used the laser printer method for transfering the design to the pcb. Be sure to print out the “reverse” when you print it from ultiboard. NOTE: if you use my ultiboard design remove all the NC pins connections to ground, you can connect them to each other but I dont recommend you connect them to ground.

So, basically print the circuit (in reverse) on some magazine paper and then heat it up on your board with a iron. Once you start to see/feel the traces coming through your paper (or it just feels right) take your board up and put it in some warm water, let it soak for about 20min. Then go and rub off the paper the toner should remain attached to the board.

It comes out pretty crappy, or at least it does for me so get a exacto knife and a ultra fine tip (black) sharpie and fix it up.

Now you can etch it. There is a really cheep etchant on ebay it comes in a powder and makes tons of etchant. I just put two spoonfuls in about .5c of water for this one.

I had to let it sit for about 2+ hours when I noticed it started to remove the copper I agitated it a little with a plastic fork.

Then when its finished take it out and clean it off. You dont want to leave it in for too long after it has etched the exposed copper because it will start to eat away at the unexposed copper too! Genty scrub off all the black toner/marker with basically anything abrasive.

Again get out your exacto knife and make sure the smaller lines are not connected, especially the ones going into the lga-14. Then you can drill the holes, for this you really need a drill press. I use a dremel with a drill press, but then you run into another problem, the drill bits are so small they dont fit in the dremel. I fixed this by adding masking tape around the bit then tightening it a lot. Make sure your bit is not wobboling before you start to drill, and wear saftey glasses.

And of course from there everything was already wrong because I was unsure if the connections had been made to the chip. Its impossible to tell because there is no place to connect to to test for connection. Once I get new chips and a toaster oven (or i could use the skillet method) I’ll do it again but it wont be on this adapter board it will be on the main jinx board. But some of you might want an adapter like this so if you do go ahead and use the files I provide (maybe just as a starting point).

AccelAdapter (multisim and ultiboard files)

Thought I should add this to anyone who is reading this here and sees stuff related to this robot but there is no overall “what is it”.

Basically we aim to make a robot that can be controlled through the internet. So we have cheap simple robots that have basic video feed and can move around and you control them through the internet. The basic thing is “remote presence” but this could also be applied to actually manipulating objects through the robot. Think about going to work without ever leaving your seat !

Robots are very precice and we can pump them full of sensors, but they arent very good at thinking. Not to worry we already have tons of people who can think that love to do nothing more than control remote things through a computer, for example WoW, FPS, RTS etc. So, if we can make controlling the robot similar to a MMORPG or FPS it will be fun and entertaining for the users. We could even arrange competitions. But wait, wont I be restricted by the robot ? Yes and no, you will have some limitations of course but the added sensors should balance that out. For example gps and collision sensors will help you navigate and tell you if your about to collide with something you cant see.

Anyway, thats a basic overview. We started the project on a google group but I think we will navigate to this blog software since the google group software does not allow for organization of files and such.

If you want lots more information about the first semester you can look at the google groups page here http://groups.google.com/group/uhclseniorproj010?hl=en