Multiplexer Crosstalk Pure Data

giuliomoro

Can you list everything that's connected to 3.3V now?

gab_i

giuliomoro all 8 10k slide potentiometers. the individual channel values do print but the above following message shows up on the console at times - I've increased the block size and the issue remains

giuliomoro

that error is caused by electromagnetic disturbance somehow affecting the clock data lines. For instance, an electrostatic discharge on the ground or 3v3 lines when touching the device or any connected conductive parts.

Are you reading any values close to 0.82 when a pot is at the maximum? If not, try removing the capelet and connect the pots directly to the Bela analog inputs and attempt this again. If you are not reading values close to 0.82 when the pot is at maximum and using 3.3V as the reference, then there is some other problem, either with the wiring or the bela hw.

gab_i

giuliomoro yes, I read values around ~ 0.83 when the pots are at maximum. but I do get crosstalk drops in all values when two of the eight pots are at minimum for instance.

giuliomoro

gab_i but I do get crossover drops in all values when two of the eight pots are at minimum for instance.

Is that the case only with the multiplexer or even when running without it? I think it's reasonable to expect a small amount of crosstalk between all X.y channels for a given X, especially with long cables.

gab_i

giuliomoro removed the cap, used the analog inputs 1 to 4 and vizualised the data through the IDE's oscilloscope, treating them in two sets groups. crosstalk still occured in both cases, but the above console error occured on one of them..

gab_i

here's the wiring - neighboring channels do crosstalk as well... (green jumper wires --> orange jumper wire --> 3.3v // blue jumper wire to ground / yellow and white jumper wires to MUX channels)

giuliomoro

try getting ground from the analog input header and see if the crosstalk is reduced. Also, I understand that what you are seeing is that signals that are nominally grounded are being "lifted" away from 0. Can you try setting the pots to half way through and see if you see the same amount of crosstalk there?

gab_i

giuliomoro I've done that, it seems to reduce the crosstalk slightly - if one of the pots is halfway up and the others down, then the value of the highest one drops. but the error messages still occasionally occurs, and disconnects the bela... I've changed the sliders around, to see if it had anything to do with a defective one - it might be? whenever it shuts down, I need to remove the jump wire from the 3.3v in order to have the bela properly restarting again and showing up on the IDE. I run the program and then insert the pin to the 3.3v again.

ground on analog input header / 3.3v

giuliomoro

gab_i whenever it shuts down, I need to remove the jump wire from the 3.3v in order to have the bela properly restarting again and showing up on the ID

That's weird. It may be that you have something drawing a lot of current from 3.3V, maybe some dodgy connection on the breadboard? Can you measure the current that comes out of the 3.3V pin? It should, at any time, be 3.3/(10000*numSliders) Ampere.

gab_i

yikes..... rookie mistake. I had inverted the output and 3.3v jumper wires from the sliders to the bela i/o pins, slide potentiometer schematics seem to differ from one another :/ the bela isn't abruptly shutting down anymore. however, all neighboring channels pairs on the mux are crosstalking quite heavily (0.0 and 0.1, 1.0 and 1.1, and so forth). I've had to distribute them even more to bypass this issue - 0.0, 1.0, 2.0 , 3.0 etc. is there another way of avoiding drastic crosstalk between X.y channels for a given X - I have 10 more potentiometers to add.

sorry for the troubles!

giuliomoro

gab_i however, all neighboring channels pairs on the mux are crosstalking quite heavily (0.0 and 0.1, 1.0 and 1.1, and so forth

That's not expected. Is there any more wiring error there to spot?

orenr

@giuliomoro I am experiencing a similar issue with crosstalk on the multiplexer. If I have two piezo trigger inputs anywhere within the same column (0.0, 0.1 ... 0.7), then the trigger of one piezo will register as a trigger of the other.
I have also tried spacing out the piezo inputs within the same column (ie. 0.0 and 0.7), however this hasn't helped.
My wiring is set up:

gab_i

hmm no nothing apparent... I'm getting the following: if any X.1 channel is high then X.0 is lifted (even though it is at its lowest). and don't get any readings from the X.0 channels alone, when all X.1 are at lowest.
I'm running the pd multiplexer example patch, with 16 channels set on the IDE

giuliomoro

I see why it could be an issue with piezos: they have high output impedance and so may not provide enough current to quickly update the voltage at the ADC's input upon switching the multiplexer. But it still it seems weird.
Just to make sure, I'd suggest you plug the analog outs directly into the multiplexer's 0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7 inputs, set them all to a fixed voltage, except for one. That one, make it variable and see if the others are affected by it.
Something like:

[sig~ 0]
|
[dac~ 3] >> connect to input 0.0

[sig~ 0.05]
|
[dac~ 4] >> connect to input 0.1

[sig~ 0.1]
|
[dac~ 5] >> connect to input 0.2

[sig~ 0.15]
|
[dac~ 6] >> connect to input 0.3

[sig~ 0.2]
|
[dac~ 7] >> connect to input 0.4

[sig~ 0.25]
|
[dac~ 8] >> connect to input 0.5

[sig~ 0.3]
|
[dac~ 9] >> connect to input 0.6

Then the last one. Initially make it static:

[sig~ 0.35]
|
[dac~ 10] >> connect to input 0.7

Verify that all the readings from 0.x are static (note: expect some low-amplitude noise and be aware that the input readings will not be exactly what you send to the output, but they'll be approx 4.096/5 * value.

Then make the last one dynamic:

[phasor~ 0.5]
|
[dac~ 10] >> connect to input 0.7.

Does it affect the other readings?

gab_i

fixed voltages

with last one dynamic

analog out 0 - 7 to mux 0.0 - 0.7

giuliomoro

Can you show what you are sending to the dacs ?

gab_i

giuliomoro

A couple of things to keep in mind:

to avoid ambiguity, below I report in angled brackets the channels corresponding to the displayed channels (using analogChannel.muxChannel notation):

mux channel [x. 0 ]: <0.0, 1.0, 2.0 3.0, 4.0, 5.0, 6.0, 7.0>
mux channel [x. 1 ]: <0.1, 1.1, 2.1 3.1, 4.1, 5.1, 6.1, 7.1>

unconnected inputs are a distraction: they are floating and so their value is irrelevant and should be ignored. Given the previous point and the fact that you only have 0.y channels connected, only the first column of each row is to be taken into account: they are <0.0> in the first row and <0.1> in the second row and they should be affected only by [dac~ 3] and [dac~ 4] respectively
however, I don't see the <0.0> and <0.1> being affected by the corresponding dac channels the way I expect it to: expected readings should be 0 and 0.061, so I'd recommend double checking the wiring. If you have pin-to-socket wires, I recommend bypassing the ribbon cable and jumpering directly to the multiplexer inputs. You can also try starting from [sig~ 0.2] for [dac~ 3] and then increase by 0.05 for each.
also try running with 8 multiplexer channels, that will print 8 values and you should look at the first column only (as all the others are disconnected); the values on the first column will be <0.0> on the first row, <0.1> on the second row... <0.7> on the last row

I don't have a multiplexer with me right now but I should get one on Thursday or Friday

giuliomoro

Embarrassingly, I just realised that you may have to update your Bela core code, as it may be broken with the Bela Cape Rev C on the Bela image that is currently shipping.

@gab_i @orenr follow instructions here and try again https://learn.bela.io/using-bela/bela-techniques/updating-bela/#updating-with-the-ide

gab_i

giuliomoro the update solved it ..! 🙂