Skocz do zawartości

Wrona

Użytkownicy
  • Zawartość

    62
  • Rejestracja

  • Ostatnio

Reputacja

5 Neutralna

O Wrona

  • Ranga
    4/10

Informacje

  • Płeć
    Mężczyzna

Ostatnio na profilu byli

Blok z ostatnio odwiedzającymi jest wyłączony i nie jest wyświetlany innym użytkownikom.

  1. Sam "goluśki" układ optoizolatora to zrozumiałe że za słaby. Jednak moduł który oprócz optoizolatora zawiera jeszcze inne podzespoły to można by już przygotować do cięższej pracy skoro do tego się go wykorzystuje? To oczywiście pytanie retoryczne bo to kwestia producenta czy dołoży jeszcze dwa elementy do układu czy nie. Zresztą się nie znam to się nie wypowiadam. Tak czy inaczej, sprawa jest zamknięta bo sugestia @atMegaTona trafia w punkt i problem jest rozwiązany a wszystko śmiga jak należy. Na razie jest to jedna dioda mocy ale w przyszłości to się może zmienić na wiele takich diod więc zasilanie Arduino przez USB i zasilanie diod postanowiłem już teraz odizolować. Nawet jeśli nie pomorze to na pewno nie zaszkodzi. Nie zabieram Wam więcej czasu w tej kwestii bo sam mam czasu jak na lekarstwo. Więc do następnego razu gdy znów będę miał okazje do pochwalenia się swą ignorancją
  2. Dzięki. Jakoś sobie tak głupio pomyślałem że skoro kupuje moduł to jest on już gotowy do pracy i tylko podłączę wejścia/wyjścia i gotowe. Raz jeszcze dziękuje za celną uwagę.
  3. Zadanie wydawało się banalne ale jak to u mnie znów co najprostsze to najdłużej jest problematyczne. Arduino podaje stan wysoki do przekaźnika a ten załącza zasilanie diody LED 3W. Wszystko działa pięknie ale zamiast przekaźnika zamarzył mi się optoizolator. Mam dwa (poniżej linki) i w obu ta sama sytuacja czyli dioda LED świeci bardzo słabo. Nigdzie w kartach produktów nie znalazłem informacji by problemem było obsłużenie na wyjściu 650mA i kilku Voltów przez optoizolator. Zapewne umyka mi jakaś oczywistość. Ktoś wskaże drogę? https://botland.com.pl/pl/konwertery-pozostale/9909-optoizolator-czterokanalowy-a87-tlp281.html?search_query=optoizolator&results=6 https://botland.com.pl/pl/konwertery-pozostale/1937-optoizolator-dwukanalowy-ild213t-modul-sparkfun.html?search_query=optoizolator&results=6
  4. @marek1707 Dużo ciekawych pytań ale jeszcze za wcześnie na rzeczowe odpowiedzi. Czy moduł czujnika się sprawdzi w praktyce to się dopiero okaże, a jeśli zawiedzie to zacznie się szukanie czegoś innego. Jak konfiguracje kanału pomiaru i oświetlacza będzie się sprawować najlepiej to też pokażą testy praktyczne. Co do „komercyjny” czy „planami na produkcje” to jest to dla mnie obce środowisko. Brzydzę się tą sferą co nie znaczy że ją potępiam u innych osób. Tak jak ktoś brzydzący się pająków nie musi potępiać arachnologów. Pewnie gdybym coś sensownego i naprawdę nowatorskiego wymyślił to bym się tym dzielił na lewo i prawo (może tylko bym zadbał by żaden niegodziwiec sam nie mógł tego opatentować). Jednak nie zanosi się na wielkie odkrycie a jedynie dłubie sobie coś tam na warsztacie, co na nobla nie zasługuje, ale mnie się przyda. Nie ma więc tzw. „dedlajnu”. Coś zrobię i jak nie zadział to skombinuje coś inaczej a jak zadziała to może rozwinę projekt o nowe funkcjonalności. Bez ciśnienia w gaciach Skoro masz doświadczenie z systemami pomiaru to mam pytanie odnośnie projektu rozłożonego na innym stole w warsztacie. Do różnych układów pomiarowych przydałby się czujnik CO2. Z tego co zauważyłem czujniki CO są stosunkowo tanie a te do CO2 znacznie droższe. Poleciłbyś coś konkretnego do CO2 żeby mi gładko pracowało w Arduino i by taki gamoń jak ja dał sobie z tym radę (gotowa biblioteka). Zakres pomiaru miałby dotyczyć poziomu CO2 naturalnego dla świeżego powietrza tj. 0,03% i układ miałby dokonywać głównie pomiaru jego wzrostu w pomieszczeniu.
  5. @marek1707 Dzięki. W swoich analizach czasu uwzględniam poprawkę na te opóźnienia wynikające z obliczeń milisekund bo mam je też "zwymiarowane". Jednak na wszelki wypadek spróbuje to zrobić tak jak mi podpowiedziałeś i zobaczę czy wychodzi jakaś różnica. Raz jeszcze dzięki. Będzie to pomiar dla przepływającego płynu. Jeśli mi braknie fotonów to spróbuje z diodą NIR o wyższej mocy a mam do wyboru 1W lub 3W a może i 10W (nie sprawdzałem czy są takie w zakresie NIR) więc na razie o to się nie boje.
  6. @marek1707 Trochę nie potrzebnie się nakręciłeś. Nie ma jakiegoś tajnego kodu który przed Toba ukrywam. Pokazałem prostą pętle którą cały czas modyfikuje by porównać uzyskiwane wyniki. Np. taki "eksperymencik". #include <Wire.h> #include <AS726X.h> AS726X sensor; byte GAIN = 3; byte MEASUREMENT_MODE = 2; byte czasNIR = 1; unsigned long start ="0"; void setup() { Wire.begin(); Wire.setClock(400000); Serial.begin(115200); sensor.begin(Wire, GAIN, MEASUREMENT_MODE); sensor.setIntegrationTime(czasNIR); start = millis(); Wire.setClock(400000); Serial.println(((millis()-start)/1000.0), 3); sensor.takeMeasurements(); Serial.print(((millis()-start)/1000.0), 3); Serial.print('\t'); Serial.println(sensor.getTemperature()); Serial.print(((millis()-start)/1000.0), 3); Serial.print('\t'); Serial.println(sensor.getCalibratedR()); Serial.print(((millis()-start)/1000.0), 3); Serial.print('\t'); Serial.println(sensor.getCalibratedS()); Serial.print(((millis()-start)/1000.0), 3); Serial.print('\t'); Serial.println(sensor.getCalibratedT()); Serial.print(((millis()-start)/1000.0), 3); Serial.print('\t'); Serial.println(sensor.getCalibratedU()); Serial.print(((millis()-start)/1000.0), 3); Serial.print('\t'); Serial.println(sensor.getCalibratedV()); Serial.print(((millis()-start)/1000.0), 3); Serial.print('\t'); Serial.println(sensor.getCalibratedW()); Serial.println(((millis()-start)/1000.0), 3); Wire.setClock(100000); start = millis(); Serial.println(((millis()-start)/1000.0), 3); sensor.takeMeasurements(); Serial.print(((millis()-start)/1000.0), 3); Serial.print('\t'); Serial.println(sensor.getTemperature()); Serial.print(((millis()-start)/1000.0), 3); Serial.print('\t'); Serial.println(sensor.getCalibratedR()); Serial.print(((millis()-start)/1000.0), 3); Serial.print('\t'); Serial.println(sensor.getCalibratedS()); Serial.print(((millis()-start)/1000.0), 3); Serial.print('\t'); Serial.println(sensor.getCalibratedT()); Serial.print(((millis()-start)/1000.0), 3); Serial.print('\t'); Serial.println(sensor.getCalibratedU()); Serial.print(((millis()-start)/1000.0), 3); Serial.print('\t'); Serial.println(sensor.getCalibratedV()); Serial.print(((millis()-start)/1000.0), 3); Serial.print('\t'); Serial.println(sensor.getCalibratedW()); Serial.println(((millis()-start)/1000.0), 3); } void loop() { } Jak widzisz nic specjalnego tam nie ma. Pozwoliło mi to natomiast określić ile mogę "wyciągnąć" z mojego układu. Wiem już nie ma znaczenia czyli prędkość "seriala" to 9600 czy 115200. Wiem już że prawidłowo działa funkcja sensor.setIntegrationTime(); i faktycznie podanie tam 255 lub 0 daje odczyty co około 1,4 czyli 2*0,7s (gdy byte GAIN ustawiam na 2 lub 3) co dokładnie zgadza się z nota katalogową. To co daje zauważalne oszczędności to ustawienie zegara I2C na 400000 i to jest nowość której wczoraj nie udało się osiągnąć a dziś już tak (dzięki Ci @ethanak ). Oczywiste jest, że nie ma znaczenia czy wszystko jest w "setup" (jak powyżej) czy w "loop". Jednak najważniejsze jest, że nie ma znaczenia czy pomiar jest realizowany przez powyższy kod czy pętle pomiarową wsadzę do jakiegoś większego ze swoich kilku projektów. Wniosek jest taki że, pozostała część kodu nie ma znaczenia więc wklejanie tu kilkanaście razy dłuższego kodu, podczas gdy kwestia dotyczy jego maleńkiego fragmentu mija się z celem, bo mało kto ma czas by czytać moje koderskie wypociny, które nic nie wnoszą do problemu. Wracając do meritum. Jako że jest to moja pierwsza tak poważna próba analizy problemu w informatyce (choć nie widziałem zapewne prawdziwych problemów z jakimi stykają się programiści) to wysnuwam pewne wnioski i proszę tylko o opinie czy są słuszne. Mianowicie ... manipulując bitem w funkcji sensor.setIntegrationTime(bit) osiągam dla bit=255, czas trwania funkcji sensor.takeMeasurements() na poziomie 1,47s. Teoretycznie powinienem dla podanej wartości bit=1 osiągać 0,0055s a osiągam obecnie 0,033 (wynik już po odjęciu obsługi Serial.print() i millis()). Wnioskuje więc że być może te brakujące 0,0275s to czas na obsługę biblioteki czujnika. Czy to słuszny kierunek myślenia? Na razie zrobię wersje kodu który poda wyniki czasu dla każdego z wariantów integracji od 1 do 255 i zobaczę jak wyniki teoretyczne rozbiegają się z rzeczywistymi jakie osiągam.
  7. Tak wiem o tym. Ale moja wątpliwość nie dotyczyła powodów dla których ustawienie "1" nie skraca pomiaru tylko dlaczego "255" go nie przedłużało do prawie 1s. Rozgryzę to wkrótce. To wszystko też wiem. Nie wspominam o tym bo wszystkie te "bulby" są mi kompletnie nie potrzebne i z nich nie korzystam Zaskoczę Cię, wiec trzymaj się poręczy. Dlatego właśnie nie napisałeś niczego nowego czyli nic czego bym nie wiedział bo znam dokument do którego link podałeś. Dzięki jednak za zainteresowanie. Dziś lub jutro będę eksperymentował z różnymi wariantami prostego kodu który nic innego prócz pomiarów nie będzie robił. Jeśli natknę się na jakiś problem i będę miał pytania to napisze.
  8. Tak sobie pomyślałem, że na razie nie ma sensu zagrzebywać się w pisanie własnej biblioteki do wysyłania danych czy tworzenia tablic wyników wewnątrz programu, bo ... ze wszystkich prób wynika że obsługa Serial.print() i milis() to jedynie 0,007s czyli nie oszczędzę na tym. Nawet gdybym podołał zbyt ambitnemu jak na mnie zadaniu, napisania perfekcyjnego protokołu wysyłania danych to oszczędziłbym w super optymistycznym scenariuszu 0,005s a to się ma nijak do tego że sama funkcja takeMeasurements() połyka 0,052s a getCalibratedR() i inne kanały to po 0,031s. Do momentu aż tu nie znajdą się porządne oszczędności (o ile to w ogóle możliwe) to szukanie innych mija się z celem. Spróbuje powalczyć setIntegrationTime() bo tutaj zmiany od 0 do 255 niczego nie zmieniają choć powinny w szerokim zakresie (sięgając prawie 1s). Dobrze myślę, czy już bredzę od tego ślęczenia przed monitorem?
  9. void setup() { Wire.begin(); Wire.setClock(400000); Serial.begin(115200); sensor.begin(Wire, GAIN, MEASUREMENT_MODE); lcd.begin(16,2); } Rozpatruje taką możliwość. Będzie tego od 50 do 100 tysięcy różnych pomiarów z kilku minut (mniej jeśli zamiast kilku będzie badanych tylko jeden kanał NIR). Przypuszczam jednak że znów pojawi się problem z pamięcią dynamiczną.
  10. Toś mnie bracie uradował wiadomością że nie jest to nie możliwe. Gorsza wiadomość jest taka że na razie to "dukam" kodem w Arduino więc pisanie własnych funkcji do transmisji brzmi przerażająco. Tematem się jednak zainteresuje, choć w tym momencie mam wrażenie że jakbym sam napisał te funkcje to byłyby jeszcze gorsze pod względem wydajności od Arduinowskich
  11. Robiłem testy różnorodne. Wypełniałem Serial.print() a w zasadzie ich całe zespoły tekstami by miału co wysyłać zamiast pomiarów NIR. Wykonywałem pomiary ale ich nie wysyłałem. Wysyłałem teksty zastępcze jednocześnie wykonując nie wysyłane pomiary. Włączałem i nie włączałem sensor.takeMeasurements() w przebiegu funkcji pomiarowej i mnóstwo innych kombinacji. Za każdym razem skrupulatnie notowałem uzyskane wyniki by potem porównać i wnioskować co pożerało najwięcej czasu. Same wielokrotne Serial.print(), nawet wypełnione dziesiątkami znaków pozwalały mi osiągać wymarzone 0,02s a nawet spokojnie 0,01s a niżej to już nie sprawdzałem bo żadna to pociecha gdy sam sensor.takeMeasurements() którego potem nawet nie wysyła się w Serial.print() potrzebuje około 0,05s a odczyt wszystkich 6 kanałów nawet bez wysyłania to 0,20s czyli nie ma przeproś i pomiar to 0,25s. Ustawiłem i niczego to w wynikach czasu nie zmieniło. Co dziwne LCD16x2 z konwerterem śmiga, może dlatego że to PCF8574AT (ale nie znam się tylko zmyślam). Ale dzięki za pomysł bo właśnie pokazałem mi kolejne ustawienie którego nie znałem.
  12. @kaczakat Tak, przeprowadziłem pomiary dla konkretnego mojego przypadku. Czas wykonania funkcji Serial.print() jest zaniedbywalny w stosunku do tego że funkcja sensor.takeMeasurements() potrzebuje około 0,05s a odczyt wszystkich 6 kanałów to 0,20s czyli razem pomiar 0,25s. Tego chyba nie przeskoczę i muszę wybrać albo pomiary jednokanałowe ale częściej albo wszystkie kanały równocześnie ale w "ślimaczym tempie". Jakoś to przeżyje ale jakby ktoś ... coś ... w temacie miał do zaproponowania ... to ja chętnie.
  13. "Jak nie, jak tak", "Chroniczny Pytajniku" Ale pisząc wprost a nie dziwnym kodem odpowiadam. Ustawiona prędkość to właśnie 115200. A co do kwestii rodzaju transmisji to ... jest to konstruktywna sugestia i zaraz zainteresuje się tematem.
  14. To to ja oczywiście wiem. W praktycznym zastosowaniu "czas pomiaru" to cały okres zawierający zarówno sam czas dokonywania pomiaru jak i czas związany z jego drogą do monitora portu szeregowego. Właśnie dlatego pytam o możliwości zaoszczędzenia na wszystkim co można ograniczyć na tej drodze. Próbowałem eksperymentować np. z "printMeasurements(); --- Fetches data from memory and outputs calibrated measurements " ale dostaje komunikat o niezdefiniowaniu takiej funkcji. Spróbuje się dobrać do biblioteki ale raczej jestem za cienki by tam coś gmerać.
  15. Chyba nie do końca zrozumiałem intencje pytania gdyż ty na pewno znasz odpowiedz na to pytanie które brzmi "Nie". Chciałeś chyba zasugerować (odnośnie mojego pytania 2) by spróbować wysłać wszystko za jednym podejściem. Właśnie w tym kierunku kombinuje. Szukam jednak jeszcze innych ewentualności, bo skoro dla samego kanału R wynik to 0,032s a dla samego kanału Temperatury wynik to 0,011s, to być może jest tu jakiś ukryty potencjał na oszczędności. I tu, wracamy do mojego pytania 1 co z tym "byte integrationValue"? Edit: Wysłanie wszystkiego za pośrednictwem jednego Serial.println() nie zmienia czasu który nadal wynosi 0,2s a chciałbym by było 0,02s.
×
×
  • Utwórz nowe...