Pioreactor Pioreactor 20 mL v1.1

Znaczenie generacji 1.1

Bieżące API oznacza profil pioreactor_20ml version 1.1 jako legacy i publikuje jego parametry: pojemność 20 mL, średnicę 27 mm i maksymalne napełnienie 18 mL. Bieżąca generacja ma oznaczenie v1.5.

Cecha identyfikacyjna	Pioreactor 20 mL v1.1
profil software	pioreactor_20ml, hardware version 1.1
HAT	RP2040/Pico ADC/DAC pod I²C 0x2C
optyka	przewodowa dioda IR i dwie fotodiody
storage systemowy	microSD w Raspberry Pi
status	legacy; możliwa migracja do 20 mL v1.5 albo 40 mL v1.0

V1.1 jest szczególnie ważny identyfikacyjnie, ponieważ producent udostępnił dwie odmienne migracje. Zestaw SKU 3004 przekształcał 20 mL v1.1 w 20 mL v1.5, wymieniając przede wszystkim tor optyczny i elementy uchwytu. Zestaw SKU 3003 przekształcał go mechanicznie w 40 mL v1.0 bez wymiany elektroniki.

Pioreactor po modernizacji z v1.0 do v1.1 — materiał identyfikacyjny. Źródło obrazu: docs.pioreactor.com.

Identyfikacja fizyczna

Oficjalna instrukcja v1.1 opisuje dwuczęściowy vial holder. Cieńszy O-ring #024 znajduje się w górnej części, a grubszy #121 między podstawą dolnej części i heater PCB. W później wysyłanych v1.1 producent zmienił #024 na uszczelkę o przekroju X.

Na jej aluminiowej części znajduje się termopad; całość jest dociskana do uszczelnienia i mocowana śrubami M2.5. Okno otrzymuje osłonę mocowaną czterema śrubami M2.5 4 mm.

Fotodioda w kanale 1 jest mechanicznie umieszczona w kieszeni REF, a kanał 2 w kieszeni 90°. Producent ostrzega przed wielokrotnym zginaniem wyprowadzeń. W v1.5 te przewodowe fotodiody zastępują przykręcane płytki Eye-Spy, dlatego są najłatwiejszą cechą odróżniającą.

V1.1 po konwersji do 40 mL v1.0 zachowuje przewodową optykę; ma naczynie 40 mL, pręt 15 × 6 mm, Vial Cap S, uchwyt 40 mL, O-ring #024 i inne elementy frontu. Fotografuje się wszystkie PCB, przewody, uchwyt, naczynie i części luzem.

HAT, RP2040 i magistrala I²C

Oficjalny rejestr I²C dla HAT 1.1 podaje mikrokontroler RP2040/Pico obsługujący ADC i DAC pod adresem 0x2C oraz czujnik temperatury płytki grzejnej pod 0x4F. HAT 1.0 był inny: ADS1115 pod 0x48, DAC 0x49 i temperatura 0x4F.

RP2040 jest mikrokontrolerem pomocniczym, a nie głównym komputerem. Producent wskazał przy premierze v1.5, że w starszej optyce konwersja fotodiod używała jego 8-bitowego ADC i wielokrotnego próbkowania. To znane ograniczenia metrologiczne v1.1, nie automatycznie dowód uszkodzenia danego egzemplarza.

HAT v1.x korzysta z GPIO2/GPIO3 jako SDA/SCL. Pięć wyjść PWM odpowiada GPIO17, GPIO13, GPIO16, GPIO12 i GPIO18, przy czym piąte jest przeznaczone dla grzania. GPIO23 steruje diodą PCB. Dla HAT 1.1 przycisk jest na GPIO4, czujnik Halla na GPIO21, a GPIO24/25 są związane z SWD. W HAT 1.0 przycisk i Hall zajmowały inne piny. Źródła: GPIO pins used i I²C addresses.

Wyjścia wykonawcze wykorzystują złącza w rastrze 2,54 mm; w częściach producenta spotyka się TE Connectivity AMP 487526-1. Typowe mapowanie funkcjonalne przypisuje PWM 1 mieszaniu, 2 odpadowi, 3 pożywce, 4 dodatkowemu torowi i 5 grzaniu; jest konfigurowalne.

Model software i granice pojemności

Instrukcja migracji do v1.1 nakazywała dodać w konfiguracji specyficznej:

model=pioreactor_20ml version=1.1

W aktualnym interfejsie model i hardware version wybiera się dla workera w Inventory. API publikuje ten profil jako legacy wraz z pojemnością 20 mL, średnicą 27 mm, limitem napełnienia 18 mL i progami ochronnymi 78/80/85°C. Limit 18 mL jest wartością profilu software, nie obowiązkową objętością roboczą.

Komputer główny i storage

Jak inne Pioreactory, v1.1 jest nakładką na Raspberry Pi, a nie kompletnym komputerem o stałym SoC. Współczesna lista kompatybilności obejmuje Raspberry Pi 3 B+, 3 A+, 4 B, 5 i Zero 2 z 40-pinowym GPIO i Wi-Fi.

Producent zaleca obecnie 16–32 GB Class 10/UHS-I. Karta zawiera Raspberry Pi OS/Pioreactor, aplikację, UI, konfiguracje, klucze SSH, pluginy, kalibracje, logi i lokalne SQLite.

Optyka 90° i integralność pomiaru

V1.1 ma kanał referencyjny i jeden kanał rozproszenia 90°. REF kompensuje zmiany źródła IR; nie usuwa wszystkich zakłóceń: przesunięcie fotodiody, EMI przewodu, zabrudzenie fiolki, bąble i zmiana RPM pozostają. Producent wprost wymienił EMI, ograniczenie 8-bitowego ADC RP2040 i słabsze mocowanie jako powody przejścia na Eye-Spy.

Producent udostępnia protokół DC-based, który przechodzi przez duty cycle i rejestruje RPM.

Architektura leader–worker

Bieżąca dokumentacja obejmuje m.in. uruchamianie/zatrzymywanie jobów, aktualizacje ustawień, konfigurację, kalibracje, zmianę modelu, restart, pluginy i eksport ~/.pioreactor.

Usługi i uwierzytelnienie

W typowym współczesnym profilu występują SSH 22/TCP, HTTP 80/TCP, MQTT 1883/TCP, MQTT WebSocket 9001/TCP i mDNS. Oficjalna instrukcja instalacji rekomenduje użytkownika pioreactor z hasłem raspberry i logowanie SSH hasłem.

Interfejs webowy działa domyślnie przez HTTP. Opcjonalny plugin Basic Auth dodaje prompt logowania; nie szyfrowanie. Dla starego urządzenia ryzyko pozostawienia historycznych defaultów jest szczególnie wysokie, zwłaszcza po aktualizacji software bez ponownego przeglądu hardeningu.

Stan faktyczny potwierdza się w zakresie autoryzacji, z zachowaniem logów i bez zakłócania aktywnej hodowli.

Aktualizacje, zgodność i status legacy

Od 26.3.0 aplikacja używa schematu YY.M.N; na dzień 2 września 2026 r. najnowszym publicznym wydaniem było 26.8.1. Ta informacja jest punktem odniesienia, nie podstawą do zmiany badanego urządzenia.

Kroczący update klastra chwilowo tworzy version skew; producent odradza długotrwałe mieszanie wersji.

Dane i ślady

• ~/.pioreactor/config.ini — konfiguracja wspólna; - ~/.pioreactor/unit_config.ini — stan właściwy workerowi w nowszych wersjach; - ~/.pioreactor/storage/pioreactor.sqlite — centralna baza na leaderze; - lokalne trwałe SQLite — cache, kalibracje i metadane workera; - ~/.pioreactor/hardware/ — definicje HAT/modelu i mapowania; - ~/.pioreactor/experiment_profiles/ — harmonogramy YAML; - ~/.pioreactor/plugins/ — rozszerzenia i zasoby; - ~/.ssh/ — klucze i historia zaufania; - /var/log/pioreactor.log i journald — logi; - /run/pioreactor/ — ulotne cache, kolejki Huey, sockety i eksporty.

Dla v1.1 dochodzą artefakty migracji: stare i nowe profile modelu, instrukcje/BOM zestawów 3003/3004, pliki kalibracji sprzed i po zmianie, daty modyfikacji config oraz pozostawione elementy optyczne. Te informacje pozwalają ustalić, czy dane powstały jeszcze na v1.1, czy po konwersji.

Hardware, usługi i pluginy

Moduł fotodiod wykorzystuje długi przewód i wciskane kapsle. Platforma udostępnia HTTP i MQTT oraz ma znane domyślne poświadczenia. System pluginów pozwala rozszerzać joby, hardware i API.

Weryfikacja wyników i osi czasu

Dla v1.1 szczególnie wartościowe jest zestawienie surowego kanału 90°, REF, RPM oraz zdarzeń środowiskowych.

Postępowanie identyfikacyjne

1. Sfotografować 20 mL vial, pokrywę, O-ringi #024/#121, dwuczęściowy holder, heater PCB/FFC i optykę przewodową.
2. Odczytać model Raspberry Pi, HAT, nadruki PCB, numer seryjny, nośnik i zasilanie.
3. Ustalić, czy wystąpiła migracja 1.0→1.1, 1.1→1.5 albo 1.1→40 mL v1.0; zachować części pozostałe.
4. Zebrać wpis model/version, pio version -v, wersje OS/UI/pluginów i stan zgodności.
5. Skorelować surowe OD, referencję, RPM, temperaturę, dawki i źródła akcji.
6. Udokumentować leader/workery, IP/MAC/hostname, porty, AP/VPN i segmentację.

Galeria identyfikacyjna

Dokładna generacja 20 mL v1.1 z oficjalnego ogłoszenia wersji. Źródło: oficjalna dokumentacja lub karta produktu Pioreactor.

Bieżący 20 mL v1.5 pokazany wyłącznie dla porównania z legacy v1.1; nie jest zdjęciem v1.1. Źródło: oficjalna dokumentacja lub karta produktu Pioreactor.

Bieżący stos sterowania 26.8.1 — granica zgodności

Kod źródłowy sprawdzony 8 września 2026 r. wskazuje wersję aplikacji 26.8.1 i commit 5d758529ea23aef387a2f18f4a774ff3898db7bc z 19 sierpnia 2026 r. Pioreactor przyjął schemat wersji YY.M.N; numer oprogramowania nie oznacza rewizji mechanicznej. Ten sam release może sterować modelami 20 mL, 40 mL, XR i sprzętem legacy, ale dobiera parametry przez jawny model i wersję workera.

Od wydania 25.11.12 backend, unit API i UI są utrzymywane w jednym repozytorium. Obraz bazowy przeszedł na Debian 13 „Trixie”, wprowadził /etc/pioreactor.env, usługę pioreactor-web.service i katalog /run/pioreactor/.

Od 26.4.0 konfiguracja właściwa dla jednostki jest przechowywana przez worker w unit_config.ini; leader utrzymuje jej obraz i pobiera aktualny stan. Interfejsy nazwane wcześniej /api/config/files* zostały usunięte na rzecz zasobów shared oraz unit-specific. W mieszanym klastrze leader i workery mogą zatem różnić się zarówno buildem aplikacji, jak i własnością konfiguracji.

Web UI — widoki operacyjne

Okno zarządzania konkretnym workerem: etykieta, docelowe RPM, temperatura i odstęp między dawkami. Źródło: oficjalna dokumentacja Pioreactor.

Panel Pioreactors pokazuje stan zadań i ustawień osobno dla każdego workera. Zakładki Activities, Settings, Dosing, LEDs i System odpowiadają różnym klasom komend. Zmiana Target stir RPM wpływa nie tylko na mieszanie, ale także na tor optyczny; zbyt wolne mieszanie może się zatrzymać, a zbyt duży wir zmienić OD. Pole czasu między dawkami może spowodować wcześniejsze zdarzenie dawkowania, dlatego zmiana w UI powinna być korelowana z logiem i wpisem dosing_events.

Overview z wykresami, podsumowaniem dawkowania i tabelą zdarzeń zawierającą czas, worker, źródło oraz komunikat. Źródło: oficjalna dokumentacja Pioreactor.

Overview łączy dane historyczne z SQLite z bieżącym stanem przesyłanym przez MQTT. Tabela zdarzeń odróżnia jednostkę i komponent źródłowy, np. monitor, instalację pluginu albo dodanie workera.

Okno wyboru modelu rozdziela 20/40 mL v1.5 oraz rewizje legacy. Źródło: oficjalna instrukcja instalacji.

Wybór modelu nie jest opisem kosmetycznym. Profile sprzętowe wpływają na geometrię naczynia, objętości, kanały optyczne, adresy I²C, pinout, ustawienia mieszania i dostępne kalibracje. Błędnie wybrany wpis może sprawić, że poprawny fizycznie sensor zostanie zinterpretowany jako inny kanał lub automatyka użyje wartości właściwych dla innej rewizji.

Drugi widok ustawień workera pokazujący, że parametry procesu są edytowane z centralnego web UI. Źródło: oficjalna dokumentacja Pioreactor.

Topologia leader–worker i granice zaufania

Leader serwuje SPA, obsługuje leader API, prowadzi główną bazę SQLite, uruchamia zadania tła przez Huey, pośredniczy w komendach do workerów i zazwyczaj hostuje Mosquitto. Worker wykonuje sterowanie lokalne i od 24.9.19 ma własny web server z unit_api, bez interaktywnego UI.

Warstwa webowa jest serwowana przez lighttpd. Pakiet zawiera osobne konfiguracje aplikacji, CORS i HTTPS, a podstawowa dokumentacja kieruje do http://pioreactor.local. Backend działa jako FastCGI z aplikacją Python, a długie operacje trafiają do kolejki Huey.

MQTT przenosi stan i komendy. Typowy broker nasłuchuje na TCP/1883, a web UI używa MQTT over WebSocket na TCP/9001. Dokumentowany przykład konfiguracji zawiera użytkownika pioreactor, hasło raspberry, use_tls=0 i WebSocket ws; HTTP UI zwykle korzysta z TCP/80, SSH z TCP/22, a mDNS z nazw .local.

Poświadczenia i uwierzytelnienie

Historyczne obrazy i skrypty klastrowe używały konta Linux pioreactor oraz hasła raspberry; to samo hasło występuje w przykładach MQTT. Współczesny proces przygotowania obrazu przez Raspberry Pi Imager prosi operatora o ustawienie nazwy użytkownika i hasła, więc raspberry jest wskaźnikiem do kontroli, a nie gwarantowanym poświadczeniem każdej sztuki.

Producent udostępnia opcjonalny plugin Basic Auth dla UI. Basic Auth bez HTTPS nie zapewnia poufności transportu; osobnymi mechanizmami pozostają konta Linux, klucze SSH leader–worker i poświadczenia MQTT.

Dokumentacja hardeningu zaleca niewystawianie interfejsu bezpośrednio do Internetu, odrębną sieć laboratoryjną lub prywatny kanał zdalny, zmianę haseł Linux/MQTT/AP oraz ograniczenie instalowania pluginów. Pliki DISALLOW_UI_INSTALLS i DISALLOW_UI_FILE_SYSTEM blokują wybrane operacje z UI/API, ale nie zastępują kontroli dostępu do SSH ani integralności samego systemu plików.

Dane trwałe i schemat SQLite

Główna baza leadera ~/.pioreactor/storage/pioreactor.sqlite jest źródłem danych historycznych dla UI. Aktualny schemat obejmuje między innymi tabele experiments, workers, przypisania workerów, raw_od_readings, od_readings_filtered, od_readings_fused, growth_rates, temperature_readings, stirring_rates, dosing_events, ustawienia i zdarzenia automatyki dawkowania/LED/temperatury, led_change_events, pwm_dcs, logs, calibrations, od_blanks, historie konfiguracji i uruchomienia profili eksperymentów.

Na węźle występują także SQLite cache: trwały local_persistent_pioreactor_metadata.sqlite oraz bieżący cache metadanych. W gałęzi 26.x cache tymczasowy przeniesiono do /run/pioreactor/, a SQLite może używać WAL/SHM. Kopia wykonana przy aktywnym procesie bez plików -wal i -shm może nie odzwierciedlać najnowszych transakcji. Oficjalne zadanie backupu potrafi kopiować bazę na workery; te repliki są dodatkowymi artefaktami, nie automatycznie niezależnym źródłem integralności.

Od wersji 24.5.22 MQTT w Pioreactorze jest kanałem danych efemerycznych, a trwałe dane procesu są przechowywane w SQLite.

Profile, kalibracje i estymatory

Profile eksperymentów są plikami YAML opisującymi kolejność zadań i nastaw. UI pozwala je tworzyć, edytować i uruchamiać, a backend zapisuje uruchomienia. Kalibracje pomp, OD i mieszania są osobnymi obiektami z nazwą, datą oraz aktywnym wyborem. W XR dochodzą estymatory fuzji kanałów. Kopia samych wykresów bez profilu, aktywnych kalibracji i mapowania modelu jest niewystarczająca do niezależnego odtworzenia wyniku.

Aktualizacje i łańcuch dostaw pluginów

Polecenia pio update i pios update aktualizują aplikację, UI, a zależnie od wydania także komponenty systemowe i skrypty migracyjne. Repozytorium zawiera wersjonowane migracje SQL, pakiety systemowe, zmiany usług i pliki konfiguracyjne. Aktualizacja może więc zmienić nie tylko kod Pythona, ale również lighttpd, bazę, systemd, model konfiguracji i lokalizację artefaktów.

Plugin może dostarczyć joby, automatyzacje, endpointy, elementy UI, definicje sprzętu, tabele SQL i eksportowane datasety. Od 26.4.0 opis możliwości workera jest pobierany dynamicznie, więc plugin obecny tylko na workerze może pojawić się w centralnym UI.

Elektronika, I²C i zależność od Raspberry Pi

Pioreactor HAT nie jest samodzielnym komputerem aplikacyjnym. GPIO, I²C, PWM i pomocniczy mikrokontroler współpracują z Raspberry Pi; obsługiwane modele mają różne SoC Broadcom i ilości RAM, a microSD pozostaje podstawowym nośnikiem.

Profile I²C rozdzielają przetworniki i moduły pomiarowe. Konflikt adresu, niestabilne zasilanie albo uszkodzenie przewodu może dawać przerwy w OD, temperaturze lub sterowaniu, które zdalnie wyglądają podobnie do błędu software. Self-testy pomagają w diagnostyce, lecz nie stanowią kryptograficznego attestation sprzętu.

Źródła podstawowe

• Pioreactor 20 mL v1.1 — instrukcja startowa
• Wetware assembly 20 mL v1.1
• Connecting the optics — v1.1
• Konfiguracja po migracji v1.0 → v1.1
• 20 mL v1.1 → 40 mL v1.0, SKU 3003
• 20 mL v1.1 → v1.5, SKU 3004 — lista upgrade kits
• API Reference — modele
• I²C addresses
• GPIO pins used
• Hardware calibrations
• Security hardening
• Filesystem locations
• Data stores
• Updating software
• Oficjalne Releases

Stan dokumentacji sprawdzono 2 września 2026 r.