Project Logs

Collapse

• Loop Response Measurement

  Jesse Farrell • 03/02/2025 at 04:30 • 0 comments

  I got side tracked again! This time “designing” an injection transformer to analyze the loop stability of the power supply. No need to reinvent the wheel thanks to Wolfgang Griebel. They posted a DIY injection transformers investigation where they found a core that was extremely comparable to the Omicron b-wit100. The DIY version was named the NVT-1. If you’re considering purchasing an injection transformer, and have a tight budget, I’d highly recommend rolling your own!

  FYI - I’m not really concerned about the loop stability of this system. This is just a learning exercise!

  I ended up ordering a better enclosure for the thing, along with an insulated BNC connector to add a bit of polish to the homebrew solution.

  Happy with the performance (shown in first image, extremely flat between 100Hz to 1Mz), I moved on to analyze the loop stability of the buck converter on this project. If you’re unfamiliar with loop stability analysis there’s countless papers on the subject. For example; Analog Devices – Understand power supply loop stability, Rohde & Schwarz – Tips and tricks on how to verify control loop stability, Texas Instruments – How to measure the loop transfer function of power supplies, and many more.

  I’m going to validate the loop stability by injecting a signal into the feedback network, and observing the outputs response. We can then graph the gain of the signal, as well as the phase shift. From this transfer function we can pinpoint the gain and phase margins, which allows us to make some conclusions regarding the stability of the system. It should also be noted that the response will change based on the systems state. To fully characterize the stability of the system you would need to test all possible operating points. For example, just because the system is stable at 10V wouldn’t guarantee stability at 5V. Even changes in temperature will influence the system. Have a read if your interested in the subject!

  ---

  Now that I’ve made an injection transformer, and done some reading, we can turn to the PCBA. I connected the transformer output across R75, and probed either side of the resistor with an oscilloscope (enjoy my paint diagram below). I was somewhat concerned about the downstream components, so I started with a very low-level signal.

  The result surprised me! When I first tried to test the system using the above wiring, I saw nothing on the output. I probed pin 4 on U1 and confirmed the injected signal was indeed making its way back to the chip. Eventually I was able to get the output to somewhat follow my injected signal, but it was only when the injected amplitude was uncomfortably large. Furthermore, the output seemed distorted (almost clipping as if it were half rectified).

  I ended up blaming the various IC’s on the 3V3 rail for affecting the systems behaviour. So, I got to work soldering a new PCBA, only populating the PSU and various caps scattered around the board.

  Afterwards I injected the signal again, and was surprised to see the system was mostly unresponsive (see below captures). The injected signal is channel 1 (yellow), and the output is channel 2 (purple). The only way I can influence the output is by using a very low frequency signal.

  At this point I realized I’m testing an unloaded system. As a result the switcher is in PFM mode. The expected load on 3V3 for my application is 340mA. Setting the eload to this value, I finally saw the behaviour I expected.

  Here’s the system response when injecting a 1kHz 200mVpp signal. Notice the injected signal is much lower than the 200mVpp I expected, yet the output is suspiciously close. It seems like the system is fast enough to compensate the injection. Neat! (and probably expected)

  Here’s the system response using a 200mVpp injection signal. If I wanted to cleanup the response, I could use variable injection levels to cleanup the higher frequencies.

  Eureka! We’ve characterized the closed loop response for this one operating point! 

  At 5Vin and 340mA,...

  Read more »

• LAN95xx EEPROM Programming

  Jesse Farrell • 02/04/2025 at 05:35 • 0 comments

  This is a bit of a follow-up from one of my previous logs (Auto-Negotiation Issues). At the end of that log, I came to the conclusion that I could resolve the issue by disabling auto-negotiation in windows device manager. This was just a temporary solution. For the long term, I wanted to investigate using the EEPROM to store the default configuration of the PHY. 

  So long as you are using a supported EEPROM, then the process of programming it is very pain free. You can use either the “LAN95xxUtility-v3_2_0_0 GUI” or “9500eeepApp_V2.5” both of which can be found here on Microchips website. As you might expect the GUI application provides… a GUI… whereas the second file provides an executable that can be called from the command line. In my mind the GUI application (LAN95xxUtility-v3_2_0_0 GUI) is useful for quick test work, whereas the executable (9500eeepApp_V2.5) would be invaluable for manufacturing in volume. 

  Let’s first look at the GUI… When you first launch the app you’ll be greeted with a device connection window. In my case it recognized the device as LAN9513/14 and the EEPROM size as 512KB.

  The LAN95xx Utility then launches, with the below window. Checkout the readme on microchips website if you want to read into the details… but it’s a pretty nifty tool! For my project I’m modifying the manufacturer, product and configuration strings, but most other settings are left at their defaults. 

  Without thinking I bumped all the power requirements for my device to 500mA. I also changed the power type from self-power to bus power. I thought this would give my USB device the max power that the host USB port could provide… Instead I locked myself out and effectively bricked my device. -_-

  My device is bricked (more locked really) because I wrote an invalid configuration to the EEPROM. I wrote a power requirement so large that no port dare enable it. As a result, every port I tried in my lab, whether bus powered or self-powered refused to connect to the device. I can’t just write a new binary to the EEPROM because I rely on the LAN95xx controller to do the programming. Since windows won’t connect to the device, I can’t reprogram the EEPROM, and because I can’t reprogram the EEPROM, windows won’t connect to my device (it’s a chicken and the egg conundrum of my own creation). I reordered a new EEPROM and went back to the drawing board. (Maybe I could have used the command line tool to wipe the EEPROM? Future thing to try...)

  Where I went wrong? Let’s do some reading…

  Bus-powered hubs: “Draw all of their power for any internal functions and downstream facing ports from VBUS on the hub’s upstream facing port. Bus-powered hubs may only draw up to one unit load upon power-up and five unit loads after configuration. The configuration power is split between allocations to the hub, any non-removable functions and the external ports. External ports in a bus-powered hub can supply only one unit load per port regardless of the current draw on the other ports of that hub. The hub must be able to supply this port current when the hub is in the Active or Suspend state.” [USB Specification 2.0]

  Self-powered hubs: “Power for the internal functions and downstream facing ports does not come from VBUS. However, the USB interface of the hub may draw up to one unit load from VBUS on its upstream facing port to allow the interface to function when the remainder of the hub is powered down. Hubs that obtain operating power externally (from the USB) must supply five unit loads to each port. Battery powered hubs may supply either one or five unit loads per port.” [USB Specification 2.0]

  Now that I understand the standard a bit better I first flashed the NEW EEPROM and confirmed it was working. Next, I increased the current requirements to something more reasonable and tried flashing the EEPROM again… And CRAP! Not again!

  At 250mA I’m locked out of thing. Once again on every USB port I have semi-bricked...

  Read more »

• Overcoming USB Overcurrent

  Jesse Farrell • 02/03/2025 at 05:50 • 0 comments

  I was using the device for awhile without any capacitance for the downstream ports. When I finally added 120uF to each of the 3x USB ports I was blessed with a symphony of windows device connect/disconnect notifications.

  It doesn’t take much effort to theorize the issue. The second the USB load switches are enabled, and the 120uF bulk capacitors are allowed to charge, the host is hit by a tremendous di/dt demand. This could either trip overcurrent at the host, or it might just sag the local 5V rail enough that it resets the device.

  Here’s the critical sections of the circuit WRT this issue. When I first designed the circuit, I read up on the USB protocol, and noticed it called for 120uF for each port… I slapped down 270uF since that’s what I had in my parts bin. I later dropped this down to 120uF when I observed the first connection issue, but the behaviour was unchanged. (foreshadowing - spoilers I should have read the spec more carefully!)

  First things first, I had to do some fact finding to understanding this issue better. Here’s a waveform of the general power up sequence.

  The waveform shows the enable lines (ENB1 and ENA1) from the schematic, external 5V provided by my trusty bench PSU, and the current on the 5V line. Note that when the enable lines are HI, they enable the output of U4 which provides power to the USB devices, hence charging the 120uF caps.

  There seems to be two spikes on my current waveform (channel 4 – Green). One which occurs while 5V is ramping, and another that occurs ~200ms afterwords, when the enable is asserted.

  Let’s check the first enable… 

  Yikes!!! There are actually two pulses that saturate my current sense amplifier (CSA) which is clipped around 850mA. One spike occurs when the device is first connected to power. This is reasonable enough since there’s some significant capacitance on the board. The second spike is more concerning since it seems to be caused by my enable pin floating high and allowing the USB ports to be powered on briefly.

  Checking the datasheet for my USB load switches (MIC2536) shows we’re right in the ballpark of their enable thresholds.

  I briefly probed the 120uF cap with channel 2 to confirm it was truly being enabled, and yup that cap sure is charging!

  I started to toy with ideas relating to the power sequencing of the project. I could (1) delay the 3V3 startup, (2) slow down just the pull-up (PU) voltage somehow with some clever passives, or (3) just remove the damn PU’s entirely.

  Idea 3 was easiest to investigate first, and seemed reasonable based on my foggy memory of the LAN95xx chip. That fog was cleared by a quick reference to the datasheet. The LAN95xx does indeed provide its own internal PU, which in theory wouldn’t be applied until it enables itself (hopfully near that 200ms mark we saw earlier). 

  Removing the PU resistors resolved the false trigger issue, see result below. Next up is the massive pulse from the bulk capacitors.

  Hindsight is 20/20…. 120uF per HUB!

  Here’s a zoomed in look at the massive gulp of energy those 4x 120uF capacitors demand. The current waveform is completely clipped. I expect the true peak current approached 2 or 3 Amps. I did some investigation into different load switches with better current limiting/soft start features, but didn’t find much that fit the bill. Then it hit me…

  While designing the board several months ago, I remember thinking 120uF per port seemed ridiculously large, but I sort of shrugged it off. After working on the bug for a little too long I thought I’d better double check the standard. And yup I missed a crucial declarator… its 120uF per HUB minimum! Not per port, Doh!

  Now we can safely decrease the capacitance at each port to 47uF.  Decreasing the capacitance to 47uF and rebooting yielded the waveform below. It seems like 5V no longer sags to the same extent as before, but the overall current draw is still far too large (once again...

  Read more »

• Auto-Negotiation Issues

  Jesse Farrell • 12/01/2024 at 21:38 • 0 comments

  So, I have 2 of my 7 assembled boards that weren’t working as expected. I was able to quickly narrow it down to the connection between the two PHY’s (uh-oh). Immediately I was suspicious of my home-brew coupling network that replaced the magnetics we normally see.

  After a lot of sniffing around the circuit I wasn’t able to see anything out of the ordinary. FLPs (Fast Link Pulses) were being sent and received by both PHYs, but no link was ever established. I ended up comparing to some of my known good PCBA’s and noticed something interesting about the FLP of my problematic DUT. 

  Here’s what the FLP’s look like that are being received by the IC+ PHY on my problematic unit.

  And here’s what those same signals look like on a working device.

  Very odd. I thought this difference could be caused by a lack of Vref on IC+ (since the rail seems to sit around 3V3 when I’d expect it to be closer to 1V8), but after looking closer at the supporting passives around the IC+ PHY everything seemed in working order. 

  I also took some wider captures of the entire startup hoping to gain some insight, but there was nothing else unique I could find between my two DUT’s.

  This issue led to a LARGE LARGE LARGE rabbit hole of trying to read the internal registers of the Microchip PHY (the one sending the above pulses). There are some very handy registers that would have helped me debug this issue (see below).

  Sadly, I burned half a day trying to configure a system to read/write the registers of the device using blueTag and OpenOCD. BlueTag was able to recognize the device, but past that I was never able to make any significant progress in this endeavor. 

  To unstuck myself, I decided to disable auto-negotiations since that’s where everything seemed to be hanging (you can do this just in device manager). Doing this resolved the communication issue. If this is the fix I choose to implement it means the end user would have to muddle around in device manager before using their HUB (not ideal). 

  So, I have two options to investigate further. (1) Redesign the coupling network to resolve the auto-negotiation hiccups, or (2) add an EEPROM to the PHY that will store the default setting as 100base-t. Both of these options are supported by the copper on rev 1.

• KiCad Variants with Python

  Jesse Farrell • 11/24/2024 at 01:12 • 0 comments

  Mini side quest time!

  So I recently watched a video from Psychogenic Technologies and learned he made a Python package that lets you easily interact with KiCad Schematics. My mind immediately jumped to PCBA variants. The same weekend, I launched VS Code and started scripting. I later learned I should have searched the web more first… There is already support for variants in KiCad and it was added this year (?) via the KiVar plugin. It looks like KiVar is very well maintained and fleshed out, so if you’re looking for variants in your KiCad project I’d highly recommend you go there.

  Alas it was too late; I already created my own python module to create BOM variants. I made my github repo public, but unless you have good reason probably just use KiVar 😉

  Anyways here’s my hacky way to get BOM variants into my project!

• Enclosure Updates

  Jesse Farrell • 11/11/2024 at 20:58 • 0 comments

  I've been working on an enclosure in the background using fusion 360. I have a couple tweaks to make to the enclosure, but for now this is what it looks like. STL files have been added to the project files. For future updates to the enclosure I'll edit this log.

• Blender Render - Side Quest

  Jesse Farrell • 11/07/2024 at 16:46 • 0 comments

  I opened up blender for the first time in two years to test out the pcb2blender plugin for Kicad (here). Shown below was my first attempt. I'm pretty happy with the results, but there's still lots of tweaking/learning ahead  [those LEDs for example]. I'll update this log later when I have some more time to play with the tool.

  Update - The next morning I was able to create this one. I'd really like to learn how to generate a realistic glow on the LEDs, but I think that will have to be a full weekend project. Coming from other CAD tools like fusion and KiCad, Blender has a very unintuitive user interface (I did the donut tutorial, but that was >2 years ago now).

  Second Update - I spent Saturday learning how to create a short animation, and how to create a more realistic lighting affect on my LEDs. For the LED’s I ended up separating the mesh using the “bisect” feature, and assigned a different material to the transparent portion of the LED. Then I placed a small point light source inside the transparent material. I did similar for the RJ45 connectors.

  To make the light blink I followed this handy tutorial (How to Make A Flickering Light in Blender), and for tips on the animation workflow I followed Blender Guru’s legendary donut tutorial (Part 12).

  Here’s the end result....

  In the future, I’d like to do another animation including the enclosure, and have the components dropped onto the PCBA. For now though, I’ll call my Blender side quest a success.

• Documentation Update

  Jesse Farrell • 11/04/2024 at 15:59 • 0 comments

  I did a big documentation push over the weekend and added 3000 words to my hardware architecture spec document. If your interested in the details of this project, or are looking to do something similar I recommend you take a look in this projects attached documents. 

  Note, its still technically unreleased since I need to add sections for creepage and clearance, validation and likely some other sections which don't exist yet.

• Rev1.0 Release

  Jesse Farrell • 10/20/2024 at 15:22 • 0 comments

  Quick update: The next revision of the board has now been ordered through JLCPCB. I’m using pick-and-place for about 95% of the board. The remaining parts are straightforward to solder or a one-off part. I couldn’t justify paying the reeling fee for the extended part.

  REV1.0 – Layout

  REV1.0 – 3D Model

• Creepage & Clearance - Attempting Standards

  Jesse Farrell • 10/09/2024 at 05:15 • 0 comments

  While I don’t know if I’m truly a green engineer anymore, I’m definitely a little wet behind the ears when it comes to standards. I thought it might be a good exercise to determine the creepage and clearance requirement for isolation on my ethernet circuit. The result was/is a large can of worms.

  ---

  What are the requirements?

   I’ve seen the requirement waved around on several occasions… ethernet transformers are designed to survive 1500Vac, and sure enough looking at 802.3 (IEEE standards that outline ethernet) you can find this spec listed in various locations throughout the PDF. Interestingly its only ONE of 3 possible isolation tests. from 802.3; “this electrical isolation shall withstand at least one of the following strength tests”. The other options include being exposed to 2250Vdc or a short impulse.

  Bare minimum – Withstand 1500Vac @60

  ---

  Approach Number 0

  The zeroth approach might be just to look at the IPC-2221B(?) design standard for C&C (creepage and clearance) recommendations. I didn’t go down this route. Though this standard can be invaluable, I don’t believe any safety standard would point us in its direction.

  ---

  Approach Number 1 - Start from the directives

  My first thought was to start from the directive and work down to the product standard, if one exists. I’m a little more familiar with the EU framework, so I’ll start there by looking at Harmonized Standards listed by the European Commission.

  Scrolling down the list there are several directives that would be of interest. General Product Safety (GPSD), Low Voltage (LVD), and Electromagnetic compatibility (EMCD). I’m adding the “D” here in the acronym since I’m referring to the directive (though I think GPSD is now a regulation?).

  NOTE. If you click on the directive and scroll down to the bottom of the webpage you can look at a “summary list as pdf document”, this is how I found the list of harmonized standards for each directive.

  Not having too much experience with standards my C&C spec could be hiding under any one of GPSD, LVD, or EMCD. I quickly learned my product doesn’t fall under the LVD since that directive covers “electrical equipment operating with an input or output voltage between 50-100Vac or 75-1500Vdc”. From the GPSD, it seems like I need to consider EN IEC 62368-1:2020, this standard concerns “Audio/video, information and communication technology equipment – Part 1 : Safety requirements”. My project is essentially a big communication adapter, so I believe it would comfortably fit here. From EMCD I’ll be looking into EN 61000-6-1:2007, EN 61000-6-3:2007, EN 55032:2015, and EN 55035:2017. These standards relate to immunity/emission “for residential, commercial and light-industrial environments” and “Electromagnetic compatibility of multimedia equipment”.

  Already I’m not a happy camper, this is a lot of overhead to get one value…

  After looking at each standard, it seems like 62368-1 has the info I need. Table 14 provides the “minimum clearances using required withstand voltage”. If I assume the definition of withstand voltage is the same between IEEE 802.3 and IEC, then I should be able to read the clearance right off the table. The lingering question is, does my application require reinforced insulation? Very likely it doesn’t, but I want to know how to find out.

  I read the entirety of the standard the next day and I wasn’t able to gain much clarity over my initial understanding. So much of the C&C is depended on a mains connection, which I do not have for my product. I’ll do some more reading but the expected C&C value is 1.5mm.

  Expected Clearance Requirement 1.5mm

  ---

  Approach Number 2 - When in doubt, phone a friend

  Every product with a CE mark needs to have a declaration of conformity (DoC) that outlines which standards the product complies to. If we can find a similar product’s...

  Read more »

View all 15 project logs