Fragen zum Softwareupdate

Hallo PW,

solange das HF-seitig eingesetzte Protokoll (inkl. einer Betriebsart wie "Listen before Talk") im Sendemodul codiert ist und der darüberstehende Sender (auch mit beliebiger Firmware wie OpenTX, ER9X etc.) daran nichts ändern kann, ist das der HF-Seite doch völlig egal.

Genau deshalb habe ich erwähnt, dass die Jeti-Sendemodule vom OpenTX-Sender via PPM angesteuert werden und m.E. keinerlei Risiko besteht, auf der HF-Seite durch selbstentwickelte (für Dich "selbst zusammengefummelte") Firmware etwas protokollseitig zu beeinflussen.

Sobald das nicht mehr so ist und der Sender anders als mit den Jeti-Modulen ein SDR (= software defined Radio) implementiert, wäre die Sachlage natürlich völlig anders und die Sender-Firmware auch für die HF-Seite verantwortlich... Dann würde auch Deine Erwartung zutreffen, dass Firmware-Updates "abgesichert" stattfinden müssen.


@DD8ED Hallo Frank,
passt das zur aktuellen Auffassung der Physik und der hoffentlichen darauf basierenden Rechtslage?

Grüße
Henning / DB5SH

Hallo,
schick mir die mal.
Gruss
Frank

Hallo,
in diesem Fall ist so ein Modul ein sog. "Plug-In Device". Das ist vergleichbar mit einem WLAN oder BT USB-Stick.
Wenn das Host-Equipment Open Source ist, ist das nicht das Problem des Plugins, solange der Host nicht in die Parametrierung des Plugins eingreifen kann. Das ist jetzt schon klar geregelt.

Gruss
Frank

Henning wrote: Hallo PW,

solange das HF-seitig eingesetzte Protokoll (inkl. einer Betriebsart wie "Listen before Talk") im Sendemodul codiert ist und der darüberstehende Sender (auch mit beliebiger Firmware wie OpenTX, ER9X etc.) daran nichts ändern kann, ist das der HF-Seite doch völlig egal.

Genau deshalb habe ich erwähnt, dass die Jeti-Sendemodule vom OpenTX-Sender via PPM angesteuert werden und m.E. keinerlei Risiko besteht, auf der HF-Seite durch selbstentwickelte (für Dich "selbst zusammengefummelte") Firmware etwas protokollseitig zu beeinflussen.

Sobald das nicht mehr so ist und der Sender anders als mit den Jeti-Modulen ein SDR (= software defined Radio) implementiert, wäre die Sachlage natürlich völlig anders und die Sender-Firmware auch für die HF-Seite verantwortlich... Dann würde auch Deine Erwartung zutreffen, dass Firmware-Updates "abgesichert" stattfinden müssen.


@DD8ED Hallo Frank,
passt das zur aktuellen Auffassung der Physik und der hoffentlichen darauf basierenden Rechtslage?

Grüße
Henning / DB5SH

Die Situation ist im Augenblick die, das in Zukunft der Hersteller sicherstellen muss, das die Kombination von Hardware und Soft / Firmware in jedem Fall den Anforderungen der Konformität entspricht. Diese Anforderung muss allerdings seitens der EU noch in Kraft gesetzt werden.
Was die Hersteller da tun müssen ist noch offen, da die EU erst einen "Delegated Act" zu dem Thema erlassen muss. Eins ist aber sicher: Es wird mich beliebig viel Nerven kosten, da diese Anforderung voraussichtlich in die Funkstandards implementiert wird.
Wenn der Hersteller von Funkequipment die alleinige Gewalt über Updates hat, wird das noch relativ easy zu handeln sein. Open Source wird dann aber eher unlustig und aufwändig.
Was da an Regeln kommen wird, ist noch offen. Es gibt allerdings schon höchst unlustige ETSI-Standards in diesem Bereich. Wenn diese für R/C implementiert werden:
Schon mal über Freiflug (ohne Funk) oder Fesselflug nachgedacht ?

Gruss
Frank

Henning wrote:
PS: Die Hardware der Jeti-Sendemodule war anfänglich übrigens auf ATMEL ZigBit-Modulen aufgebaut, siehe Foto eines "frühen" TG-Moduls...

Hallo, gehe ich recht in der Annahme, das heute auch noch ATMEL-Chips verwendet werden ?
Die sind im Bereich IEEE 802.15.4 ja nun nicht die schlechste Wahl, obwohl die dummerweise nur wenig Frequenzen im Hopping erlauben. DAs ist allerdings ein grundsätzliches Problem von IEEE 802.15.4 (in vulgo Zigbee)

Gruss
Frank

Hallo Frank,

hab gerade mal kurz auf ein TU-Sendemodul gesehen. Bei den neueren Sendemodulen ist kein komplettes ZigBit-Modul mehr aufgelötet, sondern die 3 Einzel-IC sind direkt auf die PCB (unter einen Epoxy-Sichtschutz) gewandert. Es werden aber weiterhin ein Atmel-Microcontroller (beim TU ist es ein mega328P), ein ATRF-Chip und ein weiteres HF-IC (von TI ?) verwendet.

Ich gehe davon aus, dass das ganze weiterhin auf ZigBee / ZigBit basiert und nur die verwendeten IC mittlerweile etwas "optimiert" appliziert sind...

Gruß
Henning / DB5SH