[F4][F7][C] Przesył bezprzewodowy o "dużej" prędkości.

Hej,

Chciałbym zrealizować do swojego urządzenia przesył danych metodą bezprzewodową.

Interesuje mnie wysyłanie ramek wielkości do max. 120 - 150KB (kilobajtów). Takich ramek w ciągu sekundy chciałbym móc wysłać powiedzmy 10. Daje nam to wymaganą prędkość przesyłu do 1,5MB/s (megabajta). Mikrokontroler F4 bądź F7 po odebraniu jednej ramki 120-150KB zapisze ją w sobie w buforze, trochę ją obrobi a następnie będzie przesyłał dalej przez SPI (ale już nie bezprzewodowo). Po przesłaniu przez SPI będzie czekał na kolejną ramkę do zapisania w tym samym buforze. Takich operacji w trakcie sekundy chciałbym mieć minimum 10. Im więcej tym lepiej. Powiedzmy max 15-20. Minimum te 10 chciałbym uzyskać.

Przechodząc do meritum. Myślę w jaki sposób zrealizować taką transmisję. Dobrze byłoby oprzeć to o moduły WIFI np ESP. Nigdy nie miałem do czynienia z takimi modułami. Z tego co widzę, to komunikują się one z mikrokontrolerem za pomocą UART, co będzie wąskim gardłem dla takich prędkości, jakie oczekuję. Najlepszym rozwiązaniem byłby moduł WIFI który mógłby odbierać z komputera PC dane binarne z prędkością min. 1.5MB/s i wysyłał to po SPI do mikrokontrolera.

Chciałbym prosić o pomoc w doborze odpowiedniego modułu. Co do WIFI to się nie upieram. Jak ktoś ma pomysł w jaki inny sposób można taką transmisję zrealizować (PC/Smarfton -> mikrokontroler) z odpowiednimi prędkościami (by UART nie był wąskim gardłem) byłbym wdzięczny. Może zamiast WIFI jakiś transceiver po SPI? Bluetooth?

Bardzo dziękuję

Elektro_maniak napisał:

120 - 150KB (kilobajtów). Takich ramek w ciągu sekundy chciałbym móc wysłać powiedzmy 10. Daje nam to wymaganą prędkość przesyłu do 1,5MB/s (megabajta).

To jest zdecydowanie za mało bo to tylko "payload". A gdzie protokół?

Liczę same dane użyteczne. Oczywiście trzeba wziąć pod uwagę narzut protokołu/sposobu transmisji.

Jakiego rodzaju są te dane, czy chodzi o przesył obrazu lub inne dane które można kompresować/wysyłać różnice?

ESP będzie tanim rozwiązaniem, skalowalnym do warstwy IP co pozwoli na debugowanie i rozbudowanie nawet o integrację z LAN/WAN do przesyłania danych np. poprzez internet lub do wspomnianego PC.

Z ESP można komunikować się po UART, SPI, a nawet wymyślone swoje protokoły szeregowe lub równoległe, wszystko kwestia optymalizacji i sprawdzenia czy wspomniane 12Mb/s jest w ogóle możliwe technicznie do osiągnięcia,
ESP8266, ESP8266 uPython
ESP32

Można spróbować wykorzystać moduły z mniejszym zasięgiem i elastycznością, ale z mniejszym narzutem na transmisję
pod warunkiem że udałoby się zmienić zapotrzebowanie na pasmo do 2Mb/s (kompresja / wysyłanie różnic itp.) np.:
https://botland.com.pl/moduly-radiowe/5842-modul-radiowy-rfm75-s-24ghz-transceiver-smd.html

Ciekawe zagadnienie, pisz śmiało, może uda się wspólnie coś osiągnąć tak jak np. tutaj https://www.elektroda.pl/rtvforum/topic3443242.html
a później można zaprezentować efekt w DIY: https://www.elektroda.pl/rtvforum/forum85.html

OK, to opiszę bardziej szczegółowo co mi chodzi po głowie

Chciałbym skonstruować wyświetlacz widmowy (już drugi w mojej hobbystycznej karierze) z możliwością przesyłu zawartości online.
Wyświetlacz składałby się z podłużnej listwy z 120 diodami SMD APA102C.
Każda dioda potrzebuje paczki 4 bajtów (R,G,B + 5 bitów na jasność).

Zakładając, że wyświetlacz kręciłby się względem środka listwy, daje nam to:
120 (ilość diod) * 128 (połowa rozdzielczości radialnej) * 4 (bajty) = 60KB.

Zakładając, że wyświetlacz kręciłby się względem jednego z końców listwy:
120 * 256 * 4 = 120KB.

Aby uzyskać w miarę rozsądne odświeżanie (zakładając większe pole wyświetlacza - obrót względem końca listwy) - oczywiście zsynchronizowane z ilością obrotów na sekundę - powiedzmy max do 5-10 wychodzi, że potrzebuję transmisji do 1-1.5MB/s (do 8-12Mb/s)

Oczywiście, jakbym założył, że wysyłam tylko 60KB, albo nawet 45KB (pomijając bajt jasności) to dla max 10FPS (jeżeli w ogóle uda się uzyskać taką prędkość) daje to do max. 4-5Mb/s).

Ewentualnie, jakby ten pomysł nie wypalił, to zastosuje zewnętrzną pamięć po QUAD SPI, do której będę wysyłał dane z normalną prędkością a odtwarzał dopiero po ich całkowitym wysłaniu. (np. materiał "video" kilkusekundowy). Ale wtedy nie byłoby to online

Elektro_maniak napisał:

Każda dioda potrzebuje paczki 4 bajtów (R,G,B + 5 bitów na jasność).

Zdecydowanie nie potrzebuje - zupełnie wystarczą 3 bity, bo przecież składowe R, G i B zawierają w sobie informacje o jasności. A te 3 bajty i tak są potrzebne tylko i wyłącznie wtedy jeśli diodami sterujesz z 8 bitową rozdzielczością. Generalnie spokojnie można by się ograniczyć do R5G6B5 (2 bajty) albo i R4G4B4 (1.5 bajta) - i tak filmów w jakości HD na tym oglądać nie będziesz.

Dokładnie tak, już takim prostym zabiegiem jak 16b kolor RGB565, albo RGB444 redukujesz liczbę przesyłanych danych, warto przetestować 8b kolor np. RGB332 lub inny chociaż efekt może być trochę słaby. Jasność można regulować globalnie dla całego wyświetlacza.
Są też układy YCbCr422 i inne ale lepszą oszczędność może przynieść kompresja...
Trzeba się zastanowić czy zawsze warto przesyłać całą klatkę, być może wystarczy przesyłać zmiany w stosunku do klatki kluczowej, lub przesyłać zawsze pełną klatkę ale skompresowaną jpg lub png. To oczywiście dodatkowy spory narzut na obliczenia, oraz trudno wskazać co gotowego wykorzystać, ale pole do eksperymentów duże.

Można też pójść w innym kierunku, ( który mocno skomplikuje projekt np. pod względem synchronizacji ) i jeżeli jeden z interfejsów jest wąskim gardłem dla 3 kolorów, to może przesyłać dane o 3 kolorach równolegle kilkoma interfejsami tak jak cyfrowo jest w HDMI, lub analogowo w VGA. To raczej uwaga w kierunku zabawy a nie praktyki, ale przemyśleć można.

TechEkspert napisał:

ESP będzie tanim rozwiązaniem, skalowalnym do warstwy IP co pozwoli na debugowanie i rozbudowanie nawet o integrację z LAN/WAN do przesyłania danych np. poprzez internet lub do wspomnianego PC.

ESP i ESP32 niestety nie spełniają oczekiwań autora odnośnie transferu danych. Realny transfer danych jesst na poziomie << 1MB/s. W praktyce 300-600 kB/s (piszę o samym payload).
Aby uzyskać wymagane szybkości transmisji trzeba znaleźć jakiś dużo lepszy (i zapewne już nie tak tani) moduł WiFi.

Wspomniane 2.4-4.8Mb/s to faktycznie niezbyt dużo, ale cena modułu ESP32 i elastyczność przenoszenia payload w IP może być warta sprawdzenia. Czy wspomniane prędkości zależą od sposobu przesyłania danych (np. TCP/UDP, albo sposobu połączenia ESP32 do WiFi np. podłączone do AP lub jako AP) ?

Można albo odrzucić rozwiązanie jako zbyt wolne, lub spróbować upchnąć w tej przepustowości <8Mb/s dane do wyświetlacza widmowego.

Zapytam jeszcze czy w trybie ESPnow przepustowość jest również <8Mb/s ?

Dziękuję bardzo za wszystkie podpowiedzi.

hmm... myślę, że faktycznie możemy ograniczyć przepustowość i skorzystać z trybu R5G6B5. Wielkość ramki wyniosłaby wtedy:
120 * 128 * 2 = 30KB.
Wysyłając 10 ramek na sekundę mamy transfer 300KB/s = 2,4Mbps + narzut protokołu.
Zawsze można jeszcze zejść z rozdzielczości kątowej.

Wyświetlacz obracałby się względem środka listwy ledowej (2x mniej danych do wysłania).

Myślę, że tu już byłaby szansa z przesyłaniem obrazu bezprzewodowo. Żeby zapewnić sobie też jakiś bezpieczny margines, dobrze by było uzyskać prędkości do 3-4Mbps.

Nie musi to być koniecznie WIFI. Droższe moduły mogę również rozpatrzeć.