Mit einem einfachen Terminalprogramm war ich nicht erfolgreich. Ein kleines Pythonskript hat aber funktioniert. Es fragt die ID des RadEye ab. Am besten vorher den RadEye neu starten. Dann ist er sicher im Textmodus. Man darf vorher nicht die Originalsoftware verwenden. Die schaltet den RadEye irgendwie in einen anderen Modus. Bei mir hat dann nur ein Neustart geholfen.

Zuerst sendet man "@" ohne CR&LF. Die erwartete Antwort ist ">" (auch ohne CR&LF).
Danach "V" mit CR&LF senden. Die erwartete Antwort ist "#" gefolgt von der RadEye ID und CR&LF.

"""Ask the RadEye SPRD for its identity (command V). Read only, pyserial only.
    Usage: ask_identity.py COM3
    It is only working when RadEye is in text mode.
"""
import sys

import serial

s = serial.Serial(None, 9600, serial.SEVENBITS, serial.PARITY_EVEN, serial.STOPBITS_TWO, timeout=2)
s.port = sys.argv[1]
s.open()
s.reset_input_buffer()

command = b"@"                # wake-up: ">" = text mode
print(f"sending {command}")
s.write(command)
response = s.read(1)
print(f"Response: {response}")

command = b"V\r\n"                # ID
print(f"sending {command}")
s.write(command)
response = s.read_until(b"\r\n")
print(f"Response: {response}")

s.close()


Zitat von: DG0MG am 29. Oktober 2026, 15:12@Na-22 Falls jemand diese Infrarot-Datenschnittstelle nach persönlichem Gusto  "nachempfinden"  und dann auch testen möchte, braucht es als erstes eine ganz einfache Möglichkeit eines Tests, ob damit die Kommunikation mit einem Gerät klappen könnte.

Also z.B. mit einem Terminalprogramm (PuTTY oder HTerm) die seriellen Parameter (Baudrate, Bitanzahl, Parität, Stopbits) einstellen und dann "X" senden. Dann könnte das Gerät mit "Y" antworten. So in der Form, falls es X und Y gibt. Das kommt natürlich auch darauf an, ob die Kommunikation in reinem ASCII oder binär erfolgt. Im zweiteren Fall ist das leider nicht ganz so einfach, könnte mit HTerm aber auch gehen. Lang nicht mehr gemacht.

Dank der weiteren Unterlagen sind jetzt alle Bauelemente bekannt. Dem Datenblatt der IR-LED kann ich entnehmen, dass die Wellenlänge 950 nm beträgt. Somit wäre auch das geklärt.

Wer weis das schon

Man könnte denken, das stammt aus den Originalunterlagen der IR-Schnittstelle.

Zitat von: Ravenlord am 29. Oktober 2026, 14:48nicht schlecht

@Na-22 Falls jemand diese Infrarot-Datenschnittstelle nach persönlichem Gusto  "nachempfinden"  und dann auch testen möchte, braucht es als erstes eine ganz einfache Möglichkeit eines Tests, ob damit die Kommunikation mit einem Gerät klappen könnte.

Also z.B. mit einem Terminalprogramm (PuTTY oder HTerm) die seriellen Parameter (Baudrate, Bitanzahl, Parität, Stopbits) einstellen und dann "X" senden. Dann könnte das Gerät mit "Y" antworten. So in der Form, falls es X und Y gibt. Das kommt natürlich auch darauf an, ob die Kommunikation in reinem ASCII oder binär erfolgt. Im zweiteren Fall ist das leider nicht ganz so einfach, könnte mit HTerm aber auch gehen. Lang nicht mehr gemacht.

Zitat von: Z. Erfall am 28. Oktober 2026, 18:58Kommt mir sehr bekannt vor mit dem 103G und einem Pixel 7, allerdings nicht nur im Auto, sondern auch auf dem Rad. Abrisse oder wilde GPS-Fehler, die zu heftigen Positionsabweichungen einzelner oder mehrere aufeinanderfolgender Messpunkte führen

Zu solchen Effekten hatte ich vor einiger Zeit auch schon einmal hier gepostet – inklusive Screenshots, ebenfalls auf einem Pixel7 (unter GrapheneOS).

Was den Parallelbetrieb mehrerer Apps mit Zugriff auf das GPS angeht – RC-App + Tracker oder OsmAnd~ –, hatte ich allerdings bisher noch keine Probleme.

nicht schlecht

Im Stadtarchiv von Waldkirch (Ba-Wü, bei Freiburg) befindet sich so ein Gerät und es wird berichtet, "es erzähle Geschichte":

• https://www.regiotrends.de/de/aus-vereinen-gruppen/index.news.570970.ein-geraet-gegen-die-unsichtbare-gefahr-in-waldkirch---der-geigerzaehler-im-stadtarchiv.html
• Archivlink: https://archive.is/vJLdZ

Leider ist die Geschichte recht dünne, mehr so nach dem Motto "Nichts Genaues weiß man nicht.".

Ja, dafür wird es ein.

Solange nichts zum RadEye gesendet wird ist TXD high und Q1 und damit auch D1 off. Pin 9 von U2 wird bei TXD=high langsam aufgeladen und gibt somit die Empfängerdioden frei.
Sobald TXD auf low geht wird Pin 9 von U2 über D2 sehr schnell auf low gezogen und blockiert damit die Signale der Empfängerdioden.
Ohne U2C, C4, D2 und R6 bekäme man wahrscheinlich ein Echo des TX Signals auf RX zurück. Die Sende- und Empfangsdioden sind nebeneinander im Gehäuse angeordnet. Die Anordnung Empfänger-Sender-Empfänger erlaubt es, den Adapter in beiden Richtungen an der Auslesestation zu montieren.

Uh, das ist interessant, danke!

Welchen Sinn haben denn C4, D2 und R6, an denen das TxD-Signal eingreift?


Blockiert das den Empfänger, solange Daten gesendet werden?