Guten Abend miteinander! Ich habe mal eine generelle Frage zu verschieden Funktechniken für den Einsatz in einem µC betriebenen Projektes. Es geht um folgende Aspekte für das Funkmodul 1. Reichweite (2 Meter würden schon dicke reichen) 2. Energieverbrauch (sollte möglichst klein sein, auch unter dem Aspekt es autark zu betreiben) 3. Datenmenge (diese ist sehr gering...im Endeffekt nur ein double das übertragen werden soll) 4. Preis (sollte relativ gering sein) 5. Richtung des Datentransfers: 1 Way würde fürs erste reichen aber natürlich ist bidirektional auch nett nun gibt es ja diverse Technologien von Bluetooth über RF aber nach stundenlanger (womöglich zu schlechter) Recherche konnte ich nicht auf einen Nenner kommen bezüglich den Vorteilen der Techniken. Welche Art von Modul würdet ihr benutzen? PS: Grob geht es um eine Temperaturmessung über einen Pt100. Der Temperaturwert soll dann per Funk an ein Display übertragen werden. Viele Grüße und nen schönen Abend
Student N. schrieb: > 3. Datenmenge (diese ist sehr gering...im Endeffekt nur ein double das > übertragen werden soll) Über wieviele Größenordnungen ändert sich denn deine Temperatur, dass du double brauchst? Beim mittleren Stromverbrauch kommt es bei manchen Systemen ganz entscheidend auf die Art der Übertragung drauf an. Auf der Sendeseite hängt es von der Datenmenge ab, auf der Emfangsseite vom Duty Cycle.
Miki schrieb: > Student N. schrieb: >> 3. Datenmenge (diese ist sehr gering...im Endeffekt nur ein double das >> übertragen werden soll) > > Über wieviele Größenordnungen ändert sich denn deine Temperatur, dass du > double brauchst? > > Beim mittleren Stromverbrauch kommt es bei manchen Systemen ganz > entscheidend auf die Art der Übertragung drauf an. Auf der Sendeseite > hängt es von der Datenmenge ab, auf der Emfangsseite vom Duty Cycle. Ahh ja gut es reicht ein float...denke mehr als 0,1°C Änderung bekomm ich eh nicht gemessen :) War gerade etwas verwirrt mit den Kommazahlen Und zu den Daten und duty cycle: Ich dachte so an ein mal alle 5 Sekunden einen Float XXX.X senden
Student N. schrieb: > René K. schrieb: >> NRF24L01 > > Das sieht ja schon mal echt nett aus! Ok ich sehe gerade...ist dieses Modul nur für einen Arduino? Oder könnte ich es auch mit einem anderen µC?
Student N. schrieb: > Ahh ja gut es reicht ein float...denke mehr als 0,1°C Änderung bekomm > ich eh nicht gemessen :) Der ist auch nicht nötig. Ein 16-Bit-Int reicht. Interpretiere den als Temperatur in Zehntelgrad, und Du kannst damit Temperaturen im Bereich von -3276.7 bis +3276.7 ° übertragen ... also viel mehr, als a) physikalisch möglich ist, b) Dein Sensor überhaupt erfassen kann und c) sinnvoll ist.
holger schrieb: >>Schau mal bei Pollin unter RFM12. > > Nimm Kabel;) Ich plädiere für eine Filterfunktion in diesem Forum, der unqualifizierte Beiträge zur empfohlenen Kabelnutzung beim Thema Funk kommentarlos löscht. Jedesmal kommt so etwas - das nervt gewaltig.
Rufus Τ. Firefly schrieb: > Student N. schrieb: >> Ahh ja gut es reicht ein float...denke mehr als 0,1°C Änderung bekomm >> ich eh nicht gemessen :) > > Der ist auch nicht nötig. Ein 16-Bit-Int reicht. Interpretiere den als > Temperatur in Zehntelgrad, und Du kannst damit Temperaturen im Bereich > von -3276.7 bis +3276.7 ° übertragen ... also viel mehr, als a) > physikalisch möglich ist, b) Dein Sensor überhaupt erfassen kann und c) > sinnvoll ist. Ok klingt logisch :) also reichen 16-bit Ich habe daran gedacht das ganze mit einem ARM® Cortex™-M0 zu betreiben, da ich mit dem PSoC Creator und PSoC allgemein schon etwas Erfahrung habe...auch wenn der PSoC 4 (mit dem ARM M0 wahrscheinlich maßlos übertrieben ist für diese Anwendung)
Student N. schrieb: > Ich habe daran gedacht das ganze mit einem ARM® Cortex™-M0 Um 12 Temperaturwerte pro Minute von einem Empfänger anzuholen und formatiert auf ein Display auszugeben? Oder soll das Display die Temperaturwerte als frei im Raum drehbare und animierte Graphik darstellen und das ganze aufgehübscht mit einstellbarer Beleuchtung und per Raytracing berechneten Helligkeiten in ein Echtzeitkamerabild einbauen.
Mr. Tom schrieb: > Student N. schrieb: >> Ich habe daran gedacht das ganze mit einem ARM® Cortex™-M0 > > Um 12 Temperaturwerte pro Minute von einem Empfänger anzuholen und > formatiert auf ein Display auszugeben? > > Oder soll das Display die Temperaturwerte als frei im Raum drehbare und > animierte Graphik darstellen und das ganze aufgehübscht mit > einstellbarer Beleuchtung und per Raytracing berechneten Helligkeiten in > ein Echtzeitkamerabild einbauen. Der M3 ist der einzige mit dem ich Erfahrung hab :) und da dacht ich an die Billigere M0 Version :) Aber ich lass mich gern auf einen kleineren µC hinweisen der die Anforderungen erfüllt :D
Mr. Tom schrieb: > Student N. schrieb: >> Ich habe daran gedacht das ganze mit einem ARM® Cortex™-M0 > > Um 12 Temperaturwerte pro Minute von einem Empfänger anzuholen und > formatiert auf ein Display auszugeben? Warum nicht? > Oder soll das Display die Temperaturwerte als frei im Raum drehbare und > animierte Graphik darstellen und das ganze aufgehübscht mit > einstellbarer Beleuchtung und per Raytracing berechneten Helligkeiten in > ein Echtzeitkamerabild einbauen. Es ist ein Cortex M0, kein Cortex M4.
Rufus Τ. Firefly schrieb: > Der ist auch nicht nötig. Ein 16-Bit-Int reicht. Interpretiere den als > Temperatur in Zehntelgrad, und Du kannst damit Temperaturen im Bereich > von -3276.7 bis +3276.7 ° übertragen ... also viel mehr, als a) > physikalisch möglich ist, b) Dein Sensor überhaupt erfassen kann und c) > sinnvoll ist. Man kann auch mit unsigned int 0 bis 6553,5K übertragen. Dann kann es noch ein bisschen wärmer werden und die Physik wird auch nicht auf den Kopf gestellt. Zum Übertragen würde ich RFM23 nehmen. mfg.
Student N. schrieb: > Der M3 ist der einzige mit dem ich Erfahrung hab :) Na was spricht denn dann gegen den STM32W mit integriertem ZigBee? Kostet beim hbe-shop (Farnell) 4,22EUR. Dazu noch 'nen Spannungsregler, 24Mhz Quarz, 'nen 2.4Ghz Bandpass + Balun + Chipantenne und los geht's. Für Cortex-M0 müsste es bei Atmel SAM's geben (ATSAMR21*), ist aber auch alles SMD, alternativ wohl auch AVRs (Atmega256 RF). > Aber ich lass mich gern auf einen kleineren µC hinweisen der die > Anforderungen erfüllt :D
Student N. schrieb: > Ok ich sehe gerade...ist dieses Modul nur für einen Arduino? > Oder könnte ich es auch mit einem anderen µC? Sollte eigentlich mit so gut wie jedem µC gehen. Student N. schrieb: > Aber ich lass mich gern auf einen kleineren µC hinweisen der die > Anforderungen erfüllt :D Wenn du einen internen ADC verwenden willst und dir 10bit Auflösung reichen könnte man es z.B. mit einem PIC12LF1840 (8 Pin) lösen. Von Atmel würde ein ATtiny in Frage kommen, dazu kann ich dir nichts sagen, da ich nur PICs programmiere. Falk Schilling schrieb: > 'nen 2.4Ghz Bandpass + Balun + Chipantenne Das wäre mir im Vergleich zu einem fertigen nRF24L01 Modul viel zu aufwändig. Diese kosten auch nicht wirklich viel: http://www.ebay.de/itm/251512918564
Max H. schrieb: > Falk Schilling schrieb: >> 'nen 2.4Ghz Bandpass + Balun + Chipantenne > Das wäre mir im Vergleich zu einem fertigen nRF24L01 Modul viel zu > aufwändig. Diese kosten auch nicht wirklich viel: > http://www.ebay.de/itm/251512918564 Jo, sollte auch reichen. Ich mag ZigBee halt ganz gerne aufgrund der Erweiterbarkeit der Netze: heute isses mal noch ein PT100, später will man mal noch 'nen anderen Sensor von woanders auf dem gleichen Display integrieren. Das nRF24L01 macht aber auch 'nen Guten, man hat damit deutlich weniger Aufwand und niedrigere Kosten - trifft den Anwendungsfall vielleicht besser.
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.