Digital sampler?

I want to do a fast sampling of a digital pin with a given freq between 100Hz and 100KHz (or the max of the IMP what I don’t know).

Right now I would have a few choices but all of them have setbacks:

  1. Just do a sampling in a while() but I can’t measure exactly (or not even close) the time for N samples to know the sampling freq since time() is only second accurate - I would need a tickcount or something else for that. Is there anything similiar in squirrel for a higher resolution time measurement?

  2. Do sampling in a while() cycle and use a 1 callback to interrupt it - this is would say how many sampling was done in 1sec, hence would give the sampling freq. As far as I know this is not possible since squirrel code will not interrupt another squirrel code. Right?

  3. Using the newly introduced ADC sampler. The setback here is that eats too many data - 16 bit for every sample, while 1 bit would be enough. And I don’t know the maximum sampling freq either for it - the doc talks about minimum only …
    Can anyone tell me what is the max sampling rate here? And can a new request to be filled for 8 bit (or even 1 bit) adc possibility for the sampler?

Coming from http://forums.electricimp.com/discussion/239/onewire-support/p1 I’m also very interested to know the specs of the pin API.

If you’re just trying to measure the input frequency, that’s what pin1.configure(PULSE_COUNTER) is for.

The next release will have millisecond and microsecond free-running timers which would help you with #1.

The maximum hardware sampling rate is about 2MHz, but we don’t mention it because that’s not the limiting factor: you can’t deal with the data that fast in Squirrel. How fast you can deal with it depends on how much processing you’re performing: a simple threshold test is about as straightforward as you can get, and then you’ve effectively got 1-bit data. What is it you’re actually trying to extract from this signal?

Peter

Data analyzer for slow signals, max 100KHz but I would be happy if it would work for 10Khz signals too. It’s a “debug mode” for some kind of one wire protocol.

Sorry to be some kind of hyjacking this discussion, but I guess that I’ve similar problem. Using the following squirrel-code
`
class Sampler {
rawData = [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0];

// reading 40 state-changes analyzing the duration of highs/lows on the wire
function sample() {
for (local i=0; i<40; i++) {
rawData[i] = 0;
while(hardware.pin5.read() == state) {
rawData[i]++;
//imp.sleep(0.000001);

    if (rawData[i] > 10000) {
      return -2; // timeout
    }
  }
state = hardware.pin5.read();

}

function dump() {
for (local i=0;i<40;i++) {
server.log(format("bit %d = %d ",i, this.rawData[i]));
}
}
}

sampler = Sampler();
sampler.sample();
sampler.dump();

`

Produces the following output:
Tuesday, December 04, 2012 16:27:47: bit 0 = 2
Tuesday, December 04, 2012 16:27:47: bit 1 = 0
Tuesday, December 04, 2012 16:27:47: bit 2 = 0
Tuesday, December 04, 2012 16:27:47: bit 3 = 2
Tuesday, December 04, 2012 16:27:47: bit 4 = 0
Tuesday, December 04, 2012 16:27:47: bit 5 = 3
Tuesday, December 04, 2012 16:27:47: bit 6 = 0
Tuesday, December 04, 2012 16:27:47: bit 7 = 0
Tuesday, December 04, 2012 16:27:47: bit 8 = 2
Tuesday, December 04, 2012 16:27:47: bit 9 = 0
Tuesday, December 04, 2012 16:27:47: bit 10 = 1
Tuesday, December 04, 2012 16:27:47: bit 11 = 2
Tuesday, December 04, 2012 16:27:47: bit 12 = 1
Tuesday, December 04, 2012 16:27:47: bit 13 = 0
Tuesday, December 04, 2012 16:27:47: bit 14 = 1
Tuesday, December 04, 2012 16:27:47: bit 15 = 0
Tuesday, December 04, 2012 16:27:47: bit 16 = 0
Tuesday, December 04, 2012 16:27:47: bit 17 = 0
Tuesday, December 04, 2012 16:27:47: bit 18 = 0
Tuesday, December 04, 2012 16:27:47: bit 19 = 0
Tuesday, December 04, 2012 16:27:47: bit 20 = 0
Tuesday, December 04, 2012 16:27:47: bit 21 = 0
Tuesday, December 04, 2012 16:27:47: bit 22 = 0
Tuesday, December 04, 2012 16:27:47: bit 23 = 0
Tuesday, December 04, 2012 16:27:47: bit 24 = 0
Tuesday, December 04, 2012 16:27:47: bit 25 = 0
Tuesday, December 04, 2012 16:27:47: bit 26 = 0
Tuesday, December 04, 2012 16:27:47: bit 27 = 0
Tuesday, December 04, 2012 16:27:47: bit 28 = 0
Tuesday, December 04, 2012 16:27:47: bit 29 = 10001
Tuesday, December 04, 2012 16:27:47: bit 30 = 10001
Tuesday, December 04, 2012 16:27:47: bit 31 = 10001
Tuesday, December 04, 2012 16:27:47: bit 32 = 0
Tuesday, December 04, 2012 16:27:47: bit 33 = 0
Tuesday, December 04, 2012 16:27:47: bit 34 = 0
Tuesday, December 04, 2012 16:27:47: bit 35 = 0
Tuesday, December 04, 2012 16:27:47: bit 36 = 0
Tuesday, December 04, 2012 16:27:47: bit 37 = 0
Tuesday, December 04, 2012 16:27:47: bit 38 = 0
Tuesday, December 04, 2012 16:27:47: bit 39 = 0

Expected higher values for each sample (=duration of high/lows) @2MHz

Well this could be a half solution for me but it’s not enough - I would need to get the baudrate as well, not only the shape. And without knowing the time passed I cannot get that value (only approx). I really wait the bitbanging module to see it’s capabilities. Anyway TY for the idea and the code :slight_smile:

You can’t get round that loop at 2MHz in Squirrel. By optimising it a bit – by taking operations out of the loop:
local state = hardware.pin5.read(); local pin = hardware.pin5; local count; for (local i=0; i<40; i++) { count = 0; while(pin.read() == state) { count++; if (count > 10000) { return -2; // timeout } } state = hardware.pin5.read(); rawData[i] = count; }
I can get it to go round at about 12KHz.

Peter

The message really is that we need to figure out what we’re doing about a bitbang driver before input signals like that are really usable with the imp.

Peter

Ok, got it. Looking forward to get bitbang-driver. Thanks for optimizing :slight_smile: