Forum.PowerSDR.de

Werner B hat geschrieben:Guten Morgen,
hat denn jemand so ein Aluminiumgehäuse und ist das Thema damit erledigt ?
....

es scheint also, dass dieses Aluminiumgehäuse keine Lösung ist ?

Inzwischen habe ich aufgehört meine FPGA Temperatur zu beobachten.
In den vergangenen, verfrühten Sommertagen habe ich mit meiner Blechkiste einen Rekordwert von 62°C aus der FPGA gelesen.
Ohne jeden Lüfter ...
Die Abschirmung halte ich auf jeden Fall für sinnvoll / nötig.

Grüße
Werner

Is it possible to compile the “sdr-transceiver-hpsdr” UDP server ( and subsets of its code ) on my VMbox and for the VMbox ?
I have tried “Make” and of cause it does not invoke the cross compiler tool chain on a x86_64 machine.

arm-linux-gnueabihf-gcc -static -O3 -march=armv7-a -mcpu=cortex-a9 -mtune=cortex-a9 -mfpu=neon -mfloat-abi=hard -D_GNU_SOURCE sdr-transceiver-hpsdr.c -o sdr-transceiver-hpsdr -lm –lpthread
does not work at all.
arm-linux-gnueabihf-gcc -static -O3 -march=armv7-a -mcpu=cortex-a9 -mtune=cortex-a9 -mfpu=neon -mfloat-abi=hard -D_GNU_SOURCE -lm –lpthread sdr-transceiver-hpsdr.c -o sdr-transceiver-hpsdr
will do some, with some missing arithmetic …
Both would not be usable binaries for local debug and simulation.

gcc -static -O3 -D_GNU_SOURCE sdr-transceiver-hpsdr.c -o sdr-transceiver-hpsdr -lm –lpthread
gcc: error: –lpthread: Datei oder Verzeichnis nicht gefunden
gcc -static -O3 -D_GNU_SOURCE –lm –lpthread sdr-transceiver-hpsdr.c -o sdr-transceiver-hpsdr
a longs list
sdr-transceiver-hpsdr.c: In function ‘icom_write’:
sdr-transceiver-hpsdr.c:334:22: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
if(uart_fd >= 0) write(uart_fd, buffer, 10);
^
/tmp/cckSHPSb.o: In Funktion `calc_log_lookup':
sdr-transceiver-hpsdr.c:(.text+0x16b5): Nicht definierter Verweis auf `log10'
/tmp/cckSHPSb.o: In Funktion `process_ep2'
sdr-transceiver-hpsdr.c:(.text+0x20aa): Nicht definierter Verweis auf `trunc'
…
/tmp/cckSHPSb.o: In Funktion `main':
sdr-transceiver-hpsdr.c:(.text.startup+0xa0a): Nicht definierter Verweis auf `cos'
…
sdr-transceiver-hpsdr.c:(.text.startup+0xb07): Nicht definierter Verweis auf `floor'
sdr-transceiver-hpsdr.c:(.text.startup+0xcf6): Nicht definierter Verweis auf `pthread_attr_init'
sdr-transceiver-hpsdr.c:(.text.startup+0xd08): Nicht definierter Verweis auf `pthread_attr_setinheritsched' ….


With Netbeans and Eclipse building for LINUX x86_64 is always stuck with “datagram” ?!? More or less the same error and a number of subsequent errors ?
“mmsghdr” should be a structure of “msghdr”s + size defined in “socket.h” ?
They are called datagrams but … where is “datagram” defined ?
Why isn’t “datagram” interpreted ?
I only would like to try and test a few minor changes to the I²C interfaces…
lets say a different approach.

73 Werner

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

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

@ 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

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

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

Hallo zusammen
auf diese Art finde ich es zu mühsam...

@Pavel
“Read the docs” keeps misleading me.
This time installing the (SDK) development machine unwillingly destroyed the existing C/C++ ARM ECLIPSE IDE finally both were not working.
RP seems to be in love with FPGAs.
For now I don’t care if that is “Field”, “Factory” or “Not at all” programmable. If it was a bunch of hard wired TTL chips doing the DDC and DUC job, fine.

73 Werner

I agree on ECLIPSE.
But RP recommends Vivado SDK which is ECLIPSE in the bitter end.
I am very disappointed, left in the rain with setting up ECLIPSE myself.
RP does not give a prebuilt “Hello World!” example, ready to roll, fixing the ECLIPSE SDK for me ?
Hardware, board, OS …

Hello Pavel, Hello Uli.

Thank you Uli. I think there must be better ways. What you do and describe is the traditional trial and error.
Which isn’t what I am used to and what I am looking for. I should have asked better.
A good IDE ( EDT, SDK etc) will make life a lot easier. Coding can be fun.
More efficient, less time consuming, less error prone is what I expect from a 300Euro single board computer in 2018.
When you read the RP docs you might get the impression there is.

It doesn’t clearly say here is what you will need for FPGA design.
This is where I took the wrong turn ? I didn’t know that all of this hustle is useless for what I want to do.
The SDK is mentioned to be added and it is only a few percent of the whole 30 GB bundle.
The second best disaster has been the Vivado installation.
It does not install the promised program icon, short cuts, etc. Repeatedly on my side and according to google on many other user’s end as well.
Most end up with not knowing how and what to start ( under LINUX only ?).

A very busy thread in their forum is about just launching one of their programs. I.e. SDK.
See a three page thread on how to lauch it :O( There is a large community that wonders what and how to start at all.
https://forums.xilinx.com/t5/Embedded-D ... d-p/693615
Typical confusing Xilinx stuff.

(**** Picture greeting from Eclipse ***)
Then you will be surprised to end up in yet another ECLIPSE installation.
It comes unnoticed and in disguise named as a Xilinx SDK.
You probably should not have two gods at a time ?

(**** Screen shot of ECLIPSE II alias EDT (SDK) Vivado ****)
It doesn’t mean ECLIPSE II is working yet, but it isn’t dummy dead as ECLIPSE I in the end…
I wish I had tested ECLIPSE I before installing ECLIPSE II.

73 Werner
somehow I cannot add any files or pictures anymore.

Hello Pavel,
I can leave some question marks. But I don’t think I know what I’m talking about anymore.

Years ago I’ve been playing with STM32F407VGT6-Mikrocontroller ARM Cortex®-M4 and ST-Link to xyz IDE.
Latest Raspberry is Cortex-A53 ?
For WINDOWS all free cross compilers I can find are bare metall and ARMv8-M (Hard FP) latest.

We are up to ARM-9 hardware floating point ?
They say there is for LINUX ? But it seems to be a rumor away from the command line Interpreter ?

There must be one inside Vivado but I am just too stupid for HLS or should it be SDK ?
I even cannot really figure the purpose of their three programs ?

All I can see and find is :
/lib/ld-linux-armhf.so.3: No such file or directory.
With no solution ?
May be just the *hf is the point where it all crashes about ?

Best regards
Werner

Hello Pavel,

… GNU autoconf, configure and make scripts for GNU compiler, binutils and eglibc are extremely large and complex software.
Unlike normal software development, it is almost always impossible to decipher any useful information from printed error messages.
Nobody in the world except elite GNU developers understands them.
If something does wrong, go Google for it. Probably someone already saw that particular problem. In any case, trying to handle it entirely by yourself is just waste of time.
Because the entire thing is very fragile and it's very easy to break something in the course, it's very important to perform all actions on the virtual machine(s) and take snapshots after each major success. Otherwise you'll have to restart this Rube Goldbergy each from the scratch.
Only few will go all the way to the end, and everyone of those people will have strong personal qualities of perseverance and total neglection of failures. Impatient and emotional character types should …
I've got some from the link … there is a piece of hardware.
The hardest part is done in the FPGA, thanks to Pavel.
I could imagine a number of things to be done with the rest of it.
Unfortunately it would be a quantum leap and I am not going for.
Some 40 years ago I used to toggle binaries in d-i-g-i-t-a-l PDP8. Yes, I was happy when we got a punched tape reader …
But I m not going to develop and debug with an egg and a tooth pick on a Red Pitaya..
It simply isn’t spread and supported like Arduinos, Discoveries, Raspberries and name it ... Where you setup an IDE in two or three mouse clicks.
I will just leave it alone.

Best Regards
Werner

P.S. yes, it doesn't do "Hello World" either.
But I can do it from a TTY console ...

it all seems to be there. It still doesn't built any usefull "bin"

Some defines / declares are bugging it ?
Some options are "wrong" ?
I don't know anymore.

Connecting Red Pitaya / remote file System does not seem to be a problem though.
May be it even would debug ....

Hello Pavel,
thank you very much.
Strange it doesn’t work like this on my side ( again )
I found some instructions last night that do seem to make some sense for Eclipse ? It needs all steps ?!? But it is ( I'm) missing a number of declarations ?
And I am not really sure what it is doing, the includes do not look right.
It will show ARM for new, empty projects ( vanishing as soon ... )

I had thought someone, somewhere pops up :
“ Here is a copy of my ECLIPSE, KEIL, IAR, VisualStudio etc. project, template, export etc.” ready to roll.
May be a Xilinx thing with a few hundred pages on how to easily import it again :O)

Is all that can be done with it a blinky LED, letter by letter on a command line ?
And does it take a FPGA to make it blink ?

It all seems to be a waste of time.

Best regards
Werner

Ups that is simultanious...
I came across this hardware floating versus software.
Hundreds of hits at google, all leading to a dead end with no answers finally.
At one point cross compiling failed with *hf, can’t remember which constellation.
File not found …
Just found it, some sources ECLIPSE is doing that :
/lib/ld-linux-armhf.so.3: No such file or Directory
Just putting it there raises new errors ..

I will check out your link, but I only got WINDOWS 7 prof 64bit.

Hello Pavel,

I am not a native C-person, but might get around with some help from a good IDE.
With TTY “gedit” and a command line “gcc” I will be lost. Disastrous trial and error …
I cannot imagine the C-part of the coding is always done like that and I wonder why none of the guidance leads to anything functional.

I have got the strange feeling, some things can be seen UDP on the C&C at EP2 but they just don’t get passed out the Red Pitaya the right way …
Now it is hard to trace and impossible to debug :O(
I am also missing the heart beat of the round robbing at EP2.
My system is HAMLAB alike, used both worlds and needs to know if openHPSDR is powered or off, up and running or down.

Best regards
Werner

Hallo,
gibt es irgendeine probate Möglichkeit den C-Code “sdr_transceiver_hpsdr“ zu ändern ?
Ich habe nun >> 100 Stunden lang versucht irgendeine IDE, SDK, (nenn es wie du willst) zum Laufen zu bekommen.
Google glüht noch …
Alle Anleitungen münden in ein heilloses Durcheinander.
Möglicherweise könnte ich nun die FPGA verhunzen, das will ich aber nicht.

Mit ECLIPSE komme ich noch am weitesten.
Ich kann das ändern und kompilieren, kann den RedPitaya einbinden, kann es jedoch nicht debuggen.
„Could not determine GDB version using command: /opt/Xilinx/SDK/2017.2/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/runtest –version Unexpected output format: ERROR: unable to find expect in the PATH“

Für Vivado wird immer das FPGA Design erklärt ?
Schließlich habe ich HLS „entdeckt“, im „richtigen“ Programm kann ich es aber nicht kompilieren
und somit auch nicht simulieren ( was mir am liebsten wäre )
Einige "includes" werden nicht aufgelöst ? Der "cross Compiler" geht ?
Ich kenne mich ein wenig mit IDEs(SDK) aus, IAR, KEIL, AVR Studio(VisualStudio), finde meinen Weg.
Ich frage mich was die Leute bei Vivado rauchen, so ein Sch.. G(U)I ohne User. 30GB bullshiut

Hat / kennt jemand eine funktionierende Lösung ?
Meinetwegen auch gerne WINDOWS , damit hatte ich aber die ärgsten Probleme.
OS spezifisch …

ORACLE Virtual Box
Version 5.2.8 r121009 (Qt5.6.2)

LINUX UNBUNTU 16.04

Eclipse IDE for C/C++ Developers
Version: Oxygen.2 Release (4.7.2)

Xilinx Vivado 2017.2 HL,HLS und SDK

Wozu ?
Ich möchte zurück auf den kleinsten gemeinsamen Nenner.
Ich möchte auf den EP2 des METIS Protokoll aufsetzen.
Bis hier wäre alles gleich und somit wäre es auch Wurst welches SDR PC Programm benutzt wird.
Was der RedPitaya nicht selbst verwirklicht sollte die angeschlossene Hardware sich selbst decodieren.

Grüße
Werner

<Key>chkRX2StepAtt</Key>
<Value>True</Value>
</Options>
<Options>
<Key>udHermesStepAttenuatorData</Key>
<Value>0</Value>
</Options>
<Options>
<Key>chkHermesStepAttenuator</Key>
<Value>True</Value>

Thank you Pavel,

that does show a step attenuator control for RX2 as well.
This way both base lines are independent.
Before both were controlled by the step attenuator of RX1.

But… it has to be “ANAN 100D” or so The attenuator for RX1 goes 0..31 and 2..31 plus hidden 0+0dB and 10+20dB
61 different steps displayed / 5 different values are accessible 2, 4, 6 & b00 or b11
The step attenuator for RX2 goes 0..31
31 different steps displayed / 4 different values are transferred 0, 14, 22, 30

As long as PCA92555s at 0x20..0x23 are active the Arduino at 0x40 is not served.
The Arduino would do most of the trick, but I’m afraid the rest of it is too special for third party PC, tablet, and smart phone software.

I didn’t succeed to activate the 12 Bit of the DC2PD pre-amps(s) at 0x60-0x61 yet.
How would that work and what does the control look like ?

Best regards
Werner

P.S.

Ich denke steuerbare, variable RX Abschwächer sind die Voraussetzung für „Auto Attenuate“ bei PureSignal.
Noch bin ich sehr weit entfernt vom Sendebetrieb, ich höre viel zu und oft ist das Thema:
Signalrückführung ( zum RX2 beim RedPitaya ). Oft klingt es wie endlose Stapel von sündhaft teuren SMA Abschwächern, kleinen Dosen mit Potentiometern, Rätselraten um Pegel und „Sampler“.
Manchmal klingt es wie mangelhafte Isolation zwischen den Eingängen IN1 und IN2,
ebenso oft wie mangelhafte Einstrahlfestigkeit direkt in den ungeschirmten RedPitaya.
Jetzt habe ich leicht Reden, rein theoretisch …

I believe controllable, variable RX attenuators are essential for the „Auto Attenuate“ function of PureSignal.
I’m light years away from transmitting with a RedPitaya, but I listen to many QSOs about signal feed back ( to RX2 for RedPitaya ).
Mysteries about signal level, stacks of attenuators and potentiometers.
Often it feels like insufficient cross talk IN1 <> IN2, quiet as often like direct reception of unscreened RedPitayas,
bypassing all the expensive SMA attenuators. But that’s all theory …

Google “auto attenuate puresignal” liefert eigentlich die Erklärung, für Hardware die wir nicht haben.
The default with ANANs and others … ?

P.S.P.S.

Ich habe den DAC0 gefunden. Es geht wenn außer ihm nur noch die AudioCodec Platine auf dem I²C Bus anwesend ist.
Andere Adressen dürfen scheinbar nicht antworten. DAC1 bleibt verschollen.

I did find the DAC0. It looks like no other address but the audio codec board is allowed to answer / be present.
DAC1 still doesn't happen ..
It does not matter if Hermes or ANAN or ... A week later ..

P.S. P.S. P.S.
Meanwhile I would favour the Arduino Sketch of G8NJJ.
It has got the fewest things I don't seem to understand.
May be I've got some kind of an idea how
HPSDR<>RedPitaya's HPSDR compatible transceiver software<>hardware connected to the RedPitaya is communicating ...
The G8NJJ project is documented very well and for sure it is done very well ...
but I will start with a light version, using his protocol for the standard functions.
It contains anything like all others plus offers endless possibilities.
To start with is fine, to change to is hard.
It counts as well 0..61 in disjunctive steps.
A bug in HPSDR? A bug in the skin definition? There is more than 5 bits ? C0=0x14 HPSDR packet is 8 bit RX1 attenuation ?
It does treat the "Step Attenuator" for RX2 properly.
... but it looses the value after transmitting. Either two times #6 with first value OK. Or just one time and wrong.
Not synchronized with the skin and base line anymore.

Mit einem Arduino und BASCOM kann man den I²C Bus auf einem Terminal visualisieren.
Ich benutze das Terminalprogramm TerraTec. Die BASCOM eigene Terminallösung reagiert nicht immer ( je nach Fokuserhalt der WINDOWS Fenster ).
Der Arduino nimmt hierbei den Platz des(r) I²C Geräte(s) ein.


Das Programm besteht aus Fragmenten (m)einer I²C Sammlung.
Der Ardunio ist ein NANO3.0 Chinakracher. Die gibt es unter 3 Euro das Stück.
Das 5Volt Gerät kann man nicht direkt an den Red Pitatya anschliessen.
Man benötigt einen Pegelwandler für SDA und SCL ( 3,3 <> 5 Volt )
Mangels Masse habe ich meinen Clone auf 3,3 Volt umgebaut…
Er ist nun mit 3,3 Volt / 16MHz übertaktet, läuft aber klaglos.
Es benutzt Hardware TWI, der Prozessortakt spielt eigentlich keine Rolle.

Meinem Wunsch Eingangsabschwächer aus dem GUI mit funktionierender Hardware abzubilden bin ich nun näher gekommen. Ohne jetzt nach einer weiteren Version / Abart / Einzellösung für die RedPitaya SDR Software zu rufen / suchen.

Die Erste Hürde war:
Der RedPitaya wird im Netzwerk unerreichbar, wenn bei seinem Neustart ein „unverseller“ I2C Gesprächspartner ( mein Arduino siehe oben ) verfügbar ist. Er ( irgendwas im Linux ) sendet eine Reihe Kommandos an eine I2C Adresse und möchte eine Antwort. Meldet der I2C Bus „vorhanden“ und das vermeintliche Gerät antwortet dann nicht sinnvoll, dann hängt er. Bei "TX?" wurde SLA-W gesendet. Ich weiß nicht was antworten, 'weiß nicht wer fragt :O)

Schritt 1,5.
Die Abfrage, das Pollen der SDR I2C Geräte auf Vorhandensein findet beim Start der RedPitaya SDR Software statt, das ist OK. Es reicht eben nicht nur die PC Software neu zu starten, nicht bei allen Geräten.

Zweitens behaupte ich jetzt einmal einen „ANAN 100D“ zu haben. Ohne genau zu wissen was das ist. Mit „Hermes Step Attenuator“ gibt es auf 0x64 drei Bytes:
Ein Kommando(?) „6“ und für RX1 2 x 31 Schritte, für RX2 die Werte 0-10-20-30. Das zweite Byte gilt es dann wohl mit dem 10er und 20er = 30 ( 0-31 und 32-61 ) für RX1 zu verknüpfen. Die „DC2PD“ 0x60 und 0x61 wurden noch nie adressiert (?).
Was müsste man „vortäuschen“ , damit sie aktiv werden ?
Das sollte kontinuierliche Werte geben ? Auch für RX2 auf 0x61 ?

73 Werner