Teensy 4.1 -- crank/buzz acts strange

[bazmonk]

Got a Teensy4.1 to try out.

DigiGurdies have been Teensy3.5 so far, but those units are currently in extremely short supply due to the chip shortage and it's unclear when they'll be available again. Since Teensy4.1 is not much more expensive, faster, available, and the same form-factor, it'd be nice if they could be both supported.

After installing on the 4.1, everything looks ok in terms of the pin assignments and core functions. However, the crank/buzz is off. I notice that it seems to get "stuck" for a few seconds after cranking sometimes. This behavior in turn affects how the buzz behaves (it doesn't work during this sticking event).

I've noticed more minor behavior like this on the 3.5, that I initially wrote off as motor funkiness, so hopefully I'm killing two birds here.

There's a few things to explore here:

• I'm running the teensy4.1 at full speed, which is over 4x faster than the 3.5. If I ramp this down to 3.5 speeds, I wonder if that affects anything.
• I need to make some debugging messages to see what exactly gets stuck during these events. I'm not sure if the motor wigs out, if my "spin" algorithm gets stuck somehow, or what.

I'll try to debug and find what's happening and then fiddle around with fixing it.

@Gubbledenut is this the sort of crank behavior you're getting or something else on your 4.1 unit?

[angeleusebio]

I have the same issue with the 3.5 and I also tought that the motor was the problem. I buy the pololu recommended by David Jacob, to see if it works better. When arrive, I try it. May be David can tell us something about. Thanks for the great job

[bazmonk]

What I've tried so far:

• The crank motor gives out an inconsistent voltage as its sampled. What I'm doing to give a consistent crank at speed is that when the voltage from the motor is above threshold, it adds a large number to a "spin" counter. That counter maxes out at the equivalent of registering high voltage 4-5 times in a row. When the voltage is low, spin decreases by a smaller amount. How high this spin is determines if the crank makes noise or not.
  • I was using a max spin of 3000, with high voltage adding 800 to this number, and low voltage removing 2 each pass. Adjusting this to adding 500 for high voltage and subtracting 20 helped, but did not eliminate the problem.
• If you compile for the Teensy4.1 at 150mHz instead of the full 600, the problem practically disappears for me at least.
• I haven't tried with Teensy3.5 again yet because I don't want to replace it too many times.
• During the "stuck" episodes, the spin number doesn't go out of control, but it appears to take longer to decay down to zero. It counts down the right amount each cycle, but it looks like the cycles themselves slow down.

Looking at the buzz logic next. It gets calculated in the same step and maybe it gets into trouble and slows things down.

Still hopeful that it's a bug that fixes it for everyone (I'd like the algorithm to work no matter how fast it's run), but there might be s 3.5/4.1 configuration option like the WHITE/BLUE OLEDs that use different values to cope with the different speeds.

[bazmonk]

I have the same issue with the 3.5 and I also tought that the motor was the problem.

I added in a Serial.println(crank_voltage) here where I'm polling the voltage:

        crank_counter += 1;
        if (crank_counter == crank_interval) {
          crank_counter = 0;
          crank_voltage = analogRead(voltage_pin);
          // Serial.print(crank_voltage)...
        };

During these events where it freaks out, the voltage looks ok to me: when it keeps playing and gets stuck, the voltage has already died down as usual. So I'm assuming it's a logic problem and not the hardware. You could do the same if you want to check yours, but I'm guessing the quality of the motor may help/hurt hide a problem in the code and isn't actually causing the core problem.

[bazmonk]

Timing... it's the timing. The loop() cycle is too fast! With a bunch of Serial.print lines sprinkled around, something, I don't know what, was getting the buzz-updating loop stuck.

I'm tweaking numbers before I give y'all something to try, but the real fix is pacing the loop() cycle with microsecond delays (not delay(), but delayMicrosecond()). It'll be different for each architecture, but I'll make directives at the beginning for you to choose which one at compile time.

It actually makes it feel more responsive, oddly enough.

There's more refinement to do later down the road, but I think pacing the code with a tiny delay is the key here.

[bazmonk]

Ok, I like how it behaves with 4.1 now. Just gonna switch back to 3.5 here real quick and make sure it also behaves nice, and I'll push out the update.

[bazmonk]

@angeleusebio @gubbledenut I think this latest version fixes the issue. I tested higher and higher delays until I couldn't manage to get it "stuck". Higher delays should never, ever get stuck but you'll start to notice the responsiveness decrease when playing. Lower delays are more responsive but then start to get "stuck".

[bazmonk]

I'm closing this issue because I opened it, and it's done the trick for me. Y'all are welcome to open another issue if this isn't an improvement on your end.