Wyświetlacz widma audio – ESP32 i 399 WS2812B

[ethanak]

Dodaj jeszcze żar na dole, postaw na tym dwa srebrne świeczniki, zegar i rodzinną fotografię w ramkach - będziesz miał najbardziej zajefajny kominek na świecie

Z tym żarem to ja na serio... reszta według uznania

[Gieneq]

@ethanak Podoba mi się  W podstawie przewidziałem miejsce na kilka ledów to razem z dolnym wierszem matrycy mogą stworzyć taki jakby żar.

[Gieneq]

Elektornika - final?

Kolejne podejście do wzmacniacza ale tym razem w środowisku docelowy. Do tej pory testowałem wyświetlacz podłączając do laptopa z wykręconą na maxa głośnością, żeby coś było widać. Sygnał audio przechodził dalej na wzmacniacz skręcony na minimum... pomysł beznadziejny zwłaszcza jak trafi się wyjątkowo słabe źródło audio.

W obudowie przygotowałem otwór na przyciski i złącza jack, okazało się że jest tam trochę płytko ale nie ma tragedii:

Dodałem jeszcze kilka przycisków, bo może się przydadzą. Docelowo ma być integracja z Home Assistant ale jak zabraknie WiFi to dobrze by było jakoś móc tym sterować.

Po licznych testach zdecydowałem się na układ TDA2822. Zasilanie 5V, ale wyjście ma być na 3,3V dla ESP32. Schemat w większości to kit AVT 1782:

Wyrzuciłem z wejścia rezystor 10k i dałem tam sam potencjometr. Zauważyłem ciekawe zjawisko, które udało się zniwelować kondensatorem:

Przy poprzednich testach sygnał był trochę zaszumiony. Choć taka płytka jest daleka od standardów audio, to najwyraźniej użycie przewodów audio trochę pomogło. Nie jestem w stanie powiedzieć od jakich częstotliwości liczy się efekt skórny, ale po coś używa się specjalne przewody w audio.

Wróciłem do pomysłu z mikrofonem, działa on wtedy, gdy nie jest włożony wtyk jack. Przy testach okazało się, że nie jest to zbyt przydatny dodatek - do muzyki się średnio nadaje, a jedną frajdę sprawia klaskanie - jedno klaśnięcie włącza elektroniczny kominek 

Nie ma co marudzić, najważniejsze że działa wzmacniacz jacka. No właśnie, a jak to działa? Czas na kilka testów.

Odpaliłem mój ulubiony generator sinusoidy i sprawdziłem jak mają się wzmocnienie i przesunięcie w fazie w zależności od częstotliwości:

Dane zebrałem w tabelach:

a dla fanów wykresów:

To co widać przy wzmocnieniu (rozrzut) to niestety moje niechlujstwo w pomiarach - najbardziej interesowało mnie czy wzmocnienie jest stałe w całym przedziale 0-20kHz i jak już zauważyłem, że taki trend się utrzymuje to niekoniecznie uśredniałem wahające się wyniki. Czyli układ działa  

Dobrze, że zamówiłem 2 płytki plexi bo trochę nie trafiłem z otworami i wyszły takie sobie. Niemniej układ działa, można podłączyć jacka, puścić muzykę, doregulować potencjometrem i cieszyć się efektami. Oczywiście, niemienie miesiąc a na pewno coś tam rozgrzebię 

Co dalej? Trzeb dopieścić obudowę, wzmocnić tył, trochę oczyścić miejsca klejenia - niestety takie uroki prototypu. Do zrobienia jest jeszcze sporo ale już widać efekty. Filmik niedługo  

[MR1979]

Pomiary i wykresy super! Fajnie jest sprawdzić czy teoria sprawdza się w praktyce I jednocześnie potwierdzasz że układ działa poprawnie.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Gieneq]

Refaktoryzacja

Nie pracowałem nigdy w prawdziwych projektach programistycznych, ale legenda głosi, że przez większość czasu refaktoryzyje się kod. Dlatego zrobiłem osobną gałąź na gicie i zabrałem się za psucie kodu. Wymarzyłem sobie, że w pliku main.cpp będzie prawie nic i się udało!

Przygotowałem następujące pliki:

• main.cpp - wejście programu,
• ffthsv.h/cpp - główna część programu, funkcje aktualizujące dla obu rdzeni, rysujące efekty, punkt zaczepienia FFT,
• analyser.h/cpp - aktualizacja próbek, kod FFT, wstępnym przekształceniem danych wyjściowych,
• effects.h/cpp - pole do popisu przy tworzeniu efektów,
• bands.h - dystrybucja kubełków FFT,
• presets.h - różne stałe i typy danych w tym handler funkcji efektów.

Plik main.cpp jest teraz naprawdę minimalistyczny:

#include <Arduino.h>
#include "presets.h"
#include "effects.h"
#include "ffthsv.h"

effect_handler_t fire_effect_handlers[] = {fire_effect};

void setup() {
    Serial.begin(115200);
    FFTHSV_begin();
    FFTHSV_set_effects(fire_effect_handlers, 1);
    FFTHSV_select_effect(0);
    FFTHSV_benchmark_params(10,20000,200,10000);
    FFTHSV_benchmark(false);
}

void loop() {
    FFTHSV_update();
}

Można tu zauważyć nowe funkcje ze rdzenia programu "FFTHSV_xx". Do programu można dodać własne efekty funkcją FFTHSV_set_effects. Jako argument przyjmuje tablicę wskaźników na funkcje efektów - o tym później.

Benchmark

Widać jeszcze benchmark - jest to nieblokująca funkcja, która generuje próbki i scroluje po całym wyświetlaczu. Argumenty to:

void FFTHSV_benchmark_params(double min_freq, double max_freq, int steps, long evaluation_time_ms) {
    benchmark_time_ms = evaluation_time_ms;
    benchmark_steps_count = steps;
    benchmark_step_interval = long(1.0*evaluation_time_ms/steps);
    benchmark_step = 0;
    benchmark_min_freq = min_freq;
    benchmark_max_freq = max_freq;
    benchmark_exp_factor = pow(max_freq/min_freq, 1.0/benchmark_steps_count);
}

Warto podkreślić jaka jest charakterystyka funkcji - jest to funkcja wykładnicza dlatego że wyświetlacz też ma taki charakter - niskie częstotliwości są rozłożone co dosłownie kilkadziesiąt Hz, a wysokie nawet co setki-tysiące Hz. Dlatego przy pomocy prostego podstawienia wyznaczam wzór funkcji. Na początek ustalam 2 punkty:

i wiem, że funkcja ma postać:

gdzie f to częstotliwość, x to krok, a i b to współczynniki odpowiadające kolejno za skalę/przesunięcie w pionie i rozciągnięcie w poziomie. Teraz podstawiam i wyprowadzam współczynniki a i b:

widać to w powyższym kodzie programu  Dzięki temu animacja przesuwa się równomiernie, a nie jak w przypadku funkcji liniowej połowe drogi pokonuje w ułamku sekundy, a resztę przez pozostałe kilka sekund.

Po co w ogóle ten benchamrk? Dlatego, że miałem wątpliwość czy aby na pewno próbkowanie działa poprawnie. Okazało sie, że jest ok. Popróbowałem kilku wariantów okien, o których teraz nie będę się rozwodził, ale okno Hamminga jednak faktycznie jest dobre w 95% przypadków.

Kod aktualizacji trafił oczywiście do funkcji update związanej z rdzeniem 1:

/*
 * CORE 1 - CALC EFFECTS & DRAW
 */
void FFTHSV_update() {
    //BENCHMARK
    if(benchmarking){
        if (millis() - last_benchmark_time > benchmark_step_interval) {
            int benchmark_freq = benchmark_min_freq * pow(benchmark_exp_factor, benchmark_step);
            FFTHSV_set_test_frequency(benchmark_freq);
            Serial.print("Benchmark[Hz]:");
            Serial.println(benchmark_freq);
            ++benchmark_step%=benchmark_steps_count;
            last_benchmark_time += benchmark_step_interval;
        }
    }
  //...
}

Tu akurat nie ma nic szczególnego - programowy timer i wyznaczanie wartości funkcji.

Efekty

Do tej pory pisanie efektów to było gmeranie w funkcji rysującej, gdzie miałem kaskadę ifów i w każdym coś związane z efektem. Ale gdy zacząłem pisać ten sam kod do 2 ifów to doszedłem do wniosku, że kod zaczyna śmierdzieć... co to było?

Wymyśliłem, że wyznaczę coś co nazwałem energią - może jest to nietrafione pojęcie ale trudno. Energia to tak naprawdę suma wysokości słupków, a najważniejsza jest pochodna czyli różnica w pewnym odstępie czasu, obrazująca jak szybko zmienia się wykres najlepiej względem wartości średniej. Dzięki temu można było dokonać detekcji uderzeń. Wymyśliłem, że tak genialne narzędzie przyda się w kilku miejscach i tu problem - gdzie to ulokować.

/*
 * CALC BURST OF BRIGHTNES
 */
static void calc_energy_eval(int* bar_heights, double* bar_thrs, double* energy) {
    int sum_bar_thrs = 0;
    for (int display_x = 0; display_x < 3; display_x++)
        sum_bar_thrs += bar_heights[display_x];

    ++burst_end_index %= BURST_BUFFER_LEN;
    ++burst_front_index %= BURST_BUFFER_LEN;

    energy[energy_t::ENERGY_CURRENT] = double(sum_bar_thrs) / 3;
    burst_buffer[burst_end_index] = *energy;
    energy[energy_t::ENERGY_BURST] =
        burst_buffer[burst_end_index] - burst_buffer[burst_front_index];

    energy[energy_t::ENERGY_MEAN] = 0.0;
    for (int burst_i = 0; burst_i < BURST_BUFFER_LEN; burst_i++)
        energy[energy_t::ENERGY_MEAN] += burst_buffer[burst_i];
    energy[energy_t::ENERGY_MEAN] /= BURST_BUFFER_LEN;

#if DEBUG_FPS == 1
    Serial.print("TB:");
    Serial.print(total_brightness / 10.0);
    Serial.print(", ");
    Serial.print("Energy:");
    Serial.print(energy);
    Serial.print(", ");
    Serial.print("Mean_energy:");
    Serial.print(mean_energy);
    Serial.print(", ");
    Serial.print("Burst_energy:");
    Serial.println(burst_energy);
#endif
}

Uzyskane 3 parametry: aktualna wartość, różcina (pochodna) i średnia umieściłem w tablicy typu double z indeksami w postaci enuma:

typedef enum {
    ENERGY_CURRENT,
    ENERGY_BURST,
    ENERGY_MEAN
} energy_t;

Po refaktoryzacji kod ten został przeniesiony do funkcji update (ciąg dalszy tego co wyżej:

  //...
    // UPDATE
    if (millis() - last_time_update > UPDATE_INTERVAL_MS) {
        dt = (millis() - last_time_update) / 1000.0;  // secs

        for (int i = 0; i < BANDS_COUNT; i++) bars_threshold[i] = mags[i];

        calc_movement(bars_threshold, bars_pos, velocities, gravity, BANDS_COUNT, dt, diffs);

        for (int i = 0; i < BANDS_COUNT; i++)
            bars[i] = constrain(int(bars_pos[i]), 0, 21);

        calc_energy_eval(bars, bars_threshold, energy);
        effects_options[current_effect_index](bars, bars_threshold, energy, display_leds, base_leds);

        last_time_update += UPDATE_INTERVAL_MS;
    }

    // DRAW
    if (millis() - last_time_draw > DRAW_INTERVAL_MS) {
        FastLED.show();
        last_time_draw += DRAW_INTERVAL_MS;
    }
}

Widać tu też dość długą, ale przydatną funkcję:

effects_options[current_effect_index](bars, bars_threshold, energy, display_leds, base_leds);

Z tablicy wybieram wskaźnik na funkcję wybranego efektu i używam go z parametrami tak jak w typie danych:

typedef void (*effect_handler_t)(const int* bar_heights, const double* bar_thrs, double* energy, CRGB* display_leds, CRGB* base_leds);

Dzięki temu mam bardzo wygodne narzędzie do projektowania własnych efeketów  W plikach effects.h/cpp jest właśnie na to miejsce. Na począteke plik nagłówkowy:

#pragma once
#include "Arduino.h"
#include "FastLED.h"
#include "presets.h"

constexpr int NOISE_FLAMES_count = 128;
const uint8_t NOISE_FLAMES[] = {199, 218, 234, 245, 252, 255, 253, 248, 239, 228, 216, 204, 191, 180, 170, 163, 157, 154, 152, 152, 153, 155, 157, 159, 160, 160, 159, 157, 154, 151, 147, 143, 139, 136, 134, 133, 133, 134, 136, 138, 140, 143, 144, 146, 146, 145, 143, 140, 136, 131, 127, 122, 119, 116, 114, 114, 114, 116, 119, 123, 127, 131, 135, 137, 139, 139, 138, 136, 132, 128, 123, 119, 115, 112, 110, 110, 111, 114, 118, 124, 130, 137, 143, 148, 151, 153, 153, 151, 147, 141, 135, 127, 120, 114, 108, 105, 104, 105, 109, 115, 122, 131, 140, 148, 155, 160, 163, 162, 157, 150, 139, 126, 110, 94, 79, 64, 53, 44, 40, 40, 45, 55, 69, 87, 108, 131, 155, 178};

void fire_effect(const int* bar_heights, const double* bar_thrs, double* energy, CRGB* display_leds, CRGB* base_leds);

Widzimy tu opisywany niedawno sposób na migotanie ognia - stablicowana funkcja. Mamy też deklarację (prototyp) funkcji efektu ognia.

W pliku effects.cpp na początek przydatne funkcje widoczne tylko w tym pliku:

#include "effects.h"

/*
 * TOOLS
 */
inline int get_idx(int x, int y) {
  x = DISPLAY_W - x - 1;
  #if ZIGZAGING == 1
      return (x&1 ? DISPLAY_H - y - 1 : y) + x * DISPLAY_H; //todo - tablica?
  #else
      return y + x * DISPLAY_H;
  #endif
}

void inline set_hsv(CRGB* hsv_leds, int x, int y, uint8_t h, uint8_t s, uint8_t v) {
  hsv_leds[get_idx(x, y)] = CHSV(h,s,v);
}

I wreszcie kod mojego kominka 

/*
 * FIRE
 */
constexpr uint8_t FIRE_TONGUE_HUE[] = {12, 16, 32, 33, 34, 35, 36, 37, 37, 37, 37, 36, 35, 34, 33, 20, 19, 18, 255, 255, 255};
int burnt[DISPLAY_LEDS_COUNT];
constexpr uint8_t FIRE_HUE = 22; 
constexpr uint8_t BURNT_HSV_VALUE = 32;
constexpr uint8_t BURNT_HUE = 254;
constexpr long BURN_INTERVAL = 300;
long last_burn_time;
extern const uint8_t NOISE_FLAMES[];
int fire_twinkle_counter;
constexpr int FIRE_BASE_TICS = 6;
constexpr int FIRE_RANDOM_TICS = 24;
int total_brightness = MIN_BRIGHTNESS;
long last_burst_time;
constexpr int BRURST_INTERVAL = 2;

void fire_effect(const int* bar_heights, const double* bar_thrs, double* energy, CRGB* display_leds, CRGB* base_leds){
    ++fire_twinkle_counter;

    static int reduce_burn;
    if(millis() - last_burn_time > BURN_INTERVAL){
      reduce_burn = 1;
      last_burn_time += BURN_INTERVAL;
    }

  int base_hue = constrain(int(energy[energy_t::ENERGY_MEAN]), 0, DISPLAY_H);
  for(int base_x = 0; base_x < BASE_LEDS_COUNT; base_x++)
    base_leds[base_x] = CHSV(FIRE_TONGUE_HUE[base_hue], 255,255);
  

    if(total_brightness < TOP_BRIGHTNES/2) {
      if(energy[energy_t::ENERGY_CURRENT] - energy[energy_t::ENERGY_MEAN] > 4)
        total_brightness = TOP_BRIGHTNES;
    }


    if (millis() - last_burst_time > BRURST_INTERVAL) {
      if(total_brightness > MIN_BRIGHTNESS)
        total_brightness-=5;
      if(total_brightness < MIN_BRIGHTNESS)
        total_brightness = MIN_BRIGHTNESS;

      last_burst_time += BRURST_INTERVAL;
    }

    FastLED.setBrightness(total_brightness);

    for(int display_x = 0; display_x < DISPLAY_W; display_x++) {
      for(int display_y = 0; display_y < DISPLAY_H; display_y++)
        set_hsv(display_leds, display_x, display_y, 0,0,0);

      for(int display_y = 0; display_y < bar_heights[display_x]; display_y++) {
        int factor = DISPLAY_H - (bar_heights[display_x] - display_y - 1) - 1; // dla BH=4, 17, 18, 19, 20
        uint8_t fire_hue = FIRE_TONGUE_HUE[factor];

        uint8_t fire_saturation = 255;
        if(factor < 10)
          fire_saturation -= (10-factor-1) * 28;

        uint8_t fire_value = 255;
        if(factor > 9 && factor < 21){
          fire_value = NOISE_FLAMES[(fire_twinkle_counter + display_y + display_x*6)%128];
          
          if(factor > 9 && factor < 17){
            //factor: 10...16
            double mix_factor = (factor - 10)/6.0;
            fire_value = (mix_factor * fire_value + (1.0 - mix_factor) * 255); //mix
            if(fire_value>255)
              fire_value = 255;
          }
        }

        set_hsv(display_leds, display_x, display_y, fire_hue, fire_saturation, fire_value);
        burnt[get_idx(display_x, display_y)] = FIRE_BASE_TICS + random(FIRE_RANDOM_TICS);
      } 

      for(int display_y = bar_heights[display_x]; display_y < DISPLAY_H; display_y++) {
        int idx = get_idx(display_x, display_y);
        if(burnt[idx] > 0){
          set_hsv(display_leds, display_x, display_y, BURNT_HUE, 255, BURNT_HSV_VALUE);
          if(reduce_burn == 1)
            burnt[idx]--;
        } else
          set_hsv(display_leds, display_x, display_y, 0, 0, 0);
      }
    }
}

Jak widać użycie funkcji z licznymi argumentami bardzo pomaga - są to wskaźniki na tablice, nie kopiuję wartości, no co najwyżej kopia na stos adresu wskaźnika. O tym jak to działa pisałem ostatnio, ale teraz tylko dopowiem jak użyłem zmiennej energy.

Fire burst

Tym razem zmieniam ogólną jasność wyświetlacza - dla uderzenia jasność ma gwałtownie skoczyć i później opaść. Odpowiada za to ta część kodu:

      if(total_brightness < TOP_BRIGHTNES/2) {
        if(energy[energy_t::ENERGY_CURRENT] - energy[energy_t::ENERGY_MEAN] > 4)
          total_brightness = TOP_BRIGHTNES;
      }


      if (millis() - last_burst_time > BRURST_INTERVAL) {
        if(total_brightness > MIN_BRIGHTNESS)
          total_brightness-=5;
        if(total_brightness < MIN_BRIGHTNESS)
          total_brightness = MIN_BRIGHTNESS;

        last_burst_time += BRURST_INTERVAL;
      }

      FastLED.setBrightness(total_brightness);

Jeżeli energia wykresu przekroczy średnią energię o 4 paski to gdy jasność dostatecznie spadła to ma na nowo podskoczyć. Bez tego dodatkowego warunku, w utworach wysokiej zmienności, jasność tkwiła na stałym, bardzo wysokim poziomie. Teraz tylko uderzenia powodują skok. Dzięki temu, wyświetlacz naprawdę ożył, patrząc na animację można "poczuć" dźwięk.

Na ten moment można cieszyć się ładną animacją ognia. Ma teraz plan przenieść pozostałe animacje i trochę je wzbogacić. Myślę, że można dodać więcej narzędzi, które będzie można obliczać na zewnątrz efektów (w funkcji update), a używać ich wartości wewnątrz funkcji obsługi. Chcę też użyć do czegoś 4 przyciski z tyłu obudowy - do tego przyda się osobna funkcja.

Przyciski

Obsługa przycisków to pewnie kolejna nieblokująca pętla w której będę sprawdzał naciśnięcia, czasy itp i będę wyzwalał funkcje obsługi przycisków dla zdarzeń:

• on_press - zbocze 0 na 1,
• on_relese - zobcze 1 na 0,
• on_longpress - gdy dostatecznie szybko nie zajdzie on_relese.

Na pewno przydadzą się funkcje:

• benchmark,
• automatyczne przełączanie efektów,
• wybór efektu.

Myślę też nad dodaniem inteligentego wybierania efektów - np te płomyki wyglądają dobrze ze spokojnymi utworami, a do tych szybszych można by dodać inny efekt. Zobaczymy  

 

Edytowano 4 stycznia przez Gieneq

[Zealota]

Brakuje jeszcze tylko "porządnego" filmu z działania

[ethanak]

21 minut temu, Gieneq napisał:

te płomyki wyglądają dobrze ze spokojnymi utworami, a do tych szybszych można by dodać inny efekt.

O, i tutaj możesz wrócić do liczenia BPM-ów.

21 minut temu, Gieneq napisał:

Obsługa przycisków to pewnie kolejna nieblokująca pętla w której będę sprawdzał naciśnięcia, czasy itp i

Zerknij na kod Arduinowej biblioteki Bounce2 - tam masz dokładnie to co chcesz (fell, rose, currentDuration, previousDuration).

 

[Gieneq]

@Zealota będzie niedługo, jakoś za 2 tygodnie wrzucę konkrety. Mam problem... wyzwanie! z nagraniem tego żeby było ładnie widać szczegóły efektów, ale niestety nagrywanie LEDów nie jest takie proste.

50 minut temu, ethanak napisał:

O, i tutaj możesz wrócić do liczenia BPM-ów.

I taki mam plan. Ostatnio źle googlowałem... hasło "bpm analzyer github" dopiero dało trafne wyniki. Okazuje się, że są algorytmy które w czasie rzeczywistym dają przyzwoite wyniki, ale to spory temat. Nie jestem pewny czy ESP to udźwignie, ale i tak mam w planach ulepszenie sprzętu.

Tu jest całkiem ciekawe repo z kodem w C++ https://github.com/teragonaudio/BeatCounter

Jest też inne repo z kodem w Pythonie, od tego zacznę żeby zobaczyć jak w ogóle to działa. Podobno używa falki (ang. wavelet) do wyciągnięcia informacji o maksimach z których można oszacować BPM. Szczegóły pewnie zawarte są w tej pracy: http://www.cs.cmu.edu/~gtzan/work/pubs/amta01gtzan.pdf

Albo ten kod https://github.com/breakfastquay/minibpm tym razem hasło "beat per minute github" chwalą się że kod jest minimalistyczny w C++98, patrząc na tę funkcję wygląda jak to czego szukam, ale zobaczymy w praktyce  

double
MiniBPM::estimateTempoOfSamples(const float *samples, int nsamples)
{
    return m_d->estimateTempoOfSamples(samples, nsamples);
}

Będąc już przy wrzucaniu pdfów, to dla zainteresowanych polecam ten o oknach: https://download.ni.com/evaluation/pxi/Understanding FFTs and Windowing.pdf

1 godzinę temu, ethanak napisał:

Zerknij na kod Arduinowej biblioteki Bounce2

Faktycznie, dziękuję. Pamiętam że kiedyś o tym wspominałeś w kontekście tego co pisałem o Arduino.

    if (millis() - previous_millis >= interval_millis) {
        bool currentState = readCurrentState();
        if ( currentState != getStateFlag(DEBOUNCED_STATE) ) {
            previous_millis = millis();
            changeState();
        }
    }

Jakie piękne koło, jakie okrągłe i się toczy. Dokładnie takie same jak koło które właśnie wynalazłem  

[Gieneq]

@MR1979 @Zealota obiecany porządny filmik z działania. Wstrzymywałem się z premierą, wybierałem "piecyk" do tego kominka. Kilkoro moich znajomych kojarzy mój kanał na YT (tak ktoś z tych 12 subskrybcji...), a wymyśliłem sobie, że zrobię oficjalne otwarcie połączone ze spotkankiem.

Offtop: zdaję sobie sprawę, że kolumny powinny mieć na około więcej przestrzeni.

Największa porażka tego projektu to nieprzemyślenie połączeń pomiędzy urządzeniami - przecież żaden przyzwoity wzmacniacz nie ma na wyjściu jacka tylko cinche... na ostatnią chwilę robiłem "na taśmę klejącą"  połączenie pomiędzy źródłem a wzmakiem.

Efekt na żywo jest jak dla mnie rewelacyjny  widzowie nie zgłaszali uwag choć jest się czego przyczepić - np. w podstawie świeci tylko połowa LEDów, dlatego że nie chciał mi się poprawić połączenia. Ale przeciętni śmiertelnicy i tak odbierają takie zabawki inaczej niż twórca więc można śmiało obniżać normy

Na filmiku efekt kominka, w przyszłości pojawia się inne efekty i więcej nagrań.

 

Plany

Mam zamiar dodać kilka efektów – ESP32 ma spory zapas mocy i można się jeszcze pobawić zanim wejdę z FPGA. Problem w tym, że programowanie tego jest męczarnią. Sprzęt waży około 20 kg, ustawiłem go jako mebel i przenoszenie tego za każdym razem na stanowisko robocze jest niepraktyczne. Wymyśliłem, że albo podłączę RPi i będę wgrywał zdalnie kod, albo skorzystam z OTA.

OTA już kilka razy testowałem i działa całkiem dobrze. Musiałbym tylko zmienić kod tak by przy starcie ESP umożliwiał wgranie programu, a np. po wybraniu przycisku na rdzeniu 0 odpalany był kod związany z FFT.

Oczywiście temat BPM do przełączanie efektów.

Wciąż też brakuje integracji z Home Assistant. Do tego jakby mieć wpięte przekaźniki włączające wzmacniacz. Źródło ma w sobie wifi więc integracje by ładnie pasowały.

 

[MR1979]

@Gieneq Super projekt Zazdroszczę urządzenia (w pozytywnym znaczeniu) i życzę dalszych sukcesów

Sam może kiedyś się skuszę na podobny projekt, muszę tylko jakoś doprowadzić do końca obecny

PS: Fajny wzmacniacz

[Gieneq]

@MR1979 szczerze to nie jest aż tak skomplikowane, zależy kto w czym ma doświadczenie. Na początek możesz zrobić coś na mniejszej matrycy LED, albo multitool z twojej konsoli  tryb analizatora spektrum.

4 minuty temu, MR1979 napisał:

Fajny wzmacniacz

2h siedziałem w audiofilskim sklepie i robiliśmy odsłuchy. O dziwo ten model Yaqina jest całkiem dobry, ma uderzenie (coś czego wyższe modele na lampach KT88 nie mają) ale zarazem średnie i wysokie są bardzo przyjemne. Zwłaszcza przy gitarze akustycznej ładnie się sprawdza.

[ethanak]

59 minut temu, Gieneq napisał:

Musiałbym tylko zmienić kod tak by przy starcie ESP umożliwiał wgranie programu, a np. po wybraniu przycisku na rdzeniu 0 odpalany był kod związany z FFT.

Możesz jakoś przybliżyć co chcesz zrobić bo albo ja czegoś nie rozumiem albo coś kręcisz naokoło?

Tak przy okazji - aż by się chciało potraktować to ustrojstwo jako dwuwymiarowy ekran... np. iskierka lecąca ukośnie (albo jeszcze ciekawiej po paraboli)...

[Gieneq]

Dnia 17.01.2022 o 18:40, ethanak napisał:

Możesz jakoś przybliżyć co chcesz zrobić bo albo ja czegoś nie rozumiem albo coś kręcisz naokoło?

Niewykluczone, że coś kręcę, bo w ten temat jeszcze nie wchodziłem świadomie. Z tego co rozumiem WiFi jest obsługiwane na rdzeniu 0. Czyli jeżeli ja mu daję coś do roboty, to przy starcie mikrokontrolera nie mogę od razu dać od razu własną funkcję działającą na rdzeniu 0 tylko, no właśnie nie wiem co tam się odbywa. Interesowałby mnie menadżer WiFi, jakby w ogóle dało się używać WiFi i tego wszystkiego jednocześnie to byłoby świetnie, bo potrzebowałbym integracje z Home Assistant.

@ethanak masz pomysł jak mogę do tego dodać menadżer WiFi?

[ethanak]

52 minuty temu, Gieneq napisał:

Interesowałby mnie menadżer WiFi

Pytanie: po co menadżer WiFi do urządzenia, które stoi sobie w jednym miejscu i łączy się tylko z jedną domową siecią? Na dobrą sprawę możesz dane połączenia nawet wkompilować w kod, albo (jak chcesz mieć większą kontrolę) dać możliwość konfiguracji poprzez serial i zapisać to przez Preferences.

Jeśli startuje WiFi, to i tak urządzenie musi poczekać na połączenie zanim zacznie coś pokazywać... więc nie trzeba nic na tym rdzeniu 0 od razu uruchamiać.

A WiFi pracujący na rdzeniu 0 nie zajmuje całego czasu procka; sprawdź, zanim zaczniesz coś kombinować, bo być może szukasz problemu tam, gdzie go nie ma.

No i zamiast jakiegoś managera z fafnastoma opcjami których nigdy nie wykorzystasz możesz wrzucić coś takiego - czasu nie zajmuje dopóki jest połączony, automatycznie wznawia połączenie. Możesz mu dać jeszcze co najwyżej jakiegoś delaya w pętli oczekiwania, żeby ESP mógł w międzyczasie zrobić coś mądrego (np. wyświetlić na tych słupkach napis ERROR czy inny budujący tekst).

Masz tam miejsce na jakieś dodatkowe przyciski z tyłu? Jeśli tak, to w ogóle nie ma co mówić o jakichś menagerach - np. pierwszy przycisk to "restart w trybie AP" (coby można było z komórki dane poustawiać jak hasło w routerze zmienisz), drugi to "zwykły restart" i tak dalej... jak  tak mam w czytaku (włączenie zasilania z przytrzymaniem PLAY włącza interfejs WiFi, z przytrzymaniem FWD lub BACK włącza tryb AP).

Aha, jeszcze jedno. Pewnie od razu chodzi Ci po głowie AsyncWebServer - zapomnij, żre pamięć jak koń trawę i przy okazji robi niezłą sieczkę w tej co nie zeżarł.

 

[Gieneq]

@ethanak dziękuję, trochę zapoznałem się z tematem i widzę, że to nie jest takie trudne.

A takie pytanie, może też do innych użytkowników forum - jak ma się sterowanie diod programowalnych z Raspberry Pico? Przejrzałem wpisy dotyczące biblioteki FastLED, ale nie znalazłem żadnych konkretów. W repo Neopixel Adafruita wyraźne wskazano wsparcie dla PIO RP2040:

#if defined(ARDUINO_ARCH_RP2040)
  // Find a free SM on one of the PIO's
  sm = pio_claim_unused_sm(pio, false); // don't panic
  // Try pio1 if SM not found
  if (sm < 0) {
    pio = pio1;
    sm = pio_claim_unused_sm(pio, true); // panic if no SM is free
  }
  init = true;
#endif

"don't panic" dobre  

Zastanawiam się, który mikrokontroler lepiej radzi sobie z obsługą WS2812B, RP2040 czy ESP32?