HarleyHacking

Android media devices - a really, really annnoying flaw: no bluetooth microphone (headset) support

2011-09-19T05:44:00.000-07:00

Woot has the Samsung Galaxy S 5 inch wifi device on sale sunday. I have a Toshiba Thrive, but this would have been ideal as a replacement for the cell phone I use on my bike. Well almost. My cell (a Motorola Cliq) runs Froyo as does the samsung. Looking at the specs (not easy to find), just like my Thrive, IT DOES NOT SUPPORT THE BLUETOOTH HEADSET PROFILE. I hope they fix this in IceCreamSandwich. I can plug in an external wired headset into my Thrive, but sometimes that is quirky and defeats the purpose of having bluetooth. If I want to use Skype, Fring, Tango, a CSipsimple, or GrooVe IP, I'm stuck in wired headset or speakerphone mode. I haven't checked if a rooted device can have this added, but it is a stupid and glaring omission. Every phone device supports it so it isn't like there is some complex software change necessary.

iPrefer my android phone

2011-09-09T07:13:00.000-07:00

It is only a Motorola Cliq with Froyo, but I only had the occasional problem, but they were easily resolved. No temperature warning screens. The Dolphin HD browser crashed a few times but I could restart it (my instrument cluster is really stressful, and I had Waze and other things going on). The only hiccup is that it needs something unusual to charge - I don't know what. I have a plain USB cable, which will turn it on but not charge it. I'm using a charging tip and cable from one of my battery packs, and that works. If I just use a plain cable, it doesn't. But my mifi does the same thing.

So far, it is far better than iOS - which also crashes, and they still haven't fixed the problem with the compromised SSL certs.

Ain't too proud to Bleg...

2011-09-09T06:49:00.000-07:00

My avnet contest videos about my harley experiments are at:

http://www.youtube.com/watch?v=BwRO-HOUpLY

http://www.youtube.com/watch?v=z8ij9axe_qc

Please like the video since I can win an iPad. Not that I particularly like iPads, but there is Gazelle so I can get another Thrive or Android phone.

Atmel ATtiny4313 as bluetooth, first post.

2011-09-07T08:42:00.000-07:00

This is a quick post for comments.
The bluetooth module is available from Seeed studios which has a wiki page with the pinouts, etc.
There are many clones - this is a very standard module. I use some 12v 3mm LEDs (with internal resistor) for all kinds of things which I got from Digikey - they are available in red, yellow, or green, so I placed one across PD1 and Ground - it blinks while searching and goes solid on a connection.
Before attaching to the 4313, I used a 3.3v FTDI connection (I could have used the nokia serial cable from the transport entry as well). That let me set the baud rate and PIN.
The project was originally in my earlier post on j1850 to bluetooth which includes another source for the part and a pointer to the serial code archive. One note with the bluetooth module - it has a short timeout so when you do AT+PIN=1234, you can't type it, you must do a copy-paste or something like "echo AT+... >/dev/ttyUSB0" instead of manually typing in on a terminal
I have a hot job at work, but will be posting more details and the code, but if you are in a hurry, a version that does I2C is at my github repo
See also the tip from April about soldering the resonator on top of the Atmel devices.
Sorry for the low quality, but here's a handsketch of the schematic:

Moving my server

2011-08-13T16:42:00.000-07:00

If you have trouble with any URLs pointed at zdez.org, try zdez.com. Zdez.org should work during the transition, but jut in case :).

Blank is Beautiful, or why I will never return to Google Plus

2011-08-05T10:21:00.000-07:00

http://www.maxheadroom.com/mh_episode_16.html

Computer Court 9: "Guilty. Take her down."
Convicted Blank: "I know my rights. I won't be judged by a machine!"
Dragul: "You don't have any rights. You're a Blank."
Convicted Blank: "Blank is beautiful! Blank is beautiful! Blank is beautiful!"

Read the whole episode at the link. Pseudonymity (not Anonymity) is something valuable. I've had the same google profile for many years, and the identity long before that. It was good enough for Buzz. It is good enough elsewhere. Not for Google Plus. They suspended my account.

Note. Data Liberation is A BIG LIE. When the data isn't captive (like when your account isn't suspended), you don't need it. When it is suspended, your data is captive and you cannot liberate it. I tried. It said zero bytes for my plus1s and my stream an the rest - I haven't looked at the JSON, but I'm reasonably sure the data is gone since I deleted my public profile.

I would not mind having more details available, but not easily accessible to any robo-bigot including those run by Google.

They could require an email and a click through and delay several minutes and/or require a catchpa. Or require me to approve access (or require them to be in one of MY circles, or even having been added to theirs for some length of time).

They have the full information since I have Google Checkout so they have my credit card info in detail.

But they want everyone outed on Google Plus. Various groups don't need encouragement via hot air, they need a safe place they can explore and see who they really are. "It gets better - but we are going to make your life a living hell by outing you before that happens with G+ 'community standards'". I'm waiting for some organization to scan the profiles for the "Other" setting for Gender then (snail) mailing or phoning offers of a cure. edit - note I'm not a member of those groups, but a civil libertarian. just after 9/11 "towelheads" were killed, we know what happened in the 1940's and in the Southern USA. And in the century before, Catholics were fair game.
.
.

J1850 interface update

2011-07-23T19:18:00.000-07:00

I have one of my old CR-42 nokia serial interfaces that uses 3.3v, but provides 5v going to one of my AVR 4313s with a resonator instead of trying to go I2C. I couldn't get all the data across the I2C at 100kHz so I moved it to a serial port.

I stripped the plastic part off exposing pads for all the connections including 5v, so I have 5v, ground, tx and rx going to the AVR, and a wire going to J1850 (relying on a common ground).

iOS 3x speed increase for my instrument cluster app

2011-07-01T19:11:00.000-07:00

But first another reason the crippled iOS is only magical in the sense it is something that makes me want to burn it at the stake.

I go running. I send articles to my kindle and it reads them to me. Easy - but it doesn't read the web page, so the upload is an extra step.

The iPodTouch has voicover, so I should just be able to use that. No. First it takes some setup. A triple press of the one button (I'm surprised they don't have a shift, option, control, and apple key) can bring it up. OK, it is now almost impossible to navigate, but I can select a paragraph and two fingers down will start speaking. Until I tilt it - then it speaks "landscape", and stops. Then maybe "Portrait". There is an orientation lock buried in the multiask menu.

Ok, so I've found a long article, press play, put it in my fanny pack... and after about 50 feet it starts back at the top. I didn't do anything, I didn't touch the screen, but maybe "shake" does something. Why can't I have a "just push play" that would read audio. In the background.

Well, that is why this is an HTML5 webapp, not a native one.

But even that they can't do right.

The critical change was to rewrite the URL links to be the IP address. I originally used the mDNS names, e.g. charley.local (for chumby-harley), so the motorcycle instrument cluster would be http://charley.local:2947/hogstat.html, the link itself being "hogstat.html". I only got 2-3 updates per second. I modified webgpsd to prepend the IP address, so it would be "http://192.168.1.5:2947/hogstat.html". I am getting 8-12 or maybe more updates per second!

Ordinary DNS seems a bit slower but does appear to be cached. But why not mDNS? It isn't as if the IP is likely to change in a fraction of a second. Even a 30 second cache would help.

AVR SMPTE ltc (audio time code) generator

2011-06-16T19:10:00.000-07:00

This uses OCRA to generate a SMPTE time code waveform starting at 0 using a 16 bit counter.

The timing is set for a 12Mhz ceramic resonator, ports are set for a ATtiny4313.  Released under GPLv3

Cut Here ----------------

#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/sleep.h>
#include <string.h>
#define CPUFREQ 12000000 

unsigned char frame = 0, secs = 0, mins = 0, hour = 0;
void incsmpte()
{
    frame++;
    if ((frame & 0x0f) > 9)
        frame += 6;
    if (frame < 0x30)
        return;
    frame = 0;
    secs++;
    if ((secs & 0x0f) > 9)
        secs += 6;
    if (secs < 0x60)
        return;
    secs = 0;
    mins++;
    if ((mins & 0x0f) > 9)
        mins += 6;
    if (mins < 0x60)
        return;
    mins = 0;
    hour++;
    if ((hour & 0x0f) > 9)
        hour += 6;
    if (hour < 0x24)
        return;
    hour = 0;
}

unsigned char user[8] = {2,4,6,8,1,3,5,7};
static unsigned char block[10];
void fillblock()
{
    block[0] = (user[0] << 4) | ( frame & 0xf );
    block[1] = (user[1] << 4) | ( frame >> 4 );
    block[2] = (user[2] << 4) | ( secs & 0xf );
    block[3] = (user[3] << 4) | ( secs >> 4 );
    block[4] = (user[4] << 4) | ( mins & 0xf );
    block[5] = (user[5] << 4) | ( mins >> 4 );
    block[6] = (user[6] << 4) | ( hour & 0xf );
    block[7] = (user[7] << 4) | ( hour >> 4 );
    block[8] = 0xfc;
    block[9] = 0xbf;

    unsigned char par, i;
    par = 1; // last two constants
    for (i = 0; i < 8; i++)
        par ^= block[i];
    par ^= par >> 4;
    par ^= par >> 2;
    par ^= par >> 1;
    if (par & 1)
        block[3] |= 8;
}

unsigned char step = 0;
unsigned char oneflg = 0;

#define WIUONE (CPUFREQ/4800)
ISR(TIMER1_COMPA_vect)
{
    if (oneflg) {
        OCR1A += WIDONE;
        oneflg = 0;
        return;
    }
    if (1 & (block[step >> 3] >> (step & 7)))
        oneflg = 1;
    if (oneflg)
        OCR1A += WIDONE;
    else
        OCR1A += WIDONE*2;
    step++;
    if (step == 80)
        step = 0;
}

unsigned hitime = 0;
ISR(TIMER1_OVF_vect)
{
    hitime++;
}

ISR(TIMER1_CAPT_vect)
{
}

/**************************************************************************/
int main(void)
{
    MCUCR = 0x20;               // enable sleep as idle
    PRR = 0x06;                 // shut down USI and Timer 0
    BODCR = 3;                  // disable brown-out detect during sleep
    BODCR = 2;
    DIDR = 3;
    ACSR = 0x80;

    // Select clock, etc for timer |1 = xtal/1, |2 = xtal/8,,,
    GTCCR = 0x81;               // stop for reset - normally to sync multiples
    TCNT1 = 0;
    TCCR1A = 0xA0;
    TCCR1C = 0xC0;              // force clear
    TCCR1A = 0x50;              // now toggle
    TCCR1B = 0xC0 | 1;          // NoiseC, edge ...  off,1,8,64,256,1024,ext
    GTCCR = 0x80;               // start

    TIFR |= 0xC8;               // reset interrupt triggers
    TIMSK |= 0xC8;              // enable interrupt
    DDRB = 0x18;

// Not adjusted for CPU Freq - not using UART yet

    UBRRL = 12;                 //div 13 for 115200 baud from 12MHz
    UBRRH = 0;

    UCSRC = 0x06;               //8N1 (should be this from reset)
    UCSRA = 0xE2;               // clear Interrupts, UART at 2x (xtal/8)
    UCSRB = 0x18;               // oring in 0x80 would enable rx interrupt

    sei();

    for (;;) {
        sleep_mode();           // INT will waken
        if (step)
            continue;
        incsmpte();
        fillblock();
    }
}

I2C is too slow, Serial works

2011-06-15T05:44:00.000-07:00

There are two problems with I2C on the Chumby Hacker Board. First, it won't run at 400kHz (high speed) without a new kernel. Second, you need to continually poll the device.

Using the ATtiny4313 with only 256 bytes of ram, it would lose data even with a 200 byte buffer (for hex, so it would be about 80 bytes of messages). Nice -n -20 didn't resolve the problem, nor anything else I tried, so time to go serial.

I have several Nokia CA-42 cables. You can find them for around $5 from the cheap cell accessory places. Basically they are CR210x serial adapters, but are 3.3v friendly. Even better, if you rip off the plastic sheath, all the RS232 lines are there and a 5v passthrough. So I went back to my serial 115200 j1850 code, removed the molded jacket on one of these, and attached it. I modified the devgpsrc data sourcer code, and can't find a missed message. RPM was at 15.00 messages per second, the fuel messages were all in the low 20s (this is an incrementing counter, I will see a jump of 40 or 60 if a message is missed). All with 20Hz gps on the other channel.

It did stop in the middle of the ride, but the connector might not have been seated properly. Reseating it made it work for the rest of the ride.

I will try to post some pics later.

Venus at 20 Hurts, iPod is hot - too hot.

2011-05-31T09:41:00.000-07:00

The Venus 638 has a strange problem. If it loses lock it has a very hard time regaining it at some times (this is when it knows when and where it is). Hitting reset has it snap back and find all the satellites and lock in a few seconds. I need to try dropping back to 10Hz to see if it still does it.

Meanwhile my last ride went well until the iPod started acting strangely. It would first dim. Then after a while an alert screen titled "Temperature" with a yellow triangle with exclamation point came up. It was 90 degrees, and it was in a box but not that bad. Probably the refresh rate - the back surface did get hot. It needed full brightness to be visible in the sun.

I will need to see if I can get the kindle mounted and tweak the pages a bit more.

My latest test setup - video

2011-05-23T04:57:00.001-07:00

Failure modes

2011-05-21T18:33:00.000-07:00

I finally got the 1.0 Chumby hacker board going (with the rt8188USB module). It works 100% managed mode, but can't seem to create an access point or do some things in Ad-hoc mode. In any case I have another ATtiny4313s for J1850, and am ready to test it.

Today a test didn't go so well with two problems. First, the j1850 keeps stopping. I'm wondering about a problem with the I2C. Second, the antenna wire came loose from the connector, so no GPS. The latter is fixed now.

So far things works. I'm also thinking of creating a "chumbase station" - with two wireless connections, one that roams, one that goes to the iPod/Android/Laptop/Kindle. Streaming an MP3 could go through a proxy that would save a complete image, so it would be part of a library so could be listened to again.

The Kindle is the magical device

2011-05-15T06:01:00.000-07:00

I just got a 3G whispernet kindle. I almost got a DX when it was on a really good deal last month from Amazon's gold box, but the DX doesn't have wifi. But the smaller one is probably better. 800x600 eink screen - and the experimental browser works with the Chumby board - fairly complete HTML5. Not for videos though. And it would help if sites could check the useragent and do a grayscale friendly version (e.g. google maps), but the kindle generally does well enough. Audiobooks I ripped play back in the audiobook folder.

No folders or organizing books, but it has only 4Gb of space, which isn't tight for books, and the mp3 player seems to pick some place in the collection at random to start or continue. I await the kindle app store and/or upgrades.

I'm looking for a 1.8v bluetooth module since there is a 4 conductor connector in one of the side slots that gives console access.

It doesn't have Bonjour/mDNS/uPNP, so I can't use the harley.local type of address, I have to know the IP of the chumby hacker board. But the web browser works on 3G. (I did have to tweak the webgpsd code - it demands the 200 HTTP response code and such before the content).

I wish it had bluetooth for a keyboard and/or headphones but I can get around. I can also use a klip.me bookmarklet to sent webpage articles to be read on the kindle, and the text to speech works well on that. It can read PDFs but some of the features only work if you convert them, but there is a free service via wifi. I was looking for a way to read all the things I wanted like I do audiobooks and the kindle does it.

I can't seem to put even a dent in the battery. And it is really light weight.

Oh, and you can get millions of books, most inexpensively.

Hackerboard version pix

2011-05-08T17:54:00.000-07:00

This is the setup, though packed in a box when on my bike today. I've been fixing bugs as I went (literally, stopped to eat and hack). I've changed the I2C firmware in the 4313 to nak if no data, but to only send one message per transaction to make the reader code cleaner. And tweaked the script to start webgpsd only on "ac", and fixed a number of other bugs. All should be up on github (or elsewhere for the atmel code) shortly.

More chumby hackerboard and Venus secrets

2011-05-08T06:01:00.000-07:00

On the hack connector there is a USB port. It is battery powered. The docs said only the rear USB had power on battery, but this one does too - it isn't really mentioned either way, but I have it powering the GPS with the rear port going to the small module (pics to come). I have one of the battery doors from a real chumby (sparkfun chumby parts) that fit and works.

In /sys/class/power, there is a section for "ac" (external power) so you can see if the power is online, and battery, so you can monitor the discharge. I added a script that would kill (and flush) webgpsd when the battery started getting low, and poweroff when it got lower, but would restart webgpsd if the "ac" goes back up. On the real chumby, I would be left with the last "current.kml" file - this was a mechanism to prevent data loss in case of a crash, and works, but isn't very neat. With a battery, I don't need to worry.

Meanwhile there are two annoyances with the Venus 638 GPS at 20Hz. I have twice left it on overnight, and it would lose a lock (out my window where it can see half the sky). I would expect it to lose it occasionally, but it doesn't recover until/unless I hit reset. Also, it will favor satellite 1 (which is defective, "do not use", will never get a lock) over the WAAS satellite 46 which is visible. It won't drop 46, but with AGPS if there are 12 satellites, even if it won't use them (e.g. too close to the horizon) it won't attempt to lock onto the WAAS satellite.

AGPS is great to make locks quicker, but it might be causing some of these problems. But it also might be when it gets the ephemeris from the satellites and remembers them it would do the same thing.

Progress

2011-05-06T14:36:00.000-07:00

Several useful thing I didn't know but should make things easier.

The one battery boosted USB port can run both the GPS (as /dev/ttyUSB0) and the wireless adapter at the same time, so the I2C doesn't have to run at top speed.

There is a whole power section in /sys/class where I can detect power and battery discharge, and do a "poweroff" after the motorcycle is shutoff.

It still takes about 20 seconds for the USB to come up, but I can startup the GPS logging then. I wish it were faster, but with the battery backup it will be far less of a problem. (If I could only sleep/suspend).

Test Flight, and a few problems.

2011-05-06T12:15:00.000-07:00

It went well, though the infocast has a bit of a boot time, so I'm returning to the hackerboard.

The hackerboard allows mdns to be turned on, and boots up faster, and has the battery, but the battery only powers one port (which I'm using for one of those tiny WIFI adapters). So how to get the GPS in? I programmed up a 4313 with a 12Mhz resonator, and it works (two addresses, one for J1850, one for UART read), but the I2C bus only runs at 100kHz so I get overruns from the 20Hz GPS (the bus itself might be fast enough, but the system overhead means I don't have time to empty it completely as it will be filling at 115.2 and after starting I will only be draining at 100). I'm looking how to fix the timing - it is just a register, but it might need a kernel module tweak.

The chumby has a UART, but it is for the console. I suppose I could launch the GPS data reader off it somehow, but that might make getting to the console hard if/when I need to.

If I can get the battery powered hacker board working, it would do everything I need.

Chumby (infocast) adapted

2011-05-04T10:05:00.000-07:00

A quick note on the ATtiny85 - it doesn't work well for J1850, at least not at 8Mhz. It only has an 8 bit timer and pin change interrupt so I can pull the time of the edge when it is serviced, but with the USI constantly going, it will jitter enough to scramble a few messages.

The 4313 (and the 84) have 16 bit timers with input capture so I don't have to service the interrupt immediately.

Here is a 4313 in a 20 pin socket from radio shack folded into the infocast. I added a USB connector in the power line and brought out the j1850 line (the grounds will be common, or I could use the common from the audio out if I'm using an isolating power supply).

Simplified I2C on chumby

2011-05-03T15:31:00.000-07:00

You don't have to use the message ioctl to access the I2C on the chumby. For the accelerometer, the code is shown below. This actually works better for me since I don't have an address register, I just return data bytes.

#include <stdio.h>
#include <linux/i2c.h>
#include <linux/i2c-dev.h>
#include <fcntl.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/ioctl.h>

int main(int argc, char **argv) {
    int i2cfd;
    int8_t x, y, z; // the readings are 8 bits and signed!

    // Open a connection to the I2C userspace control file.
    if ((i2cfd = open("/dev/i2c-0", O_RDWR)) < 0)
        exit(1);

    if (ioctl(i2cfd,I2C_SLAVE,0x1D<<1) < 0)
    exit(2);

    unsigned char reg=6;
    int8_t iobuf[8];
    for(;;) {
    write(i2cfd, &reg, 1);
    read(i2cfd,iobuf,3);
    printf("{\"accx\":%d,\"accy\":%d,\"accz\":%d}\n", iobuf[0], iobuf[1], iobuf[2]);
    }
    close(i2cfd);
    return 0;
}

Chumby with J1850

2011-05-03T12:19:00.000-07:00

One of my 4313s 8mhz no crystal with a tweaked version attached to the chumby. The connector from the corner is 3.3v, SDA, SCL, X, GND

Chumby (infocast) already ready

2011-05-03T05:39:00.000-07:00

An article on one of the hacking blogs I follow pointed to someone using an infocast. So I reopened mine (I have both models - Actually two of the 8 inch versions, but the display won't work on the one I opened completely.

Several things make this really nice.

1. The hacker port is present so it has I2C ready to wire (for an ATtinyXXX j1850 reader).

2. The USB recognizes the GPS board.

3. mDNS Responder is already there (and with the touchscreen you can attach to Wifi easily).

4. It takes the binaries I compile under scratchbox for the Nokia n8x0 tablet so webgpsd "just works".

The next step is to rewrite the python feeder apps in C for the chumby. No python on the chumby. I have to do something for I2C to pull the J1850 but that should be easy (the wiki at ladyada has the info and I already wrote and worked with the I2C).

Once in place, and after I find the 5v connector, it is onto my Harley with my iPod, android, and laptop.

Minigpsd 0.39, webgpsd plans.

2011-05-01T07:00:00.000-07:00

For nokia tablets, an update so that OBD/harley will work with the 4313:

http://www.zdez.org/minigpsd_0.39_armel.deb

The source is at

http://www.zdez.org/minigpsd_0.39.tar.gz

(I will update github later)

Right now the biggest problem with webgpsd is to get the feeder programs (those that send the harley or gps data into webgpsd) working on all platforms. Nokia doesn't have a recent version of bluez that uses dbus. iOS doesn't have dbus at all, and although BTstack lets me talk (great job Matthias!), I need to write something to set and maintain the connection.

Longer term, the Chumby Hacker Board is at 1.0 and has an I2C which I can use for the J1850, and real USB which I can use for the GPS for both power and interface. I was trying to do bluetooth there but it needs lots of things and Fedora abandoned full distro ARM support at fc12 (I don't know about fc15 and rawhide seems to have it). But I don't need bluetooth for that.

The problem I need to solve is to connect it wirelessly without a great deal of hassle. Zcip is supported and I should be able to get mDNSresponder going (Avahi needs dbus). I should be able to create a default ad-hoc network, so just browsing with any current phone, tablet, player or computer should find it (and tell it where to find a real AP). The CHB could do the logging and web interface can pull and/or manage the logs.

There is also an android project for Harleys which uses ELM-327 OBD2 bluetooth interfaces (I used them in earlier versions):

https://github.com/stelian42/HarleyDroid

Webgpsd harley

2011-04-28T15:22:00.000-07:00

Dashboard:

using javascript - here is a test fixture (the real one is inside webgpsd and grabs the data from webgpsd). I need to clean it up a bit but it shows everything.
It does run on the iPod touch (remotely, but I'm working on a Cydia version of webgpsd, but the bluetooth needs work), or any html5 canvas supporting browser.

Temp, left turnsig, right turnsig

speed (mph)

gear (red if clutch, neutral, 1-6, 0 for unknown like when off)

fuel level

rpm

Quickie - GPS (usb) keepalive

2011-04-27T14:38:00.000-07:00

This uses a LiPo charger from Adafruit. I have a miniB usb power source, and the venus evk board uses the same thing. I had a spare LiPO from an old iPod booster, so created a passthrough. The only problem is that it requires a battery. I have some other batteries, but don't know how long I might want it. This would keep it tracking - even thought the Venus is fast with a warmstart, sometimes it can take a few seconds and it often will take a while to reacquire a WAAS satellite.

J1850 to bluetooth

2011-04-16T07:12:00.000-07:00

The code is at my zdez site

I use a module from mdfly, but any 3.3v with ttl can be used. This particular chip can be renamed and baud rate changed which I did with a 3.3v arduino USB interface.

I'm using a low-dropout regulator from my parts box. Any that can tolerate vehicle (12v+) should work - but many don't. Switching regulators might also work.

20 pin socket is from radio shack.

(I will say "2313" for both 4313 and 2313 going forward)

I'm using a 10MHz resonator soldered on top of the chip.

I'm not using BT TxD to 2313 RxD, but connected it anyway.
The connections to the 2313 are just V+, GND, TxD, and RxD, and the ICP1 on pin 11 across from ground to a 10k resistor that goes to the J1850 line.

ATtiny tip - solder the resonator on top

2011-04-16T05:25:00.000-07:00

You can only set the fuses for the 8MHz internal with 10% accuracy or for a crystal or resonator. And if you set it to require a crystal, you can't use ISP without having one.

You want to use a resonator for the higher accuracy for baud rates or such, but how do you program it using ISP? You can attach a daugherboard with crystal or resonator, but having a crystal at the far end of wires isn't reliable.

The High voltage programming mode works for the ATtinyX5 series, but they are few wires, but the 2/4-313 is parallel with lots of wires.

The usual resonators are on 0.1" wires. What I do is push the middle ground pin to one side, and push the two resonator wires in so that they go diagonally across the top of the pins. Then I take a wire from the center wire (now on the top) and run it to ground.

Note: Some idiot named Vinod was spamming this post for some electronic services in Delhi, so I've closed comments for this one post.

ThingSpeak

2011-04-15T08:11:00.000-07:00

There is a new service that puts devices on the web, Thingspeak.com.

It includes slots for status and GPS style location and multiple sensor data.

I'm going to put my harley on it.

I already have Webgpsd going at github.com/tz1, and I was looking for something instead of or in addition to GPSGate which I did with minigpsd. This should be easy.

The only limit is 15 seconds between updates, but I can send RPM, gear, engine temp, fuel and other bits.

I already have a new J1850 to UART (to bluetooth module) based on the ATtiny2313 - or go right into the Venus GPS and let it do the merge. I need to do a bit of soldering, but it is ready,

Then I need to add thinkgspeak.com to webgpsd and turn on harley decoding again. I'll be busy this weekend.

Venus SDK and EVB

2011-04-13T19:26:00.000-07:00

I got the SDK that goes with the evaluation board for the Venus 638. It lets me add to the firmware and make some changes to how it operates. Thanks to Thorsten for his code and notes.

The downside: The SDK will only do 10Hz, not 20. Most of the peripherals aren't interrupt driven, so things like the UART in aren't really useful since you will lose characters.

The upside: There is a nice I2C core and an SPI core (they use for logging). Most of the data is easily accessible.

So I've been playing with the I2C (after not being able to get the UART to go fast).

I managed to get a newhaven display unit showing the first part of the GPRMC message.

I've also done a J1850-to-UART for the ATtiny2313, which I adapted by adding USI-TWI slave code, which also applies to the ATtiny85, but doesn't seem to work there, probably because it doesn't have a real input capture. The UART version has a 10Mhz crystal since it divides close to 115200 for bluetooth, but the USI version can work without a crystal using the "close enough" 8 MHz internal oscillator setting. If I wanted to get fancy, I could use the PPS or something else on the Venus to calibrate it, but it doesn't seem necessary.

This isn't yet on my bike, but I have data being sent across J1850 appearing as NMEA-like messages on the serial output of the Venus. I have to set the Venus to 10Hz to avoid missing anything, but after some tweaks it seems to be 100%, though I've Digikeyed a bunch of ATtiny4313s with twice the RAM. The code should be up on Github or somewhere similar shortly.

GLONASS+GPS on my satellite display

2011-04-02T11:07:00.000-07:00

webgpsd uses an HTML5 canvas

I managed to bludgeon the code into doing GLONASS alongside GPS. I might update the github repo with it but I really need to clean it up

edit - the latest is always at https://github.com/tz1/webgpsd

(SkyTraq) Venus rising - A new and probably the best GPS/GNSS

2011-04-02T06:03:00.000-07:00

I just got some eval boards from SkyTraq with their new GPS chips.

The first one is the Venus 7 that does GLONASS in addition to GPS (it will do either depending on what is visible - it can do a 3d solution from 2 of each). Limited to 1Hz but the DoP (dilution of precision) is better with the extra satellites.

The second is their new 638 chip that I can customize the firmware (e.g. adding the j1850 directly to the output stream) and runs at 20Hz! It does WAAS, though it seems to have trouble locking in on the satellite and the position reported is off (it should be at the equator which is south of where I am). It also does AGPS so it finds satellites quickly.

Both are surprisingly sensitive, getting good signal strength in many places.

One downside is that NMEA was not designed for two satellite systems. So I have to rip out and replace parts of my webgpsd to accommodate the dual sentence structure. (It is annoying in that the satellites themselves are G+GSV with the + as either P or L for gPs or gLonass, but G+GSA will be P or L if only one is used, but be N if there are two and you have to look at the satellite numbers to tell which it refers to).

gpsd-ng is in worse shape, but I'm going to be working with the project to remove floating point as much as possible and redo the NMEA parser anyway, so this is a good time to do the change.

The GLONASS version does not (yet?) do WAAS or AGPS, or would it be AGNS?

I had both out yesterday. Both worked well but I'm still processing the logged data.

The 20Hz has one artifact. Even at 10Hz the samples are far enough that it looks linear even though there is quantization going on. At freeway speeds you move about 10 feet (3 meters) every 10th of a second. This is about the accuracy of the gps, but is about 30 times the precision. 20Hz cuts that in half and is visible at lower speeds. The position is quantized to fractions of seconds of about 16 centimeters, but webgpsd changes it to 10cm microdegrees.

If you imagine a graph paper where you have to draw lines only from intersection to intersection, if the paper is fine or the lines are long it will look smooth. If the lines are 20 units apart it will look smooth. If 10, it will start to look jaggy. If 5 it will look like an accordion.

Only when you zoom in, and at the higher speeds 20Hz is so much better, but at slow speeds, and with the typical drift of a few counts either way as the satellites move and are recomputed, the quantization effect is that much worse.

Fedorable 14

2010-11-07T15:24:00.000-08:00

I've been switching away from Ubuntu for Fedora and I find it is now far better.

First, I'm upgrading from 13 to 14 and it isn't shoving all the junk I removed down my throat again and making strange and arbitrary changes to my setup. I'm not sure what Malicious Meerkat has because I haven't looked at it but I would have expected them to backport fixes to the current version and that hasn't happened. Another nice thing about the upgrade is you can interrupt it and it will restart (though it will update the update). My boot partition is a bit small so it warns I will need a fixed ethernet connection (instead of the you need a wireless driver - I'll try to download it - oh, I can't because... deadlock in Ubuntu). Everything has been available.

Fedora still has the Gnome flaws that Ubuntu has, but they aren't making whimsical and arbitrary changes to it either instead of fixing the flaws.

As the weather turns colder, resuming projects.

2010-10-27T17:23:00.000-07:00

I've not been idle, but that means I've been riding more than anything else.

But I have a few things in the works.

First, I'm updating minigpsd to work as webapps instead of the earlier APIs, and use JSON instead of XML.

For maps and weather, I have a work in progress here which has a moveable google map with corresponding wunderground radar map scaled to be the same error (within a few percent - any tweaks to the algorithm are welcome). The Javascript program and html are released under GPL.

It works on an iPod touch, a desktop browser, Android browser...

Minigpsd now does HTML5 canvas status images, but I don't think they will work in IE. I tried SVG and it works, but the android browser doesn't support it (turned off!).

All that is targeted at the new Chumby Hacker Board

I have Fedora 12 for ARM working in a chroot, which gives me bluetooth and avahi. The former will read GPS and other sensors. The latter makes attaching easy - create an AdHoc network and use auto-assigned IPs, then http://tz-hhack.local/ to access content.

I've also been playing with bluetooth modules (mdfly.com has them for $10) attached to an ATtiny2313 - serial and ICP. 10Mhz gives 115.2kbaud, and it can read the Valentine V1 or J1850 and replay. The J1850 is working now.

Radar @ Harley

2010-06-04T16:42:00.000-07:00

The following form is what I use on my Harley, though embedded in minigpsd and adjusted for my Nokia's screen size

It returns with an animated gif looking 20 miles (from the radius) from the center to the side of the square.

To see your area, set the latitude and longitude. Or check the national radar to find an active location.

Travel Logs - KMZ and time lapse video

2010-06-01T00:13:00.000-07:00

These KMZs are processed - I didn't upload the ones with the raw data but I might after post-processing.

KMZ of my 10Hz GPS - 5/29 throu 5/31

6/1 - my Nokia tablet had a problem so didn't record a KMZ

KMZ for 6/2

KMZ for 6/3, the end.

Time lapse - much of the sky instead of the road

When given a Limon in Colorado... My harley leaves its mark.

2010-05-31T17:38:00.000-07:00

It is memorial day and the Harley dealerships are closed. My service manuals are over 1000 miles distant, and after filling the fuel tank there was this huge spot. It was the color oil but smelled like gasoline.

Here is my dilemma, and why I'm sitting here writing this post instead of continuing on to Kansas. If it is just gasoline overflow and the color was a false positive (my high-tech oil gage showed empty but it is cold/full), I could have continued. If there IS a more serious problem, the engine would seize somewhere on I-70 and it would get worse from there. So I'm sitting in a nice motel room typing this instead of riding. Where I got on the internet and found more information as to what might be going on. I have the extended warranty (service contract) and AAA trip protection and an extra day shouldn't hurt.

I should mention I am enjoying the ride. Really enjoying it. This is why people ride. Just the scenery. And the bike. And the wind. (And the bugs which got painful in the last few minutes ...). I also happen to have a bit of a sunburn, so it is probably the best thing to pause. I used something which claimed to be water/sweat/sports proof SPF 30 which should be 100% blocking, but why am I so red?

I am in the process of uploading to youtube. And in the process of getting rid of Chrome. I thought that it would work better to upload to Youtube in Chrome, and the only thing I get is the upload percent updated in the corner too. But Google Reader and GMail and other web pages are broken or sticky. Firefox has problems, but they tend to be predictable and although annoying don't do bad things. My folder list was scrambled in Google Reader (it may have thought I dragged something...). Other sites just sat there and spun. While the URL pasted in firefox ran and completed (and I have about 50 extensions). Google, you can do better - much better. Firefox 4.0 should be both faster and actually work.

The latter part of the timelapse of my journey 5/30/10 is of the sky but it should be up in a few hours (and I will post here).

UPDATE - after calling the dealership the next day, although they recommended taking it in (84 miles in the wrong direction) because it was gasoline, it turns out that if you fill the tank with COLD gasoline and leave it in the heat, it will warm up and expand (I tried leaving the cap loose and it splashed a few drops when I tried to close it to a seal after warming up. If you seal it before it will go out that tube just to the front on the left side of the rear tire. When I get to my service manuals I plan on doing another update.

Google Chrome is a stupid early alpha even if it is stable.

2010-05-31T07:11:00.000-07:00

I was uploading the BIG HD timelapse file, and I accidentally selected the new post in that tab. It didn't say "upload in progress do you really want to waste the last 30 minutes". It just killed the upload and YouTube is too stupid to have any kind of resume (This is in FTP going back 25 years).

Chrome (linux) also locked up on something - I couldn't get certain pages (but others worked). They all had the links loaded, but presented the "something on this page is locking up" and killed the page completely to replace it with the crash page so I couldn't even click on a link that might have worked.

If there is a page that the javascript crashes, the links aren't broken. The javascript should be stopped, but display it as a static page.

And be smarter about asking when something is busy. I can't control to force everything to open a new tab (like I have on Firefox), and there aren't extensions yet so I'm stuck with their stupid design mistakes. I will be going back to firefox.

Transcontinental

2010-05-31T07:04:00.000-07:00

I'm in the middle of my trip back to Michigan from San Diego.

For the Sunday part, I have a HD time-lapse on my new Samsung HD http://www.amazon.com/gp/product/B002GYWJ3Y - it was on sale for $99 so I couldn't resist. I will have pictures of the setup when I have some more time.

I entered and became a finalist in the Arrow-Atmel Smart contest but didn't win, but the entry was my motorcycle system. And there was a miscommunication so it was delayed so is being shipped back to Michigan. I had to recreate it, so version 1.5 is on my bike at the moment and I will have an article on that. I have KMZ files with all the relevant engine data of the journey so far.

One feature that was handy yesterday was my live radar map. It is in minigpsd (up at maemo.org in the diablo archive - I should move it to github). It uses the GPS to create a local page with iframe with a map from the weather underground

More updates later.

Anotehr good FAT library - sdfatlib

2010-05-12T08:11:00.000-07:00

It drops into the arduino environment and provides FAT16 and FAT32 access to SD cards. Adafruit has a new SD Shield (sadly, it lacks an SRAM for a buffer, but does have an RTC).

http://code.google.com/p/sdfatlib/

It is C++, in two monolithic sections, one for the SD and one for the FATFS but the author did a very good job of coding it.

New Kent Display

2010-05-11T21:44:00.000-07:00

From Public

This is the new display combined with my QR encoding library, all at http://github.com/tz in the sparkfun repo, in the qrkentlcd subdirectory.

The display holds the image with the power off. This is 4x (one QR square = 4x4 pixels).

It uses SPI, 1 is white, 0 is dark blue.

One big downside is that it is SLOW. It takes over a second to update the display. It isn't going to do fast animations (or rpm updates from my harley :(, it doesn't have adequate sub-screen update). But for things like this - persistent and high-resolution, high contrast, sunlight readable, it works very well.

It is also a bit pricey.

http://www.sparkfun.com/commerce/product_info.php?products_id=9559

with the breakout:

http://www.sparkfun.com/commerce/product_info.php?products_id=9747

Luciferic Lynx

2010-04-15T07:13:00.000-07:00

Ubuntu doesn't change.

Network Manager is still broken, missing the AP which has been on for 5 minutes but listing every AP I drove by. I suppose it would be good for war-driving, just not for managing wireless.

The Upgrade manager still doesn't work right (and will even put all the junk back I took out - moving to Xubuntu helps since it doesn't insist on evolution or mono).

Notify-osd is still broken. I.e. there is no way to configure it to be un-annoying, nor dismiss the boxes.

Grub-2 is still horribly broken. It finds anything which might be bootable and adds it to the menu EXCEPT DOS still.

Here is a DOS tip (following up on my Kursed Karmic post).

Part of my delay posting is my HP netbook - which I like - had some go arounds with HP repair. They were good about it but it took some back and forth until every part functioned properly. They were good enough about it I'm seriously thinking of their tablet instead of the iPadLockIn.

This time they reinstalled Windows, but it was in a better state than I could have restored it to, so instead of restoring my image, I cleaned up XP and shrank the partition, and moved XP up about 1G for a DOS partition. The version of DOS I use for my recovery master USB drive doesn't like booting too far out on the disk. With nothing else, XP worked fine.

Busy with, among other things Busies.

2010-03-29T09:09:00.000-07:00

I have many updates to Hyperlog/Fat32cli and have been on github with comments and such under OpenLog trying to solve the problem of dropped sectors (at high baud rates).

First, I've found a lot of interesting and a few strange things about erasing SD cards. I already mentioned (in the Flashdance post earlier) that SD cards slow down according to performance curves in the spec. Erasing a card turns out to be simple, so I've added an erase routine to the SD driver and a fat32format routine to fat32lib (just over 1k, but not included if not used). And a # command to fat32cli. Erase can take several minutes. Once erased, the dropped sectors should all but disappear until the card's internal flash is fragmented. One possible exception - I am rewriting the FAT and directory entry, but it should be able to shift fairly quickly since it doesn't have to shuffle and re-erase a block.

Second, I've added a 32K SPI SRAM which has enough space to buffer characters at very high baud rates, and added sramlog with the initial version.

While doing this, I found at least one of my cards with a class 6 label reports as class 2 in a program I was using investigating the erase process (They have a way to do so in blocks so you can track progress and cancel v.s. the whole card). Others report correctly. I note this because I can't find ANY utility that does this under any OS on the web after a fairly long attempt with google. So I can't confirm it but am suspicious after Bunnie found lots of fake cards http://www.bunniestudios.com/blog/?p=918 so maybe the next step is to write a utility printing this info out.

In java, Not half bad.

2010-03-07T14:21:00.000-08:00

Updated.

Over at github. A command line finder finder

Run through javac to create the class(es).

java QuickFinderFinder imagefile

The C version and this are now in sync and seem to work well. There are still some optimizations possible, but I don't know how effective they would be.

Very fast constrained QR finder finder - Feature Complete

2010-03-05T22:58:00.000-08:00

quickie.c at github. http://github.com/tz1/qrduino in the imageproc directory

Feature complete, but I need to clean things up. Limited memory usage. Very fast, and except for the initial check, has a linear runtime (i.e. based on the width or height, not area).

Completely accurate and surprisingly effective even if the constraints are bent.

It finds 50% of the test images in the zxing set, with one false on a 45 degree rotated image (way out of the constraints).

There are a handful it fails on which it might otherwise work on an actual camera but have some subtle but serious distortions due to the image sampling, e.g. the 11311 ends up as 1 3 6 3 2 or 2 2 4 2 2- the outer box is too thin or such as the edges are just at the wrong camera pixel boundary. One gray

Constraints:

One finder pattern needs to be close to the upper left corner of the image. It need not be exact but there is a chance that the noise in the white background might be mistaken for a finder.

The finder patterns must be vertically and horizontally aligned within a few pixels, i.e. drawing a line vertically or horizontally from the center of one finder must intersect the center 3x3 of the other. It need not be perfectly flat but perspective distortion will cause this to be violated, especially for large codes.

Update: I have a "try harder" so the 3x3s need to overlap, not just the center.

The finder patterns need to be undamaged and have sufficient contrast.

Module size should be at least 3 pixels - 2/4 eroded, but 3 average.

It doesn't require the finders be below and to the right - it will interpolate the third from the second.

This is easily done with a cell phone camera, though preferably with a box and guide lines so the image can be aligned and be within the scan area.

Method:

Start 17 pixels (module size) down from the top and start tracing diagonal lines up and to the right across the gray field (no, it doesn't have to be histogram-ed or thresholded into black and white). Find the average luminosity of the line and use it as a threshold. Reduce the crosses of the average to run-lengths. Process the run-lengths to find a 11311 pattern, e.g. 20,[4,5,11,4,4]... This will be diagonally across the corner finder pattern. Do a plus sign to find the extents (using the same average for a threshold), then find the center of the 3x3 box, and record the size.

Going vertically, start from just below the original finder, and use an adapted average based on the average at the ULF (upper left finder). Look for the same 11311 pattern, and do the same width-height calculation. Throw away sizes very different from the ULF. There may not be a finder pattern if the code is rotated clockwise, or there may be a fake one, so just store it for now.

Do another search, but horizontally to the right from the ULF.

(if the code image wasn't rotated, you probably have the three now, but you still might have to evaluate as there may already be some false positives).

From the center of each potential finder found vertically, search to the right horizontally.

From the center of each potential finder found horizontally, search downward vertically.

You now have the complete set of finders and know the module size. Some might be duplicates so sort them and pick the three based on size (close to the original), distance (square if you don't want to allow rectangular pixels) and right angle.

I'm adjusting the sorting criteria now - it is possible that every false positive could be eliminated in the runs scan.

Summary

I don't require thresholding the image before hand.

I only examine a tiny fraction of the pixels in the image. (2 scans per diagonal initially, but those are short, and then one each vertical and horizontal, then one per pattern found in the v and h scans). I don't do any complex mathematics - only maintaining the dynamic threshold and evaluating if the current pixel is above or below - and I don't even store a line, only a list of run-lengths.

Test pic qrcode-4/09.jpg finds 3 wrong patterns, but the image is at 45 degrees, way out of alignment.

No false positives get through.

(After finding it, you can then run it through the thresholding if desired - but you would only need to do the part of the image containing the code modules, and you have the finder positions and module sizes, so can start looking for alignment patterns or version bits).

QR code image processing - part 2

2010-03-04T21:16:00.000-08:00

Image Processing code here

I went through the zxing examples and code.

The zxing methods aren't the most effective. It uses a simple threshold which fails badly on many images where the lighting is not uniform, e.g. where a white pixel in the lower right has less luminance than a black one in the upper left. It uses a static histogram.

What I came up with is a dynamic line-by-line histogram window of 64 pixels, applied horizontally and then anded vertically, i.e a pixel must be "black" in both directions to be considered black in the output.

Note it doesn't produce good results for anything other than barcode - a 64x64 square would probably work better. However when there are clear distinctions between white and black in the window, it produces a result where the next steps can easily find the finder patterns.

There are a few problematic images in the set they use to test- but they violate the spec. They are those that seem to be a white overlay over some other kind of picture, so white is white, but black is anything from 0 to 80% of white.

Stepping back a moment - I want to be able to find QR codes anywhere in the image, and to try for fairly severe angles. If I could constrain it to a rectangle where I know the borders around the QR code are completely white, or it is perfectly cropped so the finders align with the picture edges - all nearly vertical or horizontal it would be easy and I could take a completely different approach which would handle a lot of these cases since I would already know how to set parameters up. For all the variation, there can only be two ultimate values, black and white, and they are supposed to be finder patterns at the corners.

But for the photographs, I need to be more flexible. I end up with noise and the QR image with the black pixels eroded. Note that the zxing algorithm erodes black squares in bright areas and dilates them in dark ones.

So hist.c reads in a PGM (ascii, no comments like the GIMP adds) and applies the line histogram windows and outputs a PBM (stdin to stdout).

Now the problem is to find the finders. They are 1-1-3-1-1 patterns, which are easy to find. Here (finder.c) I do horizontal, then vertical, anding the result. There needs to be some window for the pixel sizes so I do approximations - the white spaces and outer black should be equal, and the inner black should be about the sum of two blacks and a white. Note this will still find the patterns at 45 degrees off, but will find the middle square in the diamond after the and operation. With the noise it often has gaps, which I will explain how I'm fixing shortly. To find the 11311, I first create an array of run lengths starting with white as 0, then check at the odd numbers. i and i+4 should be about the same, i+1 and i+3 should be too, and i+2 should be the "3".

The sensitivity seems about right now, but I might have to adjust the calibration to compensate better for the erosion of black if I test more cases. 10 eroded 2 becomes 8 (x3=24), with the gaps becoming 12. and the "3", 30 becomes 28.

Note that the finder 11311 ratio pattern has a high negative in the encode weighting, but still can occur within the main body of the QR code, though it would be very unlikely a real finder pattern would occur.

Version 1.4 of the zxing finder finder code has problems. Many of my perfect jpegs generated by qrduino FAIL. First, it will end early if it finds three likely candidates that have the ratio in both the vertical and horizontal in one row/column, even if they look like plus signs and not squares, aren't at good angles, or anything else. Second, even when it scans the whole image, it selects the first three blobs, and makes no attempt to insure they might be the right size, angles, or anything else. I changed the code to scan the entire image, then pick the largest three candidates and it found all my qrduino images and more of the test images.

My code should also work on rectangular images like the LCD below. The zxing requires the vertical and horizontal sizes be similar.

In most images there are three big squares whose center is the center of the finder pattern. When the ratio looks wrong, it causes only one corner or some lines of the finder to be recognized. So I added to my code (and still needs adjustment) orthogonal dilation. If there is a found block in a 11311, and on the right are black pixels, it will widen the block 1 pixel. And will repeat until the edge is not completely made of black pixels. That is left to right. Repeat top to bottom, right to left, and bottom to top. All the finders are found, but there are other blocks on the screen but few are square, and most have black pixels bordering a significant part (unlike the white in the real finders).

I'm outputting a PGM showing the candidates. Some earlier test code would place 3 dots in the real finders, mostly at the center in almost all the test cases using the zxing black and white routines. The next step is to throw out bad aspect ratio images, and see if any hard cases remain, then finish off to see if I can consistently pick out the centers of the 3 finders.

Once I have the 3 finders, I can then use the knowledge of where things should be to go back to the original image, or to make things easier even in the processed version. I have a box around the image.

I haven't done a FFT yet, but actually the Goetzel algorithm should be better for the module size.

QR Image processing made easy?

2010-02-27T21:03:00.000-08:00

One of the difficulties in scanning a QR code is determining the size of the "modules" - the black or white blocks.

QR codes try hard to avoid runs of one color, and to have 50% so each line will look a lot like a square wave at some frequency, with peaks at f (strongest), f/2, f/3, etc. The period corresponding to this frequency will twice the size of a module.

I can easily get this number, or a very small set of candidates, and even separate horizontal/vertical values for rectangular distortion using two common utilities: netpbm and audacity. Yes, the audio processor.

First, use netpbm to convert the image into a .PGM file, portable gray map. Gimp will also work for this, (and despeckle and a slight blur will remove artifacts in the later step, but it is optionas). It will have some header lines (which can but need not be discarded), then import this pgm file into audacity as unsigned 8 bit mono data at 100000 Hz (this number makes it easier). Then run Analyze -> Plot Spectrum and select Enhanced Autocorrelate. Use a buffer about the horizontal size of the image (e.g. if the picture is 1200 wide, use 1024). If you use this or the frequency spectrum (use logarithmic display) you will see a peak around the size of 2 modules. The BWBWBW pattern produces a frequency component of twice the module width.

Rotate it 90 degrees for height instead of width, or if it is supposed to be square, append the rotated version to the original. Netpbm can do this too.

There will be few peaks. In the case of a picture of an LCD, the only significant peaks were at .00070 seconds, 70 samples. And the modules were about 35 pixels wide in the image.

QRduino - First Release

2010-02-26T16:33:00.000-08:00

http://github.com/tz1/qrduino has been active for a while. So here is the first release version, under the GNU General Public license, Version 3.

It now is faster, with both generate a fixed version table and parameters in to a C file (pick the ecc level and size - no longer hard coded, mainly for AVR/embedded) and an on the fly version with mallocs (for the rest). Note I don't free the memory since I'm doing a CLI which expects to exit - the fix is for the next version.

I don't use any modulo or divides in the encoder anywhere so it is even faster now. And there were other optimizations. The mask array was symmetrical (mirror down the diagonal) so I stored it as a triangle. I'm playing some games with buffer reuse so it doesn't have to regenerate the frame for masking, but it doesn't use much more space.

For the embedded, all fixed data tables are in flash. Minimal (8 bytes, but const) data segment usage for the AVR version of the encoder with tables or dynamic generation. Optimized BSS usage.

I will be adding to this post later with some examples.

Newhaven Display + QRduino = much better

2010-02-23T22:15:00.000-08:00

The focus wasn't perfect when I took the picture, but it worked on my Cliq:

This is in more normal light:

Toolbox: NetPbm

2010-02-23T14:36:00.000-08:00

NetPbm is a set of utilities that use a very simple bitmap format that allow for easy scripting and manipulation of images. First, pnmtoplainpnm will output the data in ASCII where it is easy to edit or otherwise process with text utilities. But there is pnmarith that lets me do a -difference to compare two bitmaps (how close are my qrcode images? this shows it easily).

You can also do simple operations like pad and scale, or convert to or from other formats easily.

QveRsized.

2010-02-23T14:08:00.000-08:00

GitHub has the current revision, but it doesn't match the other implementation perfectly, and above a certain size, I can't test it with my camera, e.g.:

This is version 40 - the largest possible, 177x177. It would probably take an arduino mega, and then I would need a display - and something to read it. But as a benchmark, the lcd compiles to:

avr-size lcd.elf

text data bss dec hex filename
13502 100 7961 21563 543b lcd.elf

The frame generator is separate, but probably wouldn't use any more RAM, only flash.

QRduino

2010-02-21T22:02:00.000-08:00

QR codes for embedded systems:

Which takes about a second to generate on the Arudino.
$ size lcd.elf
text data bss dec hex filename
3676 30 1895 5601 15e1 lcd.elf
It fits in a 328, and I'm still working on the bss usage which is mostly the 1641 for the frame, and 172 for the input bitstring.

Unfortunately, my Cliq won't read it nor will zxing. Probably the distortion since the pixels aren't square. This is a jpeg (and check github in the sparkfun wiki for information on embedding twotone jpegs):

QR codes are two dimensional bar codes.
Those are the boxes you see in place of URLs - because they are URLs,
just encoded

But first a few links to resources

A C based qrcode program is available at:
http://pyqrcode.sourceforge.net/
It uses a python wrapper, but produces PNG files

This was something I could use to test my version - I modified it to produce a PBM file (ASCII text 1s and 0s), as well as checking if what I was calculating was right by dumping some of the internal structures. This forced me to copy some of the quirks (they have some bits as flags or whatever so when I dumped their frame, it was either write something to post-process or duplicate the quirks; They also do something strange in the demerit code which I had to duplicate to get the same numbers, and had one ugly recursion in the data fill). After I have something working, I can test N v.s. N-1 to see if anything changed, but how do I get N=0? This was the easiest to use to get a known good version.

Java based, android code, and online:
http://code.google.com/p/zxing/

The wikipedia article covers most of the details:
http://en.wikipedia.org/wiki/QR_Code

A word about words. The ISO spec and most websites use different terms which can be confusing. "Version" is size. Version 1 is 21x21, version 6 is 41x41, and they go up by 4 each version up to 171x171. They call the black or white blocks "modules" instead of dots, blocks, or pixels.

QR codes have a lot of options to cover a large number of use cases.

I'll go through them and note why I chose to do things a certain way.

Data to Coded Bitstream

The first step is to turn the letters, numbers, etc. into a string of bits. Here there are a number of optons. There is a tightly packed code for numbers, another for alphanumerics (44 symbols including uppoercase letters and numbers, and common symbols used in URLs). Then there is a byte coding, and finally Kanji. They can also be mixed, so if you have a URL that has a long set of letters for a directory with a file with a long string of numbers, the first part can be coded in 8-bit, then switch to alphanumeric, then switch to numeric, and maybe back and forth. This way you can pack far more symbols.

Note that it is NOT REQUIRED to use more efficient methods. The downside of the numeric and alphanumeric coding is that you must operate at the variable bit level and pack strings of bits.

For my implementation, I just use 8-bit. This only requires shifting things three nybbles (3 times 4 bits) to the right for the prefix type code and a byte for length (for this implemetation - it can be two bytes). At the end a zero nybble is appended. To encode "HI", it would be hex 48 49 becomeing 00248490. The code is short and compact.

After the 0, which is an end marker, if there is space a set of alternating bytes is used as a fill pattern for the data space, so there will always be something in the buffer, and it allows me to specify a larger size even if I don't use all the space.

Error Correcton

QR codes use Reed Solomon error correction. The mathematics are well known, but QR Codes offers 4 levels. A particular size can only hold a fixed number of bytes. In the case of version 6, it is 172, so if you have more error correction codes, you have less space for data.

There are four levels, lwo, medium, quality, and high. I'm using low since the images will be digital. If this was for a thermal printer I would choose one of the top two. The low level can lose 7% of the bits and still recover.

The next step depends on the size, and for V6, L ecc, the data is split into 2 blocks and the correction is added to each block separately. So 172 bytes holds 136 data + 36 ECC, but that is split up into the first half, 68 data, then 18 ecc, then another 68 and 18.

Larger codes are split into more blocks, 4 is typical, smaller ones are just one block.

The Frame and the Data.

There are fixed sections of the QR code image which the data has to wrap around, and the data bits zig-zag from the right corner left, then right and up, then left, and around these fixed areas.

Also if there are multiple blocks, it uses the first byte from each block, then the second from each block, and so on.

This is as complicated to code as it sounds.

The fixed areas include the large squares in the three corners, and the small target-like alignment squares (above v1) in the other corner, and added in the middle as the image gets larger. There are also one row and column of alternating black and white blocks.

Backing up a moment, one reason I chose to use 41x41 version 6 instead of version 7 is there is a "version" data block which has its own coding scheme and ecc and rules. This creates a bit of a stup in the complexity since you need to implement functions for these blocks for anything v7 or larger. 6 was a nice size and largest without this.

There can be more pixels than data, and these are set to zero (black) initially.

Masking

The problem is that most data isn't a nice 50% black/white noise pattern that would have clear edges in each row and column and no blobs of black or white. So for the areas which are not fixed, a mask is applied. The most basic one is a checkerboard (flip every alternate bit). But there are vertical ro horizontal stripes and more complex patterns.

There are 8 masking patterns in all and each is supposed to be tried and a weighted functions identify bad combinations. A large amount more of one pixel color is one. Series of pixels that look like the locating squares are very bad. Long runs or large blocks of black or white are bad. A weighted sum is produced for each masking pattern and the best chosen.

Here is a place I cheat. I printed out a sampling, and found a threshold number I use to say "good enough" The numbers are just under 2000, and usually there would be one or two under 1800.

There are two reasons not to try all 8. First, to save memory I don't want to use a separate buffer, so I end up drawing the unmasked image each time. If mask 3 is the best, it has to be redone after the later ones are tried, but if the mumber is low we can jsut use it "now". The second reason is that the masking algorithms become more complicated (read slower) - they have modulo 3 divisions and more operators so mask 7-8 may take 10x the effort as mask 1. So if mask 1 is "good enough", i.e. has a low score, I just use it.

Finishing up

The final step is to write some format information indicating which mask is used, and it wraps around the edges of the big alignment markers. But that is the last step - the QR code is complete.

The code will be at github.com when I finish a bit of packaging.

Sparkfundamentals - But can it draw circles?

2010-02-16T18:41:00.000-08:00

I used a compass in school. Actually two, but I would stick with the one in Geometry class as it had only one sharp point which went to the center of the circle.

The other one from science pointed north.

Sparkfun has created a breakout board with the wonderful HMC5843 chip. It is a magnetometer, but to cut to the chase, it is a 3d compass.

If you remember the bar magnets and lines of force (iron filings on paper with a magnet beneath) you would see the roughly elliptical shapes made by the lines of force.

The same thing happens with the earth's magnetic field, but most compasses don't have an easy way to point outside of the horizontal plane. But the field isn't flat, but varies by how far away from the magnetic pole you are. At the north magnetic pole the north side of a compass would want to point straight down.

But this chip returns X, Y and Z axes. In an earlier post it was this chip connected to the Arduino. One of the interesting

With the capacitor pointed "north", the values returned (from San Diego, CA with magnets in the room) are: -38, -465, -566.

(Code for this is at http://github.com/tz1/sparkfun in the i2cperiph directory).

This is about right. The large negative Y is toward the north, the negative X because I am west of the pole, and the large negative Z because if you draw an image of a bar magnet, the magnetic field is going into the earth. Or maybe toward some bit of metal :).

There is a rate setting for the chip, but the ones I've seen have been fast. The "50Hz" setting gives 60+ Hz. Sometimes as much as 75Hz.

Note that earlier (and perhaps currently shipping) versions of the breakout board used a high-ESR capacitor. It caused the chip to reset when it tried to do a measurement.

Decoupling is needed because chips tend to have a power surge when they turn on. Sometimes you can see this at home when your refrigerator or some other appliance turns on and the lights dim. This can have two problems. First, if the surge is large, it will cause digital signals to go wrong - if it needs to put out 2.4v, and the supply voltage at the pin drops to 2v for a few microseconds, the output will bounce or not be seen as a "1". Worse, for chips like this that do analog, the voltage references can bounce around causing a lot of noise - if 100% means close to the power rail, but the power rail moves, what value is it really?

There is a tiny note on the datasheet for the HMC5843 warning about capacitors, but not really saying what is needed in exact engineering terms. But it warns against using tantalum or other high ESR capacitors. ESR = effective series resistance. Every component, if only because the connections aren't superconductors have a built-in resistor between the actual component and the connection. Some are worse than others. The surge for this chip is deep and fast enough that you need a capacitor to respond instantly with a lot of current, and it can't do that through any noticeable resistance. So you have to use a common but specific kind of capacitor. That is why on the product page, there are recommendations to add or change the capacitor.

If strange things are happening, and only with this chip, and it has a fairly thick and large black capacitor opposite the connector, it probably needs to be changed.

I've heard there is a fix in the works.

But with the right capacitor, it works flawlessly. They did change the capacitor on the 9DoF board which uses the same chip, and it works fine on that board where it shares the I2C bus with an ADXL345 accelerometer.

There are other projects using this chip including an arduino library - google for "hmc5843 arduino" for more or check out the sparkfun forums.

JPEG - Huff & puff

2010-02-15T22:09:00.000-08:00

As part of my JPEG experiments, I've already done a byte per 8x8 block.

http://wiki.github.com/tz1/sparkfun/two-tone-jpeg-made-incredibly-easy

I wanted to try to get it down - you might think it would compress more, but the overhead of the coding prevents it.

Most of the information is at:
http://www.impulseadventure.com/photo/jpeg-huffman-coding.html
or from the output of his jpegsnoop program.

First, there is an AC component code of 1 bit even if there is no AC on any of the blocks.

Second - and here is one of the keys to understanding the JPEG bitstream - the huffman codes are followed by the magnitude codes. That is what the "length" means, i.e. the bytes following the actual table. The best I've come up with is about 2.5 bits.

jpegsnoop doesn't split out the tree from the value.

Here is the table (from the program):
1, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
2, 1, 0,

1 code of 1 bit, followed by 2 bits. The two bits represent the values -3, -2, 2, 3 for 00, 01, 10, and 11 respectively. 0 is assigned first, so the codes would be
[0][00] for -3
[0][01] for -2
[0][10] for 2
[0][11] for 3
The values are from the above page, at "Table 5 - Huffman DC Value Encoding".
The next entry says there are two codes of two bits. 0 is used, so they will be 10 and 11 prefixes. The first has a 1 bit value, which is for -1 or +1 for 0 or 1 respectively. Continuing:
[10][0] -1
[10][1] 1
And finally a zero bits code is an "end of block" marker or no change, which is the second two bit code:
[11] 0

So to encode black and white squares if it starts with black, we need to move from 50% to 0%, so luminance would be -1, the code would be [10][0](0) - the (0) is the AC component. Then if the next block is also black, it would be an EOB or [11](0). If it were white, we need to add +2, and that code would be [0][10](0).

To recap, the huffman tree itself is:
[0] - two bits follow to indicate values of {-3,-2,2,3}
[10] - one bit follows, values {-1,1}
[11] - no bits follow, value is 0, the end of block marker.

For chrominance values, they are encoded as (the underscore separates the tree from the luminance value code):
0_00 -3
0_01 -2
10_0 -1
11 0
10_1 +1
0_10 +2
0_11 +3

So to encode the bitstream:
100110101
you would need
+1 -2 0 +2 0 -2 +2 -2 +2 0(eob).

If you didn't mind it going between 50% gray and black or white it could be reduced:
1, 1, 0, 0...
1, 0,
so [0][0] would be -1, [0][1] would be +1, and [10] would be the no change/EOB.

With a white background, for things like barcodes or text it should be enough, and ends up being 3 bits (2 DC, 1 AC) per block instead of the 3.5 average above.

Sparkfundamentals: I2C

2010-02-15T20:35:00.000-08:00

I am starting a series about sparkfun products I've used and programmed for.

I use a lot of I2C devices on breakout boards, and Atmel devices have two common interfaces - USI or "universal serial interface" common on the ATtiny series, and the TWI or "two wire interface" common on the ATmega series. I've written about my USI driver here so search the archives. But I more commonly use an Arduino:

Here you see the 3.3v Arduino pro connected to a 3.3v FTDI breakout wiht the 3.3v and Ground from the pins (hidden behind in the picture) and SDA/SCL from the two right angle pins in the middle going to an HMC5843 breakout.

My i2cperiph code over at github (http://github.com/sparkfun) uses this setup. All I have to do is attach the 4 pins and since the Arduino can enable pullups on the TWI pins I can just plug and play.

A better way of doing pullups is with a current mirror. A circuit is at http://www.i2cchip.com/constant_current_pullup.html but you can use four 2N3906s or a BCV62 as shown in the article, though it is a surface mount device. That would make a nice breakout board. And I wish SparkFun would standardize the I2C breakouts to correspond to the Arduino pins on the larger boards or do something so that I could just stack them and a terminator.

The code over at GitHub uses an array with the length followed by the bytes to go over I2C (if the address is odd, they are read and filled in). It produces a restart condition until it gets a length of zero where it sends a stop. This makes changing code easy for most things as I just have to create a table with commands. Where it doesn't work as well is when I have to put pauses in the stream or do other things like change what I do based on a response. Most of the time they can be separate commands but sometimes they have to be integrated with the communication. For now, it works well to exercise the hardware and print out results to a terminal.

EyeFi and JPEG over at github

2010-02-15T09:46:00.000-08:00

My notes on getting the EyeFi to upload jpegs bearing other data:

http://wiki.github.com/tz1/sparkfun/automatic-wireless-uploading-with-the-eye-fi

And how to create JPEGs with black and white pixels easily:

http://wiki.github.com/tz1/sparkfun/two-tone-jpeg-made-incredibly-easy

Where is this leading? Think bar codes. I'm looking into QR codes (though the reed-solomon error correction might be a deal breaker for embedded), but the general idea is to have thumbnails you can scan with a smartphone or other imaging scanner.

Strobe - pics and video

2010-02-13T23:59:00.000-08:00

A commenter pointed out I omitted them, and since I've finished some other projects, I'm returning to this.

This is the less expensive timing light from Harbor Freight

http://harleyhacking.blogspot.com/2010/01/strobe-smaller-cheaper-easier.html

One warning - the flyback transformer that powers the 300+ volts (the black box with the blue vertical stripe in the middle) will get very hot if you have it on continuously - I'm looking into a heat sink. But it does seem to keep up. The board doesn't seem to be of the highest quality, but for $12 and a fairly fast speed, I can't complain. (The disposable camera flashes take a brief time to charge so can't normally be used like this).

The yellow wire is +, the short black from the corner is - and it runs on 12v, but goes down to 9 (a NiMH 9v works), and probably up as well. These came from the battery clips The long wire to the center is capacitively coupled to the triggering mechanism, so will flash on the right edge.

And I have a fan video:

(YouTube has an annoyance - upload video - it doesn't appear in your list even after several minutes and refreshes, upload video again, it appears and says it works, but sometime later the first appears and the second is deleted as a duplicate).

I need to adjust the arduino software to display the current RPM and let me type it in directly (or at least the period).

Flash Dance on SD/SDHC has intermissions.

2010-02-06T09:53:00.000-08:00

Most of the time the SDHC cards will work really fast. Then there is this long pause.

The SD Group Simplified Specification V 2.00 sheds light on what is happening.

On page 45, it says that it may take 100mS for read and 250mS for write for timeouts, or 100x longer than the typical time.

Page 70 has a curve. Basically it is an exponential reduction proportional to how full the card is, and at about 30% full it shows performance drops to HALF the original rating. And the curves are very steep at the start.

There are allocation units - and these are erasable blocks, but also recording units which are the "sectors" (or maybe multiples)

Write Performance and Read Performance are left blank, but it shows a ratio of used to free.

Basically as you use more and more flash, the complex algorithms kick in to map your sector to one of these units, move them, erase pages, etc. Except for the latency, this is transparent.

So for something like the using it on an embedded system, unless you completely erase the card first it can have frequent high-latency periods and lose data at high baud rates unless you have a big buffer.

github restore

2010-01-24T21:33:00.000-08:00

With a few strange links I can download, and they apparently have an old caching problem causing the problems which are fixed at least for me.

Since I was offline, I decided to refactor the build directories so the stuff which talks to sparkfun hardware is in:

http://github.com/tz1/sparkfun

Most of the rest of the Atmel/Arduino stuff is in

http://github.com/tz1/partsbox

My viceousness toward virtual entities.

2010-01-23T19:16:00.000-08:00

My frustration with GitHub exposes a rule of the internet:

If you want a purely faceless, robotic, collective, virtual internet presence, don't expect to be treated like a real human because you are doing your best to completely dehumanize the transaction.

GitHub isn't unique. It is cheap to NOT have more than one email address for contact, just web forms. No phone number anywhere. No address, not even the country whom/whatever are based in. Whois returns some information...

I overreacted, and might even want to apologize - if there was an actual human to apologize to. Oh well.

EyeFi + JPEGtrigger = instant netcam

2010-01-23T17:06:00.000-08:00

Yes, it does work.

Still some instability, maybe hardware, or software adjustments (921600 baud can hiccup).

http://www.zdez.org/dcimmer.zip - 100 images, checks the port D pins and should continually record, but this also needs verification.

(update - the current tree is at http://github.com/tz1/sparkfun in the dcimmer directory)

GitHub has SOME support and is broken

2010-01-23T16:57:00.000-08:00

(Edited - GitHub did get back)

I can't upload. Actually I uploaded one thing, but the second would silently fail and just show the select file. I reported it somewhere on Friday and got no response or acknowledgment even now. They use some flash app that worked once, but the next time would bring up the file dialog, but ignore the fact I selected a file without any error message or anything I could guess at. Why they use flash instead of plain HTML forms? I don't know. In any case I can't upload to the download section of their pages.

Something went wrong with one of my repositories so I deleted it. Or thought I did. It created a zombie repository, so I couldn't refill it with the correct files, I could go there and it shows the "new repository" screen but I can't do anything with it. Apparently they did get back to me shortly thereafter but the email or something was delayed. Apparently they are working on this problem.

I hope they will fix it, but I find it frustrating. Things don't work, some times I get a reply, sometimes I don't, and I'm trying to get some work done this weekend.

I've removed the repositories while I look for some alternative.

GitHub

2010-01-21T15:14:00.001-08:00

Starting to put stuff up on GitHub:

http://github.com/tz1

Lots of stuff is there already.

Sparkfun's serial jpeg camera in C (with 921600 baud shift - over 1fps)

2010-01-20T16:10:00.000-08:00

For linux, mostly. C/stdio/termios. Run gthumb cam.jpg after the file exists and you can see it update.

#include <stdio.h>
#include <string.h>
#include <termios.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdlib.h>

static int serfd;
static struct termios tio;

static int seravail(unsigned long tmo)
{
    struct timeval tv = { 0L, tmo };
    fd_set fds;
    FD_ZERO(&fds);
    FD_SET(serfd, &fds);
    tv.tv_usec = tmo;
    int i = select(serfd + 1, &fds, NULL, NULL, &tv);
    return i;
}

static void readlen(unsigned char *buf, unsigned len)
{
    int i = 0;
    while (i < len) {
        seravail(10000);
        i += read(serfd, &buf[i], len - i);
    }
}

static unsigned char cmdjpeg[6] = "\xAA\x01\x00\x07\x00\x07";
static unsigned char cmdreq[6] = "\xAA\x04\x05\x00\x00\x00";
static unsigned char cmdsnap[6] = "\xAA\x05\x00\x00\x00\x00";
static unsigned char cmdp512[6] = "\xAA\x06\x08\x00\x02\x00";
static unsigned char cmdbaud[6] = "\xAA\x07\x01\x01\x00\x00";
static unsigned char cmdrst[6] = "\xAA\x08\x00\x00\x00\x00";
static unsigned char cmdsync[6] = "\xAA\x0D\x00\x00\x00\x00";
static unsigned char cmdack[6] = "\xAA\x0E\x0D\x00\x00\x00";
static unsigned char cmdnak[6] = "\xAA\x0F\x00\x00\x00\x00";

static int cmdwack(unsigned char *cmd)
{
    unsigned char buf[6];
    unsigned char max = 3;
    while (max--) {
        write(serfd, cmd, 6);
        if (!seravail(5000)) {
            printf("cmd %x timeout\n", cmd[1]);
            continue;
        }
        readlen(buf, 6);
        if (memcmp(cmdack, buf, 2)) {
            if (!memcmp(cmdnak, buf, 3))
                printf("cmd %x NAK %x\n", cmd[1], buf[4]);
            else
                printf("cmd %x badack %x %x %x %x\n", cmd[1], buf[0], buf[1], buf[2], buf[3]);
            continue;
        }
        if (buf[2] == cmd[1])
            return 0;
        printf("cmd %x misack\n", cmd[1]);
    }
    return 1;
}

main(int argc, char *argv[])
{
    unsigned char buf[520];
    unsigned long xsize, size;
    unsigned i;
    unsigned len;
    unsigned cks;
    unsigned maxpkt;
    unsigned pktnum;
    unsigned char bigbuf[256000], *bp;
    int outfd;

    outfd = open("cam.jpg", O_RDWR | O_CREAT, 0644);
    if( outfd < 0 )
        return -11;
    serfd = open("/dev/ttyUSB0", O_RDWR);
    if (serfd < 0)
        return -10;
    if ((tcgetattr(serfd, &tio)) == -1)
        return -1;
    cfmakeraw(&tio);

    for (;;) {
        cfsetspeed(&tio, B115200);
        if ((tcsetattr(serfd, TCSAFLUSH, &tio)) == -1)
            return -1;

        maxpkt = 300;
        printf("start\n");
        memset( &cmdack[2], 0, 4 );
        while (maxpkt--) {
            write(serfd, cmdsync, 6);
            if (!seravail(10000))
                continue;
            usleep(10000);
            if (6 != read(serfd, buf, 6))
                return -5;
            if (memcmp(cmdack, buf, 3))
                continue;
            cmdack[3] = buf[3]; // may be needed
            usleep(10000);
            if (6 != read(serfd, buf, 6))
                continue;
            if (!memcmp(cmdsync, buf, 6))
                break;
        }
        if (!maxpkt)
            return -19;
        printf("synced\n");
        cmdack[2] = 0xd;
        write(serfd, cmdack, 6);

        cmdwack(cmdbaud);
        cfsetspeed(&tio, B921600);
        if ((tcsetattr(serfd, TCSAFLUSH, &tio)) == -1)
            return -1;

        cmdwack(cmdjpeg);
        cmdwack(cmdp512);
        sleep(2); // to adjust for lighting
        for (;;) {
            usleep(1000); // small wait requires to reset
            cmdwack(cmdsnap);
            cmdwack(cmdreq);
            readlen(buf, 6);
            size = buf[5];
            size <<= 16;
            size |= buf[4] << 8;
            size |= buf[3];
            maxpkt = size / 506;
            xsize = 0;
            pktnum = 0;
            cmdack[2] = cmdack[3] = 0;
            bp = bigbuf;
            while (pktnum <= maxpkt && xsize < size) {
                cmdack[4] = pktnum;
                cmdack[5] = pktnum >> 8;
                write(serfd, cmdack, 6);
                readlen(buf, 4);
                //if (buf[0] == 0xaa && buf[1] == 0x0f) break;
                //if (buf[0] != cmdack[4] || buf[1] != cmdack[5]) break;
                len = buf[3] << 8;
                len |= buf[2];
                //if (len > 506) break;
                xsize += len;
                cks = buf[0] + buf[1] + buf[2] + buf[3];

                readlen(buf, len);
                for (i = 0; i < len; i++)
                    cks += buf[i];
                memcpy(bp, buf, len);
                bp += len;
                readlen(buf, 2);
                if ((cks & 0xff) != buf[0]) break;
                ++pktnum;
            }
            cmdack[4] = cmdack[5] = 0xf0;
            write(serfd, cmdack, 6);
            if (size != xsize) {
                printf("sz: %d xsz %d\n", size, xsize);
                write(serfd, cmdrst, 6);
                break;
            }
            printf("=%d\n", size);
            write(outfd, bigbuf, size);
            ftruncate(outfd, size);
            lseek(outfd, 0, SEEK_SET);
        }
        sleep(15);
    }
}

FATmel32 bootstrapping

2010-01-19T12:49:00.000-08:00

Proof of concept

Booter is a proof of concept. If you have a normally formatted SDHC card (have windows erase and create 1 partition with FAT32), and have a file named ATMELOAD.BIN, it will send it out the serial port at 57600 baud from an OpenLog.

The base code is just under 2K, so it could probably do read and flash (LPM/compare/Erase/SPM) if different in the given space. With main (and the single multiply from the library, interrupt vectors and other stuff) it is just over 2k.

This would allow people to reflash by just inserting the cards. This would be far easier when the system is connected for logging.

Barometric pressure, or doing Pascals in C. Plus magnetometer, LCDs

2010-01-18T20:21:00.000-08:00

I've been working on I2C. The latest is the VTI SCP-1000, D11 I2C version.

So I have a new archive with the test source (the display version just counts, but the others write to the UART at 57600 baud).

A more recent version is at github in the i2cperiph directory.

It also includes source for the newhaven 2x16 and 2x20 LCDs, the ADXL345 accelerometer and the HMC5843 magnetometer.

(updated to include accelerometer)

I used the breakout board DigiKey PN 551-1044-ND and one of those 0.6 inch wide component headers - the type you typically use to hold resistors or capacitors or things. I simply wired all the Vdd and Vss lines together.

SDA in yellow, SCL in green, 3.3v in red, and ground in black.

Pin 1 is at the bottom left of the baro. The top of the arduino pro has the Vcc and Ground pins. SDA and SCL come out the middle.

Strobe, smaller, cheaper, easier

2010-01-17T12:57:00.000-08:00

Earlier I posted my frozen fan pictures using an adapted engine timing light, as well as LED.

Harbor Freight model 03343 is actually easier to adapt, smaller and CHEAPER! than the earlier strobe.

It has only power, ground, and flash, the latter through a capacitor so any small pulse will trigger it.

Same brightness. $12 through the beginning of Feburary.

I need to update to "dial an RPM" version, now that I have more hardware

(I need to redo the setup and take another set of pics)

Upload text to the internet automatically via EyeFi

2010-01-16T16:40:00.000-08:00

There seems to be some limit - only files over 28K will be uploaded from the card, so you can't do small things. Fortunately each text comment can be just under 64k.

So, Just create a valid black 1x1 dot. There may be a more minimalist jpeg file, but this was the best off the cuff.

Split it where you put comment metadata.
Write out first part of file.
Read text (binary should work too!),
Encapsulate and write out one or more FF FE lh ll (lhll - 2 bytes of data) jpeg comment records.
Write out final part of file.

Use the DCF rules to write it to the EyeFi. Wait for it to upload to your favorite site (in my case picasa). Find the black squares which display as pixels and download. Reverse the FFFEdlen encapsulation and the data is intact!

#include 

unsigned char dotjpg0[] = {
0xff,0xd8,0xff,0xe0,0x00,0x10,0x4a,0x46,0x49,0x46,0x00,0x01,0x01,0x01,0x00,0x48,
0x00,0x48,0x00,0x00 };

unsigned char dotjpg9[] = {
0xff,0xdb,0x00,0x43,0x00,0xff,0xff,0xff,0xff,0xff,0xff,0xff
,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff
,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff
,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff
,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xdb,0x00,0x43,0x01,0xff,0xff
,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff
,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff
,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff
,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xc0
,0x00,0x11,0x08,0x00,0x01,0x00,0x01,0x03,0x01,0x22,0x00,0x02,0x11,0x01,0x03,0x11
,0x01,0xff,0xc4,0x00,0x15,0x00,0x01,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x03,0xff,0xc4,0x00,0x14,0x10,0x01,0x00,0x00
,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xff,0xc4
,0x00,0x14,0x01,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
,0x00,0x00,0x00,0x00,0xff,0xc4,0x00,0x14,0x11,0x01,0x00,0x00,0x00,0x00,0x00,0x00
,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xff,0xda,0x00,0x0c,0x03,0x01
,0x00,0x02,0x11,0x03,0x11,0x00,0x3f,0x00,0x98,0x00,0xff,0xd9 };

unsigned char textbuf[65536] = { 0xff, 0xfe };

main() {
    int len;
    fwrite(dotjpg0,1,sizeof(dotjpg0),stdout);

    for(;;) {
        len = fread(&textbuf[4],1,65532,stdin); 
        if( len <= 0 )
            break;
        len += 2;
        textbuf[2] = len >> 8;
        textbuf[3] = len;
        fwrite(textbuf,len+2,1,stdout);
    }
    fwrite(dotjpg9,1,sizeof(dotjpg9),stdout);
}

-lF@2^5 0.3a

2010-01-16T09:35:00.000-08:00

fat32 library 0.3a, with high-performance SDHC.

Still have things on the TODO. SDHC runs near the maximum (OpenLog has an 8MHz SPI clock, and I'm transferring just below that). Uart is now interrupt driven. Should work at 115200 baud worst case (allocating and linking a new cluster when needed WRWRW pattern). I noticed my class 2 were busy a lot longer than class 6.

sdhc.o is bigger. 1. I have found other samples and specs so it is a more accurate implementation of the spec. 2. I added a "get number of sectors" function which can be used. 3. The superfast read/write block add a little.

I'm still deciding if this might work better as a library. I need to split the busy-while-write or otherwise handle the case since it is now much larger than the actual transfer of data.

Also the read access time - things might be faster if I did multi-block, but for now I will leave it. It isn't that bad.

Meanwhile I have on order a jpeg trigger and camera from SparkFun. I plan on getting the camera up to 921400 baud, and to use my lib to store onto my EyeFi. DealExtreme has an adapter.

SDHC at top speed, SPI, optimization tutorial

2010-01-16T00:03:00.000-08:00

I wanted to speed things up.  SPI is set to f/2 on a 16MHz m328p, so
it generates an 8MHz SPI clock.

I didn't bother with the wait-for-whatever since if it takes
200 mS to access, I might change 202 mS to 201.

But a scope showed block transfers having 8 clocks at 8MHz, with huge
gaps, taking over a millisecond just for the send or receive.  I could
do a lot better - the time between SPI transfers should be only a few
clocks if not zero.

Here is the original receive routine:

static void recvspiblock(u16 len)
{
    u8 *buf = filesectbuf;
    while (len--) {
        SPDR = 0xff;
        while (!(SPSR & 0x80));
        SPSR &= 0x7f;
        *buf++ = SPDR;
    }
}

The problem is mostly with:

        while (!(SPSR & 0x80));
        SPSR &= 0x7f;

To translate,
   Loop:
        Initiate Transfer
   Loop1:
        Read the status register
        (if it becomes ready right here we will need an extra loop)
        Check the status bit
        If the status bit was not set in the read, go to Loop1.
        Reread the status register (need assembler or a smarter compiler)
        mask off the interrupt bit
        Write back the Status Register

Note that we can start the next transfer as early as a successful read
with the bit set, but it takes time to determine it.  Also we know how
many cycles it will take (within a few).  So why are we doing all the
housekeeping including the copy to buffer and the end check before
starting the next transfer.

The best case is:

    Initiate Transfer
    Loop:
        tick until SPI must be done (bit or no bit)
        Initiate Transfer
        do housekeeping
        go to Loop.

This way, as soon as it is ready, we initiate a new cycle.  We have to
protect the edge cases - pump priming and shutdown.  The current
version looks like:

static void recvspiblock(u16 len)
{
    u8 *buf = filesectbuf;
    if( !len )
        return;
    SPDR = 0xff;
    while(--len) {
        asm( "nop" ); // 9 nop == 9 cycles
        asm( "nop" );
        asm( "nop" );
        asm( "nop" );
        asm( "nop" );
        asm( "nop" );
        asm( "nop" );
        asm( "nop" );
        asm( "nop" );
        SPDR = 0xff;
        *buf++ = SPDR; // double buffered
    }
    while (!(SPSR & 0x80));
    SPSR &= 0x7f;
    *buf = SPDR;
}

It works. and is much faster.  The housekeeping is done between
triggers.

Using the -s to generate the assembly shows the instructions so you
can count the cycles.

recvspiblock:
 movw r20,r24
 lds r22,filesectbuf
 lds r23,(filesectbuf)+1
 sbiw r24,0
 breq .L10
//prime pump
 ldi r24,lo8(-1)
 out SPDR,r24            1
 movw r18,r20            1
 movw r30,r22            1
 ldi r25,lo8(-1)         1
 rjmp .L7                2
//loop
.L8:
        .rept 9
 nop                     1x9
        .endr
 out SPDR,r25            1
 in r24,SPDR             1
 st Z+,r24               2
.L7:
 subi r18,lo8(-(-1))     1
 sbci r19,hi8(-(-1))     1
 brne .L8                2 (taken)
//shutdown
 movw r30,r20
 sbiw r30,1
 add r30,r22
 adc r31,r23
// original wait code here
.L9:
 in __tmp_reg__,SPSR
 sbrs __tmp_reg__,7
 rjmp .L9

 in r24,SPSR
 andi r24,lo8(127)
 out SPSR,r24
 in r24,SPDR
 st Z,r24
 ret

17 clocks for the central transfer loop.  16 would be the minimum, but
it seems to need one extra to sync properly, i.e. it is ready after 16
cycles, not on the 16th cycle.  For writes, it seems to take 1 more,
or I'm undercounting the CPU cycles.

This doesn't fix everything.  Particularly, the access time on the
reads and busy time on the writes (which I should add a flag to say
the write is done and buffer is available, or just do the busy check
as part of startup - I had trouble reading too soon after writing if I
don't wait).

A newer version of my fat32lib will be posted shortly.  Includes interrupt
driven UART, and some tweaks.

fat32lib 0.1, zap your card edition.

2010-01-10T07:33:00.000-08:00

This is the first alpha, and does not include source except for the main.c menued demo.

fat32lib-0.1b.zip (Update, filename editing, linux test version)

Runs on SparklFun's openlog and any 3.3V arduino with the SDHC attached to the SPI pins.

FAT32 ONLY, no FAT16 support, but will work on any card, e.g. a 512 byte SD card. (I have only one which maybe should be FAT16 - a legacy spinrite and general fixup DOS boot USB with uSDHC - under 1024 cylinders for really old bioses). Anything current typically uses FAT16. No long filename support (see below).

I'm still refactoring, which means in practice that half the lines can be changed, moved, removed, or replaced, and need to clean up some things (like using unsigned long instead of u32). The library is fairly machine agnostic and I test using linux and ordinary 512 byte reads and writes to /dev/sdX.

Right now it takes just over 8k for FAT32 with everything included, just over 1k for the SD/SDHC driver. Just under 16K out the door with main.c and libraries (the library and driver don't need any external libraries).

A flashable hex file is included in the zip. Also the library, driver, main.c, the headers and a Makefile are included which is a menued demo program similar to what OpenLog does, but no eeprom, and fixed at 57600 baud. A space or any other unrecognized character brings up a menu. It follows the API in fat32.h. For logging, N return W will open a sequential log and start sending data into it. control-z gets back to command, E and F sync the buffer and directory.

Fairly feature complete - extended partitions are disabled in this build (350 bytes). And I interlock not writing when the "current file" is a directory and not deleting directories (until I can add a directory empty check). But it is still dangerous.

I've tried to minimize extra reads and writes, but there are still a few places where it could be improved (cluster linking)

Long filenames are not supported because they can straddle three sectors, have to be read backward, and need to work with unicode. This results in ugly buffer read-writing or shuffling and would need a huge string match buffer. For embedded applications, reading and writing 8.3 DOS names should suffice.

Version 0.1b includes my high-performance SD driver source. Verified on everything from 512Mb to 16Gb, the Eye-Fi, HC and normal, version 1 and 2. I went through the spec and tried to do the initialization properly. The transfer loops should optimize well and run fast (copyright, use at your own risk, but free for educational use, post comment for other terms).

a little FAT(32), new displays...

2010-01-09T22:35:00.000-08:00

Some more displays 3.3v, mostly I2C from Newhaven on the left.

Openlog on the right, with an EyeFi and adapter - it signs on, but I need a "Pro" version to upload non-image files. And I don't have the jpeg trigger camera logger version from sparkfun to try.

Meanwhile, I have written a fairly complete FAT32 (sans long filenames) implementation which fits into just over 8K. And just over 1K for a tuned SDHC driver. The main OpenLog source doesn't work with SDHC and FAT32 - they are linked in the current source, at least if you don't want to overwrite your bootloader. If you enable SDHC, it changes the data size for offsets to 8 bytes, so all kinds of ordinary calculations double in size, even though SDHCs can only transfer in 512 byte units.

This will allow me to record the information coming from the devices even if bluetooth isn't uploading it.

The I2C Display, Pics, problems.

2010-01-01T09:11:00.000-08:00

It should be displaying the magnetometer on the bottom line, but you will note it is moved back (the board with the big capacitor).

For now it displays the output of temperature, and accelerometer (500=no gs, 0-1000) x,y,z.

Adding devices adds capacitance. The magnetometer seems to be the worst. The problem is that the display has a very low current sink capability so if I use lower resistance pullups, the ACK will not be seen since it will be at 1.2v or even higher instead of right near the 0v floor. I can only go down to about 4.7k.

linux + ftdi + arduino = no auto reset - same with openlog

2009-12-31T06:29:00.000-08:00

None of my FTDI breakouts can actually reset an arduino. Nor the one built-in on the arduino mega.

It turns out that avrdude (or at least the version I have) doesn't toggle the line, and to do so may require some effort on the low-level software front (there is a libftdi which corks).

I was able to verify the sparkfun openlog when I manually reset it (I'm still bothered that ISP didn't work, but I will need to explore that further). It was easy since the SD card holder is grounded and right under the reset pin, so putting a wire through the hole would make contact and reset.

Newhaven 3.3v display working - Arduino and ATtiny

2009-12-30T20:29:00.000-08:00

Update: ATtiny85 Works!

One thing which is not clear (except with a scope) is that it does not have good current drive capability. Some I2C busses have 3.3K. One of the other sparkfun modules had 1K pullups on SDA and SCL! I needed to remove them and have 12Ks and things worked (though you could see the ACK pulse was noticeably above ground and the clock pulses had a rise time which made it look like sawteeth instead of the sharp square waves).

I wanted to do this since I can then use another port to time J1850 pulses and print out the data on the display, all with 3.3v, no crystal, and few components.

For now, with some glitches, I have it displaying the temp, and the XYZ from both the accelerometer and magnetometer on the breadboard. Pics to follow.

Main post is at:

http://www.newhavendisplay.com/forum/viewtopic.php?f=9&t=86&p=349#p349

I don't know what I really needed to get this working. Much hacking until the display appeared (though thanks to Curt at Newhaven who suggested trying different contrast settings - the max works much better). I have to integrate this with my other code, but now I have a way to quickly display info from other things attached (including other I2C devices). It is working at 400kHz.

There is one subtlety where you need to send the address THEN A CONTROL BYTE then the data byte or bytes. This is in the controller datasheet, but hard to understand, and the control bytes specifies whether you are doing control or data, and if there are more control/data pairs or if it is the last control followed by just data.

I'm getting a few more - including an 8x20 (that I might have a connector for - 2m instead of 1.5), and a 100x160 character display. All use 3.3v. Also a larger one with bytewide bus.

They have lots of neat stuff there, so check them out. I found them via digikey, but they sell direct and the prices are very reasonable and they have boards which make prototype connection easy, which is usually the hardest part.

http://www.newhavendisplay.com/

I don't have the ATtiny85 talking to it yet, but having one working version should make it easier.

I2C - there's the spec, then there's hardware

2009-12-30T08:50:00.000-08:00

I was having problems with the I2C using my ATtiny85 USI routine I have posted here.

The HMC5843 (yes, the one that I needed to add the low ESR cap to) would only return 1 byte of data when reading, then a series of 0xff. It acted like I was NAKing it but it was a good ACK as far as the specs were concerned (on the scope).

It turned out I needed two or three NOPs right at the top of the PulseSCL macro to insure setup time for SDA. It also doesn't work to just put the delay just before the ACK in the read routine.

I've been having similar problems with some I2C displays from Newhaven Display. They are nice in that they only need a single 3.3v supply, and run I2C. They need a few caps since they have an on-device voltage booster, but it ends up being only 4 connections. On an arduino, I managed to get a block and underline cursor, but no text so far. I was getting nothing with the ATtiny, but I will need to try it with this fixed code.

latest minigpsd tarball

2009-12-29T11:03:00.000-08:00

Yahoo, or my browser (firefox with various blocks for security like noscript, flashblock, nodirect) was having problems, but I figured out how to get the old FTP to work.

http://www.zdez.org/minigpsd_0.31h1.tar.gz

Busy... Magnetometer, openlog, minigpsd.

2009-12-29T09:08:00.000-08:00

There are a few updates to minigpsd that should appear at www.zdez.org when I can get them to upload. Mainly gpsgate was disabled if logging couldn't work (e.g. I didn't have a card in the n810). Also I managed to get a lock and then turn off the external GPS stream (j1850 worked), and found the internal would not override the external if that happened. That has been fixed too.

Meanwhile I got the HMC5843 breakout and openlog from sparkfun. Frustration.

The HMC5843 - as per the discussion - REQUIRES YOU TO ADD AN EXTERNAL LOW-ESR CAPACITOR. I used a 47uF electrolytic.

It is not that it doesn't work at all, it does strange things - resetting, returning 0xff instead of the correct bytes, etc. With the external cap, it seems to be working 100% (there are a few hiccups, but they are probably on the master end).

The openlog won't reflash, but they really don't say how to do it. It has some kind of arduino/stk500 style bootloader, which would help if it just worked. Maybe the baud rate is off. Maybe the version. Maybe it needs to be manually reset if you use a 3.3v FTDI. But they don't say. Worse, the ISP pins are broken out and I can't get it to be recognized that way either.

The broken FTDI driver in Ubuntu Karmic

2009-12-06T08:59:00.000-08:00

I was wondering why I was having such problems doing "cat /dev/ttyUSB0".

Turns out to be a known problem - patches submitted to the kernel after the ubuntu freeze.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/460857

The suggestions involved a kernel rebuild, however it is just one driver from two files.

So I found some other drivers and figured out how they did their quick Makefiles.

Putting the following makefile (remember the indents must be tabs, not spaces) with the ftdi_sio.* files will allow you to build the module with just "make".


KDIR:=/lib/modules/$(shell uname -r)/build

EXTRA_CFLAGS += -I$(KDIR)/drivers/usb/serial -I/usr/src/linux-headers-$(shell uname -r)/include

obj-m:=ftdi_sio.o

default:
 $(MAKE) -C $(KDIR) $(EXTRA_CFLAGS) SUBDIRS=$(PWD) modules
clean:
 $(RM) *.mod.c *.o *.ko .*.cmd Module.symvers Module.markers modules.order

Toolbox: 12V LEDs

2009-12-03T18:39:00.000-08:00

These have an internal resistor, but will glow even at lower voltages (3.3-5). So they are hard to kill and won't kill your target, but easy to hook to a port or to see if there is voltage. $2.63/10 as of this writing

The digikey part numbers are (red,yellow,green):
67-1067-ND LED 3MM 12V SHORT LENS RED DIFF 12V
67-1079-ND
67-1061-ND

Double Dragon

2009-12-01T15:25:00.000-08:00

My new dragon is still working well. I have the 40 pin ZIF socket, so I had the HVSP going to the bottom 8 pins (pin 1). I just added the debugwire to the other end - and it works (if I use HVSP to program DWEN).

Three wires, but can't change the fuses. But the nice thing is I end up with a 3 wire solution - two are power so have to be there anyway.

Now to try debugging...

2megabaud improved

2009-11-28T12:51:00.000-08:00

A larger but less intrusive (leaves the other port bits alone) 2 megabaud.

The 0xfe and 0x01 can be set to which port bit to use

The final ror is redundant, if you want to do .rept8 then copy the first 4 instructions or just set the stop bit at the right time. The ret takes 4 cycles so the stop bit will be more than long enough.


 .file "sendchar.S"
PORTB = 0x18
 .text
        .global sendchar
 .type sendchar, @function
sendchar:
        in r23,PORTB
        andi r23,0xfe // Zeroing mask - clear port bit
        out PORTB,r23 // start bit
        sec           // for stop bit
        .rept 9
        mov r22,r23
        sbrc r24,0
        ori r22,0x01 // Marking mask - set port bit
        out PORTB,r22
        ror r24
        .endr
        ret
 .size sendchar, .-sendchar

Some assembly required, or at least good practice

2009-11-24T19:38:00.000-08:00

I've added an i2c temp sensor which I will add later.

Tweaked so that every SCL pulse is uniform (1.4us low, 0.9 high, except for stop which is 1.5 low).

What do I look for in a good assembly program?

Comments should point to the key points.  For example, that the write loop needs to be split into the initial and main if you want speed over space.

This is the current version of usi2c.S which I tried to comment properly:

;;; copyright 2009, all rights reserved. released under the terms of the GNU
;;; general public license V3.  See www.gnu.org for details.  For other terms,
;;; contact tz@execpc.com

;;; USI I2C for Atmel 25 and larger chips.

;;; Features: Uniform frequency (9 cycles high, 14 cycles low) for SCK except
;;; for STOP condition where it is 15 cycles low.

;;; Input: Pointer to unsigned character buffer (in R24:25).
;;; Returns any read data into same buffer.
;;; Buffer format: One or more of: { LEN ADDR-RW BYTES }, followed by zero
;;; LEN is the number of bytes for the transfer, the address-r/w plus any
;;; bytes read or written.  A start condition is generated, the address is
;;; sent, then bytes are read or written.  If there is another transfer, a
;;; repeated start is generated, and the second transfer occurs.  Otherwise
;;; a stop condition is generated.

;;; The USI on the ATtinyx5 uses PB0 and PB2 which are properly set upon start.

;;; Constants
        
ZERO = 1
PORTB = 0x18
DDRB = 0x17
PINB = 0x16
USIDR = 0x0f
USISR = 0x0e
USICR = 0x0d

;;; Macros

;;; Waitup - pause until the SCL line is high. Required for normal clocking and STOP
        .macro  WaitUp
1:      sbis PINB,2
        rjmp 1b
        .endm

;;; PulseSCL - generate the high-time for SCL during data bit transfers.  Start and
;;; Stop are handled separately.  Timing adjusted for minimum of 6 cycles, but normal
;;; pullups will do 9 cycles since the test to wait for the line to actually go high
;;; is just after the line is released so reads as 0 at the instant.
        
;;; r21 contains 43 (0x2b)
        .macro PulseSCL
        out USICR,r21           ;Toggle SCL High
        WaitUp
        lpm                     ;3 cycle delay
        out USICR,r21           ;Toggle SCL Low
        .endm

;;; XFER8 - transfer 8 data bits using USISR
        
;;; r22 has 0xf0 for count
        .macro Xfer8        
        out USISR,r22
8:      PulseSCL                ;SCL High pulse
        sbic USISR,6            ;Exit xfer8 on interrupt
        rjmp 9f                 ; jump to exit
        rcall .dly7             ; 7 cycle delay
        rjmp 6f                 ; 2 cycle delay - +1 to make it the uniform 14.
6:      rjmp 8b                 ; loop for next bit
9:                              ;3 cycles after SCL low
        .endm

;;; Function USIxfer Body.
        .text
.global USIxfer
        .type   USIxfer, @function
USIxfer:
        mov r26,r24             ;Pointer to transaction to X
;;; r19 will hold PORTB status for efficiency.  This and later sections of the
;;; code will need to be changed to do a read-modify-write with interrupts
;;; disabled if an interrupt can alter PORTB elsewhere.  Instead of redoing RMW
;;; r19 will be written to PORTB.to set the pins high
        in r19,PORTB            ;alt: sbi PORTB,0...2
        ori r19,lo8(5)
        out PORTB,r19
;;; set the SDA/SCL to input.
        in r24,DDRB
        ori r24,lo8(5)
        out DDRB,r24
;;; Setup the USI registers and local values used later
        ldi r23,lo8(-1)
        out USIDR,r23
        ldi r21,lo8(42)
        out USICR,r21           ;enable USI
        inc r21                 ;change into toggle command
        ldi r22,lo8(-16)
        out USISR,r22
        rjmp .MainBot

;;; X (r26/27) - pointer to message buffer
;;; r25 - current msg length left
;;; r24 scratchpad
;;; r23 const 0xff
;;; r22 const 0xf0 for 8 bits
;;; r21 const 0x2b to toggle SCL
;;; r20 - read/write flasg (break write loop after 1)
;;; r19 - incoming both high PORTB image
.MainTop:
        out PORTB,r19           ;Set both SDA and SCL high
.sdaupwait:
        sbis PINB,2
        rjmp .sdaupwait         ;wait until SDA is actually high (periph wait)
        ld r20,X                ;save message first byte for read/write bit
        cbi PORTB,0             ;set SDA low for start condition
        lpm                     ;delay 3 cycles
        rjmp 5f                 ;delay 2 cycles
5:      
        cbi PORTB,2             ;*** set SCL Low
        out USIDR,ZERO          ;this prevents a cosmetic glitch on the SDA line
        sbi PORTB,0             ;set SDA high so USI can use it
        lpm                     ;delay 3 cycles
        nop                     ;delay 1 for uniform 14 cycle lowtime
        rjmp .WriteTop          ;Enter write loop
;;; If the address or any byte is NAKed, the current transaction will end.
.nacked:
        add r26,r25             ;skip bytes to next length
        adc r27,ZERO            ; set remaining length to zero
        rjmp .PastRead          ; end this transaction
;;; WRITE LOOP
.WriteTop:
        ld r24,X+               ;Get (next) message byte
        out USIDR,r24           ;send to USI
        Xfer8                   ; send it
        cbi DDRB,0              ;reverse SDA direction
        rcall .dly7             ;delay 7 cycles
        nop                     ;one more cycle for 14 uniform
        PulseSCL                ;Get the Ack or Nak - SCL high pulse
        dec r25                 ;len--
        breq .PastRead          ; no more chars, end
;;; SDA back to out, but if we switch to read we clear it?  Maybe optimize
        sbi DDRB,0              ;return to output
        sbic USIDR,0            ;Did we get a NAK?
        rjmp .nacked            ; yes, skip rest of this transaction
;;; This causes the longest nomal path at 14 cycles.
;;; For faster, e.g. at 8Mhz RC, it would be faster to do a split out address write,
;;; then jump to the write or read loop instead of checking this bit each loop
        sbrs r20,0              ;check read/write bit
        rjmp .WriteTop          ;Back to top
        nop                     ;delay for uniform 14
;;; Read Loop
.ReadTop:
        cbi DDRB,0              ;switch to input on SDA
        nop                     ;delay for uniform 14
        Xfer8                   ; get data byte
        nop                     ;delay for uniform 14
        in r24,USIDR            ;read data byte
        st X+,r24               ;save to buffer
        out USIDR,r23           ;set output high (-1) in case of NAK
        sbi DDRB,0              ;set SDA to output
        dec r25                 ;len--
        breq .doNAK             ;NAK of last byte - note optimize out tst r25 lower
        out USIDR,ZERO          ;more data, Ack - drive SDA low
.doNAK:
        PulseSCL                ;Pulse the SCL line high to send the (n)ack
        tst r25                 ;retest length
        breq .PastRead          ;exit loop
        lpm                     ;delay 3
        rjmp 9f                 ;delay 2
9:      rjmp .ReadTop           ;continue read at next byte

.PastRead:                      ;Read (or write) complete
        out USIDR,r23           ;set output high if USI active
        sbi DDRB,0              ;set SDA to output
.MainBot:
        ld r25,X+               ;get length of (next) transaction
        tst r25                 ;check for 0/end
        breq .doStop            ;skip to stop conditon
        nop                     ;delay for uniform 14
        rjmp .MainTop           ;do next transaction
.doStop:
        cbi PORTB,0             ;clear SDA for STOP
        sbi PORTB,2             ;bring SCL high
        WaitUp                  ;wait unit it really does
        lpm                     ;delay 3 cycles
        sbi PORTB,0             ;Stop: Bring SDA high after 0.6
;;;Need to hold SDA for 13 before going low again - ret - call - setup will be longer
.dly7:  ret                     ;call to ret is 7 cycles - space efficient delay
        .size   USIxfer, .-USIxfer

I2C Master, mastered.

2009-11-23T21:42:00.000-08:00

Frustration sometimes is the mother of production. While I wait for my new Dragon (which I need to be more careful with)...

http://www.zdez.org/tinyacc2.tgz - source is here.

I don't have the COPYING file, but it is GPLv3.

This reads the accelerometer, puts out 1 volt for flat, with more or less depending on tilt, and uses the 9555 to drive a LCD to show 100 for flat, lower or greater depending on tilt. Not clean given the noise on the breadboard but it works.

I've made the i2c driver a bit faster and more consistent - it still needs a few adjustments, but the code paths are nearly identically long giving a very clean wave on a scope.

There is also a reason to split or adapt the driver - things like the port and DAC will just sit there and successive writes can be done without the addressing or register selection. A start - continue - stop version might be next.

But I also have got to get back to the V1 LED stuff.

Smoking Dragon, fluxed up beyond all operation.

2009-11-23T13:39:00.000-08:00

I was out and got some soldering and electronic supplies, including a bottle of flux.

I spilled a small but more than annoying amount when the bottle tipped. Right on the Dragon.

After a very thorough cleaning (flux is hard to remove in quantity), it worked for several hours, but finally the power supply chip has lost its magic smoke, so another Dragon is on order.

In the meanwhile, my I2C has added the NXP PCA9555 and an LCD which was working while I'm tweaking the code paths to have better timing. Back to the clips and the rest of the chips I didn't change the reset fuse on...

The (AVR) Dragon, tamed.

2009-11-21T14:35:00.000-08:00

The Dragon is working. A few things I needed to do:

Solder the headers for HVSP mode, then for the 40 pin passthrough for the prototyping area.

I added a plain socket and a ZIF socket for the narrow devices - 8 to 28 pin - the bottom socket is so I can add the wider 40 pin if I ever need it.

Then it has to be wired.

http://courses.cit.cornell.edu/ee476/AtmelStuff/dragon.pdf (ATtiny2/4/85 is on page 22).

It is actually very clear, the other page which has basics: http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/AVRDragon_HVSP_Description.htm but DOES NOT MENTION YOU MUST RUN VCC FROM THE POWER TO ISP HEADER ("A" in the PDF).

At the top of ~/avrduderc, I needed:

default_programmer = "dragon_hvsp";
default_parallel = "usb";

(and removed the stuff from the Makefile(s) - these are just the parameters to -c and -p ).

Update: Wonderful! I wish I knew about it earlier.

It took a few tries, but I have an MCP4725 (i2c D/A) to a meter going offscreen working - read the ADXL345, write the MCP4725.

Instead of using the clip (to the upper ATtiny85 - with the ceramic resonator), I just popped another t85 into the dragon, did HVSP, and swapped.

I2C in assembly

2009-11-20T19:42:00.001-08:00

Closing in. Still at 10Mhz. The I2C section is now in assembler.

Right now the paths are 15 clocks low, 9 high.

The SCL pulse should be 6 clocks, but shows 9. What is happening is I immediately check if the line went up, but here is enough capacitance that it takes longer than the time between the grounding driver is turned off and when the bit is checked the first time for it to be detected as high, so instead of 2 cycles, it takes 5 (rjmp back to the test again), then the 3 delay between.

The other paths are optimized, but the longest one is on reading between the 8th bit and the pulse for the ACK/NAK since it has to store the byte, decrement the length, and use it to determine whether to ack or nak. 16 clocks.

Looping back to the top and doing a restart of course takes longer.

9+16 = 25 = 400kHz. The other paths are 15, so I could add a NOP in places.

I've moved the common things into macros.

The updated archive is at http://www.zdez.org/tinyacc.tgz replacing the others.

I still need to do an 8Mhz (non crystal version), add some more I2C devices, and do more substituting lots of consecutive NOPs with something more space efficient. But the whole thing is around 600 bytes. The I2C driver is 246 bytes.

Enter the (AVR) Dragon

2009-11-19T09:39:00.001-08:00

I've been wondering how hard it would be to use the high voltage serial programming mode. On most AVRs there are lots of IO ports so it doesn't really matter. But on the ATtinyX5 series, there are 6 port pins and one is reset, but reset is needed by the ordinary ISP. And is shared by the debugwire. So if you set this pin, you can't program it that way.

But the HVSP mode is supported by the AVR Dragon programmer (I couldn't find any other programmer which did this I could just buy).

By pulling the reset pin up to 12v, (with some other sequencing) it enters this special mode and otherwise just works. And is supported by avrdude.

So I should be able to have one more pin (which I need for another project). If nothing else, to do serial input as well as output (which needs the crystal/resonator pins) and I2C.

tiny does ADXL, update

2009-11-18T16:39:00.000-08:00

The code is at http://www.zdez.org/tinyacc.tgz and runs full speed sending out binary (5aa5, then X,Y,Z as bigendian 16 bit words).

GPLv3, that which isn't scenes a faire.

The updated version merges the message and length buffers. So you have a length followed by length message bytes (first is always written, the rest are read or written depending on the LSBit of the first message byte). Length=0 ends things. See test.c for an example.

Start / msg / reStart / msg... / Stop is like I described in the previous post.

Now I need to see about an AVR Dragon so I can use high voltage serial programming so I can use the reset line as a port pin...

(and figure out how to actually program the TSSOP8 verson).

Rant: the great disconnect

2009-11-17T17:47:00.000-08:00

Why are all connectors either huge or cumbersome?

There are fine-pitch connectors for LCDs or touch screens which are hard to handle.

Or 0.1 inch center which are larger than the ATtiny45XU20 (TSSOP8). The 0.5 inch connectors which are similar are very tall.

For Arduino Pros and breakout boards (without posts) I ended up getting Components Corp TP-105-40-XX from Bisco - breakaway 0.1 test points that act as a fairly low profile connector/clip/plug. Think banana plug but just two wires that insert and hold and insure contact.

But I'm working on really small components. To program the above ATtiny, I don't want to leave the ADXL345 attached (5v v. 3v), but how to connect it? Even something I could insert into a microsocket. Either it doesn't exist or is buried where I can't find it.

Tiny does the ADXL345 at top speed.

2009-11-17T17:28:00.000-08:00

The bad news: the optimizer in avr-gcc is overzealous.

The good news: Not so much that I couldn't get my current project working.

I took the megabaud driver, and merged it with an updated "fixed" and optimized (-Os) I2C driver. The result? 3.2kHz+ sampling rate in 3 axes on the ADXL345.

I am running somewhat over 400kHz (The I2C spec says it has to remain high for 0.6 microseconds, low for 1.3, but overall 2.5. What to do with the remaining 0.6? I didn't quite use it all).

I will post something shortly, but the core driver works with -Os, but the main program doesn't - it doesn't reset the DDR/PORT register to do an input/pullup at the end so I get break/noise.

How it works:

I merged everything so that I send in a messages buffer and lengths buffer. The latter is the length of each message segment (separated by what becomes a repeated start instead of a stop then start). The ending length is zero. Reads set the message bytes, Writes read from the message bytes.

The start condition is sent, then it enters the write loop - a do {} while since even reads need to send an address. It exits if it isn't writing, or it has sent LEN bytes. That is followed by the read loop, so if there are bytes left, it does the direction switch and loops reading, NAKing the final received byte to end the transfer. If the next length is zero, it sends a stop. Otherwise it does a repeated start.

So the initial setup commands are sent as a block. Then the Read FIFO number of samples ( send regno, read val, 4 bytes) as a block. Then loop reading groups of 6 bytes (send regno, read val, 9 bytes), followed by sending them out PB1 using my 2Mbaud routine. The lines are pulled up by external resistors so I just set DDR to input so it doesn't see the shifting bits. Blocks are read until the FIFO count is exhausted, where it reads the next FIFO value.

When I clean it up and take some pictures I'll post them.

I'm using my pomona clip to program them using a second resonator on the board. I should try it on the clip attachment, so it wouldn't matter what the fuses are.

But I really need to figure out high voltage serial programming (or find something that will do it). That way I can use the reset pin - which is 17% of the IO!

Cliq-ing, and a very tiny to accelerometer

2009-11-14T08:06:00.000-08:00

I haven't been posting because I got a Motorola Cliq (as part of a giveaway from my attending the Moto/Android Developers conference) and have been playing with it.

It appears to require a T-Mobile data service SIM (which I was able to borrow) to get the Blur part registered (and it won't let you do anything until that is done). Afterward, it can do everything via wifi. It won't recognize a T-mobile prepaid SIM for voice.

But it is a very nice device. I will be trying Ustream and/or Qik on my motorcycle this weekend. The only problem is there is no link (nor root, at least not yet), and it is Android 1.5/1.6, not 2.0 like the new Droid. (It has bluetooth, but only for things like handsfree).

Meanwhile, I found Digikey has the ATTiny45 in a TSSOP-8 package. A very tiny tiny. I'm already talking to the ADXL345 using my ATtiny85, so this will make a very small unit.

Getting I2C working was painful. There is at least one bug in Atmel's AVR311 appnote code, it is complex, and everything is #defined so it can use any port/pin for the various models of the processor. I rewrote it based on their code, though T2/T4 is hard coded for fast (400Hz).

http://www.zdez.org/tinyacc.tgz has the archive (GPL - needs a 10Mhz crystal for the 2Mbaud, uses the Atmel PB2/PB0 for I2C, with PB1 for the serial). It runs at just over 800Hz, mainly because I'm outputting hex codes.

Megabaud I/O

2009-11-06T21:10:00.000-08:00

I wanted to do PB5, but then programming requires high voltage mode, so I did PB0 for RxI for now (with PB1 for TxD). I need two pins for the crystal.

(Note: an earlier test showed it was sending at 135k bytes per second for output going into my FTDI breakout from sparkfun).

Sending 100000 'U' characters returned the following number of hex values:
17 40 @
886 50 P
1197 54 T
97900 55 U

2.1% error, for a 5 bit width. Could be better but still useful. Or it could be the breadboard. With ECC or just CRCs and retries it should work (though at the end I would need to jump back to the start after doing a store to autoinc).

Update in http://www.zdez.org/tinymegabaud.tgz

Kursed Karmic

2009-11-05T09:28:00.000-08:00

While I've been doing other things I've been upgrading my main active
backup USB image (a 16Gb micro SDHC card in USB and/or SD adapter)
from Ubuntu Jaunty to Karmic, as well as a few other computers.

As usual, the upgrade has been horrible. But Koalas tend to just stay
up in the trees and eat eucalyptis until they are high in another way
all the time. Which perhaps explains this release.

The upgrade/install annoyances:

1. When it doesn't like something - I had a bad sector on the media,
or some package was out of sync, or thinks it doesn't have enough
room, it will complain and exit instead of letting you retry EVEN
IF IT TAKES 20 MINUTES EACH TIME TO GET BACK TO WHERE IT STOPPED.

2. Someone at canonical please tell the people setting up the upgrade
that networks can go down and need to be retried. Halfway through
one upgrade the network died and left the system completely
unstable - half of the upgrades were there, but it couldn't go back
but it also couldn't complete (except manually, "apt-get
dist-upgrade" seemed to work). DOWNLOAD ALL THE PACKAGES AND THEN
DECLARE A POINT OF NO RETURN OR ALLOW A RESUME.

3. Even though I burn a CD or DVD, it insists on having network access
(perhaps because the universe/multiverse need to be upgraded).
This is stupid. I should be able to get past the first reboot
without having network access, and that should allow me to connect
if I choose, or there should be a way of creating multiverse
packaga DVDs.

4. After rebooting the first time into Karmic it is nice to know some
things never change. The first is the network deadlock. In order
to do some (restricted) hardware, it needs to download the drivers
from the internet. It can only detect such hardware on the system
it is running on and will not cache these. But if the network
ports are the devices needing the hardware, how can it ever come
up? Having various spare USB devices with suppored drivers helps,
but this is REALLY STUPID. To make it work all I have to do is
download the driver, but I don't have network access until I
download the driver. They need a cache installed from the CD by
default with all NETWORK hardware not installed by default. You
can also use the CD if you installed that way or burn one.

5. It is also not nice to see things don't change like the stupid
Gnome Network Manager that takes minutes to discover the AP I just
turned on and has sent out beacons so that iwlist scan shows it
immediately. Something which might make it slightly faster is
promised for "zippy zebra", but I suggested they add a button that
does what I have to do in 2 steps - disable then reenable wireless.

6. Including beta software is usually a mistake, and worse in
something like the boot manager. Unwelcome to grub2. Actually the
boot process works extremely well, but there is almost NO
documentation at any official site, there is a good set at another
place http://members.iinet.net/~herman546/p20.html covering all the
CLI commands, but it has gaps. But the worst thing is the support
utilities are badly broken. They have something which scans for
other operating systems on anything which might be attached and
adds them to the menu whether you want it to or not. With a
movable key this is a big problem. Also it is completely incapable
of finding DOS boots (like where I run spinrite). And it gets
confused with post boot v.s. bios enumeration, so it might be (hd1)
after boot, but (hd0) when it is active. The UUID stuff does work
and helps and would be wonderful if the rest of grub2 would find
and use it properly.

To get DOS:


# from the first partition on the first BIOS disk:
menuentry "DOS (on C:\)" {
        chainloader (hd0,1)+1
}
# use "blkid" to find the DOS partition and replace UUID-UUID
# with the actual value given
menuentry "DOS (via UUID)" {
        search --no-floppy --fs-uuid --set UUID-UUID
        chainloader +1
}

6. There needs to be a non-eye-candy setting somewhere. Right now I
have to neuter it at several places. I do want to see the console
messages, but even more don't want a multimedia extravaganza. A
graphic "starting X" that doesn't induce epilepsy would be ok.

7. Related, I usually set the finest fonts possible so I can edit
using consoles and/or see 50-100 lines of messages instead of 25.
It used to be vga=extended on the kernel command line (and
something in initrd to duplicate or at least not change back, then
the post-boot option). With a full graphic console I get higher
resolution, but with big fonts. console-tools / console-utilities
using Cyr_a8x8 gives me 160x100 on my older laptop, but the kernel
still boots in big VGA, and initrd isn't switching though has a lot
of junk which is there to do that.

8. And another switch which they don't document how to undo is
policykit-1. It kept asking me for authorization every time I
wanted to mount a disk. And the dialog box is supposed to do
something if I click on a link saying where/what is requiring the
authorization, but that is broken I found in /usr/share/polkit-1
there is an actions directory that has files with XML so changing
all the allow tags to "yes" gets rid of this, but this is also
broken and badly documented. Whatever is supposed to popup to let
me permanently change the settings from the dialog box is missing
and I have no way of guessing what it might be, existing things
don't work on these files, and there is no quick howto about using
alocal file. I finally found some manpages for policykit but not a
lot of detail on how it is used across the various bits in ubuntu -
like having a Python guidebook isn't helpful figuring out the
upgrader.

9. X has gotten 2x slower, at least in 3d fps (stellarium). I don't
know why since the drivers are open. Also the "don't zap" seems
not to be overridable (sometimes for run-aways or other hiccups it
is easier to do that than to logout). But I was able to override
for my larger frame-buffer size. xrandr seems to be in a package
(My netbook sometimes needs a bigger virtual screen). They need
some way of easily and manually (though GUI or utility, not "sudo
vim /etc/X11/xorg.conf" overriding X features.

10. tzdata-java and tzdata are out of sync preventing me from
installing java unless I downgrade (a really annoying manual
process since I have to find the old version, download it, and use
dpkg to install the older tzdata). Something is wrong in that the
dependencies go both ways and they shouldn't have updated/upgraded
tzdata without tzdata-java (and "held back" isn't a good mechanism
since it only works with things which are installed). This bit me
on Karmic but has been a problem since Gutsy where tzdata will get
ahead of the java version, and the dependency is marked as exact
instead of greater than or equal to.

11. I did install it new, but didn't want to repartition. The evil
partitioner will NOT indicate it will reformat swap space and/or use
that swap space - you need to select it and choose and any change
will NOT be visible. So if you get to the final screen, you have to
go back and restart the process. I have a bug report in - there is
no reason not to check the "format" box if they are going to format.
There might not be a mount point but they should say "(swap)" if it
is going to be used as swap.

ATtiny85 2 Megabaud Output only

2009-11-04T22:20:00.000-08:00

Updated! Cleaned up and now as a function.

At 3.3v I can only safely do 10Mhz, for which I have a ceramic resonator (and you need to set the fuses appropriately).

I also have a 3.3v FTDI breakout from sparkfun so I can connect ground, 3.3v, and RXI.

At 2 megabaud, a character takes 5 microseconds, and interrupts can often be disabled for this long to prevent hiccups. High throughput is also nice, but mainly because the ATTiny doesn't have a built-in UART, I don't want to bit-bang or eat a timer, or have to worry about the latency or load. I can blip out a few bytes when I need to.

http://www.zdez.org/tinymegabaud.tgz

Since I'm not sure about GCC/avr/as syntax, I cheated and wrote a quick C program and edited the assembly.

It will be incorporated into a few projects shortly, but some might find the proof of concept useful.

I don't disable interrupts but that would need to be done if interrupts are used in the larger project

(one thing is I now can sample other bits at a high rate and send them, or just do printf debugging)



 .file "sendchar.S"
__tmp_reg__ = 0
__zero_reg__ = 1
 .global __do_copy_data
 .global __do_clear_bss
 .text
.global sendchar
 .type send, @function
sendchar:
        cli             // No Interrupts during send
        out 24,__zero_reg__     // Send start bit
 ldi r25,9       // 8 data plus stop
        sec             // set carry for stop
        sec             // nop - one more cycle
.L2:
 out 24,r24      // send bit out PB0
 ror r24         // set next bit
        dec r25         // repeat N bits
 brne .L2
        sei             // reenable interrupts (really should save/restore)
        ret
 .size send, .-send
===========================================
#include <avr/io.h>
extern void sendchar(unsigned char c);
char test[]="Megabaud Tiny\r\n";
int main()
{
    DDRB = 1;
    PORTB = 1;
    for(;;) {
        char *c = test;
        while( *c )
            sendchar(*c++);
    }
}

Different colors for K and Ka band beeps

2009-11-01T20:56:00.000-08:00

Patch at bottom.

The staccato used to split K and Ka is actually fairly easy to add, though it will be wrong for the first fraction of a second.

If the beep is the short/split staccato, it will show orange to indicate Ka, otherwise blue-green for K. The "brap" is 4 cycles of the X band followed by 4 cycles of a very short waveform (about 1/4 of X). The K band signal is 13 of these groups, the Ka is 9, a 1/50th of a second gap (which isn't visually perceptable), then another 9 cycles.

So there will be 36 cycles of the short wave for Ka, 52 for K. I count and set a flag. The NEXT group will be the color based on the flag. I was out testing and it works.


--- visione.bak 2009-11-01 19:24:01.000000000 -0800
+++ visione.c 2009-11-01 20:54:36.000000000 -0800
@@ -6,11 +6,17 @@
 #define PCHGI 4
 
 unsigned char lowtime;
+int beepcount = 0;
+int kaflag = 0;
+#define BEEPS 40
 
 ISR(TIMER1_OVF_vect)
 {
-    PORTB = 0;;
-    lowtime = 7;
+    PORTB = 0;
+    lowtime = 255;
+    if( beepcount )
+        kaflag = ( beepcount < BEEPS );
+    beepcount = 0;
 }
 
 ISR(PCINT0_vect)
@@ -26,6 +32,9 @@
     // long period, probably not beeping
     if( lowtime > 21*7 || this > 21*7 ) {
         PORTB = 0;
+        if( beepcount )
+            kaflag = ( beepcount < BEEPS );
+        beepcount = 0;
         return;
     }
 #define RED 4
@@ -33,7 +42,13 @@
 #define BLUE 1
     if( lowtime < 21*2 ) {
         // 126 294 460 microseconds
-        PORTB = RED + GREEN; // Ka as Orange instead of red
+        beepcount++;
+        if( kaflag ) // maybe && beepcount < BEEPS
+            PORTB = RED;
+        else
+            PORTB = BLUE;
+
+        //        PORTB = RED; + GREEN; // Ka as Orange instead of red
         return;
     }
     if( lowtime < 21*4 ) {

Working Prototype Visual Beep

2009-10-26T21:02:00.000-07:00

I'm using the pomona connector to do the upload of the code.

Current version:

http://www.zdez.org/tinyvisbeep.tgz

The colors have changed slightly - X band = Green, K/Ka yellow, Laser: Red/Green alternate, Bogey++: Blue, Junk: blue-red-green.

AVRtiny85 Valentine V1 Beep to LED conversion

2009-10-24T21:04:00.000-07:00

The LED is http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=425-2722-1-ND
1.6 millimeter square.

Those go through some resistors to balance the color and limit the current. The LED is VERY bright. I will need to add something for a dimming function.

The V1 has four basic tones (one is a combination for the Ka Braap alert). The waveforms are rail to rail based on a 12Khz clock, so counting the number of 84 microsecond ticks (4uS * 21) gives a series of numbers from 1-6. Anything longer should turn off the LED.

Current (preliminary) Source:
http://www.zdez.org/v1beep2led.c
Fuses need to be 0xe2 for lfuse, 0xdd for hfuse

There are standard beeps for the V1, and this is how it shows up
X will show green.
K/Ka will show yellow (Ka has a gap/flash)
Laser alternates red/green
One-More contact flashes blue twice
Junk (alert canceled) will be blue-red-green

ATtiny clip programming

2009-10-23T19:22:00.000-07:00

One annoyance is many boards waste space with ISP connectors.

The alternative is to use dip-clips or soic clips:

http://www.mouser.com/Search/ProductDetail.aspx?R=5208virtualkey56520000virtualkey565-5208
http://www.mouser.com/Search/ProductDetail.aspx?R=5250virtualkey56520000virtualkey565-5250

They are about $10 each, and require you to get some female break-away headers if you want to do it like I did, but you don't need to the onboard connector.

Bluetooth Arduino programming and more race

2009-10-23T12:26:00.000-07:00

Two quick notes - I had an arduino fail (given the amount of abuse in the prototyping it was not surprising but was annoying).

So while I'm replacing it I decided to try flashing via bluetooth using the same Parani (www.sena.com) module I'm using with a wire shift. It worked fine though the display update was less smooth (I think the BT uses bigger buffers than USB).

Also I found a race condition with the fixed race condition - I need to save a local copy of rxmrk, process the line to that point, then update rxmrk to the saved point. If I don't, when a second "push" character comes in (like a linefeed following a carriage return), it can be ignored.

So my weekend project will be to get this working again (and I've decided to drop the accelerometer, at least until I can get it to return data and not just random vibrations).

Update:
http://www.zdez.org/j1850.c - current version, accelerometer support removed
http://www.zdez.org/j1850acc.c - old version with accelerometer
http://www.zdez.org/getephem.sh - download Eph.dat from skytraq
http://www.zdez.org/agpsup.c - send Eph.dat to venus

I reconstructed the unit with a new arduino, and while I was there put in the switch. In the default position I can use agpsup.c to send the AGPS data to the Venus GPS. In the other, I can use avrdude to reprogram the arduino.

Basically it is a parani module from Sena with Tx going to the Venus module and the alternate pin on the switch, the Rx to the sena module from the Tx on the arduino, the Rx on the arduino to the switch which defaults to the Tx from the Venus (and the arduino acts as a passthrough). Without V1 or J1850 traffic it just acts transparent to/from the venus. And currently the Venus doesn't seem to ming the arduino programming (though I would need to be careful if I start putting venus config strings in the arduino).

D8 is for j1850 (IC1), and D9 is for the V1 (PCINT)..

A note on the SkyTraq/Venus AGPS - it really needs to know the time, so even with AGPS it will take a long time to cold start unless you send it the current UTC (or something close), or it finds one satellite. After that it is fast.

(I added the diode and battery specified in the venus datasheet (both are available from digi-key) to the Venus breakout, though without the recommended series resistor).

Teensy timing

2009-10-21T21:20:00.000-07:00

I've been playing with a USB based arduino-like system called the Teensy

http://pjrc.com/teensy/index.html

Cool thing is both have two input captures. They will also run independent of the USB and the 2.0 can be set to 3.3v by adding the regulator and changing a solder jumper.

Serial is cdc_acm based and should allow much faster speeds.

http://pjrc.com/teensy/usb_serial.html

So I hacked the timing code from the Mega into the teensy and it seems to work fine, though in this case I have to give an III (I followed by any two letters) to enable it. It probably could be enabled from the start, but I'm still experimenting.

Here is the patch (oops - reversed) to example.c:



--- example.c 2009-10-21 20:23:49.000000000 -0700
+++ orig/example.c 2009-07-06 03:33:52.000000000 -0700
@@ -21,9 +21,6 @@
  * THE SOFTWARE.
  */
 
-#include <avr/interrupt.h>
-#include <avr/sleep.h>
-
 #include <avr/io.h>
 #include <avr/pgmspace.h>
 #include <stdint.h>
@@ -39,91 +36,6 @@
 uint8_t recv_str(char *buf, uint8_t size);
 void parse_and_execute_command(const char *buf, uint8_t num);
 
-
-unsigned char hobuf[20] = "x";
-unsigned long ltens[12];
-static void widthout(unsigned char polarity, unsigned long width)
-{
-    unsigned char *h = hobuf, i,j;
-    *h++ = polarity & 1 ? '1' : '3';
-    *h++ = polarity & 0xc0 ? '/' : '\\';
-    i = 1;
-    while( ltens[i] < width )
-        i++;
-    while( i-- ) {
-        j = '0';
-        while( width >= ltens[i] ) {
-            width -= ltens[i];
-            j++;
-        }
-        *h++ = j;
-    }
-
-    if( 1 || polarity & 0xc0 ) {
-        *h++ = '\r';
-        *h++ = '\n';
-    }
-
-    *h++ = 0;
-
-    h = hobuf;
-    while( *h ) 
-        usb_serial_putchar(*h++);
-    
-    //txenqueue(hobuf, h - hobuf);
-}
-
-static unsigned char toggle1 = 1, toggle3 = 1;
-static unsigned long hitime1, hitime3, lastedge1, lastedge3;
-ISR(TIMER1_CAPT_vect)
-{
-    unsigned long counts;
-    PORTD |= 0x40;
-    if( toggle1 )
-        TCCR1B ^= 0x40;
-    counts = ICR1;
-    counts += hitime1;
-
-    widthout(1 | (TCCR1B & 0x40) ,  counts - lastedge1);
-    lastedge1 = counts;
-}
-
-ISR(TIMER3_CAPT_vect)
-{
-    unsigned long counts;
-    PORTD &= ~0x40;
-    if( toggle3 )
-        TCCR3B ^= 0x40;
-    counts = ICR3;
-    counts += hitime3;
-
-    widthout( TCCR3B & 0x50 , counts - lastedge3);
-    lastedge3 = counts;
-}
-
-ISR(TIMER1_OVF_vect)
-{
-    hitime1 += 0x10000;
-    hitime3 += 0x10000;
-}
-
-void timer_init(void) {
-    hitime1 = hitime3 = 0;
-
-    GTCCR = 0x81;
-    TCCR1B = 0xC0 | 2;  // NoiseC, edge ...  off,1,8,64,236,1024,ext
-    TCCR3B = 0x80 | 2; // NoiseC, edge ...  off,1,8,64,256,1024,ext
-    // /8
-    GTCCR = 0x80;
-
-    TIFR1 |= 0x21;              // reset interrupt triggers
-    TIFR3 |= 0x21;              // reset interrupt triggers
-    TIMSK1 |= 0x21;             // enable interrupt
-    TIMSK3 |= 0x20;             // enable interrupt
-
-}
-
-
 #if 0
 // Very simple character echo test
 int main(void)
@@ -156,18 +68,6 @@
  usb_init();
  while (!usb_configured()) /* wait */ ;
  _delay_ms(1000);
-        //timer_init();
-    unsigned long lt = 1;
-    unsigned char i;
-
-    for( i = 0 ; i < 12; i++ ) {
-        ltens[i] = lt;
-        // lt *= 10
-        unsigned long lx = lt + lt;
-        lx += lx;
-        lt += lx;
-        lt += lt;
-    }
 
  while (1) {
   // wait for the user to run their terminal emulator program
@@ -255,11 +155,6 @@
   send_str(PSTR("unrecognized format, 3 chars min req'd\r\n"));
   return;
  }
-        if(buf[0] == 'I') {
-            timer_init();
-            return;
-        }
-
  // first character is the port letter
  if (buf[0] >= 'A' && buf[0] <= 'F') {
   port = buf[0] - 'A';