Author
|
Topic: "Daily Snapshots" von Firmware und Bootloader nun verfügbar (Read 53455 times)
|
|
dl1avx
schon länger dabei
 Offline
Posts: 60
Ich liebe dieses Forum!
|
 |
Re:"Daily Snapshots" von Firmware und Bootloader nun verfügbar
« Reply #495 on: 16. July 2016, 20:11:41 »
|
|
Hallo Danilo,
der EEPROM ist von Atmel!
73 de Peter
|
|
 Logged
|
|
|
|
Inkiiin
Neuling
Offline
Posts: 34
Ich liebe dieses Forum!
|
|
Re:"Daily Snapshots" von Firmware und Bootloader nun verfügbar
« Reply #496 on: 19. July 2016, 18:36:54 »
|
|
Hi an das Software Team,
könnten wir für die resp byte 0 des CAT Kommanto 0xE7 statt
0x09; // S9 signal;
folgendes
(uint8_t) round(sm.s_count*0.5);//S Meter signal;
nehmen?
Es würde dann immer der aktuelle SMeter Wert übergeben , je nach eingestellter Methode 
Viele Grüße,
Axel
|
| « Last Edit: 19. July 2016, 18:38:53 by Inkiiin » |
Logged
|
|
|
|
|
|
Inkiiin
Neuling
Offline
Posts: 34
Ich liebe dieses Forum!
|
|
Re:"Daily Snapshots" von Firmware und Bootloader nun verfügbar
« Reply #498 on: 20. July 2016, 15:40:59 »
|
|
Danke erstmal !
Also das es geht weiß ich schon , nur füge ich es bisher immer händisch ein wenn eine neue Version raus kommt
HRD ruft diesen Wert ab und zeigt ihn an,
warum es in der Hamlib nicht drin weiß ich nicht oO
Viele Grüße ,
Axel
PS: funktioniert, grad mit der aktuellen Version getestet.
falls Du in der Gegend nochmal etwas anfasst - mit folgender Änderung wären dann auch Power und VSWR per CAT verfügbar:
case 189: /* BD Read TX Status */
//resp[0] = 0;
if(ts.tx_disable||(ts.txrx_mode != TRX_MODE_TX))
{
resp[0] =0x00;
}else{
resp[0] =((uint8_t)round(swrm.fwd_pwr)<<4)+(uint8_t)round(swrm.vswr_dampened);
}
|
|
|
| « Last Edit: 20. July 2016, 16:21:06 by Inkiiin » |
Logged
|
|
|
|
|
|
Inkiiin
Neuling
Offline
Posts: 34
Ich liebe dieses Forum!
|
|
Re:"Daily Snapshots" von Firmware und Bootloader nun verfügbar
« Reply #500 on: 20. July 2016, 16:43:30 »
|
|
Hi Andreas,
danke für das einpflegen.
Ich bastel nebei noch an einer Möglichkeit cw etwas komfortabler zu gestalten ( memorys und decoder)
Gibts bezüglich decoder schon irgend welche Anfänge/Gedanken oder soll ich mich da an fldigi orientieren?
Viele Grüße,
Axel
|
|
Logged
|
|
|
|
|
|
Inkiiin
Neuling
Offline
Posts: 34
Ich liebe dieses Forum!
|
|
Re:"Daily Snapshots" von Firmware und Bootloader nun verfügbar
« Reply #502 on: 20. July 2016, 17:45:33 »
|
|
Hi,
fldigi ist auch in sofern gut da eigentlich alles vorhanden ist, gepflegt wird und "lediglich" etwas eingedampft werden muss.
Der kleinste gemeinsame Nenner bezüglich der Digimodes scheint mir in der modem.h zu liegen ich werde die Modem Klasse in ein struct umschreiben um da einiger Maßen lesekompatiebel zum C++ zu bleiben und sehen ob mir der Anfang für eine
vernünftige Integration gelingt.
Viele Grüße,
Axel
|
|
Logged
|
|
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:"Daily Snapshots" von Firmware und Bootloader nun verfügbar
« Reply #504 on: 20. July 2016, 22:37:47 »
|
|
Hallo Axel und Andreas,
fldigi ist auch in sofern gut da eigentlich alles vorhanden ist, gepflegt wird und "lediglich" etwas eingedampft werden muss.
Der kleinste gemeinsame Nenner bezüglich der Digimodes scheint mir in der modem.h zu liegen ich werde die Modem Klasse in ein struct umschreiben um da einiger Maßen lesekompatiebel zum C++ zu bleiben und sehen ob mir der Anfang für eine
vernünftige Integration gelingt.
|
|
Ich denke, die händische "Übersetzung" von C++ Code nach C ist der falsche Weg (ohne mich im Detail mit der konkreten Nutzung von C++ in fldigi auseinandergesetzt zu haben).
Das ist sehr viel Aufwand ohne großen Mehrwert. Es ist grundsätzlich kein Problem C++ und C Code zu mischen, insbesondere wenn die Schnittstelle überschaubar ist. Und das ist sie hier. Im Wesentlichen müssen die Audio-Daten geliefert werden und die Ergebnisse der Darstellung zugeführt werden. Dazwischen kann alles problemlos C++ bleiben.
Der GCC, Eclipse und auch CoIDE können das.
Das hätte insbesondere den Charme, dass man vermutlich viel 1:1 übernehmen könnte und auch entsprechend so weiteren fldigi Code oder Fehlerbereinigungen einfacher übernehmen kann.
Ich würde das nicht nur mental sondern auch praktisch bei der Umsetzung des korrekten C/C++ Builds durch Makefile/Eclipse/CoIDE unterstützen und bei der Gestaltung der Schnittstellen helfen.
Aber wie schon Andreas sagt, es liegt bei Dir, Axel.
73
Danilo
|
|
Logged
|
|
|
|
Inkiiin
Neuling
Offline
Posts: 34
Ich liebe dieses Forum!
|
|
Re:"Daily Snapshots" von Firmware und Bootloader nun verfügbar
« Reply #505 on: 21. July 2016, 03:02:58 »
|
|
Hi Danilo,
sofern die Bereitschaft zum mischen da ist macht es das in der tat um einiges einfacher.
Dann bliebe hauptsächlich "nur" Abstraktionen/Schnittstellen zu schaffen um den Fldigicode mit den Daten des mchf zu füttern bzw diese ab zu holen ...
Mchf <-> fldigi
===========
Audiodriver/Management <-> trx.cxx
Uidriver <-> watefall.cxx
Digimode fifo <-> modem.cxx
Habe ich das soweit richtig auf dem Schrim ?
Viele Grüße,
Axel
|
|
Logged
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:"Daily Snapshots" von Firmware und Bootloader nun verfügbar
« Reply #506 on: 21. July 2016, 06:52:53 »
|
|
Hallo Axel,
was die konkreten Schnittstellen angeht, hängt das natürlich von dem Ansatz der Integration von fldigi ab. Und das ist ja "deine" Baustelle.
Audio-Daten gibt es tatsächlich im audio_driver.c zu holen. Bei der UI Integration wird man sicher überlegen müssen, wie man das hinbekommt. Die Frage ist auch, wievel Rechenzeit noch übrig bleibt, wenn fldigi Code mit läuft. Aber im Grund muss das dort irgendwo rein.
Fürs CW Senden würde ich ja eher den vorhandenen Code verwenden. Für RTTY und ähnliche Modi muss geklärt werden, wie die Sendedaten in den mcHF gelangen.
Das eigentlich Handling des Sendens passiert dann ja wieder in audio_driver.c, Umschaltung RX/TX etc. in ui_driver.c
Der erste Schritt wäre ja erstmal den fldigi Code von allem Überflüssigen zu befreien, "Fake"-Schnittstellen zu schaffen und ihn dann überhaupt erstmal zu übersetzen (auf dem PC). Das würde Hinweise auf Speicherverbrauch liefern. Und dann in den mcHF einpassen.
Es ist auch wichtig zu verstehen, in welcher Form fldigi Multitasking betreibt und das dann an den mcHF anzupassen. Der mcHF Code hat ja nur ein sehr,sehr eingeschränktes Multitasking.
73
Danilo
|
|
Logged
|
|
|
|
Inkiiin
Neuling
Offline
Posts: 34
Ich liebe dieses Forum!
|
|
Re:"Daily Snapshots" von Firmware und Bootloader nun verfügbar
« Reply #507 on: 21. July 2016, 08:58:37 »
|
|
Hi Danilo, zur not tut es ein 2. stm als kleine Zusatz Platine der per spi am 1. hängt und sich nur um die digimodes kümmert *lach*
Nee irgendwie wird es schon passen.
Viele Grüße ,
Axel
|
|
Logged
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:"Daily Snapshots" von Firmware und Bootloader nun verfügbar
« Reply #508 on: 21. July 2016, 10:03:30 »
|
|
Hallo Axel,
auch das ginge.
Nebenbei: Ich würde gerne eine bessere "Frontplatte" (Größeres Display, etwas erweiterte Bedienelemente) machen und mit dem original mcHF verbinden.
Leider hindern mich das nicht ausreichende Zeitbduget und bescheidenen PCB-Layoutfähigkeiten, meine Idee umzusetzen.
Konkret ware die Idee folgende: Man nehme ein STM32F7 Discovery-Board (50 Euro: Display, viel RAM etc.), verbinde das über I2C / I2S mit dem original mcHF und mache eine "einfache" Platine, die die Bedienelemente trägt, die Aufnahme für das Discovery-Board ist als auch eine Verbindung zum mcHF über den ja dann nicht benötigen Display Adapter herstellt.
Das ist dann nicht mehr so klein und schnuckelig wie der original mcHF, aber um Größenordnungen leistungsfähiger. Löttechnisch ist das dann keine Herausforderung mehr und preislich nur relativ geringer Aufpreis.
Vielleicht hat ja jemand Interesse, da auch aktiv zu werden.
Grüße
Danilo
|
|
Logged
|
|
|
|
DD4WH
positron
alter Hase
Offline
Posts: 462
Ich liebe dieses Forum!
|
|
Re:"Daily Snapshots" von Firmware und Bootloader nun verfügbar
« Reply #509 on: 21. July 2016, 12:48:17 »
|
|
Hallo Danilo, hallo Axel,
das fände ich auch sehr interessant! Dann könnte man vielleicht auch im noise reduction-Bereich mal etwas rechenintensivere Methoden ausprobieren ;-). FreeDV nutzt ja im Prinzip schon spannende Techniken im speech processing-Bereich, das sollte auch auf beliebige andere Signale anwendbar sein.
Vielleicht kann man in dem Zuge dann auch gleich den RF-Teil etwas aufbessern, z.B.
- Bandpässe / low pass-Filter für 160m, MW, LW
- anderer Oszillator (vielleicht Si514), um von 100kHz bis 30Mhz alles zu empfangen
- zuschaltbarer attenuator (bei Empfang zwischen 900kHz und 1600kHz ist bei mir hier nur mit 10-20dB attenuation ein Empfang möglich, ohne dass der ADC völlig übersteuert: zugegebenermaßen spezielle Bedingungen hier mit BPF auf passthru und hochpegeliger Aktiv-Antenne)
Den Audio-Verstärker muss man -wenn man das discovery board nimmt- ja wohl nicht mehr überarbeiten, der ist ja mit drauf. Den originalen Audio-Verstärker des mcHF mit dem LM386 habe ich hier durch eine diskrete gain-arme und absolut rauschfreie Lösung ersetzt, da das Rauschen des LM386 selbst bei geringen Lautstärken am Kopfhörer für mich unerträglich war.
Also: die Idee finde ich hochspannend und würde gerne mitmachen, bin aber hinsichtlich PCB-Layout absoluter Laie . . .
Die Frage wäre auch, ob das ein absoluter fork wäre und dann die Entwicklungen von Hard- und Software komplett auseinandergehen. Das müsste man genau bedenken. Andererseits ist eine Spaltung in die Optionen a) portabler mcHF (dann aber auch mit geringem Stromverbrauch: Schaltregler und sparsamer LO) und in b) maximale Leistung-mcHF mit low noise-Spannungsreglern ohne Rücksicht auf Stromverbrauch (das display braucht ja vermutlich auch viel mehr!) ja gar nicht so schlecht.
73 de Frank
|
|
Logged
|
-----------------------------------------
Teensy Convolution SDR
https://github.com/DD4WH/Teensy-ConvolutionSDR
|
|
|
|
|
|
Online
