Paweł Szabaciuk - Software Developer

Paweł Szabaciuk

Software Developer

Honda Hornet zmiana przedniej zębatki.

Dzisiaj nadszedł czas zmiany zębatki przedniej w Hondzie Hornet PC36 2004 rok.
Moto po jednym sezonie wymagało napięcia łańcucha. Dokładnie o 0.5 podziałki na wachaczu. Ponieważ pierwsza zużywa się przednia zębatka i to zużycie odpowiada głównie za niszczenie zestawu napędowego, najprościej po prostu ją zmieniać jak się zużyje.
Zmiana ta jest banalanie prosta.
Zaczynamy od ściągnięcia osłony zębatki. Następnie luzujemy śrubę na zębatce. Powinno pójść prosto, w końcu moment dokręcenia to tylko 54 N-m. Najprościej to zapiąć bieg, postawić kogoś na hamulcu tylnim ( albo samemu jak mamy za długie ręce ) i odkręcamy śrubę.
Po tej opracji, stawiamy tył na stojaku, luzujemy naciąg łańcucha, luzujemy nakrętkę tylnej osi. Wyciągamy łańcuch przez przednią zębatkę i ściągamy ją wałka.

Tak wygląda stara zębatka:

Tak wygląda nowa:

Stara i nowa:

I z bliska:

Wszystko widać, tłumaczenia są zbędne.
Zakładamy zębatkę na wałek, czyścimy podkładkę i śrubę, wkręcamy śrubę w wałek.
Następnie wstępnie napinamy łańcuch i dokręcamy śrubę. Dla mojego moto właściwy moment to 54 N-m. Robimy to odwrotnie do odkręcania, więc najprościej przy użyciu tylnego hamulca.
Na koniec regulujemy napięcie łańcucha – dla mojego moto właściwy luz to 30-40mm, więc ustawiam go w połowie. Póki moto jest na stojaku, smarujemy łańcuch. Na koniec zestawiamy ze stojaka i dokręcamy tylną oś. U mnie – 88 N-m.

Sterowanie pompą obiegową od cyrkulacji

Dzisiaj temat dość prozaiczny. Recyrkulacja wody w instalacji domowej, żeby po odkręceniu kranu leciał z niego Johny Walk… wróć! ciepła woda. I żeby nie trzeba było na tę ciepłą wodę czekać. Tylko żeby od razu była ciepła.

Problem jest w tym, że zimą woda jest ogrzewana przez piec, a piec ma możliwość sterowania pompą. Nawet potrafi ją włączać cyklicznie, co by ciepło w zasobniku oszczędzać. Tylko trzeba było sobie instrukcję doczytać. Bo pan serwisant, który uruchamiał instalację o takiej rzeczy nie wiedział. Albo nie pomyślał.

Inaczej jest latem, kiedy to woda ciepła jest pozyskiwana z innych źródeł. Na przykład kolektory słoneczne, pompa ciepła etc. Wtedy nie za bardzo ma co sterować pompką.

Samo sterowanie jest banalnie proste, raz na jakiś czas, mieszamy wodę w instalacji przez załączenie napięcia na pompie. W piecu można ustawić to mieszanie od 1x na godzine na 5 minut do 6x na godzinę na 5 minut. Lektura elektrody zaś głosi, że trzeba to robić raz na 5 minut przez minutę. Zimą miałem 5×5, latem mam 10×1 i nie widzę różnicy.

Do tej pory miałem prosty układ na ATMega328. Nie posiadał on jednak RTC, wobec czego, całość działała całą dobę.
Całą dobę ciepłej wody jednak nie używamy. W nocy zazwyczaj śpimy, więc żeby oszczędzić trochę ciepła w zasobniku, nie ma sensu odpalać pompki w godzinach nocnych.

Powstał więc układ na ESP8266. Pilnuje on sobie czasu na liczniku, natomiast aktualny czas pozyskuje sobie z internetu. Przez NTP. Jak zabraknie prądu i nie będzie internetu, to do czasu pozyskania aktualnego czasu i tak będzie mieszać wodę, tyle, że całą dobę.

Używam WebSocketów do prezentacji real-time czy pompka aktualnie jest włączona, czy też nie. No i można sobie skonfigurować godziny pracy oraz zakresy czasowe dla stanów ON i OFF.

Schemat jest banalny. Typowa implementacja ESP12E z automatycznym programowaniem przy użyciu RTS i DTR. Pamiętajcie tylko o wyprowadzeniu masy do konwertera USB< ->UART. Ja zapomniałem (schemat już poprawiony). Przez co straciłem trochę czasu na walkę z komunikacją.
Brakuje przekaźnika, ponieważ mam już płytkę z przekaźnikiem, do której jest podłączona pompa obiegowa, potrzebuję tylko podać sygnał z zakresu 3 – 5V żeby przekaźnik załączył pompę.

Sterownik wygląda tak:

Płytka jest „uniwersalna”, to znaczy ma obsłużyć jeszcze dwie inne sytuacje, dlatego ma dodatkowe elementy, i miejsce na kolejne. Może kiedyś to też opiszę 🙂

Tradycyjnie też, kilka screenów z aplikacji:

Monitoring środowiska w domu – schemat i płytka

Tak to wygląda jeśli chodzi o czujnik:

Monitoring środowiska w domu – podsumowanie po kilku miesiącach

Od uruchomienia monitoringu minęło już trochę czasu.
W międzyczasie przerobiłem szablon dla strony na trochę bardziej kolorowy.
Dodałem też filtrowanie danych po datach dla dni oraz miesięcy.
Same czujniki działają nadzwyczaj dobrze. Niestety kupiłem zestaw baterii słabej klasy, przez co czujniki potrafią się zawiesić przy wysyłce danych. Baterie po prostu nie podają odpowiedniego prądu, nie pomaga też jeden mały kondensator na linii zasilania. Powoduje to reset układu w czasie wysyłki danych.
Pierwsze baterie które miałem, pracują do dzisiaj. Dzisiaj przy nowych płytkach na pewno dodałbym więcej kondensatorów na zasilaniu, żeby podtrzymać ładunek niezbędny do wysyłki danych. Powinno to pomóc na problemy ze słabymi bateriami.
Zużycie prądu to ok. 3uA w spoczynku. W czasie nadawania 30mA zabiera układ RF, w czasie odbioru danych 15mA, 300uA pobiera czujnik w czasie pracy i reszta układu w granicach 3mA.
Jeśli chodzi o jednostkę centralną, to działa bez restartu od listopada (podmianka usług z poprawkami).
Projekt uważam więc za zadowalający.
Muszę dorobić w wolnej chwili czujniki dla reszty pomieszczeń oraz myślę ciągle nad czujnikiem jakości powietrza.

Poniżej kilka screenów z nowej szaty graficznej:

Monitoring środowiska w domu – wersja działająca

W końcu (w połowie sierpnia :p) udało mi się uruchomić system do monitoringu danych środowiskowych.
Koncepcja w stosunku do pierwotnej trochę się zmieniła, przez co centralką zbierającą i przechowującą dane jest Raspberry Pi.
Hosting zapewnia NodeJS wraz z ExpressJS. Dane zbierane są do bazy danych SQLite.
Całość chodzi stabilnie od prawie miesiąca.
Czujniki się nie zmieniły (chociaż kolejna wersja będzie poprawiona, antena wzdłuż baterii, czujnik od strony baterii a nie procesora).
Do RPi podpięty jest wygrzebany z otchłani śmieci na biurku wyświetlacz OLEDowy. Wyświetla bieżące dane.

Poniżej kilka screenów z hostingu:

WiringPi (like) obsługa przerwań

Dzisiaj zajmę się poprawną obsługą oczekiwania na przerwanie, jeśli przerwania oparte są na poll (czyli biblioteka WiringPi i klony).
W czym leży problem?
Otóż poll chodzi sobie w drugim wątku. Jest to metoda nieobciążająca procesor. Samo poll nie zużywa mocy obliczeniowej. Natomiast większość przykładów, które widziałem, opartych jest na pętli nieskończonej, oczekującej na wystąpienie przerwania. Co powoduje, że ta pętla obciąża nam procesor w 100%.
Przykład takiego użycia:

 C++ | 
 
 copy code |
?

01
bool packetAvailable = false;         
02
 
03
void signalsInterrupt(void) 
04
{
05
	packetAvailable = true;
06
}
07
 
08
int main(int argc, char *argv[])
09
{
10
	wiringPiSetup();
11
 
12
	pinMode(GDO2, INPUT);
13
	pullUpDnControl(GDO2, PUD_UP);
14
 
15
	wiringPiISR(GDO2, INT_EDGE_FALLING, &signalsInterrupt);
16
 
17
	while (1)
18
	{
19
		if (packetAvailable) 
20
		{
21
			(...)
22
		}
23
	}
24
 
25
	return 0;
26
}

Mało eleganckie, nieprawdaż?
Z pomocą przychodzą nam mechanizmy do obsługi wątków, jak np. semafory.
A oto poprawny przykład, zużywający ~0% procesora:

 C++ | 
 
 copy code |
?

01
static sem_t interrupt;
02
 
03
void signalsInterrupt(void) 
04
{
05
	sem_post(&interrupt);
06
}
07
 
08
int main(int argc, char *argv[])
09
{
10
	wiringPiSetup();
11
 
12
	pinMode(GDO2, INPUT);
13
	pullUpDnControl(GDO2, PUD_UP);
14
 
15
	sem_init(&interrupt, 0, 0);
16
	wiringPiISR(GDO2, INT_EDGE_FALLING, &signalsInterrupt);
17
 
18
	while (1)
19
	{
20
		sem_wait(&interrupt);
21
 
22
		(...)
23
	}
24
 
25
	return 0;
26
}

Kod działa następująco. sem_init definiuje nam semafor obsługujący przerwanie. Callback signalsInterrupt wywoływany jest przez wątek obsługujący przerwanie (ten z poll). Tutaj ustawiany jest semafor. W pętli głównej while(1) oczekujemy na ustawienie semafora. Aplikacja działa teraz bez obciążania procesora.

Specjalne podziękowania dla anonimowego darczyńcy za zredagowanie tekstu 🙂

Monitoring środowiska w domu

Jak pisałem wcześniej (tu i tu) pracuję nad prywatnym projektem. Projekt ten zakłada sieć czujników i układów wykonawczych.

Komunikacja odbywać się będzie przy użyciu fal radiowych na częstotliwości 433MHz.

Czujniki mają być zasilane z baterii CR2032 i działać minimum rok na nowej baterii.

Układów wykonawczych póki co nie mam, mam natomiast zestaw mini czujników opatych na SHT21. Co daje nam możliwość monitorowania temperatury i wilgotności na danym obszarze.

Cześć centralna oparta jest o ESP32. Udostępniać będzie stronę WWW z danymi zebranymi przez czujniki. Dane zapisywane będą na karcie SD. Dodatkowo na bieżąco wyświetlane dane będą na wyświetlaczu LCD.

Stan prac jest marny na dzień dzisiejszy. Czujniki są gotowe i oprogramowane, natomiast część centralna dopiero się kompletuje.

Visual GDB na platformie embedded linux segmentation fault przy starcie

Jeśli przy starcie sesji debugowej dostajemy komunikat:

To znaczy że musimy doinstalować symbole debugowe:

 Bash | 
 
 copy code |
?

1
apt install libc6-dbg

I to wszystko 🙂

NanoPi Air wyłaczenie monitora

Ponieważ i tak nie mamy złącza HDMI, warto zaoszczędzić te kilkaset miliamperów:

 Bash | 
 
 copy code |
?

1
nano /boot/boot.scr

 Bash | 
 
 copy code |
?

1
setenv video-mode "monitor=none"

 Bash | 
 
 copy code |
?

1
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

Kernel mainline i edycja dtb

NanoPI Neo Air to bardzo przyjemna płytka systemu embedded.
Pojawiła się potrzeba uruchomienia na tym maleństwie drivera do magistrali CAN.
O ile w dystrybucji ARMBIAN jest wszystko co potrzeba, czyli moduł w kernelu, o tyle problemem okazało się uruchomienie modułu.
Konfigurację (częstotliwość kwarcu dla MCP2515, IRQ) musiałem nadpisać dtb uwzględniając mój hardware.

Pierwszą rzeczą jaką zrobiłem, jest kopii zapasowa konfiguracji. Tak na wszelki wypadek.
Potem skopiowałem plik dtbo do katalogu użytkownika i zdekompilowałem go:

 Bash | 
 
 copy code |
?

1
dtc -I dtb -O dts sun8i-h3-spi0-mcp2515.dtbo > sun8i-h3-spi0-mcp2515.dts

Następnie wyedytowałem…

 Bash | 
 
 copy code |
?

1
nano sun8i-h3-spi0-mcp2515.dts

…do następującej postaci:

 Bash | 
 
 copy code |
?

01
/dts-v1/;
02
 
03
/ {
04
        compatible = "allwinner,sun8i-h3";
05
 
06
        fragment@0 {
07
                target-path = "/aliases";
08
 
09
                __overlay__ {
10
                        spi0 = "/soc/spi@01c68000";
11
                };
12
        };
13
 
14
        fragment@1 {
15
                target-path = "/clocks";
16
 
17
                __overlay__ {
18
                        #address-cells = &lt;0x1>;
19
                        #size-cells = &lt;0x1>;
20
 
21
                        can0_osc_fixed {
22
                                compatible = "fixed-clock";
23
                                #clock-cells = &lt;0x0>;
24
                                #częstotliwość kwarcu:
25
                                clock-frequency = &lt;16000000>;
26
                                linux,phandle = &lt;0x2>;
27
                                phandle = &lt;0x2>;
28
                        };
29
                };
30
        };
31
 
32
        fragment@2 {
33
                target = &lt;0xffffffff>;
34
 
35
                __overlay__ {
36
 
37
                        can0_pin_irq@0 {
38
                                #pin z podpiętym IRQ
39
                                allwinner,pins = "PG11";
40
                                allwinner,function = "irq";
41
                                allwinner,drive = &lt;0x0>;
42
                                allwinner,pull = &lt;0x1>;
43
                                linux,phandle = &lt;0x1>;
44
                                phandle = &lt;0x1>;
45
                        };
46
                };
47
        };
48
 
49
        fragment@3 {
50
                target = &lt;0xffffffff>;
51
 
52
                __overlay__ {
53
                        status = "okay";
54
                        #address-cells = &lt;0x1>;
55
                        #size-cells = &lt;0x0>;
56
 
57
                        mcp2515@0 {
58
                                reg = &lt;0x0>;
59
                                compatible = "microchip,mcp2515";
60
                                pinctrl-names = "default";
61
                                pinctrl-0 = &lt;0x1>;
62
                                spi-max-frequency = &lt;0x989680>;
63
                                interrupt-parent = &lt;0xffffffff>;
64
                                interrupts = &lt;0 203 2>;
65
                                clocks = &lt;0x2>;
66
                                status = "okay";
67
                                linux,phandle = &lt;0x3>;
68
                                phandle = &lt;0x3>;
69
                        };
70
                };
71
        };
72
 
73
        __symbols__ {
74
                can0_osc_fixed = "/fragment@1/__overlay__/can0_osc_fixed";
75
                can0_pin_irq = "/fragment@2/__overlay__/can0_pin_irq@0";
76
                can0 = "/fragment@3/__overlay__/mcp2515@0";
77
        };
78
 
79
        __fixups__ {
80
                pio = "/fragment@2:target:0", "/fragment@3/__overlay__/mcp2515@0:interrupt-parent:0";
81
                spi0 = "/fragment@3:target:0";
82
        };
83
 
84
        __local_fixups__ {
85
 
86
                fragment@3 {
87
 
88
                        __overlay__ {
89
 
90
                                mcp2515@0 {
91
                                        pinctrl-0 = &lt;0x0>;
92
                                        clocks = &lt;0x0>;
93
                                };
94
                        };
95
                };
96
        };
97
};

Na koniec ponowna kompilacja i skopiowanie do katalogu źródłowego:

 Bash | 
 
 copy code |
?

1
dtc -O dtb -o sun8i-h3-spi0-mcp2515.dtbo -b 0 sun8i-h3-spi0-mcp2515.dts && cp sun8i-h3-spi0-mcp2515.dtbo /boot/dtb/overlay/

Dodałem jeszcze obsługę do pliku armbianEnv:

 Bash | 
 
 copy code |
?

1
nano /boot/armbianEnv.txt

 Bash | 
 
 copy code |
?

1
verbosity=7
2
logo=disabled
3
console=both
4
disp_mode=1920x1080p60
5
overlay_prefix=sun8i-h3
6
rootdev=UUID=abdc65e6-2e32-4a5f-9a19-56c01c6bdb23
7
rootfstype=ext4
8
overlays=spi0-mcp2515

Konfiguracja samej magistrali CAN:

 Bash | 
 
 copy code |
?

1
nano /etc/modules

 Bash | 
 
 copy code |
?

1
can
2
can-dev
3
can-raw

 Bash | 
 
 copy code |
?

1
nano /etc/network/interfaces

 Bash | 
 
 copy code |
?

1
auto can0
2
iface can0 can static
3
        #taktowanie magistrali CAN
4
        bitrate 250000

I to wszystko. Po restarcie powinniśmy w dmsg zobaczyć następujące linie:

 Bash | 
 
 copy code |
?

1
[    6.824164] can: controller area network core (rev 20120528 abi 9)
2
[    6.829914] can: raw protocol (rev 20120528)
3
[    8.252856] mcp251x spi0.0 can0: MCP2515 successfully initialized.
4

« Older posts

© 2018 Paweł Szabaciuk

Theme by Anders NorenUp ↑