Posts by yo2loj

    Ich glaube da brauch ich ein bisschen Unterstuetzung.
    Bei der Phy hab ich beim experimentieren den Bootloader geloescht, wass keine Rueckkehr zur Originalfirmware ermoeglicht.
    Dies macht ein Experimentieren fuer andere in dem Falle keinen Sinn, da so ein perfekt funktionsfaehiges Geraet ja eingeschraenkt wird.


    Gibt es die Moeglichkeit einen Bootloader der Phys zu bekommen (eine Hex- oder Binaerdatei reicht, Source ist nicht noetig), um so eine Entwiklung anderen zur Verfuegung stellen zu koennen, ohne das diese einene Debugger brauchen und ohne dass die Firmwareaenderung endgueltig ist? Nicht zum Weitergeben sondern nur zum Testen der Firmware Upgrades auf der Phy.


    Reverse Engineering ist ja machbar, aber der Aufwand gross.


    Als Ausgangsphase waehre MMDVM auf der Phy und durchschleifen zum seriellen Port machbar, dann koennte man das UP4DAR mit MMDVMHost uber den seriellen Port als einfaches Modem, mit oder ohne RMU2, experimentell betreiben. Remote Serial Port ueber Telnet waehre auch eine Idee.
    Die FW auf dem Hauptprozessor braucht noch etwas Zeit, das Durcheinander ist gross und der Speicher eng. Oder da koennten auch andere eingreifen.

    Hallo Leute,


    Habe versucht ein MMDVM auf die Phys zu portieren :-)


    Nach 3 Wochen Arbeit endlich soweit...
    D-Star, DMR, und YSF auf dem UP4DAR (nur Hotspot, ohne AMBE Unterstuetzung, theoretisch auch P25 und NXDN).
    (Ich glaube das ist zum Erstenmal dass MMDVDM auf einem AVR32 laeuft) :P


    Durch der geringeren Prozessorleistung kommen bei mehr als 3 Modi gleichzeitig Bufferoverruns...


    Noch keine Buttons und Settings (alles ist noch hardcoded).


    Analoges Funkgeraet und RMU2 wird unterstuetzt (RMU2 ist noch etwas unstabil und Rx haengt hie und da).
    Die Phy spricht MMDVM, Clients liegen am Hauptprozessor.
    Es funktionieren YSF Reflektoren, DMR/DMR+ ueber MMDV Protokoll (getestet BM und IPSC2) und DCS fuer D-Star.
    Telnet Server und HTML Seite sind minimal dabei.

    UP4DAR hotspot mode expects R1 and R2 to be set to 'DIRECT' and no repeater flag, and is not working otherwise.
    Icom transceivers do this by default for simplex operation and use the R1 and R2 settings only in repeater mode.
    Other hotspot setups expect R1 and R2 to be set whith dup 0 assimilating the hotspot functionality to a (simplex) repeater.

    Ok,


    Den ganzen Thread kann man ruhig vergessen.


    Ich habe die unveraenderte 1.01.41 neu draufgespielt und alles scheint zu funktionieren.
    Und das Geraet sendet tatsaechlich "DIRECT " fuer RPT1 und RPT2 aus (gechecked).


    Jetzt wieso das zu einem Zeitpunkt nicht ging, kann ich mir nicht vorstellen, das lag wahrscheinlich an irgend einer Einstellung am Funkgeraet die mir im Moment nicht bewusst ist.


    Entschuldigung fuer den Krawall.

    Wie gesagt, in der luft sendet mein Icom mit neuerer firmware NICHT "DIRECT" aus, sondern etwas, was beim Empfang in buffer als 8x space erscheint.
    Deswegen hat der Hotspot mit diesem Geraet auch nicht mehr funktioniert.


    Ich fahre jetzt mit der Aenderung, kein Problem in meinem Fall, da ich das selber machen kann, nur wahrscheinich werden auch Andere damit Probleme haben. Ich wollte nur ein bischen 'proaktiv' sein :-)


    Ich guck mir den Datenaustausch noch einmal genauer an und komme mit Details...

    Hallo Denis,


    Ja, die Matrix ist interessant. Nur mit einigen Problemen im Hotspotmodus, der irgentwie viel zu streng implementiert ist. Sonst ist ja alles I.o.
    U. zw. bei Direct Operation/QSO sendet nicht jedes Funkegerat "DIRECT" aus, und das ist auch nicht am Funkgeraet einstellbar, und wie Du selber sagst, gibt es ja keinen Hotspotmodus am Geraet.


    IC7100 z.B. sendet da leere Felder. Im Setupdisplay erscheint "--------" und das kann man im Simplexbetrieb nich aendern.
    Das hat sich eigentlich bei Icom in den Firmwares ab e3 veraendert (inzwischen sind die bei e5) - frueher hat alles funktioniert. Und ich koennte mir vorstellen, das dieses Verhalten auch bei neueren Firmwares fuer andere Modelle umgesetzt wird (und so dass immer mehr Icoms UP4DAR-Hotspot-inkompatibel werden).


    Der vorher beschriebene Patch ist minimal und behebt dieses Problem indem er auch leere RPT-Felder zulaesst, welche meiner Meinung nach als "DIRECT" zu deuten sind.

    Hallo,


    Ich moechte gerne ein Fehlverhalten des UP4DARs im Hotspot-modus diskutieren.


    Einerseits werden Autokonfigurationsbefehle ausgesendet, so dass das Funkgeraet sich mit RPT1 = Rufzeichen und RPT2 Rufzeichen G selbst konfiguriert.
    Anderseits werden in der 'send_dcs_hotspot funktion' in der Datei dcs.c RPT1 und RPT2 auf "DIRECT" ueberprueft, und dann verworfen, falls die Autokonfiguration stattgefunden hat.


    Bei den Geraeten von Icom ist ein setzen der RPT1 und RPT2 im Simplex-modus nicht moeglich, so dass man ohne RPT-Rufzeichen fahren muss. Das bringt ebenfalls ein Verwerfen der Daten in der oben genannten Funktion, da diese Felder leer sind und nicht de String "DIRECT " beinhalten.


    Der Ausweg ist normalerweise einen Repeater mit Shift 0 einzurichten, so dass man dann RPT eintragen kann. Da man jetzt jedoch im Repeater-Modus arbeitet, ist dann das Repeaterflag gesetzt, was zu einem Verwerfen der Daten in der Datei txtask.c Funktion vTXTask linie 895: ((hotspot_mode) && (rx_header[0] & 0x40) hervorruft.


    Die Loesung die Ich hier sehe ist das Entfernen der Autokonfiguration im Hotspot-modus, da diese sowiesoh nicht funktioniert, und das Veraendern der send_dcs_hotspot Funktion aus der dcs.c-Datei so dass auch ein leeres RPT Feld als gueltig erkannt wird:


    Code
    1. if ( (hotspot_mode &&
    2. (dcs_state == DCS_CONNECTED) && // only send if connected
    3. (crc_result == DSTAR_HEADER_OK) && // last received header was OK
    4. ((rx_header[0] & 0x40) == 0) && // no repeater flag in header
    5. ((memcmp("DIRECT ", rx_header + 3, 8) == 0) || (memcmp(" ", rx_header + 3, 8) == 0)) && // RPT1 and RPT2 contain "DIRECT " or " "
    6. ((memcmp("DIRECT ", rx_header + 11, 8) == 0) || (memcmp(" ", rx_header + 11, 8) == 0))
    7. )
    8. ||
    9. [...]


    Uebrigens, ein Ignorieren der RPT-Rufzeichen und des Repeater-Flags waehre ebenfalls eine Option, und wuerde Simplex und 0-Shift Repeater mit Autokonfiguration zulassen.


    Die oben beschriebene Aenderung habe ich getestet und funktioniert entsprechend im Simplex-Modus mit meinem IC7100 mit neuester Firmware (e5).


    Marius, YO2LOJ

    Der Reflektor ist gute 5 tage alt :-)
    Welche Version da drauf ist weiss ich leider nicht, da ich den Reflektor nicht selbst eingerichtet habe, aber es funktioniert richtig mit 1.1.41 (ich habe die Firware veraendert so dass xrf226 als xrf226.hamnet.ro aufgeloest wird).
    Werde demnaechst mit der ofiziellen Version testen.


    Danke.


    Marius, YO2LOJ

    Hallo Denis,


    Was Franz sich eigentlich wuenscht is wahrscheinlich die Moeglichkeit, die Position eines Repeaters, Hotspots oder IP-Reflektors, die ueber eine GPS-Maus ausgelesen wird, an das DAPRS-system weiterzugeben.
    Das hat auf Firmware 1.01.34e funktionert und geht auf neueren Versionen nicht mehr.

    Wenn man den Umbau der Stromversorgung unterlaesst, funktioniert die RMU mit geringerer Leistung? Die cc1125 geht ja von 2.0 bis 3.6 Volt... Oder gibt es dann Pegelanpassungsprobleme?

    Ich weiss nicht genau ob das die Stelle ist um reinzuquatschen, aber was auf dieser Hardware, einschliesslich mit der neuen RMU, machbar waehre, ist ein 9k6 G3RUH APRS-tracker, Packetnode mit Internetanbindung oder sogar ein iGate.
    FSK geht mit der IC von der RMU (1k2 wahrscheinlich nicht, da BELL AFSK nicht unterstuetzt wird, vielleicht direkt mit einem externen Funkgeraet), GPS ist da, ein nettes Display auch, und der Ethernetport ebenfalls. Falls die PHY da mitspielen wuerde...