universalscientifictechnologies / labdos01 Goto Github PK

Současné pokusy s měřením s LABDOSem vedou na to, že je poměrně obtížné zobrazit naměřená data. Aktuálně to znamená:

1. Zkopírovat txt log z SDkarty LABDOSu a někam ho uložit
2. Vybrat si některý z Jupyter notebooků ten spustit (Před tím mít nainstalované všechny závislosti)
3. Zeditovat jej, minimálně tak, aby cesta k souboru s daty byla platná.
4. Nechat vykreslit data. (V tomhle okamžiku vznikne nemergovatelný soubor noteboku i když efektivně k žádným změnám nedošlo. Zpracování dat je tak neaktualizovatené a právě vznikla další samostatná větev vývoje)
5. Prohlédnout si data a zkontrolovat jejich relevanci.

Aktuální postup mi proto přijde velmi nepraktický pro běžné užití (což nezahrnuje vědecké zpracování konkrétních měřených dat). Myslím si, že pro většinu uživatelů by bylo výhodné aby měli webové rozhraní, kam nahrají data a dostanou zpátky náhled nějakých standardních grafů. Další zpracování pak následně jde vyřešit existujícím postupem.

Myslím, že dobrým příkladem potřebného uživatelského rozhraní je flight_review. Myslel jsem si, že by šel zrecyklovat i jeho zdrojový kód. Nicméně @roman-dvorak ani @slimonslimon si nemyslí, že je to časově efektivní.

Při následné diskusi se @slimonslimon se pak ale ukázalo, že zřejmě plánuje takovou webovou aplikaci postavit na vue.js. To mi ale naopak přijde velmi nevhodné. Protože již máme na několika projektech vyzkoušeno, že takový zdrojový kód je pak dlouhodobě prakticky neudržovatelný. Navíc aplikace, které tímto způsobem vznikají jsou pak ve výsledku příšerně velké což následně způsobuje mnoho potíží, které je nutné řešit.

Související issue: #4 #12

Pro vyřešení problému s ovládací aplikací pro uživatele #4 je nutné sjednotit výstupní datový formát na UART tak, aby byl jednotný formát zpráv mezi AIRDOSem, GEODOSem a LABDOSem.

Takový krok je důležitý i pro dohodu s jinými lidmi, např. OpenGammaProject/Gamma-MCA#25

Jako optimální by mi přišlo, kdyby přístroje posílaly více typů zpráv a nebylo tak potřeba tolik informací držet v paměti. Důvodem k tomu proč se to tak nyní nedělá je jednoduchá minimalizace mrtvé doby měření, která ale i tak není moc optimální #13

Tištěná krabička se při sešroubování zdeformuje.

Příčinou je zřejmě příliš malá délka distančních sloupků, které se tak stáhnou proti PCB.

Řešením by tak bylo buď prodloužit sloupky, nebo doprostřed krabičky dát ještě jeden sloupek bez šroubu, který se při stažení opře o PCB.

Současný firmware má několik různých variant, které se jen minimálně liší:

• Počtem kanálů 256/512
• Jestli má nebo nemá SDkartu pro zápis
• Frekvencí použitého krystalu

U těchto rozdílů zřejmě neexistuje důvod proč držet různé codebase. Zádrhelem je akorát to, že by bylo potřeba implementovat přepínací vlastnosti firmware (což je ale stejně potřeba kvůli integračnímu intervalu). Tyto parametry jsou buď nastaveny při překladu (frekvence krystalu), nebo jsou parametrem přístroje (počet kanálů, integrační doba, zápis na SDkartu...)

Parametry přístroje by zřejmě správně měly být zapisovány do externí EEPROM, aby nebyly přepsány aktualizací firmware.

Poznámka k počtu kanálů
Původní verze detektoru měla pouze 256 kanálů jako liulin. Zvětšení počtu kanálů podle @kakl vedlo na problem, ze ta ATmega ma nejakou proprietarni kompenzaci DC offsetu. Díky tomu interní ADC nefunguje dobře s externí referencí a způsobuje to jitter kanálů na spektrogramu. #15

Počet kanálů by ale obecně potřeboval zvýšit viz UniversalScientificTechnologies/GEODOS01#23 Tudíž je zřejmě nutné začít používat externí ADC.

There is accidentally silicone instead of silicon:

At the same time, I suggest updating the text to describe better form: "LABDOS01 is an open-source spectrometer-dosimeter based on silicon PIN diode and is intended for scientific research and experimental purposes. "

Vzhledem k drobným mechanickým úpravám je potřeba vytvořit upravený návrh samolepky. Který bude řešit následující:

• Průhlednost samolepky v místech LED
• Posun citlivé oblasti
• Výroba by pak měla být provedena tak, aby se neopakovaly známé potíže jako např. #7

Pro SPACEDOS03 jako produkt by bylo užitečné mít obslužný SW, který bude plnit několik funkcí a bude zajišťovat dobrou kompatibilitu.

V první iteraci je potřeba zajistit několik vlastností:

• Co nejvíce multiplatformní
• Možnost snadné instalace - nejspíše pipy
• Spolehlivost a kompatibilita s FW
  • #2,
  • Reset zařízení
  • Rozpoznání připojeného zařízení
  • #3,
  • automatický update firmware
• Schopnost logovat data
  • Histogramy
  • Jednotlivé eventy
  • Metadata
    • Geografická poloha
    • Vlhkost
    • Teplota
    • Tlak
• Upload dat na vyhodnocovací server (s databází měření navázanou na uživatelský účet)
• Zvukově signalizovat tok částic. Například cvakáním. Dneska by to ale zřejmě šlo udělat i sofistikovaněji podle spektra a energie částic.

Pro experimenty s firmwarem je celkem podstatné mít možnost číst data na sériové lince od okamžiku spuštění MCU. U LABDOSu s připojením na USB, se to ale těžko dělá, protože MCU dovede zapisovat data do virtuálního USB serial ještě dříve, než se zinicializuje.

Řešením tohoto problému by bylo přidání resetovacího tlačítka, které lze zmáčknout otvorem v krabičce pomocí nějakého nástroje.

Popis problému

Současné řešení je navrženo tak moc "univerzálně", že některé jeho vlastnosti nelze využít. Například JST-GH konektor původně určený pro bateriové napájení je obtížně použitelný, protože vyžaduje speciální osazení PCB a precizně stabilizované napájení.
Zároveň je zde příprava pro připojení TFGPS01 na konektoru "AUX IO", která ale nejde použít jinak než se speciální powerbankou, která má dva napájecí USB konektory. Příčinou je, že LABDOS je k TFGPS zapojen jako payload pro UAV. V takové aplikaci se ale předpokládá, že TFGPS bude napájena z jiného zdroje (autopilota).
UART konektor je proto chráněn diodou tak, aby se na něj nemohlo dostat napájecí napětí z případně zapojeného USB konektoru, což by při zapojení do UAV jinak způsobilo nechtěné napájení celého UAV skrz USB konektor. Proto nelze v součaném řešení LABDOS i TFGPS napájet jedním USB konektorem. Zároveň USB konektor (na kterém je stejný UART jako na vyvedeném UART konektoru) je na LABDOSu podstatný proto, aby zařízení mohlo být kompaktní s USB rozhraním a snadno použitelné pro různé laboratorní aplikace.

Navrhované řešení

Z těchto důvodů bych navrhoval použití LABDOSu jako UAV payloadu zrušit a tuto vlastnost pokrýt původně zamýšlenou úpravou SPACEDOS02, který nemá mít USB konektor. Tím efektivně vznikne nový AIRDOS03 vhodný pro měření v bezpilotních prostředcích, kde TFGPS poskytne spolehlivý zdroj polohy přes TFPayload konektor. Kombinace těchto dvou konektorů na LABDOSu (napájecí konektor a USB konektor) s ostatními konektory jsou příčinou komplikací popsaných v úvodu.

Proto dává smysl současnou kombinaci UART konektoru a "bateriového napájecího konektoru" na LABDOSu nahradit Autopilot GPS&SAFETY konektorem na místo Aux IO. To pak umožní připojit TFGPS stejně jako se připojuje k autopilotu, což kromě napájení celé dvojice TFGPS a LABDOSu z jednoho USB poskytne i další vylepšení:

• Připojení externího pípáku který je uvnitř TFGPS
• Možnost připojení tlačítka (na konektor TFGPS), tlačítko může například značkovat důležité fáze měření
• Připojení GNSS přijímače pro aplikace, kde přijímač v přípojeném telefonu/tabletu nestačí (například kvůli COCOM limitům, nebo nastavenému dynamickému modelu). Nebo zařízení ze kterého se LABDOS napájí GPS prostě neobsahuje (např powerbanka).
• Možnost připojení nějakých podpůrných čidel na I2C sběrnici.

Na zvážení je také odebrání pouzdra pro SDkartu, které v zařízení, které je napájeno z USB konektoru připojeného do nadřazeného systému nedává úplně smysl. Jedinné použití této možnosti je napájení z powerbanky, které je ale z principu velmi neefektivní a vlastně nepřináší výhody nad napájením z telefonu nebo tabletu. Tudíž nevidím moc důvod, kvůli tomu zesložiťovat návrh.
Taktéž RTC obvod a jeho baterie asi nedává smysl, ze stejných důvodů. Smysl by to dávalo pouze v případě jednoznačného značkování dat viz, mlab-modules/DATALOGGER01#9 to ale současná implementace nesplňuje.

Firmware pro starší/existující varianty spacedosů zřejmě existuje ve více variantách. Obvykle podle specifik konkrétních aplikací. Je potřeba najít nejpodobnější/nejaktuálnější verzi posledního FW a přidat ji do tohoto repozitáře. Aby z ní šlo dále vycházet.

Je potřeba vymyslet co zapsat do EEPROMky, tak aby firmware poznal, jaký má hardware.

1. Identifikace obsahu paměti
2. Co je to za zařízení, jeho verzi
3. sériová čísla ostatních komponent
4. Kalibrační parametry?
5. Checksum

Pro github actions existuje compile-arduino-sketches worker, který by měl umět zkompilovat arduino projekt a vytvořit soubor, který by měl jít nahrát do arduino spacedosu.

Zkusil jsem změřit parametry signálu na nožičce krystalu a vypadá to, že je tam zapnutý "Full swing Crystal Oscillator". Myslím že by to chtělo jej vypnout aby zbytečně nerušil analogové měření @kakl.

Originally posted by @kaklik in ust-modules/USTSIPIN02#12 (comment)

Je potřeba popsat postup kalibrace.

Samolepky se při skladování zřejmě scvrkly a otvory na hlavičky šroubů nyní nepasují přesně na šrouby. Tím dochází k zakrývání hlaviček šrubů.
Podezřelé ale je, že se tento problém zřejmě vyskytuje už od nových samolepek. Před výrobou dalších je třeba ověřit, že otvory výřezů pro šrouby z vrchní strany jsou skutečně správně umístěny.

Aktuální implementace minimalizuje mrtvou měřící dobu tím způsobem, že hromadí co nejvíce dat v operační paměti a z nich pak vytvoří datovou zprávu kterou buď rychle odešle na UART, nebo uloží na SDkartu.

Takový přístup je do značné míry suboptimální, protože jednak neminimalizuje mrtvou dobu měření úplně a zároveň ji prodlužuje na těžko definovanou dobu, která závisí na měřených datech.

Navíc to komplikuje zacházení s formátem výstupních dat #12

Teoreticky by ale mrtvou dobu mělo jít výrazně omezit vhodnou obsluhou UART. Protože, jednak lze nastavit různou délku bufferu pro UART. Například bootloader pro mightycore má tyhle flagy, které tu velikost bufferu řídí. Velikost bufferu 128 bytes by měla stačit na většinu zpráv, kromě spektrogramů, které se posílají jen zřídka. Navíc u spektrogramů by možná bylo žádoucí, aby zprávy byly nějak komprimovány, protože zpráva spektrogramu obsahuje většinou samé nuly.

Zároveň by mělo být možné UART obsluhovat v časech, kdy probíhá ADC převod. Protože při vzorkování ADC 125 us má MCU při 8 MHz k dispozici 1000 instrukcí mezi každou hodnotou ADC. Za tu dobu může být odesláno celých 14 bitů na UART rychlostí 115200.

Aktuální firmware průměruje na začátku 8 vzorků ADC na signálu vůči referenci, aby zjistil offset ADC vůči reálné nule.
Občas se ale stane, že tento proces nezafunguje dobře (zřejmě když je offset zrovna nesoudělný přesně s kanálem). Tím pak vzniknou v prvním kanálu neúměrně vysoké hodnoty.

Řešením by mohlo být

• průměrování z jinak vybrané množiny vzorků
• někde mít uložený kalibrovaný offset změřený za laboratorních podmínek
• použití externího ADC, které tento problém zmírní.

Kalibrovaný offset, by ale potřoboval korekci na teplotu.

Bylo by velmi přinosné, aby bylo možné zjistit, jaký commit firmware aktuálně běží.

Obvykle se to řeši tak, že se nějakým způsobem vygeneruje soubor (např. git_version.h), který bude obsahovat definici aktuálního commitu. S výhodou může tento soubor obsahovat arduino makra vkládající aktuální datum a čas pro lokální kompilování - tím půjde poznat, jestli to bylo kompilované v CI nebo jestli to bylo kompilované v uživatelském počítači.

Soubor git_version.h může být vytvořen buď v rámci samotného CI nebo nějakým arduino pre-compile skriptem. To ale nevím, jestli funguje i s CI nástrojem.

Po spuštění firmware může být aktuální verze (+ nějaké nastavení) vypsána po sériovce.

Ukazuje se, že je těžké vysvětlit k čemu jsou polovodičové detektory dobré a jaké jsou jejich výhody oproti současným detektorům. Důvodem je, že polovodičové detektory nejsou příliš známé. Zřejmě by tak bylo vhodné napsat nějaké vysvětlující texty na:

• Hackaday
• Wikipedii
  • Liulin instruments
  • Semiconductor detector

Je potřeba vytvořit popis ověřovacích postupů pro kontrolu kvality. Tato úloha souvisí i s vytvořením servisního software zřejmě na způsob Gamma-MCA.