Hi Leute, wollte mal fragen über welchen aufwand es möglich ist sprache digital über funkmodule zu übertragen (die conrad-standarddinger von aurel). Ist das leicht, also gibts dafür fertige ics oder ist das ein heiden aufwand ? meiner meinung nach bräuchte man ja nur nen a/d wandler und etwas was den datenstrom in seriell änderd , oder ?
Wie hoch ist den die Übertragungsgeschwindigkeit der Module in kBit/Sekunde? Wahrscheinlich scheitert das Ganze ausschliesslich an einem zu geringen Datendurchsatz der Funkstrecke. Gruß, Magnetus
die Datendurchsatzrate liegbt bei 19200 b/s also ca 20 kbits = 2,5 KByte Sprache benötigt eine Bandbreite von mind. 3000 hz, das heißt man könnte eine abtastfrequenz von 6 mal die Sekunde ansteuert (hört sich das an ??) was ist wenn man ne lauflängenkodierung zwischenschaltet ?, dafür müsste es doch einfachste bausteine geben oder ?
meisteralex wrote: > die Datendurchsatzrate liegbt bei 19200 b/s also ca 20 kbits = 2,5 KByte > Sprache benötigt eine Bandbreite von mind. 3000 hz, das heißt man könnte > eine abtastfrequenz von 6 mal die Sekunde ansteuert (hört sich das an > ??) Definitiv falsch gerechnet. 19200 b/s = 19200 BITs pro Sekunde Angenommen, du samplest das Audiosignal mit 8Bit und überträgst es der Einfachheit halber wie mit einer RS232 (1 Startbit, 8 Datenbit, 1 Stopbit), dann benötigst du für 1 Sample bereits 10Bit. Rechnung: 19200 Baud / 10 Bit = 1920 Byte/s Das macht dann heoretisch eine maximal übertragbare Frequenz von 910Hz. Klingt nicht gerade gut, oder? Gruß, Magnetus
>wie kommst du von 1920 Byte/s auf 960 Hz ? Shannon-Theorem http://de.wikipedia.org/wiki/Claude_Elwood_Shannon Klingt dann wirklich wie "Eimer"...
Nun, wenn man die Audiodaten unkomprimiert überträgt, dann genügt die Bandbreite nicht. Hat man aber auf beiden Seiten der Übertragungsstrecke ausreichend Rechenleistung zur Verfügung stehen, kann man die Audiodaten komprimieren und so die Bandbreite erheblich besser ausnutzen. Die von GSM-Telephonen verwendete Kompression (GSM 6.10) kommt mit einer Übertragungsrate von etwa 1 kByte/sec aus. Und wie gut die klingen kann, ist jedem "Händie"-Nutzer wohlvertraut. Weitere Informationen gibts hier http://kbs.cs.tu-berlin.de/~jutta/toast.html - ob die dort angebotenen Sourcen auf einen der üblichen µCs portierbar sind und ob dessen Rechenleistung genügt, das muss jetzt jemand anderes herausfinden. Viel Spaß dabei.
Bei den AM - Sendern von Conrad steht bei, das sie eine Bandbreite von 3khz haben ? was sagt mir jetzt diese angabe ??? http://www1.conrad.de/scripts/wgate/zcop_b2c/~flNlc3Npb249UDkwV0dBVEU6Q19BR0FURTAzOjAwMDEuMDEyMy5mNjlkMzQ3MSZ+aHR0cF9jb250ZW50X2NoYXJzZXQ9aXNvLTg4NTktMSZ+U3RhdGU9MzE4MzQ2MzA0MQ==?~template=PCAT_AREA_S_BROWSE&mfhelp=&p_selected_area=%24ROOT&p_selected_area_fh=&perform_special_action=&glb_user_js=Y&shop=B2C&vgl_artikel_in_index=&product_show_id=&p_page_to_display=DirektSearch&~cookies=1&zhmmh_lfo=&zhmmh_area_kz=&s_haupt_kategorie=&p_searchstring=funkmodul&p_searchstring_artnr=&p_search_category=alle&r3_matn=&insert_kz=&area_s_url=&brand=&amount=&new_item_quantity=&area_url=&direkt_aufriss_area=&p_countdown=&p_80=&p_80_category=&p_80_article=&p_next_template_after_login=&mindestbestellwert=&login=&password=&bpemail=&bpid=&url=&show_wk=&use_search=3&p_back_template=&template=&kat_save=&updatestr=&vgl_artikel_in_vgl=&titel=&darsteller=®isseur=&anbieter=&genre=&fsk=&jahr=&jahr2=&dvd_error=X&dvd_empty_error=X&dvd_year_error=&call_dvd=&kna_news=&p_status_scenario=&documentselector=&aktiv=&p_load_area=$ROOT&p_artikelbilder_mode=&p_sortopt=&page=&p_catalog_max_results=10 und es gibt auch highspeed module von aurel bei conrad die datenraten von 5-50 kbits bringen, würden die mehr bringen ?
Eigentlich brauchts "nur" das gsm_encode.c und das gsm_decode.c. Wäre ein Versuch wert, dass auf einen AVR zu portieren...
Oder wäre es nicht einfacher mit ADPCM zu komprimieren? Das töt weinigstens brauchbar und braucht nicht so viel Rechenleistung.
wie geh ich denn an die sache ran ? also erstmal nen a/d wandler und dann ???
Ein ARM dürfte wegen der geforderten 32-Bit-Arithmetik wohl geeigneter sein: > Our implementation [is] destined to be compiled and used > on a Unix-like environment with at least 32-bit-integers, > but others have ported it to VMS and a MS-DOS 16-bit-environment. Na schön, 16-Bit-CPUs gehen wohl auch, aber der AVR kann nunmal nur reine 8-Bit-Arithmetik. Alles andere ist entsprechend aufwendig in Software nachzubilden. > GSM 06.10 is faster than code-book lookup algorithms such as > CELP, but by no means cheap; to use it for real-time > communication, you will need at least a medium-scale workstation. Gut, eine "medium-scale workstation" von 1992 ist heute nicht mehr ehrfurchtgebierend. Zu der Zeit waren 386er mit 33 MHz "top notch", und da es wohl nicht auf FP-Arithmetik ankommt, sollte dessen Performance mit einem aktuellen ARM7-µC (Atmel SAM7xx oder Philips/NXP LPC2xxx) zu erreichen sein. Viel Spaß.
Servus Alex, was ist denn das Ziel - die Nutzanwendung - welche Qualität wird gewünscht? Ahoi D.
Warum überträgst du das Signal nicht analog? Die module sind an sich für analoge übertragungen ausgelegt (deshalb auch die Angabe der Bandbreite). Versuch doch einfach mal ein verstärktes Mikrofonsignal an den sender an zu schließen und den empfängerausgang einfach mit line in deines PCs verbinden.
Anwendungsfall ist einfach eine sichere Sprachübertragung zu gewährleisten. Die Module von Conrad können meiner meinung nach nicht direkt mit NF moduliert werden, wie soll das funktionieren, wenn der Eingang digital ist ?
Wenn es nur darum geht die Sprache halbwegs verstehen zu können, dann sollte sich mit ~20 kbit/s schon etwas hinbekommen lassen, auch ohne dass man schwere Geschütze wie GSM-Codecs auffahren muss. Nimm dir mal Matlab oder Scilab her und probier verschiedene einfache Komprimierungsverfahren durch. Vielleicht reicht es ja schon, einfach nur mit 2 Bit pro Sample zu quantisieren. Ansonsten: DPCM, logarithmische Quantisierung mit 2-4 Bit, ... auf einem AVR kein Problem.
Ale Komprimierungsverfahren haben aber einen Nachteil: Bei einem
Übertragungsfehler werden je nach Verfahren mehr oder weniger viel
Samples zerstört. Vor allem wenn ein Datenblock auf dem vorhergehenden
aufbaut. Schön ist das z.B. bei einem mpeg oder DivX Film zu sehen: Ein
Fehler ist bis zur nächsten Keyframe sichtbar, und das kann schonmal für
>10s sein.
Wenn man etwas mit Übertragungstechnik experimentieren will, ohne eine
große Bandbreitenbeschränkung zu haben: Mit einem Videosender kann man
problemlos auch UART Daten bis >1MBit/s übertragen: Das Sendesignal über
einen 330Ohm Widerstand auf den Sender geben, und am Empfänger das
Signal über einen Komparator mit 0,5V Schwelle wieder auf 5V Pegel
bringen.
Damit kann man dann wunderbar Audio in CD Qualität (16bit, Stereo,
44kS/s) übertragen. Nur ab etwa 20m Entfernung fangen dann die Fehler
an. Irgendeine einfache Fehlerkorrektur oder Erkennung sollte man also
einbauen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.