Hallo Leute, ich habe ein EMG Messgerät mit Bluetooth 4.0 (cc2540) entwickelt. Leider bin ich jetzt todunglücklich ;) Der Grund ist folgender, Bluetooth 4.0 hat eine maximale Sendefrequenz von 133Hz. D.h. ich kann maximal Frequenzen von 65 Hz messen bzw. versenden. Das bringt mir aber nichts, weil ich die Frequenzen von 60-150Hz messen bzw. senden will. Leider habe ich keine Lösung für das Problem. Ich bräuchte dann einen anderen FunkMikrocontroller, der mit min. 200Hz senden kann. Was mir wichtig ist, dass es viel Doku bzw. Erfahrungen mit dem Chip gibt. Wie sieht es mit dem Atmega128 aus ? Danke. Gruß
??? Der Mikrocontroller ist doch völlig egal (nen 300sps ADC hat wohl jeder) Du brauchst halt ein Funkmodul das mit schnellerer rate senden kann.
Du musst mehrere Daten zusammenfassen und in einem Packet schicken. Also zB nur 10 mal pro Sekunde ein Packet schicken reicht eigentlich für eine Anzeige. Adib
Das klappt auch nich hab ich mir schon überlegt. Naja ich hab jetzt 120 HZ eingestellt. Trotzdem zu wenig.
Ich benutze eine Kombination aus Atmel Mega 1281 und at86rf212. Damit erreiche ich updateraten von 200 Messages pro Sekunde (8 16Bit Kanäle pro Message). Bei mir ist dann eher der Flaschenhals das vom Funkempfänger in den PC zu ziehen. http://www.an-solutions.de/products.html prinzipiell das Gleiche wie http://de.farnell.com/atmel/atzb-900-b0r/mod-zigbit-900mhz-balanced-port/dp/1773402?ref=lookahead Pro Protokoll gibt es aber noch Overhead durch die Funkübertragung bei jedem Datenpacket. Normalerweise erreichen 802.15.4 250kbit/sek. rein als Netto Datenrate. Wenn du jetzt noch Protokolloverhead abziehst und eventuell die Funkschnittstelle nur zu 10% auslastet und mit deinen Daten klarkommst, sollte das mit der KOmbination kein Problem sein. HTH, Adib.
Weshalb will man die Verbindung immer neu aufbauen. Lass die Verbindung doch einfach offen und sende ein endloses packet.
Kann ja auch gar nicht sein, da z.B. jedes Bluetooth Headset einen Audiostream simultan senden und empfangen kann. M.W. gibt es mittlerweile auch einen Stereo 'HQ' Dienst, der nochn bisschen mehr Daten schaufeln kann.
Kann es sein, das Du, "Brain", einfach nur 200 analoge Messwerte pro Sekunde übertragen möchtest? Das würde Deinem Anliegen zumindest den Ansatz eines Sinns verleihen. Die Stelle, wo Du suchst wäre aber die Falsche.
Adib schrieb: > Du musst mehrere Daten zusammenfassen und in einem Packet schicken. > Also zB nur 10 mal pro Sekunde ein Packet schicken reicht eigentlich für > eine Anzeige. Du hast recht. Das wäre die einfachste Lösung. Dann bräuchte ich den uC auch nicht wechseln. BT 4.0: Es können alle 7,25ms ca. 20 Byte verschickt werden. D.h. der A/D-Wandler tastet 7,25ms lang ab und ich schicke sie dann weg. Auf dem Rechner empfange ich das Paket. Fange dann an 7,25ms lang die Daten darzustellen bzw. auszuwerten. Nachteil: Ich bin dann auf dem PC 7,25ms in der Vergangenheit. Ok, danke an alle !
Adib schrieb: > Ich benutze eine Kombination aus Atmel Mega 1281 und at86rf212. > Damit erreiche ich updateraten von 200 Messages pro Sekunde (8 16Bit > Kanäle pro Message). > > Bei mir ist dann eher der Flaschenhals das vom Funkempfänger in den PC > zu ziehen. > > http://www.an-solutions.de/products.html prinzipiell das Gleiche wie > http://de.farnell.com/atmel/atzb-900-b0r/mod-zigbi... > > Pro Protokoll gibt es aber noch Overhead durch die Funkübertragung bei > jedem Datenpacket. > Normalerweise erreichen 802.15.4 250kbit/sek. rein als Netto Datenrate. > Wenn du jetzt noch Protokolloverhead abziehst und eventuell die > Funkschnittstelle nur zu 10% auslastet und mit deinen Daten klarkommst, > sollte das mit der KOmbination kein Problem sein. > > HTH, Adib. Das wäre eine elegante Lösung aber ich habe in die Einarbeitung bzw. Programmierung viel Zeit inverstiert und jetzt alles neu machen hab ich kein bock. Dann nehme ich lieber den Nachteil von oben in Kauf.
Hilfsrevoluzzer schrieb: > Weshalb will man die Verbindung immer neu aufbauen. Lass die Verbindung > doch einfach offen und sende ein endloses packet. Die Verbindung ist offen, das hat mit dem Frequenzhopping zu tun.
Brain schrieb: > Nachteil: Ich bin dann auf dem PC > 7,25ms in der Vergangenheit. Wenn du Windows und kein spezielles EchtzeitOS auf dem PC benutzt kannst du keine Vorhersage machen wie lange es dauert bis die Empfangenen Daten an dein Programm weitergereicht werden. Kann mal 7ms dauert, mal 1s. Je nachdem wie der PC halt gerade ausgelastet ist... Kenn auch solche Leute, die verlassen sich darauf das Windows ne bestimmte Zeit braucht und wundern sich wenn es später nicht mehr funktioniert weil noch was anderes im Hintergrund läuft...
Mal wieder ein gutes Beispiel für kranke Anforderungen bedingt durch kaputtes Konzept.
Simon K. schrieb: > Mal wieder ein gutes Beispiel für kranke Anforderungen bedingt durch > kaputtes Konzept. Das Problem liegt wohl eher bei der richtigen Umsetzung. Meines Wissens erlaubt Bluetooth 4.0 oder auch Bluetooth Low Energy einen Datendurchsatz von 0,2Mbit/s. Das ist wahrlich nicht viel, sollte aber für ein 150Hz Signal ausreichend sein. Für Ultra-low-power anwendung gibt es nur ANT und Bluetooth 4.0. Wenn es nicht Ultra-low-power sein muss, dann nimm doch einfach Bluetooth 3.0. Oder sag den Leuten hier was du vor hast und dann hilft dir jemand.
Sebastian H. schrieb: > Wenn du Windows und kein spezielles EchtzeitOS auf dem PC benutzt kannst > du keine Vorhersage machen wie lange es dauert bis die Empfangenen Daten > an dein Programm weitergereicht werden. Das spiel bei mir keine große Rolle. Tastkopf schrieb: > Das Problem liegt wohl eher bei der richtigen Umsetzung. Meines Wissens > erlaubt Bluetooth 4.0 oder auch Bluetooth Low Energy einen > Datendurchsatz von 0,2Mbit/s. Das ist wahrlich nicht viel, sollte aber > für ein 150Hz Signal ausreichend sein. Du kannst natürlich die Anzahl Bytes pro Ladung ändern aber nicht die Anzahl der Ladungen. Mein Problem ist gelöst, danke an alle !
Bitte 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.