Reset Issues

Copying from Google Groups:

11th March 2017
"Hi Brian,
I’m noticing some reset issues too - full setup described below but in short I’m finding that every 4th or 5th reset I send to my two ER101/102s causes one of them to go out of sync and then the next reset knocks the out-of-sync back into sync, then a couple of resets later the same one goes out of sync again. But the other Er101/102 stays perfectly in sync all the time when it receives the same reset gate (and clock).

Both ER101s are using firmware F2.06
Both ER102s are using firmware F2.12

The ER101/102 that is periodically going out of sync when it receives a reset has serial number F-130
The other ER101/102 that always stays in sync when it receives the same reset (and clock) has serial number G-272


Master clock is the new ‘Pamela’s New workout’ by ALM (will use PNW for short below).

PNW is sending a x24 clock signal to both ER101s
Also sending /4 gate signal from PNW to both ER101s to reset it - as described above the F-130 ER101 goes out of sync every 4th or 5th reset signal it receives the G-272 does not (I know this because when I was analysing what was going on to write this I compared a x1 gate output from PNW and compared against the two equivalent x1 from the two ER101s).

The sequences in the ER101 are 4 steps each with a duration of 16 and gate of 1 (note: the multiplier/division for both tracks in both ER101s is set to 2/3 so that the x24 (DIN) incoming clock can be used in a more conventional music gridding)."

Reply with answers (13th March 2017);

"Hi, here are some answers to your questions.

  1. Are there any asymmetries (differences) in the way you have the 2 ER-101’s patched up?
  • No, nothing different whatsoever.
  1. How are you distributing the clock?
  • Both ER 101s are receiving the same clock signal from a buffered mult and reset signal from a passive mult (stackable cable)
  1. Does the same behavior happen if you disconnect the ER-102 and just use the ER-101 in standalone mode?
  • Can’t test until I return from my travels in 3 weeks, maybe Phil can test in the meantime.
  1. Check to make sure the expansion cable connecting the F-130 ER-101/102 together is not damaged in any way. This could cause dropped packets between the ER-101 and ER-102 and if one of those packets contained the reset event…
  • Again will check when I get back from my travels
  1. How consistent is the dropped reset? If it is very consistent then that is a huge clue.
  • It’s consistent that you don’t have to wait very long for it to happen in terms of the number of resets I.e. Approx every 4th of 5th reset knocks the sync out. But still unpredictable within that range."

Latest reply from Brian (21st March 2017);

“I think its hard to go any further with this diagnostic until you can get back to your studio. It sounds like a hardware issue but we will still need to isolate the source before moving to the repair stage. I especially would like to know if the problem moves with the ER-101 or the ER-102 (for example, by physically swapping the modules in your case and in the patch).”

Hopefully will follow up with new test results beginning of next week when return from vacation.

1 Like

Hi Brian,

Made some good progress this evening trouble shooting - below is a patch diagram of how I’m checking the reset problem:

  1. I went back and tested everything again because I couldn’t quite remember what I’d done 3 weeks ago - so the first thing I did was load a blank snapshot in both pairs of ER101/102’s and set them up with the same pattern on track 1 which was a single step of duration 16 and gate 1 (track multiplier 2/3). Both pairs of ER101/102’s gave perfect reseting i.e. there was no asynchronous issues with either when they received the /8 reset signal from Pamela’s New Workout (PNW).

  2. So I then loaded a snapshot I knew I had observed the original issue in one of the 101/102 pairs and then checked the x1 signal from PNW with the gate from track 1 which had an equivalent x1 gate out. (It’s snapshot N0 in the attached .zip file (9.5 KB) Note: This snapshot is from the F-130 ER101).
    This time I observed the original problem where every 4th or 5th reset trigger caused the track 1 gate out of the ER101 to become delayed by approx. 20ms.

  3. I then decided to simply delete the contents of Track 4 of the same N0 snapshot and all of a sudden the reset issue disappeared!! I then reloaded the snapshot and the problem reappeared so I then deleted the contents of Track 3 this time - the same thing happened, as soon as I deleted one of the tracks in the snapshot the problem disappeared.

  4. I then replicated the N0 snapshot in the other ER101/102 combo (G-272) (Note: I actually copied the above snapshot onto the other card but for some reason when I loaded the snapshot it wasn’t the same so I had to manually replicate it). I then ran the test again and found the same results as point 2 above! So one conclusion is that the issue I am observing is not hardware related as I can replicate the problem of both pairs of ER101/102s. I then repeated item 3 above where I then delete the contents of either track 3, 4 or 2 and the reset issue that caused an approx. 20ms delay disappeared.

  5. Out of completeness I also checked the cable connecting the ER101/102s together and there is nothing damaged or strange.

So I’m pretty convinced the problem is not hardware related but software related, I wonder if I’m taxing the CPU with a combination of short duration steps with 2/3 track multipliers/dividers and causing the ER101 to have a hiccup??
If you could download the N0 snapshot and repeat my tests I’m sure you will be able to see the problem I described above.

Let me know if you need any further information.

Thanks, Phil


Phil, thank you for this exemplary write-up and top notch sleuthing. I agree with your conclusion that this is a software problem. There is more than enough here for me to run with and (hopefully quickly) fix the problem.

Confirmation #1: Can you confirm that the attached N0 snapshot is the correct snapshot? Despite it being inside the folder named N0, the snapshot data itself seems to be actually from G0. So I thought it would be prudent to check.

Confirmation #2: From the point of view of the ER-101, the reset signal is received once every 8*24 = 192 clock pulses?

One more thing. Do I have some time to get this fixed or is this an urgent I-am-performing-for-the-Queen-of-England-in-a-week situation? :wink:

Hi Brian,

Answers to your questions below:

Confirmation #1: Can you confirm that the attached N0 snapshot is the correct snapshot? Despite it being inside the folder named N0, the snapshot data itself seems to be actually from G0. So I thought it would be prudent to check.
- Yeah, your right. Originally it was saved in G0 but I then moved it’s location to N0 when I was testing it in my second pair of ER101/102 (test 4 in my latest post). Sorry for the confusion.

Confirmation #2: From the point of view of the ER-101, the reset signal is received once every 8*24 = 192 clock pulses?
- Yes, I think you are correct.

One more thing. Do I have some time to get this fixed or is this an urgent I-am-performing-for-the-Queen-of-England-in-a-week situation? :wink:
- Good news, I’ve no planned live performances for at least a month so you have some time :relieved:

Thanks again for the support - pleased I was able to get a bit closer to the problem and that there isn’t a hardware issue. It had be irritating me at the back of my mind on my 3 week holiday :slight_smile:

Cheers, Phil

I think I may be getting the 101 reset issue, as I’m having some sync problem when I reset the 101 and trigger generators…
Any thing I can provide to help with the investigation?

I haven’t had time to touch the code on this one but while brainstorming a list of suspects, it occurred to me that assigning a step to one or more groups might slow down its rendering.

So one experiment that would help is to try emptying all of your groups and then see if the reset issue goes away.

Hi Brian,

I’ve just tested your theory and removed all steps from all groups in the snapshot I sent previously (just for future trouble shooting it is only track 2 of that snapshot that has groups assigned and only groups 1 and 2).

Unfortunately the syncing issue still remains after I’ve unassigned all the steps from all the groups.

If I then on top of that delete all the steps from track 4 (much like I explained previously) the sync issue disappears.

Thanks, Phil

Hi Brian,

Realise you’re snowed under - it would be great if you could have a look at this sooner rather than later as I’m putting together a new liveset & I’m finding the problem a bit irritating and distracting from the task at hand.

Cheers, Phil

Definitely, Phil. I’ll take an in-depth look this weekend and hopefully solve it by Monday. Does that work?

1 Like

That would be fantastic Brian!!

Hope you didn’t mind me giving you a nudge.

Many thanks

Not at all! Quite the opposite. A bug in the reset handling is a serious deficiency and I’m glad to have received your patience thus far.


I was able to reproduce your problem on my end and I believe I have fixed it. May I please have you try this firmware out before I officially release it? (120.5 KB)

Inside the zip, is a file call f9_99.bin. This is actually v2.12 firmware with the fix applied.

1 Like

Hi Brian, just tested it - looks to have solved the problem at this end too. :sunglasses:

I also tested it where I had the multiplier/division set to 4/3 and 8/3 and still everything good.

So pleased your were able to find and fix the problem - dare I ask what the problem was?

As an aside I just had a look and I’m responsible for the last 4 ER102 firmware updates … I’m certainly putting it through it’s paces :relieved:


That’s great news. It was a rather subtle bug that took a few hours of scribbling in a notebook once I had it reproduced.

Basically, there is an algorithm in the ER-101/102 that handles the fact that clock edges and reset edges will not typically coincide. Detecting a slightly late (or early) reset signal (with respect to the clock) requires accurate timestamps on clock edges and reset edges. In a standalone, ER-101 those timestamps are unambiguously created when the reset or clock edge is detected. However, in the case of ER-101/102, events received at the ER-101 are binned and packaged together for communication to the ER-102 every 0.3ms. This obfuscates the timing information (and order) of clock edges vs reset edges, so that ER-102 cannot rely on its own timing information but must rather infer it from the communication subsystem’s timing. That was the bug. Once I used the timing information as according to the ER-101-to-102 communication bridge (rather than the ER-102’s own sense of time), it all worked out again.


Thanks for the explanation and the support!!

Have a beer on me :beer:

That’s true and greatly appreciated, Phil! I think the beers should be on me!


hello guys, you solve one of my biggest problem in my live set righ here, i’m so happy !
i didn’t know from where this reset problem comes because, i use a complex patch to reset a new song, there are teletype, VG8, a150… anyway, i didn’t have the right words to explain it ! but when i read this topic, i said to myself, i’ll test it ! and it simply solve it ! thank you so much, both of you :slight_smile:


Glad it’s helped you! It took me awhile to trouble shoot but I got there in the end and then Brian worked his magic!

I’m going to be doing my next live set this weekend at the Brighton modular meet and having this resolved makes things a lot easier and less stressful not having to worry that a ‘clock/reset hiccup’ :heart_eyes_cat:

Hi guys, so now it’s solved is this implemented in the software?
I’m new to the 101/102 so there is a learning curve and I didn’t understand what exactly was the problem.
Could you please explain a bit?
Is this bug solved in the ER101/102 combo which I’m about to receive soon?
Thank you