Podsumowanie
Rejestrator opisany w niniejszej pracy został wykonany i uruchomiony. Po przeprowadzeniu testów i wprowadzeniu licznych poprawek urządzenie działa zgodnie z założeniami. Zostało ono sprawdzone zarówno dla przypadku bezpośredniego podłączenia do komputera, jak i podłączenia przez sieć, w której rejestrator był oddzielony od komputera jednym hubem. Obydwa testy dały pozytywne wyniki.
Z powodu braku 16 kart interfejsu linii telefonicznej praca urządzenia z 32 rozmowami prowadzonymi jednocześnie została sprawdzona w sposób zastępczy. Test polegał na zmianie programu na procesor DSP w taki sposób, żeby powielał on jedną rozmowę na 32 kanały. Wszystkie 32 (identyczne) rozmowy zostały zarejestrowane prawidłowo, co potwierdziło przewidywanie, że przepustowość interfejsu UDP-Ethernet będzie wystarczająca do wykorzystania pełnych możliwości urządzenia.
Ponieważ przed opracowaniem ostatecznej wersji rejestratora i programu komputerowego wykryte zostały liczne nieprawidłowości, niektóre z zastosowanych rozwiązań musiały zostać znacząco zmienione w stosunku do ich początkowych wersji.
Po pierwsze, po uruchomieniu urządzenia okazało się, że popełniłem kilka błędów przy projektowaniu płytki drukowanej. Dotyczyły one między innymi połączenia mikrokontrolera Atmel z procesorem DSP i umiejscowienia sygnałów na złączu, przez które płytka komunikuje się z interfejsami linii telefonicznych.
Poza tym, płytkę projektowałem korzystając z jej poprzedniej wersji z interfejsem USB. Dodatkową zmianą, poza wprowadzeniem łącza Ethernet na miejsce USB, było zastąpienie transoptorów izolatorami elektromagnetycznymi firmy Analog Devices. Wiązał się z tym problem, ponieważ przeoczyłem fakt, że transoptory wprowadzały inwersję logiczną sygnału, co nie występowało w nowych izolatorach. Jednak różnicę tę można było skorygować programowo, zmieniając polaryzację końcówek sterujących portu ESAI procesora DSP oraz dokonując negacji logicznej danych odbieranych z tego portu.
Kolejny problem dotyczył mechanizmu potwierdzeń i retransmisji. Rejestrator odbierał potwierdzenia z opóźnieniem około 250ms, co znacznie przekraczało założenia i nie pozwalało na efektywną transmisję. Dokładne przebadanie problemu wykazało, że jego przyczyną było pisanie raportów diagnostycznych przez program komputerowy, co drastycznie spowalniało jego działanie. W raportach tych zapisywana była zawartość wszystkich ramek odebranych przez program oraz inne informacje, mające na celu ułatwienie testowania. Po skróceniu raportów transmisja zaczęła przebiegać prawidłowo. W wersji ostatecznej programu zostały one całkowicie wyeliminowane.
Następnym elementem, który przysporzył problemy, była procedura odbioru danych z układu W3100A. Pierwotna jej wersja, będąca bezpośrednim przetłumaczeniem kodu Socket API, dostarczonego przez producenta układu, na język asemblera, okazała się zawodna. Problem polegał na tym, że jeżeli podczas odczytu danych z układu W3100A odbierał on następny datagram, nie powodowało to wywołania kolejnego przerwania przez ten układ. Skutecznym rozwiązaniem okazało się sprawdzanie po każdym odbiorze, czy w buforze nie znajduje się jeszcze jeden datagram.
Ponadto jeden błąd pojawił się w programie na mikrokontroler AT89C2051. Dotyczył on programowej implementacji protokołu SPI.
Wyeliminowanie wszystkich wymienionych i innych drobniejszych usterek sprawiło, że rejestrator funkcjonuje w pełni prawidłowo. Wobec tego może być on z powodzeniem stosowany do archiwizacji rozmów, co było celem jego projektowania.
komentarze
Copyright © 2008-2010 EPrace oraz autorzy prac.