Such a strange problem. I’ve had no trouble using interrupts to measure the pulse time from a servo tester, and my version of Lepton should be more prone to interference, being more densely routed with less ground plane area, and I remember the revision I had manufactured has an unnecessarily long path somewhere (maybe the ground from the gate driver chip). Must be beginner’s luck…
But aside from interference problems, printing from inside an interrupt may not be a good idea since it could happen in the middle of a communication from the main loop. I’m not sure if Arduino’s Serial class is written to deal with that or not. But it would certainly be safer to store the relevant data in variables and then print it from the main loop later.
@Anthony_Douglas is yours the 2-layer or 4-layer version of the Lepton?
How are you checking it? To find interrupts you’ll probably have to use the trigger mode of the scope to find the rising edges causing the interrupts.
If they’re happening with the pin tied directly to ground (with a short cable? how is the connection made?) then there will probably be some noise coming in through the ground line.
if the noise is due to coupling, say with the PWM lines, then it should be visible on the unconnected (internally pulled up) pin also.
If you add a simple RC filter with a 100nF capacitor and 100Ω resistor, do the problems go away?
You should not use the Serial port, or any other potentially blocking IO function from within an interrupt function…
Hey guys, I’m sorry I don’t have much time to check this out in more detail. I don’t think adding a capacitor would help much because even connecting it bang to ground doesn’t work. I think there is noise on the VCC line of the MCU or something. All I know for sure is that’s not supposed to happen…
Runger, I have heard such things and generally agree, but man sometimes you gotta. I thought it basically just plonked data in the serial peripheral’s buffer, I don’t see why that would be blocking? It seems like a reasonable operation as long as the amount of data is small, I think the buffer is 32 bytes. Anyway it’s a moot point now.
I have also discovered that there is a lot of errors with communication over the UART. About one out of every 15 characters is getting messed up, quite randomly.
This could also I guess maybe be due to innacuracies in the clock speeds? I don’t notice this problem arising when I use the TTL to USB converter, but when I talk to it with a Pico it’s a problem, yeah. It seems to be the same whether the baud rate is 1000000 or 115200.
Trying to deal with errors and glitches makes things exponentially more complicated…
Again, further arguments in favor of the HAT approach, where you get a proper crystal oscillator etc. I guess. At least it would eliminate the uncertainty.
Well, the point would be to place a R-C filter between input and the pin, which forms a simple low-pass filter and protects the MCU from noise - and therefore the spurious interrupts. But when the input is permanently tied to GND not sure how effective it would be. Certainly the series resistor would not hurt to protect the MCU.
Noisy power could definitely be the cause of many hard to diagnose problems, but should be quite visible in the oscilloscope. Again, you can use the trigger mode to look for spike type noise, and (if the scope supports it) use its analysis functions to give you the peaks, ripple value, dominant frequency (if any), etc…
A simple fix is often to add some more bulk capacitance - the lepton, for example, should probably have an external bulk capacitor when used with higher power levels.
The more components, connections, protocols, different abstraction layers, etc you have to deal with, the more complex everything gets and the more work you have debugging and solving problems. I would even predict that the relationship complexity to number of components is not even linear.
The absolute best way not to have a problem with a component is not to use it at all
That’s not super-helpful, I know.
I have the fear that the multi-mcu approach is going to be a lot more work and more complex than an approach that keeps things, well, more simple.
My approach would be a different one: if you find you’re not getting what you want out of the system, you have to ask yourself: what’s different about my setup / use-case / situation than that of the other people?
It’s a fact that by now hundreds of people have made their motors turn using SimpleFOC. The forum is testimonial to many questions and difficulties, but also many successes and problems overcome. People have used SimpleFOC to make robot arms, haptic feedback devices, balancing systems, mobile robots and more.
So what’s different in your case?
you’re trying to go 3000RPM - this is a lot for FOC control. Within the attainable, but certainly a challenge and requiring careful choice of components, and careful writing of the software and tuning. Solutions: 1. start simple - aim for 500RPM at first, and work your way up. 2. get a nice fast MCU like a Nucleo G474 board, and a good encoder / sensor to make your life easier.
you’re trying to be whisper-quiet. A fair requirement, but generally speaking in conflict with the aim to go fast. optimize first one then the other, doing both at the same time will be harder.
you’ve gone right to custom HW development - maybe work work with a Nucleo board and a SimpleFOCShield or BoostXL or similar and work with this until you’re happy with the software. Then dive into custom driver development.
you’re using our worst-performing sensors: PWM and I2C, but are trying to achieve high performance control. It won’t really work. SmoothingSensor etc are interesting ideas, but not a recipe for quick success. Get a proper sensor, like a high speed magnetic encoder or high resolution optical type encoder, and get it working well.
That would have been welcome advice before I started, lol. I decided to switch to the B-G431B-ESC1 board for now. It has it’s own issues, it has a baffling tendency to overheat and flake out sometimes, but I am hoping that won’t happen much.
I did try the simplefoc shield and graduated from it pretty fast, I heard there were issues with 3 pin PWM although that may not be as bad as I had thought, that’s why I didn’t pursue the use of the shield. I have never heard of boosterXL.
The one major missing piece in the ecology is a decent 6 pin pwm stage. If I had had that things would have been a lot easier. The only reason I got the leptons made is that I was going to have to have a 6 pin pwm stage board made anyway.
I certainly asked for such advice early on, in fact I DM’d Valentine and asked for exactly his advice on what hardware I should try to rumble with. From what we knew at the time the lepton and SDC6022-whatever was not wrong, it’s just that the difficulty of a quiet system is quite unusual. Also couldn’t get the driver working for that encoder although with my improved understanding of the library I could probably get it working now. I don’t think I really need it, the AS5600 with it’s analog output seems to be working ok so far with the pico’s ADC input. Maybe I’m speaking too soon, but it seems to be leading to reasonably precise angle info to regulate the angle of the rotor vs. the electrical angle. My challenge is not the same as most of the things on here because a fan has a very predictable load vs. rpm curve and there should not be any shocks etc. I could almost do things with open loop. But it wouldn’t be safe in the event of stall etc. and not as efficient. however by adjusting the voltage in a way that scales with RPM etc., I am actually able to get fairly good efficiency with open loop only. Better, in fact than the texas instruments MCF8316 chip was getting.
I did add a good 1000uf 50V capacitor, I don’t know it’s ESR but I checked the inputs with an oscilloscope and don’t see any noise on there.
I tried exactly the same code (except with the new pins for the driver stage) ong the b-G431B-esc1 board and there are no errors with the uart communication that appear to be detectable. It could have been noise, or it could be a mismatch in clock rate perhaps.
