Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

WiFi/VoIP pager oparty o ESP8266

ostrytomasz 07 Maj 2016 20:57 9702 15
  • WiFi/VoIP pager oparty o ESP8266
    Paging jest to jednokierunkowa komunikacja głosowa. W tej prostej aplikacji ESP8266 (moduł ESP-01 lub inny) służy za odbiornik strumienia RTP wysyłanego przez program PC. Przebieg analogowy generowany jest poprzez tzw. "fake-PWM" I2S znany z popularnego projektu dekodera mp3. W minimalnej formie do odbioru audio wystarczy zatem moduł ESP, zasilanie, filtr RC i słuchawki.
    W pierwotnym zamyśle zastosowaniem miało być automatyczne rozgłaszanie zapowiedzi słownych o ustalonych godzinach. Stosowny plugin do softphone nie powstał, więc używany przeze mnie "nadajnik" może być w tym momencie obsługiwany jedynie ręcznie. Nie powinno być też problemu z użyciem "biurkowego" telefonu VoIP jako nadajnika o ile posiada taką funkcję (typowo modele z BLF).
    WiFi/VoIP pager oparty o ESP8266
    Do poszczególnych przycisków programu PC przypisać można różne pliki wave (PCM S16 LE, 8Ksps dla strumieniowania G.711a/u) i różne adresy docelowe. Przy braku przypisanej zapowiedzi używane jest domyślne urządzenia audio (typowo mikrofon).
    WiFi/VoIP pager oparty o ESP8266
    Jakość odbieranego dźwięku jest niska - jak połączenie telefoniczne w telefonii analogowej. Ograniczenia to z jednej strony bardzo proste przetwarzanie cyfrowo - analogowe, z drugiej brak obsługi G.722 jako popularnego kodowania przy tym zastosowaniu (przy czym wydaje się, że nie ma przeszkód technicznych dla obsługi G.722). Dokuczać mogą też zakłócenia o charakterze cyfrowym przenoszące się przez zasilanie. Zależą one od filtrowania zasilania, ale trudno wyeliminować je całkowicie, przynajmniej nie udaje mi się na płytce stykowej - być może rozwiązaniem byłby osobny bufor PWM korzystający z niezależnie filtrowanego zasilania.

    Inne niedoróbki i problemy:
    - losowe problemy ze stabilnością (restarty co 5-20 minut strumieniowania, wydaje się że inni użytkownicy układu mieli już podobne problemy przy "dużym" ruchu UDP - tajemnicze logi "dev 1143" i "mac 674", być może uda mi się coś uzyskać od Espriff)
    - brak działania w trybie multicast - niewyjaśnione, do zdiagnozowania przydałoby się otwarte wifi lub linuksowy router z możliwością monitorowania pakietów - może być to jeden z wielu problemów UPC horizon do którego jestem obecnie podłączony, ze względu na niestabilną pracę tego AP pager też ma ustawiony dosyć duży bufor audio wprowadzając tym samym kilkaset ms opóźnienia
    - brak interfejsu konfiguracyjnego lub użycia smartconfig (wymagana kompilacja źródeł dla ustawienia danych punktu dostępowego, powinien działać też testowany przez krótki okres czasu tryb soft-AP)

    Źródła kompilowane były przy użyciu "nieoficjalnego" SDK w wersji 2.0.9 dla windows (wersja SDK: 1.5.0, NON-OS), można użyć make lub make + Code::Blocks.

    Załączniki:
    RTP_pager_...160413.zip Download (201.42 kB) kod źródłowy dla ESP8266
    tSIP.7z Download (1.32 MB) softphone (skompilowany)


    Fajne! Ranking DIY
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz pendrive 32GB.
  • #3 08 Maj 2016 13:01
    tomek10861
    Poziom 27  

    Kolejny fajny projekt oparty o te moduły. Szkoda, że nie ma tu jakiegoś lepszego przetwornika DAC. Ciekawie by wyglądało to w drugą stronę - ESP jako mini pluskwa. Czyli dorzucić do tego modułu jakiś ADC i mikrofon. Zasięg to ma bardzo dobry.

    BTW. Bardzo podobają mi się te moduły jako samodzielne urządzenia.

  • #4 08 Maj 2016 13:37
    george2002

    Poziom 19  

    tomek10861 napisał:
    Kolejny fajny projekt oparty o te moduły. Szkoda, że nie ma tu jakiegoś lepszego przetwornika DAC. Ciekawie by wyglądało to w drugą stronę - ESP jako mini pluskwa. Czyli dorzucić do tego modułu jakiś ADC i mikrofon. Zasięg to ma bardzo dobry.

    BTW. Bardzo podobają mi się te moduły jako samodzielne urządzenia.


    Proszę bardzo:
    https://www.hackster.io/middleca/sending-sound-over-the-internet-f097b4

    widziałem ostatnio na youtube gdzieś dwa połączone esp8266 z sobą i działał intercom na nich w obydwie strony ale teraz nie mogę znaleźć ... jakoś była średnia ale da się :D

    Pozdrawiam
    George2002

  • #5 08 Maj 2016 15:17
    ostrytomasz
    Poziom 22  

    Duch__ napisał:
    Można prosić o jakieś próbki dźwiękowe?

    Fragment wywiadu z L.T., zdaje się że public domain: lin_ou..wav Download (3.11 MB). Próbkowanie przez wejście mikrofonowe podłączone przez dzielnik 1k + 100 + kondensator równoległy 330n. Zakłócenie przypominające przydźwięk sieciowy to w rzeczywistości zakłócenie przeniesione z zasilania - odbiornik przetwarza 50 pakietów UDP na sekundę.

    george2002 napisał:


    Pod kilkoma względami (chociażby prawdziwy DAC) moduły Photon przewyższają ESP, ale cenowo to trochę inna liga - $30 na ebay. Przy tej cenie można już myśleć o zestawie typu używany AP (jeżeli potrzebne jest WiFi) + telefon VoIP.

    george2002 napisał:

    widziałem ostatnio na youtube gdzieś dwa połączone esp8266 z sobą i działał intercom na nich w obydwie stron


    Też jakoś nie widzę. Wydaje mi się że tutaj wymagany byłby kodek I2S, bo jeżeli chodzi o ADC wbudowane w ESP to jest ono trochę rozczarowujące:
    WiFi/VoIP pager oparty o ESP8266
    (zarejestrony przez ESP-01 przebieg przy praktycznie zerowym ruchu który powinien być sinusoidą, przy 100 pakietach na sekundę dla dwustronnej komunikacji prawdopodobnie byłoby gorzej).

    Edit: przy okazji kilka poprawek powiązanych z buforowaniem: RTP_pager_...160508.zip Download (201.83 kB). Gdyby ktoś chciał potestować to skompilowana wersja w archiwum powinna działać bez zmian (tj. konieczności wprowadzenia SSID/hasła i kompilacji) jeżeli wcześniej ESP8266 pracował w trybie station. Jeżeli chodzi o zakłócenia przenoszone przez zasilanie, to z tego co widzę na płytce stykowej istotny jest punkt do którego przyłączona jest masa słuchawek wraz z kondensatorem filtrującym - najlepiej podłączyć je blisko wejścia zasilania.

  • #6 08 Maj 2016 23:09
    george2002

    Poziom 19  

    ostrytomasz napisał:


    george2002 napisał:

    widziałem ostatnio na youtube gdzieś dwa połączone esp8266 z sobą i działał intercom na nich w obydwie stron


    Też jakoś nie widzę. Wydaje mi się że tutaj wymagany byłby kodek I2S, bo jeżeli chodzi o ADC wbudowane w ESP to jest ono trochę rozczarowujące:
    WiFi/VoIP pager oparty o ESP8266
    (zarejestrony przez ESP-01 przebieg przy praktycznie zerowym ruchu który powinien być sinusoidą, przy 100 pakietach na sekundę dla dwustronnej komunikacji prawdopodobnie byłoby gorzej).



    Normalnie zaćmienie, jeszcze wczoraj to widziałem i działało bdb, bodajże 8khz jakość miał gość połączone dwa esp8266 z sobą z mikrofonami i głośnikami a teraz nie mogę tego znaleźć :D

  • #9 13 Maj 2016 00:15
    ostrytomasz
    Poziom 22  

    george2002 napisał:
    mateuszciupka napisał:


    10/10, kurczę na youtubie źle szukałem, ale coś o 8khz świtało :D thx za podrzucenie linka :) jak widać działa to dosyć ładnie i da się na samym ESP8266 bez atmela :)


    Prawie, bo to znowu Photon. Podłączanie "atmela" nie miałoby tu sensu - albo kodek na I2S albo "duży" procesor który przejąłby na siebie pracę udostępniając przy tym swoje wejście/wyjście audio: http://hackaday.com/2015/12/09/raspberry-pi-wifi-through-sdio/

    Wersja z obsługą G.722: RTP_pager_...160512.zip Download (211.87 kB), tSIP.7z Download (2.27 MB) i próbka audio: lin_G722..t.wav Download (4.72 MB).
    Z ciekawych rzeczy - wygląda na to, że naocznie doświadczyłem niestabilności DAC delta-sigma drugiego rzędu (prawdopodobnie w projekcie dekodera mp3 DAC pracuje z "łatwiejszym" sygnałem niż sygnał z mikrofonu gdzie łatwo o przesterowanie), stąd amplituda podawana na wejście DAC ograniczona jest o połowę. Pdf opisujący problem: http://classes.engr.oregonstate.edu/eecs/spri...ece627/Lectures/2nd%20%26%20Higher-Order2.pdf
    Prawdopodobnie warto zaktualizować SDK do wersji 1.5.3 - http://bbs.espressif.com/viewtopic.php?t=1205

  • #10 13 Maj 2016 08:23
    Freddy
    Poziom 43  

    ostrytomasz napisał:
    Paging jest to jednokierunkowa komunikacja głosowa.
    Nie do końca sie z Tobą zgodzę. Pagery odbierały komunikaty tekstowe, zwykle w protokole POCSAG, a niektóre z nich miały możliwość wysłania potwierdzenia odbebrania.

  • #11 13 Maj 2016 19:13
    ostrytomasz
    Poziom 22  

    W zasadzie POCSAG jest ciągle w użyciu - straż pożarna czy WSPR w Olsztynie.

  • #12 14 Maj 2016 22:37
    kordian2
    Poziom 9  

    Jestem pełen podziwu dla Pana projektu. Robi wrażenie (przynajmniej na mnie). Chyba mnie Pan zmotywował żeby zmierzyć się z Eclipse :) Do tej pory esp8266/Arduino mi wystarczało aż nadto.
    W ESP32 jest DMA,I2S,12-bitowe ADC,8-bitowe DAC więc chyba już w zupełności wystarczy na aplikacje typu "RTP/RTSP" lub nawet cały telefon VOIP wraz ze zdalną zewnętrzną słuchawką i mikrofonem na BT.

    W tej chwili wystarczyło by proste "walkie talkie" 8kHz/PCM/ESP8266/UDP/ADC/fake-pwm lub ewentualnie TDA1543/MCP4725

    Zainteresowanie jest jak widać duże.
    Może się da Pan namówić ?

    ps. Może być w wersji "beta" z "niestabilnościami DAC delta-sigma drugiego rzedu" :)

  • #13 15 Maj 2016 00:39
    ostrytomasz
    Poziom 22  

    kordian2 napisał:
    Jestem pełen podziwu dla Pana projektu. Robi wrażenie (przynajmniej na mnie).


    Polecam obejrzenie https://github.com/espressif/ESP8266_MP3_DECODER - stąd pochodzi pomysł/kod użycia I2S jako PWM DAC.

    kordian2 napisał:

    Chyba mnie Pan zmotywował żeby zmierzyć się z Eclipse :) Do tej pory esp8266/Arduino mi wystarczało aż nadto.


    Nie wiem jak się tego używa, ale w arduino też jest obsługa I2S (przynajmniej widać ją w pliku core_esp8266_i2s.c - też jako "fake PWM").

    kordian2 napisał:

    W ESP32 jest DMA,I2S,12-bitowe ADC,8-bitowe DAC więc chyba już w zupełności wystarczy na aplikacje typu "RTP/RTSP" lub nawet cały telefon VOIP wraz ze zdalną zewnętrzną słuchawką i mikrofonem na BT.


    W przypadku ADC i DAC przydatne byłoby DMA gdzie w przypadku ESP8266 dokumentacja jest trochę skąpa - oprócz I2S znajduję użycie DMA tylko dla UART. Jeżeli drugi rdzeń będzie w 100% dostępny dla użytkownika obyłoby się bez DMA, ale na razie niewiele jest chyba szczegółów. Plusem jest na pewno większa ilość pamięci - chociaż stare telefony SIP zadowalały się klonem '51. Ogólnie sporo pracy trzeba byłoby w to włożyć.

    kordian2 napisał:

    W tej chwili wystarczyło by proste "walkie talkie" 8kHz/PCM/ESP8266/UDP/ADC/fake-pwm lub ewentualnie TDA1543/MCP4725


    Pozostając przy ESP8266 - te układy to tylko DAC a większy problem jest z ADC. Dostępność "pełnych" kodeków I2S nie jest chyba zbyt dobra, być może w tego typu zastosowaniu lepszy byłby osobny mikrofon MEMS I2S (~$4).

  • #14 15 Maj 2016 21:55
    kordian2
    Poziom 9  

    Oglądałem już ten projekt.
    Ten też jest ciekawy - https://github.com/pvvx/mp3_decode..

    A w jakim IDE Pan realizował projekt ? W kodzie który Pan załaczył jest opis "org.eclipse.cdt".

    Powracając do ADC w ESP8266.
    http://www.esp8266.com/wiki/doku.php?id=esp8266_gpio_pin_allocations
    The ADC cannot be used when the chip is transmitting. Otherwise the voltage may be inaccurate.
    Czy to oznacza że jednocześnie nie można odczytywać wartości z ADC przy transmisji WIFI ?

    Postanowiłem sprawdzić szybkość przetwornika ADC w przy wykorzystaniu analogRead(A0). Wiele osób na forach sygnalizuje że osiągają ledwo ~2500Hz.

    W Arduino dla ESP8266/12 uzyskałem dla ADC/A0 poniższe "sample rate"
    (zwykła pętla loop)

    ESP8266/12
    Zegar: 80Mhz
    Time per sample: 94.64
    Frequency: 10566.80

    Zegar: 160Mhz
    Time per sample: 81.29
    Frequency: 12300.88

    Dla porównania dla
    Arduino Nano
    Time per sample: 112.01
    Frequency: 8927.62

    Po zmianie prescale ADC dla
    Arduino Nano
    Sampling frequency: 153.66 KHz

    Na pewno da się wyciagnąć z ADC/ESP o wiele więcej.
    (phy_adc_read_fast)
    https://github.com/pvvx/esp8266web/blob/master/info/libs/phy/sar_read_fast.c

    Czy dał by Pan radę sprawdzić jaki sample rate można by wyciągnąć przy wykorzytaniu tej funkcji ? Niestety mój poziom wiedzy jeszcze na to nie pozwala.

    // Programy testowe dla sample rate ADC

    // ADC/LOOP ------------------

    Kod: c
    Zaloguj się, aby zobaczyć kod


    // ADC/PRESCALER ------------------
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Dodano po 1 [godziny] 3 [minuty]:

    Może ktoś z bardziej zaawansowanych potrafiłby z powodzeniem w IDE/Arduino/ESP8266 podmienić defincję funkcji analogRead

    lokalizacja żródłowa:
    arduino-1.6.8/hardware/esp8266com/esp8266/cores/esp8266/core_esp8266_wiring_analog.c
    Kod: c
    Zaloguj się, aby zobaczyć kod

    na phy_adc_read_fast
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Niestety w moim przypadku przy powyższej zmianie w czasie kompilacji wyskakuje komunikat błedu "undefined reference to `analogRead'" (dodałem #include "wiring_private.h" #include "pins_arduino.h" ).

    Dodano po 43 [minuty]:

    cd.
    po podmianie na
    Kod: c
    Zaloguj się, aby zobaczyć kod

    otrzymałem poniższe wyniki:

    160Mhz
    Time per sample: 15.82
    Frequency: 63223.11

    80Mhz
    Time per sample: 19.85
    Frequency: 50367.68

    Podłączyłem potencjometr pod ADC i odczyty są prawidłowe.
    Ciekawe czy to będzie działać poprawnie.

    Dodano po 26 [minuty]:

    cd ..
    po zmianie parametrow na
    phy_adc_read_fast(&adc_out, 1, 2);

    80Mhz
    Time per sample: 18.27
    Frequency: 54743.53

    160Mhz
    Time per sample: 13.78
    Frequency: 72590.01

    Disassemble phy_adc_read_fast()
    https://github.com/pvvx/esp8266web/blob/master/info/libs/phy/sar_read_fast.c

    void phy_adc_read_fast(uint16 *adc_addr, uint16 adc_num, uint8 adc_clk_div)
    uint16 *adc_addr: ADC sample output address
    uint16 adc_num: ADC sample count, range [1, 65535]
    uint8 adc_clk_div: ADC sample collection clock range[2, 23]

    Example(Continue to collect 100 ADC samples):
    uint16 adc_out[100];
    phy_adc_read_fast(&adc_out[0], 100, 8);

    Teraz zmiast odczytywać "bajt po bajcie" można by coś zapisać do tablicy.

    Dodano po 1 [godziny] 38 [minuty]:

    dla
    uint16 adc_out[100];
    phy_adc_read_fast(&adc_out[0], 100, 2);

    Time per sample: 3.14
    Frequency: 318405.41

    Teraz trzeba by podać jakś sygnał na wejscie i zapisać/wysłać i sprawdzić czy to działa.

  • #15 15 Maj 2016 23:03
    ostrytomasz
    Poziom 22  

    kordian2 napisał:
    Oglądałem już ten projekt.
    Ten też jest ciekawy - https://github.com/pvvx/mp3_decode..


    Zbytnio nie widzę różnicy oprócz tego, że brak wzmianki o możliwości użycia SPI RAM i kodeka I2S.

    kordian2 napisał:

    A w jakim IDE Pan realizował projekt ? W kodzie który Pan załaczył jest opis "org.eclipse.cdt".


    Określenie IDE jest tu trochę naciągane, ale jako edytora i narzędzia do uruchomienia make używam Code::Blocks. Makefile bez większych zmian zaczerpnięty jest z przykładów UDK. Ponieważ przykłady z UDK zawierają pliki eclipse więc i u mnie one zostały, ale nie wiem nawet czy działają.
    Można używać linii komend, jedyne do czego przydaje się tu IDE to skok do linii kodu przy błędzie kompilacji.

    kordian2 napisał:


    Dzięki za wyniki testów.
    W tym projekcie jak widzę jest "test ADC" - możliwość ściągnięcia przez serwer HTTP pliku wave (według opisu ~2kB, ~20ksps), z komentarzem:
    Cytat:

    // Правильное чтение организуется по прерыванию таймера(!).
    // Тут только демо!

    Jeżeli celem miałoby być zastosowanie VoIP, to odczyt po 100 próbek nie jest raczej przydatny, raczej timer z rozdzielczością us:
    http://www.esp8266.com/viewtopic.php?p=13492

  • #16 17 Wrz 2017 08:33
    Erbit
    Poziom 31  

    kordian2 napisał:
    ...
    Czy to oznacza że jednocześnie nie można odczytywać wartości z ADC przy transmisji WIFI ?
    ...

    Niestety na to wygląda.
    Inaczej może być w ESP32.