Project Logs

Collapse

• 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 »

• REV00 -> REV01 Fixes

  Jesse Farrell • 10/08/2024 at 04:14 • 0 comments

  I’ve returned from travel and started working on cleanup for 1 of 4 of my projects… this one I’m most excited about so it’s the chosen one.

  Based on my spark up I had a number of errata items to address. More than I’d care to admit; but in my defense this was somewhat by design, since I knowingly pushed the board to fab without running a number of my final checks. Everyone knows that the last 5% of the project is where all the work hides… sometimes its easier to debug in HW than to pour over datasheets for minor oversights.

  1) IC+ I1P75Gx – Termination Resistors

  We don’t need them parrallel/shunt termination for this PHY. It even says on the front page of the datasheet (BUT LITERALLY NOWHERE ELSE!!!) “built-in 50 ohm resistors for simplifying BOM”. Removing the 50ohm parallel termination resolved the comms issue I was having.

  2) USB Ports – Increase Capacitance

  I hadn’t read the spec before I did my design (a horrible sin). As a result, the capacitance on my USB ports are woefully out of spec. From the USB standard “downstream facing port Vbus power lines must be bypassed with no less than 120uF capacitance”. So, I’ll add 150uF electrolytics to each port.

  3) USB Port Pinout – Footprint Error

  I made a custom footprint for an interesting side mount USB connector… I should have triple checked the part. The ports are completely flipped. Instead of VBUS/D+/D-/GND, my footprint had GND/D-/D+/VBUS. To test the circuit for spark up I had to make a disgusting bodge. But it worked!

   4) FTDI – Pinout Error

  Another dumb mistake. I had my D+/D- flipped going into my RS232 converter. Nothing a bodge can’t fix though.

  5) Clock Stability – Bug

  My first board worked fine, but the second seemed to only briefly bootup, then power off after a few seconds. I was able to narrow it down to the clock on the USB to ETH adapter. I had to add a 1M feedback between XI/XO to ensure the clock remained stable (or would it be instable…). I already had the footprint there it was just DNP’d. Easy fix, no bodge this time.

  6) Power Switch Variant

  To toggle the power to each USB port I’m using a pair of N channel power switches (MIC2536). These were jellybean parts recommended by a reference design so I didn’t give them much thought. This lack of thought led me to buy the first variant I saw MIC2536-2… the enable is inverted on this version, what I needed was MIC2536-1. To continue spark up I just tied the enable to the appropriate rail.

• A Transformerless PHY to PHY Connection – Success (Sort of)

  Jesse Farrell • 05/29/2024 at 06:11 • 0 comments

  I was able to get the connection between the two PHY’s working, but more tuning is needed. As it stands, these are all just “eye-balled” values, and that really doesn’t sit well with me. What I really need to do is read the 10BASE-T and 100BASE-TX standards to better understand the underlying protocol. Even understanding the protocol, I still don’t know the exact architecture of either PHY. Nevertheless, I’ll post the results I have so far to document the journey.

  I’ve collected some A/B comparisons for the transformer (xfrm) and xfrm-less solutions. The control uses a Pulse H1102NL, and the xfrm-less solution uses either a resistor or capacitor in its place.

  So first let’s look at the change to TXP/TXN shown above. This signal is driven by LAN9514 (Current-Mode), and the MOD was a small series resistor. The main thing I noticed is a shift to the peak-peak value, and the dc-offset of the signal. I’m impressed how well it handled this change in impedance. 

  That was the sending end, now let’s see what’s received by I1P75G (net HUB_RXIP/N above). Its okay, though somewhat overly attenuated. I suspect some tweaking would be beneficial here!

  Next, we’ll look at the data on the sending end of voltage-mode driver (I1P75G). The MOD here was a pair of 100nF coupling caps. 

  I believe the ringing on the STOCK circuit can be explained as follows; When both HUB_TXIP(N) are equal then there won’t be any current flowing into the windings of the xfrm and it appears high impedance to the driver. Moreover, any small amount of current that is conducted through the center-tap and its small capacitor would be impeded by the common mode choke. Both these factors effect the load impedance seen by our voltage-mode line driver. 

  Lastly is the received signal at LAN9514. The signal looks great, but the DC offset is in need of some attention. The received signal is biased to 3V3, as a result the AC coupled signal rides on-top 3V3 and throws it up/down by 500mV. As a result, I’m likely overstressing the LAN9514 receiver.

  Transmission Line – Realization

  After stressing about the termination of the signal for longer than I care to admit, I came to the realization that its not particularly critical here. The rise times are ~3ns, so the frequency is approx. 117MHz (0.35/3). In FR4 that frequency has a wavelength of ~1.208meters. So the critical length would be about 60mm (λ/20), depending on who you ask.

  I’ll keep this in mind for my next round of changes. Atleast the link b/w my two PHY's is stable now!

• A Transformerless PHY to PHY Connection – Failed Attempt

  Jesse Farrell • 05/24/2024 at 04:55 • 0 comments

  The connection between the USB-ETH controller and the ETH switch doesn’t need to be isolated. Its on the same board with the same reference plane. I’ve included the transformer for now as a failsafe, but there’s a network of DNP’d parts on the backside of the PCB that will hopefully replace the transformer in REV01 (cost savings!).

  There are several application notes that outline transformerless PHY-PHY communication, but the exact implementation depends on the line-driver topology, and seems pretty silicon dependent. A good overview of the two line-driver topologies is provided in ENT-AN0106. The main takeaway are the two images shown below. 

  So how can we accomplish this without the transformer? There’s no reference design or app-note for my specific devices, so I’m going to need to do some research to better understand the topic. Based on the termination of the devices I believe LAN9512 uses a current-mode line driver, whereas I1P75G uses a voltage-mode line driver. Linked below are several app-notes I read to help design the interconnect.
  

  AN2190 - Transformerless Applications of Microchip’s Ethernet Devices (Current-Mode)

  TLK110 - Ethernet PHY Transformerless Operation (Current-Mode)

  RTL8305SC – Single Chip 5Port 10/100MBPS Switch Controller (Current-Mode)

  ANLAN120 – Capacitive Coupling Ethernet Transceivers without Using Transformers (Both Modes)

  ADI WIKI - ADIN1300 and ADIN1200 with Capacitive Coupling (Voltage-Mode)

  SNLA088A - AN1519 DP83848 PHYTER Transformerless Ethernet Operation (Current-Mode)

  Interfacing Intel® 8255x Fast Ethernet Controllers without Magnetics (Current-Mode)

  Maybe I was worried for nothing, the transformerless design looks suspiciously simple... In nearly every document the transformerless application is just a coupling capacitor placed in the signal path b/w the two PHY s. See example below from AN2190 (Current-Mode).
  

  Shown below is the existing biasing network for the current-mode line driver (LAN9512). Based on everything I’ve read I should just be able to remove the magnetics along with its supporting CT bias, and couple each data lines with a >15nF capacitor.

  On the voltage-mode side. I believe I’m able to directly connect each line to the coupling caps, since (I recently discovered) the device is internally biased. The final network is shown below.

  Oh boy does this not work. Probing the voltage-mode side (I1P75G), it seems like the bus is floating. It periodically droops down to GND, then shoot back to VCC.  I was able to get the link working but I’m still not happy with it… will discuss my solution in the next post.

View all 12 project logs