evt pin with craft

lokki

i built a custom controller with craft, based on copper wires (a bit like frets) inserted into a nice piece of wood.
everything works perfectly and i use each pin as a "on/off" trigger for notes (midi at the moment). i use craft with a teensy and would like to read data only when the evt pin is high.

i noticed that when i let go of my "frets" and no sensor is touched anymore the evt pin goes low before all sensors send a "zero" (or small value) which results in not ideal behaviour when retriggering the same sensor quickly. some hits are then missed.

wouldn't it be better to send all zeroes before the evt pin goes low?

for now i reset a timer when the evt pin is high, so that i can read data in even after it goes low.

something like this:

if (digitalRead(2)) {
readTime = 0;
 // trillSensor.requestRawData();
}

if (readTime < 150) {
  trillSensor.requestRawData();
}

readTime being an elapsedMillis variable and digitalRead(2), the PIN where the EVT out of craft is connected.

giuliomoro

lokki i use craft with a teensy and would like to read data only when the evt pin is high.

Ah! Someone's using the event pin, at last! That's how we're going to uncover the bugs!

lokki i noticed that when i let go of my "frets" and no sensor is touched anymore the evt pin goes low before all sensors send a "zero" (or small value)

This is expected behaviour as far as I can tell from the firmware code and comments. In DIFF mode, the event pin is set only when new data is available and at least one pad reads non-zero: https://github.com/BelaPlatform/Trill/blob/master/firmware/common/trill-main.h#L428-L433

lokki which results in not ideal behaviour when retriggering the same sensor quickly. some hits are then missed.

I am not sure how this happens: if you do touch any pad after all pads have been released, the EVT pin should be triggered again.

lokki wouldn't it be better to send all zeroes before the evt pin goes low?

If I understand correctly, you would want the event pin to be toggled also when bActivityDetected becomes 0 for the first time, is that right? It seems like a reasonable behaviour, but would that actually fix the issue you are having?

lokki

giuliomoro I am not sure how this happens: if you do touch any pad after all pads have been released, the EVT pin should be triggered again.

right, but if it is the same pad as before, it never gets a reset in my code, since note off is relying on a zero (low) value of the sensor.

lokki

well, with this code:

/*
   ____  _____ _        _
   | __ )| ____| |      / \
   |  _ \|  _| | |     / _ \
   | |_) | |___| |___ / ___ \
   |____/|_____|_____/_/   \_\
http://bela.io

\example craft-print

Trill Craft Print
=================

This is an example of how to communicate with the Trill Craft
sensor using the Trill Arduino library.

The sensor is set to Differential mode and readings from each of the
capacitive connections on the sensor ar eprinted to the serial port.
 */

#include <Trill.h>
byte notes[8] = {60,63,65,67,68,71,72,74};
byte pattern[30] = {notes[0],notes[1], notes[2], notes[3], notes[4], notes[5], notes[6], notes[7],
notes[3] +12,notes[0] +12, notes[2] +12, notes[1] +12, notes[4] +12, notes[5] +12, notes[6] +12, notes[7] +12,
notes[0] +24,notes[1] +24, notes[2] +24, notes[3] +24, notes[4] +24, notes[5] +24, notes[6] +24, notes[7] +24,
notes[0] +36,notes[1] +36, notes[2], notes[3]+36, notes[4], notes[5] +36
};
int touch_val[30];
byte pin_order[30] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29};
bool pin_touched[30];
Trill trillSensor; // for Trill Craft
elapsedMillis readTime;
void setup() {
  pinMode(2, INPUT);
 
	// put your setup code here, to run once:
	Serial.begin(115200);
	int ret = trillSensor.setup(Trill::TRILL_CRAFT);
	if(ret != 0) {
		Serial.println("failed to initialise trillSensor");
		Serial.print("Error code: ");
		Serial.println(ret);    
	}
     trillSensor.setScanSettings(0, 9);
    delay(Trill::interCommandDelay);
  //  trillSensor.setPrescaler(1);
  //  delay(Trill::interCommandDelay);
    trillSensor.setMode(Trill::DIFF);
    delay(Trill::interCommandDelay);
   trillSensor.setNoiseThreshold(40);
  delay(Trill::interCommandDelay);
    trillSensor.setAutoScanInterval(1);
    delay(Trill::interCommandDelay);
     
    

    Serial.println("Setup Complete");
}

void loop() {
	// put your main code here, to run repeatedly:
//	delay(1);

if (digitalRead(2)) {
readTime = 0;
 // trillSensor.requestRawData();
}

if (readTime < 150) {
  trillSensor.requestRawData();
}
  
//} 

	while(trillSensor.rawDataAvailable() > 0) {

  for (int i = 0; i < 30; i++) {
  touch_val[i] = trillSensor.rawDataRead();
 
  if (!pin_touched[i] && (touch_val[i] > 50)) {
    pin_touched[i] = 1;
    usbMIDI.sendNoteOn(pattern[i],127,1);
   // Serial.println(i);
  //  Serial.println(touch_val[i]);
  //  Serial.println();
  }
  if (pin_touched[i] && (touch_val[i] < 40)) {
    pin_touched[i] = 0;
    usbMIDI.sendNoteOff(pattern[i],0,1); 
  }
  }
	}
}

it all works as expected, i can retrigger the same sensor as fast as my finger goes, while with this part:

if (digitalRead(2)) {
readTime = 0;
 // trillSensor.requestRawData();
}

if (readTime < 150) {
  trillSensor.requestRawData();
}

changed to:

if (digitalRead(2)) {
  trillSensor.requestRawData();
}

retriggers of the same note do not happen very consistently.

probably my example is not coded in the best way possible, but i still think it is a reasonable approach for a sensor board to output all zeroes when not touched. if that would happen before the EVT pin goes low, this would solve my "problem" i guess, yes.

nobody uses the EVT pin? i think it will be crucial for my design, since i plan to incorporate this into a teensy 3.6 project and want to avoid polling the sensor all the time (so i can do other things in between faster)

giuliomoro

lokki nobody uses the EVT pin?

either that or no one has found anything to complain about till now 🙂 I guess in many cases it's easier to keep reading the sensor. It only becomes crucial to use the EVT pin when you start having several Trill devices and reading them all all the time slows you down signficantly.

lokki right, but if it is the same pad as before, it never gets a reset in my code, since note off is relying on a zero (low) value of the sensor.

got it

lokki probably my example is not coded in the best way possible, but i still think it is a reasonable approach for a sensor board to output all zeroes when not touched.

The board does output all zeros, it's you who are not asking for that reading!

lokki it all works as expected, i can retrigger the same sensor as fast as my finger goes,

That's similar to what I would have suggested. You can probably reduce 150 down to something like 20 (assuming that's milliseconds) and still get all the retriggerings: after all you just need one reading after the last time the event pin toggled and the scan period. The scan period is just a few hundreds microseconds more than the acquisition time, which is detailed in this table, so for the default 12 bits and Ultra Fast scanning, you get for the 30 sensors on Trill Craft: 205us * 30 = 6.15ms.

Thinking about it again, I think the current behaviour is the desired behaviour, too: by not toggling the event pin when all pads are 0, you get to save yourself transferring 60 bytes all set to 0. Again, with several sensors connected where you are trying to minimise the bus usage, that is the most efficient solution. It's up to your software to know that after one scan period has gone by without the event pin being raised, all sensor readings from that device are 0 until the next time the event pin gets high.

lokki

giuliomoro You can probably reduce 150 down to something like 20 (assuming that's milliseconds)

yeah that is milliseconds, and i thought so too. but unfortunately it does not work reliably. 150 is the lowest i could go without retriggering problems. don't know why...

is there anything wrong with the setup settings?

 trillSensor.setScanSettings(0, 9);
    delay(Trill::interCommandDelay);
  //  trillSensor.setPrescaler(1);
  //  delay(Trill::interCommandDelay);
    trillSensor.setMode(Trill::DIFF);
    delay(Trill::interCommandDelay);
   trillSensor.setNoiseThreshold(40);
  delay(Trill::interCommandDelay);
    trillSensor.setAutoScanInterval(1);
    delay(Trill::interCommandDelay);

EDIT: there is... the threshold setting has to be much lower of course, it dates from a pre 9 bit setup :-), with a lower value it works as expected. great.

giuliomoro

lokki EDIT: there is... the threshold setting has to be much lower of course, it dates from a pre 9 bit setup :-), with a lower value it works as expected. great.

hmm not sure why the threshold would affect the timing behaviour of your code ... but glad you got it working.

lokki

i think if the threshold is too high (higher then my "off" value in the code) trill never sends the lower values if they are non zero?

anyways, experimenting further, what is the default prescaler value on craft? i could not find that info in the docs.

giuliomoro

It's wahtever the default prescaler value is in the psoc CSD_ library (possibly 1?). When using the Linux library this is explicitly set to 1 at startup https://github.com/BelaPlatform/Bela/blob/master/libraries/Trill/Trill.cpp#L63 , but ultimate the user is expected to override it especially on Craft, as the definition of a reasonable value there depends a lot on the geometry and size of the sensing pads and cables.