"Quicky mit Ingmar" #18... Telemetrie-Latenz die 2.
- PW
- Offline
- Moderator
- Beiträge: 9721
- Dank erhalten: 3823
Hallo Volker,
Du kannst doch einfach eine Mail zum Jeti Support schicken und diesbezüglich nachfragen. Wir werden Dir Deine Fragen nicht beantworten können.
Gruss
PW
Du kannst doch einfach eine Mail zum Jeti Support schicken und diesbezüglich nachfragen. Wir werden Dir Deine Fragen nicht beantworten können.
Gruss
PW
Rechtsbeistand u.a. bei "Modellflugproblemen"etc. : Rechtsanwälte Wessels & Partner, Tel.: 02362/27065
PW Modellbautechnik ( Jeti Kombiangebote, Beratung/Einstellservice etc.)
PW Modellbautechnik ( Jeti Kombiangebote, Beratung/Einstellservice etc.)
von PW
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- FuniCapi
- Offline
- Platinum Mitglied
- Beiträge: 1730
- Dank erhalten: 853
FuniCapi antwortete auf "Quicky mit Ingmar" #18... Telemetrie-Latenz die 2.
Posted 22 März 2021 11:42 #50
Die JetiExSensor-Lib von Bernd ist so getimed, dass sie alle 150 ms ein Frame mit einer maximalen Länge von 29 Byte sendet. Der Header jedes Frames ist 8 Byte lang und am Ende kommen nochmals 1 Byte für CRC. Somit bleiben 20 Bytes für die Datenblöcke. Das erste Byte eines Datenblocks beinhaltet den Index des Werts und den Datentyp. Danach kommen die eigentlichen Datenbytes. Beim Datentyp 14b sind es 2 Datenbytes. Beim Typ 14b ist somit ein Datenblock 3 Bytes lang und ein Frame kann maximal 6 Werte senden.
Um 32 Werte vom Typ 14b vom Sensor an den Emfpänger zu senden braucht es 7 Frames und damit 7 * 150 ms = 1050 ms. Dies entspricht ziemlich genau dem mittleren Updateintervall von 1061 ms in dem Log von Ingmar. Damit ist klar dass die Umsetzung des Protokolls der Flaschenhals ist.
@Ingmar: Teste doch mal, was passiert wenn du die Senderintervalle in Bernds Library auf 50 ms oder noch weniger setzt. Die Updateintervalle in den Logs müssten entsprechend kürzer werden. Evtl. akzeptiert der Emfpänger auch Frames welche länger als 29 Bytes sind.
Gruss Lukas
Um 32 Werte vom Typ 14b vom Sensor an den Emfpänger zu senden braucht es 7 Frames und damit 7 * 150 ms = 1050 ms. Dies entspricht ziemlich genau dem mittleren Updateintervall von 1061 ms in dem Log von Ingmar. Damit ist klar dass die Umsetzung des Protokolls der Flaschenhals ist.
@Ingmar: Teste doch mal, was passiert wenn du die Senderintervalle in Bernds Library auf 50 ms oder noch weniger setzt. Die Updateintervalle in den Logs müssten entsprechend kürzer werden. Evtl. akzeptiert der Emfpänger auch Frames welche länger als 29 Bytes sind.
Code:
uint8_t JetiExProtocol::DoJetiSend()
{
// send every 150 ms only
if( ( m_tiLastSend + 150 ) <= millis() )
{
m_tiLastSend = millis();
// navigator exit
if( m_bExitNav )
{
SendJetiboxExit();
m_bExitNav = false;
}
// morse alarm
else if( m_alarmChar )
{
SendJetiAlarm( m_alarmChar );
m_alarmChar = 0;
}
// EX frame...
else if( m_pSensorsConst )
{
SendExFrame( m_frameCnt++ );
}
// followed by "simple text" frame
SendJetiboxTextFrame();
}
return 0;
}
Code:
void JetiExProtocol::SendExFrame( uint8_t frameCnt )
{
uint8_t n = 0;
uint8_t i = 0;
// sensor name in frame 0
if( frameCnt == 0 )
{ // sensor name
m_exBuffer[2] = 0x00; // 2Bit packet type(0-3) 0x40=Data, 0x00=Text
m_exBuffer[8] = 0x00; // 8Bit id
m_exBuffer[9] = m_nameLen<<3; // 5Bit description, 3Bit unit length (use one space character)
memcpy( m_exBuffer + 10, m_name, m_nameLen ); // copy label plus unit to ex buffer starting from pos 10
n += m_nameLen + 10;
}
// sensor dictionary: use the first few frames with even numbers to transfer
else if( ( (frameCnt/2) <= m_nSensors && (frameCnt % 2) == 0 ) )
{
for( int nDict = 0; nDict < m_nSensors; nDict++ )
{
JetiSensor sensor( m_dictIdx, this );
if( ++m_dictIdx >= m_nSensors )
m_dictIdx = 0;
if( sensor.m_bActive )
{
m_exBuffer[2] = 0x00; // 2Bit packet type(0-3) 0x40=Data, 0x00=Text
m_exBuffer[8] = sensor.m_id; // 8Bit id
m_exBuffer[9] = (sensor.m_textLen<<3) | sensor.m_unitLen; // 5Bit description, 3Bit unit length
n = sensor.jetiCopyLabel( m_exBuffer, 10 ) + 10; // copy label plus unit to ex buffer starting from pos 10
break;
}
}
}
// send EX values in all other frames
else
{
int bufLen;
int nVal = 0; // count values
m_exBuffer[ 2 ] = 0x40; // 2Bit Type(0-3) 0x40=Data, 0x00=Text
n=8; // start at nineth byte in buffer
do
{
bufLen = 0; // last value buffer length
JetiSensor sensor( m_sensorIdx, this );
if( ++m_sensorIdx >= m_nSensors ) // wrap index when array is at the end
m_sensorIdx = 0;
if( sensor.m_bActive && sensor.m_value != -1 ) // -1 is "invalid"
{
if( sensor.m_id > 15 )
{
m_exBuffer[n++] = 0x0 | (sensor.m_dataType & 0x0F); // sensor id > 15 --> put id to next byte
m_exBuffer[n++] = sensor.m_id;
}
else
m_exBuffer[n++] = (sensor.m_id<<4) | (sensor.m_dataType & 0x0F); // 4Bit id, 4 bit data type (i.e. int14_t)
bufLen = sensor.m_bufLen;
n += sensor.jetiEncodeValue( m_exBuffer, n );
}
if( ++nVal >= m_nSensors ) // dont send twice in a frame
break;
}
while( n < ( 26 - bufLen ) ); // jeti spec says max 29 Bytes per buffer
}
Gruss Lukas
Last Edit:22 März 2021 11:58
von FuniCapi
Letzte Änderung: 22 März 2021 11:58 von FuniCapi.
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- NicoS
- Abwesend
- Platinum Mitglied
- Beiträge: 489
- Dank erhalten: 146
NicoS antwortete auf "Quicky mit Ingmar" #18... Telemetrie-Latenz die 2.
Posted 22 März 2021 11:52 #51
Heute habe ich mehrere logfiles mit Jeti Studio nach Excel konvertiert. Es handelte sich um Logfiles mit 25 -30 Sensormesswerten. Es waren sowohl REX- als auch EX-Empfänger im Einsatz. In keiner dieser Excel-Tabellen waren Lücken sichtbar.
Verwendete Sensoren in verschiedenen Kombinationen: Jeti Mvario2, MRPM, MUI, MGPS2, Expander, SM-Modelbau Unisens-E, GPS-Logger 2, homebrew varioGPS und ein Jeti Mezon Pro mit eingebauten Sensoren.
Nico
Verwendete Sensoren in verschiedenen Kombinationen: Jeti Mvario2, MRPM, MUI, MGPS2, Expander, SM-Modelbau Unisens-E, GPS-Logger 2, homebrew varioGPS und ein Jeti Mezon Pro mit eingebauten Sensoren.
Nico
Last Edit:22 März 2021 12:03
von NicoS
Letzte Änderung: 22 März 2021 12:03 von NicoS.
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- STer
- Offline
- Senior Mitglied
- Beiträge: 76
- Dank erhalten: 51
STer antwortete auf "Quicky mit Ingmar" #18... Telemetrie-Latenz die 2.
Posted 22 März 2021 12:08 #52
Bei meinen Mesungen mit 40 Telemetriewerten, siehe #38, waren auch keine Lücken in den Exceltabellen zu sehen.
M.f.G.
STer
M.f.G.
STer
von STer
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- gecko_749
- Offline
- Platinum Mitglied
- Beiträge: 987
- Dank erhalten: 295
gecko_749 antwortete auf "Quicky mit Ingmar" #18... Telemetrie-Latenz die 2.
Posted 22 März 2021 13:04 #53
@Lukas
32 durch 6 sind 5,33 - es sind in deinem Beispiel 5 1/3 Pakete nötig für 32 Werte - wenn es nicht 32 verschiedene sind. IDs über 15 benötigen 1 zusätzliches Byte für die ID.
Also wenn die IDs der Reihe nach übertragen werden.
Frame 1 - ID 1 - 6
Frame 2 - ID 7 - 12
Frame 3 - ID 13 - 17
Frame 4 - ID 18 - 22
Frame 5 - ID 23 - 27
Frame 6 - ID 28 - 32
Somit werden 6 Frames gebraucht.
Die Framerate kann nicht beliebig erhöht werden. Im Ex Protokoll kommen noch 34 Bytes JetiBox - Daten hinzu. Nach jedem Paket muß der Sensor 20 ms für eine Antwort pausieren.
Ein Frame mit 63 Bytes dauert grob 80ms plus die 20ms warten ist rund 100 ms für 1 Frame. Das sind 10 Frame / s.
Mehr Frames gehen nur wenn man weniger EX-Daten sendet oder man sich ausserhalb der Spec bewegt.
Frames mit mehr als 29 Bytes werden spätestens im TX verworfen.
Gruß
32 durch 6 sind 5,33 - es sind in deinem Beispiel 5 1/3 Pakete nötig für 32 Werte - wenn es nicht 32 verschiedene sind. IDs über 15 benötigen 1 zusätzliches Byte für die ID.
Also wenn die IDs der Reihe nach übertragen werden.
Frame 1 - ID 1 - 6
Frame 2 - ID 7 - 12
Frame 3 - ID 13 - 17
Frame 4 - ID 18 - 22
Frame 5 - ID 23 - 27
Frame 6 - ID 28 - 32
Somit werden 6 Frames gebraucht.
Die Framerate kann nicht beliebig erhöht werden. Im Ex Protokoll kommen noch 34 Bytes JetiBox - Daten hinzu. Nach jedem Paket muß der Sensor 20 ms für eine Antwort pausieren.
Ein Frame mit 63 Bytes dauert grob 80ms plus die 20ms warten ist rund 100 ms für 1 Frame. Das sind 10 Frame / s.
Mehr Frames gehen nur wenn man weniger EX-Daten sendet oder man sich ausserhalb der Spec bewegt.
Frames mit mehr als 29 Bytes werden spätestens im TX verworfen.
Gruß
Last Edit:22 März 2021 13:07
von gecko_749
Letzte Änderung: 22 März 2021 13:07 von gecko_749.
Folgende Benutzer bedankten sich: Raf, FuniCapi
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
- dvcam99
- Offline
- Premium Mitglied
- Beiträge: 84
- Dank erhalten: 29
dvcam99 antwortete auf "Quicky mit Ingmar" #18... Telemetrie-Latenz die 2.
Posted 22 März 2021 13:08 #54
Zitat Lukas
Ich glaube der Flaschenhals ist die Kombination Sensor - Implementierung Protokoll - Empfänger. Ich kann mir gut vorstellen dass ein schlecht programmierter Sensor den Empfänger telemetriemässig aus dem Takt bringt. Alte R-Empfänger sind dann wahrscheinlich auch anfälliger als neuere REX-Empfänger. Auch zwischen Ex-Telemetrie und EX-Bus wird es sicher Unterschiede geben.
Hallo Lukas,
welcher Takt soll das im Jeti EX Protokoll sein? In dieser Konstellation ist der Sensor Master und der Empfänger Data Concentrator, also Datensammler, oder sehe ich da etwas falsch!!?? Der Sensor hat aus meiner Sicht gar keinen Einfluss auf den Empfänger wie dieser mit den angebotenen Daten-Frames umgeht. Es gibt auch keine Festlegung, jedenfalls ist mit keine bekannt, in der ein Frame-Intervall für den Sensor vorgeschrieben oder definiert ist.
Bei Jeti EX-Bus sieht das Geschäft anders aus, da synchronisiert / bestimmt der Empfänger die Datenabfrage beim Sensor.
Viele Grüße
Dirk
Ich glaube der Flaschenhals ist die Kombination Sensor - Implementierung Protokoll - Empfänger. Ich kann mir gut vorstellen dass ein schlecht programmierter Sensor den Empfänger telemetriemässig aus dem Takt bringt. Alte R-Empfänger sind dann wahrscheinlich auch anfälliger als neuere REX-Empfänger. Auch zwischen Ex-Telemetrie und EX-Bus wird es sicher Unterschiede geben.
Hallo Lukas,
welcher Takt soll das im Jeti EX Protokoll sein? In dieser Konstellation ist der Sensor Master und der Empfänger Data Concentrator, also Datensammler, oder sehe ich da etwas falsch!!?? Der Sensor hat aus meiner Sicht gar keinen Einfluss auf den Empfänger wie dieser mit den angebotenen Daten-Frames umgeht. Es gibt auch keine Festlegung, jedenfalls ist mit keine bekannt, in der ein Frame-Intervall für den Sensor vorgeschrieben oder definiert ist.
Bei Jeti EX-Bus sieht das Geschäft anders aus, da synchronisiert / bestimmt der Empfänger die Datenabfrage beim Sensor.
Viele Grüße
Dirk
von dvcam99
Bitte Anmelden oder Registrieren um der Konversation beizutreten.
Ladezeit der Seite: 1.030 Sekunden