ontwerpvouwtjes gladstrijken

0 comments on "Real Time Clock modification"

I bought one of those Real Time Clock modules:

I noticed it has a diode and resistor to charge the battery on the back. But I plan on using a non-rechargable CR2032 cell. So these had to be removed:

modified RTC module for non-rechargable battery

I also removed the power LED, since I plan on using it in an alarm clock with a partly translucent enclosure, and I don’t want the light to disturb me at night.

I think these modules mostly get used with primairy (non-recharable) lithium cells, so why was that diode/resistor there in the first place? Charging those cells might lead to leakage (at best), or more spectaculair failure (explosion?) at worst.

If you had battery leakage or other issues with these modules, please let me know in a comment.

If you have one of these DS3231 modules and plan on using it with a standard CR2032 coin cell (non-rechargable), I’d strongly recommend removing the diode and/or resistor, as shown in the pictures above.

EDIT:
I’v measured the 32 kHz output on my 2 modules with a Agilent 34401A. According to the datasheet, this should be 32.768 kHz, typ@3v3. One of my modules outputs 32.763 kHz, the other 32.761 kHz at 3v3. This is 5 resp 7 Hz slow: 153 resp. 213 ppm, way over the specified 3.5ppm over temperature… It would cause me to be late at a rate of about 2 minutes a week. For comparison: my wristwatch does 30 Seconds a Month. So, probably I got out-of-spec or fake modules… Darn!

EDIT2: Those modules get used/sold with rechargeable/secondary cells as well. Makes little sense considering how long a primary cell would last in this application, but at least explains why there is a charger circuit on board.

EDIT3: More about the 32-Khz-out-of-spec problem, in Dutch, here: https://www.circuitsonline.net/forum/view/147354. Also: I’ve bought a known-good chip from Farnell and plan on comparing performance – more later. The chip I bought is a DS3231MZ+ , which has a MEMS-oscillator, not a crystal like the …SN has. So cannot be compared 1-to-1, because its 32 kHz output is not compensated (only the internal 1 Hz is, within 5 ppm.)

0 comments on "USBisp V2.0 to USBasp conversion to use TPI (or: USBisp did not connect to usb anymore after fw update – fixed!)"

Recently I bought an USBasp, or at least that’s what I thought. I bought a clone that was advertised as  “USB ISP USBasp USBisp Programmer for 51 ATMEL AVR download support Win 7 64 (RANDOM COLOR)”, marked on the case as “USB ISP version 2.0” and “MX-USBISP-V5.00” on the PCB.

I intend to use this as a TPI programmer for attiny10, so I need the USBasp firmware that supports this. But it turned out not to be compatible… Unless the hardware is modified 🙂 . (So that’t what I did)

USB isp PCB and case
On the case it is labelled USB ISP version 2.0. On the PCB MX-USBISP-V5.00.

Upgrading the firmware is easy. Connect the 10pin connector to another programmers 10 pin Atmel ISP connector, put a jumper wire on the USBasp “update jumper” (Labelled “UP” in above picture), power the “usbasp-clone”, and load the new firmware using the other programmer. Plenty tutorials for that at various places on the web.

However… Before I updated the firmware, the USBasp was seen by my computer, as an “Atmel Incorporated”. After the update, it did not connect any more. It did not show with “lsusb”, and nothing in “dmesg” either. So, after the update, it does not work any more. I broke it. Let’s see if I can fix it too.

Turns out, the USBisp v2 I bought has a slightly different schematic. Among other differences, there is a 0R resistor on the board that connects one of the USB lines to another MCU pin (PD3). PD3 is unconnected in the original schematic. After removing this resistor, it worked again and connected to my PC as a “Van Ooijen Technische Informatica shared ID for use with libusb”, and it is usable with AVRdude as an USBasp (I tested reading an attiny10’s flash, and it worked).

Before that, I tried other modifications that might be needed also, but that by themselves had no effect. The other differences where that my board had a 1k8 pull-up on the USB D- line (R3 in original schematic), and R1/R2 where 100 Ohms instead of 68. So I replaced those resistors with the original values, just in case, but I think it would have worked with 1k8 / 100R.

Also I cut the trace from PD6 to one of the LED pins, as that connection is also not in the original schematic.  And while I was at it, I added a decoupling cap on a vacant spot on the PCB and soldered the mechanical pins on the USB connector.

After all these modifications, it looks like this:

modified USPisp
Modified USBisp

Zoom in to see the red dots marking changed components and the red line indicating the trace I cut.

So now, I have a TPI programmer for my Attiny10’s. And if you bought the same or a similar enough USBisp or USBasp and ran into the same issue putting USBasp firmware on it, now you know how to fix it 🙂 (See first picture for PCB & case markings).

0 comments on "RFID Deel 2 (Of: enkele losse eindjes)"

In aanvulling op Opgelost: RC522 RFID lezer leest (sommige) kaarten niet. (Deel 1):

Eigenlijk heb ik een groot deel van wat ik van plan was in deel 2 te schrijven, toch al in deel 1 verwerkt. Er zijn echter een paar “losse eindjes”.

Van de blauwe kaartlezers uit deel 1 bestaan vele varianten (ook in andere kleuren, maar ik doel vooral op de pcb-antenne). Er bestaan echter ook kaartlezers met dezelfde chip, die via I2C communiceren (ipv. SPI). Bijvoorbeeld onderstaande groene:

RC522 I2C
Groene mini RC522-I2C RFID lezer

Ik heb daarvoor de bestaande SPI-library aangepast: https://github.com/lukelectro/rfid/tree/I2Csupport . Er zijn meerdere (en andere) I2C RFID library’s voor deze chip, daar kwam ik echter pas later achter. Het blijft een leuke oefening in OO-programmeren (Mede om die reden heb ik overerving gebruikt. Het had eenvoudiger gekund door de bestaande library te slopen en deels opnieuw te schrijven, maar dan voor I2C. Of nog beter: door communicatie met de kaartlezer te scheiden van de rest van de library en mogelijkheden te maken voor I2C, SPI en UART.).

Deze groene kaartlezer werkt erg goed. Uiteraard, geen enkele garantie dat als je er nu een (aantal) besteld, je dezelfde krijgt als waar ik mee getest heb, waarschijnlijk bestaan er ook meerdere varianten van.

Verder was ik ooit van plan nog wat meetgegevens te posten van de “blauwe” kaartlezers, maar daar zie ik denk ik maar van af. (Ik zou dan moeten uitzoeken welke meting ook al weer waar bij hoorde, plus dat er dusdanig veel varianten van deze lezer zijn dat je eigenlijk zelf zou moeten meten als het niet werkt met de condensatorwaarden die ik eerder postte. Bovendien, en dat is wellicht het belangrijkste argument: Ik werkte toen voor het eerst met een VNA en zou dus zomaar eens meetfouten gemaakt kunnen hebben). Mocht het je echter toch interesseren, vraag dan gerust in de reacties.