sensors - pc interface

Hello,
I know that maybe this will be a newbie question, but anyway here it goes. I want to get data from ultrasound and infrared sensors in a
standard PC. I know that one way of connecting them is by using the parallel port, but this is not a good aproach for me. What are the mostly used solutions? Maybe using a board like OOPic, Basic Stamp or something similar?
Thank you for your help
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

The choices are pretty much fixed: serial, parallel, USB, IEEE1394, TCP, CF, IR, and possibly some others. SCSI, PCI, or even SATA if you want or have a need. It would be easier to start with the needs.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
The problem is that sensor's output usually is an analog signal (voltage), so it is not possible to directly use standard PC ports. Maybe a data acquisition board? Has someone worked with any of these?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@gmail.com writes:

Are you any good at electronics and writing USB device code ?
The way that I would solve that problem would be to use a A/D converter attached to something like a USB microcontroller like the HC08 JB8.
Alternatively, you can get ultrasonic sensors with a I2C interface (Devantech <http://www.robot-electronics.co.uk/ make one) and you can either control that directly (taking account of any voltage level issues) or use a microcontroller to offload I2C processing from the PC.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: The Standard Oil Company of the 21st century
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
And what about data acquisition boards? Wouldn't it be easier to connect all sensors to a data acquisition board? Of course, I suppose that this option would requiere doing all the processing in the PC.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I have used a couple DAQ boards. They do a very good job, but be warned that they're also very expensive. All the ones I've used were at least $5K. A couple solutions I'd advise you to look at:
interfacing sensors to microcontroller (I'm a fan of AVRs myself), then connecting microcontroller to serial port on computer
using game port (it has multiple analog inputs)
Both of these would be much more reasonable in cost.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Can you connect multiple microcontrollers to one serial port? I mean, imagine that you can connect up to 4 sensors to one microcontroller, and the connect this microcontroller to the PC using the serial port. What if you had 12 sensors? Would you need 3 serial ports in your PC?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@gmail.com wrote:

If you need to do this, then the easiest approach is to use a single microcontroller as a "dispatcher" for data back and forth on the PC serial port, and have the microcontroller talk to other microcontrollers using a shared bus (485, I2C, etc).
Having said that, if you're just talking 12 or so sensors you probably don't need multiple microcontrollers. Many will have plenty of IO on the chip itself, or you can do a bit of multiplexing if need be.
--
(Replies: cleanse my address of the Mark of the Beast!)

Teleoperate a roving mobile robot from the web:
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Not necessarily. You can just put them all on one serial bus. PICs, 8051s and probably a lot more micros support a serial communication mode where the parity bit is used as an address flag and can be used to select a microprocessor to talk to. You can also do it entirely in software. All that is needed is some kind of arbitration scheme to make sure that more than one chip doesn't talk at the same time and a single ttl chip to logical-or the transmit lines.
chris
The Artist Formerly Known as Kap'n Salty wrote:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
And what about a USB-I2C board like this one? http://www.devasys.com/usbi2cio.htm I think that this can be a good approach for interfacing with a net of I2C-enabled sensors. What do you think about it? Has someone got any experience with this kind of boards?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Also look at http://www.dontronics.com/micro-usb.html. $21, very small footprint, and emulates a COM port on the PC side, making the client application communication dead simple. Communication between the uC and the interface device is async serial, possibly limiting throughput.
I2C is a half-duplex, two wire, synchronous serial protocol, supporting up to 400 kbps. The DevaSys device is a 90 kbps I2C bus master, thus forcing your device bus to the slower speed. While I2C is potentially much faster than full-duplex async, the DevaSys uses only a fraction of that, and thus also only a very part of the available USB bandwidth. I expect 57.6 kbaud async between a PIC and the Dontronics device will do about as well with far less complication and expense. 115 kbaud async will beat it handily.
SPI is another well supported synchronous serial protocol. It's faster, full duplex on four wires, up to 5 MHz clock on a PIC and possibly higher on other chips. This gets you much closer to using all the available USB full speed bus bandwidth.
You still didn't say what throughput you're looking for.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

You are right, 90 kbps is too low speed. I have found another similar solution: http://www.xdimax.com/u2c/u2c11.html This one can be used at 400 kbps, which is more acceptable. I was planning to start with 8 sonar and 8 IR sensors, but I want to keep it open in case I decide to add more sensors or include other type of sensors. The thing is that I wanted to avoid using PIC's or microcontrollers, and do all the control and processing in the PC. I have never programmed a microcontroller, so I feel much more comfortable programming and debugging in my PC. But I have just realized that at least I have to use microcontrollers for IR sensors, as I have not found any with I2C output.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

It might help to think of PICs as interface devices rather than microcontrollers. The programming involved is not so much programming as such, but more akin to wiring up devices: setting clock rates, enabling peripherals, and selecting options. Certainly, they're capable of more, but the lack of floating point math limits their sophistication and indicates their intended use. Interfacing a few AD samples onto a communication bus comes to mind as a perfect example. I could sell you a device that does precisely that, but you'll find the Microchip logo if you scrape off my label.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Edward C. Kern wrote:

Yes -- but I was assuming a standard RS-232 hardware on a PC, which doesn't normally support this capability (at least as far as I know -- but I've been wrong before).
Which PICs have MSPs that support using the parity bit as an address flag for asynchronous serial data transfer? I'm not familiar with this.

--
(Replies: cleanse my address of the Mark of the Beast!)

Teleoperate a roving mobile robot from the web:
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Bah! Scatch that last post -- I see what you're talking about.
I think I'd still stick with a common bus between controllers, though, as it's a bit more flexible than a mster-slave/star topology. Could be simpler, though for a newbie -- and you're right -- it could be done in software, although if the PC is doing a lot of polling, the slaves end up spending a lot of time servicing interrupts if the chips used don't support ADDEN or the equivalent.
Edward C. Kern wrote:

--
(Replies: cleanse my address of the Mark of the Beast!)

Teleoperate a roving mobile robot from the web:
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

The PIC16F690 has up to 12 10-bit ADC ports and onboard uart in a 20-pin package. The PICkit2 is a $50 development kit and comes with a 16F690, prototype board, programmer, and Windows-based development tools. Order it at Microchip's site.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Mike Young wrote:

Too kewl!...that'll come in right handy for a project i'm doing with some production machines
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
basic stamp is easy to get started with.
install the software on PC, hook the stamp to the serial port.
plug your sensors into the basic stamp, write a few lines of code, see the sensor output on the basic stamp comm window.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@gmail.com wrote:

My favorite board for this is the MAVRIC-IIB from BDMicro http://www.bdmicro.com/
It has both RS232 and RS485 ports and enough I/O to deal with most robotics needs. -- D. Jay Newman http://enerd.ws/robots /
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
D. Jay Newman wrote:

I'd also like to add that this board comes with everything you need to do development in a Linux environment, nicely laid out for Linux newbies like me.
--
Mike Ross

Instructions said Win98 or better, so I used Linux.
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.