Archive for July, 2006

LED Clock: $6 Refund for Wrong Resistors

Tuesday, July 25th, 2006

Best Hong Kong never responded again to the claim/dispute process; and when their time ran out last Saturday, PayPal decided in my favor with this message:

We have concluded our investigation into your claim.

We have decided in your favor and have recovered funds from the seller. You have indicated that a partial refund amount of $6.00 USD would be satisfactory.

If the seller’s account has insufficient funds to complete the refund owed to you, please be assured that we will take appropriate action against the seller’s account, which may include limitation of the seller’s account privileges.

And both PayPal and Citibank show that $6 has been transferred from Best Hong Kong back to my credit card, so I guess we’re done here.

Curiously, PayPal’s dispute resolution center has a rather different message when I view the closed case:

We have completed our investigation of this case. We have denied this claim and a refund will not be issued.

Now, I know it’s already been issued, but that kind of message is troubling. So I’ve submitted this to their customer support:

I recently received an email from you saying you had completed your investigation of buyer complaint case #PP-179-609-629, had decided in my favor, and had provided a partial refund as I requested.

However, I just went into your Resolution Center to view the ticket online, and it says you denied the claim and no refund will be issued.

I’m a little concerned by that. Can you explain the discrepancy between the two messages?

LED Clock: It’s the Voltage, Man (DS1302)

Monday, July 24th, 2006

Well, the DS1302 now seems to be working off my 5V supply–dropped down to < 4V.

The Discovery

Earlier I had realized that I didn’t know whether the read failures were associated with having a 5V supply or having supply from VCC2 (primary). Tonight I swapped the power supply connections, so the lithium cell was connected to VCC2 (primary) and the bench supply was connected to VCC1 (backup). The read failures still occurred when the chip was running off of 5V; so the problem had to be associated with voltage, not supply pin.

The Cure

The datasheet has this to say about the supply voltage:

Supply Voltage VCC1, VCC2 2.0 3.3 5.5 V

5V is within the recommended operating conditions–but 3.3V is preferred. So I added small-signal diodes between the 5V supply and VCC2 until I got down to 3.4V, at which point everything worked.

Curiously, it took four diodes to drop 1.6V, or about .4V each–not the .7V that I’d expect from silicon diodes. Granted, I can’t find a datasheet on them (1N9148); but I really doubt they’re some new exotic that I just happen to have lying around in my parts bin.

My best guess is that the 1302′s operating current is so low (in the .5 – 1mA range) that the diodes are operating below the knee. (To paraphrase Captain Barbosa, we like to think of .7V as more of a guideline.) The knee of the curve is the point at which slight increases in voltage across the diode result in rapidly increasing current. Conversely, if the diode current is externally limited below the level of the knee, the voltage drop across it can be less than .7V. I seem to recall doing a lab on this at PSU.

I’m disinclined to acquiesce to putting four small-signal diodes on the power supply of my timekeeping chip, so I guess I’ll look for a Zener in the 3.5V range. It needs to be more than 3.2V (the lithium cell’s 3.0V plus a .2V margin) to keep the chip from switching to secondary power; and it needs to be less than 4V (but I don’t know how much less), because that’s the last reading I took while it was still malfunctioning before adding two more diodes and dropping VCC2 down to 3.4V.

Best of All,

The burst write now works, so I can set the date and time with a single function call. I can only speculate that whatever was screwing up the reads was also screwing up burst writes.

That is, everything now works on the DS1302. I think I’m supposed to be elated at this point, but I’m strangely not. Maybe I’m waiting for it to fail again. Because at this point, given that it doesn’t work even when I’m operating it within specifications, I can’t figure out what changed between when it did work and when it started not working; or alternately, I can’t figure out why it ever worked.

LED Clock: Troubleshooting the DS1302 Interface

Monday, July 24th, 2006

My LogoChip is still reading garbage from the DS1302 when it (1302) is powered at 5V and good data only when the 1302 is running off the backup battery at 3V. I spent some time looking at it this weekend and discovered a number of interesting things (which aren’t all related to the voltage problem), but no solution yet.

LogoChip Logo Include Files

Because LogoChip Logo has no documented means to reference or include other files into code, I was doing something hacky and ugly with m4. Yesterday, I accidentally (by loading the wrong file into the LogoChip console and getting a different error message than I expected) discovered that LogoChip Logo does support an include command: include foo (no punctuation required).

That’s fantastic news, because it allowed me to clean up all the m4 ugliness, do away with the need for a Makefile, etc. I switched all of my DS1302 code to use the native include command, and will do the same for the 6276 code the next time I work with the LEDs.

Burst Write Not Working

The DS1302 supports burst read and write operations, where you access multiple memory locations sequentially. I know my burst read operation works, because that’s how I’m pulling the complete timestamp out of the device to display in my test code. But for some reason, my burst write doesn’t work–I can only set the time using individual write statements, not using the burst write.

I’ve corrected two problems with the burst write code already. I had somehow forgotten to send the burst write address to the device, so I was trying to read from the clock chip without it having any idea what it was supposed to be sending. And I had omitted the control register from the end of my burst because I didn’t want to change the control bits. However, I reread in the datasheet that a burst write to the clock registers isn’t committed until all eight bytes have been written, so I added a dummy write for the status register (which contains only a write-protect bit that I don’t want to enable anyway).

Still no joy. I’m starting to feel like I’ll need a logic analyzer to solve some of these problems.

5V / 3V

A handful of experimental observations about whatever’s going on:

  • Writing to the device registers only works at 5V, not at 3V. (Writing at 3V doesn’t change the values in before/after read tests.) Reading the registers only works at 3V, not at 5V. (Reading at 3V gives garbled but repeatable results.)
  • The problem doesn’t appear to be dependent on the source of the 5V supply–the results are the same when running the LogoChip from a battery and the DS1302 from the bench supply, both from the Curiously Strong LogoChip battery, or both from the bench supply.
  • The problem doesn’t seem to be specifically timekeeping related–I get similar results reading/writing the clock registers and reading/writing the 31-byte NVRAM that the 1302 provides.

It just occurred to me while writing this that I don’t know whether the problem is related to the 1302′s operating voltage or its supply source–that is, whether the difference is that it’s running on 3V instead of 5V, or that it’s supplied by VCC1 instead of VCC2. That’s definitely worth trying tonight.

LED Clock: DS1302 Unworking

Friday, July 21st, 2006

I did some refactoring on the DS1302 code last night: moved driver code into a library, demo code into a program, wrote some print routines to send single nicely-formatted times to the LogoChip console, updated the Makefile, etc. I had a few minutes before breakfast today, so I went to my workbench to see whether the 1302 still had correct time.

Unfortunately, I found I had left my bench power supply on, so I didn’t get a real test of the backup battery. Stranger than that, I was getting garbage data from the 1302 again, and changing the data clock timing didn’t have any impact.

Strangest yet, when I shut down the bench power supply to see how the garbage would change when the 1302 was off, I started getting the correct time. This seems especially strange, as most timekeeping chips shut off all communications and go into a powersaving mode when primary power disappears.


Turn it back on, garbage. Off again, correct time.

The only thing that even halfway makes sense is if I had VCC2 and VCC1 swapped, and the chip was using the power supply as a backup power source when the battery failed (ha ha). But I’ve checked and checked, and I have power to VCC2 (pin 8 ) and battery to VCC1 (pin 1), which is what the datasheet says, even though the designations seem backward to me.

Not sure how to go about troubleshooting this, but maybe something will come to me by the time I get back to it.

LED Clock: Working DS1302 RTC Interface!

Thursday, July 20th, 2006

After the huge psychological reward of getting the LED digit working, I haven’t felt much like getting back to the real-time chip, knowing any successes there would feel insignificant compared to the bright blue glow of the LEDs. However, that’s the recipe for shelving a project indefinitely; so tonight [last night, by the time I finished writing this up] I went back and gave it a go.

Backup Battery

I had got some PC motherboard backup batteries (3V lithium button cells) from my friend’s son Phill as he emptied his “warehouse” in preparation for leaving to college. He had stuck all the cells together between two strips of masking tape, and they’re all covered with goo. I cleaned a couple of them with Goo Gone a while back, and was astounded at how shiny they are–they look newer than anything I’ve ever noticed inside a PC. [Need to remember to add a photo.]

I had also desoldered a couple of holders from dead motherboards. The first thing I did tonight, as a warmup, was plug the backup cell into the circuit and wire it into the RTC and the external crystal. It works–more on that later.


Made a mistake I’m pretty sure I’ve made before–forgot to connect the ground between the LogoChip and the RTC breadboard, so it was floating again. (That’s not the same floating ground I wrote about earlier, though–that was an off-by-one error when I meant to connect the ground pin on the chip and connected nothing instead.)

I/O Clock Timing

I was getting random data again, though, which was really frustrating. Finally I went to set up a debug mode to take the I/O clock down to 5Hz (yes, 5 Hz, to make it slow enough to watch with a logic probe, since I don’t have a working logic analyzer), and I started getting correct data.

That told me my problem was clocking the data too fast; and as it turns out, increasing the delay after toggling the clock line from one no-op to two is enough to get completely reliable data (at least as far as I’ve been able to determine). Furthermore, this eliminated the weird bit-7-is-always-on problem I’d been experiencing previously in the seconds register.

Real Time

With those problems solved, I’m actually able to get realtime out of this chip! I had previously written code to batch-read all of the time registers, cache the result, and pick it apart into separate values; and I now wrote a routine to use that and print out the individual digits of the time to the LogoChip console. I called it from the console prompt like this:

loop [ ds1302-print-hhmmss wait 10 ]

And was able to get a real-time display like this:




I guess that didn’t turn out to be as much of a let-down as I thought it would! :-) Also, the backup battery is connected properly, because I was able to power off the circuit, bring it back up, and still have correct time.

Next Steps

The times are getting printed vertically because LogoChip Logo always sends a newline terminating each print statement. I’ll update the code to send ASCII values instead, so I can print the time horizontally in a normal format.

For now, I’ve just been playing with HH:MM:SS. Eventually I’ll need to add date processing, to handle DST changes.

There’s also some code cleanup to do, plus some refactoring (rearranging the code to work the same but be in a significantly different [and hopefully better] format). I’m used to being able to use code libraries, but LogoChip Logo doesn’t support them, so I’m hacking my own method using the m4 macro preprocessor and make to glom source files together. I’ve already refactored my 6276 LED driver code that way, and part of the process is carefully defining separate namespaces (since LogoChip Logo also doesn’t have local variables). I’ll want to do the same with this.

And it looks like it must be PC board time . . . Tom McGuire volunteered to help me make the large boards for the full displays; and I need to make a small carrier board to breakout the DS1340 from SOIC to DIP for prototyping. That also means some more refactoring of the 1302 code–I need to be sure to separate the interface code that talks to the chip from the timekeeping code that delivers numbers to the clock, so the timekeeping code can operate independently of which RTC chip I select.

Source for Mini-Drill and Mill Bits

Wednesday, July 12th, 2006

I just ran across Drill Bit City, a company that resharpens mini drilling and milling bits and sells them for very reasonable prices. Like sets of ten identical bits for as low as $3, mixed sets in the $7 range, etc. I’m looking forward to buying from them once I get my own machine up and running!

Discovered via Will O’Brien’s CNC machine, part 3.

LED Clock: Escalating Resistor Dispute

Wednesday, July 12th, 2006

As I haven’t heard anything from Best Hong Kong in the week since my last email to them, I assume they’re not planning to get back to me. I just escalated my dispute to a claim, with this notation:

I picked this auction out of various LEDs offered for sale in part because it advertised my choice of free resistors; and I was very careful to follow the seller’s instructions during checkout to specify which resistors I wanted (which I notice they don’t deny).

I would really prefer to have the seller ship me the resistors I specified, completing the auction. However, as I can buy the same resistors (220-ohm 1/4 watt) through Digi-Key (a widely known mail-order catalog) for as low as $5.40 plus shipping, I guess I’d be willing to accept a $6 refund.

Since the error in sending the wrong resistors was made entirely by the seller, and if they’re really not willing to send me the right ones, I don’t see why I should be willing to accept a lesser refund than what it will cost me to replace the resistors from an alternate source. Any other outcome means that the seller’s error costs me money, which doesn’t seem appropriate.

PayPal’s system displayed this confirmation message:

A claim has been filed against this transaction. The seller’s deadline for responding to this claim is . The seller has the option to provide a full refund for the amount of the transaction, offer a full refund if the item is returned in its original condition, offer a partial refund in an amount you agree to, provide proof that a refund was already issued to you, or disagree with your claim. If the seller does not respond by the deadline, the claim will be decided in your favor. You may cancel this case at any time by clicking “Cancel” below.

LED Clock: Interfacing to the DS1302 RTC Chip

Friday, July 7th, 2006

It occurred to me that I haven’t posted the latest update on data interfacing to the Dallas/Maxim DS1302 real-time clock (RTC) chip; and then I searched and saw that I haven’t posted anything on it. I received the sample chips mid-June and started working with them after I had prototyped the A6276 LED driver and was waiting for my shipment of LEDs. Apparently once I received the LEDs, I was so excited by the bright blue glow that I forgot to get back to the timekeeping functions. :-)

“Auditioning” the 1302

I’m looking at two different timekeeping chips to use in the clock. The DS1340 looks like the better choice but is only available in surface-mount packages, so I’ll need to make a carrier before I can breadboard it to test; thus so far I’ve been testing the DS1302.

The 1302 tracks YY/MM/DD HH:MM:SS plus day of week and choice of 24-hour or AM/PM. It uses an external 32768Hz oscillator and has a VCC2 input to allow it to run on a lithium backup battery for up to 11 years in the absence of primary power. It doesn’t do daylight savings time, has century-unaware leap year support (but my clock will not still be in use in 2100), and requires you to set day of week manually rather than calculating it algorithmically. It’s not terribly sophisticated–but I don’t need terrible sophistication to get this job done.

It uses a “simple” three-wire interface for data communications:

Name Signal Use
CE clock enable? raise to begin transmission; lower to end communication
SCLK serial clock? cycle to transmit and receive data
I/O I/O data to and from clock chip

To write data to the 1302, raise CE, transmit the register address to the 1302 (setting the low bit to indicate a write operation, and clocking each bit), transmit the data (clocking each bit), and lower CE. To read data from the 1302, raise CE and transmit the register address (clearing the low bit, and clocking), continue clocking and read the received data, and lower CE.

But in the Real World . . .

I jumpered it to my Curiously Strong LogoChip and coded up an implementation of the protocol, but was getting totally random data back. The 1302 claims to support clock speeds down to DC (i.e. as slow as you want it to go), so I slowed it down to 1Hz and put the logic probe on it to see whether the bits it was sending matched the bytes I was outputting. After watching it send ultra-high-speed flurries of data back in response to the slow requests I was sending it, I realized it behaves much more predictably when I connect its ground pin to ground instead of leaving it floating. Oopsie.

Once I was actually communicating with the chip with a common voltage reference, I was able to read and display its seconds register. I found that it changed once a second as expected; and I knew its output wouldn’t be a simple count from 0-59, because it uses binary-coded decimal (BCD), where each nybble is the binary coding for the corresponding decimal digit.

I was surprised, though, to see the values alternating high and low: 64, 192, 65, 192, 66, 194, 67, 195. This suggested a bit alignment problem–I wasn’t reading the right bit in the right position. I wrote a Perl script to translate the decimal values into binary with leading zeroes (to make the bits line up so I could scan visually for patterns) and fed it a complete 60-second cycle, with this result:

64  -  01000000
192  -  11000000
65  -  01000001
193  -  11000001
66  -  01000010
194  -  11000010
67  -  01000011
195  -  11000011
68  -  01000100
196  -  11000100
72  -  01001000
200  -  11001000
73  -  01001001
201  -  11001001
74  -  01001010
202  -  11001010
75  -  01001011
203  -  11001011
76  -  01001100
204  -  11001100
80  -  01010000
208  -  11010000
81  -  01010001
209  -  11010001
82  -  01010010
210  -  11010010
83  -  01010011
211  -  11010011
84  -  01010100
212  -  11010100
88  -  01011000
216  -  11011000
89  -  01011001
217  -  11011001
90  -  01011010
218  -  11011010
91  -  01011011
219  -  11011011
92  -  01011100

I needn’t have included the whole thing, because it’s obvious what’s happening. What I thought was the high bit was changing the most rapidly, so it must in fact be the low bit. Somehow the byte got rotated one bit to the right. It’s only fair to mention at this point that the chip will keep repeating its transmitted data as long as you keep clocking it; so a rotation like this simply means that I’m a clock cycle off, not that something utterly bizarre is happening.

I searched my code for an errant clock cycle between the address-write and the data-read, but couldn’t find anything amiss. As an ugly kludge to get it working, I changed the read routine to cycle the clock after reading the bit rather than before, and of course began to get the correct data. Then I reexamined the datasheet and found the slightest justification in their confusing language that this behavior is by design: the first bit from the DS1302 is transmitted on the falling edge of the same clock cycle whose rising edge carried the last bit of the address register. Ewwwww.

I’ve been trying to think of cleverer ways to adapt to the situation, but haven’t come up with any. Clocking after reading works for single-byte reads, and should work (I haven’t tried it yet) for multi-byte reads in burst mode. So I guess I’ll leave it that way.

Here are the first few entries of a correct seconds cycle, in all their glory:

128  -  1 | 000 | 0000
129  -  1 | 000 | 0001
130  -  1 | 000 | 0010
131  -  1 | 000 | 0011
132  -  1 | 000 | 0100
133  -  1 | 000 | 0101
134  -  1 | 000 | 0110
135  -  1 | 000 | 0111
136  -  1 | 000 | 1000
137  -  1 | 000 | 1001
144  -  1 | 001 | 0000
145  -  1 | 001 | 0001
146  -  1 | 001 | 0010
147  -  1 | 001 | 0011

The 1 in the high bit of the high nybble represents that the clock is halted (which it obviously isn’t; not sure what to make of that, unless maybe it’s a write-only register???), the next three bits represent the tens-of-seconds digit, and the lower four bits represent the seconds digit. So this short list here shows seconds 00 – 13.

Higher-Level Timekeeping Functions

In order to be able to interpret the data coming back while testing the read routines, I had already written some functions to parse the time data. I haven’t gone back to test all of them after getting the read working, and I have some cleaning up to do on them anyway. Now that I have a one-digit prototype display working, I think returning to the timekeeping is the next step. Hopefully I can soon integrate the two, so the demo display can show actual seconds information.

LED Clock: Resistor Dispute Continues

Wednesday, July 5th, 2006

Best Hong Kong:

We do preferred to send you $1 to close this dispute. The gift, which is not worth $1 and we did send you the 470ohm resistors already which is perfect for 12VDC power. if you want us to send the extra 220ohm, please close the dispute and we’ll do it.


I don’t know why you describe the resistors as a gift, because they were part of the auction listing, therefore part of the auction. And while they may be worth less than $1 to you, unfortunately it would cost me $6 to replace them from another source, so I don’t think it’s fair for you to describe their value as less than $1. Also, for what it’s worth, I’m not using 12V power, so the wrong resistors you sent don’t do me any good–that’s why I ordered 220-ohm resistors, which are what I need.

I’m trying to be reasonable and work with you to correct the mistake you made when you sent the wrong resistors, but I’m not willing to close the dispute until I receive the right ones. Again, if you do send the 220-ohm resistors, I will happily close the dispute as soon as I receive them.

LED Clock: Disputing Resistors

Tuesday, July 4th, 2006

Here’s Best Hong Kong’s response to the dispute I opened with PayPal about the resistors not being the value I requested:

We can do 2 options. we refund you $1. or close the dispute and we’ll send you again, 100pcs of 220ohm resistors. by air mail. if you want a trackable shipment, you will need to pay $2.30 for registered air mail charge. if you want the resistors, please close the dispute and then email your address & a copy of my msg here. we’ll then send the resistor out in our next shipment. Regards, Ken

My reply:

I definitely want the replacement 220-ohm resistors–that’s exactly what I’m asking for, so thank you for offering.

But PayPal specifically says I can’t close the dispute until I receive the resistors:

“Likewise, if the seller is going to send a replacement item, don’t close the dispute until you have received it.”

So please go ahead and send them. I understand the overseas shipping will take a little while, and that’s okay; also, I don’t think trackable shipping is necessary. As soon as I receive the resistors, I’ll immediately close the dispute and leave you positive feedback on eBay for correcting the mistake promptly and courteously.

And the entire PayPal “Dispute Resolution and Tips” policy I’m citing:

When should I close this dispute?

Wait until you are 100% satisfied that the dispute is fully resolved before closing the dispute. A closed dispute cannot be re-opened or escalated to a PayPal claim, so before you close your dispute you should ensure that your concerns have been fully addressed. For example, if the seller is going to provide a refund, make sure that the funds are in your account before closing the dispute. Likewise, if the seller is going to send a replacement item, don’t close the dispute until you have received it.

Remember, a dispute will automatically close 20 days after the date it was opened. You should escalate a dispute to a claim if you haven’t fully resolved the issue within 20 days.