2019

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.)

MainsSensor is een klein printje dat gebruikt kan worden om te monitoren of iets nog “aan staat” , bedoeld om in de MakerSpace bij de deur een reminder te geven als je als laatste weg gaat en b.v. de compressor staat nog aan. (Of een van de andere apparaten die uit moeten, b.v. ook de ruime kilowatt aan verlichting).

Voor wie niet de hele zooi wil lezen, staat onderaan een demonstratiefilmpje.

Het printje bevat een attiny10 en een 433 MHz zendertje. (Vanwege die Attiny10 was ik vorige post dus met een usbasp bezig, de AVR dragon kan geen TPI).

Als het printje voeding krijgt, stuurt het via 433 MHz een bericht met een uniek ID en de status “aan”. Dit bericht wordt af en toe (elke 30 seconden) herhaalt: “ik ben er nog”. (Het HI-bericht).

Als de voeding wegvalt, wordt hetzelfde ID verzonden, met de status “uit”. (Het BYE-bericht). Dit BYE-bericht wordt direct enkele malen herhaald, tot de bufferelco leeg is.

Wat ik leuke aspecten van het mainssensorproject vond:

  • MainsSensor wordt rechtreeks uit het lichtnet gevoed*, via een seriecondensator. Voeding uit 12VDC is ook mogelijk.
  • MainsSensor moet een bericht versturen als de voeding nèt is weggevallen.
  • Het moet compact (Om er nog bij te passen in de bestaande behuizing van eender welk apparaat), dus:
    • de antenne voor de 433 MHz zender zit op de print ge-etst.
    • Spelen met een attiny10 in SOT23-5 (microcontroller, indeed! Dat ding is klein.)

Het schema en de software staan op github.

C1 is de seriecondensator, 47nF / 630VDC X7R in 1210 behuizing. Deze begrenst de stroom op ongeveer 3,2 mA. (Dergelijke ceramische SMD condensators in andere waarden worden ook toegepast als seriecondensator in ledlampen, lekker compact.) (In deze discussie op circuitsonline.net wordt over een dergelijke schakeling gefilosofeerd). R8 van 1k beperkt de inschakelstroom (en eventuele kortsluitstroom mocht C1 falen), en omdat dit een flameproof / fusible weerstand is fungeert deze ook als zekering.

Met die 3 mA wordt de bufferelco C2 geladen, waaruit de 433 MHz module wordt gevoed. Met een 12V zenerdiode D3  wordt de spanning begrenst op 12V. (De stroom verdeeld zich in de laadstroom voor de bufferelco, het gebruik van de schakeling, en de zenerdiode. Als de schakeling de 3 mA niet opmaakt, zal de bufferelco opladen tot de 12V bereikt is, daarboven gaat de zenerdiode geleiden). Via R6 en 5V zener D4 wordt 5V gemaakt voor de microcontroller.

Vòòr C2 zit D2, zodat vòòr D2 gemeten kan worden of de voeding wegvalt, zonder dat de bufferelco eerst leeg moet zijn om hier geen spanning meer te meten. Die buffer is immers nog nodig om de schakeling te voeden om een “uit”  bericht te sturen. C4 vlakt de te meten spanning af, R7 is hiervoor de belasting zodat C4 ontladen wordt als de voeding wegvalt. R3/R4 zijn een spanningsdeler.

C3 is 10 uF ceramisch, dicht bij de microcontroller als ontkoppeling, en tevens als buffer na R6. (Anders zou er een elcotje na R6 over D4 gestaan hebben, en 100nF ceramisch naast de micro – 10u ceramisch is compacter).

Voor het berekenen van de bufferelco is een schatting gemaakt: er is van uitgegaan dat het versturen van een bericht 1/40 s  duurt en 30 mA gebruikt. De bufferelco mag daarbij maximaal iets van 3 V dalen en moet dus minimaal I*dt/dV = 334  uF zijn. Om meerdere berichten te kunnen versturen en de tolerantie van een elco op te vangen is er 1000 uF geplaatst. In de praktijk voldoet dit uitstekend, ook al wijkt de daadwerkelijke tijdsduur en het stroomgebruik af van de inschatting, het goodbye-bericht kan ruim 2 seconden lang herhaalt verstuurd worden. (In het stadium van het project dat ik deze schatting maakte, noemde ik het nog MainsSpy en dacht ik nog Hamming(7,4) encoding toe te passen. Zie whiteboardfoto. Maar omdat het doel juist geen big-brother-robotnanny-spionage is maar een hulpje om dingen uit te zetten, heb ik het hernoemd naar MainsSensor. En forward error correction is hier niet nodig, dus geen Hamming(7,4). )

whiteboard-geklad uit een vroeg projectstadium, o.a. buffer elco inschatting
Buffer inschatting en andere projectnotities, uit een vroeg stadium van het project.

Dan de PCB antenne. Hiervoor heb ik me gebaseerd op een appnote van Murata (AN0036). Ik heb 2 PCB ontwerpen gemaakt, bij de eerste poging (rode printjes, V1.0) was de antenne veel te lang. Dat liet zich goed meten met de VNA (VNAart :)). Van de rode printjes met te lange antenne kan deze worden ingekort door het printspoor door te krassen, waarna opnieuw met de VNA gemeten kan worden wat de antenne-eigenschappen geworden zijn. De antenne van de gele printjes (v1.1) is ook iets te lang, maar minder dramatisch.

De meetresultaten variëren van exemplaar tot exemplaar, waarbij ook de veranderende eigenschappen van de veranderende meetopstelling meespelen, maar rekening houdend met dat voorbehoud: de antenne van de rode printjes resoneert op ongeveer 334 MHz, de SWR is daar ongeveer 3,9:1. Op 433 MHz is de SWR ongeveer 13:1. (meting 190609 153659). Met het inkorten van de PCB antenne op het rode printje wordt deze veel gevoeliger voor andere objecten in de buurt, maar kan deze bijvoorbeeld (meting 190609 155321) uitkomen op een resonantiefrequentie van 442 MHz met een SWR van 1,8:1 – de SWR op 433 MHz was ongeveer 2:1.

De nieuwe gele V1.1 printjes hebben (meting 190702 190935) een antenne met een resonantiefrequentie van 449 MHz, de SWR is daar ongeveer 2,5 :1. Op 434 MHz is de SWR ongeveer 4:1. Dat is dus stukken beter dan de 13:1 van een ongemodificeerd rood printje.

Verder bleek bij het schrijven van de software dat 32 bytes RAM toch wat weinig is. Het ID in ram werdt overschreven in de interrupt routine (ISR). Daardoor werdt ook dit aspect van het project interessanter dan voorheen gedacht.

Oorspronkelijk stond het ID hardcoded en was vrijwel alles al bekend bij compile time. Omdat de attiny10 zuinig moet zijn, loopt deze op een trage (128 kHz) klok. Tijdens het verzenden van een bericht beslissingen maken zou de timing verstoren, dus het te versturen bericht werdt tevoren in ram klaargezet. Er worden HI-berichten verstuurd zolang de sensor (en het apparaat) aan staat, en BYE-berichten als het apparaat (en de sensor) wordt uitgezet.

Later is een crc toegevoegd, waardoor er wat meer ram gebruikt wordt, hetgeen ertoe leidde dat de stack het ram in groeide bij de context switch bij de (pin change) interrupt die gebruikt wordt om te meten of de voeding is weggevallen, met dus als gevolg het overschrijven van de variabele met het uit-te-zenden bericht.

Omdat het niet erg is als de microcontroller reset en opnieuw begint bij het terugkomen van de spanning, heb ik ervoor gekozen de ISR zonder context save / restore uit te voeren (“naked” ISR). Om de microcontroller gegarandeerd te resetten, ook als de voeding terugkomt voordat de bufferelco leeg is, wordt bij het ingaan van de ISR de watchdog timer (WDT) op 2 seconden ingesteld. Zodoende wordt de microcontroller 2 seconden later gereset. Er is dus geen context restore en return from interrupt. Dit scheelt 13 bytes ram (van de 32).

De software aan de ontvangstkant is onder te verdelen in een aantal lagen:

  • De ontvangstlaag (datalinklaag)
  • De verwerkingslaag (Applicatielaag)
  • De presentatielaag

De ontvangslaag verwerkt de ontvangen bits tot berichten, die doorgegeven worden aan de verwerkingslaag. De verwerkingslaag slaat de ID’ s en de status van de ontvangen sensoren op. De presentatielaag haalt hier de naam van het apparaat bij en toont deze informatie.

De ontvangstlaag is een state-machine rond een timer-interrupt die de ingang polled om de startconditie van een bericht te detecteren. Eenmaal een startconditie gevonden, wordt een pin-change interrupt gebruikt om de rest van het bericht binnen te halen.

De verwerkingslaag slaat het ID op, en houdt bij welke apparaten nog aan staan d.m.v. een timestamp en de BYE-berichten. Als een apparaat zich niet afmeld met een BYE-bericht wordt het als “uit” beschouwd als er  enige tijd (anderhalve minuut) geen HI-berichten meer ontvangen zijn.

De presentatielaag geeft de informatie over wat er nog aan staat weer via een seriële verbinding en op een LCD. Op het LCD worden ook de ingestelde namen van apparaten getoond. De naam/ID koppeling wordt opgeslagen in het EEPROM van de atmega328.

De code van zowel de zenderkant als de ontvangstkant is ruimschoots voorzien van commentaar, dus bij verdere interesse in de werking: kijk op github.

Voor wie geïnteresseerd is in de berichtstructuur, is deze op de MakerSpace Wiki  gedocumenteerd. Ook alle andere documentatie staat daar.

Mocht het hierboven ingesloten filmpje niet laden is hier de link naar youtube.
En voor wie verder nog vragen of opmerkingen heeft, is onder deze blogpost een reactiemogelijkheid 🙂

*) De bijna verplichte waarschuwing: Let er dus op, mocht je dit nabouwen, dat de hele schakeling met het lichtnet verbonden is. De 5 VDC voor de microcontroller is dus, ten opzichte van aarde, nog steeds 230 VAC. Er is geen isolatie, en als je de “5V” zou aanraken, raak je 230 V aan. Niet doen dus. (Ditzelfde geldt voor de 12V).

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).

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.

In “Show Your Projects” op CircuitsOnline.net heb ik dit project al eerder getoond, maar het is ook wel een blogpost waard denk ik. Al is een blog natuurlijk eigenlijk bedoeld om te mekkeren over dingen als een gebroken arm wegens een onoplettende automobilist*, maar ook dàt had ik al op CO geuit. Blijft dus over om hier het schema van de jongleerkubussen te posten, en wellicht te linken naar de software en de files die je nodig hebt om de behuizing te printen. Zodat alles mooi bij elkaar is.

En aangezien al die benodigde informatie al gelinkt is in bovenstaande, blijft de rest van deze blogpost over voor meer foto’s.

Want als u zo ver gelezen heeft als dit vraagt u zich allicht af hoe een “RGB jongleerkubus” er nu uit ziet, wat je er aan hebt, en/of hoe ik op het maffe idee ben gekomen ze te maken. Al weet u dus alvast waarom een verdere jongleerdemonstratie in foto of videovorm wat langer op zich zal laten wachten. [sensuurbliep] automobiprutser*! (bovenstaande jongleerfoto’s zijn uiteraard van eerder datum. Plan was eigenlijk voor m’n blog wat foto’s te maken met de MakerSpace als sfeervolle achtergrond, ipv mijn kast. Ja, die muur is geel, nee, dat ligt niet aan de foto. Ja ik kan met 1 hand tikken :). )

Om te beginnen met waarom: ik wilde een step-up led-driver maken, om iets te doen met RGB leds op een 3,7V lithiumcel waarbij ook blauw en groen fatsoenlijk stroombegrenst zijn. En daarmee gelijk de hardware van de stm32f030 beter leren kennen.

Een simpel serieweerstandje bij een blauwe led gaat het niet redden, als de stroom constant moet zijn: de accu kan variëren tussen de 4,2 V wanneer vol en de 3,0 V wanneer helemaal leeg. De spanningsval over de led is b.v. 3,2 V bij 20 mA. De weerstand zou dan 1 V / 20 mA moeten zijn als de accu vol is, oftewel 50 Ohm. De weerstand bij lege accu zou -0,2 V / 20 mA moeten zijn… Dus negatief 10 Ohm. En dan nog keurig mee variëren met de accuspanning ook… Da’s wel een heel bijzondere weerstand… vandaar de wens voor een step-up leddriver. Met enkele LED’s in serie blijven ze op 4,2V dan gewoon uit omdat de gezamenlijke drempelspanning hoger is, en kunnen ze mooi in stroom geregeld worden met een step-up met terugkoppeling over een serieweerstandje – zie schema.

En RGB leds zijn leuk, maar bewegende RGB leds zijn nog leuker. Verder kan ik een klein beetje jongleren. Dus, vandaar de jongleerbal. Of jongleerkubus. Want dat lijkt makkelijker stevig te printen te zijn, omdat er een boutje in alle 4 de hoeken kan. Een ronde doorzichtige bal uit 2 helften stevig dicht krijgen is een beetje een uitdaging. Die ik uit de weg ben gegaan.

Er zit verder een adxl345 accelerometer in, om het ding te kunnen laten verkleuren op moment dat ‘ie gevangen wordt. Gewoon constant verkleuren kan ook: de “tap” detectie van de adxl wordt gebruikt om van modus te wisselen. Zie software 🙂 En Schema :).

Wat je er aan hebt is dus dat je ermee kunt jongleren. Wat met een lange sluitertijd mooie foto’s oplevert. Al dan niet met 2e-gordijn flits.


Natuurlijk zijn er ook wat uitdagingen, b.v. m.b.t de valbestendigheid. Het blijkt echt nodig de behuizing stevig dicht te schroeven. Als de helften t.o.v. elkaar kunnen schuiven, b.v. omdat in de prototypefase de boel met een elastiekje dicht zit ipv 4 boutjes, schuiven zo de elco’s en spoeltjes van de print af:

Er zijn meer technische uitdagingen geweest in dit project, zoals zwevende ingangen die het stroomverbruik in sleep erg verhogen. Makkelijk te testen op breadboard met weerstandsarrays als externe pull-up:


En zoal wellicht een beetje terug te zien in mijn vorige post: “lol met wireless power transfer” heb ik overwogen de jongleerkubussen inductief te laden. Maar daar omwille van de eenvoud vanaf gezien. Laden via de schroefjes is betrouwbaarder stabiel te krijgen.

Wie geïnteresseerd is in technische details wil ik graag uitnodigen vragen te stellen als comment, dan kan ik daar wellicht weer wat leuks over schrijven. Dit was een meerjarenproject, met allerlei afleiding tussendoor, en om te voorkomen dat de blogpost over het project zelf ook erg lang wordt laat ik het er voor nu even bij.


voetnoot: (armnoot?)
*(die nog minstens zolang ik in het gips zit af en toe op dergelijk humoristische wijze genadeloos te pas en te onpas erbij gesleept zal worden als voorbeeld van hoe het níet moet… Vooral omdat ‘ie is doorgereden vind ik het een [censuurbliep]. Nou kan ík niet door met míjn rijlessen omdat die anonieme prutser er goed aan zou doen er een paar lessen bij te nemen…Ik kan/mag niet eens fietsen! Of jongleren! Neem dan je verantwoordelijkheid en stap uit/oepssorryhulpverleenverzekeringsgegevens… Nouja. dat dus. Kan ik toch nog mekkeren op mijn blog 😛 Ben ik stiekem best goed in.)