Hello,

I'm looking for some very general suggestions and tips on possible ways to sample a set of digital outputs (that form a binary word) at reasonably high rates (100 kS/s +) and pass that data on to "the computer" do some further processing in e.g. LabVIEW or Matlab. Sorry for the vague description, but I'm at a very early stage of thinking about it and am looking for some suggestions on possible ways to implement this before I get ahead of myself.

Lets say I have 4 digital output pins which will output a 4-bit binary word that I'm interested in. I want to sample all 4 pins simultaneously to read the 4-bit word, and sample it at a fairly high rate (100 kS/s+) and then send the samples to software on the PC. I could use an Arduino, for example, but I understand that the "DigitalRead" command is relatively slow and wouldn't work at the 100 kS/s + rates I'm looking for.

I'm happy to pick things up myself, but I'm just looking for a few suggested starting points, so would be happy to hear and ideas.

Thanks!

 

Sampling the digital outputs at 100k isn't a problem for the Arduino or PIC or most any uC. They can read an 8 bit port in one hit. The problem is the PC end. The PC won't do RS232 fast enough, so maybe USB, Bluetooth or WiFi would do the job. If the PC is running windows, this is not a real time OS, the problem being that every so often the PC is going to forget your samples and go and do more exciting for a while. You will need hardware that can buffer the samples for long enough for the PC to catch up.

 

How long do you have to read for, and does the PC have to receive the reads in real-time? If you only need to read for a short period and there can be some delay between the read and the data arriving at the PC then you can buffer the reads on the micro controller and send the buffered data to the PC via serial.

If you need to read continuously or you need real-time data acquisition on the PC side then serial probably won't work. If you need to sample continuously BUT you don't have to get the data to the PC in real-time, then you may still be able to use serial if you add compression, though I don't know what that would do to the sample rate or the sample time consistency of the micro controller.

 

Thanks both for you inputs.

A few questions/responses to your comments:

"They can read an 8 bit port in one hit." - can you clarify what you mean by an 8 bit port? Do you mean 8 pins (each representing one bit), or reading a single pin with 8 bit resolution? I'm looking to do the former: read in the value (0 or 1) of "X" pins simultaneously (or at least read them all sequentially during a particular sampling period).

"How long do you have to read for, and does the PC have to receive the reads in real-time? " - I'm looking to read continuously, but in principle the PC doesn't need to receive the reads in real time. Buffering is fine. A couple of questions regarding that:

• The calculations I want to do is essentially take the value of the latest sample and subtract the value of the previous sample. Would this be more efficient to do e.g. on the microcontroller before sending the results to the PC, or buffer all the samples and then send on to the PC to perform the subtraction? I assume it would be the former as that seems like it would involve less data having to be transferred.
• " You will need hardware that can buffer the samples for long enough for the PC to catch up." - is this easily done on a microcontroller?

Thanks again!

 

can you clarify what you mean by an 8 bit port?

The I/O pins on 8-bit uC are generally arranged in groups of eight and a single instruction will read the digital values on one of those ports into a byte within the uC.

The calculations I want to do is essentially take the value of the latest sample and subtract the value of the previous sample.

The result of subtracting one byte from another is still a byte, so it is not going to reduce the amount of data to be transmitted.
[EDIT] Actually it is bigger after the subtraction. How do you represent -255 in a single byte?

" You will need hardware that can buffer the samples for long enough for the PC to catch up." - is this easily done on a microcontroller?

Yes, but the size of the buffer will be fairly limited (though you could add an external ram chip as extra buffer space).

 

Thanks both for you inputs.

• The calculations I want to do is essentially take the value of the latest sample and subtract the value of the previous sample. Would this be more efficient to do e.g. on the microcontroller before sending the results to the PC, or buffer all the samples and then send on to the PC to perform the subtraction? I assume it would be the former as that seems like it would involve less data having to be transferred.

• 
  
  I agree to do all the math in the PC given the scenario you describe Also, the range for a single byte of signed 8-bit numbers is only 127 to -128; whereas, a single byte of unsigned is 0 to 255.

John

 

"The result of subtracting one byte from another is still a byte, so it is not going to reduce the amount of data to be transmitted."

I thought that this would reduce the amount of data to be transmitted since I would only need to transmit the result of the calculation and not the two inputs, i.e. A - B = C; if the calculation is done on-chip I only need to transmit C, instead of A and B. I understand your point though.

Thanks everyone for your inputs. At least now I have some ideas of sensible places to start.

 

"The result of subtracting one byte from another is still a byte, so it is not going to reduce the amount of data to be transmitted."

I thought that this would reduce the amount of data to be transmitted since I would only need to transmit the result of the calculation and not the two inputs, i.e. A - B = C; if the calculation is done on-chip I only need to transmit C, instead of A and B. I understand your point though.

Thanks everyone for your inputs. At least now I have some ideas of sensible places to start.

Let's say you have two binary values, 13 (new) and 213 (old). That is two bytes to transmit. Now you subtract 213 from 13 (i.e., new minus old) and get -200. That is still two bytes to transmit. Whatever protocol you use, you need to anticipate that result. That is what was said above in posts #5 and #6. If you don't consider sign, then you won't know whether the value increased or decreased.

There are 9-bit protocols for serial communication. I am assuming you are dealing with an 8-bit micro.

John

 

I thought that this would reduce the amount of data to be transmitted since I would only need to transmit the result of the calculation and not the two inputs, i.e. A - B = C; if the calculation is done on-chip I only need to transmit C, instead of A and B. I understand your point though.

But then when you get sample D you need to have kept B, do the subtraction and transmit B-D. Each new sample generates another number to be transmitted.

 

Ok, thanks once again. I'll bear all that in mind. I'm sure it'll take a bit of trial and error to find the solution that seems to work best for my application.