Spiele mich seit einigen Tagen mit der FW auf github
für den uSDX+ (white buttons, Ver. 4.00e)
Nachdem es mit gelungen ist die FW in der Arduino IDE
(2.3.9) zur compilieren und auf das Gerät zu laden wollte
ich mir die CW Aussendung mal am Oszi anschauen.
Dabei habe ich den unschönen Anfangs-Spike beim Start der
Aussendung beobachtet und wollte den reduzieren, siehe Anhang.
Leider ist mir ein besseres CW Shaping noch nicht gelungen.
Im .ino Code spielt sich die Sache offensichtlich im Zeilen-
Bereich an/ab Position 2870++.
Mir scheint aber , dass die HF Formung erst nach ca. 1,5ms
tatsächlich von diesen Code beeinflusst wird, wo hingegen
der Anfangs-Spike aus der Initialisierung der Si5351 herrührt.
Ich habe keinen Parameter in der laufenden FW wie auch kein
#define im Code gefunden, der mir da weiter hilft, bin aber
auch kein Experte was AVR und Arduino angeht.
Leider habe ich mit dieser Frage auch kein Erfolg in dem ucx
Forum von https://groups.io gehabt, da meine Postings trotz
gültiger Anmeldung in diesem Forum immer ins Leere laufen und
Emails an die Mods auch nicht beantwortet wurden.
Hatte mich am Rande mit dem uSDX beschäftigt, genauer mit der Qualität der SSB-Signalerzeugung. Stecke nicht tief drin, mit Arduino hatte ich nur mal ein PoC aufgebaut.
Trotzdem: ich denke auch, du hast die richtige Stelle im Code für die CW-Rampe gefunden. Das trotzdem ein Click entsteht liegt wohl am falschen Timing.
Damit der Empfänger von der Antenne getrennt wird und der SI5351-Takt die Endstufe erreicht, muss PB0 auf low schalten. Eine weitere Sendebedingung ist ein aktivierter SI5351-Takt.
Damit kein Glitch entsteht, muss früh genug das Output-Compare Register OCR1BL auf 0 stehen, damit über PB2 und Q5 die Endstufe Q2/Q3/Q4 keinen Takt erhält. Früh genug heißt incl Integrationszeit R28/C23, 0,5ms vor PB2 oder CLK2 sollten genügen wenn der im Netz ausgegrabene Stromlaufplan mit deinem Gerät übereinstimmt.
Um die Sache einzugrenzen, könntest Du PB0 und PB2 auf dem Oszi mitschneiden. Hast du noch ein Kanal frei, auch CLK2 vom SI5351.
Außerdem den Schalter #ifdef KEY_CLICK anschauen.
Weitere Codestellen: Zeile 4976
1
#ifdef KEY_CLICK
2
if(OCR1BL!=0){
3
for(uint16_ti=0;i!=31;i++){// ramp down of amplitude: soft falling edge to prevent key clicks
Ich habe die Variante, die keinen vierten BS170 zum Schalten der drei PA FETs verwenden.
siehe Anhang. Signal kommt direkt über PB2 und ein RC-Glied als PA-BIAS als geglättete
PWM an das Gate der drei FETs und von einem Gate als Buffer vom Si5351.
PB0 ist zum RX Muten und so glaube ich hat es keinen Einfluß auf das CW HF Signal am Ant.
Ausgang.
Die von Dir genannten Code-Stellen habe ich mir bereits angesehen und habe auch mit dem
OCR1B1 gespielt, der alle Werte der LUT annehmen kann.
Die diversen Codestellen mit den
for (uint16_t i = 31; i != 0; i--) { // soft rising slope against key-clicks
OCR1BL = lut[pgm_read_byte_near(ramp[i])];
delayMicroseconds(60);
}
die die Rampe rauf und runter, je nachdem in welcher Richtung die LUT durchlaufen wird,
formen, setzen alle erst viel später an (ca. 1.5ms) nachdem die erste HF am Ant.-Ausgang
erscheint.
Deswegen vermute ich, dass bei der Initialisierung beim Wechsel von RX zu TX der Spike
erzeugt wird und eine andere Ursache hat.
Ist halt etwas lästig jedes mal wieder neu zu Flashen, um die Modifikationen im Code
in ihrer Wirkung am Oszi zu sehen.
Werde weiter mehr den Code durchforsten und hoffe die entsprechende Stelle zu finden.
Du hast die OCX-Variante gepostet, auch mit viertem BS170.
Aber gut, wenn PB0 nicht mit dem Takt CLK2 verriegelt ist, fällt der Portpin als Ursache raus. Der schützt dann tatsächlich nur den Empfängereingang.
Bleibe aber dabei, mindestens 0,5ms vor dem Umschalten auf TX muss PB2 / OCR1BL auf 0 sein. Das passiert offensichtlich nicht. Die Umschaltung auf TX scheint ab Zeile 4924 implementiert. RX ist PB0. si5351.SendRegister(SI_CLK_OE, TX1RX0) schaltet den Takt ein.
Arduino ist wegen fehlender Tracemöglichkeit bei größeren Sachen äußerst nervig, ist mir schleierhaft warum die Entwickler so einen zeitkritischen Code darin umgesetzt haben.
1
if(tx_enable)
2
{
3
// TX
4
5
if(practice){
6
fastdigitalWrite(RX,LOW);// TX (disable RX)
7
lcd.setCursor(15,1);lcd.print('P');
8
si5351.SendRegister(SI_CLK_OE,TX0RX0);// Do not enable PWM (KEY_OUT), do not enable CLK2 - DISABLE CLK2 which is the TX PA gate clock
9
}
10
else
11
{
12
fastdigitalWrite(RX,LOW);// TX (disable RX)
13
14
// GW8RDI Note: Enable TX before setting PLL frequency?????? todo revise
15
#ifdef NTX
16
fastdigitalWrite(NTX,LOW);// TX (enable TX)
17
#endif //NTX
18
#ifdef PTX
19
fastdigitalWrite(PTX,HIGH);// TX (enable TX)
20
#endif //PTX
21
22
lcd.setCursor(15,1);lcd.print('T');// Show Transmitting on LCD
ich habe den Eindruck, dass der SI_CLK_OE zu einem etwas späteren Zeitpunkt
gesetzt werden müsste und nicht gleich mit der Programmierung des Si5351.
Ist aber nur so ein grobes Gefühl, ohne es genau begründen zu können.
Dazu muss ich mir erst einmal die I2C Sendroutine ansehen, die die PLL mit
Werten befüllt.
Es werden zwei der drei PLL Clock-Takte für den RX-Tayloe verwendet und ein
Clock für den TX. Diese werden durch die Konstanten TX1RX0, TX0RX1, TX0RX0
und TX1RX1 entsprechend aktiviert bzw. deaktiviert, wobei mir die letzte
Konstante etwas unklar ist.
Ab Code-Pos. 518 ...
1
#ifdef TX_CLK0_CLK1
2
#ifdef F_CLK2
3
#define TX1RX0 0b11111000 // 248 (10) F8 (hex)
4
#define TX1RX1 0b11111000
5
#define TX0RX1 0b11111000
6
#define TX0RX0 0b11111011 // 251 (10) FB (hex)
7
#else //!F_CLK2
8
#define TX1RX0 0b11111100 // 252 (10) FC (hex)
9
#define TX1RX1 0b11111100
10
#define TX0RX1 0b11111100
11
#define TX0RX0 0b11111111 // 255 (10) FF (hex)
12
#endif //F_CLK2
13
#else //!TX_CLK0_CLK1
14
#define TX1RX0 0b11111011 // 251 (10) FB (hex)
15
#define TX1RX1 0b11111000 // 248 (10) F8 (hex)
16
#define TX0RX1 0b11111100 // 252 (10) FC (hex)
17
#define TX0RX0 0b11111111 // 255 (10) FF (hex)
18
#endif //TX_CLK0_CLK1
Werde also noch etwas experimentieren müssen, sofern
nicht jemand schon eine genaue Vorstellung hat, wo das
Problem liegt.
Hier würde ich zunächst zwischen dem CW-Shaping im AVR-Code und dem Einschaltverhalten des Si5351 unterscheiden. Wenn der Spike bereits vor dem eigentlichen Ramp-Code auftritt, wird eine Änderung an ramp[] vermutlich wenig bringen. Interessant wäre deshalb, an welcher Stelle dsp_tx_cw() den Si5351 aktiviert bzw. dessen Output einschaltet. Wenn du die Oszilloskop-Aufnahme und die .ino-Datei hier hochlädst, kann man die zeitliche Abfolge anhand des Codes genauer nachvollziehen und gezielt nach der Si5351-Initialisierung bzw. dem Output Enable suchen.
danke für den Hinweis. Das war bereits mein Gedanke, siehe weiter oben im Thread.
Den Code habe ich bereits als zip Datei hochgeladen, erstes Posting.
Ich habe noch einen .cpp Code nun hinzugefügt, bei dem Versuch nur den PP (Präprocessor)
Lauf des Compilers zu ermitteln um die ganzen #defines aufzulösen.
Darin sieht man auch die ganzen Funktions-Prototypen am Anfang des Listngs.
Muss an der richtigen Stelle aufgerufen werden, um den CW Träger zu aktivieren bzw. deaktivieren.
Nun muss ich nur die richtige Stelle finden ;-)
Markus
PS.:
So wird der Si5351-Takt via SI_CLK_OE=3 und TX0RX0=0b11111111 und si5351.SendRegister ein- bzw. ausgeschaltet.
if (tx == 1) { OCR1BL = 0; si5351.SendRegister(SI_CLK_OE, TX0RX0); } // disable carrier
bzw.
if (tx == 255) { si5351.SendRegister(SI_CLK_OE, TX1RX0); } // enable carrier TX1RX0=0b11111000
Wobei es noch andere TX0RX0 und TX1RX0 Konstanten ja nah #define gibt - da muss ich mich noch bei der
Si5351 Dokumentation einlesen. Siehe Posting #8093175
PS2.:
Ab Zeile 3036-3052 der .ino.cpp. Datei habe ich schon meine Versuche der Modifikation (//MW) Kommentar
eingebaut. War aber bis jetzt noch nicht erfolgreich.
Da habe ich mich noch nur auf die u.g. Funktion konzentriert.
void dsp_tx_cw()
Die verschiedenen Konstanten hinter SI_CLK_OE berücksichtigen, wenn ich es richtig verstanden habe, auch die verschiedenen Hardware-Varianten. Nicht alle nutzen CLK0 & CLK1 für den Mischer und CLK2 für den Sender.
Ich würde nicht in die SI5351-Routinen eingreifen. Sondern eher PB2 bzw. das damit verbundene OCR zurücksetzen. Vermute, dass man schon einen Teilerfolg erzielt, wenn man das zeitgleich zum Setzen von TX1RX0 (Sendetakt ein) einfügt. Aber eigentlich muss es ein paar hundert µs vorher passieren.
Dazu müsste man den zeitlichen Ablauf des Codes verstehen.
Vielleicht die Stelle finden, wo der Sendeknopf entprellt wird.
Nach dem genaueren Betrachten der usDX+ Platine ist mir
aufgefallen, dass der verbaute Si5351(B) in der MOSP10
Variante gar bein OEB-Pin herausgeführt hat.
D.h. wohl, das das Enabeln des Outputs der drei Clocks
nur via I2C passiert.
Damit wäre die Reihenfolge des Register-Beschreibens aus-
schlaggebend, wann der Clock am Output sichtbar wird.
Nach dem genaueren Betrachten der usDX+ Platine ist mir
aufgefallen, dass der verbaute Si5351(B) in der MOSP10
Variante gar kein OEB-Pin herausgeführt hat.
D.h. wohl, das das Enabeln des Outputs der drei Clocks
nur via I2C passiert.
Damit wäre die Reihenfolge des Register-Beschreibens aus-
schlaggebend, wann der Clock am Output sichtbar wird.
Markus
PS.: Warum können jetzt im Forum keine .jpg Anhänge mehr platziert werden?
So viel Angst vor den Sicherheitsrisiken beim Bildaufbau?
Beim ersten Posting gab es da keine Probleme. Ist das eine neue Policy
oder ist gerade nur irgendetwas nicht am Funktionieren?
Genau, nur dachte ich, dass man damit zwar den Takt frei gibt aber trotzdem
zwecks Synchronisation ein OE-Pin hat, wie bei den großeren Gehäusen, siehe DB.
In der AN619 zum Si5351 ist das Folgende zum OE zu finden.
Damit stellt sich bei mir die Frage, ohne richtig den .ino Code bis jetzt verstanden zu haben,
ob die OE Sequenz via I2C gleich nach dem Programmieren der PLL Freq. Register erfolgt, oder
wirklich erst gewartet wird, bis das HF Signal erscheinen soll.
Ich möchte mir jetzt an dem CW-Keyer einen Triggerpunkt setzen um am Oszi zu sehen, nach welchen
Zeitraum tatsächlich die HF am Ant.-Ausgang ansteht.
D.h. ein Kanal am PB4 und ein Kanal am Gate-Ausgang von dem Gatter von CLK2 (TX-Clock), damit ich
ein Gefühl dafür bekomme, wie viel ms tatsächlich nach einem CW-Tastendruck vergehen, bis die HF
erscheint.
Dadurch hoffe ich besser den Code zu verstehen und eher zu erkennen, an welcher Stelle was vor sich
geht.
die Bilder wurden mit einem SP gemacht, so wie immer.
Die Größe beträgt im jpg Format so um die 4-8MB (4608 × 3456 Pixel).
Diese Bilder werden dann via Gimp 3.x auf jeweils 50% der Kantenlänge
reduziert, d.h. auf ein Viertel der orig. Größe und dann ins
Forum hochgeladen. So mache ich das schon immer.
Es ist mir halt aufgefallen, dass er das jpg Format beim letztem Posting
nicht annehmen wollte (drei Bilder), weshalb ich sie nach gif konvertiert
habe. Kann aber nicht ausschließen, dass bei der jpg Erzeugung via Gimp
was schief gelaufen ist.
Werde es ja beim nächsten Versuch ja sehen. War nur etwas perplex, als es
vorhin moniert wurde. Habe mir aber da noch keine Gedanken dazu gemacht,
sondern nur das andere Bildformat gewählt, da ich den Beitrag posten wollte.
Die haben eine bessere Auflösung uns sogar Nachtsichtfähigkeit.
Bei meinem SP handelt es sich um ein simples Smart Phone.
Der Begriff SP ist durchaus geläufig.
Damit stellt sich bei mir die Frage, ohne richtig den .ino Code bis
jetzt verstanden zu haben,
ob die OE Sequenz via I2C gleich nach dem Programmieren der PLL Freq.
Register erfolgt, oder
wirklich erst gewartet wird, bis das HF Signal erscheinen soll.
Ist doch für dein Ziel egal, in welchem zeitlichen Abstand PLL gesetzt und OE gegeben wird. Du willst die Amplitude sanft hochfahren und dazu trägt der SI5351 nichts bei. Der schaltet immer hart ein und aus.
Die Rampe macht einzig der PB2 mit dem nachgeschaltetem Integrationsglied. Das OCR der PWM wird über eine LUT gefüttert, die nur die Aufgabe der Linearisierung hat. Die Leistungssteuerung der PA über das Gate-Bias ist natürlich alles andere als linear.
Ich fand im Code noch eine TX-Verzögerungsfunktion. Weiß nicht ob die aktiv ist, ist von Compilerschaltern eingerahmt. Siehe Zeile 4851 - 4864. Der Wert heißt txdelay und ist im Code auf 0 gesetzt. Zeile 4820.
Vielleicht kannst du was ausrichten, wenn du da ein paar 100 µs spendierst.
Habe nun die Testpunkte ermittelt und konnte ohne Löten daran messen.
Punkt und Strich Kontakt sind auf den ICP-Stecker geführt und das BS170
FET Gate Signal ist an einem unbesetzten Lötpad abgreifbar, siehe die ersten
beiden Anhänge.
Nachdem das ermittelt war (mittels DVM und Durchgangsprüfer-Mode mit Ton)
konnte ich die este Messung vornehmen.
Zeitspanne und Signal-Form des Key-Down und der HF am Ant. Ausgang.
Siehe Anhang. Sind knapp 1,5ms, wobei ein Spike auf der CW-Key Leitung,
entweder durch Prellen oder einen anderen Effekt zu dem HF-Spike vor der
CW Start Rampe führt.
Nun muss die entsprechende Stelle im Code gefunden werden, um das Übel
abzustellen.
Da Arduino kein Echtzeit-Trace oder Breakpoints unterstützt, ist das nicht ganz so einfach. Mit dem im Betrieb ungenutzten PB3 am ISP-Stecker könnte man im Code kurze Flankenwechsel einfügen und auf einen Kanal des Oszi legen. Dann siehst du ob die Stelle zeitlich passt. Etwa so:
1
fastdigitalWrite(PB3,LOW);
2
fastdigitalWrite(PB3,HIGH);
3
fastdigitalWrite(PB3,LOW);
Ein Kandidat wäre Zeile 4861. Oder gleich mal txdelay = 1 in Zeile 4822 ausprobieren.
Die Stelle macht nur Sinn, wenn die in Abhängigkeit der zahlreichen Compilerschalter auch durchlaufen wird. Siehst du in der Arduino-IDE.
Deshalb habe ich die .ino.cpp weiter oben drangehängt.
Das müsste der Output des Compilers sein, bei dem nur
der PP (PräProcessor) durchlaufen wird, wenn ich es
richtig interpretiert habe.
Ich werde mir die von Dir genannten Stellen mal genauer
ansehen und die Write-Toggel mal ausprobieren.
Diese befindet sich in der Funktion 'void start_rx() // Start radio receiver' aus Zeile 4802?
Müsste es nicht eine start_tx Funktion sein?
Sehe gerade es gibt eine 'void switch_rxtx(uint8_t tx_enable)' Funktion ab Zeile 4833.
Ich habe mal fastdigitalWrite(PB3, LOW/High/LOW); vor und nach Zeile 4861 in den Code eingefügt.
Werde gleich mit dem DSO schauen, wie da der Zeitliche Zusammenhang ist.
Habe nun das Ergebnis, siehe Anhang.
Erstes Bild - die Flanke vom PB3 und das Auftauchen der HF am Ant. Ausgang.
Bild zwei zeigt zwei CW-Punkte (20wpm) mit PB3 vers HF.
Was ich nicht ganz verstehe, ist der Umstand das PB3 nicht zwei kurze Inpulse
Macht, sondern bis Zum Ende der Aussendung eines Punktes auf High-Pegel bleibt.
Deshalb habe ich die .ino.cpp weiter oben drangehängt.
Das müsste der Output des Compilers sein, bei dem nur
der PP (PräProcessor) durchlaufen wird,
Nein, mit Sicherheit nicht. Hab zwar auch keine Ahnung von Arduino, aber soweit ich weiß, ist die ino.cpp die Haupt-Quelldatei. Darin gibts immer zwei zu befüllende Methoden, setup() und loop(). Das Ganze nennen die Sketch.
Der Präprozessor läuft anschließend, der interpretiert natürlich die #define wie jeder andere Präprozessor auch, ergänzt aber noch unsichtbar includes auf die Arduino-Libraries.
Ein gcc nimmt den Code deshalb ohne diese Ergänzungen nicht. Aber in deiner Arduino-IDE siehst du ganz schnell, ob der Code ausgegraut ist oder nicht.
Was ich nicht ganz verstehe, ist der Umstand das PB3 nicht zwei kurze
Inpulse
Macht, sondern bis Zum Ende der Aussendung eines Punktes auf High-Pegel
bleibt.
Wirklich seltsam. Jetzt wären Arduino-Kenntnisse nützlich. Vielleicht darf man die Ports nicht so schnell ein- und ausknipsen. In C oder Assembler wäre das ok.
Komisch ist auch die um 1/2 Volt überschießende Spannung.
Aber ich glaube die Stelle ist gut. Füge doch mal OCR1BL = 0; ein.
Edit: jetzt sehe ich das korrekte zweite Bild, warum auch immer. PB3 sieht sehr merkwürdig aus. Steht der Kanal auf AC? Würde aber auch nicht alles erklären.
Habe doch geschrieben, dass wir das fastdigitalWrite falsch benutzen. Als erster Parameter muss die sog. Arduino Pin Number verwendet werden. PB3 hat die 11. Also
1
digitalWrite(11,LOW);
2
digitalWrite(11,HIGH);
Zuvor muss der Pin zumindest einmal konfiguriert werden. Das macht man in Arduino vermutlich so:
1
fastpinMode(11,OUTPUT);
Das musst du oben in der Initialisierung des Controllers unterbringen. Dann werden die Pulse hoffentlich wie vermutet aussehen.
nun haben wir zwei Toggel-Punkte am DSO.
Der Erste innerhalb der "switch_rxtx(uint8_t tx_enable)" Funktion
und der zweite im Bereich der "Switch(mode)" CASE Anweisung bei dem
der dsp_tx_cw Funktions-Pointer an func_ptr übergeben wird, der wohl
innerhalb einer Interrupt-Routine angesprungen wird.
Diesen Toggel sehen wir unmittelbar vor dem Auftauchen der HF an der
Antenne, siehe Anhang.
Der von mir geänderte txdelay Wert von 0 auf 10 liefert die ca 8.5ms
Verzögerung bevor die HF startet. Erst danach kommt die Rampe, ebenfalls
mit einer etwas kleineren Verzögerung von 1.5ms.
Hallo Markus, bitte den gelben Oszi-Kanal auf DC schalten. Den blauen auch gleich. Dann sehen die Signale nicht so merkwürdig aus, irritiert mich irgendwie :-)
txdelay auf 1 hätte auch gereicht, vielleicht gehts auch mit semi_qsk_timeout und txdelay = 0, wenn man sich das Timing genau anschaut. Kann man später mal probieren.
Der grobe Ablauf sieht für mich in etwa so aus:
in void switch_rxtx(uint8_t tx_enable){...} wird die Umschaltung von RX auf TX (und umgekehrt) vorbereitet. Hoffentlich (!) wird die nur einmal pro Tastendruck / loslassen durchlaufen.
in der oben genannten Funktion wird der von dir angesprochene Funktionspointer func_ptr = dsp_tx_cw; gesetzt.
void dsp_tx_cw() wird zyklisch im TIMER2_COMPA_vect - Interrupt angestoßen.
Soweit so gut, aber OCR1BL = 0; muss ohne Schaden funktionieren, und zwar an der Stelle wo die jetzt funktionierenden PB3-Flankenwechsel eingefügt sind.
Wenn das nicht funktioniert hieße das, dass der Interrupt nicht kommt. Oder lut[255]=0 ist.
Man könnte natürlich in der Interruptroutine auch Pins toggeln, um das abzusichern. Aber eigentlich kann das nicht sein.
das mit der AC am CH1 habe ich auch mittlerweile bemerkt.
Das war der erste Kanal, mit dem ich am Anfang die HF gemessen habe.
Nun da er auf DC steht, sind die Abklingeffekte an den Flanken
nicht mehr vorhanden.
Ich werde für einige Tage ab Morgen offline sein, da auf Reisen,
melde mich aber wieder ab kommendem Mittwoch.
LG und bis dann.
Danke für die Unterstützung bei dem Problem mit dem uSDX+
Hatte kurz vor meiner Abreise noch eine andere FW von githab compiliert
und auf das Gerät draufgespielt. Diese Version 1.02.x hat keinen Spike
beim CW am Anfang jeder Punkt/Strich Sequenz.
Allerdings ist sie vom Empfang etwas besser (empfindlicher und hat weniger
ACG Übersteuerung)
Bei der Version 4.00e, die ich hier am Anfang genannt habe konnte ich das
Problem noch nicht finden. Werde die beiden Versionen vergleichen und finde
eventuell dann die entsprechende Stelle, die das Problem behebt.
Habe den Screenshot und die Version 1.02x als Archive angehängt, falls jemand
auch vergleichen will.
Die 4.00e, die ich zu Anfang angewendet habe,
ist die, bei der der RX am empfindlichsten ist.
Es kännen noch Signale vom Generator mit -115 bis
-110 dBm in CW detektiert werden (AGC off, LS auf 13),
zumindest bei meinen zwei Geräten (xSDX+ v2).
Bei anderen FW Versionen knn ich Signle erst ab ca.
-105 bis -100 dBm in CW aufnehmen. Bandbreite in beiden
Fällen bei 500Hz und bei gleicher Lautstärke und aus-
geschalteter AGC.
Deshalb habe ich diese FW (4.00e) zuerst auswählt und nur
den Empfang betrachtet. Erst danach ist mir das Problem
mit dem TX im CW Mode aufgefallen.
Die FW Version 1.02x stammt aus einer anderen Quelle und
ist etwas besser strukturiert, was den .ino Code angeht.
Es gibt einzelne Header-Files, die entsprechende Features
abdecken und die .ino Datei die dadurch etwas kürzer und
übersichtlicher ausfällt.
Ich hoffe Du kannst meinen Ausführungen soweit nachvollziehen.
vy73
Markus
PS.: Ich habe heute von Ali. ein Kabel mit dem zugehörigen Stecker
geliefert bekommen, so daß ich nicht mehr am Akku hängen muss,
sondern ein NT mit Strombegrenzung für die Experimente m uSDX+
verwenden kann. Damit ist das Risiko etwas geringer, dass ich mir
durch die FW Modifikationen die Geräte zerstöre.
Ok, danke für die Erklärungen. Ich hatte mir vor wenigen Wochen einen defekten (tr)uSDX gekauft und repariert. Ist wohl eine weitere Variante, mit veröffentlichter HW aber closed Source SW von DL2MAN und PE1NNZ.
Da kann ich vermutlich keine deiner SW-Varianten aufspielen, oder?
die FW Version 1.02.x, die ich angehängt habe, basiert auf der FW von DL2MAN
und wurde von PE1NNZ entsprechend weiter modifiziert.
Bevor OM DL2MAN seine FW closed Source machte, gab es noch nicht so viele CN-Kopien
von uSDX. Danach hat sich die FW-Entwicklung wohl etwas verselbständigt und es gibt
noch einige andere Varianten auf github.
Die besten, die ich gefunden habe, sind die 4.00e und die etwas ältere, aufgeräumte
Version 1.02x. Beide sollten für Deinen TRX gehen, wenn Du die entsprechenden #defines
aktivierst bzw. deaktivierst (Anzahl der Bänder, CPU-Takt, Pinnelegung der Morsetaste
und des Dreh-Encoders, etc)
Hallo Markus,
habe mir von https://github.com/GW8RDI/uSDXOpen/blob/main/trusdx_400.ino
den - vermeindlich - fertig parametrierten Code 4.0.0c für den truSDX gezogen und in einer VS-Code / PlatformIO Umgebung unter Ubuntu compiliert und auf meinen (tr)uSDX geladen.
So ganz rund läuft der darauf nicht, der Encoder funktioniert nicht. Müssen vermutlich doch noch irgend welche #Defines angepasst werden. Mit den Tasten lies sich CW einstellen. Die Frequenz stand noch auf ca 7MHz.
Auf Anhieb konnte ich das Problem nicht nachvollziehen. Habe zwar einen Mini-Click ca 2µs bevor der Sendepegel hochläuft, aber in deinen Oszi-Screenshots spielt sich das ja in einem ganz anderen Zeit- und Amplitudenbereich ab.
Habe per single sequence getriggert. Eigentlich sollte dabei kein Ereignis entwischen. Oder der Click ist so kurz, dass mein betagtes Oszi darauf nicht reagiert. Schaue ich mir am WE genauer an.
Gruß Wulf
Dir wird wohl nichts anderes übrig bleiben, als die
entsprechenden Anschlüsse vom Encoder zum MC mittels
eines Durchgangsprüfers (via DMM Ohm-Bereicht, Akustik-Geber an)
durchzumessen, um Ihre Zuordnung zum Controller zu bekommen.
Der TRX ist dabei ausgeschaltet, d.h. stromlos.
Sorry falls Du dass schon alles weißt, weiß nicht wie Deine
Elektronik Kenntnisse sind.
Hoffe Du besitzt die entsprechenden Gerätschaften.
Zur Not kannst Du auch zwei AAA Batterien (3V), eine 2mA LED (rot)
und einen Widerstand (ca. 1kOhm) zu einem optischen Durchgangsprüfer
zusammenbauen, falls Du kein DMM (digitales Multimeter) zur Hand hast.
Hallo Markus,
da ist schon alles sauber angeschlossen. Das Gerät funktioniert mit dem Original-Code von DL2MAN und PE1NNZ einwandfrei.
Der vorparametrierte Code des open source Projekts von GW8RDI passt halt nicht zum (tr)uSDX der Rev 1.0. Habe auch kein Interesse in den über den ganzen Code verteilten #define-Wüsten die richtigen Schalter rauszuknobeln.
Wollte eigentlich nur dein Problem mit den vorlaufenden Clicks bei CW-Betrieb nachstellen. Das passiert mit dem open source Code 4.00c weder auf 20m noch auf 40m. Die CW-Signale sind relativ sauber, siehe mein Oszi-Bild. Habe schon einige Meßgeräte :-)
Eigentlich ist es seltsam, dass die Version 4.00x empfindlicher ist als die 1.2y. In den Kommentaren zum Code steht, dass am Signal Processing seit dem nichts geändert wurde.
Ist natürlich die Frage ob das stimmt. Man könnte messen, ob die vermeindliche Empfindlichkeits-Steigerung nur ein anders berechneter Anzeigewert oder tatsächlich messtechnisch nachweisbar ist.
Hast du nachgemessen? Ich könnte das, habe die Messtechnik dafür.
Gruß Wulf
PS: deine TX-Pegel sehen etwas schwach aus. Der Kleine liefert schon einige Watt, da hätte ich an 50 Ohm über 15V Amplitude erwartet.
die FW Version 4.00e ist empfindlicher als die Version 1.02x (ohne CW Clicks).
Gemessen habe ich nur relativ einfach mittels 10dB-ATT am tinySA Ultra+.
Generator-Pegel auf -80dBm, QRG auf z.B. 14.025kHz (auch 80m, 40m und 15m probiert)
und Lautstärke auf 13 beim uSDX+ und AGC auf off.
Am tinySA schalte ich einen Sweep mit +-1kHz/2Sek./10Points ein, so daß man im RX einen
Sweep hört. Dann den Pegel jeweils um 3dB reduzieren und hören, wann der Sweep im
Rauschen untergeht.
Ist ausreichen genau und der tinySA(Ultra+) hat einen -+1-2 dB genauen Pegel, so daß
man schon in etwa den MDS eines RX's bestimmen kann.
Hallo Markus,
der RX-Pegel von -110 dBm als Empfindlichkeitsschwelle für die Firmware 4.00 kann ich bestätigen. Das ist auch gleichzeitig der Pegel des Eigenrauschens meines (tr)µSDX, d.h. wenn ich sauber mit 50 Ohm abschließe, zeigt das Gerät diesen Minimalpegel an. Die angezeigten Pegel stimmen in etwa mit denen vom Meßsender überein.
Habe mit einem Hameg HM8134-2 bei 40m gemessen. Zum Vergleich, das hier vor einem Jahr vorgestellte Pico-SDR kommt bis etwa -120dBm runter, mit passiven Abschluss. Das Pico-SDR hat den gleichen Tayloe-Detektor.
In der Praxis ist da nicht viel Unterschied, das Geräusch an der Antenne ist viel höher, so um -90dBm.
Wollte die open source Firmware mit der neusten DL2MAN-Firmware für den (tr)µSDX, die sich jetzt nG (new generation) nennt, vergleichen. Aber das klappt leider nicht. Die von DL2MAN vorgeschlagenen Flash-Tools laufen in meiner Umgebung nicht und mit meinem alten Atmel JTAGICE mk2 wird nach dem Flashen im Display dauerhaft ein Fehler angezeigt, der das Gerät blockiert. Vermutlich der Kopierschutz.
Propritäre, kopiergeschützte SW ist einfach Grütze. Und das obwohl ich ein Originalgerät habe.
Aber egal, ist alles OT. Eigentlich ging es um die TX-CW-Clicks auf deinem Gerät, was sich HW-seitig doch in einigen Punkten rund um die PA-Ansteuerung von meinem unterscheidet. Und damit ist ein Vergleich müßig.
bei meinem uTRX+ V1.2 habe ich überall im Web gefunden, dass man
vor dem Programmieren einen C entfernen müsste, der den Prog-Vorgang
stört. Ich habe meine Programmierung mit dem Buspirat v4 vorgenommen
und hatte keine Probleme dabei (BPv4 FW BPv4-firmware-v6.3-r2151.hex)
Diesen kann ich direkt aus der Arduino-IDE (bei mir Ver. 2.3.9) verwenden.
Ich programmiere den AVR unter Linux mit arduino-ide_2.3.9_Linux_64bit.AppImage
und habe soweit keine Probleme. Beim (tr)SDX kann natürlich die Sache
wieder ganz anders aussehen, vor allem wenn es sich um proprietäre FW handelt.
Eigentlich Schade, dass Alles mittlerweile so viele Stolperfallen enthält, die
einem das Leben beim Hobby unnötig erschweren.
Die (tr)µSDX-Firmware hat einen Kopierschutz, der auf der Seriennummer des AVR basiert. Vermutlich darf man deshalb die Firmware nur über den zuvor aufgebrachten Bootloader flashen und nicht über ein JTAG-, ISP- oder debugWire- Interface.
Das dies bei meinem (tr)µSDX nicht geht, liegt höchstwahrscheinlich am defekten USB-TTL-Wandler CH340G auf dem Gerät. Wird weder von Ubuntu noch Win10 erkannt und wird verdächtig warm. Habe Ersatz bestellt, probiere ich in ein paar Tagen nochmal.
Gruß Wulf
Ich suche derweil die Unterschiede zwischen FW Ver. 4.00e und 1.02x,
um die CW Tastung unter Version 4.00e entsprechend von den Spike bei
CW am Anfang zu befreien.
Ich suche derweil die Unterschiede zwischen FW Ver. 4.00e und 1.02x,
um die CW Tastung unter Version 4.00e entsprechend von den Spike bei
CW am Anfang zu befreien.
Wünsche viel Erfolg. Wird nicht ganz einfach, die von mir angeschauten Code-Abschnitte für TX-Vorbereitung und zyklischer Interrupt sind bis auf Marginalien identisch bezüglich CW.
void switch_rxtx(uint8_t tx_enable){...}
void dsp_tx_cw()
Im Bild die Interruptroutine, links 4.00, rechts 1.02.
Ich glaube immer noch an einen Timingfehler.
Gruß Wulf
Wenn der Code der beiden Versionen sich kaum unterscheidet muss es wohl
wirklich was minimales sein. Kann man das mit gdb und dem ISD feststellen?
Habe da noch nicht viel in dieser Richtung gemacht. Zudem verändert das
Debuggen ja die Laufzeit, was dann den Fehler eventuell erst gar nicht entstehen
lässt.
Ich werde mich mal etwas mit AI spielen und beide .ino einem
AI-Bot anbieten und schauen, was dabei rauskommt.
Muss nur noch einen finden, bei dem sich die Kosten dafür in Grenzen
halten. Gibt gerade einen Beitrag zu so was in der letzten oder vorletzten
C't. Optimierung bei AI-Bot Anfragen, um Kosten zu senken.
Wohl eine Verknüpfung aus beiden: auf der (tr)µSDX-Hardware tritt der Fehler nicht auf, wahrscheinlich wegen der Taktverriegelung mit dem NAND-Gatter.
Auf deiner Hardware, die diese Verriegelung nicht hat, kommt der Effekt mit anderer Firmware.
Mit einem Debugger könnte man Breakpoints setzten und damit die Codestelle eingrenzen.
Ich habe den alten Atmel JTAGICE mk2 Debugger, der unterstützt gdb noch nicht und es wäre ein ziemlicher Aufwand den in einer Arduino-Umgebung zum Laufen zu bringen. Macht aber keinen Sinn, da ich den Fehler eh nicht reproduzieren kann.
Ich würde es klassisch mit den Flankenwechsel auf dem I/O-Port und Oszi weiter eingrenzen. Warst ja schon nahe dran.
Der Ansatz über eine KI wäre spannend. Außer den üblichen Abfragen habe ich noch keine Erfahrung damit, bisher nie in eine geschlossene Loop eingebaut. Aber ich denke man sollte das einfach mal probieren. Vielleicht Antropic Claude Code, kostet nicht viel und soll erstaunliches auf dem Gebiet leisten.
uSDX-CW-Dot-Dash.png
(98 KB)
