Hallo zusammen, ich hätte da mal eine Frage bezüglich der 2,4 GHz Funktechnik in PC-Mäusen und Tastaturen. Beispiel Logitech: Besitze selbst eine Funkmaus von Logitech und bin immer wieder begeistert wie lange da die Batterien reichen. Mach das Ding schon gar nimma aus ;-) Ob diese Maus bereits auf 2,4GHz funkt kann ich nicht sagen (liegt gerade daheim und ich kenne den genauen Typ nicht, knapp 2Jahre alt). Die Angaben für die Logitch Unifying Techonologie sind schon nicht schlecht z. B. Tastatur 3 Jahre Betrieb bei 2Mio Anschlägen / Jahr. Nun meine Frage. Kennt jemand die Sende-uCs die Logitech verwendet? Sind das "frei" verfügbare oder sind diese von Logitech selbst? Hintergrund: Ich benötige für einen Datenlogger (Batteriebetrieben, und möglichst kleine Abmessungen, kleiner 30x30x10mm) eine Funkschnittstelle die sehr stromsparend ist. Habe bereits etliche Funk-Chips angeschaut und miteinander verglichen. 2,4 GHz hat den Vorteil, dass dies Frequenz fast weltweit eingesetzt werden kann (benötige ich auch). Reichweite bis 1m benötige ich. RFID könnte auch funktionieren, allerdings sind die Antennen zu groß für meine Anwendung. Hat sich schon mal jemand mit der Funktechnik in Logitech oder andern Funkmodulen befasst. Die hier bekannten Funkmodule hab ich mir bereits angeschaut, sind aber leider nicht einsetzbar (Strom). Danke für eure Hilfe Gruß Stefan
Wie der eingesetzte Chip bei Logitech heißt weiß ich nicht, aber der CC2500 von TI ist für sowas bestens geeignet ... Als Datenlogger erreihct man locker Laufzeiten von >1 jahr mit einem satz AA Batterien ... je nach Aufwand der Sensoren und des µC ... ich hab hier einen im Einsatz, der eine Einsatzzeit von 2 Jahren hat und alle paar Sekunden seine Daten sendet .... P.S. hat 2,4Ghz Snedefrequenz ;)! aber guck dich mal bei TI um, die haben da noch mehr!
sorry war eben nicht eingeloggt, kann das nicht bearbeiten: Hier eine Entwicklungsboard mit den Abmaßen 30x15x0,5: (genug Platz für eine Batterie und Sensoren ... bei deinen Maßen) http://focus.ti.com/docs/toolsw/folders/print/ez430-rf2500.html
Wie viele Daten willst du denn in welcher Zeit übertragen? Wo kommen die Daten her, brauchst du dafür sowieso noch einen Controller?
Hi Mathias, danke für die Info. Den CC2500 kenne ich und gefällt mir eigentlich auch ganz gut. Habe von Amber Wireless ein kleines Funkmodul zum testen, ist auch der CC2500 drauf. Anbindung über USART oder SPI. Leider ist der darauf befindliche MSP430 nicht ausreichend für meine Anwendung. Habe mal einen zusätzlichen uC per USART zum Testen drangehängt. Bin vom Speed und der Implementierung her aber noch nicht ganz glücklich. Die TI Module sind aber vielversprechend. Danke für deine Erfahrungen bezüglich Laufzeit. Beim mir müsste der uC ca. 3000 mal am Tag aufwachen und einen Zeitstempel im Speicher hinterlegen (also ne Sache von wenigen ms). 1x am Tag muss der komplette Inhalt dann zu einer Basisstaion gesendet werden. Die zur Zeit vorgesehene 540mAh Knopfzelle sollte ca. 6 Monate den Dienst tun. Wenn noch jemand was über die Logitech Funk-uCs herausgefunden.... bin immer noch interessiert ;-) Gruß Stefan
@Jörg sind ca. 6000-18000 Byte die täglich (besser gesagt 5x/Woche für ca. 26 Wochen) übertragen werden müssen. Das aufwachen des uC, um den Zeitstempel aufzunehmen, wird durch einen exteren Interrupt angetriggert. Ein MSP430 schläft bei mir ansonsten im LPM4. Momentan sind 4Mbit Falsh vorgesehen; möglicherweise beitet sich ein EEPROM eher an da 1Mbit vollkommen ausreichend sind, dieser einen größeren Spannungsbereich und geringeren Stromverbrauch hat (zumindest das was ich bisher rausgefunden habe, z. Z. Atmel Flash). Eure Einschätzung Danke Stefan
Stefan P. schrieb: > sind ca. 6000-18000 Byte die täglich (besser gesagt 5x/Woche für ca. 26 > Wochen) übertragen werden müssen. Am Stück, einmal täglich? Oder in Häppchen? > Momentan > sind 4Mbit Falsh vorgesehen Wofür dies? Ich denke, er funkt die Daten, oder sammelt er sie erst?
Das mit dem Speicher muss man abwägen, wenn die BAsisstation sowieso immer zur Verfügung steht kann es sinnvoll sein die Daten sofort zu denden (also öfter als 1mal pro Tag) um so ohne externen Speicher auszukommen) ... der Atmel Flash verbraucht z.B. im sleepmode immernoch 25µA ... also u.U. mehr als alles andere in deiner Schaltung. Abzuwägen ist für den Zeitstempel ob man eine externe RTC verwendet oder den µC damit beauftragt ... was auf jeden Fall sinn macht ist das Abspeichern im Timestamp(Unix)-Format ... verringert Speicherbedarf und Übertragungsmenge ...
Übertragung erfolgt an einem Stück, da sich der Datenlogger nicht immer in Reichweite zur Basisstaion befindet. Somit werden die Daten im Speicher hinterlegt. Der Zeitstempel wird bereits in 4 Byte bitweise kodiert, dazu kommen noch 2 Byte Messwert (Zeitdifferenz in Sekunden zwischen zwei Interrupts). Für den Zeitstempel ist momentan eine RTC verbaut.
komplizierte Berechnungen sollte man sowieso nicht unbedingt auf dem µC vornehmen, kostst alles nur Strom ... lieber Rohdaten speichern und dann nachbearbeiten! ... ansonsten ist der MSP recht gut aufgestellt, besonders der Wechsel von Sleep->active geht anders als bei anderen µCs sehr schnell und damit sind auch zeitkritische anwendungen denkbar, aber ich dneke du musst nochmal genau sagen worum es am Ende geht, damit man abschätzen kann warum der MSP nicht ausreichen sollte.
Sorry da hab ich mich dann wohl verkehr ausgedrückt. Auf dem Amber Funkmodul ist zum einen der CC2500 und noch eine MSP430F1232 drauf. Diesen MSP habe ich gemeint. Den kann ich rein theoretisch auch für meine Aplikation verwenden, wobei da dann die I/Os knapp werden (Speicher, Interrupt, ....). Die darauf befindliche FW hätte ich als HEX-File bekommen und diese müsste ich dann in meinen Code implementieren (war mir neu das das geht aber auch nicht verkehrt). Alternativ habe ich auch mal eine offene Lib für die Anbindung eines CC2500 gefunden. Berechnungen mach ich auf dem uC soweit nicht. Das Datum wird halt konvertiert (spart Speicher, weniger Funkübertragung) und die Zeitdifferenz wird erfasst. Hällt sich somit eigentlich in grenzen. Zum Testen des Amber Moduls habe ich dann einen externen MSP dran gehängt.
MSP430 gibts ja in allen Größen, da ist für jeden was dabei ... wenn du sagst wieviele Eingänge du brauchst könnten wir dir besser helfen ... der Speicher braucht 4(für SPI) ansonsten kannst du das SimpleTI-protokoll verwenden, das gibs bei TI auf der Homepage ... macht die Kommunikation recht einfach ,.... guck dir dazu mal http://cnx.org/content/col10684/latest/ an ... ist zwar der MSP430F2274 aber immerhin der CC2500 ... und seine performence mit dem SimpleTI Protokoll
Danke für das Angebot. Die Auswahl des MSP ist nicht das Problem. Was ganz praktisch ist, die größeren MSP haben sogar mehrere unabhängige spi, usart, ... Mein Problem ist die Auswahl eines geeineten Funk-uCs der möglichst wenig Strom verbraucht. Wobei die meisten, die ich mir bisher angesehen habe, ungefähr gleich "verschwänderisch" sind. Im 2. Schritt steht dann der Spannungsbereich, bei 3V Li-Ion Konpfzelle, sollte schon so 1,8 - 3,6V drin sein. Drum auch die überlegung mit dem Flash -> EEPROM, da die Flashes bei frühestens 2,5V anfgangen (zumindest hab ich noch nix besseres gefunden). Auf Step-Up bin ich nicht sonderlich scharf -> Wirkungsgrad -> hoher Strom Kann es sein, dass Logitech Cypress Controller verwenden?
Stefan P. schrieb: > Übertragung erfolgt an einem Stück, da sich der Datenlogger nicht immer > in Reichweite zur Basisstaion befindet. Woher weiß der Sender dann, dass der Logger in seiner Reichweite ist? Wenn der auch noch parallel hören muss, kannste das mit dem Strom- verbrauch nämlich sofort knicken. Die pure Empfangsbereitschaft kostet bei 2,4 GHz genauso viel Strom wie das Senden.
Kann sein ... muss aber nicht ... zum Teil ändert sich auch während der Produktion der Chiptyp ... sprich in einem ist einer von Cypress und im andern einer von TI (nur Beispielhaft) ... also aufschrauben und nachgucken??? Wichtiger als der Chip ist wohl die Antenne und die Sendeleistung, der Chip an sich verbraucht nicht viel, eher der Verlust beim senden .. bei deinem Aufbau wird wohl eher eine Chipantenne oder eine PCB-Leiterschleife anzuwenden sein ... da stecken die Verluste ... Also eher etwas größer (leistungsstärker) kaufen und dann lieber die Sendestärke herunterlegen ... moderne chips passen den Stromverbrauch abhängig vom RSSI-Wert an ... sprich, die Empfangsstärke ist sehr gut --> sendeleistung wird heruntergeschraubt ... da ist mehr herauszuholen als durch die Auswahl des perfekten ICs ...
@ Jörg Preamble Sampling oder Abgleich der Uhren und feste Sendezeitpunkte ...?! Uhrenvergleich ...es ist 15:12Uhr ;)
Danke für die rege Beteiligung, lauschen muss der Datenlogger nicht, nur die Basisstation. Der Logger probiert halt sagen wir mal 3-5mal am tag ob er die Basisstation erreicht, wenn ja -> Daten senden, ansonsten später nochmal versuchen. Die Überlegung mit dem "Uhrenvergleich" hatte ich auch schon. Mal schaun was daraus wird. Die Informationen bezüglich Sendeleistung, Verluste, ... sind sehr gut.
>Die pure Empfangsbereitschaft >kostet bei 2,4 GHz Bist Du da sicher? Mit den CC1100 (868MHz, 433MHz) ist das nicht so. Außerdem hängt der Verbrauch ja auch noch von der eingestellten Sendeleistung ab. Das ist bei der Receive-PLL konstant.
Sorry mein Post bezieht sich auf : > Die pure Empfangsbereitschaft > kostet bei 2,4 GHz genauso viel Strom wie das Senden.
Horst Rubbelspecht schrieb: >>Die pure Empfangsbereitschaft >>kostet bei 2,4 GHz > > Bist Du da sicher? Ja. Guck dir den CC2420 an (um bei ChipCon^WTI zu bleiben), oder die AT86RF230 etc. ICs. > Mit den CC1100 (868MHz, 433MHz) ist das nicht so. Ist ja auch eine deutlich geringere Frequenz. Der AT86RF212 braucht beim Empfang auch schon viel weniger als seine 2,4-GHz-Geschwister. ChipCon hat keine richtigen Pendants zwischen beiden Frequenzbereichen, bei denen das Backend einigermaßen vergleichbar ist (der CC1100 hat ja kein IEEE-802.15.4-Basisband, die Frameerkennung dort kostet auch nochmal ein wenig Strom). > Außerdem hängt der Verbrauch ja auch noch von der eingestellten > Sendeleistung ab. Das ist bei der Receive-PLL konstant. Dafür klappern beim Empfänger ziemlich viele Digitalgatter. Um nochmal den CC2420 zu zitieren: der Empfänger verbraucht laut Datenblatt typisch 18,8 mA. Der Sender verbraucht bei maximaler Ausgangsleistung von 0 dBm gerade mal 17,4 mA, die man bei minimal einstellbarer Leistung bis 8,5 mA herunter bekommt. Das Atmel- Pendant dazu wäre der AT86RF230, Rx-Modus 16 mA, Tx (3 dBm) 16 mA, Tx (-17 dBm) 10 mA. Das Gegenstück für 868 MHz (AT86RF212) braucht Rx 8,7 ... 9,2 mA, also etwas mehr als die Hälfte, Tx braucht er 13 mA bei 0 dBm. Ich wollte ja vor allem darauf hinaus, dass man bei UHF nicht davon ausgehen kann, dass nur das Senden "richtig Strom" brauchen würde und man im Empfangsmodus mit 1/10 davon oder weniger auskäme. Daher muss man sich Gedanken machen, wie man (falls eine Empfangsbereitschaft gewünscht ist) ein Zeitschlitzschema oder sowas findet, um den Stromverbrauch zu minimieren. Ist jedoch für Stefan kein Thema.
Stefan P. schrieb: > Der Logger > probiert halt sagen wir mal 3-5mal am tag ob er die Basisstation > erreicht, wenn ja -> Daten senden, ansonsten später nochmal versuchen. Das heißt aber, er braucht eine laufende Uhr, damit er zeitgesteuert aufwachen kann. Dann kann er sich nicht komplett schlafen legen. Ich habe die Rechnung mal für einen ATmega128RFA1 gemacht (weil ich dafür gerade eine Messung der Stromaufnahme da liegen habe). Der braucht für eine Sende-Empfangs-Transaktion mit Bestätigung (wenige Nutzdatenbytes) etwas mehr als 4 µC. Wenn man die Sendung ausdehnt auf 100 Byte Nutzdaten (kommt noch etwas Adressierungsinformation dazu, und die maximale Rahmenlänge von IEEE 802.15.4 ist 127 Byte), dann kann man das bei 13 mA für den Sendebetrieb auf ca. 40 µC pro 100 Byte hochrechnen. Deine 13000 Byte würden also ca. 5,2 mC benötigen. Dazu kämen noch ca. 10 µC (wegen der Wiederholung) für jeden Kontaktaufnahmeversuch, das ist vernachlässigbar. Die 5,2 mC pro Tag auf 5 Tage und 26 Wochen hochgerechnet wären dann 0,68 C, oder 0,19 mAh. Ich glaube, das macht noch jede Batterie mit, die man so kaufen kann. ;-) Hinzu kommt die Rechnung mit dem Standby-Strom, damit ein 32-kHz- Oszillator sich um das regelmäßige Aufwecken kümmern kann. Das Datenblatt des ATmega128RFA1 macht leider keine Angaben zum power-save-Strom, nehmen wir mal die Daten vom ATmega1281, dann müssten das so um die 2,5 µA sein. Das sind auf 26 Wochen dann 39,3 C und damit viel mehr als der Energieverbrauch im aktiven Betrieb, aber immer noch nur 11 mAh. Fazit: mit 2 x LR03 (800+ mAh) kannst du mit einer derartigen Einrichtung bei deinem gewünschten Datenübertragungsschema wohl über einige Jahre arbeiten. ;-)
Hallo Jörg, danke für die Berechnung. Habe selbiges schon mal für einen CC2500 und MSP430Fxy anhand der Datenblattwerte und ziemlich ziemlich großzügigen Werten berechnet. Wenn ich mich da nicht total vertan habe sinds bei mir für 6 Monate ca. 240mAh. Wenn ich mir jedoch die differenzen anschaue, dann sollte ich die Berechnung nochmals anschauen. Messung von realen Werten folgen auch mal noch. Was sich dekt ist das Verhältnis Standby - Senden -> selbst wenns senden etwas länger dauert, oder ein paar mA mehr; Hauptsache der Standby ist so gut wie möglich optimiert. Gruß Stefan
Hallo, den Flash oder andere Chips die man nicht fürs aufwecken baucht kann man ja auch noch via MosFet/Bipolartransistor die Versorgungsspannung wegnehmen. Viele Grüße, Martin
Stefan P. schrieb: > Wenn ich mich da nicht total vertan habe sinds bei mir > für 6 Monate ca. 240mAh. Ich habe deinen Flash-Speicher nicht bedacht, wobei mir dessen Funktion (bzw. Notwendigkeit) noch nicht ganz klar ist. Der ATmega128RFA1 hätte 16 KiB SRAM, das müsste doch komplett für deine Zwischenspeicherung genügen, oder? Damit hättest du den Controller und den Transceiver dann auf einem IC. Bei den Stromverbrauchsangaben für Flash oder EEPROM muss man aufpassen, dass man nicht die Garantiewerte anguckt, sondern die typischen Werte. Die Garantiewerte werden ja in aller Regel selbst unter ungünstigsten Bedingungen (Tmax und Vccmax) noch unterboten, und gerade die Temperatur hat einen extremen Einfluss auf die Leckströme von CMOS-Schaltungen. Wenn deine Schaltung in der Regel nicht bei Temperaturen oberhalb 40 °C betrieben wird, kannst du die Lebensdauerberechnung problemlos mit den typischen Werten plus einer Sicherheitsreserve vornehmen.
Hallo Jörg, leider bin ich durchaus dazu gezwungen einen externen Speicher mit zu implementieren. Die Anwendung zeichnet ein Nutzerprofil auf. 3000 Werte a 6Byte (pro Tag) sind voraussichtlich schon sehr hoch angerechnet. Sicher sagen kann ich das aber erst wenn echte Daten über einen längeren Zeitraum vorliegen. Dazu kommt noch, dass es vom menschen abhängt ob der Datenlogger abends zur Basisstation gelegt wird. Im Wurst Case rechne ich damit, dass der Datenlogger nur eimal pro Woche an der Basisstaion plaziert wird. D. h. der Speicher sollte mindestens 5 Tage a 3000 Werte aufzeichnen können. Das die Datenübertragung per Funk somit länger dauer und sich die Knopfzelle darüber freuen wird ist mir auch klar. Kann dann halt evtl. nicht alles auf einmal übertragen werden, sonder in mehreren kleine Happen mit mehreren Sekunden / Minuten Pause dazwischen. Temperaturnivea ist wieder ein ganz anderes Thema. Für die Aufzeichnung der Werte wird der Datenlogger in einer Umgebung mit ca. 50°C (bei ca. 20°C Raumtemperatur) sein. Umgebungstemperatur kann aber auch bis auf +40°C oder unter 0°C kommen. Für die Übertragung der Werte per Funk kann die Umgebungstemperatur angenommen werden. Gerade bei den niedrigen Temperaturen (möglicherweise sogar im negativen) wird sich die Batterie drüber freuen und mal ordentlich in die Knie gehen. Wie weit der sichere Betrieb bei niedrigen Temp. möglich ist wird ein Versuch und die Zukunft zeigen. Genügend große Pufferkondensatoren müssen da dann vorgesehen werden. Nur dumm das dadurch der Leckstrom und somit der Standby Strom ansteigt. Wird wohl auf einen Kompromiss hinaus laufen. Gruß Stefan
Um an die Ursprungsfrage einmal anzuknüpfen. Logitec verwendet ausschließlich Funkcontroller von Nordic Semiconductor mit dem Gazell-Protokoll. In Tastatur und Maus ist meist der nrF24LE1 und im USB-Dongle der nRF24LU1+ verbaut. http://www.nordicsemi.com/index.cfm?obj=product&act=display&pro=95 Alle Datenblätter einschließlich kompletten Schaltungen mit Platinenlayout sind dort für alle Funkcontroller frei verfügbar. Lediglich Atmel reicht überhaupt an die Effizienz und Stromarmut der Nordic-Funk-Controller heran. Außer dass die Nordic-Chips keinen direkten Touch-Support auf dem Chip haben (im Vergleich zum beispielsweise erwähnten ATmega128RFA1) lassen sie nichts vermissen. Das komplette Funkprotokoll einschl. aller bidirektionalen Funktionen und der Pairing-Möglichkeit zu 6 Geräten und den Tastenabfragen usw. braucht ca. 11KB Speicher (abgespeckt je nachdem was man braucht reichen mitunter auch weniger als 4kB), auf den Controllern (ohne USB) sind 16kB verfügbar, auf den USB-Controllern sind es 32kB, soweit ich mich erinnere. Gruß Sven
Stefan P. schrieb: > ür die Aufzeichnung > der Werte wird der Datenlogger in einer Umgebung mit ca. 50°C (bei ca. > 20°C Raumtemperatur) sein. Umgebungstemperatur kann aber auch bis auf > +40°C oder unter 0°C kommen. Dann solltest du dir die Reststromdiagramme mal ansehen und damit die Batterielebensdauer abschätzen. Falls der Reststrom des Flashs bei diesen Temperaturen wirklich so hoch wird, dann würde ich Martins Vorschlag aufgreifen und diesen bei Nichtbenutzung abschalten. Das geht mit einem p-Kanal-FET oder auch einfach mit einem pnp-Transistor. Letzterer zieht zwar im aktiven Betrieb Basisstrom, aber wenn man die Aktivzeiten kurz hält, ist das egal. p-Kanal-FET mit 1,8 V Schwellspannung (das wäre die Entladeschlussspannung zweier Alkali-Mangan-Zellen) ist nicht so ganz einfach zu finden. Mit der Kälte würde ich mir keine übermäßigen Gedanken machen, solange du nicht gerade aus Platzgründen mit sehr kleinen (Knopf-) Zellen auskommen musst. LR03 sind allemal auch bei -10 °C für die paar mA hier noch stromergiebig genug.
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.