ZoneMikel's Blog

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.

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

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.

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.

I had to create custom components in mulstim for almost everything I’m using in the project. I even had to make a footprint for the accelerometer LGA-14 which was pretty hard. There was no 7805 in the right footprint so I had to remake it, also the 555 timer didnt have a footprint.

Pretty much all of these components are just like dummy components that have the right footprint and pins. You cant simulate them and they dont list the pin functions.

The LGA-14 is for the ti accelerometer it might come in handy to others.

JINX_CustomMScomponents

Circuit_Interfaces_Overview

In order to get a better understanding of the circuit I need to create for JINX I’ve summed up everything in a diagram. I use DIA free diagram software. I also took the opportunity to put information about the inputs and outputs so we know we are not cramming round pegs in square holes.

The circuit is turned on by pushing one button that turns on a transistor, after that the mcu starts up and keeps that transistor high. This allows the circuit to turn itself off if needed.

I’m using almost all the pins on the 887. I did not try and spare pins but i did try and spare more useful pins, most (both?) of the free pins have a good hardware function that may come in handy later.

I mentioned above I used dia, I love dia and its free at http://projects.gnome.org/dia/ it is a linux program but there are windows binaries. I will include the actual dia diagram also.

I hope to be able to create a 40kHz signal to drive my transmitter for my range finding sonar. It has to be very close to 40kHz and tunable would be better to get the max output.

From the very simple circuit on this page the frequency is given by
Frequency = 1.44/(C1*(R1+2R2))
Where R1 and R2 are in megaohms and C1 is in microfarads.

So, f=1.44/x; x=0.000036. so if we let c1 = 1uF then R1+2R2=36uf. If we let R2= 1M then R1=36uf-2 which makes no sense. If we let R1 =1M the equation becomes R2 = (36uf-1)/2 and R2 becomes -.49 … so we need a superconductor or another value capacitor.

(after a night and half a day)

If (R1+2R2)=10 then C1 is 3.6uf. But that “r1 and r2 in M and C1 in u” is really confusing… I really dont like that formula. If you go to wikipedia they pretty much have the same formula.

If i use R1+2R2=10M then C comes to be 3.6pF. The smd caps I have that are close to that value are 1, 2.2, 3.3, 4.1 and 8pF. So with the 8 the resistors must be about 4.5M. I dont know why but I would rather have smaller value resistors, so I’ll go with the 8pF cap. With that cap I could have a 2.5M and 1M resistor for R1 and R2. The resistors I have on hand in the M’s are 1,2.2,3.3 and 4.7M. If I use a 2.2M for R1 that gives R2 as 1.15M when solving for R2 in (R1+2R2)=4.5M. For the 1.15M I’ll use a 1M and a 150K in series to give 1,150,000 ohms. Besides the tolerances this should give me something really close to 40kHz.

40kHz: C=8pF, R1=2.2M, R2=1.15M
According to those values and the forumla for frequecny above I get 40,075Hz.

Constructing the circuit I get a weird duty cycle that is more like 80% and the frequency is all wrong … I’ll have to investgate more and test in multisim.

(a little later)

When I tested it in multisim the results looked very similar to what I saw on my scope. A frequency of about 30kHz and a duty cycle of like 80%. I found a online calculator and used my values, it said my duty cycle was 74%. So my calculations all give me 40kHz but I’m not getting that.

A quick search on the web for “555 timer 40kHz” yeilded this

And a few links down I found this … which pretty much solves all my problems. Now its just a matter of building it and testing it with a scope.

Now I just need to find some pots … And i’ll also test to see if we get a big signal boost by adding a inductor. From my tests with multisim a inductor in parallel with the Txer will give voltages in excess of 20v from the 5v source.

PART II

Well after a few days (and getting my soic 555’s) I decided to test this. I created a circuit to test it in multsim, then ultiboard then I etched it using the process described in my other post

This circuit worked great ! By counting the us/div etc on my scope i found it goes from 29,851Hz to 41667Hz which works fine for this. I also feel pretty confident that i could replace the pot with a 11k resistor and not worry about it, but for tweaking the pot is nice. I set it to 40kHz by using the formula x*(s/div)=To where To is the period and the (s/div) is whatever you set your scope to.

Then I hooked it up to some of the tx/rx pairs i have it did work. There seems to be a lot of bleedthrough from the tx to the rx via the circuit but if i connect my scope to a separate rx and hold it close it will get a good .75v when it is close. As is i think this will work for ranges of about 8inches. Something has to be done about removing the ac from the tx/rx pair, there is already a cap in there as they had in this picture but it either is not working or does not work (lol).

Oh and that 330uH inductor does not seem to do anything, it just wipes out the signal and gets really hot. But all this is for another post when i make the ultrasonic tx/rx boards. For now the timer is established that it works great.

So the whole timer circuit is connected to one pin on the mcu, this one pin goes to the reset pin on the 555 timer. It should have a pull down resistor so it is low when its not high (lol). When you send a high to the reset the 555 will send out a ping ( or a few depending on how long you turn it on). Then we just wait for the reply via the us rx (gt .2v should work).