868 MHz Long Range Test
- Themenstarter Carbonator
- Beginndatum
- Status
Es tut sich was, trotz positivem Fanboy Test hat FrSky eine neue FCC Firmware veröffentlicht (180124). LBT ist auch mit drin, natürlich wieder null Changelog. Heute hatte ich die Chance, mal mit einem HF Messplatz zu arbeiten. LBT 25mW, FCC 10 und 100mW sehen alle ähnlich aus (oben). LBT 500mW ist echt krass (unten). Da wird das ganze Band geflutet, keine Ahnung, wie mehrere Funkstrecken damit zurechtkommen sollen. Vielleicht kann ein HF-ler was dazu sagen. Mein erster Verdacht war, dass der Sender durchgegangen ist und willenlos schwingt.
Da FrSky die R9 Telemetrie nicht hinkriegt, hab ich mal auf 2,4GHz umgestellt, damit ich weitertesten kann.
Der 868MHz Controllink geht mit den Orignal Antennen 360m weit mit 0,01mW (im RT mode). Die 10km sollten demnach mit 25mW drin sein, wenn man ein bißchen an den Antennen optimiert (bissel Reserve brauchts halt schon).
Die DIY Drahtdipole machen bis jetzt einen ganz guten Eindruck, trotz Fehlanpassung asym.<->sym.. Hat jemand Erfahrungen mit Baluns in diesem Frequenzbereich? Es gibt wohl SMD Baluns, aber die sind schwer zu kriegen. Kann man sowas selbst machen?
Der 868MHz Controllink geht mit den Orignal Antennen 360m weit mit 0,01mW (im RT mode). Die 10km sollten demnach mit 25mW drin sein, wenn man ein bißchen an den Antennen optimiert (bissel Reserve brauchts halt schon).
Die DIY Drahtdipole machen bis jetzt einen ganz guten Eindruck, trotz Fehlanpassung asym.<->sym.. Hat jemand Erfahrungen mit Baluns in diesem Frequenzbereich? Es gibt wohl SMD Baluns, aber die sind schwer zu kriegen. Kann man sowas selbst machen?
Es gab mal wieder eine neue Firmware 180202 für R9(slim) und R9M:
1. Fix the bug of “Telemetry Lost” false alarm.
2. Modify the PWM output period and improve the compatibility with servos.
Die Telemetrie von meinem F3 FC hat leider mit der LBT Version immer noch nicht funktioniert, bzw. nur mit Aussetzern. In der FCC Variante dafür einwandfrei. Beide Versionen gehen bei ~ 50dB RSSI in den Failsafe. Die default RSSI Warnungen hört man vor einem Crash also nie, genauso, wie viele User es sich wünschen
.
Was seltsam war, die Reichweite im LBT rangetest Modus war sehr unterschiedlich. Von 300m bis über 1km war alles drin. Außerdem kamen kurz Geräusche aus meinem X9D Lautsprecher, wie wenn das R9M selbstständig mal die Power erhöht hätte. Das fasst sich nicht schön an.
FrSky wird wohl nur unter Druck etwas tun. Mittlerweile habe ich den Eindruck, dass die Chinesen erwachsene Männer, die mit ferngesteuerten Modellen spielen, nicht wirklich ernst nehmen Deren Kohle nehmen sie aber vermutlich ernst. Deswegen kann man nur hoffen, dass nicht mehr viele den Mist kaufen, bevor sie die Firmware auf die Reihe kriegen. Engel liefert R9 gar nicht mehr aus, das funktioniert natürlich auch.
Meine subjektive Meinung zum R9 System:
- die 500mW Variante zieht nur massiv den Akku leer, die könnte man streichen (ist aber für manche sicher ein Kaufargument)
- die 25mW Variante geht ein paar km weit, das reicht
- Telemetrie muss mit FCs funktionieren
- RSSI muss auf die anderen Empfänger angepasst werden -> Failsafe bei ~ 36-38dB RSSI
- als Backup für 2.4GHz ist die 25mW Variante perfekt, aber 8 Kanäle sind oft zu wenig
- ein weiterer 25mW Modus ohne Telemetrie, dafür mit 16 Kanälen würde Sinn machen (wenn es technisch geht)
- die Servo frame rate sollte wählbar sein 9/18ms
- von Latenz ist bei FrSky nie die Rede, das ist aber der große Vorteil von x-fire. Hat FrSky das überhaupt kapiert?
- man müsste dazu nur die x-fire 400kB Ansteuerung kopieren, in OpenTX ist die ja schon funktionsfähig drin
Auch wenn Vieles negativ klingt, finde ich es wichtig und richtig, eine Alternative zu 2.4GHz zu haben. Es muss halt nur funktionieren.
1. Fix the bug of “Telemetry Lost” false alarm.
2. Modify the PWM output period and improve the compatibility with servos.
Die Telemetrie von meinem F3 FC hat leider mit der LBT Version immer noch nicht funktioniert, bzw. nur mit Aussetzern. In der FCC Variante dafür einwandfrei. Beide Versionen gehen bei ~ 50dB RSSI in den Failsafe. Die default RSSI Warnungen hört man vor einem Crash also nie, genauso, wie viele User es sich wünschen
.Was seltsam war, die Reichweite im LBT rangetest Modus war sehr unterschiedlich. Von 300m bis über 1km war alles drin. Außerdem kamen kurz Geräusche aus meinem X9D Lautsprecher, wie wenn das R9M selbstständig mal die Power erhöht hätte. Das fasst sich nicht schön an.
FrSky wird wohl nur unter Druck etwas tun. Mittlerweile habe ich den Eindruck, dass die Chinesen erwachsene Männer, die mit ferngesteuerten Modellen spielen, nicht wirklich ernst nehmen
Deren Kohle nehmen sie aber vermutlich ernst. Deswegen kann man nur hoffen, dass nicht mehr viele den Mist kaufen, bevor sie die Firmware auf die Reihe kriegen. Engel liefert R9 gar nicht mehr aus, das funktioniert natürlich auch.Meine subjektive Meinung zum R9 System:
- die 500mW Variante zieht nur massiv den Akku leer, die könnte man streichen (ist aber für manche sicher ein Kaufargument)
- die 25mW Variante geht ein paar km weit, das reicht
- Telemetrie muss mit FCs funktionieren
- RSSI muss auf die anderen Empfänger angepasst werden -> Failsafe bei ~ 36-38dB RSSI
- als Backup für 2.4GHz ist die 25mW Variante perfekt, aber 8 Kanäle sind oft zu wenig
- ein weiterer 25mW Modus ohne Telemetrie, dafür mit 16 Kanälen würde Sinn machen (wenn es technisch geht)
- die Servo frame rate sollte wählbar sein 9/18ms
- von Latenz ist bei FrSky nie die Rede, das ist aber der große Vorteil von x-fire. Hat FrSky das überhaupt kapiert?
- man müsste dazu nur die x-fire 400kB Ansteuerung kopieren, in OpenTX ist die ja schon funktionsfähig drin
Auch wenn Vieles negativ klingt, finde ich es wichtig und richtig, eine Alternative zu 2.4GHz zu haben. Es muss halt nur funktionieren.
Hallo Bernd,
stimme Dir voll zu. Da das R9-System für mich ausschliesslich als Backup zum 2.4 GHz in Frage kommt, werde ich es erst kaufen, wenn es mit 25mW, deaktivierbarer Telemetrie und 16 Kanälen funktionsfähig erhältlich ist, praktisch als R9+ Empfänger, der von der technischen Auslegeung gezielt als Backup-Empfänger beabsichtigt ist. Der ganze "LongRange-Käse", wie von FrSky immer noch beworben und als Konkurrenzprodukt zum Crossfire beabsichtigt, ist meiner Meinung nach komplett daneben, weil ich dafür nirgends einen legalen Massenmarkt sehe (wg LOS-Regularien fast überall in der Welt). Die hätten besser daran getan, konsequent von Beginn an auf Link-Backup-System zu setzen, sowohl in Punkto Design als auch in Vermarktung.
Da Du ja recht fleissig in RCG zu diesem R9-System postest und FrSky da ja wohl auch mitliest, vielleicht machst Du da noch mal nen Kommentar zum definitiven Nachteil der Beschränkung auf 8 Kanäle für ein Backup-System und der Forderung, hier doch alle 16 Kanäle zu benötigen.
stimme Dir voll zu. Da das R9-System für mich ausschliesslich als Backup zum 2.4 GHz in Frage kommt, werde ich es erst kaufen, wenn es mit 25mW, deaktivierbarer Telemetrie und 16 Kanälen funktionsfähig erhältlich ist, praktisch als R9+ Empfänger, der von der technischen Auslegeung gezielt als Backup-Empfänger beabsichtigt ist. Der ganze "LongRange-Käse", wie von FrSky immer noch beworben und als Konkurrenzprodukt zum Crossfire beabsichtigt, ist meiner Meinung nach komplett daneben, weil ich dafür nirgends einen legalen Massenmarkt sehe (wg LOS-Regularien fast überall in der Welt). Die hätten besser daran getan, konsequent von Beginn an auf Link-Backup-System zu setzen, sowohl in Punkto Design als auch in Vermarktung.
Da Du ja recht fleissig in RCG zu diesem R9-System postest und FrSky da ja wohl auch mitliest, vielleicht machst Du da noch mal nen Kommentar zum definitiven Nachteil der Beschränkung auf 8 Kanäle für ein Backup-System und der Forderung, hier doch alle 16 Kanäle zu benötigen.
So allmählich ergibt sich ein Bild:
Die R9 failsafen unterschiedlich zwischen 42 und 54dB RSSI. Die Reichweite ist nicht betroffen. Das bedeutet im Moment, wenn man RSSI Warnungen bekommen will, dann muss man den eigenen, individuellen Failsafe RSSI ermitteln und dann die Warnungen entsprechen setzen. +6dB und +3dB dürften ganz gut passen.
Wenn das hardwareabhängig ist, dann hat FrSky ein Problem und müsste diese Vorgehensweise in die Beschreibung packen. Die Folgen kann man sich ausmalen
Wenn es mit ihrem kuriosen RSSI scaling beim R9 zusammenhängt, kriegen sie es mit einer Firmwareänderung in den Griff.
Die R9 failsafen unterschiedlich zwischen 42 und 54dB RSSI. Die Reichweite ist nicht betroffen. Das bedeutet im Moment, wenn man RSSI Warnungen bekommen will, dann muss man den eigenen, individuellen Failsafe RSSI ermitteln und dann die Warnungen entsprechen setzen. +6dB und +3dB dürften ganz gut passen.
Wenn das hardwareabhängig ist, dann hat FrSky ein Problem und müsste diese Vorgehensweise in die Beschreibung packen. Die Folgen kann man sich ausmalen
Wenn es mit ihrem kuriosen RSSI scaling beim R9 zusammenhängt, kriegen sie es mit einer Firmwareänderung in den Griff.
Moin, kann mal jemand seinen R9 an den Logicanalyzer hängen? Ich habe den starken Verdacht, dass das SBus Signal, genau wie das SPort Signal, eine Macke hat. Mein Ersatz R9M ist noch auf Kreuzfahrt.
Ein Vergleich mit einem anderen SBus Signal wäre perfekt.
Ein Vergleich mit einem anderen SBus Signal wäre perfekt.
mit der Firmware 180202 kann ich die beschriebenen Effekte nicht mehr nachvollziehen.
( leider im Moment auch nicht Messen da ich mal wieder unterwegs bin....)
Ich verwende allerdings keine FC sondern "nur" einen FLVSS, ein GPS ,Tadangos SBus Sensor und konventionelle Servos.
Failsafe liegt bei meinen Modul ( ist eins mit XT30 Buchse) auch reproduzierbar bei Werten unter 40 in >300m Entfernung beim Rangetest....
Ihr denkt dran das im SBus Signal ja auch nur 8 Kanäle übertragen werden und keine 16 wie im X-System?
Ich weiss nicht ob die FCs das alle so können.
Mein X6R gibt nämlich die Kanäle 9..16 mit Mittelstellung aus falls im Sender nur 8 Übertragungskanäle eingestellt sind....
gerade gesehen:
laut Stoscheks Messung wird der SBus beim R9 nicht alle 9ms ausgegeben sondern nur alle 25? ( kann ich auf dem Handy nicht genau erkennen).. damit disqualifiziert sich das Ding für FCs und als Redundanzgeber für andere Systeme...
widerhol die Messung mal bitte mit der neuen FW...
Bei der älteren FW war ja auch die Servoausgabe mit 9ms, die ist jetzt ja OK. Nicht das da die Timer für Servoausgabe und Busausgabe vertauscht waren....
( leider im Moment auch nicht Messen da ich mal wieder unterwegs bin....)
Ich verwende allerdings keine FC sondern "nur" einen FLVSS, ein GPS ,Tadangos SBus Sensor und konventionelle Servos.
Failsafe liegt bei meinen Modul ( ist eins mit XT30 Buchse) auch reproduzierbar bei Werten unter 40 in >300m Entfernung beim Rangetest....
Ihr denkt dran das im SBus Signal ja auch nur 8 Kanäle übertragen werden und keine 16 wie im X-System?
Ich weiss nicht ob die FCs das alle so können.
Mein X6R gibt nämlich die Kanäle 9..16 mit Mittelstellung aus falls im Sender nur 8 Übertragungskanäle eingestellt sind....
gerade gesehen:
laut Stoscheks Messung wird der SBus beim R9 nicht alle 9ms ausgegeben sondern nur alle 25? ( kann ich auf dem Handy nicht genau erkennen).. damit disqualifiziert sich das Ding für FCs und als Redundanzgeber für andere Systeme...
widerhol die Messung mal bitte mit der neuen FW...
Bei der älteren FW war ja auch die Servoausgabe mit 9ms, die ist jetzt ja OK. Nicht das da die Timer für Servoausgabe und Busausgabe vertauscht waren....
Zuletzt bearbeitet:
SBus ist per Definition Futaba (aus dem Kopf) 16 Kanäle, 2 Schalter, Lostframes Flag und Failsafe Flag alle 9ms. Wenn von den 16 Kanälen nur 8 genutzt werden, werden trotzdem 16 Kanalwerte übertragen, 8 sind halt konstante Defaultwerte. Das ist auch bei D16 so.
FrSky kann unmöglich die SBus Definition so weit verbiegen.
Die "sensor lost" Meldungen kommen erst bei niedrigem RSSI. das ist auch etwas seltsam ("telemetry lost" kommt natürlich irgendwann immer).
FrSky kann unmöglich die SBus Definition so weit verbiegen.
Die "sensor lost" Meldungen kommen erst bei niedrigem RSSI. das ist auch etwas seltsam ("telemetry lost" kommt natürlich irgendwann immer).
Zuletzt bearbeitet:
Hier gibt es eine kurze und knackige SBus Definition:
"S.Bus is a serial protocol running at 100kbaud (although I found that it ran at 98kbaud) using 8E2 inverted encoding. It comprises 25 byte packets transmitted once every 7ms. The bytes are as follows.
Start byte 0xf0
16 channels of 11 bits per sample, totalling 22 bytes
Flags byte including 2 digital channels and lost frame/failsafe flags
End byte 0x00
These bytes take about 3ms to be transmitted leaving 4ms gaps... "
Es gibt folgende Ungereimtheiten: Failsafes (nicht verifiziert, nicht wiederholbar, zufällig), die R9 haben unterschiedliche RSSI bei Failsafe zwischen 38 und 54 (verifiziert, wiederholbar) und die "sensor lost" Geschichte (verifiziert, wiederholbar).
Mein F3 FC ist über UART angeschlossen (iNav) und macht natürlich wesentlich mehr Traffic auf dem SPort als ein paar Einzelsensoren. Wenn ich den Empfänger wechsle, R-XSR oder RX8R läuft die Telemetrie perfekt.
Mal sehen, was von FrSky kommt, die sollten die Diskussion in RCG ja mitbekommen haben.
Zuletzt bearbeitet:
Ich geb mich geschlagen
keine Ahnung was Frsky dann in Ihrem SBus Dekoder bzw. Servos programmiert hat das die doch gelaufen sind....
( Die Funktionieren ja auch mit CPPM Signal, nicht nur mit SBus )
kann das mal einer Checken ob das angebliche SBus Signal des R9 nicht ein verkapptes CPPM Signal ist ?
mal sehen ob die RB10 dann auch solche Kapriolen macht, die muss ich dann aber erst aus nem Modell ausbauen...
Ralf
keine Ahnung was Frsky dann in Ihrem SBus Dekoder bzw. Servos programmiert hat das die doch gelaufen sind....
( Die Funktionieren ja auch mit CPPM Signal, nicht nur mit SBus )
kann das mal einer Checken ob das angebliche SBus Signal des R9 nicht ein verkapptes CPPM Signal ist ?
mal sehen ob die RB10 dann auch solche Kapriolen macht, die muss ich dann aber erst aus nem Modell ausbauen...
Ralf
Zuletzt bearbeitet:
Nochmal danke! Öhm, hast du vielleicht die Gelegenheit, einen blackbox log mit 180202 anzuschauen? Der tschechische Kollege kriegt dort 7ms SBus frame rate angezeigt. Das ist kein Misstrauen gegenüber deinen Daten, aber die 7ms stehen halt mal da. Ganz übel wäre es nämlich, wenn beide Messungen korrekt sind und demnach die R9 Firmware mal mit 20 und mal mit 7ms die Frames schicken würde
Wetten würde ich zur Zeit auf gar nichts mehr
Der Kollege hat den R9slim, könnte auch sein, dass der mit 7ms und der große R9 mit 20ms rennt. Wie hat mal eine nette (kleine) Kollegin zu mir gesagt "Liewer klää un zaggisch, wie groß un dabbisch"
Wetten würde ich zur Zeit auf gar nichts mehr
Der Kollege hat den R9slim, könnte auch sein, dass der mit 7ms und der große R9 mit 20ms rennt. Wie hat mal eine nette (kleine) Kollegin zu mir gesagt "Liewer klää un zaggisch, wie groß un dabbisch"
Zuletzt bearbeitet:
Hmm... hatte da einen Verdacht und jetzt mal geschaut:
Da ich ja nur einen Empfänger aktiv haben kann(wollte meine Modellspeicher nicht ändern), hatte ich sie jeweils aktiv gesetzt durch auswahl des Modellspeichers und dann den Sender ausgeschaltet.
Das sind jetzt die Signale, wenn die Empfänger mit dem Sender Kontakt haben, erstes Bild X4R aktiv und zweites Bild der R9 aktiv.
Ich hatte da eigentlich keine Veränderung erwartet...
Da ich ja nur einen Empfänger aktiv haben kann(wollte meine Modellspeicher nicht ändern), hatte ich sie jeweils aktiv gesetzt durch auswahl des Modellspeichers und dann den Sender ausgeschaltet.
Das sind jetzt die Signale, wenn die Empfänger mit dem Sender Kontakt haben, erstes Bild X4R aktiv und zweites Bild der R9 aktiv.
Ich hatte da eigentlich keine Veränderung erwartet...
Ja, sehe ich auch so, der fallback auf 50Hz ist eventuell ein Problem an der Reichweitengrenze. Genau da hatte ich auch die Schwierigkeiten mit dem unerwarteten flightmodechange. Aber wir sind der Sache auf der Spur. Ich muss unbedingt SBus und SPort gleichzeitig loggen, ich hab das Gefühl, da gibt es noch neue Erkenntnisse bei niedrigem RSSI.
Das ist der Hammer: der R9 schaltet bei schwächer werdendem Link von 7 auf 20ms framerate um Ist das ein Bug oder ein Feature? Hängt das mit den "sensor lost" Meldungen zusammen, die auch mit schwächer werdendem Link kommen? Und/oder mit den unglaublichen 1000m+ mit 0.01mW?
Das Teil ist echt eine Wundertüte.
Ist das ein Bug oder ein Feature? Hängt das mit den "sensor lost" Meldungen zusammen, die auch mit schwächer werdendem Link kommen? Und/oder mit den unglaublichen 1000m+ mit 0.01mW?Das Teil ist echt eine Wundertüte.
- Status
