@tehn [quote=“tehn, post:76, topic:5861”]
i feel that you’re experiencing issues i’m completely unable to replicate-- e-mail info@monome.org and i’ll get you a replacement
[/quote]

I now have two Ansibles with cycles emitting stepped voltages after power cycling the case the first time after upgrading.

It is always smooth immediately after reflashing the firmware until the first power cycle.

It occurs with both modules in two different cases with two different power supplies with every firmware I could reach except one from early december of which I don’t know where I got it from - it is not amongst the ones on github. I think it was a modification of 1.1 that does not have tt remote for cycles and levels yet. So it might be connected to changes made with the further i2c implementation.

I may be stupid but I can’t imagine how this is not a software issue.

However I am wondering too how I am the only one experiencing this.

This is very frustrating.

:neutral_face:

do you have a modular grid page with your setup? i’ve experienced weird weird behavior in the past but in the end i chalked it up to power issues and trying to flash new firmware when the system itself was getting powered via a usb connection.

are you issuing high frequency commends via teletype?

i’ve found things to be stable until I start to try and generate so much ii activity that things start do break down (mind you this is ii commands sent as a rate above normal were the primary purpose is to break things…)

@ngwese I did not use i2c here and the behavior occurs without teletype connected to Ansible.

I don’t see how this could related to power issues as:

  1. I am within the specs, everything else is working good and it occurs in two different cases with different PSU’s.

  2. On first power up after reflashing the firmware everything is right, the problem occurs after the first power cycle then.

  3. The Behavior occured with the last big revision introducing cycles/levels remote around christmas, there was a intermediate stable version before that. When I flash this version everything works okay - it just does not support teletype remote.

Nevertheless I do everything I can to get this finally running:

@Leverkusen I completely understand you are trying to get to the bottom of the behavior you are seeing.

My line of questions was largely just trying to ask some of the more basic questions that may have been assumed up to this point. Power in eurorack land does seem to be a much more finicky compared to the large 5U system I built just due to the myriad of digital/analog devices used along with stuff like i2c busses and USB. So far when I’ve run into hard to reproduce behavior I’ve often felt that it was power related (in my own system).

On seeing your setup I can now better understand how are systems might differ - for instance I don’t have a switch module. As of now I have been plugging in arc/grid devices directly; could that have an effect, maybe maybe not. If your problems seem to be related to values getting written to flash before powering off the module then things acting weird on power up that might be another clue. I have (unintentionally) managed to get anisble (and other modules) in weird states while developing when the onboard flash was written to in “brownout” power conditions (like +5V coming from the USB connection keeping them partly powered). Another possibility is if you are saving a preset then immediately turning off the power while testing it could be that the flash writing hasn’t finished yet. Again I’m partly guessing here in the hopes that some clue might be uncovered.


Update: And I see that there was a mode initialization bug which just got fixed. Hopefully that was it.

i also think that some of the i2c issues we’re seeing might be power related. testing TXo/TXi/ansible/TT combo i was still able to get it to lock in one of my cases, but after moving it to a different case it seems stable so far. i’m completely out of my depth when it comes to the hardware side of things, but what @Galapagoose said about the pull up resistor values above suggests to me that power situation might play a role as well?

1 Like

I’m still basically a neophyte when it comes to hardware stuff like this as well. My system has lots of headroom power wise (one 4ms Row 40 per 104HP row) largely as a byproduct of going with the 4ms modular rows…

…if nothing else this kind of thing certainly offers the opportunity to learn!

1 Like

Yes, I think that was it. Eventually it was reproducable, which was basically what I tried to make clear with my post.

I know well that there are power issues within eurorack systems which are often underestimated, that’s the reason I have two cases with different PSU (linear and switched). And I appreciate the collective striving for a solution. (in 5U I experience capacity issues with all those vintage designs btw…)

But on the other hand it’s often a kind of final argument that prevents going deeper on the ground. As in this case eventually the issue was pretty easy to reproduce and then fixed.

I tend to feel a bit lost when I seemingly am the only one experiencing those bugs while everyone else seems to be amazed by new features and I am like: yes, great - but it does not work here. I do not understand how this could be possible then and I am afraid my posts read a bit negative then but that’s not what I feel about this stuff. I am just trying hard to get attention…

It’s more that I really want to work with my monome stuff because it is great, visionary and beautiful but I do not dare to program some patterns, scales and presets f.i. as long as I see there are some serious bugs and there probably will be another update to fix it and all my stuff is lost. Would be different if it was just about new feature updates you could skip for now.

All this could be so great and I would love to have it stable in the sense of everything working as it should before new features are introduced that kick up a breeze in the firmware again and it takes months again to understand which new feature introduced it and get it all working. Without the teletype integration and pattern programming Ansible/Arc is just a quad LFO and offset generator, with all current features reliably working it can be so much more. Same with Earthsea.

So, thank you very much to all of you working on this and dedicating time, work and knowledge to it. I do appreciate it very much!

1 Like

There’s a recent article from Hackaday about long runs of I2C:

Maybe not relevant to any specific problem here, but certainly helpful for understanding what’s involved in I2C communications.

6 Likes

Thanks for this! To cut directly to the chase, anything less than ~950ohms is out of spec for i2c and will exceed the specified 3mA current sink limit. While that’s likely not an issue with our small eco-system, it seems unwise to go off-spec when it’s an open protocol.

4 Likes

AWESOME! Thanks so much for sharing!!


I’ve done some peeking around and haven’t found the easy setting in the TWI API to turn on internal pull-ups on the Teletype as @Galapagoose suggested above. I have found some anecdotal forum posts that the AVR processor may (like the Teensy) have pull-ups that are “out of spec” with i2c and shouldn’t be used. Am I missing something?

might be worth replacing the TT resistors (which are 10k) with 2.2k or 4.7k to see if that fixes it immediately.

this is, of course, not a great solution. but 10k is at the edge of spec, it should be lower.

to enable a pull up in with libavr, put this in init_teletype.c

gpio_enable_pin_pull_up(PA09);
gpio_enable_pin_pull_up(PA10);

… i think. untested. please let me know.

Based on the reference manual I think the internal pull-ups on the AVR are around ~80-150 kOhm, so that’s probably worse not better.

so a proper pull-up resistor value depends on the number of devices connected, correct? just wondering how would it work in practice. is it possible to build some sort of a “smart” i2c expander that would adjust it automatically?

You could always switch between a number of resistors, or use a trimmer to adjust. I guess the proper way to do it for an arbitrary number of devices is to use those bus optocouplers… but that would probably increase the cost

Honestly I think the best solution is to choose 1 value that works for all configurations. Lower resistance isn’t ever a problem unless it gets too low (<1k) where it starts to cause current-draw issues. This could be done in future by simply adjusting the resistors on TT modules, though clearly this isn’t an easy solution for existing modules.

My thought about the internal pullups on TT was in parallel with the existing hardware resistors which would cause overall resistance to drop somewhat. It might not be enough, but there’s no harm in trying.

The most important thing now is to actually try out some values and see what works! Everything else is academic until we have a “this value works, but this doesn’t”.

Just had the scary moment too - any news on this?

(newest firmware on everything)

with the latest ansible firmware the problem is avoidable but not entirely fixed - as far as I can tell. you have to leave ansible in the TT mode on power down and make sure nothing is plugged on power up. otherwise it freezes the same way. let’s hope for a fix on the TT side soon.

I thought you just have to make sure that teletype and Ansible are in the same state and connections did not change when power cycling (it occurs in all modes - a teletype command to a non active Ansible app instantly crashes teletype).

I came across this accidentally by plugging in a cable into tt before writing a script when a script was active from a former session adressing MP in Ansible while I was working with Kria. It took me a while to figure out that it was not broken, especially when power cycling made it even worse as the screen stayed dark…:cold_sweat:

2 Likes

Was going to fiddle with ths and found that the compiler didn’t know PA09 and PA10; did you mean A09 and A10?

[EDIT]
I’m hesitant to just try something without a schematic. Don’t want to fry another Teletype by acting blindly. :wink:
[/EDIT]

Thanks!