Thursday, March 13, 2014

Updates.

Whew. I've been spending alot of time on my "Sister site". I thought I would have had more time to blog about Fun StuffTM by now. There is so much work behind the scenes that you need to do to launch a site like I want to do. I enjoy it, the supporting work, but it's all still more of the means to an end, I'm enjoying the journey, but I'm looking forward to the destination.

I have to say one stark lesson I've already learned is "Just because you've built it, doesn't mean they'll come". I have very little traffic to my site, and website traffic generation ranks substantially below marketing in requisite business development activities as far as my interests go. I know there are thousands or tens of thousands of people out there that would be interested in the site, but how do I connect with them? Part of building a catalog of existing parts was to attract a regular audience/demographic interested in hobby electronics. That, and other content I have planned (in the next phase, starting soon) would make Anibit bookmark/Feedly-subscription-worthy site.

But I get the feeling, given metrics to date, that there's more needed that just throwing content up and hoping for people to find it. Yet, I don't know what that thing is. My traffic to Anibit so far is dismal, especially if you cull the traffic generated by my personal Social Networking friends(lot of my hits cluster in places I or my family have lived). I supposed I should keep it in perspective (starting a business requires a healthy does of that). Self-bootstrapping with cash on hand like I am doing requires a lot of patience, and the experiences I've had while doing it so far have almost all been rewarding and overwhelmingly positive.

--P

Tuesday, February 25, 2014

Smart Reflow Oven

I generally don't just post links on Bytecruft, but this is beautiful.

This is a reflow oven controller:

http://hackaday.com/2014/02/22/smart-reflow-oven-is-over-engineered/

My oven controller is coming along, in between doing a lot of behind the scenes work on Anibit.com.

--P

Monday, February 3, 2014

Reflow oven

I started a new project recently, a reflow oven. This time, I've started with the physical build, and the software side of it will lag behind. I've laser cut the case I designed in OpenSCAD, and I couldn't be more pleased with the results.

The case with the "human interface" components - a touch screen LCD a 1 watt speaker.

I have some projects in R&D for Anibit, and I'm going to need to whip up some PCB's. I need a reflow oven, and I'm going to recycle an old toaster-over. I was inspired by this project, which was in turn based on osPID. The touch-screen was something I've had lying around, waiting for a project. 

Sunday, January 19, 2014

Introducing Anibit

I started this blog in part to document my hobby work, and hopefully provide ideas or inspiration to others.

A lot of work that I've done lately has been on something I wasn't ready to blog about... until now.

I'm starting a new website, devoted to hobby electronics and programming, and hope for it to become more than just a website, I'd like to use it to be a more substantial presence, and a greater contributor to the community, by publishing code, tutorials, and designs, as well as hosting forums and of course, I'd love to make my hobby, self funding, so it will feature a store, where I'll sell my original products, as well as resell other product of interest to the makers and programmers out there.

Without further delay:

Anibit Technology:
https://anibit.com

Like on Facebook:
https://www.facebook.com/anibittechnology

Or, if you're more of a pluser:
https://plus.google.com/+Anibit/posts

I plan to release most, if not all, of the code for the work I do on Github at:
https://github.com/anibit



Sunday, December 22, 2013

Traffic Light

[Editor's note. This is a post that I started almost 3 years ago, I'm making an effort to purge or polish some of the unfinished or unworthy posts on Bytecruft]

This is a traffic light I made for my kids. It's got a ATtiny 13 driving the leds. It also features a "soft" on-off circuit   driven by a tactile momentary push button.

I know, another AVR LED based project. They're so easy. I swear, I work on more than LEDS and with chips other than AVR's. It's just that the AVR ones tend to get 100% finished. Part of my hopes for this blog is to provide motivation to finish a couple of the unfinished projects I have. Actually, looking back, it's not so much a problem of motivation, but time. I usually "multithread" my projects, work on several at once, to keep form getting burned out or over-obsessed with one. Sometimes, before I know it, a project hasn't been touched in a couple months.

This is a project I did for my kids, it was another one of those "in between" projects, where my goal was to make a small project that would be lightweight after working on something big.

Present-day action shot, I finally replaced the 3+ year old batteries
during the teardown/photo shoot for this.

The real neat trick with this project, in my opinion, was the power management.

Sunday, December 1, 2013

Eggbot hack

I was preparing today for an upcoming Eggbot demonstration, when I noticed a lot of play in the pen arm.


This wooden piece had a lot of play because it had
loosened from the bushing it was glued to.

Monday, November 18, 2013

Not Dead Yet.

I slept funny recently, and apparently cut off circulation to this ByteCruft.

It's not dead, I've been occupied with family, and several projects I'm not ready to reveal yet (which make it hard to blog about).

In the mean time, enjoy this nerd humor:

--P

Thursday, September 12, 2013

Complexity. Ambition. Progress.

What is the inclination many of us have to take on more than we can handle?

I have a really cool project I've been working on, that I'm not quite ready to reveal. It's turned out to be more ambitious that I originally thought, although I am making decent progress and achieving some things I doubted would be possible.

Is it that we overestimate our abilities, our speed, or that we have an inherent desire to avoid underachieving by aiming too low? My gut says.... well never mind what my gut says, it's always hungry, and rarely expresses anything appropriate for mixed company. My head says that we're simply just poor estimators, and there's probably tons of blogs and expert on the web that agree. What has really consumed a lot of the time on this project, were some of the mundane things that I didn't really consider, such as spending a week tracking down errors due improper CPU registers.

It seems that as some of my home hobby projects get more ambitious, and by definition more cool, I'm spending longer and long in between completed projects, with more time spent in the "this is going to be magical one day" phase. I definitely think after my current project I need a few short and sweet ones, to get that gratification of having achieved magic.

--P

Wednesday, September 4, 2013

Really short sanity check list for vexing AVR anomalies.

I've been chasing down some bizarre behavior on an Atmega 1284 for the better part of a week.

I'm posting this so that I can print it out and tape it to my forehead for future reference.

When trying to determine the root cause of strange behavior in your code, you have to sometimes use a process of elimination. Sometimes, it's best to check the easiest possibilities first, regardless of how likely you may think any given cause is. My code was behaving in pseudo consistent ways, something would fail, repeatedly. I would add code to try and catch the error before thing went haywire. I was convinced I had a memory overwrite, or a stack overflow. As soon as I would add the code to catch a problem. It would start working, or stepping though the code would give a different result than running full speed.

Here is a list of things to check while your scratching your head: (In this order)


  1. Fuses. (This turned out to be my problem). I had my fuses set for an external RC oscillator, instead of a crystal. Fuses are so easy to check, it should be the first thing you do. Scrutinize each setting, read the datasheet for each one.
  2. Proper capacitors on the external crystal.
  3. Breadboard noise. I rebuilt my breadboard, it started working better, but not perfect, so I'd assumed it was noise and a memory clobber causing the issues.
  4. Proper JTAG connection. (JTAG seems more sensitive to noise than SPI/debug wire debugging). To eliminate this as a possible cause, program the flash with the "device programming tool" in AVR Studio, using the generate hex file, and use the verify feature. Write some diagnostic code to print to a serial port, then disconnect the JTAG. If your problems go away, it may have been the tool.
  5. Memory stomp. These are pretty common, and can be hard to pinpoint, in pointer arithmetic-heavy code. Stack overflows are particularly nasty and difficult to detect, set breakpoints at your "deepest" code paths, and look at the SP register in the debugger. Comment/stub out large local variables, and eliminate recursion.
  6. Compiler bugs

The last one is actually pretty rare, but it does happen. Odds are you will have found the problem before oyu get to that stage.

--P

Friday, August 23, 2013

Android on the cheap.

Never buy an ubercheap Android device. Android is awesome when done right, but since anyone and their grandma can make one, sometimes that draws you in with their low low prices. I got a $60 4" tablet as a music player on a whim, and I've spent the past two days hoping it would magically decide to all of the sudden not suck. The same goes for phones. It's better to get a phone that was last years' high end phone and/or refurbished than to get a newly released brand new budget level device. I took an in house census recently, and realized our household has 17 Android powered devices, from Cupcake to Jellybean.(Probably half of those get regular use weekly, some are now more sentimental than useful, some are even probably sitting at the bottom of our kids' toybox).  I've modded, rooted, flashed, re-flashed, and re-flashed again custom ROMs, took a stab at compiling kernels, and even published an App, I've come to reluctantly realize I might be a slight subject matter "expert" on the topic of Android devices.

Since most new devices ship with Ice Cream Sandwhich  or higher these days, a great thing to watch out for as far as performance is RAM size. Android 4.X+ just seems to want 1 gig of RAM or more. I've seen ICS and Jellybean on half meg devices but they are almost always janky, while occasionally giving illusions of usefulness. That doesn't stop me from trying a new ROM for some of my aging devices when a I notice a new one on XDA.


I'm sending my latest acquisition back to Grandma... and I'm replacing it with a "major brand" refurb last-year's model. It did cost a bit more than $60, but it has a ton more features too, but the feature I like the best is that it actually works.


--P


Thursday, August 1, 2013

Zaethira Update.

I've made a lot of progress in the past few weeks on my Robot. It had remained dormant for a few months, but I decided to take some time for a context switch to one of my favorite projects. I've got probably 80% of the physical structure built. And the software is probably about 50% done. And the software side of things has made leaps and bounds.

Here's an updated color-coded architecture diagram. I've decided to drop the speaker output feature, mainly because I'm not sure what I'd do with it, but I may resurrect the idea.

Compare to my original chart here

I've got the Pawn scripting working pretty well, I've got some of my low level functionality exposed as Pawn API's, and I've adapted the Chibi/OS shell to treat Pawn bytecode files as "executables" that I can optionally launch in a background thread.

I could probably fill 20 pages with all the developments, but I'm not going to, I just spared myself enough time for a brief post.

Here's a video showing a script running that tries to navigate a square. The compass and and encoder readings are queried in the script to detect 90 degree turns and half meter movements. The compass code is probably beta level, and I'd call the encoder tracking alpha level, so that's why the square is somewhat off. Eventually, I'll have more elaborate geo-spatial reckoning, so that I'll simply command the robot to "go to coordinate x,y, and it will figure out how to get the from the current position(avoiding obstacles too of course). I hope this comes out, Blogger doesn't seem to have an easy way to preview video before publishing a post.

video


I can also control it manually via IR remote controller from a cheap IR helo.


Fun times.

--P

Monday, June 10, 2013

Little Wire

As usual, I've been all sorts of busy, with little time to blog about it.

I did recently score a cache of small, nay, tiny AVR chips recently, and my wife had an interest in making something with them (maybe I can get her to guest-blog about it). Anyways, I was at a local hacker meeting this evening and the subject of programming Attinys came up. As it happens, I just built a couple of Little Wire devices, but couldn't remember the name at the time. For some reason, the name makes me think of Jimi Hendrix. It's an Attiny85 based device that combines USBTiny with VUSB. The really cool think about it is that you can make an AVR programmer for roughly $3 USD worth of parts (and considerably more labor, but it's not work if you love it right?)

Here's one of my rat-nested Little Wire AVR-ISP devices:
Well she's walking through the clouds....

The Attiny 85 has a neat feature that I had overlooked until I built this in that it has a built in PLL that lets you run the system off the internal RC oscillator at around 16Mhz. Many other AVR's lack that PLL, and can only run at 8Mhz maximum without an external crystal.

I like saving my AVR Dragon for when I need to debug or do JTAG.

The easiest way to use Little Wire is with avrdude (I copied the avrdude executable and conf files from the arduino instalation into thier own folder). I then run:

avrdude -c usbtiny -p t84 -U flash:W:<path to my hex file>:i

To burn AVRStudio built hex files into (in the above case) an Attiny 84 chip.


--P

Thursday, May 9, 2013

Random updates.


  • My robot project has stalled somewhat, I just need to set aside time for it. It's been on the verge of awesome for several months.
  • I'm working on a new website, that I hope will let me be more involved with the maker/tinkerer community. 
    • Not ready for prime time yet
    • I've never really done heavy website work before, if Drupal/PHP/css can even be considered "heavy". 
    • rest assured, unwashed masses, this blog isn't going away. I still have a goal of one post per week, though rarely ever meet that goal. 
  • I recently invested in a Laser Cutter, that should, along with my CNC mill/printer, really let me make stuff I never thought possible a few years ago.
  • I'm helping my wife with her first microcontroller project, yes it involves blinking LED's :)
  • I'm currently building my own "Little Wire" AVR programmers, I want to make some quick and dirty no-fuss bulk programmers maybe.
    • I got the idea for this post when going back to my Indictron post, to check how I wired up the USB (I can't get enough detail from the blog pictures, I'll have to dig into my private notes.) I still use the build monitor at work, though it's been having PC software side issues lately.
--P

Tuesday, April 23, 2013

Eggbot and sparking the inner geek in kids.

For the past few years, my wife has taken on the task of organizing our local "spring party", usually themed around eggs, and targeted at preschool and younger elementary school-aged children in the neighborhood. This year we were vacationing in beautiful Costa Rica over the Easter break from school so we held the traditional party a little late - this past weekend. It worked out great because we got a lot of eggs at fire-sale prices!

My wife has an engineering background, and she's getting ready to go back to school for a Masters degree in education, so she can't help but mix the two passions. This year's party was about science, engineering, and of course, eggs:

That's my gal, droppin science!

Wednesday, April 17, 2013

TechShop

I learned today that TechShop RDU is closing.

I live in Cary, North Carolina, part of the "Research Triangle" known for the prevalence of Tech and Biotech companies. It's part of why I decided to relocate here almost 8 years ago, from the Virginia suburbs of Washington.

I'm saddened by this turn of events, even though I never did anything to help TechShop stick around. I liked the fact that it was here, even if the pricing of it was a little higher than I could justify spending on a hobby.

I should resolve to try harder to be involved in local hacker efforts. It's not been a matter of desire, but of free time.

--P

Monday, March 25, 2013

CNC controller case.

Though I don't think I'll have Apple banging down my door to design their next iHipTM device, I'm slightly proud of the fact that I turned this:


Into this:

Wednesday, March 20, 2013

Stainless steel is tough to work with.

Not only does stainless steel foil not cut well, stainless steel plates do not solder well with basic lead-tin solder. resin flux, and a cheapo 25 watt iron.

From the Internet, I have learned that you either need hydrochloric acid, or silver based solder and a much higher wattage iron or even a torch. I don't like using or keeping dangerous chemicals, and HCl is fairly high up in the danger scale.

I attempted to use a butane lighter to heat the stainless steel which I had sanded/roughed after my first failed attempt with an iron. The lead solder formed a ball and slid around on the surface of the plate, resembling mercury. It refused to bond, however.


This is for a probe attachment for my CNC. I've decided to skip the soldering, I will just bend at right angle in a new strip of stainless, and drill a screw hole and attach a lead wire to the screw.

--P

Wednesday, March 13, 2013

Seeding the standard C random number generator on AVR chips.

The rand() function in C gives your a pseudo-random number generator. To purists, it's got a lot of flaws, but I'm glossing over that for this post. In many cases, it is "good enough" to get the job done. A lot of times, I don't care that the distribution is not strictly even when you do something like.

int foo = rand() % 10;

Many times, just a rough approximation like above is enough to make something "feel random".

The rand() function uses a formula that calculates new "random" numbers based on a formula that includes the previously generated value(s).

So where do you get the "starting point" for the first number in the formula?

The standard C library maintains an internal state for the random number generator, and you can "seed" this state with the "srand(unsigned int)" function.

So what do you pass to it?

Well for any given "seed", you will generate the same sequence of pseudo-random numbers. For instance:

srand(42);
int a = rand() % 10;
int b = rand() % 10;
int c = rand() % 10;

will yield the same sequence for a,b, and c every time it is run. What if that is undesirable? It's almost like you need a random number to seed the random number generator, a "catch 22".

On desktops, seed values are often taken from some system time register, on Linux systems, it's sometimes generated from a timer that measures the time between a user typing keys.

On microcontrollers, you often don't have inputs, and system up-time timers don't work because the time will likely have the same value in the power up initialization sequence.

It can be difficult to get these miracle computing machines to be non-deterministic when you want them to.

A trick you may be able to use, depending on your setup is to use the ADC (analog digital convert) built in to most AVR's (on other brand) micros to read a voltage level on a pin that is "floating" or otherwise not tied well to a particular voltage. Here's a short example of how that looks on an AtTiny85:

#include <avr/io.h>
#include <stdlib.h>


void setup_seed()
{
unsigned char oldADMUX = ADMUX;
ADMUX |=  _BV(MUX0); //choose ADC1 on PB2
ADCSRA |= _BV(ADPS2) |_BV(ADPS1) |_BV(ADPS0); //set prescaler to max value, 128

ADCSRA |= _BV(ADEN); //enable the ADC
ADCSRA |= _BV(ADSC);//start conversion

while (ADCSRA & _BV(ADSC)); //wait until the hardware clears the flag. Note semicolon!

unsigned char byte1 = ADCL;

ADCSRA |= _BV(ADSC);//start conversion

while (ADCSRA & _BV(ADSC)); //wait again note semicolon!

unsigned char byte2 = ADCL;

unsigned int seed = byte1 << 8 | byte2;

srand(seed);

ADCSRA &= ~_BV(ADEN); //disable ADC

ADMUX = oldADMUX;
}

In my case, PB2 was connected to a resistor, which was then connected through an LED to ground. When the pin is in a "high z" state (eg, not driven by the CPU), this approximates "floating" close enough to give me nice erratic values. Notice that I use the "low bits" of the ADC. The low bits represent smaller voltage differences, and exhibit greater variance, so they're more likly to swing a lot on a floating pin.

I'm not sure if it was really needed to scale the IO clock down by 128x, I just added it for flourish, thinking more time would mean more variance. I have no scientific evidence that is true though.

Enjoy!

--P

Thursday, March 7, 2013

Updates, random bits.

Here are some things in the works for future posts.

  • My Zen Toolworks CNC is nearly complete for CNC functionality. I have all the parts and materials for 3D printing, I just haven't tired to do it yet, I'm still mastering CNC functionality, and tweaking my Marlin based firmware as I realize I want particular functionality.
  • I have a complete failed project started and scrapped in the space of two weeks, a record for me. I'll write it up later, but one of my goals was "to succeed, or else fail fast", mission accomplished. I did learn *a lot* though, so it was not wasted time at all.

Here are some things I learned recently:

Wednesday, February 20, 2013

Excuse me sir, your voxels are showing.

This occurred to me today, as I listened to a podcast at my day job, and the word "voxel" was mentioned, and explained to someone on the show.

Let's play a game.

pixel --> "picture element"
voxel --> "volumetric pixel" or "volumetric picture element"

But 2-dimensional  is to picture as 3-dimensional is to .....volumetric picture?

That just doesn't feel right. Imagine saying, "Hey Sven, that's a nice volumetric picture of The Battle of Gettysburg you built in your dining room, how did you get your wife to agree to that?".

I submit that 2D is to picture as 3D is to model. I don't remember what I got on my verbal SAT, other than it was respectable, and surprising to linguistically challenged dude like myself, but I think that would pass as a feasible answer.

I'd like to propose that henceforth, a three-dimensional counterpart to the pixel be known as a moxel, "model element".

They don't call me Pedantite for nothin'

--P

[UPDATE] After they read this post, ETS contacted me to inform me they are retroactively reducing my verbal SAT score.