Driven By Curiosity

I subscribe to Google alerts for a variety of subjects, including starter interrupts. It had been months since there had been any notices. Suddenely, a couple of weeks ago they started coming in citing a variety of newspapers. It turns out there was apparently one story which was sent out via the Associated Press and that article was repeated in many places.

This is interesting. It really shows how what looks like a trend or development of a serious interest is only a single source article. Reading the article and knowing something about the subprime lending business, I can also say the article was not especially useful.

In particular, the quotes from the “consumer advocate” were extremely un-informed. It was clear that he has no experience with the sub prime automobile lending market or he would not have made the comments he did. Perhaps he was miss-quoted?

He was quoted as saying the starter interrupts took all the risk out of the loans. He sort of forgot to mention
1. The customer abuses the car and then defaults
2. The customer drops the insurance and then totals the car
3. The customer bypasses the starter interrupt and keeps driving
4. The customer skips town with the car and it can’t be recovered

plus many others. Installation of a starter interrupt device helps the lender get paid, but to say it removes all the risk from the transaction is wrong!

In my search for better, quicker, easier ways to develop content rich websites I happened across an ebook called “Getting Rea;” by a company called 37Signals.com. It got me all excited because they are much farther down the path toward developing the kinds of websites I had dimly imagined.

Their sites are built with a programming language called Ruby. They have used Ruby to build a website development framework called Rails. The combination is Ruby on Rails and abbreviated RoR. I have added pages to this site where I disucss my experinces with RoR in more detail.

Once the initial excitement wears off, there are some significant hurdles. It is harder to find a webhosting company that offers it, there is a serious learning curve, and the setup and install features still have lots of rough edges. However, it looks very promising.

I almost thought I had something working yesterday. I haven’t worked out the issue yet, but I’m seeing signs of life. I got and installed the baluns and chip antennas… My 802.11 access point died and confirmed that it was polluting my receiver, as I get CCA=1 now. I figure that for test purposes, I should run the CC2500 as close to 2.45GHz as possible, as that’s the center frequency for the balun/antenna. That way whatever rotten impedance matching my rework causes should be partially compensated by maximum performance of the components.
(more…)

I was a little hasty in my board design. I did NOT do sufficient design of the RF section on my boards. What I find really funny now is that it’s much more obvious to me than it was previously. In lieu of a design, I copied the matching network from the CC2500 datasheet then copied some F-antenna from somewhere else. Not smart.

Looking at it now, the matching network is a 200 ohm to 50 ohm balun, the antenna is something else, although I really don’t know what. And the other prototype boards I’ve seen with a similar antenna have very different matching networks. Hmm… Oh well. It probably would have been clever to look around more and figure out how to do a 200 ohm folded dipole as suggested on the CC2500 datasheet.
(more…)

I am using SmartRF Studio to generate register settings for the CC2500, which is no doubt true for anyone using these parts. The code export function is cool. If you use it, be sure to save your configuration in addition to exporting code. I left out that step and had to re-configure the registers, although it wasn’t a big deal since I’m still using mostly defaults.

I set up the export code section to do the following:
- C-style comment delimiters
- normal view summary
- header:
const unsigned char cc2500_reg[][2] =
{

- for each register:
{ 0x@AH@, 0x@VH@ }@,@ // @RN@: @Rd@
- footer:
};
const unsigned int cc2500_reg_size = sizeof(cc2500_reg);


This gives a nice listing and is easily included into a build. I also use a header file with the following:
extern const unsigned char cc2500_reg[][2];
extern const unsigned int cc2500_reg_size;


Nothing too fancy, but it seems to work well. I set up my SPI tx routine to take a character pointer and a length, so sending the configuration is really easy and takes no effort aside from updating the settings in SmartRF Studio and exporting them to the C file.

I have been beating my head against the wall trying to figure out how my software kept working less and less well. It’s awful. Code would work, then it would eventually quit working — apparently. In particular, I’m trying to get the CC2500’s working on my boards. I was getting happy status bytes back until I included the c file I’m creating with Chipcon’s nifty ‘export code’ function in SmartRF Studio. I did have an issue compiling for the ATmega165, but got that fixed. Still nothing, or at least something tantalizing followed by nothing.
(more…)

I finally figured out that some issues I was having with building software for my ATmega165’s had to do with my cruddy hack to get avr-gcc to compile for them without warnings. I made it so that instead of using ‘-mmcu=atmega165′ I used ‘-mmcu=avr5 -D__AVR_ATmega165__’ when compiling. It works — up to a point. For me that point was reached when I started modularizing my code and trying to turn it into a real project instead of just lame test code.
(more…)

I noticed that I jumped into the middle of this project without much background. There are a couple higher-level posts, but nothing too specific. So…

This project started with the desire to create a simple device. The existing solutions are all complex in various ways. Generally they are a little pricey and are actually rather awkward to use as part of the business. That’s really the biggest issue. Technically they aren’t that exciting — something that blocks the starter signal in the car under certain circumstances. Not hard. A 50 cent switch from Home Depot would do fine, but not in the car finance business. “Now please place the switch in the off position until you pay us.” Not quite.

So obviously a little more is required. There’s a bit of range in implementations from punching codes in on buttons mounted in the car to pager-based enabling/disabling. The codes are easy (and inexpensive), but have an issue with distribution. Particularly when a finance company purchases the note from the dealer, there’s not really a guarantee that the customers will want to make payments solely at the finance company. The pager system makes distribution easy, on the whole, although you could have some coverage issues in places like New Mexico and it will cost you more. It probably depends on the value of the vehicle.
(more…)

I was probably being too cheap on this starter interrupt project, but I decided to save $270 by using the AVRISP in-system programmer for my atmel parts (ATmega165 or ATmega128, and AT43USB355). I didn’t read the datasheets well enough and failed to notice that all support the JTAG programmer, which would have been a good idea. But it’s too late now that I have boards back.

I had decided that while serial EEPROM programming wasn’t quite what the AVRISP or STK500-type devices did, since you can define programming commands for such things as ‘avrdude’, I could probably get them to do EEPROMs as well. Hah. Not really. The signal names on the ISP connector are all the same as for EEPROMs, but they don’t get used the same. I did learn why the programmer software had such a fetish for 32-bit values: that’s how the ISP protocol delimits commands. Oh. So no dice on the AVRISP. I did plan for that with one of my boards having an external SPI interface so I could load up the EEPROM, but that’s a little awkward and if I can do it in software from the PC, I’d like to.
(more…)

Tools are always exciting.

I decided to use the Atmel AVR family for the starter interrupt project because it had a well-established GCC port and some other utilities available from Atmel to help with things like USB drivers and such. I have used other expensive tools in the past, and while they definitely tend to have advantages in terms of libraries and debugging, I haven’t seen anything to make me want to use them for my own projects. I expect to have some messing around in setting up any tool, and even more for free tools. Which is fine — it’s awful trying to figure out why something broke in something like VxWorks. The tool does a lot for you, but when it breaks you probably won’t know why. I got to watch a support guy spend a few days reading through auto-generated header files trying to figure out what was going on. Ick.
(more…)