![]() I think the PWM frequency is 25kHz, so you may be seeing spikes at both the rising and falling edges of the PWM cycle. some GPIO pin configured as an interrupt is picking up noise and spamming the microcontroller with interrupts - this could be starving the low-priority tasks i.e. If so, I wonder if it could be suffering from interrupt overload or something like that, e.g. You say you see the noise on the probe ONLY during the failure condition.?ĭoes that mean the noise starts immediately as soon as the USB drops out, and continues until you reset the drive? I guess that’s not a storage oscilloscope though, so you might not be able to do that… The USB wires are differential so to see the actual data without noise over the top you would need to subtract one from the other. The AC coupling on your scope might be tricking you into thinking that it’s not a digital signal…? It’s possible that the signal you are looking at is normal USB communication. Ok, so you have the probe on one of the USB data wires. This 40uS and 20uS noise is not present on the 48V into the oDrive. If it’s not too much effort - would either of you able to probe it with a largish motor 400-500W to see if you see any noise? I will put pictures below of the noise I am seeing on the USB_DM. So seems the problem here is not just related to the steering motor. There is noise there but it is not as high amplitude, it did cause the USB to drop offline though a couple of times, which I have seen before intermittently throughout the project but had put down to the bad grounding issue. I have no idea how critical this is for USB.Īfter seeing the noise on the USB signal for the steering motor, I wanted to see it for the hub motor too. ![]() The PCB traces do change their distance from each other and no effort appears to have been made to separate them from other traces. The noise waveform is not identical on DM and DP. 20uS waveform at ~1V pk-pk with 2V spikes. I can see noise here and only when it fails. I probed TP1 and TP2 (USB_DM and DP) with an as short an earth lead as possible (see picture). So I added a lot of extra decoupling which did attenuate it but did not get of it completely. I started probing for noise and found a 40uS waveform across C29 (5V Reg output) only when in AXIS_STATE_CLOSED_LOOP_CONTROL. Unfortunately this hasn’t made any difference. I tested it was grounded by the rest of the frame, which is connected to 0V (of PSU and Jetson) and mains earth. I bolted a 1.2mm thick steel sheet to the gearbox to try shield the oDrive as suggested. Seem to have gone full circle again and have seen the problem occur when just using the hub motor. I will keep trying to resolve USB for now but that failing that will move to CAN.įinally got chance to work on this today. Perhaps I should have put the oDrive in a metal box… Unfortunately the wires on the steering motor are so short that I can’t move much further away without soldering extensions on it. I thought that the fact that powering from the battery test worked fine proved that this close proximity was not an issue. The steering motor is physically right next to the oDrive. The hub motor is rated to 500W while the steering motor is 440W. With the hub motor holding position, I can force it as hard as I can to make it fight me, and this still would not create the issue. I replicated the above on a separate assembly - so different oDrive and different steering motor. I swapped the axis around that each motor was using, recalibrated and repeated test - the issue follows the steering motor. ![]() It only just occurred to me this morning that I should try the same test with my hub motor, which worked fine, no USB issue, even without using USB isolator. I have just proved the issue is related to my steering motor specifically:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |