5 ms·
I don’t know why you need to be snarky. I’ve been living this for over a decade with engineers with decades of experience who have done some of the most advance
by tomhow 11d ago
I don’t know why you need to be snarky. I’ve been living this for over a decade with engineers with decades of experience who have done some of the most advanced electronics work imaginable (satellites, military drones).
To test and rework a surface-mount PCB, you may need:
- logic analyzer or oscilloscope;
- microscope;
- high precision soldering equipment/ability;
- solder paste and oven;
- cutting equipment to cut through 4-6 PCB layers and connect tracks with hair-width wire;
- Years/decades of education and experience to understand what to look for and what to do when you find a problem.
- rjh29 11d agoIf you made the PCB then you should be well placed to fix issues with it. You don't need years of experience , you have the schematic. A microscope (if you need it) is 40 USD. A logic analyser is 10 USD. Solder paste and hot air is only for specific parts and that is 30 usd. I am assuming 2 layer - 6 layer PCBs are very specialised (e.g. drones) The reason I'm being snarky is because it feels like you don't know what you're talking about. I know you're a mod so ban me or we but that's the impression I got.
- tomhow 11d agoIt’s a low move to suggest that I would ban you over a substantive disagreement in a discussion. I wouldn’t last a day in this job if I misused power like that. > If you made the PCB then you should be well placed to fix issues with it. You don't need years of experience , you have the schematic. A microscope (if you need it) is 40 USD. A logic analyser is 10 USD. Solder paste and hot air is only for specific parts and that is 30 usd. This is obviously at the extreme low end of the amount of experience and cost/quality of equipment you need to do serious work. Decent oscilloscopes or logic analyzers alone are several hundred dollars, and I didn’t even mention a programmer module, which is $500+ for a licensed J-Link. And you need to be a proficient C programmer. > I am assuming 2 layer - 6 layer PCBs are very specialised (e.g. drones) I am talking about 4-6 layer multi-MCU boards for reading from multiple different types of environmental sensors, connecting to multiple different network types (Bluetooth, cellular, satellite) and supporting multiple different power options (lithium battery, 12V DC, USB, solar). Painstakingly minimized power consumption, redundant data storage. Analogue front end for impedance readings of legacy soil moisture sensors. It’s a lot to get right together and to all work reliably in outdoor/remote contexts. But plenty of products that could be useful to reasonably large numbers of people (e.g. advanced home automation/robotics) would need to be comparably sophisticated. Elsewhere in the thread you’ve written: > PCB design is not that hard. People trying to offload this to AI are also unwilling or unable to put in the work to actually diagnose issues and finish the project. This is a dismissive value judgement against others whose circumstances you don’t know about. It’s clearly hard, relative to other kinds of technology work (web/desktop software etc), and not worth it if you can’t get to volume production and sales. So, sure, you can learn simple PCB design and get a simple 2-layer board in your hands in a month. Degree-qualified electronics engineers and companies obviously exist to provide the rest of the capabilities needed to get a serious product built and all the way to market and volume sales. It’s clearly not always as effortless as you’re making it out to be in order to justify the sneer.
- rjh29 10d agoI agree with you, high frequency is a totally different domain. But for the majority of projects, you don't need to buy special equipment. It's very accessible and PCBs are super cheap to print nowadays. I am definitely bitter (and biased) because I frequent a PCB review subreddit and increasingly people show up with zero knowledge expecting people to review their AI-generated projects for free.
- tomhow 10d agoFair enough, thanks for the reply and for understanding. I can understand that must be frustrating. I actually think another benefit of AI is that it can make it more realistic for people to self-educate and get further towards getting devices working without needing free help from forums. How they get help when they get stuck, without pestering forums like yours for free help is an interesting challenge. I still think the biggest upside of AI in electronics is for people who are experienced and competent, being able to get the laborious design/layout work done more quickly, get errors found sooner, get their designs right in fewer iterations, and get feature-rich firmware written and debugged faster. If true, that alone can mean more high quality electronics products hitting the market. That’s the point I was making. Nothing to do with newbies freeloading off experienced engineers on forums. Thanks for the discussion.
- foldr 11d agoAs tomhow points out, you are likely going to need more than just a multimeter. However, the hard part isn't whipping up a board that's 90% of the way there; it's the last 10%. I'm currently on revision ~11 of a hobby project which is far less complex than anything tomhow is talking about (4 layer PCB, 8-bit microcontroller, one analogue sensor circuit). Even the first revision of the board 'worked' for the most part, so I'm clearly not totally incompetent. It's just that the kind of polish that takes you a day or two of iteration if you're designing a web frontend can take months (or years, if you're working in your spare time) when you're constrained by manufacturing lead time and the need to test a physical object. There's a huge gap between "Yay! LED flashes!" and a marketable niche consumer product. Even just successfully putting the bloody thing in a box can require a lot of trial and error. The firmware is not to be underestimated either. In my case that's about 6000 lines of C. That doesn't sound like much, but writing, testing and updating C code targeting an 8-bit microcontroller is a whole different ball game to writing generic application code. The time investment per line is vastly higher. (In fairness, choosing an EFM8 instead of an 32-bit ARM part was probably a mistake on my part.)
- PennRobotics 10d agoI recently layed out and ordered a single-sided two-layer board with only a minimum config STM32 + crystal, two USB ports with ESD protection, and two LEDs (one is always-on). I went for commodity SMD parts and it still costs 20 USD per unit to produce and ship from China. Even that PCB doesn't work right now. [Sorry, dear reader. This post turned into a rubber duck session at your expense.] The main peripheral and reason for the PCB is a USB MIDI device with a bit of custom sysex. Modifying an Adafruit was out of the question; the MIDI peripheral powers itself and the microcontroller/host, and the other USB peripheral. (Basically always, the host shall provide power. This USB connector, however, was designed for a proprietary, discontinued, expensive accessory.) I chose STM32 over 8051 or AVR or RP2040 because it's the cheapest dual-USB chip stocked by LCSC with good vendor tool support. I'm writing my own code because there's no ST middleware for MIDI. The second LED should blink until both devices are plugged in and then remain steady, on. In testing, the LED visibly changes its timing after the second USB attach but doesn't stay on (rather, it blinks at a shorter and shorter period until simply shutting off, at which point the MIDI communication stops; the timing of the shutoff is not consistent) and the USB input events only register 40% of the time until the MIDI shutdown. The LED is misconfigured intentionally; it's open drain and GPIO while I try to fix the MIDI nonsense. Later, I'll change it to push-pull on TIM2 to support PWM brightness (e.g. to monitor audio levels when not in text entry mode). Changing GPIO to PWM is its own minor pain because the USER CODE lines in the ST USB code are separate from the USB_Init/USB_RegisterClass/USB_Start sequence, so I have to reinsert my MIDI class every time I change something in CubeMX even if I don't change the USB configuration. (The USER CODE sections persist so that you can change the chip configuration and keep your code.) Open-drain could explain weird LED behavior but not the communication shutoff. The MCU and LDO don't get noticeably warm, so I doubt it's an overcurrent situation. I suspect D+/D- could be at the wrong level. As most STM32s, the microcontroller runs at 3.3 rather than 5 volts. (I would've loved an atmega32u4 for its 8-bit simplicity and native 5V operation but then the PCB will be double the cost and size as I'd need a pair of MCUs talking to each other with each one having a single USB port or else an off-chip USB host IC etc.) Sure, I can use a cheap multimeter to test the USB data lines, but this tells me the average level and not if the waveform is being clipped on the positive side (which is usually only a problem under 3 volts). Even if it's an electrical issue, an oscilloscope will reveal the cause but still won't provide a solution. It'll be up to me to cobble together more circuitry. More probable is at least one code mistake, like a stack overflow or buffer overrun or peripheral misconfiguration/failure. I'm registering any expected USB class on both ports: HID and CDC and MIDI. The whole idea of the board is converting arbitrary USB input (PC keyboard, MIDI controller, joystick, etc.) into specific MIDI messages at standard USB data rates e.g. 12 Mbit/s at both ports with a fairly large buffer. The main MIDI device (supplying the power) will drop the connection after a few seconds of inactivity. I'm using an ST-Link V3 MINIE to step through, which is the cheapest I'd go on a debugger. Luckily I added SWO to my debug port and can still get useful debug info without stopping the processor. I also have to snip the power line of an OTG USB cable if I want the second USB peripheral to be a PC, which is a nifty hack you usually don't learn in the one month PCB design crash course. I have zero visibility into what the commercial USB MIDI device expects (bus speed, signal characteristics) from the discontinued accessory and only knew its connection handshake from a random, otherwise-inactive Github user's single commit. In any case, the USB algorithms I wrote work when the host is a PC and the code is ported to Python. I could reroute pins to ADC and roll my own built-in oscilloscope (it's QFP and not BGA chosen specifically that I can solder in a hotfix, because I've done board design before and know it NEVER, EVER, NOT ONCE EVER goes right on the first attempt) but I'd rather spend time with my kids than a choose-your-own-adventure debug hackathon in my disorganized home office, although I did fall into the IDE trap. Every few years, IDEs and toolchains and build systems change, and this project was no different. Rather than STM32CubeIDE, I took a few hours to teach myself to use the STM32Cube Core and marus25 Cortex-Debug extensions in VS Code, as that seems to be the current trend at ST, and I do favor a vendor-agnostic, Eclipse-free workflow. If this were my first project and I had to buy all of the tools for debugging, it would probably cost 200 euros or more even if I only buy cheap knockoffs. The other commenter suggesting a $10 logic analyzer?? I mean... I do own one of those, but it's barely tee-ball compared to the major leagues of Lauterbach or Rohde & Schwarz or even Saleae. In any case, I fear I'll need a new revision with its two-week turnaround or at least a manual rewire of this design. It's frustrating... such a simple design, and I've already sunk over 100 euros and at least 10 hours into it and have a bug with odd symptoms. And, as a PCB design tradition, I'll be humbled and humiliated when I discover it's something like a missing switch case or a wrong clock setting or otherwise relatively basic mistake. I'm not the first to state: There's a reason it's not called easyware.