I have an alcove where I wanted to put in some floating shelves. I wanted to use some solid wood I had lying around, to match the rest of the interior; this ruled out most of the methods described online: (i) building up the shelf around a bracket, and (ii) using hidden mounting hardware would be hard to get precise and would not provide support on the sides.
So inspired by some of the options instead I tried to get by with just brackets on the three sides, in a solid wood shelf. I ended up with 12mm brackets of plywood in a 26mm solid wood shelf, and that was plenty sturdy.
Step 1 was to cut out the rough shelves, with plenty of extra width, and rough fitting the plywood bracket pieces. It makes sense to leave as much on the top of the slit as possible, as this will be the failure point if overloaded. The excellent wood workshop at Hal9k came in very handy!
Step 2 was to mount the plywood brackets in the alcove. Pretty easy to do using a laser level, biggest problem was getting the rawplugs in precise enough for the level to be kept.
Finally, all the shelves in final mounting. Getting them in took a bit of persuasion with a hammer, and minor adjustments with a knife to the plywood brackets, as it was a tight fit. The key again was small adjustments.
One concern with such a tight fit would be wood movement; however most of the wood movement is “across the grain” which in this application means “in and out” from the alcove, where the wood is basically free to move as the shelves are not fastened to the brackets in any way.
Another concern would be if the relatively small brackets (12x12mm) can handle the load of the relatively wide shelves (60cm wide, 35cm deep, and 2.6cm high). There are two failure scenarios: (i) the wood could split above the slit, (ii) or the bracket could deform or be pulled out. Neither seems likely as (i) applying a static (or even dynamic) load large enough to split the wood seems implausible, even at the weakest point in the middle of the front, and (ii) the tight fit counteracts the brackets ability to be pulled out since pulling out in one side would have the shelf hitting the wall on the opposite side.
All in all a very satisfying project to work on and complete!
4 years ago I posted a 4 year review of the Olimex LIME2. It seems that the lifetime of power supplies is approximately 4 years as now another power supply died, and this time also the SD-card was expiring. The LIME2 lives on however!
It was a bit hard to notice, because the battery pack of the LIME2 kept it running pretty well even with the poor power supply. So, better monitoring of the battery pack is also on the todo list.
Recovering the bad SD-card
Recovering the SD-card was relatively easy with minimal dataloss, when out of the LIME2:
$ sudo ddrescue /dev/mmcblk0 backup.img
# Put in a new SD-card
$ sudo dd if=backup.img of=/dev/mmcblk0 bs=16M
I have done this a couple of times with other SD-cards from Raspberry PIs, and though there is the potential for dataloss it is usually minimal. This time a few blocks were lost.
Upgrading Debian from Stretch to Bullseye
I took the opportunity to upgrade the Debian install while the system was offline anyway. Upgrading was generally painless, following the usual Debian method. I went through the Buster release just to be sure:
$ vim /etc/apt/sources.list
# replace all "stretch" with "buster" :%s/stretch/buster
$ apt update && apt upgrade && apt full-upgrade
$ reboot
$ vim /etc/apt/sources.list
# replace all "buster" with "bullseye" :%s/buster/bullseye
$ apt update && apt upgrade && apt full-upgrade
$ reboot
The only tricky part is booting the new kernel. Since that always fails for me on the first try, I always hookup the serial console. For future reference, this is how to hookup the serial console:
Pinout from left as labelled on the LIME2: TX, RX, GND
Now, of course the boot failed. I tried getting the flash-kernel package to work for my setup, but for historical reasons I have a separate boot partition. In the end I derived a simple bootscript from that package, that boots from p1 but loads the kernel, fdt and initrd from p2:
The script can be manually input over the serial terminal, and thereby tested out.
The only downside is it needs to be manually updated after each kernel upgrade. To activate the uboot bootscript:
$ mount /dev/mmcblk0p1 /mnt/
$ cd /mnt
# ensure boot.cmd is as above
$ mkimage -C none -A arm -T script -d boot.cmd boot.scr
Monitoring the LIME2 battery pack
After upgrading to a recent 5.X mainline Linux kernel the battery pack is exposed in the sysfs filesystem:
$ cat /sys/class/power_supply/axp20x-battery/voltage_now
4070000 # 4.07 V
$ cat /sys/class/power_supply/axp20x-ac/voltage_now
4933000 # 4.93 V
I setup a couple of alerting rules for these in my home monitoring setup, so hopefully the next time the LIME2 defeats a power supply I’ll get notified.
Conclusion
I can still warmly recommend the LIME2. It is still available, and even a bit cheaper nowadays at 40 EUR + VAT, and still a little workhorse that just keeps on going.
Som med så mange andre huse fulgte der en Grundfos Alpha 2 cirkulationspumpe med da vi købte et hus. Den pumpede og pumpede, indtil den var blevet 13 år gammel: så begyndte den at flimre når den skulle starte op. Det er jo som sådan en rimelig hæderlig levetid, men også lidt mistænkeligt at det ikke virkede til at være et mekanisk problem.
Flimmer, men ingen pumpning.
Symptomerne er:
Pumpen kan køre fint i længere tid
Ved længere tids stop kan den ikke starte; nogen gange starter den efter noget tid
Ved opvarmning starter pumpen, f.x. med en varmepistol
Det er dog ikke problemet. Problemet er en lille kondensator der holder strøm til lavspændingselektronikken:
47 uF 16 V kondensatoren er problemet.
I Hal9k eksperimenterede vi en smule for at verificere: hvis man køler den ned med f.x. sprit opstår problemet med det samme. Hvis man varmer den op starter pumpen med det samme.
For en udførlig vejledning i hvordan pumpen skilles ad og kondensatoren skiftes har Simon lavet en video:
Men hvad er kilden til problemet så? Kondensatoren får over tid en alt for stor indre modstand, og spændingstabet bliver for stort. Her et par målinger uden og med lidt sprit til ekstra afkøling:
Med sprit
En helt ny kondensator måler under 1 ohms modstand, altså 100 gange så lille indre modstand:
En ny kondensator kan findes ved at søge på “47 uf 16 v smd electrolytic capacitor”, f.x. TME.eu, eller endnu mere lokalt fra el-supply.dk.
Efter erstatning pumper pumpen lystigt.
Så hvad kan man lære af hele denne historie? Grundfos laver mekanisk gode pumper, men sparer på deres elektronik. Det er trist at tænke på hvor mange pumper der mon er smidt ud lang tid før tid. Man kan nok ikke beskylde Grundfos for “planned obsolence” efter 13 år, men man kunne dog ønske at produktet fejlede i en mere brugbar konfiguration: f.x. at pumpen kører ved et minimum hvis elektronikken fejler.
I have a Philips Hue gateway at home that is connected to a number of Philips Hue lights, as well as some IKEA trådfri light bulbs, and a couple of OSRAM Lightify light strips. Most of the time the network works quite well, but some of the time a few of the lights become unreachable. I read a rumor online that the Hue lights and the other lights are actually on two different Zigbee networks. Of course, if only I had a way of sniffing the Zigbee traffic I could diagnose these problems. And thus began this quest.
USB TI CC2531 Zigbee sniffer dongle.
I started by buying a Zigbee sniffer, I found that the Texas Instruments CC2531 chip is widely used, and available in a cheap USB package. I purchased this USB CC2531 Zigbee sniffer, but others are probably equally good. After the dongle arrived I spent quite a while thinking that I need to replace the stock firmware, because of various old projects on GitHub (Sensniff, ccsniffpiper, etc.). Fortunately, you do not need to change the stock firmware. The best software package seems to be KillerBee which supports both sniffing and injection; however only sniffing with the CC2531. Installing KillerBee on Ubuntu is quite easy. You need to install scapy, and a few dependencies. The installation instructions are probably more up to date than this blog post.
Starting the sniffing is really easy, if you know the channel the Philips Hue is operating at. I think channel 11 is the default, but it is displayed in the Hue app, under info for the bridge:
sudo zbwireshark -c 11
This will launch a background process, and an instance of Wireshark that is monitoring the channel. At this point you can see the traffic; but everything is encrypted…
Encryption… Encryption everywhere!
A very incomplete intro to Zigbee encryption
Zigbee traffic can be encrypted with AES-128, which is a symmetric encryption scheme. This means the key to encrypt and decrypt is the same. There is a number of keys that can be used to encrypt a single packet payload:
The Network Key, which is unique to this Zigbee network. This is what we will ultimately need to find. It is generated by the gateway, and shared by all the devices on the network. How does a new device join the network then? It uses the…
The Key-Transport Key which is a pre-shared secret. Apparently there is a number of these, depending on the class of devices and type of network. These are apparently a well-kept secret or something, although widely available on the internet:
You can add these keys to Wireshark, and the Zigbee dissector will then try to decrypt traffic using them. Go to Edit -> Preferences -> Protocols -> ZigBee and edit the pre-configured keys:
The Key-Transport Key is used whenever a new device joins the network with the sole purpose of encrypting the network key. So, to find the network key we need to know the Key-Transport Key, and observe the traffic when a device joins. So this is what I did: I found an IKEA Trådfri lightbulb and spent the frustrating time needed to get it to join the Philips Hue gateway (resetting the bulb, searching for new lights). Finally, it suceeded!
Hitting gold!
Now, by adding the transport key to the list of keys in Wireshark all the traffic on the network was able to be decrypted!
Decrypted traffic
The next step will be to analyze the traffic, and understand the routing. Very initial probes using zigbee-viewer indicates that there is indeed three distinct routings:
Vi har en fin moderne brændeovn derhjemme (en Aduro 1-2), som vi bruger ret intensivt til opvarmning af vores gamle stuehus. Et meget relevant spørgsmål er derfor: hvor meget bidrager sådan en moderne brændeovn til partikelforureningen i vores stue?
Partikelforurening er små partikler af støv og sod, der bl.a. fremkommer ved afbrænding af fossile brændsler, som olie og træ. De kan forårsage forskellige slags sundhedsproblemer, bl.a. kræft. På et interaktivt partikelkort kan man se hvilke niveauer der (beregnet) var i Danmark i 2012, og f.x. forskellen mellem land og by; årsgennemsnittet for PM2.5 lå på 5.3 – 11.9 μg/m3.
Det er et ganske egoistisk projekt jeg har gang i: jeg har ingen data for hvor stor partikelforureningen er udenfor huset, men kun inde i selve stuen. Der er en del kilder til partikelforurening som jeg kender til, eller har observeret:
Vi har et pillefyr, der står i nærheden, der også kører i den kolde tid
Vi bor i kort afstand fra en lettere befærdet vej
Madlavning, specielt med en gammel emhætte, kan bidrage betydeligt
Den generelle baggrundsvariation kan være betydelig
For at undersøge det har jeg opsat en partikel sensor (en Honeywell HPMA-1150S0) i stuen, ca. 3 m fra brændeovnen. Samtidig registrerer jeg brændeovnens temperatur, via en Aduro Smart Response sensor. Dette har jeg nu gjort i lidt over et år, og kan dermed lave en data analyse på et års data.
Til brug for analysen er der registreret PM10 og PM2.5 værdier, ifølge databladet i μg/m3. Sensoren skulle desuden være “fully calibrated”, og kunne køre i mindst 20.000 timer, så et års data burde man kunne stole på. Usikkerheden er dog angivet til +/- 15 μg/m3, eller +/-15% alt efter målingen; i praksis virker den dog til at være ret stabil i værdierne. Sensoren beregner PM10 værdier ud fra PM2.5 værdier, så jeg vil primært fokusere på analyse af PM2.5 værdierne. Data er optaget med et interval på 5 minutter, men med sensor læsninger ca. hvert 6 sekund der så er aggregeret ved gennemsnit (Der er brugt HPMA-1150S0 sensorens “auto-send”).
Sensoren opfanger partikler mindre end 2.5 μg med en laser.
Brændeovnens temperatur er målt som foreskrevet af Aduro Smart Response, dvs. i den øvre del af brændkammeret på vej mod røgrøret. Aduro sensoren sender data i ca. 4 timer. Jeg har defineret at brændeovnen er i brug, hvis temperaturen er registreret, dvs. afkøling også er talt med.
Data der er opsamlet er bl.a. PM10, PM2.5, brændeovnens temperatur, og strømforbrug på de 3 faser.
Vi bruger vores brændeovn en hel del i de kolde måneder. Faktisk helt op til halvdelen af tiden:
Det passer meget godt med at vi bruger brændeovnen næsten alt tid vi er hjemme, i de kolde måneder.
Vi tænder op efter forskrifterne og bedste evne; genindfyring sker typisk ved 175C eller 150C ved at lægge 2-3 stykker brænde ind, og åbne spjældet (der så ved Adurotronic lukker over ca. 6 minutter). Der er naturligvis stor variation i præcis hvornår der lige bliver genindfyret. Og en sjælden gang imellem glipper optændingen, og giver røg i stuen. Men generelt opleves fyringen som ganske uproblematisk.
Gennem året har jeg lavet lidt observationer, og min subjektive vurdering for partikelforureningen er ca.:
Der er normalt meget lille partikelforurening, 2-3 μg/m3
Ved god optænding stiger forureningen med 1-2 μg/m3
I nogle perioder er baggrundsforureningen højere, lige under 20 μg/m3
Ved uheldig opførsel stiger partikelforureningen drastisk – helt op til 900 μg/m3; det kan f.x. være ved dårlig optænding, eller ved madlavning.
Uheldig optænding.
Uheldig baconstegning.
Målinger
PM2.5 koncentrationer, ifht. årets måneder.
Som det kan ses er der en del variation imellem månederne. Der er også en hel del outliers, der trækker gennemsnittet op, mens medianen for alle måneder ligger under 5 μg/m3.
Mere interessant er det om partikelforureningen påvirkes af brændeovnens temperatur, og dermed dens brug. Det ser det bestemt ud til! Selvom median værdierne ikke stiger meget stiger specielt 3. kvartil. Gennemsnitsværdierne stiger også, helt op til 12.37 μg/m3 for intervallet [250, 300). En tolkning af dette kunne være at der normalt (median) ikke er ret meget mere partikelforurening, men det sker hyppigere at der er store koncentrationer til stede.
Det bør noteres at der ikke er særlig mange målinger over 350C, som det kan ses af histogrammet for hvilke brændeovnstemperaturer der er registreret:
Fejlkilder
Der er et par fejlkilder i målingerne:
Der mangler en uges data i september, hvor en strømforsyning stod af mens vi var på ferie.
Partikelsensoren giver nogle meget højere målinger i et enkelt punkt, engang imellem. Checksummen fra sensoren ser ud til at passe, så hvad præcist problemet er ved jeg ikke. Jeg har først filtreret åbenlyst forkerte målinger (<0 eller >1000) fra i databehandlingen, men pga. gennemsnittet over de 5 min kan nogle åbenlyst forkerte målinger stadig være talt med.
Brændeovnssensor har nok manglet batteri en dag eller to, det kan jeg ikke helt huske.
Analyse
PM2.5
Årligt gennemsnit
5.44 μg/m3
– Årligt gennemsnit, brændeovn i brug
9.28 μg/m3
– Årligt gennemsnit, brændeovn ikke i brug
4.49 μg/m3
Alle værdier er under EU’s grænseværdi, på 25 μg/m3 PM2.5. Hvis vi antager at målingerne mens brændeovnen ikke er i brug er repræsentative for hele året, så har brændeovnen bidraget med 0.95 μg/m3 PM2.5 til års gennemsnittet.
For småkornet luftforurening [PM2.5] stiger risikoen for lungekræft med 18 procent per fem ekstra mikrogram svævestøv, men det resultat var ikke statistisk signifikant. Det var alle resultaterne for risikostigning under det tilladte niveau heller ikke.
Hvis vi antager at det resultat holder, og at virkningen er lineær, vil den øgede forurening på 0.95 μg/m3 PM2.5 øge risikoen for lungekræft med 3.42%.
Enkeltstående tilfælde
Et andet problem kunne være hvis enkeltstående tilfælde af høj luftforurening var specielt sundhedsskadeligt, som indikeret af at EU for PM10 også har en daglig grænseværdi (50 μg/m3), og et antal tilladte overskridelser per år (35). Der er 0 dage hvor den daglige PM10 grænseværdi har været overskredet. Jeg har alligevel analyseret de 35 dage med det højeste gennemsnit, og forsøgt at klassificere de årsager (primær og sekundære) til de høje værdier. Det har jeg gjort ved at kigge på brændeovnstemperaturen, strømforbruget, tidspunket på dagen, osv. Disse tal må derfor siges at være min subjektive vurdering.
Primær årsag
Sekundær årsag
Madlavning
19
3
Baggrund
11
1
Brændeovn
3
15
Ukendt
2
0
De primære årsager til høje målinger ser ud til at være madlaving og baggrund, mens brændeovnen bidrager til halvdelen af de høje dagsgennemsnit.
Konklusion
Vores moderne brændeovn bidrager med 0.95 μg/m3 PM2.5 til års gennemsnittet, og øger dermed vores risiko for lungekræft med 3.42%. Hvis vi f.x. flyttede til en større by som København ville vi opleve en væsentlig højere forøgelse til måske 10 μg/m3, ifølge modelberegningen, hvilket ville øge risikoen for lungekræft med 16%.
Hvis man ser på PM2.5 koncentrationer ifht. brændeovnens temperatur, ser det ud til at brændeovnen for det meste (målt på medianen) ikke udleder ret mange partikler, men bidrager til at høje forureningskoncentrationer optræder oftere (som set på de øgede gennemsnitsværdier, og forøgede 3. kvartil).
Brændeovnen bidrager til 18 af de 35 højeste dagsmålinger, mens de primære årsager til høje dagsmålinger er madlavning og baggrundsforurening.
Hal9k er Aalborgs hackerspace. Et åbent højteknologisk værksted, hvor man kan lave (næsten) alt. Udover en masse forskellige værksteder, oser Hal9k af viden, kreativitet og varmt socialt fælleskab.
Alle der kommer i vores lokaler risikerer at lære en masse, og ikke mindst få nogle gode oplevelser.
Der er fast klubaften hver torsdag fra kl. 19 til ud på aftenen, hvor alle er velkomne til at kigge forbi!
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here:
Cookie Policy
20 feb
0 Comments