I love the smell of Prototyping in the morning!

I love the smell of prototyping in the morning! Of course I am only ever seem to smell my prototypes cooking after a long day of hacking – but still there is nothing like the smell of prototypes in the early evening!

I am working on a small team prototyping a new IOT device. Over the last few days we brought up the prototype hardware I designed, getting the components stuffed, tested, and the main control chip successfully programming and running debugging software. The MKW40Z160 is just an awesome chip – I am looking forward to using it on a lot of projects. They integrated everything but the kitchen sink when designing it – Bluetooth, DC/DC converters and battery charger, capacitive touch sensors, and a boatload of peripherals.

The one problem with prototyping around the MKW40Z160 is that its pin pitch is a on the small side. The suggested footprint has a 3-mil inter pad spacing. For hand stuffed prototypes that had me nervous. A 3-mill spacing is not a problem when using a hand solder paste dispenser and hot air nozzle to reflow the chips one at a time, however testing this design required making make a small volume runs by hand. It turned out to not be a problem at all.

We got the boards from SeedStudio, and were pleasantly surprised by the board quality. We ordered a solder mask stencil with the order, and used the stencils to pull solder paste onto our boards.

Pulling_solder

The stencils were welded to an aluminum frame, and intended to be used with a stencil alignment jig. We were able to get by making a red-neck jig from some PCB off cuts, and angle iron. We used score and snap taps on our panelized design. We glued the snapped off pieces down to a sheet of metal to hold the boards in place. We then aligned the frame over the PCB under the microscope. Once the stencil was aligned one of us held it in place while the other glued 1/4 inch aluminum angle iron around the frame to hold it in place. It worked surprisingly well. Once the glue dried we could pull and reseat the stencil over boards quickly and accurately.


Inspecting_solder_pull_p2.jpg

When pulling solder past onto the boards it is important you get a clean, slow, pull when putting the paste down. You can not easily go back and fix a bad pull. We had some luck using a clean metal squeegee to scrape the stencil at a right angle from the previous pull, then re-pulling the solder past, but the results – while usable – were never as good as just getting it right the first time.

Reflow_oven

The next step was reflowing the boards. Despite what you will read online – avoid the solder skillet technique; it is garbage. Toaster oven reflow actually works really well. I never had much luck with my own toaster oven reflow attempts until I made two small modifications.

The first oven modification was adding aluminum foil to the front window of the oven. You loose most of your heat out the glass front of the oven, and adding a layer of aluminum foil, held down by Kaptan tape, reflects a lot of the heat back into the oven. I initially cut a small viewing hole in the foil, but I would not recommend that as it creates a huge thermal stress on the glass. The second oven modification was adding dual temperature sensors to monitor the inside of the oven directly. For $60-70 from amazon you can pick up a dual probe temperature sensor, and it negates the need for the “window” in the aluminum foil.

With these modifications you can reflow conventional solder pastes, but we experimenting with low temperature solder paste, but so far the stuff is proving awesome – you only need to heat things to 160C as opposed to 250C. So much faster and easier to use.

Second_board_run_8units

Dam you Farmers Union iced coffee!

Dam you farmers union iced coffee, despite my best efforts you drew me into your madness. Even 8 years later I see something like this on the shelf and think, maybe this is the one, something like you that I can get outside of Australia. I get my hopes up. Then I have it, and its just bad coffee and milk.

Not_Farmers_Union

All these years later and I am still getting my hopes up when I see something like this. Dam you Farmers Union. Dam you. You are liquid evil.

A weekend of Aikido

It was a pretty awesome weekend. While visiting some friends in Chicago we all got to attend the Seiso Aikido Organization’s Friendship Seminar. We meet and trained with a bunch of great Aikidoka in IL, and more importantly got to meet a bunch of great people that I hope to get to train with again.

Visiting_Phil_Seiso_Aikido_organiztion_P2_Jan17th2015.jpg

That has got to be one of the best parts of the martial arts – when you show up at a dojo you are going to meet a bunch of martial arts nerds. It doesn’t matter what country you are in, or where you are from, you instantly have this huge thing in common. Looking at the picture of me from the end of the day I am not sure I would have let myself on the mat, but they were very welcoming.

Visiting_Phil_Seiso_Aikido_organiztion_P1_Jan17th2015

Come to think of it, that’s actually how I met Phil, Belinda, and Dusty in the first place, at a martial arts training camp. Then here we are a few years later meeting up to catch up and train. It is funny how many of my friends I have made while I was trying to stab them!

No pictures in the dojo!

And this is a clear example of why you don’t let people take your picture when using the Makiwara…

Makiwaras_and_cameras_dont_mix_Dec2015

…or no pictures in the dojo for that matter. Best part is that the person who took this picture took several shots, so if this is the one she chose to post, then wow – how bad must the others have looked! Best part is my form is awful to.

Just capturing a list of potential project ideas for next time my nephew visits.

Wind turbine – Saw interesting looking kits on amazon. One that screwed onto a soda bottle in place of its cap, providing a weighted base, and the other using a chemistry ring stand as a base and clamping onto a motor an propeller. Then using a volt meter to measure wind induced voltage.

Greenhouse Demonstration – Two identical thermostats, one inside a sealed bottle and the other outside. The greenhouse effect will heat up the thermostat inside the chamber. Saw it as a kit, but simple enough to build.

Potato / Lemon clock – Classic experiment of two metals pushed into a potato or a lemon to power a clock. The super low voltage DC/DC converters you can get these days could drive the usable power curve from a setup like that. Build the board to show Tristan.

Rock Tumbler / Polisher – Rock tumbling might be interesting – but what about showing him a parts tumbler instead. Then we machine a part for another project and polish it?

Solar Projects – Including Photovores, but maybe set up a race of small Solar race cars

Radiometer – Not really an experiment, but showing him one of these and talking about it would be good.

Time Capsule – One we could bury in the back yard? If we bury it just off a trail where we could find it again, we risk having someone else dig it up – but we could make it into a day hacking and taking pictures and samples.

Solar Oven – Bunch of different designs for them, but an inverted pyramid formed from inward facing mirrors would be a simple start.

Solar Parabolic Fire starter – Done in parallel with the solar oven, using the tiny parabolic mirror approach for setting a piece of paper on fire we could build the parabola as part of the experiment.

Finger Printing – Put together a finger printing kit as a project, then do print and lifts. As part of this we could potentially make a simple cyanoacrylate fumer for bringing out prints.

Blood Typing – Simple project is just using one of the blood typing kits to determine our blood types. A cooler but much more involved project is if we get blood from a few different people use the agglutination test so he can see how some blood types respond badly when mixed. Not sure if this would work as a fun project, but sphygmomanometer to take blood pressure could be thrown in if we are doing several blood related projects. Also get a heart rate sensor and show how our heart rate goes up when we run / exercise.

Making Paper – Need something we can do with the paper once we made it. Possibly cast cardboard into a mold?

Fire Starting – Using a Bow and pivot to start a fire, compare with stick in a rut, and throw in using a magnifying glass. Make Matches to complex?

Biome Balls – Buy one of the biomes in a glass ball to grow while he is here? Maybe one for here and a new one to take home?

Raising Caterpillars – Make a cage to raise caterpillars and butterflies (summer project). Not just a jar with holes, do a glass case with enough growing foliage in it to feed and foster the bugs.

Molding Tracks – Go into woods on the hiking trails and make plaster molds of animal prints (Deer?) – maybe do some casts of hikers boot tread.

Production of Oxygen by Photosynthesis – Plant growing in a case under water. Case vents into a test tube with graduations on it. Transparent case lets light in keeping the plant alive. As the plant outgasses oxygen you can see it collect in the inverted tube.

Make a weather station – Play with data and graphs.

Interesting Ideas for more stuff here:

http://www.funsci.com/texts/index_en.htm

Lots of bio links that were cool here

http://www.funsci.com/fun3_en/exper1/exper1.htm#chlorophyll

Espressif’s “ICACHE_FLASH_ATTR” and larger flash sizes

Just noticed this description on the espressif website describing the
location of the ICACHE_FLASH_ATTR functions in memory.

It looks like methods WITHOUT the ICACHE_FLASH_ATTR marker get cached to memory in 32KB of ram in iram1_0_seg at power up. Methods with “ICACHE_FLASH_ATTR” are located in irom0_0_seg.

Thats the opposite of the behavior I was expecting. However looking in the eagle.app.v6.ld linking script (version esp_iot_sdk_v1.4.0/ld/eagle.app.v6.ld) we see:

MEMORY
{
dport0_0_seg : org = 0x3FF00000, len = 0x10
dram0_0_seg : org = 0x3FFE8000, len = 0x14000
iram1_0_seg : org = 0x40100000, len = 0x8000
irom0_0_seg : org = 0x40240000, len = 0x3C000
}

which is a layout change from the older memory layout found in esp_iot_sdk_v0.9.5/ld/eagle.app.v6.l

MEMORY
{
dport0_0_seg : org = 0x3FF00000, len = 0x10
dram0_0_seg : org = 0x3FFE8000, len = 0x14000
iram1_0_seg : org = 0x40100000, len = 0x8000
irom0_0_seg : org = 0x40240000, len = 0x32000
}

I’m using a few different esp8266 modules, but developing code on a HUZZA board. Checking its flash
I get:

/opt/esptools/esptool-new/esptool.py –port /dev/tty.usbserial-A600dRM4 flash_id
Connecting…
Manufacturer: c8
Device: 4016

Which from what I am seeing online should translate to a Winbond W25Q32 flash chip.

More specifically this list of flash-ROM IDs says that 0x4016 could map to a few devices but both the Windbond device, or the Gicgadevices (based on Maucacture code), are 32Mb devices, so there should be 4MB of flash available which is not reflected in the limits above.

Checking the newer linker scripts, the espressif SDK provides ./esp-open-sdk/sdk/ld/eagle.app.v6.new.2048.ld with a bigger definition.

MEMORY
{
dport0_0_seg : org = 0x3FF00000, len = 0x10
dram0_0_seg : org = 0x3FFE8000, len = 0x14000
iram1_0_seg : org = 0x40100000, len = 0x8000
irom0_0_seg : org = 0x40201010, len = 0xE0000
}

ESP8266 and “rst cause:2″

So programming the esp8266 through a USB FTDI chip that also supplies the 5V rail, means the chip has less than the 500mA provided by the USB buss. There is probably ~450mA left to power and program the ESP. Based on the data sheets that should be more than enough. Turns out it isn’t.

Apparently writing to flash on the esp8266 has higher power transients than can be supplied by USB alone. I added additional capacitive bypassing on the power rails of two 10uF capacitors to help with high current transients, and powered the board off of an external supply. Doing that and reflashing got my example code working and stopped the flash problems. It definitely stopped the “rest cause:2″ resets I was seeing.

Espressif reset codes

Looks like there is more to the reset and crash bugs. List of reset causes found on espressif website (http://bbs.espressif.com/viewtopic.php?t=563)

reset cause 1: normally during a Power-On-Reset or by CHIP_PD transient
reset cause 2: normally during a reset caused by a nRESET transient
reset cause 4: normally during a reset by wdt reset

Esp8266 error: “don’t use rtc mem data”

Update: Turns out my problems, while repeatable, were likely to do my libraries being set in a non-homogeneous state. It appears that an auto partially rolled back the SDK version being used, which was weird. A full make clean, and rebuild fixed the problem I was having. Still the reset problem is fairly common with the ESPs and Espressif SDK. This guy summed it up the ESP Reset Problem really well.

So this error was a beast to find – and I saw some others online were having the same problem – so I figured I should post about it someplace Google could find it.

I’m using the espressif development tools, which are getting better, but remain only sparsely documented. My problem started after a change in my code started the ESP crashing on power up. The crash presented, or so I thought, like a flash write error contaminating the boot loader.

I was getting this error about messing with RTC memory:


r
ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x40100000, len 29920, room 16
tail 0
chksum 0x07
load 0x3ffe8000, len 924, room 8
tail 4
chksum 0xbf
load 0x3ffe83a0, len 4528, room 4
tail 12
chksum 0xde
csum 0xde
don’t use rtc mem data

Well, it turns out the problem was my starting to use the init_done_callback code when I upgraded SDK versions. I jumped from a 1.x SDK to a 1.4. The init_done_callback code was added into the SDK somewhere in that range. The call works fine, and I had been using it for a while in my code when I ran into problems merging the timer code. It is not in the documentation anywhere yet, but you apparently can’t mess with the os timers within the init_done_callback function.

Since it looks like init_done_callback is how you launch code after all the underlying espressif code has finished I’m thinking this is a bug. For now I’m going to change to launching my timers before setting the callback, and use a flag to wait until espressif init’s done.

Here’s a cut down version of the code triggering the problem:

void ICACHE_FLASH_ATTR user_init(void){
user_gpio_init();
user_uart_init();

// Problem killing the timer is here! I should handle timers outside callback.
system_init_done_cb(init_done_callback);
}

void init_done_callback(void)
{
// Callback launches fine – but its the setting of os_timers that triggers
// the crash / messing with timer memory error.
start_keepalive_timer(KEEPALIVE_INTERVAL_SECS);
}

void ICACHE_FLASH_ATTR start_keepalive_timer(int interval)
{
#ifdef DBG_KEEPALIVE
os_timer_disarm( &dbg_keepalive_timer);
os_timer_setfn( &dbg_keepalive_timer,
(os_timer_func_t *)dbg_keepalive_timerfunc,
NULL);
os_timer_arm(&dbg_keepalive_timer, (1000 * interval), 1);
#endif
}

Fun with data!

So lately I have been playing with data measuring light levels throughout the day. I am fascinated With just how much my brain and eyes filter and smooth my perception of light, making me unaware of startlingly large changes.

This graph shows data taken from the same light sensor sampling over two days. The red series of data reflects UV light levels, and the blue reflects UV + Visible light levels.

sensor_id85_day2

Two back-to-back days can vary in duration by 40 minutes! Sure sunrise and sunset times between two days only change slightly, but cloud cover and weather has a massive impact on the light profile of the day. During darkening leading up to sunset the brightness can halve every seven-minute for two hours without it being noticeable!

Some data is just fun to play with.