Hallo liebes Forum, wie ich bereits in einem meiner früheren Beiträge erwähnte plane ich mittels von Python und einem Raspberry Pi über IR Signale zu versenden. Dazu muss ich ein passendes Protokoll schreiben. Bevor ich mich um die Programmierung auf der Empfängerseite kümmere, schreibe ich das Sender-Programm. Kann ich das Modul "time" mit Python benutzen, oder ist das zu ungenau? Was wären bessere Alternativen? Wie lang soll ich einen Bit machen? Ich hätte die Bittlänge auf 0,5sec gesetzt. Würde das Funktionieren? Meine Nachrichten sind maximal 9 Bits lang. Viele Grüße, euer Ernst
Ernst H. schrieb: > Wie lang soll ich einen Bit machen? Das kommt auf deinen Empfänger an. Die bekannten TSOP Empfänger aus der Unterhaltungselektronik arbeiten mit Bitraten von wenigen Kilohertz. Also sehr viel schneller als deine 0,5 Sekunden. Ich denke nicht, dass du das Timing zuverlässig mit Python Code erzeugen kannst. Das ist eher der Job von einem C Modul oder Hardware.
Stefan ⛄ F. schrieb: > Ernst H. schrieb: >> Wie lang soll ich einen Bit machen? > > Das kommt auf deinen Empfänger an. Die bekannten TSOP Empfänger aus der > Unterhaltungselektronik arbeiten mit Bitraten von wenigen Kilohertz. > Also sehr viel schneller als deine 0,5 Sekunden. > > Ich denke nicht, dass du das Timing zuverlässig mit Python Code erzeugen > kannst. Das ist eher der Job von einem C Modul oder Hardware. Hätte auch vermutet, dass du dafür einen HW Baustein brauchen wirst.
"Probieren geht über studieren", also Oszi oder LA an einen GPIO und dann testen, 0.1 sec, 0.2 sec etc, evtl kann man auch das SPI benutzen.
Stefan ⛄ F. schrieb: > Ich denke nicht, dass du das Timing zuverlässig mit Python Code erzeugen > kannst. Das ist eher der Job von einem C Modul oder Hardware. Was ist ein HW-Baustein? Ich habe dazu nicht viel gefunden. Lediglich weiß ich jetzt, dass die ATtiny-Microcontroller scheinbar dazu gehören. Auf C will ich nun nicht mehr umschwenken. Das heißt ich muss die Hardware ändern. Was genau muss ich da machen?
Ernst H. schrieb: > Was ist ein HW-Baustein? Ich habe dazu nicht viel gefunden. Ein spezialisiertes Stück Hardware, dass die Daten seriell von deinem Python Programm empfängt und irgendwie in das Infrarot-Protokoll umsetzt. In der regel also etwas mit Mikrocontroller. Konnte man früher unter dem Namen "Irda" kaufen. Heute musst es wohl selbst konstruieren. > Auf C will ich nun nicht mehr umschwenken. Dann hat sich das Thema für dich erledigt. Es sei denn, du willst Geld für einen Basic Compiler (Bascom) ausgeben und das lernen. Mit Python alleine kommst du jedenfalls nicht weiter.
Stefan ⛄ F. schrieb: > Dann hat sich das Thema für dich erledigt. Es sei denn, du willst Geld > für einen Basic Compiler (Bascom) ausgeben und das lernen. Mit Python > alleine kommst du jedenfalls nicht weiter. Wenn ich C verwende, spare ich mir dann die Umrüst-Arbeiten bei der Hardware?
https://www.digikey.de/en/maker/blogs/2021/how-to-send-and-receive-ir-signals-with-a-raspberry-pi oder in Deutsch und bunt https://codingworld.io/ir2-infrarot-empfaenger-und-sender-am-pi/
:
Bearbeitet durch User
Ernst H. schrieb: > Wenn ich C verwende, spare ich mir dann die Umrüst-Arbeiten bei der > Hardware? Theoretisch kannst du dir ein C Modul programmieren, dass du in dein Python Programm einbindest. Dazu musst du dich aber intensiv mit der Hardware befassen, auf der das ganze Läuft. Oder dein Python Programm auf dem Raspberry Pi sendet die Daten seriell zu einem Hardware Modul, das du selbst auf Basis eines Mikrocontrollers baust und programmierst. Auch dafür brauchst du in der Regel C. Ich würde mich nach fix und fertigen IR Adaptern umschauen, die vom Linux Betriebssystem unterstützt werden (Stichwort LIRC). Lies dazu https://cool-web.de/raspberry/raspberry-pi-mit-infrarot-fernbedienung-fernsteuern.htm
Ich stelle mir gerade diese wundervolle Stille und das gelegentlich gesprochene Wort vor… Es ist die Stille die entsteht, wenn nur diejenigen Leute über etwas reden von dem sie auch Ahnung haben. Und wenn ich mir die bisherigen Beiträge so ansehen… Vor vielen Jahren begab es sich, das jemand die Frage nach der Geschwindigkeit gestellt hat. Die erzielbare Geschwindigkeit wenn man an einem raspi mit dem GPIO arbeitet. Er war aber nicht im Mikrocontroller Forum und hat nur dumm rumgeschwätzt, er hat es geprüft und gemessen: https://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/ So hat er gelernt, GELERNT das mit Python Code selbst auf einem uralten raspi durchaus 70kHz Schaltfrequenz möglich sind. Und da hier in diesem Fall die Trägerfrequenz bei der IR Übertragung per HW erzeugt wird, geht es hier nur um (Daten)Bits und Bytes. Das sollte selbst ein Anfänger Problemarm hinbekommen.
Es ist schlicht kein Timing garantiert und daher ist Bitbanging eine schlechte Idee. Sinnvoll waerte tatsaechlich einen uC zu programmieren, der z.B. per UART die Daten annimmt und dann in die Welt blinkt.
devzero schrieb: > Es ist schlicht kein Timing garantiert und daher ist Bitbanging > eine > schlechte Idee. Sinnvoll waerte tatsaechlich einen uC zu programmieren, > der z.B. per UART die Daten annimmt und dann in die Welt blinkt. Du möchtest dich mit Linux beschäftigen. Insbesondere mit der Möglichkeit auf einem CPU-Kern nur (im Sinne von ausschließlich) dieses Programm mit höherer Priorität laufen zu lassen. Dann möchtest du messen was denn so alles geschieht. Anschließend würdest du gerne deinen Beitrag korrigieren (was als Gast nicht geht).
Norbert schrieb: > devzero schrieb: >> Es ist schlicht kein Timing garantiert und daher ist Bitbanging >> eine >> schlechte Idee. Sinnvoll waerte tatsaechlich einen uC zu programmieren, >> der z.B. per UART die Daten annimmt und dann in die Welt blinkt. > > Du möchtest dich mit Linux beschäftigen. > > Insbesondere mit der Möglichkeit auf einem CPU-Kern nur (im Sinne von > ausschließlich) dieses Programm mit höherer Priorität laufen zu lassen. > > Dann möchtest du messen was denn so alles geschieht. > > Anschließend würdest du gerne deinen Beitrag korrigieren (was als Gast > nicht geht). Hab ich doch schon gesagt, wenngleich mit anderen Worten Beitrag "Re: IR Protokoll mit Python selbst schreiben"
devzero schrieb: > Es ist schlicht kein Timing garantiert und daher ist Bitbanging eine > schlechte Idee. Eben! Genau deswegen werden selbst PC mit 4 Ghz Taktfrequenz und 12 Kernen immer noch durch zahlreiche Mikrocontroller und Spezial IC unterstützt, wenn es darum geht, Signale zu erzeugen.
Stefan ⛄ F. schrieb: > devzero schrieb: >> Es ist schlicht kein Timing garantiert und daher ist Bitbanging eine >> schlechte Idee. > > Eben! Genau deswegen werden selbst PC mit 4 Ghz Taktfrequenz und 12 > Kernen immer noch durch zahlreiche Mikrocontroller und Spezial IC > unterstützt, wenn es darum geht, Signale zu erzeugen. Ja Ja. Und eine 4GHz CPU kann kein 4kHz Signal erzeugen ohne gleich ohnmächtig zu werden. Liegen ja auch nur 6 Größenordnungen dazwischen. In den nächsten Folgen: Warum man einen 38Tonner zum Brötchen holen braucht. Wäsche trocknen leicht gemacht. Wir warten auf einen Tornado.
Norbert schrieb: > In den nächsten Folgen: > Warum man einen 38Tonner zum Brötchen holen braucht. Anders herum: Warum ein 38 Tonner kaum zum Brötchen holen geeignet ist.
Stefan ⛄ F. schrieb: > Anders herum: Warum ein 38 Tonner kaum zum Brötchen holen geeignet ist. … und warum’s aber trotzdem geht, wenn man es drauf anlegt. Genauso, wie man mit Python auf der entsprechenden Hardware (denn irgendwas mit IR-LED und Photodiode auf der einen, und PC-Schnittstelle auf der anderen Seite braucht man ja nunmal – ein Microcontroller mit Micropython böte sich daher an, wenn man nicht gleich einen Pi oder was Anderes mit GPIO und den passenden Libs nimmt) durchaus via Bitbanging die IR-Protokolle bedienen kann. Inspirationen finden sich z.B. auf Github.
:
Bearbeitet durch User
auf den alten RPi war selbst lirc unzuverlässig wenn es mit Kodi genutzt wurde. Ich habe ein RFM69 Funkmodul am RPi und die Software dafür lief zuerst in JavaScript, sogar als ISR. Die Reaktionszeiten waren mit 400..1200 µs zu langsam, in C dann bei <100 µs. Python mag jetzt schneller sein als JS, aber das läuft dann trotzdem noch im Userspace. Da würde ich die lirc Lösung allemale vorziehen. Mit einem alten ESP8266 kann man ein IR-Wifi Gateway bauen, ein paar Zeilen aus Arduino Beispielcode ist da schnell zusammengeklickt. Damit kann vielleicht sogar ein RPi eingespart werden.
devzero schrieb: > Es ist schlicht kein Timing garantiert und daher ist Bitbanging > eine > schlechte Idee. Sinnvoll waerte tatsaechlich einen uC zu programmieren, > der z.B. per UART die Daten annimmt und dann in die Welt blinkt. Oder man kodiert die Daten so das kein hoch genaues genaues Timing erforderlich ist und setzt noch eine Fehlerkorrektur drauf.
Also noch einmal. Gaaaaanz langsam. Wir haben 4 Kerne (in Worten VIER Kerne) die allesamt in der Größenordnung 10^9Hz laufen. Einer dieser Kerne (sagen wir Nummer 4) ist dediziert dem Python Programm zugeordnet und läuft von mir aus auch noch mit erhöhter Priorität. Linux (und Anwendungen) benutzen ausschließlich Kerne 1…3 Ja, Linux kann so etwas. Bitte beantwortet mir schlüssig warum dieser eine Prozess nicht glatt wie Seide laufen soll und welcher Mechanismus eurer Meinung nach das Ding zum stottern bringen würde. Ich bin - das muss ich ernsthaft gestehen - sehr, SEHR gespannt. (Und ja, der alte RasPi 1 hatte nur einen Kern, aber von dem reden wir hier wohl eher nicht.)
Python Programme rufen alle Nase lang Linux Funktionen auf. An der Stelle endet die Zuordnung zu einem exklusiven CPU Kern. Das haben schon andere erfolglos versucht. Google einfach mal danach.
Stefan ⛄ F. schrieb: > Python Programme rufen alle Nase lang Linux Funktionen auf. An der > Stelle endet die Zuordnung zu einem exklusiven CPU Kern. > > Das haben schon andere erfolglos versucht. Google einfach mal danach. OK, da denken wir besser noch mal drüber nach, oder? Wenn man zB. eine Funktion aus der libc aufruft, in welchem Kontext läuft das dann?
Ernst H. schrieb: > Kann ich das Modul "time" mit Python benutzen, oder ist das zu ungenau? Wenn Du statt Raspberry Pi den Raspberry Pico nutzen würdest, wäre die Sachlage eindeutig. So hängt es von vielen Randbedingungen ab, die wir nicht kennen, da Du sie nicht erwähnst. Es ist theoretisch machbar, gerade so eben. Deswegen hängt es hauptsächlich von Deinen Qualitätsansprüchen ab. Und "ungenau" ist nun einmal kein technisches Kriterium. Fakt ist: Typischerweise macht man IR-Übertragung mit einer amplitudenmodulieren Trägerfrequenz. Die sollte typischerweise langzeitstabil sein, damit man bein Empfang eng filtern und Störungen eliminieren kann. Wenn das nicht gebraucht wird, geht es problemlos. Dann baut man im Protokoll einen schön langen Korekturcode ein und wiederholt das Ganze permanent. Empfehlen würde ich sowas niemandem, aber die Frage war, ob es wohl ginge. Wenn es störfest und schnell sein soll, gibt man sowas an einen uC ab, wie ja schon vielfach vorgeschlagen wurde. Aber um mal auszubrobieren, ob es wohl geht? Na klar! Sollte nicht länger als eine Stunde dauern. Thonny wurde extra für sowas erfunden. Gruß Klaus (der soundsovielte) P.S. Wenn ich aber ohne den 38-tonner nicht zu meinen Brötchen käme. würde ich den wegen meiner Freßlust schon nehmen ;-)))
Für den RPi Pico gibt es MicroPython. https://www.raspberrypi.com/documentation/microcontrollers/micropython.html
Norbert schrieb: > Also noch einmal. Gaaaaanz langsam. > > Wir haben 4 Kerne (in Worten VIER Kerne) die allesamt in der > Größenordnung 10^9Hz laufen. > Einer dieser Kerne (sagen wir Nummer 4) ist dediziert dem Python > Programm zugeordnet und läuft von mir aus auch noch mit erhöhter > Priorität. Man kann auch ein RT-Linux drunter knallen, dann geht so einiges ohne einen kompletten Kern zu verbraten, allerdings ändert das nicht am nichtdeterministischen Verhalten von Python. Aber der TO will ja mit einem Hammer eine Schraube rein drehen anstatt das richtige Werkzeug zu nutzen.
In seinen vorigen Threads wurden dem TO schon diverse einfache Hardware Lösungen empfohlen. Aber er mag es ja gerne kompliziert. Beitrag "Fragen zur IR-Informationsübertragung" Beitrag "Raspberry Pi (4B) mit NE555 38kHz modulieren"
Kreativ schrieb: > Man kann auch ein RT-Linux drunter knallen, dann geht so einiges ohne > einen kompletten Kern zu verbraten, Aha. Wir nähern uns langsam. Jetzt geht's also schon… Nebenbei, wenn man einen Kern übrig hat (was in den meisten Fällen zutrifft), dann ergibt sich keinerlei Unterschied für das System. > allerdings ändert das nicht am > nichtdeterministischen Verhalten von Python. Also den gc kann man selbst auslösen wenn man es gerade mag. Außerdem kann man ›thresholds‹ selbst festlegen, was aber in den meisten Fällen noch nicht einmal ansatzweise notwendig ist. Und wenn man irgendwo durch null teilt oder anderen Blödsinn macht, gibt's 'ne Exception. Jetzt wäre noch zu klären was sonst an Python ›nichtdeterministischer‹ als an anderen Sprachen ist. Da wäre ein wenig fundierte Information hilfreich!
Norbert, probiere es doch einfach mal aus, dann weißt du warum wir abraten. Wie gesagt, andere haben das Experiment bereits hinter sich. Ja es geht, aber eher Schlecht als Recht und mit großem Aufwand.
Stefan ⛄ F. schrieb: > Norbert, probiere es doch einfach mal aus, dann weißt du warum wir > abraten. Wie gesagt, andere haben das Experiment bereits hinter sich. > > Ja es geht, aber eher Schlecht als Recht und mit großem Aufwand. Stefan, ich habe das schon des Öfteren gemacht. Und ich kann sagen das, auf einem Linux System, auf die von mir oben geschilderte Art keine Probleme auffällig wurden. Aber - ich nehme deinen Vorschlag gerne auf - bei nächster Gelegenheit wenn etwas Zeit ist werde ich mal die schlechtest mögliche Testversion mit einem Raspi 1B aufbauen. Ein Kern, 700MHz. Dann ein paar hunderttausend Pulse mit 1/2/5/10/20ms erzeugen und mit einem Pi pico (auf 10ns genau) messen.
Norbert schrieb: > ich habe das schon des Öfteren gemacht. Und ich kann sagen das, > auf einem Linux System, auf die von mir oben geschilderte Art keine > Probleme auffällig wurden. Dann sei doch so nett und helfe dem Ernst dabei, es ebenso zu machen. Erkläre ihm, wie du das gemacht hast.
Für die Standard-Protokolle gibt es doch schon "halb"-fertige Lösungen. Ich würde versuchen so eine zu nehmen und auf dein Protokoll anpassen, falls es eh nicht schon drin ist.
Nachtrag: hier ist ne feine Anleitung leider in Eng. https://www.digikey.de/en/maker/blogs/2021/how-to-send-and-receive-ir-signals-with-a-raspberry-pi
Schlaumaier schrieb: > Für die Standard-Protokolle gibt es doch schon "halb"-fertige Lösungen. Hatten wir schon Stefan ⛄ F. schrieb: > Ich würde mich nach fix und fertigen IR Adaptern umschauen, die vom > Linux Betriebssystem unterstützt werden (Stichwort LIRC). Lies dazu > https://cool-web.de/raspberry/raspberry-pi-mit-infrarot-fernbedienung-fernsteuern.htm Aber der TO (Ernst) ist wie in seinen beiden vorherigen Threads offenbar nicht an Lösungen interessiert. Sonst würde er die vorgeschlagenen Lösungen wenigstens mal ausprobieren.
Stefan ⛄ F. schrieb: > Aber der TO (Ernst) ist wie in seinen beiden vorherigen Threads offenbar > nicht an Lösungen interessiert. Sonst würde er die vorgeschlagenen > Lösungen wenigstens mal ausprobieren. Er stellt gern Fragen und freut sich über unsere Antworten :-) Und weil wir am Helfersyndrom leiden, geben wir gerne Antworten :-))) Daran finde ich nichts Schlechtes, diesmal ganz "ernst". Und da hier ein offenenes Forum ist und er sich an die Regeln hält, verhält er sich korrekt. Daß wir es uns anders wünschten (inclusive mir!), ist unser Problem, nicht seines. Gruß Klaus /der soundsovielte)
Ernst H. schrieb: > Hallo liebes Forum, > > wie ich bereits in einem meiner früheren Beiträge erwähnte plane ich > mittels von Python und einem Raspberry Pi über IR Signale zu versenden. > Dazu muss ich ein passendes Protokoll schreiben. Das beginnt dann damit, erstmal die Eckwerte festzulegen, was es leisten können soll. Sprich: Welcher Durchsatz über welche Entfernung soll erreicht werden und welche Datensicherheit ist erforderlich. Bevor man diese drei Kennwerte nicht festgelegt hat, kann man kein Protokoll entwerfen und dementsprechend braucht man sich auch noch keinen Kopf darüber zu machen, wie man das Protokoll dann mit den gegebenen Möglichkeiten umsetzen könnte.
Der dritte Thread zu der Frage, Unmengen an Vorschlägen bekommen und immer noch nichts probiert. Und dann ein eigenes Protokoll schreiben und Probleme mit GC und Jitter umschiffen?
c-hater schrieb: > Bevor man diese drei Kennwerte nicht festgelegt hat, kann man kein > Protokoll entwerfen Ich kann ein Protokoll entwerfen, ohne überhaupt einen einzigen Kennwert zu haben. Wo ist das Problem? Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Ich kann ein Protokoll entwerfen, ohne überhaupt einen einzigen Kennwert > zu haben. Wo ist das Problem? Dann mach mal, zeige dem Ernst für seine Anwendung, wie es geht. Ansonsten ist dein Beitrag nur ein weiterer völlig nutzloser.
Stefan ⛄ F. schrieb: > Norbert schrieb: >> ich habe das schon des Öfteren gemacht. Und ich kann sagen das, >> auf einem Linux System, auf die von mir oben geschilderte Art keine >> Probleme auffällig wurden. > > Dann sei doch so nett und helfe dem Ernst dabei, es ebenso zu machen. > Erkläre ihm, wie du das gemacht hast. Ja aber gerne Stefan, sehr gerne. Und es ist ein einfaches Python Programm das auch noch jeder auf seinem Rechner nachvollziehen kann. Da ich aber gerade keinen Raspi hier habe, für einen normalen Linux PC. Die komplette Klasse, nur die zwei GPIO Befehle laufen auf einem normalen PC hier nicht. Trotzdem, gerade das Timing sollte dennoch sehr schön ersichtlich sein. Aufruf mit:
1 | nice -n -10 ./programm.py | tee results.log |
Ausreißer sind in der Ausgabe mit einem ›X‹ vermerkt. So kann man's prima ›greppen‹ Hab hier mal einen Zehntausender-Lauf auf dem ArbeitsPC gestartet. 10000 64bit 1ms Nicht überraschend läuft das Ding fast 11 Minuten. Hier sind die "Ausreißer" geloggt:
1 | grep X results.log |
1 | /tmp/norbert$ grep X results.log |
2 | Delta (64 × 1ms pulses): min: 0.1µs avg: 6.1µs max: 375.6µs X |
3 | Delta (64 × 1ms pulses): min: 0.1µs avg: 1.1µs max: 54.9µs X |
4 | Delta (64 × 1ms pulses): min: 0.2µs avg: 0.7µs max: 11.7µs X |
5 | Delta (64 × 1ms pulses): min: 0.1µs avg: 0.4µs max: 10.2µs X |
6 | Delta (64 × 1ms pulses): min: 0.1µs avg: 0.6µs max: 23.4µs X |
7 | Delta (64 × 1ms pulses): min: 0.1µs avg: 0.4µs max: 11.0µs X |
8 | Delta (64 × 1ms pulses): min: 0.1µs avg: 0.6µs max: 11.4µs X |
9 | Delta (64 × 1ms pulses): min: 0.1µs avg: 0.3µs max: 11.3µs X |
Bei 10000 Stück 64bit pulsetrains habe ich ohne Kapriolen zu veranstalten: 1 echten Ausreißer 1 der 5% länger als gefordert ist 1 der 2% länger als gefordert ist 5 die 1-2% länger sind Die ~9990 anderen sind unter 10µs Abweichung. Danke für's zuhören.
Stefan ⛄ F. schrieb: > Dann mach mal, zeige dem Ernst für seine Anwendung, wie es geht. > Ansonsten ist dein Beitrag nur ein weiterer völlig nutzloser. Ja, da gebe ich Dir völlig recht. Der ganze Thread ist vermutlich nutzlos. Ich hab Ernst bereits gesagt, was ich ich für sein Programm empfehlen würde (übrigens dasselbe wie Du). Mich animieren nur völlig überzogene Behauptungen, die einfach grottenfalsch sind. Da es hier ein offenes Forum ist, versuche ich nur möglichst freundlich auf so etwas hinzuweisen. Aber Du scheinst wirklich recht zu haben, in diesem Forum ist das nutzlos, hier regiert die starke Meinung, die mit der Wirklichkeit nicht unbedingt übereinstimmen muß. :-) (Achtung:Sarkasmus!) Ich werde es auch weiter aushalten, daß das so ist und werde nur ab und zu mal dazwischengrätschen. Versprochen! Peace! Gruß Klaus (der soundsovielte)
Ernst H. schrieb: > Wie lang soll ich einen Bit machen? Ich hätte die Bittlänge auf 0,5sec > gesetzt. > Würde das Funktionieren? > Meine Nachrichten sind maximal 9 Bits lang. Ja, das würde funktionieren. Wenn dir eine Datenrate von 2bit/sec reicht, würde ich das genau so implementieren.
Seit 30 Jahren gibts dafür standardisierte Verfahren. Nennt sich IRDA und funktionierte damals problemlos. Siehe: https://de.wikipedia.org/wiki/Infrared_Data_Association Für den Pi gibts auch schon fertige Lösungen. Da muss der Laie nichts mehr zusammenpfuschen: https://irdroid.eu/product/irda-pihat/ Wer mag, darf sich das ganze selber abpinnen: https://github.com/Irdroid/irDA-piHAT Man beachte: "No drivers required." fchk
Frank K. schrieb: > Seit 30 Jahren gibts dafür standardisierte Verfahren. Nennt sich IRDA > und funktionierte damals problemlos. Auch darauf wies ich bereits in einer der ersten Antworten hin. Beitrag "Re: IR Protokoll mit Python selbst schreiben" Ich sehe nur keinerlei Reaktion vom TO, auf die man aufbauen könnte. Vielleicht sammelt er seit 6 Monaten Vorschläge, die er demnächst als Buch verkauft "101 Möglichkeiten der IR Kommunikation". Reich wir er damit sicher nicht.
Frank K. schrieb: > Seit 30 Jahren gibts dafür standardisierte Verfahren. Nennt sich IRDA > und funktionierte damals problemlos. > > Siehe: > https://de.wikipedia.org/wiki/Infrared_Data_Association > > Für den Pi gibts auch schon fertige Lösungen. Da muss der Laie nichts > mehr zusammenpfuschen: IRDA wurde in den vorigen Threads auch schon mehrfach erwähnt, aber der TO möchte mindestens 2m überwinden. Ich kenne IRDA noch von früher (HP200LX), das funktionierte recht gut über ein paar Zentimeter direkte Sichtverbindung hinweg, aber 2m sehe ich schon als problematisch an. Der TO möchte Daten von einem Raspberry Pi zu 1..n Raspberry Picos senden. Beide haben als standardisierte Schnittstelle ein Serial Comm Port. Warum der TO nicht einfach auf beiden Seiten eins der vielen angebotenen Funkmodule mit transparenter serielle Übertragung nimmt, sondern sich so auf die IR Übertragung fokusiert hat, das verstehe ich nicht. Natürlich kann es dafür einen guten Grund geben, aber ich habe in keinem der Threads einen Hinweis darauf gefunden.
Frank K. schrieb: > Seit 30 Jahren gibts dafür standardisierte Verfahren. Nennt sich IRDA > und funktionierte damals problemlos. > > Siehe: > https://de.wikipedia.org/wiki/Infrared_Data_Association > > Für den Pi gibts auch schon fertige Lösungen. Da muss der Laie nichts > mehr zusammenpfuschen: > > https://irdroid.eu/product/irda-pihat/ Dieser Link sieht sehr vielversprechend aus Stefan ⛄ F. schrieb: > Ich sehe nur keinerlei Reaktion vom TO, auf die man aufbauen könnte. > > Vielleicht sammelt er seit 6 Monaten Vorschläge, die er demnächst als > Buch verkauft "101 Möglichkeiten der IR Kommunikation". Reich wir er > damit sicher nicht. Vielen Dank für die Antworten. Ich werde jetzt mal einige der vorgeschlagenen Möglichkeiten ausprobieren. Ihr hört von mir ;-) Beste Grüße, euer Ernst
Robert schrieb: > Der TO möchte Was er möchte hat sich im Laufe der Zeit wohl mehrfach geändert. Ich habe das Gefühl, dass er selbst nicht mehr so richtig weiß, was er möchte, denn auf entsprechende Rückfragen und Vermutungen ist er nicht eingegangen. Ernst H. schrieb: >> 101 Möglichkeiten der IR Kommunikation > Ich werde jetzt mal einige der vorgeschlagenen Möglichkeiten > ausprobieren. Gefällt dir der Buchtitel oder wie wirst du es nennen? :-)
Robert schrieb: > Der TO möchte Daten von einem Raspberry Pi zu 1..n Raspberry Picos > senden. Beide haben als standardisierte Schnittstelle ein Serial Comm > Port. Das ist schonmal eine gute Beobachtung. > Warum der TO nicht einfach auf beiden Seiten eins der vielen > angebotenen Funkmodule Da ist eben die unbeantwortete Frage, was genau erreicht werden soll, also die Frage nach den Kennwerten. Fakt ist: um z.B. eine Fernbedienungsfunktion (über Wohnzimmer-Entfernungen mit einer überschaubaren Zahl von "Tasten") zu erreichen, braucht man ganz sicher keine Funkmodule. Auch kein IRDA. Das geht ALLEIN über die UARTs, natürlich mit ein bissel zusätzlicher Elektronik, aber in einem sehr bescheidenem Umfang. Auf Senderseite ist das halt eine LED und ein Widerstand, auf Empfängerseite ein Fototransistor, drei Widerstände und ein Kondensator. Ich habe jahrzehntelang meinen MP3-Player so gesteuert. Sender war ein bissel CMOS-Standardkram, Empfänger die UART eines gewöhnlichen PC-Boards. Sowas geht, wenn man sich halt ein geeignetes Protokoll überlegt.
Ernst H. schrieb: > Vielen Dank für die Antworten. > Ich werde jetzt mal einige der vorgeschlagenen Möglichkeiten > ausprobieren. > Ihr hört von mir ;-) > Beste Grüße, > euer Ernst Auch Dir alles Gute, Ernst! Bis dann also im Thread #4: "Mit Python von einem Raspberry Pi IR-Signale senden - ganz ohne IR-Diode"
Jester schrieb: > Bis dann also im Thread #4: "Mit Python von einem Raspberry Pi > IR-Signale senden - ganz ohne IR-Diode" Geht. Über Vollast und Grundlast die Wärmeemission modulieren.
c-hater schrieb: > Robert schrieb: > >> Der TO möchte Daten von einem Raspberry Pi zu 1..n Raspberry Picos >> senden. Beide haben als standardisierte Schnittstelle ein Serial Comm >> Port. > > Das ist schonmal eine gute Beobachtung. > >> Warum der TO nicht einfach auf beiden Seiten eins der vielen >> angebotenen Funkmodule > > Da ist eben die unbeantwortete Frage, was genau erreicht werden soll, > also die Frage nach den Kennwerten. Ja, wenn Ernst den Kontext besser erklären würde, könnte man ihm auch besser helfen. Manchmal habe ich den Eindruck er weiß selbst nicht so genau wo die Reise hingehen soll. > Fakt ist: um z.B. eine Fernbedienungsfunktion (über > Wohnzimmer-Entfernungen mit einer überschaubaren Zahl von "Tasten") zu > erreichen, braucht man ganz sicher keine Funkmodule. Auch kein IRDA. > > Das geht ALLEIN über die UARTs, natürlich mit ein bissel zusätzlicher > Elektronik, aber in einem sehr bescheidenem Umfang. Auf Senderseite ist > das halt eine LED und ein Widerstand, auf Empfängerseite ein > Fototransistor, drei Widerstände und ein Kondensator. Diverse Lösungen wurden ja schon in den vorigen Threads genannt. Allerdings glaube ich in der Zwischenzeit, daß ihn sowohl die Anzahl als auch die technischen Details der Vorschläge überfordert haben. Deshalb empfehle ich ihm ein fertiges Modul zu nehmen. Ein Funkmodul, welches ich kenne, ist z.B. das JDY-41. Das kann transparente serielle Kommunikation, als auch 1 zu N Kommunikation, und zusätzlich können 8 LEDs angeschlossen und per Kommando an-/abgeschaltet werden. Eventuell könnte der Raspberry Pico auf der Empfangsseite sogar entfallen. Aber dazu müsste Ernst schon etwas mehr Details bekannt geben.
Angehängte Dateien:
c-hater schrieb: > Fakt ist: um z.B. eine Fernbedienungsfunktion (über > Wohnzimmer-Entfernungen mit einer überschaubaren Zahl von "Tasten") zu > erreichen, braucht man ganz sicher keine Funkmodule. Auch kein IRDA. > > Das geht ALLEIN über die UARTs, natürlich mit ein bissel zusätzlicher > Elektronik, aber in einem sehr bescheidenem Umfang. Auf Senderseite ist > das halt eine LED und ein Widerstand, auf Empfängerseite ein > Fototransistor, drei Widerstände und ein Kondensator. Auf Senderseite habe ich 2 Transistoren, IR-LED und Widerstand, wie im Bild zu sehen ist. Ein Bit wird also dann gesendet, wenn der GPIO-Pin als Ausgang schaltet. Python scheint ungeeignet dafür zu sein (siehe 38-Tonner zum Brötchenholen). Deshalb dachte ich, ich könnte C zum Programmieren der Empfängerseite nehmen, wenn ich die Beiträge hier richtig verstanden habe. Auf der Empfängerseite habe ich einen TSOP4838 angeschlossen, sodass der OUT-Pin des TSOPs direkt an einen GPIO-Pin des Picos angeschlossen ist. Die Nachrichten, die über IR gesendet werden sollen, würde ich nach folgendem Schema aufbauen: --------------- | Startbit | ID des Picos | Befehl | Stoppbit | Anzahl der Bits | 1 4 3 1 | Gesamt: 9 Robert schrieb: > Deshalb empfehle ich ihm ein fertiges Modul zu nehmen. Ein Funkmodul, > welches ich kenne, ist z.B. das JDY-41. Das kann transparente serielle > Kommunikation, als auch 1 zu N Kommunikation, und zusätzlich können 8 > LEDs angeschlossen und per Kommando an-/abgeschaltet werden. Bisher hielt ich Funkmodule für zu platzintensiv, wenn der Pico wegfallen könnte wäre das natürlich toll. Doch ich brauche die beim Pico vorhandene Zahl an GPIO-Pins. Robert schrieb: > Diverse Lösungen wurden ja schon in den vorigen Threads genannt. > Allerdings glaube ich in der Zwischenzeit, daß ihn sowohl die Anzahl als > auch die technischen Details der Vorschläge überfordert haben. Nett, dass du dich sorgst. Noch allerdings verstehe ich das Meiste.
Ernst H. schrieb: > Auf Senderseite habe ich 2 Transistoren, IR-LED und Widerstand, wie im > Bild zu sehen ist. Vor allem sehe ich da: "PWM". Du brauchst keine PWM für meinen Vorschlag. Da wird nix moduliert, das passiert rein im Basisband. Sprich: Der UART-Ausgang ist direkt das Sendesignal. Ggf. bloß noch über einen entsprechenden Treiber mit ein bissel mehr LED-Power versehen, wenn der UART-Ausgang selber nicht genug Strom liefern kann. Und klar: da dann die UART das gesamte nötige Timing macht, kann natürlich auch ein Python-Programm der Sender sein. Es schickt halt einfach einen Datenblock an das UART-Device. Das kümmert sich um den Rest. Nämlich diesen Datenblock "lückenlos" auszugeben.
c-hater schrieb: > Vor allem sehe ich da: "PWM". Du brauchst keine PWM für meinen > Vorschlag. Anders wird der TSOP das Signal doch nicht erkennen, oder?
Ernst H. schrieb: > Bisher hielt ich Funkmodule für zu platzintensiv, wenn der Pico > wegfallen könnte wäre das natürlich toll. Doch ich brauche die beim > Pico vorhandene Zahl an GPIO-Pins. JDY-41: 22x15x2mm > Nett, dass du dich sorgst. Noch allerdings verstehe ich das Meiste. Aha, und deshalb hast du den Basiswiderstand beim unteren Transistor in deiner Zeichnung weggelassen.
Robert schrieb: > Aha, und deshalb hast du den Basiswiderstand beim unteren Transistor in > deiner Zeichnung weggelassen. Eine kleine Aufmerksamkeitsübung ;-) In der Schaltung an sich habe ich diesen natürlich verwendet.
Ernst H. schrieb: > Robert schrieb: >> Aha, und deshalb hast du den Basiswiderstand beim unteren Transistor in >> deiner Zeichnung weggelassen. > > Eine kleine Aufmerksamkeitsübung ;-) > In der Schaltung an sich habe ich diesen natürlich verwendet. Und wo war jetzt gleich noch mal das Problem? So, wie sich das ließt, tut nun ja alles - oder?
Ernst H. schrieb: > c-hater schrieb: >> Vor allem sehe ich da: "PWM". Du brauchst keine PWM für meinen >> Vorschlag. > > Anders wird der TSOP das Signal doch nicht erkennen, oder? Nix TSOP. Auch der Empfang passiert rein im Basisband. Fototransister mit kleiner Anpassschaltung -> UART-RX. Der Rest besteht in einem entsprechenden Design des Protokolls und entsprechender Software. Aber, wie eingangs gesagt: nur für Entfernungen im Wohnzimmerbereich und eine sehr überschaubare Zahl zu unterscheidender Codes geeignet. So was um die 8, vielleicht auch noch 16. Sonst wird's wahlweise zu langsam oder zu störungsanfällig. Im Original hatte ich 7 Nutz-Codes (Cursor-Kreuz + OK + zwei Tasten für "Spezialfunktionen") und einen Repeat-Code. Über die "Leitung" gehen dazu zwei Bytes pro Code (8N1 mit 300Baud). Den Originalcode des Empfängers (war für ein P90-Board unter DOS) habe ich leider nicht mehr. Aber ich habe noch den Code für die V2. Der war dann für einen P200 unter Win98. Das Protokoll und die Codes waren aber unverändert zur Urversion, denn tatsächlich war auch die gesamte Hardware unverändert, mit Ausnahme der schnelleren CPU und einer Speicher-Aufrüstung. Von dem Sender weiß ich nichtmal mehr, wie der genau aufgebaut war. Es war jedenfalls noch kein µC, sondern irgendwas mit (sehr wenigen) 4000er-CMOS-Steinen. Wenn ich mich richtig erinnere, waren das zwei. Ein 4x-Gatter (4001, 4011 oder 4030) und ein Zähler (möchte wetten: 4017). Die restliche Logik war wired-OR oder irgendwas in der Art. Heute würde ich natürlich einen ATtiny13 für sowas benutzen, aber damals(tm) hatte ich mit µC noch nicht so sehr viel am Hut... Ich müsste mich erstmal wieder sehr tief da reindenken, um aus den verwendeten Codes die Schaltung des Senders zu rekonstruieren. Ganz sicher waren die Codes jedenfalls so gewählt, dass sie sowohl bezüglich der Übertragungsstrecke möglichst "gut" als auch möglichst einfach per "Klingel-Elektronik" zu generieren waren. Ist aber im Kontext diese Threads eh' irrelevant, der TO möchte das ja von einem Pi versenden. Also: befülle zwei Bytes RAM und lasse das UART-Device diesen Puffer versenden. Fertisch.
c-hater schrieb: > Aber, wie eingangs gesagt: nur für Entfernungen im Wohnzimmerbereich und > eine sehr überschaubare Zahl zu unterscheidender Codes geeignet. So was > um die 8, vielleicht auch noch 16. Sonst wird's wahlweise zu langsam > oder zu störungsanfällig. Solange das Meter sind, reicht diese Entfernung definitiv für mich. Ich plane mit maximalen Distanzen von 2m.
Ernst H. schrieb: > Solange das Meter sind, reicht diese Entfernung definitiv für mich. Mein Wohnzimmer hatte damals ca. 25m². Von der Couch bis zum MP3-Player waren es ca. 3,5m. Egal, wie rum ich auf der Couch lag... ;o)
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.