sensors - pc interface

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.

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?

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 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.

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.

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.

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?

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.

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.

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.

My favorite board for this is the MAVRIC-IIB from BDMicro

It has both RS232 and RS485 ports and enough I/O to deal with most robotics needs.

-- D. Jay Newman

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:

And what about a USB-I2C board like this one?

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?

Also look at

$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.

Too kewl!...that'll come in right handy for a project i'm doing with some production machines

You are right, 90 kbps is too low speed. I have found another similar solution:

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.

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.

Bah! Scatch that last post -- I see what you're talking about.

I th> Not necessarily. You can just put them all on one serial bus. PICs,

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.

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.