Hallo zusammen, Bei dem 433MHz „Grillen-Fuchs“ handelt es sich um einen sehr simplen Fuchssender, welcher neben dem Funksignal zur Ortung, auch ein akustisches Signal von sich gibt (für den Nahbereich). Das akustische Signal ist dem Klang einer Grille nachempfunden. Hierbei wurde ein echtes „Grillen-Sample“ verwendet, wobei dieses Sample D/A gewandelt (per PWM) und auf einen Lautsprecher gegeben wird. Der ATTINY wird in den Pausen zwischen dem Senden immer in den Power-Down-Modus versetzt. Die Stromaufnahme der gesamten Schaltung beträgt dann etwa 5uA. Je nach Pausendauer kann der Sender dann wochenlang mit einer Batterie auskommen. Verwendet werden diese kleinen 433MHz Billig-Sender für Datenübertragung im ISM-Band. Die Kosten für die ganze Schaltung liegt dann bei wenigen Euro. Im Anhang eine ZIP-Datei mit dem AVR-Studio Projekt und einem PDF mit der Beschreibung und dem Schaltplan. Vielleicht kann das ja jemand brauchen. VG, Jo D
Hallo nochmal, am Besten die aktuelle Version (siehe Anhang) nutzen.
Jo D. schrieb: > Hallo nochmal, > > am Besten die aktuelle Version (siehe Anhang) nutzen. Der Thread wurde gerade von anderer Seite verlinkt. Nette Idee, aber leider ist dein Code unvollständig. Ich vermisse z.B. die Funktionen power_all_disable() und power_all_enable(). Ich werde den Zirp-Teil bei Gelegenheit mal ausprobieren.
Mario M. schrieb: > Isser nich. 😛 Ja, ich hab es inzwischen auch bemerkt. Ich kannte die Makros nicht, hat aber übersetzt 😉 und zirpt schon ...
@power management, da geht noch was/mehr! - power_all_enable() ist sinnlos verwendet, da nur tmr0 benutzt wird, daher besser ersetzen mit power_timer0_enable() - analog Comparator ist im power.h für attiny45/85 nicht adressiert und darum nicht disabled, hierzu ist ACSR |= _BV(ACD); einzufügen - wdt isr da reicht EMPTY_INTERRUPT(WDT_vect); - Bit Schieberrei mit (1<< ...) ist grausam, da das gcc Makro _BV() schon immer existiert, welches genau das erledigt und dann besser Makros verwenden für set/clear Bit #define mSBit(r,b) r |= _BV((b)) //set bit #define mCBit(r,b) r &= ~_BV((b)) //clear bit Das Soundsample Array würde ich in eine extra Header Datei auslagern und dann kann man den Code fast lesen ... :-)
... noch 3,5 Hinweise! 1. Der Speakersound wird wesentlich lauter, wenn dieser nicht an Ground gelegt wird, sondern an den zweiten PWM Pin und dann als inverted Output angesteuert. Also OCR0B und OCR0A benutzen. 2. Wenn interne pull-up's deaktiviert werden, dann sollte der Input in dieser Zeit auf analog Input geschaltet werden. Daa spart Energie (da die digitale Inputschaltung deaktiviert wird) und verhindert Problem hinsichtlich floating Input. 3. Outputs (z.B. Speaker) im aktiv Sleep Mode sollten, wenn möglich, deaktiviert werden. 3.5 Deine Programstruktur sollte überdacht werden, einige Unterfunktionen sind sinnlos, da diese nur einmal und dann auch nur mit einer Anweisung ... aufgerufen werden.
WauWau schrieb: > - analog Comparator > ist im power.h für attiny45/85 nicht adressiert und darum nicht > disabled, hierzu ist ACSR |= _BV(ACD); einzufügen Ich habe den Code mal in einen Tiny85 verfrachtet und konnte keinen Unterschied bei der Stromaufnahme feststellen zwischen ACD=0 (default) und ACD=1. Auch ADEN ist überflüssig - macht man nichts dran, ist er sowieso aus. > - wdt isr > da reicht EMPTY_INTERRUPT(WDT_vect); Die ganze WD-Timer Geschichte ist imho viel zu kompliziert aufgesetzt - außer man will den WD auch als Reißleine nutzen. Diese Notwendigkeit sehe ich eigentlich nie. Sonst reichen im Setup WDTCR = (1<< WDIE ) | (1<< WDP2 ); und ein EMPTY_INTERRUPT(WDT_vect); ohne den WD sonst noch zu beeinflussen. > - Bit Schieberrei mit (1<< ...) ist grausam, Naja, das ist eine persönliche Stilfrage. Für die Ports nehme ich gerne die sbit.h von Peter D., das bringt wesentlich mehr Übersicht. Bei den Registern lasse ich es beim 'grausam' 😀. WauWau schrieb: > ... noch 3,5 Hinweise! zu 1.: Ja, wenn man einen hochohmigen Lautsprecher (≈ >200Ω) hat. Braucht man eh einen Transistor um den Portpin zu entlasten, dann wird's deutlich aufwändiger. zu 2.: Ja, die Modeschalter sind nur Schließer, wenn sie offen sind floaten diese Pins. Andere Variante: Umschalter verwenden oder eben fest verdrahten / fest einprogrammieren. zu 3.: Der Speaker wird im Code deaktiviert. Er schaltet den Pin nach Soundausgabe auf Eingang, der LS selber verhindert ein floaten:
1 | // Ausgang deaktivieren
|
2 | DDRB &= ~(1 << GRILLE_PIN); |
3 | PORTB &= ~(1 << GRILLE_PIN); |
zu 3.5: Sehe ich auch so, wird nur unübersichtlich. Die paar Zeilen für die Inits würden bei mir direkt in der main vor der Endlosschleife stehen. Ist für mich übersichtlicher.
... ich wünsche mir noch andere Tiergeräusche, als Option z.B. Bienen Sum- Sum oder Katzen Miau. :-) Auch würde ich die Aussendung einer sinnvollen Nachricht/Kennung gut finden. Der analog Comparator fordert rund 35uA (Datenblatt, S. 197) ein. Richtig, für Wakeup from Sleep/Idle Mode sind nur entsprechend gewünschte Event Resourcen notwendig und nicht ein tatsächlicher Interrupt. Allerdings kann es nicht schaden für Sämtliche Interrupt Vektoren ein reti via EMPTY_INTERRUPT() zu setzen ... man weis ja nie :-). Im Sleep Mode wo möglich, setze ich gerne alle Ports auf analog Input und ansonsten auf digital Output Low. Es gibt immer was, um weiter rumzuspielen. Keep going!
... ich wünsche mir noch andere Tiergeräusche, als Option z.B. Bienen Sum- Sum oder Katzen Miau. :-) Auch würde ich die Aussendung einer sinnvollen Nachricht/Kennung gut finden. Der analog Comparator fordert rund 35uA (Datenblatt, S. 197) ein. Richtig, für Wakeup from Sleep/Idle Mode sind nur entsprechend gewünschte Event Resourcen notwendig und nicht ein tatsächlicher Interrupt. Allerdings kann es nicht schaden für Sämtliche Interrupt Vektoren ein reti via EMPTY_INTERRUPT() zu setzen ... man weis ja nie :-). Im Sleep Mode wo möglich, setze ich gerne alle Ports auf analog Input und ansonsten auf digital Output Low. Die zwei Mode Ports könnten auch z.B. mit externen 1-2M Pull-up R's betrieben werden. Es gibt immer was, um weiter rumzuspielen. Keep going!
WauWau schrieb: > ... ich wünsche mir noch andere Tiergeräusche, a Darfst du, aber nicht von mir - ich bin nicht der TO. Aber nimm doch ein Aufnahmegerät, speichere die Daten als RAW Wavedatei mit 8Bit und 11025kHz ab, schreib ein kleines Programm, das die diese Daten von Binär in Dez wandelt, zähle 128 dazu und fertig ist dein neues Geräusch. > Der analog Comparator fordert rund 35uA (Datenblatt, S. 197) ein. Messen kann ich knapp 7µA unabhängig vom ACD-Bit. Also muss er aus sein. Warum auch immer.
@WauWau & HildeK & Co Ein ganz großes Dankeschön für die vielen Verbesserungs-Ideen. Es macht richtig Spaß es zu lesen! Ich kann da eigentlich gar nicht widersprechen. Wenn einer von euch Lust hat, kann er den Code gerne entsprechend verbessern! :)) Bezüglich alternativen Sounds: Einfach Wunschsound hier (als MP3 oder so) posten, dann mache ich daraus gerne ein entsprechendes Array. Nochmals ein dickes Danke! Jo
Jo D. schrieb: > Ein ganz großes Dankeschön für die vielen Verbesserungs-Ideen. Es macht > richtig Spaß es zu lesen! Großen Dank an dich für die nette Idee! Schön, dass du dich noch meldest nach fast einem Jahr ... > Ich kann da eigentlich gar nicht > widersprechen. Wenn einer von euch Lust hat, kann er den Code gerne > entsprechend verbessern! :)) Ich hänge mal meinen an, der das 'sbit.h' von PeDa verwendet. Es ist eigentlich keine Codeverbesserung, sondern nur eine mir genehmere Darstellung, so dass ich nicht so oft suchen muss, was du denn wo untergebracht hast. Auch verwende ich kaum die Makros von der avr-libc. Für mich so wesentlich lesbarer, aber das sind eben die persönlichen Unterschiede; beim Hobby muss ich mich nicht an vorgegebene Konventionen halten ... Bezüglich WD: wolltest du den WD nur als Timer oder auch als Watchdog, der im Fehlerfall resettet? Letzteres habe ich entfernt. Den Wachhund habe ich bisher nie verwenden müssen ... Der Code sollte also das selbe tun wie deiner, wenn man vom #define SENDER die Kommentarstriche entfernt, so dass die #ifdef-Bereiche mit übersetzt werden. Ich habe keinen Sender 😀. > Bezüglich alternativen Sounds: > > Einfach Wunschsound hier (als MP3 oder so) posten, dann mache ich daraus > gerne ein entsprechendes Array. Du darfst gerne mal kurz erklären, wie du vorgegangen bist. Ich habe es so erfolgreich versucht: mit einer DAW einen File mit 'Kuckuck' in Mono 11025kHz 8Bit konvertiert, als RAW abgespeichert und dann mit einem Editor, der einen binäre Datensatz direkt als C-Array in HEX ausgeben kann das Feld erzeugt. Man könnte sich auch ein Progrämmchen schreiben ... Im Anhang ist der Kuckuck als Datensatz drin, man braucht aber dann den Tiny85. Oder du ersetzt das Array und 'GRILLE_SOUND_SAMPLES' wieder durch deine Werte. Ist jetzt halt keine Grille mehr 😉
HildeK schrieb: > Du darfst gerne mal kurz erklären, wie du vorgegangen bist. > Ich habe es so erfolgreich versucht: mit einer DAW einen File mit > 'Kuckuck' in Mono 11025kHz 8Bit konvertiert, als RAW abgespeichert > und dann mit einem Editor, der einen binäre Datensatz direkt als C-Array > in HEX ausgeben kann das Feld erzeugt. Würde mich auch interessieren, welche Tools ihr da so verwendet! DAW bedeutet was und welcher Editor erzeugt mir aus binär Daten das Array? Glaube, es gab auch eine Variante von sbit.h unter Verwendung von sbi/cbi was dann die beste Wahl bzgl. Speed/Size wäre. Leider habe ich schon wieder alles dazu vergessen ...
WauWau schrieb: > DAW bedeutet was und welcher Editor erzeugt mir aus binär Daten das > Array? DAW = Digital Audio Workstation, ein Programm, mit dem man Audiofiles verarbeiten kann. Da gibt es viele, siehe https://de.wikipedia.org/wiki/Digital_Audio_Workstation Vermutlich können nicht alle RAW ausgeben, aber mit ein wenig KnowHow bez. dem WAV-Format kann man den Header identifizieren und löschen und hat dann RAW. Mit Audacity geht es jedenfalls auch. Als HEX-Editor habe ich WinHEX zur Verfügung. Alternativ kann man sich ein kleines Tool schreiben, das binäre Daten liest und als Dezimal- oder Hex-Werte ausgibt. Selbst Notepad++ hat einen Konverter von ASCII in HEX drin, mit dem müsste es auch gehen, wenn auch mit einiger Nacharbeit. > Glaube, es gab auch eine Variante von sbit.h unter Verwendung von > sbi/cbi was dann die beste Wahl bzgl. Speed/Size wäre. Och, der Compiler verwendet da auch sbi bzw. cbi - schneller und kleiner geht es nicht 😀. Ein Ausschnitt aus dem Assemblerlisting:
1 | 555: SENDE_PIN_oe = OUTPUT; |
2 | +00000C1C: 9ABA SBI 0x17,2 Set bit in I/O register |
3 | 557: GRILLE_PIN = AUS; |
4 | +00000C1D: 98C1 CBI 0x18,1 Clear bit in I/O register |
5 | 558: GRILLE_PIN_oe = OUTPUT; |
6 | +00000C1E: 9AB9 SBI 0x17,1 Set bit in I/O register |
7 | 561: MODE_SW_1_oe = INPUT; |
8 | +00000C1F: 98BB CBI 0x17,3 Clear bit in I/O register |
HildeK schrieb: > Als HEX-Editor habe ich WinHEX zur Verfügung. Der free Editor HxD (hat einige file export optionen) kann tatsächlich auch C array export, was mir nicht bewußt war. HildeK schrieb: > Och, der Compiler verwendet da auch sbi bzw. cbi - schneller und kleiner > geht es nicht So ist es! Welche Compiler version hast du verwendet? Setzt das Optimierung Os voraus, oder macht gcc das bei dir immer? Ich bin echt überrascht ...
WauWau schrieb: > Welche Compiler version hast du verwendet? Alt. WinAVR20100110. (Never change a running system). > Setzt das Optimierung Os > voraus, oder macht gcc das bei dir immer? Ich bin echt überrascht ... Ob Voraussetzung dafür weiß ich nicht, ich nutze immer Os. Gerade ausprobiert: mit O0 und O1 macht er's umständlich. Ab O2 tauchen dann sbi und cbi auf. Es ist also keine Variante von sbit.h notwendig. > Der free Editor HxD (hat einige file export optionen) kann tatsächlich > auch C array export, was mir nicht bewußt war. Ja, sieht wohl so aus - danke für den Tipp. Den kannte ich nicht, der scheint einen ähnlichen Funktionsumfang zu haben.
... ich verstehe nicht die Diskrepanz bzgl. #define GRILLE_SOUND_SAMPLES 1576 #define GRILLE_SAMPLE_RATE 11025 Bedeutet doch wohl, das nur 140ms (1576/11025) der Grillensound lang wäre!? Was ich aber nicht glauben kann!? Mein Program Goldwave erzeugt mir bei z.B. 11025 Sample Rate auch beliebig niedrigere Bitraten kbps ... Was bedeutet das/Wo ist der Sinn? Folgt daraus das entsprechend Samples ausgelassen werden ... und die Dtenmenge sich entsprechend verringert?
WauWau schrieb: > ... ich verstehe nicht die Diskrepanz bzgl. > > #define GRILLE_SOUND_SAMPLES 1576 > #define GRILLE_SAMPLE_RATE 11025 > > Bedeutet doch wohl, das nur 140ms (1576/11025) der Grillensound lang > wäre!? > Was ich aber nicht glauben kann!? > > Mein Program Goldwave erzeugt mir bei z.B. 11025 Sample Rate auch > beliebig niedrigere Bitraten kbps ... Was bedeutet das/Wo ist der Sinn? > > Folgt daraus das entsprechend Samples ausgelassen werden ... und die > Dtenmenge sich entsprechend verringert? Hi! Ja - der Grillensound ist sehr kurz. Das Originalfile habe ich mal in den Anhang gestellt. Du kannst prinzipiell beliebige Sampleraten verwenden, wenn du die #Defines entsprechend anpasst. Letztlich hängt das einfach davon ab wie lange der Sound sein soll und wieviel Speicher vorhanden ist. das Array hatte ich damals mit einem kleinen Programm zusammengebaut. Beitrag "Wave File zu C-Array Konverter (Windows Programm)" HildeK schrieb: > Ich hänge mal meinen an, der das 'sbit.h' von PeDa verwendet. Super! das sieht richtig gut aus. Werde ich bei Gelegenheit mal testen. LG, Jo
WauWau schrieb: > Bedeutet doch wohl, das nur 140ms (1576/11025) der Grillensound lang > wäre!? > Was ich aber nicht glauben kann!? Doch, es sind nur knapp mehr als 140ms. Du hast korrekt gerechnet. > Mein Program Goldwave erzeugt mir bei z.B. 11025 Sample Rate auch > beliebig niedrigere Bitraten kbps ... Was bedeutet das/Wo ist der Sinn? > Folgt daraus das entsprechend Samples ausgelassen werden ... und die > Dtenmenge sich entsprechend verringert? Es sind zwar weniger Samples, aber ein einfaches Auslassen kann man nicht machen, es fehlt davor ein Tiefpassfilter auf die neue Grenzfrequenz. Die DAWs führen diese Filterung digital durch, wenn man z.B von 44.1kHz auf diese 11.025kHz wandelt. CDs haben 44.1kHz Abtastfrequenz, damit kann man (theoretisch) Signale mit Frequenzen bis zu 44.1kHz/2 digital darstellen. Selbstverständlich können Audiosignale auch mit kleineren Abtastfrequenzen digitalisiert werden; so sind 22kHz, 11khz und auch 8kHz (ISDN) verwendet worden. Hauptmerkmal: die höchste Audiofrequenz wird entsprechend niedriger. Hier, bei der Grille also nur bis max 5.5kHz. Das reduziert in gleichem Maß die Datenmenge, aber noch immer verlustfrei für den zulässigen Frequenzbereich. Eine weiter Verringerung ist die Monodarstellung, klar. Und dann noch die Auflösung. Ein CD-Kanal hat 16 Bit, hier wurde reduziert auf 8 Bit - nochmals Faktor 2. Das ist hier auch deshalb nitwendig, weil die verwendete PWM auch nicht mehr kann. Letztlich schränken niedere Abtastfrequenzen den Frequenbereich ein und kleine Auflösungen erhöhen das Rauschen - bei 8 Bit hast theoretisch noch 48dB Dynamik. Bei der CD sind es eben 96 dB.
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.