Investigation in to noise issue with lepton 2.0 - not the ceramic caps

1

I have like 15 of these boards so it would be nice if I could fix them, but even more importantly we don’t want whatever is going on to be inherited by subsequent boards that are derived from this one. That would ruin yet another batch.

Basically, this batch of Lepton 2.0 boards (tried 3 different ones ) suffer from some kind of noise issue. Serial communication is extremely unreliable, so is I2C, when powered from 24 volts. So are interrupts, interrupts spontaneously fire, depending on how the wires are arranged etc. (probably due to capacitive coupling in some way). It works fine if I power the MCU over the SWD connector (which is apparently backwards, you aren’t supposed to feed 5 volts into that connector but it seem to work fine :P)

I read recently using ceramic caps can lead to noise issues, paradoxically, but it looks like that’s not what’s happening.

I made three videos, one showing the voltage spikes on the ground plane when powered with 24 volts, outputting 2 volts programmed at 2 radians per second, no motor connected. Large spikes of more than 10 volts are seen on the ground plane, but of very short duration, the oscope is set to 5 volts , 0.1 microseconds per division. It may be the spikes are actually larger but extremely short and therefore the peak is not visible.

similar spikes seem to occur on the positive side, but it’s not clear. I have to change the oscope to 10 volts per division and that renders the spikes on the ground side hardly visible and so I wouldn’t expect the positive side spikes to show up when I do that, just some kind of defect in how the oscope works I guess. It would be nice to know if the spikes were positive in nature on the positive side, indicating something to do with inductance, or if they were only dips, which would say to me that the mosfets were giving a very low resistance path to ground during some periods.

The large 1000uf capacitor gets warm even when the motor is not connected.

I connected the motor, and the spikes get much bigger, at least 50% bigger, you can see in the video.

I tried removing the capacitors by destroying them/prying them off with pliers (tried to solder the off but didn’t seem to be working). Didn’t work, the voltage spikes are basically the same as before, apparently.

I would have thought the capacitors would blunt the spikes considerably, maybe the capacitors are too small, a manufacturing error. Even so it would be good to address the source of this noise a little closer to the root instead of just trying to absorb it.

Any ideas on the cause? I previously experimented with dead time and PWM frequency to see if I could solve it and could not.

Now that I have things all set up, now’s the time to investigate if anyone has any ideas.
no motor connected

with motor (iirc it was about 24 ohms for both phases of the motor in series, i.e. terminal to terminal. Power supply said 0.08 A when no motor connected and only 0.1 A when connected but I think that’s a bit off.)

2

Hey Anthony!

The Lepton 2 is still on my desk :slight_smile:

I’ve been working on a upgraded version I call the LeptonG4. :slight_smile: I think you get the idea.
It’s almost ready for a first test production, and I think I have all the components at home so I’ll order some PCBs soon.

One thing I noticed when checking out Valentines original design is that it doesn’t include any gate resistance. It may be that it’s not needed, I didn’t do any tests, but if you have it all set up and feel like testing you could try to obtain an oscilloscope trace of some switching events measured at the FET gate or driver gate output. In parallel you could measure one of the misbehaving signal lines, and/or the logic power rail. The goal would be to see if the FET is “ringing” and if this is impacting the digital side…

1 Like
3

at 2rad/s there should not be significant BEMF generated to create 10V spikes on a 24V rail… are you sure that your probes are set right? With cheap probes they usually have a switch at the handle to swap between 1x and 10x - at these low voltages it does not matter which as long as you are consistent, but 10x is safer (it’s actually the input divided by 10). Likewise, the firmware in the oscilloscope should be set that the probe magnification is matching your probe setting as well.

4

This probe and oscope set it simpler than that, there is no 1 or 10 x. It just is what it says on the screen wysiwyg ;). I have used this oscope innumerable times and it’s definitely configured right, those spikes are legit.

Ok, I will probe around on the logic supply rail and the FET gates :slight_smile:

5

nice! looking forward to the design :). I would post early and often to get input, we have a lot of board designs and I believe the next major milestone should be to integrate the lessons learned, most posted on the forum, and then we will really have something. There are a few things in this world like Marlin and Linuxcnc, the raspberry pi, and simpleFOC is shaping up to be one such thing, that have gone well and are solid stepping stones to reach further with. I believe a brushless motor controller board of such a nature is warranted, but we need to break out of the lone-wolf paradigm a little more. We are starting that already by participating in the forum.

look at me lecturing away when I should just take a couple days and walk the walk I know but I just can’t right now.

6

@Anthony_Douglas, probably, you know all that, but just in case… I think it is important to find out to which other events those spikes are related. You can try to trigger your scope in a reasonable way to see a more or less steady signal and then determine the frequency of the events. This may already give a hint. Another option is using two channels, one with the spikes and another with a regular signal, e.g. the PWM for one phase. Trigger on that other signal and you may find a correlation with the spikes for one or another. Of course, you may have multiple spikes for a single PWM signal for example since there are three phases and two MOSFETS per phase, but at least one should always be correlated if it is the cause.

7

Yes, trying to synch on the various signals could probably help a lot to reveal more info, I can try that to prove hypothesis out. Right now I think there are probably more than one problems.

This video shows serious overshoot and ringing on both leading and trailing edges:

This video shows much larger spikes of unknown origin:

Maybe it is some kind of feedback loop, ringing on the gates leads to the mosfets allowing current through at the wrong times, and this causes noise on the ground planes which leads to further problems. I think the fortior driver is wired approximately correct though, I don’t know how to fix this noise on the gates.

Sorry I cannot get my stupid camera to focus on the oscope screen, it’s a crummy camera but the autofocus is just crummy basically, sometimes it does focus for an instant…

P.s. I also investigated the digital side, with different combinations of ground - logic ground and main power ground, and the 3 volts and 5 volts outputs at the connectors. It would take me a while to figure out which pin is which and poke in there with a sewing needle, but I think measuring at the connectors is a pretty good start.

All combinations give serious noise spikes, it was a peak to peak of about 8 volts, much less than 0.1 microseconds duration on the 3.3 volt output, when measured to the power ground close to the connector on the actual lab bench supply, and more like 6 or 5 volts peak to peak when measured to the nearby logic ground pin. There may have been interaction between the noise on the ground and the noise on the power supply, don’t really know how to solve that except to connect to the actual earth as my ground or another very large mass (and also ideally connect the power ground to it some distance away). In any case I think we can assume that this size of spike will propagate through the voltage regulators and this must be an issue.

I think it’s clear that ordering a board with only minor changes is very likely to lead to problems :frowning:

8

Just realized that pwm signal to the mosfets must be like 2 mhz or something, that seems a bit high. yeah BLDCDriver 6PWM | Arduino-FOC say s 50khz max, definitely something wrong there but I have no idea what that could be, something with the timer registers deep down in the code or in arduino libraries… Wonder if that could be causing the very large spikes? Maybe when things coincide cyclically in some way or another.

9

It should be 25KHz (_PWM_FREQUENCY in stm32_mcu.h) unless you set driver.pwm_frequency to something else.

10

I definitely didn’t change it as far as I can remember… can check the code and re-upload it I guess.

This is the code currently running on the board:

#include <SimpleFOC.h>

// NUMBER OF POLE PAIRS, NOT POLES, specific to the motor being used!
BLDCMotor motor = BLDCMotor(7); 
//this line must be changed for each board
BLDCDriver6PWM driver = BLDCDriver6PWM(PA8, PA7, PB3, PB0, PB6, PB1);
float goal_speed =0;
float v=2;
int mode = 0;
float angle_for_angle_mode = 0;
void SerialComm()
{
  switch(Serial.read())
  {
  case 'T': goal_speed = Serial.parseFloat();break;
  case 't': Serial.print("T"); Serial.println(goal_speed); break;

  case 'V': v = Serial.parseFloat(); break;
  case 'v': Serial.print("V"); Serial.println(v); break;
  
//  case 'S': p_gain = Serial.parseFloat(); Serial.print("P");break;
  case 'e': Serial.print("e"); Serial.println(motor.shaft_angle); break;
  case 'A': angle_for_angle_mode = Serial.parseFloat(); break;
  case 'M': Serial.print("Mode_changed"); mode = int(Serial.parseFloat()); break;

 // case 'I': diff_filter.Tf = Serial.parseFloat(); Serial.print("I");break;
//  case 'i': Serial.print("f:"); Serial.println(diff_filter.Tf); break;
 // case 'D': d_gain = Serial.parseFloat(); Serial.print("d_gain set");
 // case 'd': Serial.print("d_gain is:"); Serial.println(d_gain); break;
//  case 'O': i_windup_limit = Serial.parseFloat(); Serial.print("i_windup_limit set");
  //case 'o': Serial.print("windup limit is:"); Serial.println(i_windup_limit); break;
//  case 'U': setpoint = Serial.parseFloat(); Serial.print("S"); break;
//  case 'u': Serial.print("s:"); Serial.println(setpoint); break;
  
  }
}


void e_val_req(){
  Serial.println(motor.shaft_angle, 3);
}



void setup() {
  Serial.begin(1000000);
  Serial.println("test serial4");
  // driver config
  // power supply voltage [V]
  
  driver.voltage_power_supply = 24;
  driver.init();

  // link the motor and the driver
  motor.linkDriver(&driver);
  FOCModulationType::SinePWM;
  // limiting motor movements
  motor.voltage_limit = 3;   // [V]
  motor.velocity_limit = 520; // [rad/s]
 
  // open loop control config
  motor.controller = MotionControlType::velocity_openloop;

  // init motor hardware
  motor.init();
  //accelerate
  motor.voltage_limit = 2;
  goal_speed = 2;
  pinMode(PA4, INPUT_PULLUP);
  attachInterrupt(digitalPinToInterrupt(PA4), e_val_req, RISING);
//  for (int j = 0; j<(maxradianspersec*accel_step_divisions); j++){
///     for (int i = 0; i<accel_loops; i++){
 //    motor.move(j/accel_step_divisions);
 //       } 
 // motor.voltage_limit = 2.4+(3.6*(float(j)/(maxradianspersec*accel_step_divisions))); 
  // Serial.println(motor.voltage_limit);
 // }
}
  
void loop() {

  
  switch(mode)
  {
  case 0: 
  motor.controller = MotionControlType::velocity_openloop;
  for (int q = 0; q<10;q++){
   for(int j=0;j<10;j++){
     if (motor.target < goal_speed-0.3){
      motor.target = motor.target+0.15;
     }
     if (motor.target > goal_speed){
      motor.target = motor.target-0.15;
     }
     motor.move();
     motor.move();
     motor.move();
     motor.move();
     motor.move();
}
 //Serial.println("t");  
     SerialComm();
     motor.voltage_limit = v;
  }
  break;
  case 1: 
    motor.controller = MotionControlType::angle_openloop;
  for (int w = 0 ; w < 10; w++){
      SerialComm();
      motor.move(angle_for_angle_mode);
      motor.voltage_limit = v;
  }
  
  break;
  }

    
}
11

Are sure? That seems very high, not sure you can even set it that high with SimpleFOC. Is that number from the scope? Are you sure that’s not the frequency of the ringing?

:joy: yeah it’s a bit hard to see, but there are some sharp parts in the middle that you can pause on to take a look.

Am I right that we’re looking at a single phase, with the horizontal sync set such that the switch-on and switch-off are almost on top of each other?

It does look like there’s some ringing, but it doesn’t look terrible. Looks to be about 10-20% of the full swing, so that would be around 1.5-2.5V or so.
On the switch-off it looks like it dips below 0V by a bit too.

I’ll design in some gate resistances on my version and check if it helps.

@dekutree64 did you look at this in your version? Did you add gate resistors?

12

No, it’s basically unchanged except for the removal of the buck converter and reset button. Same parts, just rearranged to reduce the overall size and minimize the length of PCB traces carrying high current. I haven’t had any trouble communicating with Arduino serial monitor or a little I2C LCD (although the I2C communication is slow enough that the motor doesn’t run well while it’s in use). But I’m so inexperienced and impressed that it works at all, it’s quite possible I have the same noise issues and just haven’t noticed.

I don’t know if it matters, but I’ve done all my testing so far on 2S lipo (7.4V), whereas you need 10V to fully open the gates. My intent is to use 3S lipo or 4S LiFePO4 in the end.

2 Likes
13

In order have more stable measurements, I would add

    motor.setPhaseVoltage(2.0, 0, 0);

at the end of your setup function an use an empty loop function. If my understanding is correct, this should generate PWM signals with constant timing and thus make the triggering easier. The motor won’t move though, but for the time being that should not matter.

14

Yes, Grizzly is right, setting a constant PWM would be easier to get a stable image on the scope, but be sure to use a high-ohm motor that can take the current…

15

Regarding if we are looking at a single phase, you are probably talking about the video where there appears to be rising and falling edge pulses superimposed. What’s happening is that the oscope is configured to trigger on falling edge but the noise in the signal is causing it to trigger at other times as well, probably the ringing causes it to trigger on both rising and falling edges. So you get it flickering, sometimes showing a rising edge and sometimes a falling edge. It triggers at a point about a third of the way across the screen. So that’s where you can see the rising and falling edges frequently coincide. Sorry I should have said all that I have a hard enough time reading an oscope when I can see everything but that video is very blurry…

Further investigation:
I adjusted the power supply to 7.4 volts, and indeed it makes a huge difference. The baffling very high frequency at the gate is no longer there. The signal at the gates is a proper 50khz rectangular wave exactly as expected. The ringing is quite significant, more than enough to confuse the scope into triggering at the wrong time but it still triggers in mostly the same place every pulse so you can see the waveform at least.

the noise on the power ground as compared with logic ground is very small, much less than it was. Just modest little ripples every once in a while.

I didn’t check noise on the 3.3 volts and 5 volts.

Next step is to see at what voltage the spikes on the ground arise.

Ok, yeah as I adjust the voltage those little modest blips appear to be just getting bigger and bigger the higher the power supply voltage, whatever they are.

When I zoom out by making the time division longer, up to 100 microseconds per division, the amplitude of the noise glitches appears to have a sine wave waveform, when they are aggregated together like that. The frequency is maybe 20 khz but it’s not clear.

The high frequency rectangular wave on the gate of the mosfets is still mysterious, it appeared briefly at 7.4 volts but then vanished, I thought maybe the sewing needle had contacted something else briefly but I poked around and there is nothing nearby it could be…

edit: I cannot reproduce the high frequency at the gate. Poked around in case I had the probe on the wrong spot, but no, there is nothing nearby that gives that. I changed like nothing else. However sometimes the system enters into a state where there are a constant stream of interrupts, but now it was not in that state. So it might be related to the noise somehow, only occurs at the same time the noise on the MCU pins is enough to trigger interrupts, for whatever reason. I think bottom line the noise is wreaking havoc, there is no need to discern exactly what havoc, the main issue that is leading to those large spikes on the power ground just has to be sorted and then the rest will be ok probably. Looks like significant chance it’s the ringing, which may lead to the mosfets being on at the wrong time, leading to massive very brief current and voltage spikes galore due to parasitic inductance and resistive voltage drop etc.

16

I would try to trigger on the clean signal (if there is any) and on rising or falling edge to get a better readable output.

17

… and yes, that ringing doesn‘t look good to me either, but I am lacking experience if what might be tolerable.

18

I’m no expert on ringing either but given the amplitude of those waves, I think it’s more than enough to cause the mosfet to turn on or off at the wrong time, so that’s going to be a problem for sure.

19

Hey,

You can check for this by probing the phase voltage to see if the FET is actually oscillating also in time with the gate. But it looked to me like about 1V or so, out of the 12V gate voltage? So the oscillation is around 2V p-p or something? It would not seem enough to switch the FET back off on the switch-on, but might be enough to switch it back on when it’s supposed to be off? I guess it’s better to measure than theorize.

1 Like
20

I’ll give it a check this evening then. If it’s not that then IDK what’s causing the massive spikes of noise elsewhere though.