Richard Memory Build Log


11/2/2017 - Verified basic electrical connectivity between Teensy 3.2 and CE Header. Using an Extech DMM, initially verified the power rails. For GPIO, I Used the Arduino 1.8.4 IDE, and modified the pin number (ledPin variable) of Tutorial1/Blink code, to toggle or blink each GPIO line in the CE Header by watching the voltage switch back and forth between 0 and 3.3 volts.


That’s good testing! Did you end up trying any of the I2C or SPI functions with the scope?


Not yet. Today was soldering and kicad notes (more of this tomorrow). I’ll be looking into the SPI and I2C first half of next week.


11/4/2017 - Soldered ICs to Sensor Board. The Koolertron 1080P came in handy to insure I have solder connection to the pads. Watched Thor Ragnarok, worked on my notes for KiCad usage and general design process (it helps my brain to have an overall view of the tools and the workflow). Also, took more detailed notes on the creation of the CE Header.


Great! Got a picture of the finished sensor board?


Finished soldering the Sensor board. Testing is next. Its not exactly a thing of beauty, but here it is.


Not bad! Looks like lots of flux, did you watch the skills video on cleaning up your board?


Great job! How do you like your Koolertron microscope?


Hi, Sorry, I didn’t see this post until now. I really like it. My only complaint is that it doesn’t have Linux compatible app. I have a Windows VM, which I use with it. All that said, I have found the Koolertron very useful.


I have been debugging my Sensor board. I started by debugging the ability to light the LEDs connected to the 74HC565 shift register. I started with the basic code mentioned by Chris in the “serial shift out” video.

The initial run of the code didn’t produce any positive results, meaning I wasn’t able to successfully cause any of the LEDs to light. Undeterred, I treated this as a debugging exercise.

Using my DMM, with a simple wire as a “probe”, I was able to determine Vcc of 3.3 volts was successfully being delivered to the 74HC595 chip, and also that ground was really ground.

In reviewing the code, I determined the latch pin was “high” be default, but I found the signal at the latch pin to be low. Working backwards, I also determined pin on the CE header (ie. pin 7) connected to the latch pin on the 74HC595 (ie. pin 12) was also low. The code shows the latch pin should be high at all time except for when “latching” new data from the shift register.

Continuing to work backwards, I found a bug in my layout. I had inadvertently assigned Teensy Pin 1 (USART Tx) to CE header pin7, and Teensy Pin 0 (USART Rx) to CE Pin 8. These are swapped from what they should be.

I created the following table to keep it straight my mind:

Latch = Teensy pin 0 == CE Header pin 7 == 74HC595 pin 12
Data clk = Teensy pin 13 = CE Header pin 5 == 74HC595 pin 11
Data = Teensy pin 10 = CD Header pin 6 = 74HC595 pin 14

After updating the code, I found that I was able to cause all but 2 of the LEDs to light up with the expected ascii values. The problematic LEDs were D5 and D7.

After a bit more probing and investigation using my microscope, I found a cold solder joint on 74HC595 pin 3 (LED D5, Ascii value 3). I was able to fix this quickly by just applying a bit of heat using my solder iron.

Using my Rigol DS1054Z oscilloscope and appropriately located test leads (thanks Chris!), and using an appropriately configured single trigger, I was able to watch the signals sent to the latch, clock, and data pins.

Channel 1 == CE Header pin 7 == latch == yellow
Channel 2 == CE Header pin 6 == Data == blue
Channel 3 == CE Header pin 5 == Clock = purple
Channel 4 == DC voltmeter for probing other areas of the board :slight_smile:

The attached picture shows a screen shot. There is 1 v per vertical division, and 2 us per horizontal division. The screen shot was captured when sending an ascii value of 3. The data pulse (blue) is indeed clocked out on the 4th clock signal (corresponding to pin 3 on the 74HC595).

Sorry, the colors don’t show up the picture quite a well as I’d hoped.

Each clock pulse is approximately 0.8 microseconds. On this topic, I took at quick look at the code implementing the shiftOut() function. It is written entirely in software, using a simple for loop where the width or time for each clock pulse is determined simply by how fast the CPU can iterate over that loop. Different CPUs would operate the shift register clock at a different frequency. A higher precision clock would require the device to be connected to I2C or SPI. Obviously not at all critical in this application, just kind of fun to look at.

It is also interesting to see the long RC decay curve associated with the latch signal (yellow), and how it takes a relatively long time (nearly 150x the rise/fall time of the clock pulses). Which is due to the 0.1 uF capacitor applied to the latch pin on my board (as per the data sheet). Cool stuff.

I eventually determined yet another cold solder joint on the anode side of the LED D7, which I fixed. My soldering skills are lacking, and quite frankly I don’t have a ton of interest in improving them (my primary interests are elsewhere). This experience is causing me to seriously contemplate either building or purchasing my own reflow oven and designing my boards accordingly. My hat is off to those who have professional solder skills. Its definitely an art form of its own.

This exercise has also caused me to strongly evaluate how and where to put effective “test points” in my hardware, to make it much more friendly for using an oscilloscope. Possibly the test locations can be removed during “production spins” of the hardware. Might also need to consider how a test point might affect circuit operation at high speed clocks (which I am not concerned about in the near term).


Super write up and nice troubleshooting.


This is an item I’m becoming more aware of as well. I still haven’t learned enough about where the points should be.


Yes, fully agreed. I’ve thought for example about adding through holes at “strategic locations”, into which I could just simplistically solder a header pin, where I could attach a probe. That said, I think I can see a few potential issues:

(1) As you mention, where to put them will definitely require some up front thought, and “up front thought” isn’t always my strong point :slight_smile:
(2) Extra stuff takes up actual real estate on the board. For this situation, its not a big deal because real estate isn’t at a premium, but on a very high density board it could easily become a problem.
(3) Should they be removed for during production, non-development boards (if so, how best to handle this).
(4) At what frequencies does the added test point become a problem, either with a trace or the pin itself becoming an antenna. I suspect I don’t have to worry about this scenario for a while yet :wink:
(5) Is a “header pin” the best idea in the first place, or are there other/better/industry standard mechanisms to use?


I think of test points like I think of mounting holes. I needed to take a few lumps in order to realize I should be prioritizing them on every board. I also like the idea of checklists and have written about it in the past, I think it’s relevant for doing something like that before sending off boards like this.


Chris, given my lack of soldering skills (and little interest on my part in improving my skills in this area), what are your thoughts about the wisdom (or not) of investing in a reflow oven, and designing my future boards accordingly? For example,

I realize there are reasons why this has some disadvantages. For one it means I cannot attach components to the back side of a board, at least not easily. I suspect you can point out others. I am just weighing the pros and cons.

Soldering isn’t a task I particularly enjoy, my solder connections are “buggy”, and it takes me much longer than I’d rather spend, thus possibly reflow might free up more of my time working on aspects I care more about.


That’s the one that I have, as do @Steve_Mayze and @hedrickbt. Can’t say I use mine all that much because I have one at my new workspace, but the Whizoo seems like a decent controller (and recently got a product refresh, now on rev 3). Honestly, nothing is going to replace soldering skills and there are certain things you should not be doing reflow for (small one offs, tacking on wires for monitoring voltages, etc).


That whizoo diy reflow oven works great. I haven’t had any issues with uneven heating, tombstoning, etc. so far. Great results each time. I laser cut my own mylar stencils too on a, modded, cheap eBay machine, so I am not even using the super-accurate stainless steel stencils so far.


@hedrickbt, thank you very much for you comment on installing the I2C libs on the “I2C TEMP SENSOR” project :-). That was very helpful.

I was able to verify my DS7505 is functional.

Temp: 25.00*C	77.00*F
Temp: 25.00*C	77.00*F
Temp: 25.00*C	77.00*F

Using my oscilloscope, with its I2C function, I triggered on the SDA line, also monitoring the SCL line, and I watched the data transmit to and from the device.

Additionally, thanks for the feedback from both @hedrickbt and @ChrisGammell regarding the whizoo reflow oven. It has officially entered my queue of things to buy/build.

FWIW, despite my whining on soldering, I do find the task of through-hole soldering itself to be kind of fun. Where most of my difficulties/frustrations arise are in the area of soldering SMD components.

All of that said, I have the following next steps in mind. @ChrisGammell, I’d like to hear your views (or anyone else as well). These are listed with no particular order of priority, the numbers are for ease of reference …

  1. Design a second generation sensor board. The primary purpose of the second generation board is to design with reflow in mind, and also to introduce a SPI device. I am not yet sure what this might be, suggestions are welcome. For example, an LED display.

Possibly I might also somehow consider how the devices (ie. shift register, LEDs, light and temp sensors) might be used together or interactively. All thoughts are welcome here.

Also, as part of the design, I want to include test points, and generally follow the hardware checklist mentioned by @ChrisGammell above, and refine the overall hardware design process use.

Alternatively, I can also move on to a totally different hardware design as well.

  1. Using the current hardware, implement drivers for all three devices using the Teensy C interface and gcc compiler.

  2. Develop a much deeper understanding of how to use and debug with my oscilloscope, in addition to using it as a logic analyzer. This can be accomplished with the current sensor board hardware.


As for a redesigned sensor board, you could potentially do it on a hot plate first; this would be easier if all the parts were on the top side, but you could always reflow the top and then hand solder parts on the bottom of the current board. The hotplate is a 20 dollar investment and would be a good chance to practice solderpaste application (and obviously ordering stencils).


As Chris mentioned, there will always be a need for actual hand soldering skills. Another option I’ve used for one offs and prototypes though was just using a hot air rework station and solder paste. I have a syringe filled with solder paste that I dispense by hand on each individual pad. Then I’ll go over that area with the rework station to reflow the components to the board.