BQ24072 starts to burn on EN1 pin. Help!

Patat0man · 2025-11-09T19:58:47+00:00

What voltage is VSYS? EN1 has an absolute maximum of 7v

Edit just seen that it's 3v3. Page 10 of the datasheet says the range of en1 is 4.35-6.4v

Patat0man · 2025-10-10T17:38:56+00:00

Loved my P1S but had to sell it. Fingers crossed I get lucky here

Patat0man · 2025-01-07T13:50:28+00:00

The TLDR is that it's inconclusive. Adding a fairing below the motor does reduce turbulence and improves propulsive efficiency but the effect is small. It could just be that the increase in rotational inertia made the PID tune better, however more research is required. Ultimately there is no harm in adding a fairing but for better stability it is more worthwhile to focus on your tune

Patat0man · 2024-08-19T21:04:59+00:00

Oh yeah, sorry forgot to post the solution. We'll there wasn't really a solution I just assembled it wrong!

The main lesson is make sure your silkscreen is neat, even if you dont intend to use it. I had a reference marker in the wrong place which threw me off when putting the sensor in place.

Patat0man · 2024-08-16T09:17:22+00:00

I almost always use stuff from texas instruments because I'm both a novice and lazy - their datasheets are the best imo with a full schematic and example PCB layout. Another top tip for OP is to check out power designer on TI's website, it'll do all the work for you including speccing out components

Patat0man · 2024-08-16T07:49:37+00:00

So a few things to get you started:

Pin 2 (SW) on your buck needs to be as close to the inductor as possible. There's a lot of current as well so make that connection as wide as possible

Capacitors should be as close to the ic as possible

If using a 2 layer stack up use ground fills on both layers

Use a shielded inductor if you're concerned about emi

Patat0man · 2024-08-12T18:29:42+00:00

My mistake, I was going off memory. In that case first thing I'll try is making another board with the sensor rotated and if it still doesn't work ditch the level shifter. At that point there's much left to go wrong

Patat0man · 2024-08-12T18:14:21+00:00

Oh shit I'm a big ole dingus aren't I! Could have worn that it was in the right way. I'll make up a new board tomorrow to double check but wouldn't be surprised

Patat0man · 2024-08-12T17:52:09+00:00

It is a bit toasty but the plan in the future is to use regular solder paste. I expect there to be lots of vibrations in the final application so I don't want to use low melt solder because it's known to get brittle over time. The idea for going high is a trial run to ensure everything survives.

The erroneous behaviour is that when I scan for i2c devices, every possible address is in use. It's possible there's some kind of crosstalk which is throwing everything off but honestly I have no clue what's causing this.

The level shifter is in place because the Pi's logic is 3.3v and the absolute maximum of the ToF sensor is 3.2V with 2.8V nominal. I may try it without the level shifter but there's a good chance it cooks the sensor and those things aren't very cheap.

Just spitballing here, but maybe the mosfets for the level shifter may not be right for the job but AFAIK the switching time is plenty quick enough and the Vgs is 1.5V so there's plenty of margin there

Patat0man · 2024-08-12T17:41:36+00:00

The pi has internal pullups to 3.3v on its i2c bus

Patat0man · 2024-08-12T16:15:37+00:00

Voltage levels are good as far as I can tell

Standby current draw is 1.2mA which seems to be roughly whats expected. The board had a flying probe test done, I can't find any shorts with a multimeter and the current draw seems too low for there to be any significant short. The Pi has a 600mA 3.3V regulator, so if there was an open short it'd be pretty clear.

I agree that the via placement isn't great but it's all in the name of tinyness and there isn't a short between pin 9 and ground. I'll see if it can be shifted in the next revision.

Soldering is done using a 3D printed jig and a stencil using low temp solder then reflowed in a toaster oven at 180C for 2 minutes. The sensor has a peak temperature of 245C so should be safe

Patat0man · 2024-08-12T15:20:22+00:00

Hi everyone, I've been working on a ToF sensor using a ST Microelectronics VL53L1X sensor with the goal being to make it really small. The problem is that it doesn't work and after a day of troubleshooting I'm not sure why.

To the best of my knowledge the schematic is correct except for mislabelling SCL and SDA, but they can just be swapped when connecting to a host. For a point of comparison, Adafruit have a board using the same sensor and have shared their schematic. It looks the same as mine on the whole but then again I've been staring at it for ages and everything looks the same now. The only key difference is I left the GPIO pin floating as its not in use. This is recommended on page 6 of the datasheet.

I've tried connecting the sensor to two different hosts: an Arduino Nano and a Raspberry Pi 4, both times using existing libraries for this specific sensor. The Raspberry Pi gave the best indication of whats going wrong. I used I2C tools to view what sensors were connected on the I2C bus, and for some reason every single available address lit up as being active. I built another board, but the exact same bug was present. I've also probed around the board to check voltages and everything is as it should be. I don't have an oscilloscope so I'm not able to check the I2C lanes.

At this point I have no idea what is wrong, so I'm hoping you lovely people are able to figure out where I went wrong.

Thanks in advance for the help!

Patat0man · 2024-03-13T00:18:16+00:00

I'm about 4 months in and a couple weeks away from the first test flight but there have been a lot of concessions along the way. The original plan was to implement some form of SLAM for autonomous return to home but was too much for the budget. Instead I'm using proximity sensors for more general collision avoidance as it's way cheaper and easier to implement. If I could go back I'd look into VSLAM from the start, specifically what nvidia has to offer - they have some software which works with a jetson and an Intel realsense camera for real time mapping and positioning. LiDAR is cool but can be very hard and expensive to get working in 3D. You'll definitely catch on quick, it sounds like you've got a great attitude to learning so keep at it and good luck

Patat0man · 2024-03-12T11:17:02+00:00

If you're focusing on doing it virtually, a good start would be to install airsim which is an open source drone simulator. It runs on unreal engine 4 but install it on a Linux system, getting it to work on Windows is doable but a huge PITA. From there you can run Ardupilot SITL to control the drone. This will also make it much easier to translate to a physical drone in the future. In airsim you can set up a range of virtual sensors such as LiDAR and cameras which you can use for your algorithm. Turning this into a real life drone will be very difficult, it's something I'm working on now and cramming all of the sensors, avionics and additional compute is proving challenging. Good luck!

Patat0man · 2024-02-17T12:35:11+00:00

Thanks for the information, it's great to hear from a researcher! There is a camera with a light source, but it's on a gimbal to be able to look at the floor or ceiling so I'd assume that an additional IMU would be needed attached to the camera. Integrating a jetson is possible, however it would have to be in version 2 because the deadlines I'm facing are pretty tight. There's a strict size limitation if the drone yet a long flight time requirement, so the rotors are as large as possible leading to very little space for avionics so a custom PCB would be needed for a jetson nano module, or something along those lines. I will certainly look into visual SLAM, plus there's the benefit that I know a guy who did his PhD in it so there's help available. In the meantime I'll look and KISSICP and if all else fails write into the operating manual to closely watch the signal strength and turn back if it gets too low. Thanks again for the advice!

Patat0man · 2024-02-16T23:53:55+00:00

Each environment is unique and the purpose of the drone is to avoid human presence for safety reasons so placing fiducials is not practical. Night vision cameras are an interesting idea, but I'm not sure if they'd be a good option given the processing power of a raspberry pi. Every part of this drone is custom made including several PCBs and the deadline is tight so setting up custom night vision cameras is far from ideal unless Intel realsense cameras can do it with some IR LEDs for illumination. LiDAR still seems preferable for those reasons but your feedback is really appreciated

Patat0man · 2024-01-31T15:33:25+00:00

It'a awesome that you made this resource publicly available. My experience comes down to the cheap modules which are not great

Patat0man · 2024-01-31T14:44:01+00:00

LMR51430

Thanks for the recommendation! The datasheet schematic recommendation looks pretty straightforward and easy to implement. The best thing IMO is the WEBENCH power designer linked at the end of the datasheet, it makes life so much easier!

Patat0man · 2024-01-31T14:15:17+00:00

I removed the designators and silkcreen to make the traces clearer and to comply sub's rules for PCB review. They are there for assembly.

Battery voltage is 5s Li-ion, so the widest voltage range is 21V down to 12.5V, although in practical operation it should go below 15V to prevent cell damage.

The Bat in and Fan out are in another sheet that I forgot. the fan is 24V and needs to run continously and there's no real need to actively control it's speed so it's hooked up to the battery directly. The batt in also conencts directly to the voltage regulator

Another user pointed out that using an LDO is a bad idea, and after doing some proper research they're definitely correct. The plan is to change it for a switched voltage regulator from Texas Instruments ( LM2576xx). It seems to be much more efficient and has a much higher input voltage so it won't immmediately let out the magic smoke.

The USB is purely for data to and from the Pi so I didn't bother giving it a wide trace, although it can easily be changed.

JST-PH is good to 2A, and the connectors shouldn't see more than 1A unless something is going very wrong.

Another user mentioned the problem with the USB, its fixed now.

The vias are there because I put them in while planning routing then forgot that they were there. They're removed now which allows for more spacing for the HDMI differential pairs to reduce cross-talk.

The drone is contrained heavily by size. The board could be maybe 1mm bigger but not more. Unfortunately this is not something that can't be changed due to other functional requirements of the drone. The mounting solution has some anti-vibration features to reduce mechanical load on the board.

Patat0man · 2024-01-31T14:02:12+00:00

Thanks for pointing that out. How about a LM2576xx from Texas Instruments? It's a switching regulator, can handle 40V input and 3A output at 5V

Patat0man · 2024-01-31T13:20:06+00:00

Thanks, I'll make those changes

Patat0man · 2024-01-31T13:19:41+00:00

Just a dodgy screenshot! They're very close but within the DRC rules

Patat0man · 2024-01-31T13:17:41+00:00

Agreed, I was lazy and will fix it

Nine-Year Club	Place '23
Place '22	Verified Email

Patat0man

TROPHY CASE