vivian giuliomoro heya, those dev boards arrive tomorrow but before i change there address's i wanted to ask about those hexadecimal values, im using 6 trill bars and a square as well, the trill hexadecimals are in the 0x20's as is the dev boards, is this a potential prob?
giuliomoro vivian I should have mentioned this elsewhere: you should be using two different I2C busses: one for all the Trills and one for all the encoder boards. This will not only avoid address conflicts, but it will also allow to improve the overall bandwidth.
vivian @giuliomoro everything working well, a cacophony of sine, the value of each encoder on read out was perhaps noteworthy as the values increased by 2 per encoder click, not as smooth as past readouts, otherwise great
giuliomoro vivian values increased by 2 per encoder click, hmmm ... that's weird. I couldn't get that behaviour. Is this the new consistent behaviour with two boards connected?
vivian giuliomoro 0x25 works very smooth but still has a few moments jitteriness. these encoder boards will be increasing and decreasing values by 0.1 per encoder click so fingers crossed its not too problematic in the long term.
giuliomoro In what order did you put in the addresses in the code here? std::vector<uint8_t> i2cAddresses = { ... };
giuliomoro can you try to swap the last two, e.g.: 0x23, 0x25, 0x27, And see if the behaviour of 0x27 and 0x25 also swap? In other words, I am trying to figure out if the last one is always the one that performs best.
vivian giuliomoro so this time there was some minimal improvement on all boards when turning quite slowly however, yes now the last board 0x27 is performing very well
giuliomoro Does it happen also with only two boards that the last one in the list behaves better than the first one?