Korzystając z chwili wolnego wróciłem do jednego ze swoich starych
projektów edukacyjnych - sprzętowego radia Internetowego. Projekt zaczął
powstawać jakiś czas temu w wyniku frustracji faktem, że komercyjnie
dostępne wieże stereo z funkcją "radia internetowego" często są zależne
od zewnętrznego serwera. Postanowiłem więc złożyć coś podobnego, gdzie
mógłbym po prostu sam ustawiać linki do streamów.

Konfiguracja sprzętowa urządzenia wygląda następująco:
- Mikrokontroler PIC32MX795F512 pracujący na taktowaniu 80 MHz
- Łączność sieciową zapewnia wbudowany w MCU moduł MAC, z zewnętrznym
PHY DP83848, mamy więc do dyspozycji Fast Ethernet.
- Dekodowanie streamów bierze na siebie VS1053, chociaż pewnie sam
mikrokontroler poradziłby sobie z tym programowo.
- Dostępne nośniki pamięci to karta microSD (po SPI), pendrive oraz
niewielki (bodajże 2MB) chip pamięci SPI Flash.
- Wszystko zamontowane na dwustronnej płytce, wykonanej samodzielnie
metodą termotransferu. To chyba najbardziej szczegółowa i skomplikowana
płytka jaką wykonałem w domowych warunkach.

Od strony programowej wykorzystuję raczej standardowe komponenty, m.in.
bibliotekę TCP/IP MLA od Microchipa oraz FATFS. Znaleziony na GitHubie
kod do obsługi VS1053 musiałem nieco rozbudować, tworząc maszynę stanów
skończonych, odpowiedzialną za odtwarzanie pojedynczych plików, całych
katalogów oraz streamów HTTP/ICY z sieci.

Odtwarzanie funkcjonuje w ten sposób, że mam dwuczęściowy bufor (w tej
chwili 2x8 kB). Gdy jednak połówka zasila danymi chip VS1053, druga jest
wypełniana danymi odczytywanymi z pliku lub przychodzącymi z serwera.
Gdy dane się skończą, następuje podmiana. Oczywiście do tego dochodzi
jeszcze bufor odbiorczy gniazda sieciowego (4 kB).

Kod odpowiedzialny za połączenie posiada pewne zabezpieczenia. Jeśli
dane przestaną przychodzić zostanie wywołany timeout i połączenie z
serwerem zostanie zamknięte i zainicjowane ponownie. To samo stanie się
w przypadku wykrycia utraty połączenia.

Wszystko to działa dość sprawnie. Tak naprawdę działało nawet na
mniejszych buforach (2x4 kB). Jakość dźwięku jest dobra, przycięcia
zdarzają się rzadko. Jednak już kilka razy zauważyłem dziwny objaw,
który nieco mnie zaintrygował.

Mianowicie pojawiła się sytuacja, kiedy dźwięk zaczął zrywać w sposób
przypominający zaciętą płytę gramofonową. Zupełnie jakby nowe dane
przestały przychodzić, albo przychodziły w zbyt wolnym tempie. Zazwyczaj
występuje też wtedy zrywanie połączenia albo timeout spowodowany brakiem
nowych danych. Do tej pory sytuacja wystąpiła kilka razy, zawsze po
wielu godzinach pracy urządzenia, jednak mógł to być tylko przypadek.
Co w tym takiego intrygującego?
- Gdy sytuacja wystąpi, dotyczy wszystkich streamów, nadawanych z
różnych serwerów
- Reset płytki nie pomaga, nawet przez chwilowe odłączenie zasilania
- W tym czasie zupełnie normalnie odtwarzane są pliki z nośników
lokalnych, więc to nie problem ze sprzętowym dekoderem
- Po chwili problem mija sam
- Na komputerze podpiętym do tego samego routera i switcha nie
doświadczam w tym momencie żadnych problemów z dostępem do Internetu
- Podczas występowania problemu mogę pingować płytkę i odczytywać dane z
prostego serwera HTTP, odpalonego na niej. Nie jest więc tak, że traci
ona połączenie zupełnie. Zresztą kolejne połączenia z serwerami są
inicjowane poprawnie (200 OK) ale zrywanie występuje nadal.

Ktoś ma jakiś pomysł co może być nie tak? Fakt, że reset płytki nie
pomaga wskazywałby na jakiś problem z moją infrastrukturą, chwilowo nie
mam jednak pomysłów...

do góry

Dnia Tue, 13 Sep 2022 10:38:43 +0200, Atlantis napisał(a):

> Korzystając z chwili wolnego wróciłem do jednego ze swoich starych
> projektów edukacyjnych - sprzętowego radia Internetowego. Projekt zaczął
> powstawać jakiś czas temu w wyniku frustracji faktem, że komercyjnie
> dostępne wieże stereo z funkcją "radia internetowego" często są zależne
> od zewnętrznego serwera. Postanowiłem więc złożyć coś podobnego, gdzie
> mógłbym po prostu sam ustawiać linki do streamów.
>
> Konfiguracja sprzętowa urządzenia wygląda następująco:
> - Mikrokontroler PIC32MX795F512 pracujący na taktowaniu 80 MHz
> - Łączność sieciową zapewnia wbudowany w MCU moduł MAC, z zewnętrznym
> PHY DP83848, mamy więc do dyspozycji Fast Ethernet.
> - Dekodowanie streamów bierze na siebie VS1053, chociaż pewnie sam
> mikrokontroler poradziłby sobie z tym programowo.
> - Dostępne nośniki pamięci to karta microSD (po SPI), pendrive oraz
> niewielki (bodajże 2MB) chip pamięci SPI Flash.
> - Wszystko zamontowane na dwustronnej płytce, wykonanej samodzielnie
> metodą termotransferu. To chyba najbardziej szczegółowa i skomplikowana
> płytka jaką wykonałem w domowych warunkach.
>
> Od strony programowej wykorzystuję raczej standardowe komponenty, m.in.
> bibliotekę TCP/IP MLA od Microchipa oraz FATFS. Znaleziony na GitHubie
> kod do obsługi VS1053 musiałem nieco rozbudować, tworząc maszynę stanów
> skończonych, odpowiedzialną za odtwarzanie pojedynczych plików, całych
> katalogów oraz streamów HTTP/ICY z sieci.
>
> Odtwarzanie funkcjonuje w ten sposób, że mam dwuczęściowy bufor (w tej
> chwili 2x8 kB). Gdy jednak połówka zasila danymi chip VS1053, druga jest
> wypełniana danymi odczytywanymi z pliku lub przychodzącymi z serwera.
> Gdy dane się skończą, następuje podmiana. Oczywiście do tego dochodzi
> jeszcze bufor odbiorczy gniazda sieciowego (4 kB).
>
> Kod odpowiedzialny za połączenie posiada pewne zabezpieczenia. Jeśli
> dane przestaną przychodzić zostanie wywołany timeout i połączenie z
> serwerem zostanie zamknięte i zainicjowane ponownie. To samo stanie się
> w przypadku wykrycia utraty połączenia.
>
> Wszystko to działa dość sprawnie. Tak naprawdę działało nawet na
> mniejszych buforach (2x4 kB). Jakość dźwięku jest dobra, przycięcia
> zdarzają się rzadko. Jednak już kilka razy zauważyłem dziwny objaw,
> który nieco mnie zaintrygował.
>
> Mianowicie pojawiła się sytuacja, kiedy dźwięk zaczął zrywać w sposób
> przypominający zaciętą płytę gramofonową. Zupełnie jakby nowe dane
> przestały przychodzić, albo przychodziły w zbyt wolnym tempie. Zazwyczaj
> występuje też wtedy zrywanie połączenia albo timeout spowodowany brakiem
> nowych danych. Do tej pory sytuacja wystąpiła kilka razy, zawsze po
> wielu godzinach pracy urządzenia, jednak mógł to być tylko przypadek.
> Co w tym takiego intrygującego?
> - Gdy sytuacja wystąpi, dotyczy wszystkich streamów, nadawanych z
> różnych serwerów
> - Reset płytki nie pomaga, nawet przez chwilowe odłączenie zasilania
> - W tym czasie zupełnie normalnie odtwarzane są pliki z nośników
> lokalnych, więc to nie problem ze sprzętowym dekoderem
> - Po chwili problem mija sam
> - Na komputerze podpiętym do tego samego routera i switcha nie
> doświadczam w tym momencie żadnych problemów z dostępem do Internetu
> - Podczas występowania problemu mogę pingować płytkę i odczytywać dane z
> prostego serwera HTTP, odpalonego na niej. Nie jest więc tak, że traci
> ona połączenie zupełnie. Zresztą kolejne połączenia z serwerami są
> inicjowane poprawnie (200 OK) ale zrywanie występuje nadal.
>
> Ktoś ma jakiś pomysł co może być nie tak? Fakt, że reset płytki nie
> pomaga wskazywałby na jakiś problem z moją infrastrukturą, chwilowo nie
> mam jednak pomysłów...

Czy ten projekt na PIC32MX795F512 jest ogólnodostępny? Czy też to Pana
autorski pomysł?

do góry

On 13.09.2022 10:38, Atlantis wrote:

> Ktoś ma jakiś pomysł co może być nie tak? Fakt, że reset płytki nie
> pomaga wskazywałby na jakiś problem z moją infrastrukturą, chwilowo nie
> mam jednak pomysłów...

No to podłącz go gdzie indziej, np. przez ruter podłączony przez komórkę.
Obstawiam że jakiś pakiet niekompatybilny dostaje, multicast albo coś.

--
Mirek.

do góry

On 13.09.2022 19:04, Mirek wrote:

> No to podłącz go gdzie indziej, np. przez ruter podłączony przez komórkę.
> Obstawiam że jakiś pakiet niekompatybilny dostaje, multicast albo coś.

Ok, sprawa się wyjaśniła - winę ponosiło moje przeoczenie. Jakiś czas
temu zmieniłem adres MAC radia, bo pokrywał się z innym urządzeniem,
które zrobiłem wcześniej wykorzystując te same biblioteki. To sprawiło,
że przestała obowiązywać reguła QoS ustawiona na routerze, która miała
dawać radyjku wysoki priorytet przy podziale pasma. Wygląda na to, że
przywrócenie właściwych ustawień rozwiązało problem.

do góry

On 13.09.2022 15:03, adam13lat wrote:

> Czy ten projekt na PIC32MX795F512 jest ogólnodostępny? Czy też to Pana
> autorski pomysł?

Projekt autorski, chociaż zarówno wzory płytek jak i kod są dostępne na
GitHubie.

https://github.com/marekw1986/InternetRadioPIC32DP83
848

Tylko ostrzegam, że projekt jest ciągle w wersji roboczej. Na chwilę
obecną więcej rzeczy nie działa niż działa. Da się testowo odtwarzać MP3
z nośnika lokalnego albo streamy z sieci, ale wszystkie ścieżki i URL-e
muszą być zaszyte w kodzie. Będę musiał jeszcze napisać interfejs
użytkownika (impulsator obrotowy + HD44780 + kilka przycisków + prosty
interfejs WWW) oraz całą logikę sterującą.

Generalnie projekt jest dość stary i do strony hardware'owej
podchodziłem kilka razy. Najpierw powstała bodajże wersja na
PIC24FJ265DA210 z ENC28J60 w roli interfejsu sieciowego. Jednak dopiero
po złożeniu układu zorientowałem się, że spora część RAM-u w tym MCU nie
jest dostępna bezpośrednio w przestrzeni adresowej i wymaga stosowania
specjalnych poleceń do korzystania z niej. To wymagałoby przepisania
części bibliotek o największym zapotrzebowaniu na RAM, więc po prostu
przeniosłem się na PIC32MX795F512, początkowo nadal korzystając z
ENC28J60. W końcu jednak zaprojektowałem płytkę korzystająca z
wbudowanego Ethernetu, która teraz stanowi główną oś projektu.
Trochę później wykonałem tez płytkę z STM32F107, która na razie leży -
być może po dopracowaniu wersji na PIC32 przeniosę go na tę platformę.

Generalnie jeśli chcesz sobie szybko złożyć radio Internetowe to nie
polecam mojego podejścia. To od początku był/jest projekt edukacyjny,
mający na celu sprawdzenie swoich umiejętności i nauczenie się czegoś
nowego. W Internecie bez problemu znajdziesz opisy podobnych urządzeń
zrobionych dużo prościej na ESP32 albo Raspberry Pi Zero. :)

do góry

środa, 14 września 2022 o 03:39:24 UTC-5 Atlantis napisał(a):
> On 13.09.2022 19:04, Mirek wrote:
>
> > No to podłącz go gdzie indziej, np. przez ruter podłączony przez komórkę.
> > Obstawiam że jakiś pakiet niekompatybilny dostaje, multicast albo coś.
> Ok, sprawa się wyjaśniła - winę ponosiło moje przeoczenie. Jakiś czas
> temu zmieniłem adres MAC radia, bo pokrywał się z innym urządzeniem,
> które zrobiłem wcześniej wykorzystując te same biblioteki. To sprawiło,
> że przestała obowiązywać reguła QoS ustawiona na routerze, która miała
> dawać radyjku wysoki priorytet przy podziale pasma. Wygląda na to, że
> przywrócenie właściwych ustawień rozwiązało problem.

Heh, ladny przyklad na rubber duck debugging :)

do góry

Dnia Wed, 14 Sep 2022 10:58:00 +0200, Atlantis napisał(a):

> On 13.09.2022 15:03, adam13lat wrote:
>
>> Czy ten projekt na PIC32MX795F512 jest ogólnodostępny? Czy też to Pana
>> autorski pomysł?
>
> Projekt autorski, chociaż zarówno wzory płytek jak i kod są dostępne na
> GitHubie.
>
> https://github.com/marekw1986/InternetRadioPIC32DP83
848
>
> Tylko ostrzegam, że projekt jest ciągle w wersji roboczej. Na chwilę
> obecną więcej rzeczy nie działa niż działa. Da się testowo odtwarzać MP3
> z nośnika lokalnego albo streamy z sieci, ale wszystkie ścieżki i URL-e
> muszą być zaszyte w kodzie. Będę musiał jeszcze napisać interfejs
> użytkownika (impulsator obrotowy + HD44780 + kilka przycisków + prosty
> interfejs WWW) oraz całą logikę sterującą.
>
> Generalnie projekt jest dość stary i do strony hardware'owej
> podchodziłem kilka razy. Najpierw powstała bodajże wersja na
> PIC24FJ265DA210 z ENC28J60 w roli interfejsu sieciowego. Jednak dopiero
> po złożeniu układu zorientowałem się, że spora część RAM-u w tym MCU nie
> jest dostępna bezpośrednio w przestrzeni adresowej i wymaga stosowania
> specjalnych poleceń do korzystania z niej. To wymagałoby przepisania
> części bibliotek o największym zapotrzebowaniu na RAM, więc po prostu
> przeniosłem się na PIC32MX795F512, początkowo nadal korzystając z
> ENC28J60. W końcu jednak zaprojektowałem płytkę korzystająca z
> wbudowanego Ethernetu, która teraz stanowi główną oś projektu.
> Trochę później wykonałem tez płytkę z STM32F107, która na razie leży -
> być może po dopracowaniu wersji na PIC32 przeniosę go na tę platformę.
>
> Generalnie jeśli chcesz sobie szybko złożyć radio Internetowe to nie
> polecam mojego podejścia.
"Odbiornik" nie jest celem. Celem jest nauka C na konkretnym projekcie, a
radio to mój konik.

> To od początku był/jest projekt edukacyjny,
> mający na celu sprawdzenie swoich umiejętności i nauczenie się czegoś
> nowego. W Internecie bez problemu znajdziesz opisy podobnych urządzeń
> zrobionych dużo prościej na ESP32 albo Raspberry Pi Zero. :)
Znalazłem ten projekt na RPi Zero. Też ciekawy. Czy projekt jest ogólnie
dostępny?

do góry

On 14.09.2022 16:07, adam13lat wrote:

> "Odbiornik" nie jest celem. Celem jest nauka C na konkretnym projekcie, a
> radio to mój konik.

Z klasycznym radiem to nie ma wiele wspólnego. To tylko odtwarzacz
streamów z Internetu. A co do nauki C, to też nie wiem czy to najlepszy
projekt. Jeśli go skończę, to nie pozostanie tam zbyt wiele do pisania.
Jeśli chciałbyś sam nad tym popracować w obecnej formie, to musisz się
liczyć z tym, że wykorzystane jest tam trochę dość specyficznych i
raczej dość starych bibliotek od Microchipa. Obecnie (np. na ESP32)
wiele rzeczy robi się zupełnie inaczej i nieco prościej.


> Znalazłem ten projekt na RPi Zero. Też ciekawy. Czy projekt jest ogólnie
> dostępny?

O którym projekcie mówisz? Bo radio internetowe od zawsze było jednym z
najpopularniejszych zastosowań dla RasPi, jeszcze w czasach oryginalnego
komputerka. W Internecie jest tego całe mnóstwo. Sam też kiedyś zrobiłem
coś takiego:

https://hackaday.io/project/20199-empedocles

Działa, ale też jeszcze trochę pozostało do zrobienia. Na chwilę obecną
mam tam po prostu odpalony MPD + parę skryptów do obsługi przycisków,
enkodera obrotowego oraz odbiornika IR. Trzeba by dorobić jakiś
interfejs graficzny oraz WWW. Dzisiaj tez inaczej wykonałbym płytkę -
oryginalnie miało to iść do kompaktowej obudowy drukowanej w 3D albo
wycinanej laserowo ze sklejki. Finalnie jednak urządzenie zostało
zamontowane w blaszanej obudowie, a wyświetlacz (większy niż w
oryginale) został przeniesiony na płytę czołową. Dodałem też hub USB i
kilka dużych pendrive'ów do lokalnego przechowywania plików audio.

do góry

On Thu, 15 Sep 2022 09:03:14 +0200, Atlantis <m...@w...pl>
wrote:
> Z klasycznym radiem to nie ma wiele wspólnego. To tylko odtwarzacz
> streamów z Internetu.

A tak btw skąd brałeś url streamów? Jak ja robiłem to samo radyjko z
10 lat temu to zirytowało mnie już wtedy ukrywanie lub zaciemnianie
urli przez niektórych nadawców komercyjnych. Przez ukrywanie rozumiem
embedowanie ich w jakiś durnych playerach webowych albo aplikacjach
na telefon. Wtedy już zacząłem się zastanawiać ile to radyjko jeszcze
pociągnie aż znikną ogólnie dostępne url na jakieś ukryte wooshmoo
dostępne tylko dla zamkniętych playerów. O znikaniu (zastępowaniu
czymś innym) ogólnie dostępnych formatów audio nie wspominając.

--
Marek

do góry

On 15.09.2022 09:23, Marek wrote:

> A tak btw skąd brałeś url streamów? Jak ja robiłem to samo radyjko z 10
> lat temu to zirytowało mnie już wtedy ukrywanie lub zaciemnianie urli
> przez niektórych nadawców komercyjnych. Przez ukrywanie rozumiem

Na szczęście ciągle jeszcze można znaleźć zestawienia adresów streamów
on-line. Często niestety mają one formę plików m3u albo pls do
ściągnięcia i właściwy adres trzeba sobie podejrzeć w edytorze.
Trzeba też pamiętać o tym, że taki adres nie zawsze prowadzi
bezpośrednio do streamu - nierzadka jest sytuacja, kiedy dostajemy kod
"301 Moved Permanently" albo "302 Moved Temporarily" i trzeba to
obsłużyć w kodzie. Na chwilę obecną problematyczne są sytuacje, kiedy
wywołuję adres http i dostaję przekierowanie na https - jeszcze nie
uwzględniłem w swoim projekcie biblioteki do obsługi SSL-a.
Generalnie szyfrowanie streamów ogólnodostępnych stacji radiowych uważam
za głupi i bezsensowny pomysł. ;)


> embedowanie ich w jakiś durnych playerach webowych albo aplikacjach na
> telefon. Wtedy już zacząłem się zastanawiać ile to radyjko jeszcze
> pociągnie aż znikną ogólnie dostępne url na jakieś ukryte wooshmoo
> dostępne tylko dla zamkniętych playerów. O znikaniu (zastępowaniu czymś
> innym) ogólnie dostępnych  formatów audio nie wspominając.

W części takich sytuacji jeszcze można sobie poradzić, przeprowadzając
analizę ruchu sieciowego za pomocą narzędzi deweloperskich Chrome'a.
Często taki webowy playerek pod spodem po prostu otwiera stream, którego
adres można wyłuskać.

do góry