I wanted to share this picture of a INA210 through a microscope. The size of this component is ca the same as a 0603 Component with 6 pins. It is small, but soldering it is not the issue – this bugger have 6 pins and where is PIN 1? I assume it is top left on the current picture, but smallest component I ever have soldered and unclear tagging – yeah – how fun.
I was a bit worried about soldering these for hand, but that seems to be ok with a hot air nozle as long as I can see between the legs and avoid short-cuts. This is a SC70 package it is 2/3 of SC23, and to be honest a 6-pin SC70 – the diodes did not feel so bad as they had 5 pins, but this was a struggle. I think I should consider an alternative solution, but lets see how well this Works first.
My main concern about the 3.3V PSU ripple is this schematics. It is the current sensor of my MC4X15A Motor Controller. As 3.3V is used as reference and ripple I might see sensor variations I don’t want – basically adding to the sensor noise.
This scope pic is from the 3.3V on my MC4X15A – Universal Motor Controller. The MCU is running and I have the 0.33F Supercap mounted. Ca 200mV point to point ripple is to much for my taste, but it works and this is far better than I have measured out of the Lab PSU’s. I am also using the DPS5005 in this case just to see if it worked at all.
This started as a small experiment as I wanted to see the effect of swapping out the inductor on my LMR14206 – I obviously need to revisit my lab PSU design. The lab PSU and scope is located next to each other on the shelf and I only need to switch it on to introduce noise – I don’t even need anything connected. I obviously have introduced a noise source in my lab that I need to figure out.
This is a set-back because I have been extremely happy with DPS5005 before this.
Returning to LMR14206 I seem to be stuck with 200mV point to point ripple. I am also puzled to as why I see the same ripple on 12V and 3.3V, but I will get some help investigating that. The actual reading on the scope pic is much higher, but that is the external noise. The ripple signature will differ a bit from using DPS5005 versus Thaoxin as they introduce different noise pictures. The small spikes you see above is the 1.25Mhz switching frequency of LMR14206 – and just for the record – it’s no problem adding a filter on the 12V and remove this ripple, but that add PCB size and complexity – part of the objective here was small space.
I decided to test my LMR14206 based DC/DC again and replaced the 15uH inductor with a 47uH inductor on the 12V design. The scope pictures was a shock:
This first scope picture show what I saw as 12V out. It is 12.2V, but look at that ripple picture of several voltages. To compare I scoped what I got out of my PSU and what a shock – I saw the same signature in and huge spikes & ripples out of the DPS5005 based PSU.
This is with no load and it show the same noise signature. The Scope above have different time scaling. Replacing the DPS5005 with the older Thaoxin I also instantly saw a different ripple signal from LMR14206 as can be seen below:
This is a bit better as we have 12.2V and +/-100mV ripple out. But, I need to go back and open my DPS5005 to figure out where the ripple noise is introduced.
Starting at left is a ESP32 Breakout board, then one of my own STM32F405RG breakout boards, a 5″ HDMI, Wireless keyboard and Raspberry PI 3 with my 5 port Hat – and your right it’s a different Hat with screw terminals, so I do have 2 x 5 port Hat’s working.
What I will do here is to wire up SPI between ESP32 & STM32 for testing, and I can add CAN breakout boards etc getting the boards to communicate. The only drawback here is that I can only use one SWD at the time, but I will get around that.
This shows a Raspberry PI 3 with a Communication Hat, Display and mini keyboard. This is basically all the hardware I need for a very advanced CAN Adapter & Analyzer. The main reasons I am skeptical is the wiring needed on this solution. Using a HDMI display is very powerfully, but you need a large project box for this. The total size and cost of the adapter adds up. I seriously which someone would create a more box-able display solution for Raspberry PI – one that take into account the Hat option.
This is a 5 port communication Hat mounted on a Raspberry PI 3. It contains 3 x RS485 and 2 x CAN ports. The design is not new for readers of this blog, but it is actually the first time I assemble rev 1.1 – just before I am about to order rev 1.2.
The colorfully display is because I am using 1206 led’s and saving old parts – all components on this was re-used from rev 1.0 boards. What amused me a bit is that as I mounted the MCU and switched Power on the old test program still worked. I have yet not broken a STM32 by soldering it on/off boards – quite impressive actually.
Functionally this Hat is ok, but mechanically I ordered a few Hat’s before I checked the drilling holes exactly, so rev 1.2 will correct this. I will also replace 0804 and 1206 with 0603 components + 2 leds per port is a bit overkill. I think if I reduce to 1 per port and mount them on the side that is better. Also cleaning up the line driver and replacing the 3P connector with a 4P for RS-X 12V + differential signal. I might have to make this a 2+2 port for that purpose.
I also want to do an experiment. Both CAN and RS485 are differential signaling, so I wonder if I can get RS485 to work with a CAN Tranceiver and what quality it would have? The issue is that if I can do this I can more or less make the 2 CAN ports switchable between CAN & RS485. It is worth a try!
I am just assembling one of my first Raspberry PI Hat’s With a 3 x RS485 and 2 x CAN for testing. The circuits below is what I used at the time. Rev 1.2 will use 3.3V only and remove the components crossed in Red.
It is a common error to add protection towards ground, but what you actually do is to force ground to be part of the signal. RS485 and CAN are both differential signals that should not need ground. If you need protection use the galvanic Versions! Even worse, the “protection” will disturb your signal quality at higher speeds.
Another issue here is that RE and DE is connected – this works, but it prevents some options – etc reading as you send to detect conflicts and disabling both sending and receiving etc.
The rev 1.1 also used some 1206 Components and a mix of 3.3V and 5V, as well as a XC6206 3.3V regulator in SO23 package. This will all be replaced with AMS1117, 0603 packages and 3.3V Components. Rev 1.1 also had the mistake that I implemented ground plane on both sides – it is not realy a mistake as such, but it makes it harder to assemble prototypes by hand.
Since we talk about galvanic RS485 & CAN Adapter’s I guess it is time to visit this project as well. The universal adapter below was something I started last time I needed CAN. This adds W5500 and ESP12-E + NRF in addition to CAN & RS485.
I never made a revision of this Board, but it served a purpose to test CH340G, STM32F405RG and ADM2582E together. The Board above with the added coil was after my struggle to get STM32 ticking at 168Mhz.
I never tested ADM3053, so that is what I will do next. I see no point sending for a new PCB including parts of this design before I have completed this test.
As for the adapter above – this has in many ways been a big success because I have corrected and re-used a lot of the design I did here, but I will not finish this adapter as such. ESP32 is so much better than the ESP12 or ESP8266 based options. I do however have things left to test on this Board.
This is the rev 1.2 of my 5 port Hat with 3 x RS485 and 2 x CAN. I never ordered this PCB because it is only mechanical changes from Rev 1.1. But, using this or a galvanic version with Raspberry PI is an option for my CAN Adaptor plans.
The advantages with this is that Raspberry PI have an excellent HMI option. It would also enable a PLC style adapter where you add on what you need – but it would be a much larger solution as well.
The size difference from a packed, single board solution is not dramatic and it offer other options as you get a proper display, keyboard and a full Linix computer to back it up.