iliketurtiles

joined 9 months ago
 

Im working on a board for controlling a few linear actuators. They will at full load draw something like 10A, and will be powered by a 24V (or so) LiPo pack.

I have a few H-bridges and as expected when the power is cut off, there is an inductive kickback of about 10A. No PWM, they will be turned on and off occasionally only.

I havent been able to fibd anything on if a LiPo pack would be able to take this reverse current, or if it needs some sort of protection. It also lasts for quite a short time but I'm new to batteries so I want to be sure its not a problem.

Would apprecaite any help :)

Oh that makes sense, thanks :)

[–] iliketurtiles@programming.dev 8 points 3 weeks ago* (last edited 3 weeks ago)

Heres a comment I read on youtube where again soneone points out the ground voltage rising/falling. Very confused why they say this.

 

This is from a section on why decoupling capacitors should be attached to CMOS chips. It shows current spikes during transitions. Which then because of the inductance of traces connecting power to the chip, will cause the power rail voltage to droop.

But why is the ground voltage also shown to rise? What does it even mean for ground voltage to rise when ground is what voltage is measured against?

[–] iliketurtiles@programming.dev 2 points 4 months ago* (last edited 4 months ago)

Other than what others have suggested:

  • Do get an etch resist pen. The toner occasionally, even when it goes well, might not transfer on some spots of the copper plate. So you'll need the etch resist marker to color in breaks in paths etc. and fix these little issues.
  • The acid or whatever you use to etch away the copper might not work on some spots. Leading to shorts or otherwise unwanted connections. So do check with a multimeter the paths and pads that are close to make sure there arent shorts. You can scratch away unwanted copper with a blade.

I dont think theres much more to add, its quite a simple process. Have fun :)

[–] iliketurtiles@programming.dev 5 points 4 months ago (8 children)

The toner transfer method would be I think the most DIY method you can use. Make your pcbs entirely by yourself at home.

Naturally wont give you as professional a result: no silkscreen, limited to 2-layer pcbs (2 sides of a copper plate).

But it is a lot faster that having it manufactured (takes me like 1 hour for a pcb) and maybe this is debatable but it makes me feel like I have more room to make mistakes.

 

CubeIDE does some checks which means clone bluepill boards don't work with it - you can't flash or debug. The methods I found online to get around this didn't help except for a stackexchange answer that got me most of the way. I figured I'd rewrite the answer with some small changes and add in a few details I needed to make it work.

The gdb and OpenOCD that CubeIDE uses do the verification checks, so an alternative is to install separate versions of these and get CubeIDE to use them instead.

  • Install Eclipse CDT from the Eclipse store within CubeIDE.
  • Install OpenOCD and gdb-multiarch (using whatever package manager your OS has).
  • Under "Debug Configurations", choose "GDB OpenOCD Debugging" to create a new debug profile. See this image from the stackexchange answer and check that the debug profile looks like it.
  • Config options for OpenOCD: -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /path/to/bluepill_ocd.cfg Where bluepill_ocd.cfg is /usr/share/openocd/scripts/target/stm32f1x.cfg with the line set _CPUTAPID 0x1ba01477 changed to set _CPUTAPID 0x0 which disables checking the CPU ID which the clone has different from the original.
  • Delete __HAL_AFIO_REMAP_SWJ_NOJTAG() within stm32f1xx_hal_msp.c or it will enter a reset loop after calling HAL_Init(). Not really sure why the reset loop happens. You'll have to delete this line every time you generate code from the device configuration tool (CubeMX).

Debugging should work now.

 

I'm using an Arduino and through a library working with an IC (MCP2515, a CAN controller) over SPI. The IC indicates interrupts by causing a falling edge on an interrupt pin.

Components are connected using jumper wires on a breadboard.

  • When a logic analyzer is not attached, the IRQ gets called a few hundred times. It should only be called once. I thought it must be noise on the external interrupt pin but a pull-up doesn't help. I've tried the internal pullup and an external one.
  • Trying to see if there is a ton of interrupts from the IC, or an error internal to the Arduino, I attach my logic analyzer. Now it works perfect.

Any idea what might cause such a weird issue? Looking around I haven't found anything.

EDIT: I found a Reddit post for a different circuit where a user suggested placing a small capacitor to make the edges of a signal rise slower. This has fixed my problem.

Since I've already created a post: does anyone know why I was getting an unending number of interrupts? Why would the edges of the interrupt signal changing too fast cause something like this?

 

Not sure if this is a dumb question but this has me quite puzzled.

The legs on TO220 packages are very small. How is it that there are e.g MOSFETS rated as being able to continuously conduct ~100A? e.g IRF1404Z

From what I understand such large currents need busbars on PCBs and these appear a lot larger than the legs on these components.

[–] iliketurtiles@programming.dev 1 points 9 months ago

Thank you, will give that a go :)

 

I'm making a driver for a small 15V, hall sensored, 9-slot BLDC motor I got off of AliExpress. It has u,v,w inputs. Three hall outputs and Vcc, Gnd for them. No datasheet :)

I understand the working principle: I'll have to use the hall sensors to figure out the location of the rotor, then power the appropriate windings.

Trouble is, I don't know how the windings for the three phases are arranged within the motor. So I don't know which pin to give power to, because I don't know which windings within the motor will then be powered.

How can I figure out where the windings are for each phase?

I'm guessing I've got to manually spin the motor and do some detective work with back-emf measurements and hall sensor outputs to figure this out?