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?

belion@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

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.

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

Teleoperate a roving mobile robot from the web:
http://www.swampgas.com/robotics/rover.html

Coauthor with Dennis Clark of "Building Robot Drive Trains".
Buy several copies today!

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

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.

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.

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.

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:
http://www.swampgas.com/robotics/rover.html

Coauthor with Dennis Clark of "Building Robot Drive Trains".
Buy several copies today!

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:
http://www.swampgas.com/robotics/rover.html

Coauthor with Dennis Clark of "Building Robot Drive Trains".
Buy several copies today!

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.

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

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.

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/

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.