Posts by DL8MBY

    Hallo OMs,


    die ersten Schritte sind wie immer erwas Mühsam.


    Verstehe ich das soweit richtig, dass der RP im FPGA bereits vorkonfigurierte
    Funktionsblöcke beinhaltet, auf die man dan z.B. über Libs / Header-Files
    zugreifen kann.


    z.B. Arbitrary Waveform Generator (AWG) FPGA controller als Funktionsblock
    kann über die Files fpga_awg.h / fpga_awg.c angesprochen werden.


    Solange der FPGA nicht neu mit Strukturanweisungen gefüllt wird, wozu man ja die
    Xilinx-Tools braucht, kann man auf diese vorkonfigurierten Strukturen, die im
    Auslieferungszustand vorhanden sing, zugreifen.


    Für heute genug gespielt - Jetzt gehts ins Bett ;)


    Morgen ist ja auch noch ein Tag.


    Markus

    Hallo Uwe,


    ich schon wieder,


    habe halt RP Blut geleckt ;)


    ist das der Code in dem Du eine LTU für den Sin/Cos aufbaust
    um sie dann an den Kanal A/B zu schicken?


    for(uint32_t i = 0; i < n; i++) {
    data = round(amp1 * cos(2*M_PI*(double)i/(double)n));
    if (data < 0) {
    data += (1 << 14);
    }

    g_awg_cha_mem[i] = data;

    data = round(amp2 * cos(2*M_PI*(double)((phase_offset + i) % n)/(double)n));
    if (data < 0) {
    data += (1 << 14);
    }

    g_awg_chb_mem[i] = data;


    Anscheinend braucht man diese _agw_ Funktionen um mit dem Konfiguriertem FPGA zu kommunizieren.


    Wo kann man sich über die Aufrufe


    g_awg_reg->state_machine_conf = 0x000041;


    und


    g_awg_reg->state_machine_conf = 0x110011;


    schlau machen, wie sind die Flags zu intepretieren.



    Markus


    Konnte meine Frage selbst beantworten:


    uint32_t state_machine_conf;
    /** @brief Offset 0x04 - Channel A amplitude scale and offset
    *
    * Channel A amplitude scale and offset register (offset 0x04) used to set the
    * amplitude and scale of output signal: out = (data * scale)/0x2000 + offset
    * bits [31:30] - Reserved
    * bits [29:16] - Amplitude offset
    * bits [15:14] - Reserved
    * bits [13: 0] - Amplitude scale (0x2000 == multiply by 1, unsigned)
    */


    aus fpga_awg.h

    Hallo Uwe,


    einen habe ich noch ;)


    Ich verstehe folgenden Zusammenhang nicht:
    In der ersten if-Anweisung wird dafür gesorgt, dass der
    Phasenparameter zwischen -1799 und + 1800 liegt,
    sonst wird der Programmablauf unterbrohen.
    In der Zugehörigen else-Anweisung wird der Phasenwert
    Modulo 3600 geteilt, aber der Rest ist ja immer gleich dem
    ursprünglichem Wert des Phasenparameters, da dieser
    doch immer kleiner 1800 ist.


    Kannst Du mir erklären was Du mit der Modulo 3600 Division
    bezweckst. Irgend wie stehe ich auf dem Schlauch, was diese
    Codesequenz angeht.


    /* Phase Offset */
    int32_t phase_offset = atoi(argv[2]);
    if ((phase_offset < -1799) || (phase_offset > 1800)) { <============= 1.
    fprintf(stderr, "Invalid phase shift: %s\n", argv[2]);
    usage();


    return -1;


    } else {
    phase_offset = phase_offset % 3600; <============== 2.
    if (phase_offset < 0) {
    phase_offset += 3600;
    }


    /* scale it to match AWG buffer length */
    phase_offset = n * phase_offset / 3600;


    }



    Danke für Deine Mühe schon mal im Vorraus.


    Gruß
    Markus

    Hallo Uwe,


    wie sind die Werte


    const int dcoffs = -155;
    const int trans0 = 30;
    const int trans1 = 300;


    aus der iq.c Datei zu verstehen.


    Hast Du diese empirisch ermittelt für Deinen RP?


    Bei mir liefert ein erneuter Aufruf mit +950 oder -850 als Parameter
    für die Phase einen kreisrunden Kreis.


    Sieht aus, alls wenn nach dem erstmalliegem Start, irgend ein Offset von
    50 in Phasen Buffer dazukommen würde.


    Gruß
    Markus
    DL8MBY

    Hallo Wolfgang, Uwe und OMs,


    Ich habe einige Sereenshots zum IQ-Gen vom Uwe angehängt.
    Mir ist aufgefallen, dass ein XY-Darstellung nicht immer den selben
    Wert liefert.


    z.B.


    nach dem Einschalten des RP


    Bild #1: (Punkt in der Bildmitte, da kein Signal am DAC)


    Bild #2: (schöner Kreis bei dem Aufruf von iqgen mit folgenden Parametern)


    ./iq 1.0e6 -900 +0.0 +0.0


    Bild #3: (Nun Phase nicht um 90° sondern um 45° verschoben - Aufruf von iqgen mit folgenden Parametern)


    ./iq 1.0e6 -450 +0.0 +0.0


    Bild #4: (nun wieder den verhergehenden Zustand wieder herstellen d.h. Phase um 90° verschoben)


    ./iq 1.0e6 -900 +0.0 +0.0


    Leider liefert diese erneute Einstellung keinen unverzehrten Kreis mehr.



    Was meinst Du Uwe dazu?



    Wolfgang,


    um eine Partition einer SD-Karte unter Linux zu vergrößern, gehst Du bitte wie folgt vor.



    Partitionstabelle des Karten-Image mit fdisk -l /dev/<SD-Karten-Name> betrachten


    Bei mir ist <SD-Karten-Name> z.B. mmcblck0, könnte aber auch sdb oder sdc sein,
    je nach Anzahl der verbauten Disks im Rechner.


    Hilfreich ist der Befehl lsscsi und auch lsusb, der angeschlossene Devices zeigt.


    Bei meinem RP liefert fdisk -l die folgende Ausgabe



    root@red-pitaya:/home/sdr/iqgen# fdisk -l /dev/mmcblk0


    Disk /dev/mmcblk0: 14.9 GiB, 15931539456 bytes, 31116288 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disklabel type: dos
    Disk identifier: 0x0004085a


    Device Boot Start End Sectors Size Id Type
    /dev/mmcblk0p1 8192 30719 22528 11M e W95 FAT16 (LBA)
    /dev/mmcblk0p2 30720 31116287 31085568 14.8G 83 Linux


    Dies ist aber bereits die Ausgabe für meine vergrößerte Partition mmcblk0p2.


    Wenn Du das Original-Image auf die SD-Karte mit dd übertragen hast und der Aufbau
    wie folgt ist:


    /dev/mmcblk0p1 8192 30719 22528 11M e W95 FAT16 (LBA)
    /dev/mmcblk0p2 30720 XXXXXX YYYYYY ZZ.8G 83 Linux


    und du willst die letzte Partition vergroßern, so musst Du:


    1) mit fdisk die Partition #2 löschen
    2) mit fdisk die Partition #2 neu Anlegen (primär Partition)
    2a) als Startwert der Partition #2 den Endwert der Partition #1 + 1 angeben
    hier ist es der Wert 30720 = 30719 + 1
    2b) den Endwert der Partition #2 als letzten größtmöglichen Wert der SD-Karte nehmen.
    Diesen Wert ermittelt man am besten vor dem Draufspielen des Images mit fdisk -l /dev/...
    3) die neu angelegte Partition durch Speichern permanent machen.


    Die einzelnen Kommandos lauten unter fdisk:


    1) fdisk /dev/mmcblk0 (diesmal ohne -l für list d.h. nur ansehen und nichts modifizieren)
    2) <p> <== Partitionstabelle erneut zeigen
    3) <d> Partition
    3) <2> #2 löschen
    4) <n> neue partition anlegen
    5) <p> eine primäre Partition als Type wehlen
    6) ... Start und Stop Block setzen
    7) <p> Partitionstabelle nochmal ansehen und auf Fehler (Überlappungen) prüfen
    8a) <q> quit, ohne speichern raus - wenn nötig
    8b) <w> veränderte Partitionstabelle schreiben.
    8c) <q> program verlassen.


    Hoffe keinen Schritt vergessen zu haben - war aus dem Gedächtnis.


    Bevor man Punkt 1 - 8 durchführt muss man sicherstellen, das beim Einstecken der
    SD-Karte diese nicht sofort vom System eingebunden wurde (mount Befehl)
    Falls man einen Eintrag wie


    /dev/mmcblk0p1 on xyz
    /dev/mmcblk0p2 on xyz


    findet,
    diesen mit umount /dev/mmcblk0p1 oder/und umount /dev/mmcblk0p2 aushängen.


    Alles als root user!!!


    Jetzt muss man nur noch das Filesystem der zweiten Partition mit fsck analysieren


    fsck -f /dev/mmcblk0p2


    und dann den Resize-Vorgang anstoßen:


    resize2fs /dev/mmcblk0p2


    geschafft - und ich auch ;)


    Gruß
    Markus

    Hallo Uwe,


    ich habe noch ein Zweiton-Signal, vom Notebook, siehe Bild, an Eingang 1 angelegt.
    800Hz + 1200Hz.


    Gruß
    Markus


    PS.:


    Bei mir sind es ebenfalls 75°C


    root@red-pitaya:~# monitor -ams
    #ID Desc Raw Val
    0 Temp(0C-85C) b07 74.279
    1 AI0(0-3.5V) a 0.017
    2 AI1(0-3.5V) 12 0.031
    3 AI2(0-3.5V) 9 0.015
    4 AI3(0-3.5V) a 0.017
    5 AI4(5V0) 67f 4.964
    6 VCCPINT(1V0) 56a 1.015
    7 VCCPAUX(1V8) 9b3 1.819
    8 VCCBRAM(1V0) 56a 1.015
    9 VCCINT(1V0) 56c 1.017
    10 VCCAUX(1V8) 9ad 1.815
    11 VCCDDR(1V5) 802 1.502
    12 AO0(0-1.8V) f0000 0.173
    13 AO1(0-1.8V) 4e0000 0.900
    14 AO2(0-1.8V) 750000 1.350
    15 AO3(0-1.8V) 9c0000 1.800

    Hallo Uwe,


    richtig, habe noch keinen Lüfter dran.
    Mir ist aber auch aufgefallen, dass der Chip recht heiß wird.


    Ich sätze aber dass man den Lüfter extern versorgen muss
    (12V) um keine Störungen Onboard einzustrahlen.


    Alternativ könnte man einen höheren Kühlkörper nehmen.
    Scheint ein standart Fabrikat zu sein.


    Muss mal meine alten Mainboards und Graphikkarten durchsehen,
    ob da nicht ein ähnlicher verbaut ist.


    Da der FA-VA3 erst ab 50KHz läuft, habe ich Dir nur ein Abbild
    von dieser Frequenz angehängt.


    Wie schon nachgefragt, sind auch in meiner Darstellung des Spektrums
    störende Linien zu sehen.


    Muss mal in der Arbeit am Spektrumanalyzer nachmessen, ob der VA oder der
    RP diese Linien erzeugt.


    Markus

    Hallo OMs,


    ein kleiner Nachtrag zum RP.


    Benutzung des Webinterfaces ermöglicht z.B. die Auswahl eines
    Spectrumanalyzers - was Ihr bestimmt schon bereits kennt.


    Ich habe diesem Eingang #1 zweimal das Signal (20MHz)
    eines FA-VA3 angeboten. Einmal mit vorgeschaltetem 10dB
    ATT und einmal direkt 1:1 - so zum testen.


    Siehe die angehängten Jpg-Files.


    Jetzt wird aber ausgiebig gespielt ;)


    Gruß
    Markus


    War natürlich Schmart mit den 10dB ATT - waren 30dB Dämpfung!

    Hallo Uwe,


    die erstinstallation war soweit erfolgreich. 20Min. samt Download vom Image.


    ich habe bei mir die IP statisch eingestellt, damit ich keinen DHCP server aufsetzen muss.


    Geht durch Modifikation der eth0 Datei im Verzeichnis


    /etc/network/interfaces.d auf der zweiten Partition der SD-Karte /dev/mmcblk0p2


    Ersetzt wurde erste und einzige Zeile



    iface eth0 inet dhcp


    durch


    z.B.


    auto eth0
    iface eth0 inet static
    address 192.0.1.7
    netmask 255.255.255.0
    gateway 192.0.1.254



    Dies kann man sofort nach der erstellung des SD-Images machen, noch bevor
    man die SD-Karte in den RP steckt. Dadurch ist der RP sofort auf der gesetzten
    IP via ssh ansprechbar:


    ssh root@192.0.1.7 (pw changeme)



    Anbei meine Status-Infos vom laufenden Debian auf dem RP.


    root@red-pitaya:~# df -h
    Filesystem Size Used Avail Use% Mounted on
    /dev/root 15G 503M 14G 4% /
    devtmpfs 226M 0 226M 0% /dev
    tmpfs 234M 0 234M 0% /dev/shm
    tmpfs 234M 4.3M 230M 2% /run
    tmpfs 5.0M 0 5.0M 0% /run/lock
    tmpfs 234M 0 234M 0% /sys/fs/cgroup
    /dev/mmcblk0p1 11M 6.3M 4.8M 57% /boot
    root@red-pitaya:~# cat /proc/cpuinfo
    processor : 0
    model name : ARMv7 Processor rev 0 (v7l)
    Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
    CPU implementer : 0x41
    CPU architecture: 7
    CPU variant : 0x3
    CPU part : 0xc09
    CPU revision : 0


    processor : 1
    model name : ARMv7 Processor rev 0 (v7l)
    Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
    CPU implementer : 0x41
    CPU architecture: 7
    CPU variant : 0x3
    CPU part : 0xc09
    CPU revision : 0


    Hardware : Xilinx Zynq Platform
    Revision : 0003
    Serial : 0000000000000000



    Ich hoffe die Infos helfen weiteren RP Enthusiasten, wie mir die Infos von
    Uwe geholfen haben und binnen Minuten zu einem lauffähigem System geführt
    haben.


    Nochmals verbindlichten Dank Uwe!


    vy73
    Markus
    DL8MBY

    Hallo Uwe,
    hallo OMs,


    halte gerade auch die schnuckelige RP Platine in meinen händen.
    Kann mir einer auf die Schnelle sagen, wie man den Code compiliert
    und in den Arm lädt.


    Grundlagen in C und Linux sind vorhanden, es geht mir rein um die RP
    spezifischen Tools und ihr Handling.



    Wollte mir das durchforsten der Doku sparen und ein Erfolgserlebnis
    sehen, bevor ich mich mehr in die Tiefe der Materie einarbeite.


    Als bitte um Nachsicht.



    Danke!


    Markus
    DL8MBY

    Hallo OM's,


    war am WE unterwegs, konnte mich deshalb an der regen Diskission nicht beteiligen.


    Zu den Messungen ist folgendes zu sagen:


    Es wurde am TX der konstante Träger (Mode CM) ohne Tastung am 30dB Dämpfungsglied
    mit einem Advantest 3131 Spektrumanalyzer gemessen.


    Dabei stellte sich heraus, dass die Oberwellen meist 53dB unterhalb des Trägers waren.
    Ausnahme 10 und 14 MHz Band 43dB und 48 dB Abstand zum Träger.


    Bei Modulation des Trägers mit Fonie aber auch CW-Tastung entstanden die bereits erwähnten
    Nebenaussendungen, die relativ breitbandig (+- 50 kHz) sind und bis auf 30dB in der Spitze an
    den Träger herranreichen.


    Wir haben aus Zeitgründen und Mangels eines USB-Sticks keine Screendumps gemacht, werden
    dies aber noch nachholen.


    Es wurde keine Zweitonmessung weder am RX noch am TX durchgeführt - Dazu suchen wir noch
    eine Möglichkeit im OV od. bei befreundeten OMs. Möglicherweise kann Norbert - DJ9RB - dies
    demnächst untersuchen.


    Beim RX haben wir nicht nur S9 zu S2 Signale im 4kHz Abstand verglichen, sondern auch S9+40
    mit S2 - der Abstand betrug 14kHz. Gemessen wurde der Pegel des leisen Signals mit mV-Meter
    und Oszi beim Ein-und Abschalten des starken Störträgers.



    Zuvor hatten wir noch, wie bereits beschrieben, die Empfindlichkeiten mit und ohne PRE und ATT
    gemessen. (Siehe meinen erster Beitrag.)



    Wie bereits erwähnt, wollen wir noch Messungen bei externer Tastung (Palm-Keyer) am Träger machen,
    um zu sehen ob dort auch die Nebenaussendungen erkennbar sind.
    Unser Verdacht ist nämlich, dass der uC wohlmöglich den TX zu steil Tastet und ein RC Glied an der
    Nahtstelle die Probleme beheben würde.


    Werde im Urlaub, mitte August, mehr Zeit zum Spielen mit dem Gerät haben und berichten.



    vy73
    Markus
    DL8MBY

    Hallo Peter, hallo OMs,


    gemeint war, dass der TRX z.Z. nicht zur Ansteuerung einer PA geeignet ist, die z.B. 750W HF macht.
    Rudi wollte sich sein solches Gerät zulegen, um in seinem Shack etwas Platz zu schaffen.
    Davon habe ich Ihm nach jetzigem Erkenntnisstand abgeraten, wegen der besagten Messwerte.
    Auf der HAM-Radio, hatten wir diesen Messmöglichkeit nicht, sondern erst im QRL.
    Wir konnten das Gerät nur an der Logperiodic und der Vertikal nur subjektiv und mittels Web-SDR
    testen.


    Da der reine Träger sehr gut aussieht, glaube ich nicht, dass es an der Hardware liegt, sondern an der
    Firmware - meine persönliche Meinung.


    Ich habe gerade mit den mir zur Verfügung stehenden Messmöglichkeiten am QTH die Filter des Gerätes
    durchgesweept und hänge die Screenshots an.


    Gemessen habe ich im 40m Band.
    RX ohne PRE und ATT.
    Generatorsignal am RX (FA-NWT) mit eingeschaltetem Dämpfungsglied (44dB)
    Messeingang mit 30dB auf den der Audioausgang des RX gelegt ist (halbe Lautstärke)
    AGC aus.


    Werte wurden so gewählt, damit eine gute rauschfreie Grundlinie entsteht.

    Weitere Messungen folgen.


    Ich hoffe mich nun etwas klarer ausgedrückt zu haben.


    vy73
    Markus
    DL8MBY

    Hallo Markus,


    bin ganz Deiner Meinung, zumal ja vieles an Technik aus dem Smartphonebereich verwendet werden kann.


    Leider hat dieser Trend auch seine Schattenseiten, die auch auf unserem Arbeitsmarkt ihre Spuren hinterlassen werden.


    vy73
    Markus
    DL8MBY

    Hallo OM's


    kaum ist die HAM-Radio vorbei, hat man wieder ein neues Spielzeug.
    In meinem Fall einen QRP TRX (1-20W HF) des chinesischen Herstellers
    XIEGU mit dem Modellnamen X108G (angeboten zum Messe-Preis von 499€).


    Für dieses Gerät gibt es bereits einige Beiträge im Netz mit unterschiedlicher
    Resonanz.


    Das Handbuch zum Gerät findet Ihr z.B. unter:


    http://www.wouxun.us/Manuals/X…anual_English_%20Rev1.pdf


    Das ist wohl noch die Vorgänger Version, die dort beschrieben wird.


    Mein Gerät hat auf der Rückseite eine mini-USB Buchse und einen zweipoligen
    weißen DC-Anschluß (nicht schwarz und nicht vier polig!)


    Beim Einschalten und dem Halten von F1 (oberster Funktionsknopf) kommt man
    ins Konfigurationsmenu. Beim Drücken des VFO-Knopfs während des Einschaltens
    kommt man ins Firmware-Update Menu.



    Zum Gerät ist folgendes zu sagen.


    Es ist ein single conversion TRX mit einer einzigen ZF von ca. 10.7 MHz.
    Schaltbare Bandfilter am Frontend machen den RX sehr robust.
    Es werkelt ein leistungsfähiger ARM (ST32F4..) MC im Inneren des Gerätes.


    Mein subjektiver Eindruck vom Gerät lautet:



    RX: Guter Empfang, (-95dBm mit ATT, -105dBm ohne PRE-Amp, -120dBm mit PRE-Amp)


    Ein S9 Signal in 4kHz Abstand im Mod CW bügelt ein S2 Signal nicht nieder (sehr beindruckend!)


    TX: Sehr stabiler und sauberer Träger bis auf das 30m Band (-43dB) waren alle Oberwellen
    mindestens -53dB unterdrückt bei 20W HF am Ausgang ohne Modulation (Labormessung an der Dummy)


    Die Probleme die der TX noch hat sind Nebenaussendungen in SSB und CW, die etwa nur 30-35 dB neben
    dem getasteten oder SSB moduliertem Träger liegen (Somit nicht PA tauglich).


    Unabhängig von der Sendeleistung (bis 20W HF gemessen) und der Tastung mit dem internen Keyer von
    1 bis 40 WpM.


    Möglicherweise sind die ZF-Filter aus einzelnen Quarzen noch im Sperrbereich zu breit.


    Betrieben wurde der TRX an einer Logperiodic auf 14 und 21 MHz und an einer Vertical auf 7MHz.
    Anwesende OMs waren Rudi (DK5FD) Norbert (DJ9RB) und bei den Messungen im Labor im QRL
    Frank (DF2ZJ).
    Aussendungen wurden via WEB-SDR und auf dem Spectrumanalyzer am Leistungs-Dämpfungsglied
    verglichen/gemessen.



    Neben der Tatsache, dass das Display sehr klein ist (eine Leselupe auf dem Display wäre hilfreich) und
    die zwar intuitive, aber nicht ganz komfortable Bedienung dem OM einiges an Geschick abverlangt,
    ist das Gerät durchaus gut konzipiert und wird sicherlich durch weitere Firmwareupdates verbessert.


    Es ist noch nicht für den Einsatz an einer großen PA einsetzbar, obwohl die Treiberleistung ausreicht,
    aber gut für SOTA-, Camping- und Urlaubs-Einsetze geeignet.


    Es zeigt das man die aufstrebende China Industrie auch im HAM-Bereich nicht mehr unterschätzen und
    belächeln darf.


    Hoffe das einige von Euch die Möglichkeit haben auch den TRX zu testen, und bin auf Eure Meinung und
    Erfahrung gespannt.



    In diesem Sinne


    vy73
    Markus
    DL8MBY


    PS: Anbei noch einige Bilder zum Inrernen Aufbau - Sind nicht von meinem Gerät!

    Hallo Chris,


    danke für den Hinweis, dieser könnte zum Erfolg führen.
    Werde mal den OM via Mail kontaktieren.
    Zumindest ist jetzt von Dir bestärigt, das es sich wirklich um einen
    VCO im GHz Bereich handelt.


    Ich hoffe, das er nicht via I2C oder SPI programmiert wird, wie von
    nanchen OMs hier vermutet.


    vy73


    Markus
    DL8MBY

    Hallo Michael,


    laut Verkäufer in Ebay handelt es sich um einen 1.2GHz VCO.
    Diese Aussage ist natürlich mit Vorbehalt zu sehen, aber das
    Teil sieht rein außerlich so wie manche VCOs aus.


    Möglicherweise handelt es sich um eine kundenspezifische Anfertigung.


    Wahrscheinlich muss ich doch einen schlachten, um heraus zu
    bekommen wie es beschaltet werden muß.


    vy73
    Markus
    DL8MBY