>www.voti.nl comes to mind
Thanks!

>If you are in fact a complete neophyte, I would suggest you abandon
>USB PICs right now.  If you really want USB, you can use a
>USB-to-serial bridge from FTDI, but I think RS-232 might be more
>appropriate.

Already purchased a serial->USB! My plan was to go serial first, and then 
revise the software to go straight to USB.

>The other think you might do is buy John Peatman's PIC book.  I forget
>the title, but the newer one is the one to go for.  It covers the
>18F452.

Will do.

>Questions you need to answer:
>1.  Do you want to be able to vary the sampling rate?

No. I didn't even think this was possible without reprogramming. Will 
definitely consider it as a possible upgrade, but initially I just want 
fixed (but not necessarily equal) sampling rates.

>2.  How many channels need to be sampled?
Answered below.

>3.  Does data need to come back constantly, or is it enough to capture
>data in a buffer and send it at a predetermined time?
See below.

>4.  What resolution do you need on the data (huge huge consideration,
>affects everything else)?

Anywhere between the standard 8-bit or 10-bit A/Ds is fine.

>5.  What are you going to "catch" this data with on the PC?
I'm still trying to figure out the best way to do this, but for the moment I 
was thinking a Perl script/C++ program; see below.

Below: [I'm praticing my "GOTO" instructions... :)]

There are two projects I'm trying to put together. Project 1 is an 
electrocardiogram, Project 2 is a car DAQ system.

Project 1:
4 channels, all sampling at 250-300Hz, dump the data through serial onto a 
PC, which records the values in a timestamped fashion so they can be 
synchronized with other eventual peripherals (eg video). I already have the 
analog amp side set up and working.

Project 2:
Easily 10 channels, initially A/D and maybe timers to count pulses for tach 
(I'm following the other thread on this). Eventually, add more A/D channels, 
a couple of D/A, some PWM stuff. All data is stored on an onboard PC 
(including, eventually, video). Thus, also has to be kept timestamped for 
eventual synch. Using multiple PICs to delegate is probable.

With this in mind:

>Does data need to come back constantly, or is it enough to capture
>data in a buffer and send it at a predetermined time?

Project 1 needs as constant feed as possible, for project 2 a refresh rate 
(of data to the PC) of ~20-50Hz would be sufficient (if displayed, they eye 
wouldn't see the data 'frames').

>5.  What are you going to "catch" this data with on the PC?
I'm considering dumping the data through serial. A program would catch the 
data and either make a table (which can be looked up by the display 
software), or write it to disk and make it available on a socket for a 
"front end" to plug into. Obviously, I'm still unsure of the limitations and 
advantages of either method, but just getting data showing up on the PC 
serial port would make me happy, and is all I'm trying to do at the moment.

My knowledge is still limited, but for the moment I'm thinking of doing 
something like this:

Start
Poll ch1
Write data
Poll ch2
write data
....
Send all data
Reset WDT.
Go back to start.

But I could have variable sampling rate by simple propotions, eg sample 
1,2,3,1,2,1,2,1,2,3.... (sampling ch3 at 1/4Hz of ch1)

And I was thinking that if the A/D conversion is slow enough relative to a 
~10-16 bit serial transfer, I could: start ch2; transmit data from ch1, 
record ch2, start ch3, transmit ch2, etc.

The questions I'm trying to answer is how the PC knows from which channel is 
a particular data packet from, and wheter the time stamp should just be left 
to the PC to do as each packet comes in rather than trying to synchronize 
multiple RTCs....

Thanks for the help!
Alex


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist