Sugestie i pomysły związane z Rad@H

[andy101fah]

Dołączyłem do ekipy Radioactive i mam pytanie. Dodałem do BM projekt i coś pobrało i zaczęło liczyć mimo że nie mam czujnika. Czy to są jakieś testowe projekty czy też użytkownicy bez czujników mogą wspierać projekt poprzez przeliczanie i walidowanie wcześniej dokonanych pomarów. Byłoby super gdyby również osoby bez czujników mogły wspierać obliczeniowo projekt. Możemy przeliczać testowe próbki lub w inny sposób testować stabilność projektu.

[goofyx]

Do PAN słać :D

aha, skrót R@H jest juz zajęty przez rosettę. Może nasz powinien brzmieć RA@H?

Myślałem, że przyjęliśmy skrót Rad@h ??

[TJM]

Dołączyłem do ekipy Radioactive i mam pytanie. Dodałem do BM projekt i coś pobrało i zaczęło liczyć mimo że nie mam czujnika. Czy to są jakieś testowe projekty czy też użytkownicy bez czujników mogą wspierać projekt poprzez przeliczanie i walidowanie wcześniej dokonanych pomarów. Byłoby super gdyby również osoby bez czujników mogły wspierać obliczeniowo projekt. Możemy przeliczać testowe próbki lub w inny sposób testować stabilność projektu.

Aplikacja bez czujnika nic nie robi, po prostu czeka na czujnik (podobnie jak aplikacja QCN).
Żeby nie komplikować spraw i nie stresować serwera, zadania "liczone" bez czujnika się walidują, ale z 0 kredytów.

[krzyszp]

W zasadzie nie bardzo widzę możliwość takiego walidowania wyników (brak przecież punktu odniesienia), niemniej kilka komputerów bez czujników przydaje się do... testowania reakcji app na taką sytuację... Zwłaszcza, gdy taki użytkownik nie próbuje nas "powiesić za j..." z powodu "dziwnych" komunikatów (np. brak walidacji wyników).
Przypominam, że projekt jest non-cpu-intensive i nawet z dołączonym czujnikiem ilość mocy obliczeniowej procesora jakiej używa jest wartością w zasadzie pomijalną (całą robotę wykonują czujnik oraz serwer projektu).

Generalnie, pobrana przez Ciebie próbka ma za zadanie nie robić nic, przy braku czujnika aplikacja przez określoną liczbę minut (ta wartość zmienia się w zależności od wersji app) sprawdza co jakiś czas, czy jednak user nie podłączył czujnika (zwykle w interwałach jedno minutowych).

[andy101fah]

Przynajmniej wszystko jasne. Ale moim zdaniem warto wykorzystać też użytkowników bez czujników którzy mogliby przeliczać jako betatesterzy przyszłe wersje lub aktualizacje klientów lub w inny sposób przyczyniać się do testowania całej infrastruktury projektu. Np tworzenie mapek radioaktywności na podstawie danych z czujników lub inne projekty w oparciu o dane z czujników czy też stabilność serwerów projektu.

[TJM]

Niestety nie widzę jak użytkownik bez czujnika mógłby testować nowe wersje aplikacji, skoro aplikacja zajmuje się jedynie odbieraniem danych od czujnika i logowaniem do pliku. Gdy nie ma czujnika po prostu nic nie robi, czeka aż pojawi się czujnik, jeśli nie pojawi się w ciągu określonego czasu aplikacja wychodzi i tyle. Lepiej po prostu poczekać aż będą dostępne czujniki.

[andy101fah]

Niestety nie widzę jak użytkownik bez czujnika mógłby testować nowe wersje aplikacji, skoro aplikacja zajmuje się jedynie odbieraniem danych od czujnika i logowaniem do pliku. Gdy nie ma czujnika po prostu nic nie robi, czeka aż pojawi się czujnik, jeśli nie pojawi się w ciągu określonego czasu aplikacja wychodzi i tyle. Lepiej po prostu poczekać aż będą dostępne czujniki.

Niechaj koledzy nie potraktują tego jako podważanie ich wysokich umiejętności programistycznych (ze swojej strony wypowiadam się jako laik programistyczny) ale moim zdaniem od strony informatycznej jest to trywialne. Po prostu soft emulujący czujnik i jego zachowanie. Nic innego jak sekwencje impulsów w jednostce czasu. W ten sposób moglibyśmy testować nowe wersje aplikacji dla czujnika z korzyścią dla wszystkich.

[TJM]

Już widzę tą trywialność w napisaniu emulowanego urządzenia HID.
Poza tym najzwyczajniej w świecie szkoda tracić czas na coś, co jest niepotrzebne, w szczególności na obecnym etapie rozwoju kiedy nawet nie ma stabilnej wersji aplikacji.
Testy jak stabilność serwera itp w ogóle nie mają znaczenia dla projektów nci (1 WU dla hosta -> znikome obciążenie). Poza tym zauważ, że BOINCowy światek niezbyt toleruje dawanie kredytów za nic i zapewne wokół testowych nicnierobiących aplikacji szybko by się zrobił smrodek, jak to już parę razy bywało tu i tam.

[andy101fah]

Uważałem że możemy dzięki temu przyczynić się do szybszego powstania stabilnej wersji aplikacji. Tak jak obecne nazwane są: sample_xxxx_x, to testowe mogłyby być odpowiednio oznaczone i oczywiście nie punktowane ( można jedynie stosować wewnętrzne odznaki Teamu) dla wspierających projekt. Warto opracować mechanizm dzięki któremu możemy testować niestabilne wersje dla innych i już gotowe upubliczniać w projekcie.

[TJM]

Udało mi się w pewnym stopniu przygotować aplikację Windows.
W pewnym stopniu, ponieważ kompiluje się, ale mam problem z błędami linkera, m.in. częściowo nie widzi funkcji z BOINC API - jedynie boinc_sleep()
Poza tym wykłada się co nieco na windows.h.
Czy jest ktoś obeznany z mingw, coby wspomóc w interpretacji błędów linkera ?

[AL]

Raportuję uprzejmie, że dziś od rana pobiera mi aplikację Radioactivity Monitor 1.03. Każde zadanie "przelicza się" w nieco ponad minutę z wyjątkiem dwóch (WU 29917 i WU 30606). Ładnie się walidują otrzymując 0 punktów (komputer bez czujnika).

[Svistak]

Również raportuję aktywność od rana - 12 próbek dosyć szybko, za to jedną męczy i męczy - zresztą czas raportowania ma jako jedyna aż za dwa tygodnie - http://radioactiveathome.org/boinc/results.php?userid=1500 ...

[TJM]

Te "dość szybko" to były 1.02 które działały 80 sekund, to był tylko test czy aplikacja Win zapisuje pliki wyjściowe.
1.03 już działa identycznie jak na Linuksie, tzn chyba 2-3 godziny czeka na czujnik jeśli go nie ma i wychodzi bez błędu (0 kredytów).
A tutaj przykład - host 315 to właśnie Windows http://radioactiveathome.org/boinc/test123.php

P.S. Niektórzy szczęśliwcy załapali się z rana na bug validatora przyznający po 10-15 kredytów za puste wyniki   %)

[Svistak]

ot szczęście mnie nie lubi  :(  ... ale grunt, że w temacie spory ruch do przodu ... czekam cierpliwie na prototyp czujnika, a trochę danych na przełomie września.października "załaduję" wtedy z Prypeci i Czarnobyla... będę tam wtedy siedział...

[AL]

No niestety ja też do grona szczęściaży się nie zaliczam. Dodatkowo po 3 godzinach musiałem zresetować pc i próbka zaczęła się liczyć od nowa. Więc ją ubiłem.

[Svistak]

Biedna próbka  :D  ... moja się zliczyła, odfrunęła i liczy się kolejna - tylko czy na pewno się liczy?... ale przynajmniej czuje się dobrze na moim kompie przez trzy godziny :) ...

[TJM]

Liczy się to za dużo powiedziane - na przemian idzie sleep i próba połączenia do czujnika. Teoretycznie w momencie podpięcia czujnika powinien ruszyć z miejsca progress bar.

[Svistak]

nio to "szczekamy" na prototypy czujników... a na razie bądźmy "gościnni "dla próbek... dla programistów to przynajmniej dobry sygnał, że aplikacja na "okienkach" pracuje :) ...

[krzyszp]

Wykonałem telefon do jednego z producentów sprzętu zajmującego się małoseryjnymi zamówieniami, ale... nie byli zainteresowani, bo mają za dużo zleceń obecnie... ???

[Svistak]

czyżby wariactwo po Fukushimie? ja to obserwuję po rynku wtórnym liczników Geigera różnej maści - te, które dawno wycofano z użytku i na aukcjach stały co najwyżej po 25zł, teraz kosztują po 600zł - szkoda mi ludzi, którzy kupują ten chłam... nówka z ukraińskiej dostawy Terra-P w pełni skalibrowana to koszt ledwo 400zł... ale to jest sprzęt specjalistyczny, a nie dozymetry z lat 90-tych... ale też jeden z nią problem, bo Ukraińcy "wyczyścili" wszelkie magazyny dla Japonii - bo tam każde dziecko musi mieć teraz osobisty dozymetr... ot i wariactwo... a tak robiąc lekkie OT - w centrum opuszczonej przed 25 laty Prypeci jest mniejsze promieniowanie tła gamma niż... w centrum Warszawy, czy mojego Szczecina - jeszcze wiele Odry i Prypeci musi przepłynąć byśmy bardziej racjonalnie niż wariacko podchodzili do radioaktywności...

[TJM]

AL nawet nie wiesz o ile swoją wypowiedzią usprawniłeś aplikację  :ph34r: Po tym co napisałeś rzuciłem okiem na źródła i tak: bez sensora rzeczywiście zaczynała od nowa co nie jest niczym strasznym i tak zostanie (bo i tak nic nie robi tylko czeka, to niech se czeka dalej).
Gorzej z tym, że aplikacja zachowywała się tak samo również z sensorem, czyli w niesprzyjających warunkach (częste restarty) mogłaby się w ogóle nigdy nie zakończyć   :ph34r: Co gorsze plik wyjściowy się przy tym strasznie gmatwał, do tego stopnia, że validacja stawała się niemożliwa.

Tymczasowo poprawiłem aplikację (na razie tylko wersję Win, bo Linuksową muszę budować na specjalnie przygotowanym laptopie który chwilowo jest nieczynny) i wydaje się działać ok, ale może poprawi się jeszcze moją poprawkę.


P.S. Nie ma ktoś z was jakiegoś MACa do którego mógłby ustawić zdalny dostęp w celu umożliwienia kompilacji aplikacji ? Może bym tam coś spróbował ulepić %)

[Troll81]

A maca na motorolce chcesz czy na intelu? Na intelu mogę ci postawić maca w wirtualce.

[TJM]

Myślę że jak coś to oba, ale można zacząć od Intela - wtedy w ogóle zobaczę czy dam radę coś tam ulepić.

[Troll81]

To jak wrócę do domu to sie postaram ruszyć tę wirtualkę. Maca na motorolce jednak ni mam :(

[TJM]

Myślę że nie ma za dużego pośpiechu, jakbym zaczął coś działać to raczej bardziej w piątek wieczorem/weekend.

[AL]

AL nawet nie wiesz o ile swoją wypowiedzią usprawniłeś aplikację  :ph34r:

Proszę bardzo!

[Sergeant]

Domyślam się, że obecne próbki Radioactivity Monitor 1.33 potrzebują podpiętego czujnika i nie będą się zliczały do końca (podobnie jak w QCN)?
Mam też następne pytania:
1. Czy czas przeliczania próbek jest zbliżony (podobnie jak w QCN)?
2. Czy stała jest ilość zdobywanych punktów za próbkę?

[TJM]

1. Nie wiem ile jest w QCN, u nas jest 1,5h ale nie jest to ostateczna decyzja
2. Nie; bliżej prawdy jest stwierdzenie, że liczba kredytów zależna jest od czasu pracy czujnika. Czas pracy czujnika niekoniecznie musi być jednoznaczny z czasem pracy aplikacji, aczkolwiek w większości przypadków tak jest.

Bez czujnika aplikacja po prostu wisi sobie kilka godzin po czym wychodzi (bez błędu).

[Sergeant]

W pierwszym pytaniu miałem na myśli, czy podobnie jak w QCN czas przeliczania próbek jest zbliżony do siebie (nie do czasu liczenia próbek w QCN - 24h).

[krzyszp]

W pierwszym pytaniu miałem na myśli, czy podobnie jak w QCN czas przeliczania próbek jest zbliżony do siebie (nie do czasu liczenia próbek w QCN - 24h).

Tak, próbki przeliczają się ok. 1.5h na wszystkich hostach (jeśli czujnik jest podłączony).

W przypadku braku czujnika aplikacja przez kilka godzin na niego czeka, po czym wychodzi.

[Szopler]

Panowie krzyszp, Michal i TJM...

Trzeba ;)

aby czujnik sam obliczał średnią dajmy na to z ostatnich 7 dni i jak średnia z kilku ostatnich pomiarów przekroczy ją o 150-180% dawał znać brzęczykiem, że coś jest nie tak (nawet jak w prefsach brzęczyk dla pojedynczych zliczeń będzie wyłączony).

[Tomasz R. Gwiazda]

pytalem wczesniej w "niewlasciwym" watku...

czy czujniki (plytka z prockiem) i tuba - beda mialy jakas obudowe?

[Szopler]

Na chwilę obecną niestety nie.
Kupiłem co prawda 5 różnych obudów, ale bez znacznych przeróbek płytki i/lub samej obudowy czujnik nie wejdzie :(

Może w n-tej wersji hardware'u dopasujemy się do jednej z istniejących obudów, bo zamówienie obudowy na miarę przy naszych ilościach czujników nijak się nie opłaci.

[krzyszp]

Panowie krzyszp, Michal i TJM...

Trzeba ;)

aby czujnik sam obliczał średnią dajmy na to z ostatnich 7 dni i jak średnia z kilku ostatnich pomiarów przekroczy ją o 150-180% dawał znać brzęczykiem, że coś jest nie tak (nawet jak w prefsach brzęczyk dla pojedynczych zliczeń będzie wyłączony).

Mało realne na tę chwilę, biorąc pod uwagę, że w takim przypadku trzeba by obsługiwać przekazywanie danych do czujnika (wszak nie ma gwarancji, jak długo czujnik będzie podłączony do komputera, ktoś może używać go co drugi dzień na przykład), pojemność eprom'u w czujniku też nie jest ogromna (w stosunku do ilości pomiarów)...
Natomiast można oczywiście "wzniecić alarm" gdy wartość skoczy do np. 500uR/h (lub innej wartości określanej jako "niebezpieczna").

[Tomasz R. Gwiazda]

tak, myslalem.
Ale moze znajomek mi cos dopasuje bo on robil rozne czujniki sobie (temperatury, wilgotnosci) i w cos to zawsze pakowal

[Szopler]

Mało realne na tę chwilę, biorąc pod uwagę, że w takim przypadku trzeba by obsługiwać przekazywanie danych do czujnika (wszak nie ma gwarancji, jak długo czujnik będzie podłączony do komputera, ktoś może używać go co drugi dzień na przykład), pojemność eprom'u w czujniku też nie jest ogromna (w stosunku do ilości pomiarów)...
Natomiast można oczywiście "wzniecić alarm" gdy wartość skoczy do np. 500uR/h (lub innej wartości określanej jako "niebezpieczna").

Kod [Zaznacz] Rozwiń


kumulacja = 0;

W pętli:
kumulacja = kumulacja + pomiar_aktualny;

Średnia z pomiarów:
srednia = kumulacja / ilość prób 40 sekundowych

średnia jako wartość w RAM do porównywania na bieżąco + zapis do EEPROM na stałym adresie (2 bajty ?), żeby mieć odniesienie po włączeniu + ew. zapis ilości pomiarów z których była ta średnia wyliczona (aby można było kontynuować jej liczenie).

Po włączeniu do ramu zaciągana jest wartość z eeprom jako wzorzec. Oprócz tego w zmiennej w RAM jest na bieżąco określana aktualna średnia. Po jakimś czasie ta średnia zastępuje wartość w EEPROM.


[krzyszp]

Niezupełnie, trzeba by jeszcze timestampy zapisywać, uwzględniać deaktualizacje średnich (czujnik wyłączony przez np. tydzień), trochę się tego uzbiera... A w planach być może wyląduje obsługa GPS'a. Prościej by jednak było (chyba) obrabiać to na kompie i w razie czego alarm na czujniku (i ew. kompie) wszczynać.

[Szopler]

A'propo GPS'a -  możemy go obsłużyć na dwa sposoby:
- złączem SPI (programatora)
- via RS232 - podpiąć do pinów 2 i 3 uP + masa i zasilanie

[Troll81]

Kod [Zaznacz] Rozwiń

http://allegro.pl/tuba-geigera-sbm-20-1-dozymetr-czujnik-radiacji-i1805500814.html
http://allegro.pl/licznik-geigera-dozymetr-zestaw-do-skladania-9v-i1803499040.html


w tym drugim zestawie jest fajna tuba....

[Troll81]

Kod [Zaznacz] Rozwiń

http://www.centronic.co.uk/geiger_muller_tubes.htm

Kod [Zaznacz] Rozwiń

http://www.hellotrade.com/vacutec-messtechnik/geiger-mueller-tubes.html

Kod [Zaznacz] Rozwiń

http://www.canberra.com/products/463.asp

Kod [Zaznacz] Rozwiń

http://www.wholesalesecurityproducts.info/geiger-tube-counter/