Just an update on debugging (with the help of okyeron) the issues i posted few days ago. I had enabled master mode in frimware (but not added pull up resistors! ) This doesn’t just stop the 16n outputting correct i2c but it also hangs. I had two 16n on test and one would run for 30 seconds or so, the other immediate crash - further confusion, guess internal teensy tolerances?)
The other point to note is that if programmed as master, it needs to be powered up after the slave has been powered.
In my setup i have er-301/JF/Ansible on a i2c bus and out to a 3.5mm stereo jack. 4k7’s soldered onto the back of the ansible. These three (and i happy together)
As there is potential (excepting port conflicts) for two masters to work on the same i populated the 16n with reasonably large 10k resistors (figuring the load in parallel with 4k7 is still reasonable)
With everything powered dow i connect the 3.5mm cable (1m in my case) power up 301 then the 16n . (sometimes the 16n needs to be cycled twice to work)
Everything works together - or separately. PolyES puts out on SC.CV1-8 and 17-24, 16n puts out sc.cv1-16
If using faders 1-8 it can cause issues but faders 9-16 are fine. If the16n could be changed to output 32-47 (like its midi channels) or think scanner_darkley mentioned alt firmware for PolyES then there would be harmony all round
Found an interesting read here, though not sure the speed the i2c is running- i have a 1m cable running reliably here alongside ansible/poly
Heres a good read on i2s resistor/ speed considerations, cable capacitance etc.
http://www.ti.com/lit/an/slva689/slva689.pdf