Tag Archives: Sigma Delta

Modifying the circuit for better Vpp control

by

Planning:

I needed finer control of Vpp.  Since this is an experimental design, I decided to make some calculated guesses to choose the right values.

To start with, I believe that putting a resistor between the emitter and ground of the feedback transistor will limit the gain of the transistor.  The voltage of this resistor will rise as the current through it increases limiting the current gain of the circuit.  The first guess I tried was calculating the resistor as if the transistor wasn’t there(same as fully saturated) for my max voltage (25 V).

Continue reading →

Vpp Regulation test

by

Second Thoughts:

I am having second thoughts about co-processor model.  This significantly increases the complexity of the firmware for this design.  I haven’t ruled out any options yet.  If I can get a good voltage for Vpp without the co-processor, I may decide to go back to the level shifter.

Programmatically controlling Vpp:

I have been thinking about how to make an “adjustable voltage” switching regulator adjustable by the microcontroller.  By putting a transistor on the low side of the voltage divider feedback, I believe I can have linear control of the generated voltage controlled by the Sigma-Delta output. I got a basic circuit design from the FAN5331 datasheet. I then replaced the ground side resistor of the feedback voltage divider with an NPN transistor.  I came up with the circuit below.

The FAN5331 has a 1.25 volt reference comparator to decide if it needs to generate more voltage or wait.  With the Sigma Delta input to r3 at 0 out of 255, the transistor will never turn on and the voltage on the feedback will be above the 1.25V threshold and the regulator will effectively shut down.

Resistor Calculations:

Continue reading →

Vpp Control Loop (Firmware V00M)

by

Plan:

This week I decided to work on the control loop. I decided to add a simple adjustment scheme to the 5 mS system timer event. And then create a way to change the required voltage in increments of 0.1 Volts starting at 10.0

Implementation:

I created a local “static” variable in the events.c file for the target voltage. I then created a function to set this variable target_voltage and another function to get the value of target_voltage.  I then added a simple if statement into the 5ms event that increments the duty cycle of the Sigma Delta if the measured value is too low and decrements it otherwise.  I compiled and tried this, Vpp is ugly.

pic_42_3 Continue reading →

New Release of Espressif’s SDK (Firmware Version 00I)

by

Espressif released a new version of their NonOs SDK.  The new Version is 2.0.0 released on July 19, 2016.  The change from 1. something to 2. suggests it might break the code.  I downloaded the new version.

Last week I crippled the software for debugging purposes. I found the bug. This week I want to update to the new version of the SDK.  Since it might break my code, I want to get all the functionality back in the code before I move to the new SDK.

First, I uncommented the HSPI overlap test code. I made a small change to the code that reads out from the SPI RAM to guarantee there is a null terminator in the 13th position of the buffer that is filled from the SPI  RAM. Then I compiled and tested it. It immediately crashed.  I am really glad I haven’t upgraded the SDK yet.

I put hspi_overlap_deinit(); directly after the call to the writeRam(); function. It didn’t crash, but I didn’t get the Hello World from the SPI RAM.  I need to init and deinit hspi overlap mode in the writeRam() and readRam() functions. I modified these two functions and tried again.  Now I get the Hello World after the menu after a reset.

Next, I enabled the WiFi modem.  I set the wifi opmode to  STATION_MODE and commented out the other lines that disabled the modem. It booted, I set the SSID and Password, requested a connect and no apparent result.  I remembered the WiFi Callback is still disabled, I uncommented that and tried again. This time, it remembered the settings from the previous try and connected immediately.

Next, I re-enabled the Sigma Delta circuit and tried changing values.  It is working without crashing.  The code is where it should have been before the buffer overrun bug.  I am ready to upgrade the build environment.

I am going to use this code as my base going forward because the web server code was unstable, and I don’t want to work with the web protocols as much as that would require.

I did some of these tests while the file was downloading from Espressif’s website.  I ran make with the clean option. This removes all the intermediary files used in compiling. Next, I copied the folder I was working with to UProgrammer-SDK1.5.4  This gives me something to go back to if the upgrade fails.  Next I opened up the zip archive of the new SDK.  I copied all the files and folders in the ESP8266_NONOS_SDK into the UProgrammer folder.  This copies over all the SDK files but leaves all my files in place.  It does mean the linker file I modified will get overwritten as well.  I checked this file and they have changed it in the new version of the SDK.  It doesn’t match my linker file, but it might have enough room for my code.  I decided to try compiling without modifying the linker file.

There are linker errors but they are not based on code size.  They describe undefined references to user_rf_cal_sector_set in function flash_data_check.  This looks like a makefile error.  I compared the makefile in the app directory with the one in my project directory.  There was no makefile in the app directory like there has been in previous versions of the SDK.  I went into the examples folder and used the makefile from the IOT_Demo Example for my comparison.  I did some clean up and made some changes to make the files closer to each other.

The changes I made weren’t enough, So I copied the whole file over to see if it fixed it. It didn’t, It looks like a file library file isn’t being linked in. I went into the lib directory looking for the library I needed to link. user_rf_cal_sector_set sounds like a memory function to me. So I looked for a library that dealt with calibration memory.  In the include directory, used the following command line:

grep -r user_rf_cal_sector *

and I got no results back, so for a sanity check, I tried the following command:

grep -r smartconfig *

and I got a list of lines with smartconfig  listed.

On a hunch, I decided to remove the link to main. In the makefile under LINKFLAGS, I removed the line -lmain \.

That also didn’t work.  I did the following command in the UProgrammer foler:

grep -r user_rf_cal_sector *

The result looks like every example implements this function. So I copied that function into user_main.c from the IOT_Demo user_main.c and it turns out they required this new function because they changed the layout of the flash calibration data. Now it builds.  Now the code no longer works.

I tried changing the ld file back to having a length of 0xC0000 and I noticed that the build said I should upload the code to 0x10000.  My shell scripts upload the code to 0x40000.  So, I restored my makefile from the copy of the folder and tried again. It still builds to load at address 0x10000. I modified my script file to load to that location.

And finally, success.  I set the SSID and the password and requested a connect. it seemed to stall.  I reset the board and it connected immediately. I am going to have to take a look at that.

I tested the Sigma Delta and that worked as expected. I measured 22 volts on the output with a duty of 102 and Prescaler of 4.

I re-uploaded the default settings and tried again. I set the SSID, Password, and requested a connect. it seemed to stall again.  I waited ten minutes to see if something would change.  I looked at the connect request code while I was waiting.  Somewhere along the development I deleted the actual call to connect.  I didn’t make it to the full ten minutes. Put the connect request in the code, compiled it, reset the flash to defaults, and uploaded the new version.

This time it connected in about 5 seconds. Success. I have uploaded the new version of the code to GitHub, click the Firmware on GitHub link at the top of the right column to go get it or just take a look.

Please comment below about your experiences upgrading to a new version of API/APK.  Maybe you have had similar experiences switching between devices in a processor family?  I would love to hear from you.

Component analysis (Hardware V00G)

by

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.

Voltage Boost testing

by

I have a very stable version of the Sigma Delta(ΣΔ) firmware to test with.  I decided to use it to test the Voltage boost circuit.  I started by populating the PCB with the voltage boost components.  Definition: Populate a PCB means installing the components onto a board; this includes but isn’t limited to soldering.

PCBVboost  PCBVboostPop 

Once Installed, I started modifying the code for a simple test. The first test is a sanity check.  I disabled all functions other than sending an incrementing number out the serial port every 5 seconds. And then I ran into another problem.  I had upgraded my install of Ubuntu studio to 16.04 earlier this week and now USB wasn’t working in the virtual machine.  After a few hours of fiddling, I got it working and finally built and uploaded the test code.  The terminal started counting as expected.

Next I turned on the ΣΔ and set the duty to 16. I figured out the prescaler with the following math.  An inductor will reach approximately 2/3 saturation current after a given amount of time calculated by inductance divided by resistance.  I am using a 2 μHenry inductor with an internal resistance of 0.25 Ohms. 2×10^-6 /.25 = 8×10^-6 or 8 μsesonds.  So the most efficient use of the inductor will be between 4 and 8 microseconds. One cycle (pulse width) at 80 MHz is 12.5 nanoseconds. This results in a prescaler of 640 for an 8 microsecond pulse width. If I choose a prescaler of 255, I end up with a pulse width of 3.2 microseconds.  This is a simplified calculation and I hope it will get me close enough.  The PCB resistance, capacitors, and R5 all contribute in varying degrees. I also set GPIO16 as an output and drove it low to enable the voltage booster.  And the code ran as I was hoping for.  I measured the Vpp voltage at 5.93 Volts which is slightly above the 5 volts being supplied by the USB. Yeah! small victory.

The next firmware modification turns on the Sigma Delta and set the duty cycle to 128 (50%) .  I measured 2.75 Volts. So next I read from the ADC each time I sent to the terminal.  The value I read back was 137.  Then I enabled changing the duty with each update. and the values changed with each step.  Very good. Next I did a little math on the data. The ADC reads 1/1024 V/step.  So when I got the reading of 137, that means (137/1024)*20 = 2.675 V.

I get a small error but within 5% reading a meter verses calculated.  I fixed this by changing the 20 to 21.  I got the error because of a 5% error in the calculation of the voltage divider.  I had known about this error, but was ignoring it.  Now it is fixed.  I then started to play with the prescaler to see if i could make it work better.  The 100 Ohm resistor is having more affect on the circuit than I had anticipated.  With a prescaler of 128, Vpp rises to 8V.  At 64 Vpp rises to 11.6 V. At 32 Vpp Rises to 11.6 V again. At 16 the Vpp Rises to 11.6 again.  This suggests the design is limiting the max voltage. I need to check the reverse breakdown voltage on the diode and FET.  I would like to see better control between the steps.  With a prescaler of 0 it Vpp peaked at 12.1 V.  It took more steps to get there, and the steps weren’t linear.  It still needs tuning, maybe a different inductor.

This was fun playing with the Voltage boost circuit.  I actually got it to work fairly well.  This is the first switching boost circuit I have designed from scratch. Of course, I have had a few bumps along the way.  I have uploaded the test code to GitHub.

Have you designed a circuit that was out of you normal area of expertise? I would love to hear about your experience.

Sigma Delta still causes reboots Firmware Version 00E

by

I was hoping but not expecting the SDK Update to fix the Sigma Delta problem.  So first thing I did this week was to test.  Same failure as before.  I had two Ideas this week that might be an answer to the problem.  On another project, I was using the Arduino IDE to develop a little weather station project.  In it, I was using old code that set certain pins as output.  Those pins were/are tied to the SPI bus and was causing it to reboot.  Maybe, there is a pin set to have Sigma Delta(ΣΔ) output that is also tied to a critical pin.  My second thought is that if the ΣΔ is causing interrupts, I should disable them.

A good practice for microcontroller programming is to always set up all I/Os immediately after a reset.  I have gotten sloppy and haven’t done that with this project. If a pin is connected to the ΣΔ that shouldn’t be, this will fix that.
I started by writing down what each pin will do in the design. I referred to the schematic for each pin.

Pin 18 GPIO0 -- Output -- controls analog switch
Pin 22 GPIO1 -- Output -- TxD0
Pin 17 GPIO2 -- Output -- sets VPP output high
Pin 21 GPIO3 -- Input -- RxD0
Pin 19 GPIO4 -- Output -- ΣΔ pulse stream to generate Vpp
Pin 20 GPIO5 -- Output -- Sets Vpp output low
Pin 14 GPIO6 -- Output -- SCLK (SPI and HSPI overlap) (need to verify Pin number for ESP12F)
Pin 10 GPIO7 -- BiDir -- MISO (SPI and HSPI overlap) (need to verify Pin number for ESP12F)
Pin 13 GPIO8 -- BiDir -- MOSI (SPI and HSPI overlap) (need to verify Pin number for ESP12F)
Pin 11 GPIO9 -- BiDir -- QIO2 (SPI and HSPI overlap) (need to verify Pin number for ESP12F)
Pin 12 GPIO10 -- BiDir -- QIO3 (SPI and HSPI overlap) (need to verify Pin number for ESP12F)
Pin 9 GPIO11 -- Output -- CS0 (SPI) (need to verify Pin number for ESP12F)
GPIO12 -- BiDir  -- Data to target device
GPIO13 -- BiDir  -- Data to target device
GPIO14 -- BiDir  -- Data to target device
GPIO15 -- Output -- Chip Select for HSPI
GPIO16 -- Output -- Disables Vpp generation

I went into the user_init() function and removed all the commented out code leaving an example of the PIN_FUNC_SELECT() macro. I then set GPIO_PIN0 – 15 registers to 0 which disables interrupts and disconnects the ΣΔ output.  I compiled the code and uploaded it and it crashed.  To find the new problem I caused, I commented out all the new code except setting the GPIO registers to 0. I rebuilt and uploaded the code and … a continuous stream of reboots.  I commented out setting the GPIO registers to 0 then put the PIN_FUNC_SELECT() back in. And … reboots slowly.

I removed the function selects that should be controlled by the API anyhow(GPIO6-11). And … I found a typo on the GPIO6 function select. I fixed the typo, rebuilt, uploaded and it ran at least as well as last week.  I then started testing to see if it fixed the ΣΔ issue. The reset problem still exists.

Next I set a subset of the GPIO registers to a value of 0  I decided to go with the first 8 to see what would happen. Same failure, a stream of reboots. Then I noticed I wasn’t writing to the correct register locations.   I fixed this and then recompiled, uploaded, and code is running, but ΣΔ is still causing a reboot if i set the prescaler to greater than 99.

Next I started looking at the ΣΔ interrupt structure.  Unfortunately it has very little documentation that I have found so far.  I used google to search for articles pertaining to the use of the Sigma Delta and found very little.  My next step is to do a little experimentation. I decided to disable the ΣΔ while changing the prescaler.  I got the same results.  It’s time to make a Hello World program for a sanity check. It would be the minimum to set up and test functionality of the ΣΔ on GPIO4.  If it works correctly, then I have to take a deeper look at my code, if it doesn’t, I’ll have something to post to Espressif’s forum for help.

Have you had similar problems with a chip you have never used before?  I have uploaded the current code to GitHub. Use the link at the top of the right hand column to get the download.

Sigma Delta still causing resets.

by

When I first built this revision of PCB, the board would reboot a lot.  That turned out to be the mis-wiring of the SPI RAM.  Part of that process in trouble shooting that board, I had guessed that I had a noisy power connection to the Wi-Fi module. So one thing that I had tried was adding a large reservoir capacitor and a small filter capacitor near the power pins of the module. Unless I am drawing too much current from the voltage regulator, this should eliminate any possible power issues.

This means my first test is to measure how much current is being drawn from the voltage regulator.  To do that I removed the jumper that bypassed the lithium cell charger and attached 3.7V to the PCB from a bench power supply.  To do this I removed all the test pins I had soldered to the module and soldered one to +BATT and another one to GND.  I connected my meter in series with the power supply and turned it all back on.  I measured the current consumed between 75 and 80 mA for the whole range of 0 to 99 prescaler.  This measurement was made with the radio inactive.

I think I can rule out the power supply as my problem.  Next I decided to change the software to take steps of 10 instead of 1 for adjusting the prescaler.  If the failure is because of an accumulated error, this should happen later and I should be able to get a number larger than 100 without a failure. I re-soldered the  bypass of the Lithium Cell charger and uploaded the change. I got to 91 No Failure. At 101 it still failed.  I change the step to 30 and when I got to 120, I got a reset cause:2. (maybe there is a clue here, This means external reset.)  I found this in the 2c-ESP8266_SDK_Programming Guide.pdf file from the Espressif BBS.

There are two pins on the module that can be used for external reset.  Since the serial to usb bridge is controlling the reset line, I decided to look into the EN pin first. It looked good with the right resistor in place to pull it up.  I then started looking through the code to make sure the Sigma Delta was configured to the correct pin.  Turns out that it wasn’t configured to output on any pin.  There was a missing statement in the code setting pin4 to output the sigma delta channel.  I added that line back in, saved, recompiled, uploaded and tested again. It still is failing.

Going back to the external reset, I decided to put lower value pullup resistors on the reset lines. I changed them from 10 K to 1 K.  This should reduce any affect of noise on the pins and still not draw too much current when pulled low. It still fails in the same way.  I have another project where the sigma delta is working very well.  The main difference I can see is that on this project I am reading the sigma delta twice before I write to it. In my other project, it reads the register once.  So I am going to make a simple uint8 variable to retain the value I am writing to the Sigma Delta prescaler.

It is still not fixed.  Have you seen this problem? Have you solved it?

 

 

Javascript

by

Merry Christmas!

The PCBs came in today, they look great.  Of course I will need to make the modifications I mentioned last week.  I haven’t received the CH340G chips yet. I will wait until I receive them before I start building.

Rev00BPCBs

This week, I wanted to add  a slider to set the Sigma Delta output that drives the voltage booster to the web interface.  I didn’t know javascript at all so, I went to an online tutorial at Codecademy.com. This tutorial is very basic and even explains the basic concepts of programming in general.  I didn’t learn enough to set up a slider, I did learn enough to do some testing.

I quickly got the Sigma Delta output working in GPIO12 by copying the necessary code from the test project I was using. I then added a call to config_sigma_delta() from user_init() in user_main.c.  I also added a call to set_sigma_delta_duty() from my test code in cgi_relay.c.  Of course I added includes to sigma_delta.h in both of those files.  I then changed the Sigma Delta output from GPIO12 to GPIO4 to match the HV_pulse line used to run the switched coil.

Now if I hit the say Hello button, It changes the Sigma Delta output duty cycle. also, the Chart on the index.html page gives the current reading from the ADC once every 5 seconds.

ADCandSDelta