Component analysis (Hardware V00G)

Last week, the voltage boost circuit would barely get above 12 volts.  This would work for most devices but I had set my goal at around 20v. I rechecked datasheets to verify I wasn’t operating out of specification.

Diode D1: The voltage across this diode is really close to 12V when Q5 is on and C14 is charged. From the datasheet, the reverse breakdown voltage(Vr) for and SD103 is 40 V.  This is a fast switching Schottky diode. This is probably not my problem.

FET Q5: The voltage across the drain to source will also reach around 13 Volts when in the off phase of the pulse stream.  The drain to source breakdown voltage is 50 V. This transistor can switch fast enough even at 80MHz.  This is probably not my problem.

Resistor R5: I chose to use 100 Ohms when I populated the PCB.  I am definitely seeing a voltage drop at C17 when driving to around 12 Volts.  If this is the problem, I will not even be able to get to 12V when running on the lithium cell. I think this is causing the problem.

To test this, I decided to change the resistor to 47 Ohms and redo my testing.

I tested with a prescaler of 0, 1, 2, and 4.  With a prescaler of 4 I got 20 volts with the duty set to 51.

Analysis and testing revealed that the filter resistor R5 was too much resistance.  By changing it’s value to 47 Ohms, I was able to get the circuit operating the way I wanted.

I made no changes to the software other than changing the prescaler.  For this firmware, that is a value that I expect to be played with, so no firmware upload this week.  I did change the value of resistor R5 to 47 Ohms.  So I uploaded a new version of the hardware to GitHub.

I would like to see smaller steps between voltages, I am thinking of changing the inductor to a smaller value to improve efficiency and control.  I am not sure this works, but it might be worth a try.

I am still working in an area of electronics I don’t understand very well.  This is the first time for me to design a switching voltage boost circuit.  Do you have any suggestions of how to do it better? How about stories about your own experience with switching power supplies.

Update to SDK 1.5.4 Firmware V00J

Since I don’t seem to be making any progress on the Sigma Delta output, I decided to update my copy of Espressif’s API. I went to bbs.espressif.com and clicked on the SDKs thread under the heading DOWNLOADS. In the list i looked for the most recent Non OS SDK release.  I saw that ESP8266_NONOS_SDK_V1.5.4_16_05_20 is the most recent release. It’s file name indicates a release date of May 20th 2016.  I downloaded the zip file and extracted the contents.

To Make moving forward a little easier, I renamed the SDK folder to UProgrammer.  This will help me maintain paths the next time I move to a new SDK Version.  Each time I update to a new SDK, I will Rename the OLD SDK folder to indicate it’s version number, and rename the new SDK folder to UProgrammer.  To maintain compatibility with Github’s folder naming, I will continue to keep the UProgrammer-Firmware folder name for the project files.  This folder will be sitting in the SDK folder I just renamed to UProgrammer.  I then created an empty text file with the name of the SDK file to mark the version I am working in.  Then I copied the hidden file .metadata from the old SDK folder into the new (UProgrammer) SDK folder.

I opened eclipse and pointed the workspace to the UProgrammer folder and it loaded the files as if I hadn’t changed anything. Then I made edited the comment block at the top of the file to indicate I had moved to NONOS SDK V1.5.4.  I saved the file and then checked the file in the new directory structure for the changes. It has the change I had just made.  To make sure there wasn’t something weird going on, I also checked the file in the old directory structure. It was unchanged.  I had planned on dealing with more problems just in case they happened.

I compiled the code to see if anything broke moving to the new SDK.  Things definitely broke. First the files all compiled but linking failed.  The first error message was:

section `.irom0.text' will not fit in region `irom0_0_seg'

This reminded me that I modified the linker file eagle.app.v6.ld to allow for more room for the code space in a 4MByte flash chip.  I made the modification to the new file and saved it.

Modified linker file

I tried compiling again.  Again it failed to link but I was no longer getting the memory failure. This time the first error message was:

 undefined reference to `uart0_sendStr'

I didn’t have the most recent programming reference, so I went back to bbs.espressif.com to download it.  I got the 2C-ESP8266_SDK_API Guide_EN_1.5.4.pdf.  It turns out uart0_sendStr() isn’t in the documentation.  So I looked in my code to find it.  I found the prototype for it in uart.h. but it doesn’t appear anywhere else. This makes me wonder how I was compiling last week.  I did find it in uart.c in the drivers folder.  At one time that file was part of the project. I am guessing the object file was still getting linked in to the project.  The compiled object files are in hidden folders and didn’t get copied by default.  (It’s a good thing.  The versions of code on Github would not have worked. Now they will get fixed.)  I copied The code for uart0_sendStr() into simple_serial.c and recompiled expecting it to fail because uart0_sentStr() calls something else in uart.c.

Again I looked at the first error from the linker which was:

../lib/libat.a(at_ipCmd.o): In function `at_set_rx_buf_state':
(.irom0.text+0x10ac): undefined reference to `espconn_secure_sent'

I am not using any secure features or any AT functions, so I decided to look at the make files. I used a Linux tool called meld to compare files.  There were very small differences.  Looking at my makefile, I noticed four lines that effectively added the -lat linker option.  I commented out those 4 lines and recompiled.  Now the linker only has 4 errors remaining, all of which can be fixed by copying code from the uart.c file.  After copying each function I needed from uart.c, I finally got a successful compile of the code.  I then uploaded it to the PCB to see if it still runs.  It ran the wrong code.  I now get a message in the serial terminal “dmode : softAP (XXX) indicating it is booting up as an access point.

I was able to connect to the device and dhcp worked, but an attemp to connect by http was refused.  Since the messages are system messages I decided to try a UART Swap. No change in the behavior.  I need to do a sanity check, this is a new API so back to doing a Hello World test. I finally got confirmation that my code is what is being uploaded to the module.  I placed the following function call:

system_set_os_print(0); // Turn off System Messages

into the code. I am no longer getting any output in the terminal.  I wasn’t getting any error from compiling but it turns out the function uart_tx_one_char() needed to be copied from the uart.c to simple_serial.c I chose not to have uart.c to reduce code size, there is a lot of code in uart.c that I will never use.

I cleaned up some of the things I tested recompiled and posted a new copy to Github. Do you have any tips for migrating between environments? I’d love to hear about them.

Making, Hacking, and or Engineering.

I am waiting for PCBs to come in and hardware testing is next on my agenda for the design. So, I wanted to explore the differences of Making, Hacking, and Engineering.

Dictionary.com Definitions:

Making:

1. the act of a person or thing that makes:

The making of a violin requires great skill.

Hacking:

8. Informal. to make use of a tip, trick, or efficient method for doing or managing (something): to hack a classic recipe;

to hack your weekend with healthy habits.

Engineering:
1. the art or science of making practical application of the knowledge of pure sciences, as physics or chemistry, as in the construction of engines, bridges, buildings, mines, ships, and chemical plants.
I of course picked the definitions relevant to this blog. Making requires skill but doesn’t necessarily have to be clever.  Hacking as used in the term “life hack” are clever or unusual ways of doing something efficiently.  Then finally Engineering is applying known science to a given goal. As an electronics designer, you are usually working in a blend of all three ways.
A few days ago, I did a little project that was basically all Making.  I wanted an inline set of controls for a wired headset that I already own. I looked up the requirements online, designed the schematic, and PCB layout and ordered PCBs.  I really didn’t do much engineering and it wasn’t particularly clever.
When designing something that has never been done before, Engineering is great, but sometimes falls flat. Perhaps the design hasn’t been done because no one has found a clever solution yet. An engineer has to be careful when they incorporate a hack into their design.  Often clever solutions have unforeseen drawbacks that may not become apparent until thousands of units have been produced.
Sometimes a design hasn’t been done because no one has seen the need for it before.  This is often a nearly pure engineering process. Nothing in the design is hard to do, but you have to know the science(or it’s shortcuts) to complete the design.
Side note: In some cultures Engineering is about individual and public safety. An Engineer’s job is to make sure a product or design won’t hurt someone. Although I think it is important to always be thinking about safety in your design, this is not part of this discussion.
Side Note: Scientific shortcuts speed up the design process.  For instance we know the left hand rule for figuring out the magnetic polarity of a coil given it’s direction of current flow.
Do you have any favorite science shortcuts? Are you a maker, a hacker, or an engineer?  Is there another way to look at creating something that you’d like to talk about?

Parts Placement (Hardware V00E)

With the design review and testing done, it is time to update the layout.  I started by doing a Design rules check on the schematic. I got 3 errors, two were passives connected to inputs.  I changed the analog input of U10 Pin 3 to a passive pin. This is not a problem, but might be in other circuits. The third indicated two power outputs were connected together.  The CH340G has a 3 volt pin that operates as either a power input (3.3v operation), or as an output (5v Operation), I went in and edited it to be a bidirectional pin.  It still gave me a warning, but it’s acceptable.

Design rule warnings and errors are important, for each one, I will check to make sure it doesn’t represent a real problem and try to fix it.

I then ran CvPCB to confirm all devices have an assigned footprint.  I had made some changes that means a few new components, and footprints. I got all the parts assigned and saved them. then saved the schematic sheet. I then ran a netlist. I opened the layout design, and imported the new netlist… it gave me an error. It couldn’t find the library Housings_SOT-23_SOT-143_TSOT-6. The library name had changed, I went back into CvPCB and found the TO_SOT_Packages_SMD library that had the SOT23 footprint that I needed for all of my transistors. After making reassigning the footprints, I re-saved CvPCB and the schematic file, then generated a new netlist.

This left me with a bunch of parts all jumbled together. I started by spreading them out so I could see their ratsnest better. Once I saw how much components needed to be moved around, I ripped up all traces as well as the ground plane.  This gives me the freedom to re-arrange the board more efficiently.  My strategy was to start at each end of the board and work to the middle.

Looking at the design, the switch for upload takes up a lot of space and is not needed. I went back into the schematic and removed the upload switch. This required that I generate a new netlist and read it into PCBnew.

I left the USB connector where it was, put the Lithium cell in the NW corner, the Reset circuit in the SW corner, the wifi module in the SE corner, The test header along the south edge, the target connector on the NE corner and the high voltage circuit along the north edge.

PartsPlacementV00E

I routed the board using the interactive router. I then added my logo on to the board. I want to edit my logo a little bit, I may change that before I send the files off to fabrication.

FinishedLayoutV00E

The kicad files are on www.github.com, use the link just below my logo to download them.

Do you have any comments, would you do something differently,  can you see a better placement of parts?

Code Cleanup and Boost Circuit testing (Firmware V00E)

This week I was reading through the SDK documentation, and realized a better way of handling serial events.  I was setting a flag and using a software timer to handle those events once a second. I also found that there is a webserver example in the IOT example.  I think this server is much simpler than ESP Ginx.  I have decided to try to use this example to move forward in the design

I decided to set up an OS task that I can post to that will do things like display the serial menu.  I am already using a task for serial handling.  (I grabbed it from an example and modified it for my uses).

I started by changing the UART task to a more generic task. I changed uart_recvTask to taskHandler. Then I just call an os_event_post with the action I want taken.  This allows the system to decide when to start the action. Displaying the menu and other tasks will generally happen faster this way.

As soon as I tried to do anything with GPIO16, I got lots of reboots.  It seems that the problems I was having with the Voltage boost circuit may have actually been GPIO16 problems. I have moved the control pin from GPIO16 to GPIO13 for enabling the voltage boost circuit.  With GPIO13 connected to the base of Q4 to enable/disable the boost circuit, the firmware booted and worked reliably.  After that I changed the filter resistor back to 10 Ohms as I had originally specified. And… It didn’t boot.

I replaced the 10 Ohm resistor with a 100 Ohm Resistor.  Still wouldn’t boot. I found that if I could get Q4 turned off, then the system would boot and run reliably.  As soon as I turned Q4 back on, the system would reboot and hang. So I tried adding a 100 μF between +BATT and GND to try to filter any electrical noise. It didn’t work.

I connected a bench power supply set at 3.3V to the boost circuit input, and I got it to partially work. I got 8 volts out of it for a few seconds.  I reinserted the GPIO16 initialization functions and no problems when no power is connected to the boost circuit.

I added some code that allows me to increment or decrement the prescaler using + and – keys respectively. When I hit the – key when the prescaler was at 0 to get to 255, it would reboot. When I hit the + key to go from 99 to 100 it would reboot.  So for now the prescaler is limited to the range of 0 to 99.

I am encouraged by getting the voltage on VPP higher than any supply voltage on the board. It appears that I need to create a separate ground plane just for the boost circuit.  If I couple it to the main ground with a low value inductor, I might be able to eliminate the problems it has caused.  I have uploaded the new version of the code. It still has very little commenting, however, I think it is cleaner and easier to read.

Updating Schematic V00B

In the last few posts, I found several problems with the design as well as found some ways to reduce Bill of Material costs.  I also want to make soldering of the parts easier for a hobbyist.

I had problems using the CH340G chip on my NodeMCU board.  I couldn’t find any references to this problem on the internet.  So I replaced U8 (the CP2104 USB to UART bridge) with the CH340G USB to UART bridge.  I inverted DTR and RTS  and connected them to GPIO0 and RST respectively.  Using transistors as the inverters means that when U8 is not powered, it won’t draw those two lines down.  This is looking forward to when the design is battery powered.

I used the NodeMCU schematic as reference during this part of the design since it is close to what I want to do with this part of the design.

I changed the reset push-button switch to pads on the board and left the upload push-button switch unchanged but don’t plan on installing it unless I run into problems programming the board.

I also want to make things smaller, U9 is a large part of the board.  A shift register can do the same thing and be less expensive. I found the 74HC595 to replace U9. I am still clocking data in using the SPI bus, and then latching it with a pulse from GPIO5.

For the High voltage, I removed the AAT1230 and replaced it with two logic level FETs. One to disable the circuit to drop current draw when in low power mode connected to GPIO14. The other the pulse stream that generates the current through the inductor connected to GPIO4.  This means all the pins on the module are used up again.

Kicad schematic and layout can now be found here. The pcb layout is not current to the schematic, I still need to do a design review before I start the layout.

UProgrammerSchV00B

Initial Connections

As I start connecting signals on the schematic, I look at which pins have dedicated functions.  The dedicated functions I need, I handle first.  This allows me to adjust the rest of the design around the required elements.  To make the schematic easier to read, I try to avoid crossing traces.


I went into the library editor and moved the pins of the ESP-12E around to make it easier to read the schematic.

I have connected the SPI pins from the ESP-12E to the level shifter chips.  I have also connected four GPIO pins to the level shifter chips.   I have placed the 3.3V power connections to each of the level shifter chips and the ESP-12E. I have also tied the 3.3V regulator to the 3.3V power bus. I connected GPIO0, GPIO2, GPIO4, GPIO5 to the direction pins of the level shifter chips.  I have also connected Vt to the level shifter chips. this voltage will come from the target to be programmed.

I have ordered 5 ESP-12E boards from Ebay.  I should receive them within 30 days.  Once I receive them, I will start doing a basic hello world project.

Initial Connections

Creative Commons

There are several flavors of the Creative Commons license.  I am going to look at the attribution and attribution share alike licenses.

Both licenses are very similar to the modified BSD license and are more explicit about what rights are conveyed by the license. Both require attribution to the author without endorsement from the author.

The share alike requires any derivative works be licensed with the same license or a compatible one.


For this project, I don’t see any advantage this gives me for the final product.  I hope to build and sell these programmers, but if someone else does for a decent price, I would still benefit.

I have to pick a license or make it public domain or someone else could license or patent it in a way that would restrict me or anybody else from building and selling it.

I am applying common design principals in this project. I do not believe there will be anything unique enough to patent.

Experience and Heuristic method

Experience gives us a better chance at guessing solutions to a problem.

For instance a 220 Ohm resistor is a good rule of thumb for an LED current Limiting resistor in a 5 volt circuit.  A simple guess for a 10 volt circuit would be to just double the resistance to around 440 ohms.  Unfortunately this will probably burn out the LED.  From experience of doing the calculations, you would recognize that a 1000 ohm resistor usually works well in a 10 volt circuit.

Heuristic method comes in to play when you are working in an area that you are less experienced in.  You look at how similar operating circuits have worked in the past and make an educated guess to design the new circuit. Sometimes you just make a guess and then test, even with no reasoning as why that guess would work.

So if you are a tinkerer or an engineering student, go get some experience. Go build some circuits, make some changes, break something, then try to fix it or maybe improve it.