BPF in vorhandene Schaltung einfügen.
BPF in vorhandene Schaltung einfügen.
Ich habe nun einen BPF bekommen den ich in den RX/TX Pfad einfügen möchte.
Aber wie könnte es anders sein, jetzt ich stehe vor einem Problem.
Ich habe den bisher unbenutzten (im LPF der FT747-PA ist 30m und 20m zusammen, übrigens auch 17/15 und 12/10 m (ich hatte also 3 Codes übrig))
BCD-Code für 30m (0010) benutzt, um zwischen HF und VHF-Transverter umzuschalten. Das war die einfachste Lösung für mich zu dieser Zeit.
Nicht schön aber funktionabel.
Da im neuen BPF jedes Band separat angesteuert werden will, fehlt mir jetzt natürlich 30m und habe ich keine Ahnung, wie ich das machen könnte, ohne 2m zu verlieren.
Ich habe auch keine Ahnung, wie die originale 2m Umschaltung im Hermes / Alex / Penelope-Projekt gemacht wird.
Es sieht so aus, als müsste ich einen Controller bauen, der viel mehr Möglichkeiten bietet, auch im Hinblick auf zukünftige Erweiterungen wie 70cm Transverter, Anschluss für Tunersteuerung nach ICOM (gibt es die überhaupt die Möglichkeit unter PowerSDR mit dem Tunebutton einen Tuner zu schalten?)
u.s.w. Aber nur wie.
Bisher wurde die LPF Filterumschaltung der PA mit einem BCD Decoder gemacht.
Die RX/TX Umschaltung für HF findet direkt auf dem LPF in der PA statt.
Des weiteren wird der "übrige" Ausgang für 30m (0010) am BCD Decoder abgegriffen um mit einem Relais die Umschaltung HF/VHF,
mit einem weiteren Relais RX/TX für VHF und einem weiteren Relais die Umschaltung der RX/TX Pfade für HF/VHF von und zum
Red Pitaya, Transverter und PA zu machen. Funktioniert auch alles, nur jetzt stehe ich auf dem Schlauch wie es weiter gehen soll.
Von Platinenlayout usw. habe ich leider absolut keine Ahnung.
Das ganze soll natürlich mit Original OpenPowerSDR funktionieren ohne eine speziell dafür modifizierte Version verwenden zu müssen.
Bin mit meinem Möglichkeiten (und die sind sehr beschränkt) am Ende.
Wer kann mir Tips oder Hilfe dazu geben?
Aber wie könnte es anders sein, jetzt ich stehe vor einem Problem.
Ich habe den bisher unbenutzten (im LPF der FT747-PA ist 30m und 20m zusammen, übrigens auch 17/15 und 12/10 m (ich hatte also 3 Codes übrig))
BCD-Code für 30m (0010) benutzt, um zwischen HF und VHF-Transverter umzuschalten. Das war die einfachste Lösung für mich zu dieser Zeit.
Nicht schön aber funktionabel.
Da im neuen BPF jedes Band separat angesteuert werden will, fehlt mir jetzt natürlich 30m und habe ich keine Ahnung, wie ich das machen könnte, ohne 2m zu verlieren.
Ich habe auch keine Ahnung, wie die originale 2m Umschaltung im Hermes / Alex / Penelope-Projekt gemacht wird.
Es sieht so aus, als müsste ich einen Controller bauen, der viel mehr Möglichkeiten bietet, auch im Hinblick auf zukünftige Erweiterungen wie 70cm Transverter, Anschluss für Tunersteuerung nach ICOM (gibt es die überhaupt die Möglichkeit unter PowerSDR mit dem Tunebutton einen Tuner zu schalten?)
u.s.w. Aber nur wie.
Bisher wurde die LPF Filterumschaltung der PA mit einem BCD Decoder gemacht.
Die RX/TX Umschaltung für HF findet direkt auf dem LPF in der PA statt.
Des weiteren wird der "übrige" Ausgang für 30m (0010) am BCD Decoder abgegriffen um mit einem Relais die Umschaltung HF/VHF,
mit einem weiteren Relais RX/TX für VHF und einem weiteren Relais die Umschaltung der RX/TX Pfade für HF/VHF von und zum
Red Pitaya, Transverter und PA zu machen. Funktioniert auch alles, nur jetzt stehe ich auf dem Schlauch wie es weiter gehen soll.
Von Platinenlayout usw. habe ich leider absolut keine Ahnung.
Das ganze soll natürlich mit Original OpenPowerSDR funktionieren ohne eine speziell dafür modifizierte Version verwenden zu müssen.
Bin mit meinem Möglichkeiten (und die sind sehr beschränkt) am Ende.
Wer kann mir Tips oder Hilfe dazu geben?
73 de Sigi, DH1KLM
Re: BPF in vorhandene Schaltung einfügen.
Hallo Sigi,
im original wird die Steuerung per SPI-Bus gemacht, dort hat man 32bit zur Verfügung.
Bei HPSDR Atlassystem und Nachfolgern (außer Orion MK2 aka 7000/8000DLE - 48Bit und für RX 2x 5 BPF + 6m LNA) hat man die RX BPF aus einem Zusammenspiel von LPF und HPF realisiert, für die Transverterfunktion gibt es ein separates Bit.
Leider hat man bei RP das SPI Protokoll nicht vollständig und sauber in die FW integriert, das habe ich mit original Alex, eigen entwickelten Kontroller und Logicanalyzer verifiziert, im original wird bei jeder Änderung, also RX/TX, Ant1-2-3 Band usw. das komplette DWord gesendet, das macht RP nicht, somit kommt es dann zum kompletten Verschieben der Register und fehlerhaften Filter bzw. Relaisstellungen.
Es ist sehr schade, das man da nicht mehr Augenmerk drauf legt, die Möglichkeiten sind einfach größer, als auf den 7 User I/O´s
im original wird die Steuerung per SPI-Bus gemacht, dort hat man 32bit zur Verfügung.
Bei HPSDR Atlassystem und Nachfolgern (außer Orion MK2 aka 7000/8000DLE - 48Bit und für RX 2x 5 BPF + 6m LNA) hat man die RX BPF aus einem Zusammenspiel von LPF und HPF realisiert, für die Transverterfunktion gibt es ein separates Bit.
Leider hat man bei RP das SPI Protokoll nicht vollständig und sauber in die FW integriert, das habe ich mit original Alex, eigen entwickelten Kontroller und Logicanalyzer verifiziert, im original wird bei jeder Änderung, also RX/TX, Ant1-2-3 Band usw. das komplette DWord gesendet, das macht RP nicht, somit kommt es dann zum kompletten Verschieben der Register und fehlerhaften Filter bzw. Relaisstellungen.
Es ist sehr schade, das man da nicht mehr Augenmerk drauf legt, die Möglichkeiten sind einfach größer, als auf den 7 User I/O´s
Re: BPF in vorhandene Schaltung einfügen.
Hallo Sigi,
die komplette Steuerung mache ich über ein Arduino, dieser liest die BCD Daten ein und ich sage was damit geschaltet wird. der Mega 2560 hat sehr viele E/A die genutzt werden können. Zusätzlich habe ich noch ein LCD dran, was mir die Zustände anzeigt. Bild liefere ich nach.
73 Tom
die komplette Steuerung mache ich über ein Arduino, dieser liest die BCD Daten ein und ich sage was damit geschaltet wird. der Mega 2560 hat sehr viele E/A die genutzt werden können. Zusätzlich habe ich noch ein LCD dran, was mir die Zustände anzeigt. Bild liefere ich nach.
73 Tom
Re: BPF in vorhandene Schaltung einfügen.
Hallo,
aber mehr als 16i/o´s kann man mit 4bit BCD nicht auflösen und genau das ist sein Problem, wenn man wenigsens die 8Bit zur Verfügung hätte, aber soweit ich weiß gabs nur 4bit für RX1 und 4Bit für RX2 oder?
aber mehr als 16i/o´s kann man mit 4bit BCD nicht auflösen und genau das ist sein Problem, wenn man wenigsens die 8Bit zur Verfügung hätte, aber soweit ich weiß gabs nur 4bit für RX1 und 4Bit für RX2 oder?
Re: BPF in vorhandene Schaltung einfügen.
Danke schon mal für die Antworten.
Ich werde heute Abend mal eine grobe schematische Zeichnung vom Ist Zustand machen. Ich denke dann ist es leichter, mein Anliegen zu verstehen.
Ich werde heute Abend mal eine grobe schematische Zeichnung vom Ist Zustand machen. Ich denke dann ist es leichter, mein Anliegen zu verstehen.
73 de Sigi, DH1KLM
Re: BPF in vorhandene Schaltung einfügen.
Hallo zusammen.
Allem zugrunde liegt das bidirektionale „HPSDR USB Datenprotokoll“ vom PC zum HPSDR?
So steht es in der Beschreibung.
Da fängt die Verwirrung schon wieder an ?
Die Endpunkte und das Medium passen irgendwie nicht?
Es ist dennoch das gleiche. Heute ist es ist nur UDP und Ethernet und 1032 Bytes.
Ich denke an die Richtung von der PC Anwendung „HPSDR“ zum RedPitaya …
Diese Richtung ist zunächst interessant, hier spiegelt sich alles was auf dem PC Bildschirm abgebildet werden kann wieder. Ohne Filter und Fehler, zumindest so wie es gedacht war, soweit es im Rahmen der Protokolldefinition wiedergegeben werden kann und soweit es im Protokoll implementiert ist. Alle HPSDR PC Anwendungen sind bis hierhin gleich, auch wenn sie unterschiedlich auftreten und aussehen. Nicht jede PC Variante bildet jede Möglichkeit des „Standards“ in der grafischen Benutzeroberfläche ab.
Interessant sind nun 5 Bytes der 1024 Bytes Nutzlast der Pakete.
Ein „Control&Command „ Byte bietet 255 mögliche Befehle / Zustände. Jeder ist 4Byte ~ 32Bit breit.
Das macht theoretische 8160 Bits bzw. Relais etc. das Protokoll ist lange nicht ausgereizt ….
Was es bereits enthält kann man nachlesen und alles was wir suchen findet sich dort.
Meines Wissens ist das Protokoll seit 2015 nicht mehr erweitert worden.
Soweit ich das sehen konnte ( so ist es auch beschrieben ) läuft es zyklisch in einer Endlosschleife und nicht Bediener / PC ereignisgesteuert. Schon deshalb weil es neben den “Relais“ auch den Audio Datenstrom zum Sender befördert. Dabei werden alle definierten Ausgänge reihum immer wieder ausgegeben. Das hat eine gewisse, aber auch geringe Latenz zur Folge.
Jetzt und hier hätte man alles verfügbar …
Wenn die Hardware ( RP, ANAN etc ) das alles interpretieren kann ist alles in Ordnung.
Wenn die Hardware das wiederum an andere Hardware delegiert ist das auch kein Beinbruch, solange sie das ursprüngliche Protokoll interpretieren kann und soll.
Es wäre ideal, wenn jede Harwarekomponente genau das umsetzt was sie zu interpretieren weiß.
Hier ist das aus meiner Sicht falsch gelaufen.
Aus dem RP kommt nicht alles was verfügbar wäre und vermtl. auch nicht unverfälscht und interpretierbar. Solange es im RP umgesetzt wird OK (GPIO, XADC etc )
I²C mit einem eigenen, abweichenden Protokoll am RP ist schon falsch
G8NJJs Projekt dachte in meine Richtung. So kann man dort aus der Frequenz beliebige Bandpässe und Filter ableiten. Wie „APOLLO“ (Firmware / Manual ). Die „PureSignal“ Rückführung automatisch regeln usw. wie die Originale.
Ich kann es aber z.T. nicht nachvollziehen. Unvollständiger Zugriff auf das ursprüngliche Protokoll.
Ich sehe auch nicht wie ich die HPSDR Software im RP mit vertretbarem Aufwand ändern könnte.
Irrtum nicht nur vorbehalten, vermutlich sogar wahrscheinlich …
73 Werner
Allem zugrunde liegt das bidirektionale „HPSDR USB Datenprotokoll“ vom PC zum HPSDR?
So steht es in der Beschreibung.
Da fängt die Verwirrung schon wieder an ?
Die Endpunkte und das Medium passen irgendwie nicht?
Es ist dennoch das gleiche. Heute ist es ist nur UDP und Ethernet und 1032 Bytes.
Ich denke an die Richtung von der PC Anwendung „HPSDR“ zum RedPitaya …
Diese Richtung ist zunächst interessant, hier spiegelt sich alles was auf dem PC Bildschirm abgebildet werden kann wieder. Ohne Filter und Fehler, zumindest so wie es gedacht war, soweit es im Rahmen der Protokolldefinition wiedergegeben werden kann und soweit es im Protokoll implementiert ist. Alle HPSDR PC Anwendungen sind bis hierhin gleich, auch wenn sie unterschiedlich auftreten und aussehen. Nicht jede PC Variante bildet jede Möglichkeit des „Standards“ in der grafischen Benutzeroberfläche ab.
Interessant sind nun 5 Bytes der 1024 Bytes Nutzlast der Pakete.
Ein „Control&Command „ Byte bietet 255 mögliche Befehle / Zustände. Jeder ist 4Byte ~ 32Bit breit.
Das macht theoretische 8160 Bits bzw. Relais etc. das Protokoll ist lange nicht ausgereizt ….
Was es bereits enthält kann man nachlesen und alles was wir suchen findet sich dort.
Meines Wissens ist das Protokoll seit 2015 nicht mehr erweitert worden.
Soweit ich das sehen konnte ( so ist es auch beschrieben ) läuft es zyklisch in einer Endlosschleife und nicht Bediener / PC ereignisgesteuert. Schon deshalb weil es neben den “Relais“ auch den Audio Datenstrom zum Sender befördert. Dabei werden alle definierten Ausgänge reihum immer wieder ausgegeben. Das hat eine gewisse, aber auch geringe Latenz zur Folge.
Jetzt und hier hätte man alles verfügbar …
Wenn die Hardware ( RP, ANAN etc ) das alles interpretieren kann ist alles in Ordnung.
Wenn die Hardware das wiederum an andere Hardware delegiert ist das auch kein Beinbruch, solange sie das ursprüngliche Protokoll interpretieren kann und soll.
Es wäre ideal, wenn jede Harwarekomponente genau das umsetzt was sie zu interpretieren weiß.
Hier ist das aus meiner Sicht falsch gelaufen.
Aus dem RP kommt nicht alles was verfügbar wäre und vermtl. auch nicht unverfälscht und interpretierbar. Solange es im RP umgesetzt wird OK (GPIO, XADC etc )
I²C mit einem eigenen, abweichenden Protokoll am RP ist schon falsch
G8NJJs Projekt dachte in meine Richtung. So kann man dort aus der Frequenz beliebige Bandpässe und Filter ableiten. Wie „APOLLO“ (Firmware / Manual ). Die „PureSignal“ Rückführung automatisch regeln usw. wie die Originale.
Ich kann es aber z.T. nicht nachvollziehen. Unvollständiger Zugriff auf das ursprüngliche Protokoll.
Ich sehe auch nicht wie ich die HPSDR Software im RP mit vertretbarem Aufwand ändern könnte.
Irrtum nicht nur vorbehalten, vermutlich sogar wahrscheinlich …
73 Werner
Re: BPF in vorhandene Schaltung einfügen.
Hallo Sigi,
irgendwann stehe ich auch vor deinem Problem. Mir schwebt vor 70 MHz Transverter mit 28 MHz ZF.
Jetzt ist der RedPit kein Hermes-Board und hat nur eine begrenzte Anzahl von Ausgängen:
u.a. auch 2 Ausgänge für Dämpfungsglieder (10dB/20dB) und ein Ausgang für zuschaltbaren PreAmplifier.
Meine Idee:
Einen der 3 letztgenannten Ausgänge im PedPit als Schalter für Transverter "missbrauchen".
Ob sich das mit PowerSDR realisieren lässt, kann ich nicht beurteilen. Ich habe piHPSDR.
irgendwann stehe ich auch vor deinem Problem. Mir schwebt vor 70 MHz Transverter mit 28 MHz ZF.
Jetzt ist der RedPit kein Hermes-Board und hat nur eine begrenzte Anzahl von Ausgängen:
u.a. auch 2 Ausgänge für Dämpfungsglieder (10dB/20dB) und ein Ausgang für zuschaltbaren PreAmplifier.
Meine Idee:
Einen der 3 letztgenannten Ausgänge im PedPit als Schalter für Transverter "missbrauchen".
Ob sich das mit PowerSDR realisieren lässt, kann ich nicht beurteilen. Ich habe piHPSDR.
73 de Uli, DF5SF
Re: BPF in vorhandene Schaltung einfügen.
Hallo Werner,
soweit passt das alles, nur das es wirklich so ist, das der SPI Bus erst bei Änderung neu gesetzt wird, so ist es auch im FPGA Code implementiert.
Was meinst du mit dem Apolloprotokoll bzw. der automatischen PS Ausregelung?
Leider hat man sich nicht an das Protokoll gehalten, das würde in der Summe viel mehr Flexibilität geben und man hätte noch IO´s frei für andere Spielereien, eine Abhängigkeit von den "Anpassern" vom PWRSDR wäre auch nicht nötig.
In wie weit überhaupt die Ressourcen vorhanden sind im FPGA des RP sowas zu implementieren kann und will ich aber nicht beurteilen, auf alle Fälle wurde bis dato hervorragende Arbeit geleistet.
soweit passt das alles, nur das es wirklich so ist, das der SPI Bus erst bei Änderung neu gesetzt wird, so ist es auch im FPGA Code implementiert.
Was meinst du mit dem Apolloprotokoll bzw. der automatischen PS Ausregelung?
Leider hat man sich nicht an das Protokoll gehalten, das würde in der Summe viel mehr Flexibilität geben und man hätte noch IO´s frei für andere Spielereien, eine Abhängigkeit von den "Anpassern" vom PWRSDR wäre auch nicht nötig.
In wie weit überhaupt die Ressourcen vorhanden sind im FPGA des RP sowas zu implementieren kann und will ich aber nicht beurteilen, auf alle Fälle wurde bis dato hervorragende Arbeit geleistet.
Re: BPF in vorhandene Schaltung einfügen.
Hallo Rene(?),
den SPI (Serial Peripheral Interface) Bus habe ich noch gar nicht entdeckt. Alle Schaltungen die ich betrachtete hatten die Anschlüsse 3 bis 6 auf E2 unbeschaltet gelassen. Im Quellcode fand ich auch keinen Hinweis auf den SPI Bus.
Auf dem Weg aus dem RP raus habe ich bislang nur am I²C (TWI) Bus gelauscht.
Dazu sind auch einige Stellen im Quellcode ersichtlich. Hier gibt es einige Erweiterungen für einzelne „Anbauten“ und auch die Kontrolle der CODEC Platine. Deren Register werden jedoch relativ selten gesetzt. Davon abgesehen gibt es dort tatsächlich nur Aktivität wenn sich etwas ändert. Das ist meist mit einem „Wenn neuer Wert ungleich altem Wert“ verknüpft bzw. darin begründet. Die Werte werden aber im UDP Protokoll per Ethernet ungleich häufiger und vollzählig übertragen. Sie ändern sich nur nicht so häufig. Der Datenverkehr am I²C Bus ist gemischt mit Kommandos welche die Hardware dieser „Anbauten“ zum Betrieb benötigen.
Das ursprüngliche HPSDR/UDP Protokoll ist hier aber nicht vollständig und z.T. nur verändert abgebildet.
Tatsächlich weiß ich im Moment gar nicht ob I²C, SPI, UART, GPIO etc ARM oder FPGA Hardware ist.
Zumindest die Nutzung steht nicht im FPGA Programm, das ist alles C Code für den ARM Prozessor, keine FPGA Resource.
Ich wollte den „Step Attenuator“ nutzen, wobei es Ungereimtheiten auf dem I²C Bus gibt.
Man müsste ihn auch für beide RX haben, die Rückführung geht beim RP in den zweiten RX.
Gerade dabei macht es aber einen Fehler auf dem I²C Bus nach dem (ersten) Senden. In dem Arduino Sketch fehlen mir einige Werte. Seltsamerweise funktioniert auch der originale C Code bei mir so fehlerhaft wie mein eigener. RX1 Frequenz z.B. gibt es nie ?
Workaround : „Wenn TX <> RX2 dann RX1 = TX“. usw.
Darin gibt es eigentlich auch die Möglichkeit die Anzahl und Lage der Band-,Hoch- und Tiefpässe beliebig nach eingestellter Frequenz für jeden RX/TX frei zu wählen, in einer Tabelle der Arduino Firmware. Etwas Ähnliches vermute ich hinter der Auswahl „Manual/Firmware“
Ich ziehe selbstverständlich auch den Hut vor den Leuten und dem Umgesetzten.
Nur mit dem RP und dem Support dafür hadere ich doch inzwischen sehr.
Irrtum nicht nur vorbehalten, vermutlich sogar wahrscheinlich …
73 Werner
den SPI (Serial Peripheral Interface) Bus habe ich noch gar nicht entdeckt. Alle Schaltungen die ich betrachtete hatten die Anschlüsse 3 bis 6 auf E2 unbeschaltet gelassen. Im Quellcode fand ich auch keinen Hinweis auf den SPI Bus.
Auf dem Weg aus dem RP raus habe ich bislang nur am I²C (TWI) Bus gelauscht.
Dazu sind auch einige Stellen im Quellcode ersichtlich. Hier gibt es einige Erweiterungen für einzelne „Anbauten“ und auch die Kontrolle der CODEC Platine. Deren Register werden jedoch relativ selten gesetzt. Davon abgesehen gibt es dort tatsächlich nur Aktivität wenn sich etwas ändert. Das ist meist mit einem „Wenn neuer Wert ungleich altem Wert“ verknüpft bzw. darin begründet. Die Werte werden aber im UDP Protokoll per Ethernet ungleich häufiger und vollzählig übertragen. Sie ändern sich nur nicht so häufig. Der Datenverkehr am I²C Bus ist gemischt mit Kommandos welche die Hardware dieser „Anbauten“ zum Betrieb benötigen.
Das ursprüngliche HPSDR/UDP Protokoll ist hier aber nicht vollständig und z.T. nur verändert abgebildet.
Tatsächlich weiß ich im Moment gar nicht ob I²C, SPI, UART, GPIO etc ARM oder FPGA Hardware ist.
Zumindest die Nutzung steht nicht im FPGA Programm, das ist alles C Code für den ARM Prozessor, keine FPGA Resource.
Ich wollte den „Step Attenuator“ nutzen, wobei es Ungereimtheiten auf dem I²C Bus gibt.
Man müsste ihn auch für beide RX haben, die Rückführung geht beim RP in den zweiten RX.
Gerade dabei macht es aber einen Fehler auf dem I²C Bus nach dem (ersten) Senden. In dem Arduino Sketch fehlen mir einige Werte. Seltsamerweise funktioniert auch der originale C Code bei mir so fehlerhaft wie mein eigener. RX1 Frequenz z.B. gibt es nie ?
Workaround : „Wenn TX <> RX2 dann RX1 = TX“. usw.
Darin gibt es eigentlich auch die Möglichkeit die Anzahl und Lage der Band-,Hoch- und Tiefpässe beliebig nach eingestellter Frequenz für jeden RX/TX frei zu wählen, in einer Tabelle der Arduino Firmware. Etwas Ähnliches vermute ich hinter der Auswahl „Manual/Firmware“
Ich ziehe selbstverständlich auch den Hut vor den Leuten und dem Umgesetzten.
Nur mit dem RP und dem Support dafür hadere ich doch inzwischen sehr.
Irrtum nicht nur vorbehalten, vermutlich sogar wahrscheinlich …
73 Werner
Re: BPF in vorhandene Schaltung einfügen.
Hallo Werner, (ja, René stimmt
)
den i2c auf RP habe ich noch nicht betrachtet, nur den SPI, da er für meine benutzte HW benötigt wird.
Ich habe damals , zu HPSDR Atlas Zeiten eine kleine µControllerplatine entworfen mit einer Hand voll Software, welche den SPI ausliest und die passenden Ausgänge setzt, das war darauf begründet, das man zu der Zeit die TPIC6B595 nur teuer importieren konnte.
Diese Platine funktioniert auch unter Hermes/Angelia und Orion (nicht unter MK2 - > Protokoll geändert in Bezug auf Geschwindigkeit usw.)
Daher habe ich recht lange mit der Analyse des SPI verbracht, weil es damals auch einige Bugs im Protokoll gab und ich nach Fehlern in meiner HW gesucht habe, die es nicht gab..hi![Smile :-)](./images/smilies/icon_e_smile.gif)
Bei HPSDR macht man die Filterzuweisung per if then im FPGA (Firmware) oder per Software am PC (Manual) -(hoffe die Erklärung zu Firm- und Software reicht aus)
Um die Abläufe genau zu analysieren kann man sich auch die FPGA sourcen für HPSDR runter laden und mit jeden Texteditor öffnen (eleganter natürlich mit Quartus)
mfg René
![Wink ;-)](./images/smilies/icon_e_wink.gif)
den i2c auf RP habe ich noch nicht betrachtet, nur den SPI, da er für meine benutzte HW benötigt wird.
Ich habe damals , zu HPSDR Atlas Zeiten eine kleine µControllerplatine entworfen mit einer Hand voll Software, welche den SPI ausliest und die passenden Ausgänge setzt, das war darauf begründet, das man zu der Zeit die TPIC6B595 nur teuer importieren konnte.
Diese Platine funktioniert auch unter Hermes/Angelia und Orion (nicht unter MK2 - > Protokoll geändert in Bezug auf Geschwindigkeit usw.)
Daher habe ich recht lange mit der Analyse des SPI verbracht, weil es damals auch einige Bugs im Protokoll gab und ich nach Fehlern in meiner HW gesucht habe, die es nicht gab..hi
![Smile :-)](./images/smilies/icon_e_smile.gif)
Bei HPSDR macht man die Filterzuweisung per if then im FPGA (Firmware) oder per Software am PC (Manual) -(hoffe die Erklärung zu Firm- und Software reicht aus)
Um die Abläufe genau zu analysieren kann man sich auch die FPGA sourcen für HPSDR runter laden und mit jeden Texteditor öffnen (eleganter natürlich mit Quartus)
mfg René
Re: BPF in vorhandene Schaltung einfügen.
So, hab jetzt mal etwas zusammengeschustert.
Das PDF zeigt die derzeitige Zusammenschaltung der einzelnen Komponenten.
Jetzt soll eben noch der BPF dazu. Evtl. noch ein Sampler an IN2, der aber weiterhin auch als RX2 verwendet werden soll.
Edit: Hab gerade gesehen dass ich vergessen habe die PTT an DIO0_N einzuzeichnen.
Das PDF zeigt die derzeitige Zusammenschaltung der einzelnen Komponenten.
Jetzt soll eben noch der BPF dazu. Evtl. noch ein Sampler an IN2, der aber weiterhin auch als RX2 verwendet werden soll.
Edit: Hab gerade gesehen dass ich vergessen habe die PTT an DIO0_N einzuzeichnen.
- Dateianhänge
-
DH1KLM-RP-TRX.pdf
- (1023.83 KiB) 412-mal heruntergeladen
73 de Sigi, DH1KLM
Re: BPF in vorhandene Schaltung einfügen.
@ Rene
Da bin ich aber froh, dass ich bei der falschen Hardware war.
Ich konnte mir so gar nicht erklären wie ich den SPI übersehen konnte.
@ Sigi
Eigentlich rätsele ich an der gleichen Fragestellung, nur noch sehr theoretisch.
Immer wenn ich etwas umsetzen will liegt der Teufel im Detail…
Ich denke Du willst Filter für den RX1 schalten ?
RX1 und RX2 sollen auch in unterschiedlichen Bändern gleichzeitig empfangen ?
RX2 soll auch für die PureSignal Rückführung benutzt werden ?
( Bei mir kommt jetzt noch hinzu :
Beide RX sind die Messeingänge des „HAMLAB“ wenn HPSDR nicht läuft.
Die Messeingänge sollten auch einer der wählbaren Antenneneingänge bei HPSDR Betrieb sein)
Für nur einen ( den ersten ) RX haben wir
7 Bits zum ankreuzen in dem PC Register HERMES
7 Bits zum ankreuzen in dem PC Register ALEX
Für bis zu acht RX haben wir die Empfangsfrequenz aus HPSDR
Für zwei Empfänger lassen sich die HERMES Bits an zwei verschiedene VFOs binden, bei nur 4 und 3 Bit Auflösung ( 4x3 Split ).
Aus dem nackten Red Pitaya mit der Software von Pavel bekommen wir
4 der 7 HERMES Bits an DIO7..3+ von Anschluss E2
/* set output pins */
ptt = frame[0] & 0x01;
att = frame[3] & 0x03;
preamp = ptt | (*gpio_in & 1) ? 0 : (frame[3] & 0x04) >> 2 | (rx_att_data == 0);
*gpio_out = (frame[2] & 0x1e) << 3 | att << 2 | preamp << 1 | ptt;
7 HERMES Bits für PENELOPE auf dem I²C Bus Adresse 0x20 (falls ein Codec Board benutzt wird).
7 HERMES Bits für PENELOPE an Schieberegister E1 wenn kein Codec Board benutzt wird.
/* configure PENELOPE */
if(i2c_pene)
{data = (frame[3] & 0x1c) << 11 | (frame[4] & 0x03) << 11 | (frame[3] & 0x60) << 4 | (frame[3] & 0x03) << 7 | frame[2] >> 1;
if(i2c_pene_data != data)
7 HERMES Bits auf dem I²C Bus G8NJJ Adresse 0x40 „C&C“ 0x4
Mikrokontroller z.B. Arduino nötig.
else
data32 = i2c_ard_ocant_data & 0x0003007f;
data32 |= (frame[2] << 7); /* add back in OC bits */
data8 = (frame[3] & 0x60) >> 5; /* RX aux bits */
if(data8 == 0)
Es geht auch auf die eine oder andere Weise zum MISC duo Transceiver und per RS232 zur seriellen Schnittstelle.
Usw. nur ein Aspekt: RX 1 BPF
Aus den 7 + 7 Bits lässt sich etwas kombinieren. Aus 7 Bits kann man 127 Mögliche ableiten.
Das führt aber alles dazu, dass Anzeige und Wirkung nicht mehr passen.
4 Anschlüsse am Red Pitaya machen 16 Mögliche ohne Abbild auf dem Bildschirm. 4 : 16 Decoder.
Mit 4 Anschlüssen hätte man auch das gesamte Protokoll in eine Eimerkette aus Schieberegistern schieben können. 1 : n Decoder nach Belieben.
Also Lösungen ohne Mikrokontroller…
In erster Näherung braucht du ETWAS ( G8NJJ ) an I²C Adresse 0x40 oder etwas an ETWAS (DC2PD) an I²C Adresse 0x20 und 0x21.
So oder so hat man dann schon einmal mindestens 12 Bänder mit einer sinnvollen Beschriftung im PC.
Ganz Verwegene könnten einen Sniffer auf das UDP Packet setzen und mit den 10 Bytes machen was sie wollen … und nur das.
Ich habe nicht verstanden wie sich der zweite Lottoschein definiert, was ihn aktiviert, wo er sich abbildet.
Den Unterschied RX2 und PureSinal kann man sicher aus der PTT ableiten, bei den Abschwächern bin ich dann schon stecken geblieben …
Mir verdreht sich das Gehirn. Als gäbe es für jede historische Gerätschaft eine Ausnahme / Umsetzung im Red Pitaya. Dabei ist auch vermutlich irgendetwas durcheinander geraten ?
Lieber hätte ich das Bisschen C&C HPSDR Protokoll 1:1 durchgereicht um selbst ALEX, HERMES, PENELOPE, APHRODITE, ICOM KENNWOOD 736 / 737 / 7123 zu spielen. Wenn es dann falsch läuft bin ich es selbst schuld oder die PC / Tablett / Smartphone Software hält sich nicht an das Protokoll, ist also etwas anderes.
Das wäre im Zweifel nur ein Arduino für 3 Euro, den ich souverän und schmerzfrei von Assembler bis C im Griff hätte.
Mir hat der längliche Text erst einmal geholfen zu verstehen, warum mein Hirn sich so verweigert.
Wie immer kann das auch wieder alles Unsinn sein :O)
Werner
Da bin ich aber froh, dass ich bei der falschen Hardware war.
Ich konnte mir so gar nicht erklären wie ich den SPI übersehen konnte.
@ Sigi
Eigentlich rätsele ich an der gleichen Fragestellung, nur noch sehr theoretisch.
Immer wenn ich etwas umsetzen will liegt der Teufel im Detail…
Ich denke Du willst Filter für den RX1 schalten ?
RX1 und RX2 sollen auch in unterschiedlichen Bändern gleichzeitig empfangen ?
RX2 soll auch für die PureSignal Rückführung benutzt werden ?
( Bei mir kommt jetzt noch hinzu :
Beide RX sind die Messeingänge des „HAMLAB“ wenn HPSDR nicht läuft.
Die Messeingänge sollten auch einer der wählbaren Antenneneingänge bei HPSDR Betrieb sein)
Für nur einen ( den ersten ) RX haben wir
7 Bits zum ankreuzen in dem PC Register HERMES
7 Bits zum ankreuzen in dem PC Register ALEX
Für bis zu acht RX haben wir die Empfangsfrequenz aus HPSDR
Für zwei Empfänger lassen sich die HERMES Bits an zwei verschiedene VFOs binden, bei nur 4 und 3 Bit Auflösung ( 4x3 Split ).
Aus dem nackten Red Pitaya mit der Software von Pavel bekommen wir
4 der 7 HERMES Bits an DIO7..3+ von Anschluss E2
/* set output pins */
ptt = frame[0] & 0x01;
att = frame[3] & 0x03;
preamp = ptt | (*gpio_in & 1) ? 0 : (frame[3] & 0x04) >> 2 | (rx_att_data == 0);
*gpio_out = (frame[2] & 0x1e) << 3 | att << 2 | preamp << 1 | ptt;
7 HERMES Bits für PENELOPE auf dem I²C Bus Adresse 0x20 (falls ein Codec Board benutzt wird).
7 HERMES Bits für PENELOPE an Schieberegister E1 wenn kein Codec Board benutzt wird.
/* configure PENELOPE */
if(i2c_pene)
{data = (frame[3] & 0x1c) << 11 | (frame[4] & 0x03) << 11 | (frame[3] & 0x60) << 4 | (frame[3] & 0x03) << 7 | frame[2] >> 1;
if(i2c_pene_data != data)
7 HERMES Bits auf dem I²C Bus G8NJJ Adresse 0x40 „C&C“ 0x4
Mikrokontroller z.B. Arduino nötig.
else
data32 = i2c_ard_ocant_data & 0x0003007f;
data32 |= (frame[2] << 7); /* add back in OC bits */
data8 = (frame[3] & 0x60) >> 5; /* RX aux bits */
if(data8 == 0)
Es geht auch auf die eine oder andere Weise zum MISC duo Transceiver und per RS232 zur seriellen Schnittstelle.
Usw. nur ein Aspekt: RX 1 BPF
Aus den 7 + 7 Bits lässt sich etwas kombinieren. Aus 7 Bits kann man 127 Mögliche ableiten.
Das führt aber alles dazu, dass Anzeige und Wirkung nicht mehr passen.
4 Anschlüsse am Red Pitaya machen 16 Mögliche ohne Abbild auf dem Bildschirm. 4 : 16 Decoder.
Mit 4 Anschlüssen hätte man auch das gesamte Protokoll in eine Eimerkette aus Schieberegistern schieben können. 1 : n Decoder nach Belieben.
Also Lösungen ohne Mikrokontroller…
In erster Näherung braucht du ETWAS ( G8NJJ ) an I²C Adresse 0x40 oder etwas an ETWAS (DC2PD) an I²C Adresse 0x20 und 0x21.
So oder so hat man dann schon einmal mindestens 12 Bänder mit einer sinnvollen Beschriftung im PC.
Ganz Verwegene könnten einen Sniffer auf das UDP Packet setzen und mit den 10 Bytes machen was sie wollen … und nur das.
Ich habe nicht verstanden wie sich der zweite Lottoschein definiert, was ihn aktiviert, wo er sich abbildet.
Den Unterschied RX2 und PureSinal kann man sicher aus der PTT ableiten, bei den Abschwächern bin ich dann schon stecken geblieben …
Mir verdreht sich das Gehirn. Als gäbe es für jede historische Gerätschaft eine Ausnahme / Umsetzung im Red Pitaya. Dabei ist auch vermutlich irgendetwas durcheinander geraten ?
Lieber hätte ich das Bisschen C&C HPSDR Protokoll 1:1 durchgereicht um selbst ALEX, HERMES, PENELOPE, APHRODITE, ICOM KENNWOOD 736 / 737 / 7123 zu spielen. Wenn es dann falsch läuft bin ich es selbst schuld oder die PC / Tablett / Smartphone Software hält sich nicht an das Protokoll, ist also etwas anderes.
Das wäre im Zweifel nur ein Arduino für 3 Euro, den ich souverän und schmerzfrei von Assembler bis C im Griff hätte.
Mir hat der längliche Text erst einmal geholfen zu verstehen, warum mein Hirn sich so verweigert.
Wie immer kann das auch wieder alles Unsinn sein :O)
Werner
Re: BPF in vorhandene Schaltung einfügen.
Hallo Werner,
mir verdreht sich schon das Hirn wenn ich nur versuche eine Schaltungmöglichkeit zu finden, abgesehen davon
ob sich das dann auch mit PowerSDR schalten lässt und dann kommst du mit so einem Post um die Ecke, mit einer
Thematik die meinen Horizont deutlich übersteigt.
Ich gehe mal stark davon aus, dass sich eine Menge meiner "Anforderungen" über den I²C schalten lässt.
mir verdreht sich schon das Hirn wenn ich nur versuche eine Schaltungmöglichkeit zu finden, abgesehen davon
ob sich das dann auch mit PowerSDR schalten lässt und dann kommst du mit so einem Post um die Ecke, mit einer
Thematik die meinen Horizont deutlich übersteigt.
![Laughing :lol:](./images/smilies/icon_lol.gif)
Ich gehe mal stark davon aus, dass sich eine Menge meiner "Anforderungen" über den I²C schalten lässt.
73 de Sigi, DH1KLM
Re: BPF in vorhandene Schaltung einfügen.
Hallo Sigi,
hier eine Idee, wie deine Lösung aussehen könnte:
hier die Beschreibung und die dazugehörende Schaltung
hier eine Idee, wie deine Lösung aussehen könnte:
hier die Beschreibung und die dazugehörende Schaltung
73 de Uli, DF5SF
Re: BPF in vorhandene Schaltung einfügen.
Danke Uli,
über die Schaltung bin ich auch schon mal gestolpert.
Damit werden ja schon mal alle Bänder abgedeckt. Für meine Zwecke müsste der ULN2004AD gegen einen UDN2981A ausgetauscht werden (high side).
Aber wie sieht es denn mit dem gleichzeitigen RX auf 2 verschiedenen Bändern aus? (z.B. 40m + 20m) Das wird ja damit auch nicht funktionieren oder,
wie werden denn da die Filter geschaltet?
über die Schaltung bin ich auch schon mal gestolpert.
Damit werden ja schon mal alle Bänder abgedeckt. Für meine Zwecke müsste der ULN2004AD gegen einen UDN2981A ausgetauscht werden (high side).
Aber wie sieht es denn mit dem gleichzeitigen RX auf 2 verschiedenen Bändern aus? (z.B. 40m + 20m) Das wird ja damit auch nicht funktionieren oder,
wie werden denn da die Filter geschaltet?
73 de Sigi, DH1KLM
Re: BPF in vorhandene Schaltung einfügen.
Moin, Moin,
ich sehe jetzt keinen Unterschied zwischen dem YAESU Bandumschalter in der Mitte von Sigis PDF und Ulis identischem Vorschlag.
Pegel oder Polarität spielen erst'mal keine Rolle ...
Sigi hat es recht gut versteckt:
Ich habe nun einen BPF bekommen den ich in den RX/TX Pfad einfügen möchte. Dahinter verbergen sich konkrete Angaben.
Wenn es Bandpässe sind dann müsste man einen Durchgang haben bei nicht vorhandenen Bändern z.B. alle vier Bit 0 oder 1.
Für eine generelle Umschaltung HF<>VHF kann man sich nun auf einen der beiden Zustände einigen. Z.B. 0000 = Durchgang HF und 1111 = VHF.
Die neun Bänder werden dann wie beschrieben abgeschlossen und im Lottoschein entsprechend angekreuzt.
Einen Schaltplan sehe ich da nicht, Ausgänge für 0 und 15 wird der Decoder nicht haben, mit 16 Beinchen unmöglich. Was es ist kann ich nicht sehen. Man braucht vermutlich etwas zusätzliche Logik. Ein UND Baustein mit vier Eingängen oder äquivalente Kombinationen kleinerer Gatter reicht im Prinzip um den Unterschied HF-VHF zu machen.
Will man das mit den vier Anschlüssen am Red Pitaya machen wird das ein Heidengeklappere, da nun im Zweifel bei RX und TX unterschiedliche Relaiskombinationen anstehen. Auch die RX Bandpässe jeweils „mitwechseln“.
VHF ist dann auch nur VHF ohne mögliche Varianten.
Das BCD Arrangement ist eine super Lösung für „jetzt geht’s los“ ohne zusätzliches Getue .. Zukunftsträchtig ist das in keinem Fall, wollte es wohl auch nie sein.
Zwei vollwertige RX gehen so auf keinen Fall.
Also ohne mindestens die z.B. I²C Lösung z.B. DC2PD geht das nicht wirklich.
Auf lange Sicht fährt man am besten mit einem µP einfacher Machart.
Wie man ihn am besten integriert, da suche ich noch. Die Beschränkungen der BCD Kodierung sollte er aber nicht zur Grundlage haben. Die eigentliche Umschaltung HF<>VHF versteckt sich in der Antennenumschaltung XV
(Transverter) zumindest scheint das er Schaltfläche XVTR in der Transverter Einrichtung entsprechend und eben nicht nur für RX.
z.B. auf I²C zugänglich, muss dann aber auch noch verUNdet werden.
Werner
ich sehe jetzt keinen Unterschied zwischen dem YAESU Bandumschalter in der Mitte von Sigis PDF und Ulis identischem Vorschlag.
Pegel oder Polarität spielen erst'mal keine Rolle ...
Sigi hat es recht gut versteckt:
Ich habe nun einen BPF bekommen den ich in den RX/TX Pfad einfügen möchte. Dahinter verbergen sich konkrete Angaben.
Wenn es Bandpässe sind dann müsste man einen Durchgang haben bei nicht vorhandenen Bändern z.B. alle vier Bit 0 oder 1.
Für eine generelle Umschaltung HF<>VHF kann man sich nun auf einen der beiden Zustände einigen. Z.B. 0000 = Durchgang HF und 1111 = VHF.
Die neun Bänder werden dann wie beschrieben abgeschlossen und im Lottoschein entsprechend angekreuzt.
Einen Schaltplan sehe ich da nicht, Ausgänge für 0 und 15 wird der Decoder nicht haben, mit 16 Beinchen unmöglich. Was es ist kann ich nicht sehen. Man braucht vermutlich etwas zusätzliche Logik. Ein UND Baustein mit vier Eingängen oder äquivalente Kombinationen kleinerer Gatter reicht im Prinzip um den Unterschied HF-VHF zu machen.
Will man das mit den vier Anschlüssen am Red Pitaya machen wird das ein Heidengeklappere, da nun im Zweifel bei RX und TX unterschiedliche Relaiskombinationen anstehen. Auch die RX Bandpässe jeweils „mitwechseln“.
VHF ist dann auch nur VHF ohne mögliche Varianten.
Das BCD Arrangement ist eine super Lösung für „jetzt geht’s los“ ohne zusätzliches Getue .. Zukunftsträchtig ist das in keinem Fall, wollte es wohl auch nie sein.
Zwei vollwertige RX gehen so auf keinen Fall.
Also ohne mindestens die z.B. I²C Lösung z.B. DC2PD geht das nicht wirklich.
Auf lange Sicht fährt man am besten mit einem µP einfacher Machart.
Wie man ihn am besten integriert, da suche ich noch. Die Beschränkungen der BCD Kodierung sollte er aber nicht zur Grundlage haben. Die eigentliche Umschaltung HF<>VHF versteckt sich in der Antennenumschaltung XV
(Transverter) zumindest scheint das er Schaltfläche XVTR in der Transverter Einrichtung entsprechend und eben nicht nur für RX.
z.B. auf I²C zugänglich, muss dann aber auch noch verUNdet werden.
Werner
Re: BPF in vorhandene Schaltung einfügen.
Der Unterschied zwischen meiner Bandumschaltung und des BCD_14 ist der, dass ich damit 2m (zukünftig auch 70cm) direkt schalten könnte da ja ein BCD code dafür vorgesehen ist.
Das bedeutet, ich würde 30m für den Bandpass nicht verlieren. Für alles weitere scheint mir der BCD_14 aber auch nicht geeignet.
Edit:
Ich habe auch Yevgeni RZ3QS bezüglich seines Video und dem Eintrag hier auf CQ-NRW, angeschrieben.
Leider hat er keinen Schaltplan zu seiner Steuerung.
Das bedeutet, ich würde 30m für den Bandpass nicht verlieren. Für alles weitere scheint mir der BCD_14 aber auch nicht geeignet.
Edit:
Ich habe auch Yevgeni RZ3QS bezüglich seines Video und dem Eintrag hier auf CQ-NRW, angeschrieben.
Leider hat er keinen Schaltplan zu seiner Steuerung.
73 de Sigi, DH1KLM
Re: BPF in vorhandene Schaltung einfügen.
Hallo,
irgendwie verstehe ich in diesem Thread weder die Fragen noch die Antworten…
In dem von Sigi verlinktem EBAY Artikel und dem Forumsbeitrag in Russland scheint es um die gleiche Platine zu gehen.
Die Beschaltung ist zumindest identisch.
Auf EBAY hat RZ2QS die Anschlüsse nur spiegelverkehrt dargestellt.
Obwohl das möglich ist hat er dort laut Blockschaltbild die Bandfilterplatine nicht direkt an die BCD Ausgänge des Red Pitaya angeschlossen.
Aus den Gründen die ich schildern wollte …
Grüße
Werner
irgendwie verstehe ich in diesem Thread weder die Fragen noch die Antworten…
In dem von Sigi verlinktem EBAY Artikel und dem Forumsbeitrag in Russland scheint es um die gleiche Platine zu gehen.
Die Beschaltung ist zumindest identisch.
Auf EBAY hat RZ2QS die Anschlüsse nur spiegelverkehrt dargestellt.
Obwohl das möglich ist hat er dort laut Blockschaltbild die Bandfilterplatine nicht direkt an die BCD Ausgänge des Red Pitaya angeschlossen.
Aus den Gründen die ich schildern wollte …
Grüße
Werner
Re: BPF in vorhandene Schaltung einfügen.
Hallo Sigi,
mit welchem Sensor machst du die Leistungs/SWR-Anzeige auf 2m und 70cm ?
Habe für den Bereich 160m - 2m (höher gehe ich nicht) noch nichts gefunden.
Externes SWR-Meter für 6m, 4m und 2m ist auch nicht der Hit.
mit welchem Sensor machst du die Leistungs/SWR-Anzeige auf 2m und 70cm ?
Habe für den Bereich 160m - 2m (höher gehe ich nicht) noch nichts gefunden.
Externes SWR-Meter für 6m, 4m und 2m ist auch nicht der Hit.
73 de Uli, DF5SF