sounds like the bootloader does some sort of initialisation that you're missing

point it upwards at a reflective cone

If you need precise timing, use a spare timer interrupt. Then you only need to watch out for interrupt latency if your application is more than toggling an output's state.

Add a resistor between the arduino/74hc595 output (which you've labelled +5v for some reason) of about 1k, or you'll blow something up (probably the IC's output rather than the transistor). Remember that a transistor's base-emitter junction looks like a diode to whatever's connected to it.

other than that, it looks fine.

use a transistor rated for Vce>=150v so you have some headroom. google knows where all the datasheets live

transistors + 74HC595s is how I'd do it.

Note that you can chain 74HC595s to each other, so you can get away with just 2 digital pins for the whole thing.

Of course, the more digital outputs you use, the shorter the chains will be and the faster you'll be able to update the display so it depends on which part of the balance suits your application best.

Oh, remember to connect the -ve side of the inverters to your logic 0v or the transistors won't work properly.

you could quite easily connect both the rx pins together, but only connect one tx or they will fight each other when they reply.

If you do this, one will be programmed "blind" - ie your computer will get zero feedback as to whether or not it worked, because only one can send signals back at a time.

Also, you'll need to ensure that they both reset at the same time.


You may want to have a look for the threads about using the arduino to program other chips

12.5 microseconds delay. The period is 25 microseconds, and there are 2 transitions in the period. Since it's so short, you must use a PWM output to generate the frequency. doing it in normal code will introduce too much jitter. see the atmega168 datasheet for how to set PWM outputs to particular frequencies.

Connect it to a digital port, preferably with input capture feature so you don't get interrupt latency in your readings. The transducer itself will filter out most other frequencies for you, and like I said before, the analog ports are useless for short pulses.

The SRF04 I linked is a great example of an ultrasonic ranging module, read its article closely

ok, that seems pretty simple... but the question i have for using the microcontroller is : how would i know what 40 khz is in delays? is it just plain old 40 milliseconds, so all i have to do is write delay (40) and then turn it off and on every 40 millisecond delay?

period = 1/frequency.
1/40KHz = 25uS (uS is microseconds).
period = Ton + Toff, so for a 50% duty cycle, Ton = Toff = 1/2 period = 12.5uS * 16MHz = 200 clocks.

you'll have to use a PWM output for that sort of delay.

and for the amplifier, will any amplifier work? like any amplifying chip, or do i need a sepcific one, or a kind of chip? also, can the arduino maybe amplify it, by possible multiplying the analog input coming in by a value?

You could theoretically use an analog input, but since its sensitivity to high frequency low level signals is basically abysmal, you would get only very short range readings, maybe a foot or two, and that's with lots of tweaking and messing around. You really need an analog amplifier like an op-amp to boost that signal up, and may as well do simple thresholding after all that trouble, just like the SRF04. Then, you simply send a ping, and time how long it takes to get back. You'll need an op-amp with decent gain at 40khz, so 741 and LM324 are no good (only 20dB gain at 40KHz), and something like LM833 should be better (50dB gain at 40KHz)

so i have to buy a crystal that is at 40 khz

Nope, just generate a signal using one of the timers or a separate microcontroller or whatever. You could probably even do an oscillator since the transducers act like ceramic resonators tuned to 40khz already, although it would be difficult getting a nice sharp pulse.

, feed power through it, and connect ground to the other side, then by some amplifier and connect it to the other range finder, and pump power through it also?

yep

and keep them perfectly level next to eachother?

They don't have to be perfectly level, see the beam pattern in the datasheet to find out how much leeway you have.

will it matter how close they are to eachother, like 3 inches next to eachother, or 5 inches?

That depends entirely on your detection circuit. You get a huge pulse during transmission from direct coupling, then the received pulse is much lower, so you need to be able to ignore one and pick up the other. If you mechanically isolate them with rubber mounts and foam and stuff, the direct coupled pulse will be much smaller and easier to ignore.

Another thing to note is that the received pulse will get weaker and weaker with both distance and the smallness of whatever the signal bounces off. The srf04 uses a very clever method to start off with a very low sensitivity and increase it over time to compensate.


All these considerations are why people usually buy a premade unit that simply gives you a digital high as long as it's waiting for the reply so you can just time it and not have to worry about the analog stuff.

see the srf04 schematic on the link I pasted above. You need to feed 40khz into one, then amplify the other and listen for a reply. The time between transmission and reception gives you distance, based on speed of sound.

see also http://www.robot-electronics.co.uk/htm/srf04tech.htm for details of a very popular ranger

The current through a phototransistor depends on the amount of light falling on it. I use them on my robot's analog ports, and with a 47k pullup to +5v, they read 255 in darkness, <3 in full sun, and usefully different values in between, usually around 130 under the compact fluoro in my room and 160-170 under the incandescents in the lounge room.

I hooked up a bunch of ultrabright (16candela) red leds, and I use the difference in reading between leds on and leds off to detect obstacles. This way, ambient light is completely removed from the picture unless it's saturating the sensor.

I prefer phototransistors. They're cheaper, have more gain and are much faster.

That project seems to use bizarre values like 14.7456MHz or 18.4320MHz. You need to change values if your crystal doesn't match the one its code is written for.

atmega168 datasheet says that error at 115200 baud is a bit high with 16MHz crystal, probably better off with 38400 although then you can't use it with avrstudio which will only use 115200. avrdude should be fine with whatever though