WiFi/VoIP pager oparty o ESP8266

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

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.

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ę

Pozdrawiam
George2002

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 (3.11 MB)Musisz być zalogowany, aby pobrać ten załącznik.. 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ł:

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

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:

(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 (201.83 kB)Musisz być zalogowany, aby pobrać ten załącznik.. 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.

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:

(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źć

może o to chodziło:
https://www.hackster.io/middleca/wi-fi-walkie-talkies-0a38f4

mateuszciupka napisał:

może o to chodziło:
https://www.hackster.io/middleca/wi-fi-walkie-talkies-0a38f4

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

george2002 napisał:

mateuszciupka napisał:

może o to chodziło:
https://www.hackster.io/middleca/wi-fi-walkie-talkies-0a38f4

10/10, kurczę na youtubie źle szukałem, ale coś o 8khz świtało 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 (211.87 kB)Musisz być zalogowany, aby pobrać ten załącznik., tSIP.7z (2.27 MB)Musisz być zalogowany, aby pobrać ten załącznik. i próbka audio: lin_G722..t.wav (4.72 MB)Musisz być zalogowany, aby pobrać ten załącznik..
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

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.

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

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"

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).

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 ------------------


// ADC/PRESCALER ------------------


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

na phy_adc_read_fast


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

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.

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ł:

https://github.com/pvvx/esp8266web/blob/master/info/libs/phy/sar_read_fast.c

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