Hallo zusammen,
kennt jemand den oben genannten Splitter. Bzw. hat jemand eine Ahnung wie das Ding innen drinnen ausieht. Schaltplan usw.
Würde mir gerne so was bauen. Gerne auch andere Vorschläge wie das zu realisieren wäre. Ist ein Splitter für die CAT Schnittstelle.
Denke da könnte man einfach auch eine RS232 Splitter verwenden oder ? Ist ja +/- das selbe oder ?
Danke Euch.
Hallo Martin,
wofür soll der Splitter verwendet werden. Möglicherweise kann dies mit virtuellen Schnittstellen (VSPE)realisiert werden.
73 Wolfgang
Moin moin,
ich weiss zwar nicht, was ein FT817 Buddy ist und kenne den FT817 nicht näher, aber diesem Schaltbild entnehme ich, dass der normale TTL-Ein- und -Ausgänge hat:
Einen Splitter würde ich mit zwei Dioden und 3 "Angst-Widerständen" bauen:
Grösstes Problem würde das herumbraten an einem filigranen 8-polige Mini-DIN-Stecker sein....
73,
Ralf
Grösstes Problem würde das herumbraten an einem filigranen 8-polige Mini-DIN-Stecker sein....
...eine fertigkonfektionierte (vorhandene?) Kabelpeitsche könnte ein guter Freund sein....
Hallo Ralf
Danke. Das könnte klappen. Das mit den frickeligen DIN8 Stecker ist kein Problem.
Der FT817 Buddy ist eine CAT gesteuerte Platine, mit RTC, Programmierbarer Keyer Bausteuin, 6 Programmierbaren Tasten sowie einem LCD mit Hintergrundbeleuchtung. Da hat man alles im Blick, wenn die FT auf dem Tisch steht.
Mehr Infos unter: alloutput.com/ft-817-buddy/
Kann das Teil auch iambic B?
Da hab ich nichts gefunden auf der Seite. Ansonsten macht das Teil schon mal einen Interessanten Eindruck.
Verbauter K16-Keyer von K1EL
Keying Modes: Bug, Ultimatic, Iambic A or B
Liest sich also ob, wie bei unserem "Solf" ein Chip von K1EL verwendet wird.
Fredo
Danke.
Hallo Martin,
vielleicht gibt es da ein Problem mit dem CAT-Protokoll. Der TRx sendet ja jeweils parallel an beide Peripherie-Geräte, und vielleicht fühlen die sich durch Antworten angesprochen, die für das jeweils andere Peripherie-Gerät bestimmt sind.
Mir ist aber aus dem FT-817-Manual nicht so ganz klar geworden, was der FT-817 überhaupt an das/die Peripherie-Geräte sendet. Ich vermute aber, dass die Kommunikation eher einseitig ist, also Peripherie-Geräte senden Befehle an den TRx und erwarten keine direkten Antworten.
Dann müsste das ohne Kollisionen klappen. "Versuch macht kluch", sagt man hier im hohen Norden 
73,
Ralf
Update: Uhhhh, uhhhh, da war ich wohl etwas voreilig optimistisch. Es gibt 3 Befehle ("Read Rx status", "Read Tx status", "Read Frequency and Mode status", auf die der TRx direkt antwortet, ohne dass aus der Antwort erkennbar ist, welcher Befehl ihr voraus ging.
Könnte also sein, dass der Buddy bzw. Dein Digtalmode-Programm dadurch ins Torkeln kommen, weil sie nicht selbst danach gefragt haben.
Aber wie gesagt, "Versuch macht kluch". Ich vermute aber, dass das CAT-Mate auch nicht sehr "schlau" ist und nur einen RS232-TTL-Wandler und eine ähnliche Logik-Hardware enthält wie in meinem Schaltungs-Vorschlag.
Ich vermute aber, dass das CAT-Mate auch nicht sehr "schlau" ist und nur einen RS232-TTL-Wandler und eine ähnliche Logik-Hardware enthält wie in meinem Schaltungs-Vorschlag.
Das kann so niemals funktionieren.
Wenn zwei Geräte unkoordiniert Befehle schicken führt das unweigerlich zu Kollisionen. Ein rein passiver Splitter kann nur funktionieren wenn man dafür sorgt, dass niemals beide Geräte gleichzeitig Kommandos senden und wenn beide Geräte mit nicht angeforderten Antworten umgehen können.
Es ist zu vermuten, dass der CAT-Mate einen Mikrocontroller enthält der die zwei Eingänge dekodiert und dafür sorgt, dass ein Befehl zwischengespeichert wird wenn gerade das andere Gerät sendet. Auch die Beschreibung des CAT-Mate deutet darauf hin, hier ein Auszug aus dem User Guide:
"The CAT-MATE is able to receive commands from either of its two CAT input ports and connect
to a single radio, be it an FT-817, FT-857 and FT-897. The appropriate reply from the radio will
then be directed to the port from which the command was issued."
73
Uli DF7SC
ZitatDas kann so niemals funktionieren.
Hihi, gut dass wir hier wirkliche Fachleute haben.
Ich Dussel war davon ausgegangen, dass die beiden Geräte am CAT-Anschluss nur relativ selten senden und Antworten wegschmeissen, die sie nicht selber angefragt haben. Kann so sein, muss es aber nicht. Daher das "Versuch macht kluch"
73,
Ralf
Moin, so etwas ist simpel zu bauen. Sind ja immer nur wenige Bytes. Man braucht nur einen µC, Pegelanapssung und ggf. galvanische Trennung. Der µC liest die beiden Geräte (PC und weiteres Zubehör), speichert die zwischen und leitet die Daten an den TRX. Die Antwort des TRX wird dann entsprechend zurückgesendet.
Ein ATMEGA 2560 hat vier USART. Andere zwei, aber per Software geht UART auch ganz gut, wenn die Rate nicht zu hoch ist.
Gibt es bestimmt auch in der Arduino-Community.
Allerdings würde sich für mich der Selbstbau nicht lohnen. µC und das ganze Hühnerfutter kosten ja auch schon einiges.
73
Holger DL9HDA
Hi. Ich habe gerade mal den FT-818ND gecheckt. Der sendet nichts, ausser man fragt an.
Also kommen vom FT nur Daten wenn vorher eine Anfrage gesendet wurde.
@ Jens:
So hatte ich das aus dem FT-817-Protokoll auch raus gelesen.
@ Holger:
Falls Kollisionen ein Problem sind, würde ich mich gar nicht auf die "Behandlung" der Signale mit 3 seriellen Schnittstellen einlassen, sondern versuchen, mit einem kleinen ATTiny24 und simplen I/O-Pins die Signale 1:1 durchzureichen, also so, dass der jeweilige Ausgang einfach die Pegel am jeweiligen Eingang spiegelt .
Sobald ein CAT-Gerät zu senden beginnt, wird das Andere gesperrt und erst nach Ablauf eines Timers freigegeben. Die Antwort des TRx könnte man auch so behandeln, also für eine kurze Zeit das TRx-Ausgangs-Signal nur an das befehlende CAT-Gerät senden.
Der Timer müste nachtriggerbar sein, falls das zweite CAT-Gerät in dieser Phase zu senden beginnt (dann geht sein Telegramm halt in die Grütze) , und man müsste mit dem Timing etwas experimentieren.
Aber ich habe hat den Tick, Dinge möglichst simpel lösen zu wollen; keine Ahnung, ob das so "gut genug" wäre, um Kollisionen abzufangen (so sie denn auftreten).
73,
Ralf
Sobald ein CAT-Gerät zu senden beginnt, wird das Andere gesperrt und erst nach Ablauf eines Timers freigegeben. Die Antwort des TRx könnte man auch so behandeln, also für eine kurze Zeit das TRx-Ausgangs-Signal nur an das befehlende CAT-Gerät senden.
Moin, ja kann man so machen. Aber wenn zwei Geräte zeitgleich senden, dann gehen Informationen verloren. Daher Daten der drei Kanäle empfangen, speichern und dann, wenn alles frei ist, an die anderen weiterleiten. Bei so simplen Geräten wie ein FT-817/857/897 geht das ohne Probleme. Blöd sind da die Datenschleudern wie ICOMs. Wenn man das TRCV-On einstellt, dann müllen die alles mögliche raus. Das macht dann so einen 8-Bitter auch fertig 
.
73, Holger DL9HDA
Eigentlich ist die ganze Hardware in Form des FT817-Buddy doch schon vorhanden. Man müsste jetzt nur noch mit einem USB-Kabel den Rechner, mit dem man die digitalen Betriebsarten betreiben will, mit der USB-Schnittstelle des Arduino im FT817-Buddy verbinden. Da die Software des FT817-Buddy frei erhältlich ist (Open Source) könnte man diese einfach so erweitern dass der FT817-Buddy auch gleich die Funktion des CAT-Splitters mit übernimmt.
Hinderungsgrund wären jetzt nur noch fehlende Programmierkenntnisse ...
73
Uli DF7SC
Eigentlich ist die ganze Hardware in Form des FT817-Buddy doch schon vorhanden. Man müsste jetzt nur noch mit einem USB-Kabel den Rechner, mit dem man die digitalen Betriebsarten betreiben will, mit der USB-Schnittstelle des Arduino im FT817-Buddy verbinden. Da die Software des FT817-Buddy frei erhältlich ist (Open Source) könnte man diese einfach so erweitern dass der FT817-Buddy auch gleich die Funktion des CAT-Splitters mit übernimmt.
Hinderungsgrund wären jetzt nur noch fehlende Programmierkenntnisse ...
73
Uli DF7SC
Die Digitalen Betriebsarten sollen über den buddy gehen?
Ich hab da keine Schnittstelle zum Datenport gesehen.
