Ever since seeing the name badges from the Open Hardware Summit 2013, I wanted one.  I tend to make it to 2-4 transportation conferences a year, plus 3-5 hamfests, so having a cool looking badge is... well, just a want.

2014-03-31 22.22.08

The front. Five buttons and an e-ink screen.

2014-03-31 22.21.49

The back. Coin cell, on-off switch, microSD card, serial headers, and components.

First off, the e-ink screen idea is pretty awesome.  It maintains an image with the power off, which is a great feature (especially since there are only around 100 page turns on that coin cell).

The powerplant of this is an Atmega 328p.  The same Atmel processor used in the Uno, Pro, Nano, Fio, and some Lilypads.

Per the website, there are two unpopulated items - a realtime clock and a temperature sensor.  However, looking at the schematic and the board, I see the unpopulated realtime clock area in the upper left area of the board, but in looking just to the left of the 328, there is a temperature sensor - the only unpopulated area is for a 0.1 uF capacitor!

I didn't even program the thing before fixing those little omissions.  I had to make a little change to the realtime clock I had is an NXP, and the doc calls for a TI chip.  The only difference - pin #3 is a backup power input on the TI chip, and on the NXP chip it is an interrupt output.  I clipped the pin prior to soldering.  I also soldered the ICSP and I2C connections, since I think I may end up using those at some point.

2014-03-31 23.20.34

The first thing I did with the BADGEr is get a copy of the firmware that is on it.  After trying to use avrdude with an FTDI board, I did what I should have done the first time - used the Bus Pirate.  Using the connection instructions on Dangerous Prototypes' website, I used the following avrdude command:

avrdude -c buspirate -C"..\etc\avrdude.conf" -P COM9 -p m328p -U flash:r:"C:/badgr.bin":r -b115200


The -c option tells avrdude what programmer avrdude is using.

The -C option tells avrdude the configuration file.  In my case, I'm running this from somewhere down in the Arduino IDE folder, and relatively speaking, backup one and then into the etc folder.

The -P option is the port number (in my case, COM9)

The -p option is the part number, in the case of the BADGEr, it is an ATMega 328p and per this page, that is the correct string to use.

-U is the operation.  'flash' is the part of memory to work with, r means to read, the next part is (obviously) the file path, and the final r is for 'raw binary'.

-b115200 is the connection speed.  My Bus Pirate is setup for 115200 bps, so I used this.  It will not work if incorrect.

Once I ran this (well, twice because I forgot the final r option in the -U portion), I got a raw file with the code on the device.

It takes a while...

It takes a while...

It took 1,048 seconds, or about 17.5 minutes.  For a 32 KB file.  There's some fixes for that HERE.  Use them well.

Initial Programming Experience

After screwing around for several days trying to load the BADGEr from SPI, I fixed one of my FTDI boards and got it to work.  My advice here: don't even mess with trying to load sketches via the SPI interface.  It won't work (and I'm not sure that was ever intended).

Initial Program


The battery included died very quickly.  I think my next improvement will be a better battery!  This DOES need a good power source when programming.  I initially used my Bus Pirate to power it while programming it from the FTDI cable.

Category: Arduino

On the heels of NT7S announcing that he's taking the red pill on Etherkit, I ordered a CRX1.  I decided this would be a good chance to try reflow soldering with the solder paste I added on the last Mouser order I placed.

First off, on the kit.  This is how things SHOULD be packaged, especially with SMDs.

If you can't find it here, you're either illiterate or it isn't here!

If you can't find it here, you're either illiterate or it isn't here!

Onto the build.

I used the syringe and a screwdriver to spread what was sometimes too much paste on the pads...

2014-04-07 21.57.05

Then heated it up until I saw the components move into place (I have to admit that seeing the components move to the correct place is AWESOME!) and the solder looked fully heated.

The end result looks like this.

2014-04-07 22.27.34

Lesson learned: tools made for removing flooring are NOT meant for electronics!  In the pic, the plastic bases for the electrolytics are starting to melt.  That can't be good; hopefully those caps didn't get too hot.  Also, it may have charred my workbench.  Hopefully by the time this posts I will have purchased something better (like a real soldering station!).

2014-04-07 22.42.31

I admit, I was being a fool and using the wrong tool.


Category: Equipment

This is the last of the series of using the Bus Pirate and the Bus Pirate Demo Board.  This one is using the SPI EEPROMs.  The board has two of the same EEPROM (well, one is SOIC, the other is DIP, but other than that, they're the same).


The power connections for this are the same as the connections you'd use for an I2C device - ground and power (I used 3.3V) + pull-up to Vin.

The data connections are pretty simple because the Bus Pirate is marked with MISO, MOSI, CLK, and CS (Master In Slave Out, Master Out Slave In, Clock, and Chip Select) and the demo board is marked with MISO, MOSI, SCK, and CS (there is one difference, and the process of elimination fixes that!).

Writing and Reading to the EEPROM

There are two steps to write to the EEPROM - send a write-enable command and then write to it.

Screenshot 2014-03-15 22.11.39

[0x06] - write enable command

[0x02 0 0 1 2 3 4 5] - 0x02 is write, 0 0  is the address to write to, and 1 2 3 4 5 is the data to write

[0x03 0 0 r:5] - 0x03 is the read command, 0 0 is the address, and r:5 means read five bits.


That's it with the demo board!  Expect that the Bus Pirate will make more appearances on this blog, though.


Category: Equipment

This is the second post on the Bus Pirate Demo Board I2C, showing the MCP4725 digital to analog converter and the PCF8563 real-time clock.


Like the last post, the ground and Vin need to be connected, and VPU (the pull-up resistors) need to be connected to the Vin as well.  CLK on the Bus Pirate needs to be connected to SCL, and MOSI on the Bus Pirate needs to be connected to the SDA pin.  There are other connections that will be necessary and will be different for each.

Digital to Analog Converter

The additional connection that needs to be made for this is the ADC connection on the Bus Pirate should be connected to the OUT pin on the demo board.  This will allow you to see the output.  As shown in this video by Mike Parks, it is pretty easy to address and use.

(1) - macro to search for address

Screenshot 2014-03-15 18.27.05

[0xc8 0x0f 0xff] - turn the analog output to full

Screenshot 2014-03-15 18.27.33

v - show voltages

Screenshot 2014-03-15 18.27.40

Note the ADC voltage, which is at 5.03V (the max it will show).

To change things, try using [0xc8 0x01 0x00].  It will set the voltage to 0.30V.  using ...0x00 0x00 will turn the ADC to 0V. It is linear from 000 to FFF hex, so 800 (0x08 0x00) is half, and so on.

Real-Time Clock

The RTL uses the same SDA, SCL, and power connections as above, and those are the only necessary connections.  However, the ADC and AUX connector CAN be used if wanted.

Setting and retrieving the time can be done using the following (ref):

(1) - address search macro

[0xa2 2 0 13 23 15 7 3 14] - 0xa2 is the address, 0 is the location to write, and I'm writing

[0xa2 2 [0xa3 r:7] - 0xa2 is the address, and 2 is the address to READ from in the next command, 0xa3 is the read location, and it reads 7 bits.

Screenshot 2014-03-15 23.18.33


It seems to me that connecting the AUX on the Bus Pirate to the CLK pin on the clock should be measurable (by using f in the BP interface), but I'm not seeing a reading, so it may not be the correct way to use that.  However, when I took the AUX wire and held it to pin 1 on the RTL IC and read the frequency, it came up to 60 Hz, and was not controlled by sending commands to the 0x0d address.


Category: Equipment

Yes, I shouted that.  And for very good reason - Arduino started me down the road of playing with micro-controllers (you can tell I haven't made a red cent on any of this - I call it "playing" :-)).  I guess you could consider Arduinos to be my gateway drug into Raspberry Pis, Beaglebones, and PICs.

In celebration of Arduino Day, I decided that I should list a few of my favorite Arduino Projects (some are still in progress).

The Filter Sweeper

This is probably the coolest thing I started to write.  It is also the most useful, as it would have it's uses with any receiver setup, whether it is a home-built radio, an RTL-SDR, or even an off-the-shelf radio).

The Bus Pirate Arduino Shield

I didn't do very much with this, and what I really learned wasn't even discussed in the post- I really learned how to 'break out' of the Arduino IDE and load an Arduino from the command line.  With Linux.

The Arduino Easy Logger Button

This is the start of what ended up netting me a ChipKit WF32.  I want (and still need to finish) a setup that makes it easy to log my radio contacts while mobile.  The Arduino version is around 90% done, but with several things taking my time it hasn't been finished.  And the ChipKit version has got a longer road.


I thought I'd have more of these, but I guess I don't. I do have a few "in the queue", though, so hopefully when I write some for AD15, I'll have a few more.  Either way, I've learned A LOT and I know I have several more posts coming that use my Mega 2560 and Due (and maybe even that Leonardo I picked up a few weeks ago).


Category: Arduino
Tags: ,

The Bus Pirate Demo Board has five I2C devices: two 24AA02 EEPROMs (2 KBit), one TC74 temperature sensor, one MCP4725 D/A Converter, and one DS1307 Real-Time Clock.  This post is about the EEPROMS and the TC74 - next week's post will be about the D/A converter and the RTC.

Pull-up Resistors & Connections

One thing that is not documented well enough for non-engineers is the pull-up resistors.  They are pretty important for I2C devices and results can be weird.  What needs to happen is to have BOTH the 5V and pull-up lines to the Vin pin on the demo board.  I used a breadboard for now, although I have a different Bus Pirate cable on the way to make this a little easier.

In both the cases in this post, the CLK pin on the Bus Pirate gets connected to the SCL pin on the demo board and the MOSI pin on the Bus Pirate gets connected to the SDA pin on the demo board.


Both of the EEPROMs are interfaced the same way.

Search for the EEPROM Addresses:

Screenshot 2014-03-14 23.44.59

(1) is the address search address

Screenshot 2014-03-14 23.47.21

[0xa0 0 3 2 1] - 0xa0 is the address to write to, 0 is the location in that address (the top), and 3, 2, and 1 are the values being written.

Screenshot 2014-03-14 23.47.51

[0xa0 0][0xa1 r:3] - 0xa0 is the address, 0 is the location in the address.  0xa1 is the read command, and r:3 indicates to read three bits.

Screenshot 2014-03-14 23.49.39

[0xa0 0xfa][0xa1 r:6] - this is to read a MAC address from the chip.  Unfortunately, I can only seem to get all F's from these chips... I'm not sure if I'm doing something incorrect or if the chip's spec has changed since the instructions on Dangerous Prototypes were written.

As a final test, I cut the power to the board (w) and turned it back on (W) and read the chip to see if the values were still there.  They were.

Screenshot 2014-03-14 23.50.51

TC74 Temperature Sensor

The TC74 Temperature Sensor is an interesting device to use.

Screenshot 2014-03-15 00.06.18

(1) - standard address search macro

Screenshot 2014-03-15 00.07.33

[0x9a 1] - 0x9a is the address, 1 is a value to write.  We don't really care what it writes, we just need to do this to read the chip.

Screenshot 2014-03-15 00.09.30

[0x9a 0][0x9b r] = 0x9a is the write address, 0 is a partial command to select the temperature register, and 0x9b r reads the register.

The value returned is 0x16, which is 22°C, or 71.6°F.

...next week - more I2C goodness!


Category: Equipment

In learning how to use the Bus Pirate, I started with the one-wire area of the demo board.

First off, important notes:

  • I'm using the v 3.8 Bus Pirate.  The pinout is different than some of the others.
  • I'm using a Sparkfun Bus Pirate cable.

My cable is as follows:

Black: Ground
White: 5V
Grey: 3V3
Blue: ADC
Green: AUX
Yellow: CS
Orange: MISO
Red: CLK
Brown: MOSI

The first part of this is based on using the DS2431 1,024 bit (1 kilobit?) EEPROM.  The second part is using the DS1822 temperature sensor.


I used the instructions on Dangerous Prototypes as a guide.

This is how I had the demo board hooked up.

This is how I had the demo board hooked up.

I hooked the ground (black) to the ground, the 5V (white) to Vin (the 3.3-5V pin), and MOSI (brown) to One Wire.  Then, open the bus pirate and get into one-wire mode (m {enter} 2) and turn on the power (W).  Then, issue the search macro ( (240) ).

Screenshot 2014-03-09 11.49.02

Use (240) or (0xf0) to search the one-wire bus. The bus pirate will return a list of all items on the bus. In my case, I have two EEPROMs (thanks to not being able to get a part) and a temperature sensor.

Writing to the EEPROM to a Temporary Location

Screenshot 2014-03-09 11.53.44

I write a string of numbers to one of the EEPROMs here.

To write some values to the EEPROM, I used the following:

(0x55) (2) 0x0f 0 0 8 7 6 5 4 3 2 1

(0x55) is the macro to 'match 64 bit address'

(2) is the macro to the address of the EEPROM I'm writing to

0x0f is the command to write to the devices scratch pad

0 0 is the location to write to

8 7 6 5 4 3 2 1 is the data that I'm writing

Reading (Verifying) What I Wrote

Screenshot 2014-03-09 11.54.27

I read that string of numbers here.


To read the string of numbers, I used the following

(0x55) (2) 0xaa r:3 r:8 r:2 r:2

The first two are similar to above - (0x55) to match the address and (2) for the macro to the address I wrote to.

0xaa is the read scratch pad command

r:3 reads the authorization code (needed to permanently write the data)

r:8 reads the data I wrote in the last step

r:2 reads the CRC

r:2 this is all '1's

The final r2 returns 0xFF, which is 2 bytes of 1s, in decimal this is '11111111' '11111111'.

Permanently Writing the Data

Screenshot 2014-03-09 14.20.26

I permanently write the data here.

To permanently (well, permanent until I rewrite it) write the data to the EEPROM, I used the following:

(0x55) (2) 0x55 0x00 0x00 0x07

(0x55) (2) is the same as above

0x55 is the command to write the scratch pad to memory

0x00 0x00 0x07 is the authorization code from above

Verifying the Write

Screenshot 2014-03-09 14.20.59

I verify the write here.

To verify the write, I used the following:

(0x55) (2) 0xaa r:3

(0x55) (2) is the same as above

0xaa is the read command (same as above)

r:3 means read three bytes.  The data that is returned is 0x00 0x00 0x87, which is different from before

Reading Back the Data

Screenshot 2014-03-09 14.21.39

I read back the values here. These are permanently written to the EEPROM.

To read the data, I used:

(0x55) (2) 0xf0 0x00 0x00 r:8 r:8

(0x55) (2) is the same as above

0xf0 is the read command, but this is read from the memory, not the scratch pad

0x00 0x00 is the address

r:8 r:8 reads 8 bytes, twice

The first string returned is 0x08 0x07 0x06 0x05 0x04 0x03 0x02 0x01, which is the data we wrote.  The next string is 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00, which is data that was never written, so it is all zeros.

That's it!  I read and wrote to a small EEPROM.  If it isn't obvious from the picture above, this is about the same size as a small BJT transistor.

Reading from a DS1822 Temperature Sensor

The DS1822 is a one-wire temperature sensor that is also the size of a BJT transistor.  Reading from it is pretty easy and was described on Hack-A-Day by Ian back in 2008.

This is in the same setup as above, so looking in the screenshots above, the proper address for this device is (1).

Reading from a temperature sensor.

Reading from a temperature sensor.

To read from the device, two commands must be entered:

(0x55)(1) 0x44

(0x55)(1) 0xbe r:9

The first command is a "Convert temperature" command, which basically tells the sensor to read the temperature.

The second command reads 9 bytes from the sensor.  The important part are the first two bytes.  In the example above, the first two bytes are 0x71 0x01.  This translates into being read as 0x171 (see note).  That 0x171 needs to be converted into decimal, in this case 369.  That number then needs to be multiplied by the resolution, which if never changed is 0.0625.  That comes out to a temperature of 23.06C, or 73.5F.


This is the first of a multi-part series.  Next installment in this series (hopefully next week) will be the I2C bus, although depending on the length (there are several chips there), it may be broken into two parts.



Category: Equipment

A few weeks ago, I got a Free PCB from Dangerous Prototypes for a Bus Pirate.  This is a pretty cool hardware swiss army knife that I'm still learning how to use.

This is the bus pirate in front of the terminal background.

This is the bus pirate in front of the terminal background.

I had a few issues with the build (none a fault of Dangerous Prototypes or the PCB manufacturer).  First off, I didn't get the LEDs on correctly the first time, and I'm pretty sure I didn't get the USB one right the second time, either.  Also, I didn't get good solder joints on the PIC24.  I was seeing problems that were identical to these reported on the DP Forum, and feared that the FTDI chip was fake.  After removing the FTDI chip and pulling one from another FTDI board I had, I tried sjaak's advice of pushing on the chips and found that if I pushed on one part of the PIC24, the VREG light came on, so I reflowed the solder on both chips and voila!

I also learned that PIC chips aren't as easy as Arduinos to burn, and after initially finishing the PCB, I had to order a PICKit3 to burn the chip.  It wasn't a big deal to order the PICKit, but it was a nearly week delay as I inadvertently (and unknowingly) selected a shipping option that used UPS for the long haul from Ft. Worth to Cincinnati and then used the postal service to deliver it the last 2 miles from the post office to my house (to use another ham's quote, "you get the incredible slowness of the ground services + the normal 2 day delivery of USPS. you save cents. yay!?" ... yeah, that's about right - 100 cents to add two days to the delivery time).

I did slightly deviate from what I think was intended with this - this was built for a USB Micro connector, but I put a USB Mini connector on it.  It hangs off a little, but I'm fine with that (I have minor personal reasons too, but it really boils down to preference).

I also deviated on the connector.  I didn't look back in my order history to get the correct connector, and ended up with an incorrect connector.  So I put header pins on it and called it done.

A final thing I learned was the value in over-ordering.  Since I'm not a pro in this, my parts orders tend to be small, and normally there is a price break at 10.  Having extras on hand means that as soon as I get a PCB, I can start building right away.

Thanks to Dangerous Prototypes for the PCB!  I'm already learning a lot about using it and I'm (of course) using my last free PCB build to learn more about using it.


Category: Equipment

For anyone on the Amateur Repairs (*cough* yahoo *cough*) group or who follows me on G+, YouTube, or Twitter, you've likely seen posts related to my IC-706 mkIIG.  I've pulled the radio out of service because of problems primarily on VHF-FM (at least it seems that's where the problems are at).  In fact, since early December, I've been sporadic with transmitting with it, and I haven't transmitted with it at all since mid-January.

The problem I'm having is extreme static even with very strong signals.  I've checked the likely (hopeful?) culprits of power cords and antenna connections.  Since things seem to be fine on those - I've tried two power cords and three power sources and two different antenna setups - I've moved on to checking internals.

My first check was for anything obvious.  Like this, this, or even this.  Nothing.  I don't know if I should say "fortunately" or "unfortunately".

My second check was to poke around inside.  I first looked at some of the audio waveforms at the NB test point and the WFM test point.  Pretty interesting to see on a scope, and they didn't react to volume (that's a good thing, as this is likely before the audio amp!).

The Noise Blanker Test Point

The Noise Blanker Test Point

(PS in the video above: yes, I'm checking that with an oscilloscope probe.  It works, even if it isn't necessarily 'right'... or maybe it is, I don't know).

My second test was to do something more ... practical.  I know from some of the reading I've done in the ARRL Handbook, the owners and service manual for the rig, a video from Kenneth Finnegan (from The Life of Kenneth blog that I follow), and some comments from Mike M. on Google+ that maybe I should check the PLL board.  And besides, checking stuff is easy, right?

This is the small battery of PLL tests.

This is the small battery of PLL tests.

The first check is the 60 MHz reference frequency.  After finding and fixing a messed up power switch on my antenna analyzer and after checking it with the scope to ensure I wouldn't blow up my analyzer, I probed it and found exactly 60.000 MHz.  Good.

The second test was of the PLL Loop Lock Voltage.  Initially, I found that it was around 300 mV.  This was too far outside of the required 2.0 V at 0.03 MHz. I thought for a moment that it might be a typo, although those things NEVER happen...

I've circled a few of the typos in this - not every one.  Apparently I'm SARVICING this radio and I've been spelling GREDE and RENGE incorrectly all these years.

I've circled a few of the typos in this - not every one. Apparently I'm SARVICING this radio and I've been spelling GREDE and RENGE incorrectly all these years.

...and moved on to test the Main Loop Lock Voltage.  It was far less than the spec 4.0 V on the first test (at 129.99999 MHz), so I didn't continue tests.

After some replies to the post on the Amateur Repairs group, I tried again to recalibrate the PLL circuit and was able to do it.  This was, of course, after I removed a shield to test two transistors.  I've reinstalled it in the truck and so far, so good.  But we'll see.  It could have been that the PLL was off causing weird errors that may have changed as voltages to the radio changed (it is mobile, after all), or it could be that something is still bad.


Category: Equipment

I risk falling behind in my weekly posts, so this is a post to provide a few small updates.

The Icom 706 is still screwed up on 2m FM.  And maybe 70cm FM.  I haven't tested SSB or AM on those, perhaps I will soon.  I've thought up a way to test things, so soon I will have it on the bench (again) to test.  I listened to a 40m SSB net all morning and noted no static that seemed out of place (e.g. static with an S9+40dB signal), so it still looks like things are affecting only the high VHF and UHF signal path.  In a related note, I need to tune my 40m hamstick.

I am halfway through building a Bus Pirate.  I ordered the remaining parts I need late last week and they are expected to arrive the same day I'm typing this blog post (Tuesday).  I've really been chomping at the bit to finish this and play with it, and Ian (from Dangerous Prototypes) has uploaded several videos to YouTube that show how to use it, so I fully expect to watch several of them again.

In keeping with my want to build a small Arduino powered receiver, I purchased some parts for that (on the same order that arrives today).

I'm still working on my experiment that I talked about last week.  There are some interesting findings so far.

I stopped by a Radio Shack while in the mall over the weekend.  Apparently we're still waiting for their return to a not-useless store on the east side of Cincinnati.  All I saw were the same things as the past few years, with the same high prices and same SMALL selection.  Honestly, if Micro Center would open a mall on the east side of Cincinnati, it would be maker heaven.  I do appreciate that the kids behind the counter didn't attempt to sell me a cell phone, but in their return to the 80s, they attempted to sell me batteries (and, like their cell phone sales strategy, they didn't take the first no for an answer).

On that, big shoutout to Micro Center - they've been growing their maker section with a decent selection of Arduinos, Raspberry Pis, Beaglebone Blacks, and even parts at very nice prices.


Category: QSTs

This is the new server