Willkommen, Gast
Benutzername: Passwort: Angemeldet bleiben:
Hier gibt es news und noch mal news

THEMA:

"Quicky mit Ingmar" #18... Telemetrie-Latenz die 2. 22 Mär 2021 11:16 #49

  • PW
  • PWs Avatar
  • Offline
  • Moderator
  • Moderator
  • Beiträge: 9413
  • Dank erhalten: 3564
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
Rechtsbeistand u.a. bei "Modellflugproblemen"etc. : Rechtsanwälte Wessels & Partner, Tel.: 02362/27065

PW Modellbautechnik ( Jeti Kombiangebote, Beratung/Einstellservice etc.)

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

"Quicky mit Ingmar" #18... Telemetrie-Latenz die 2. 22 Mär 2021 11:42 #50

  • FuniCapi
  • FuniCapis Avatar
  • Offline
  • Platinum Boarder
  • Platinum Boarder
  • Beiträge: 1666
  • Dank erhalten: 785
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.
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;
}
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

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

Letzte Änderung: von FuniCapi.

"Quicky mit Ingmar" #18... Telemetrie-Latenz die 2. 22 Mär 2021 11:52 #51

  • NicoS
  • NicoSs Avatar
  • Offline
  • Platinum Boarder
  • Platinum Boarder
  • Beiträge: 487
  • Dank erhalten: 145
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

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

Letzte Änderung: von NicoS.

"Quicky mit Ingmar" #18... Telemetrie-Latenz die 2. 22 Mär 2021 12:08 #52

  • STer
  • STers Avatar
  • Offline
  • Senior Boarder
  • Senior Boarder
  • Beiträge: 71
  • Dank erhalten: 47
Bei meinen Mesungen mit 40 Telemetriewerten, siehe #38, waren auch keine Lücken in den Exceltabellen zu sehen.

M.f.G.
STer

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

"Quicky mit Ingmar" #18... Telemetrie-Latenz die 2. 22 Mär 2021 13:04 #53

  • gecko_749
  • gecko_749s Avatar
  • Offline
  • Platinum Boarder
  • Platinum Boarder
  • Beiträge: 987
  • Dank erhalten: 294
@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ß
Folgende Benutzer bedankten sich: Raf, FuniCapi

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

Letzte Änderung: von gecko_749.

"Quicky mit Ingmar" #18... Telemetrie-Latenz die 2. 22 Mär 2021 13:08 #54

  • dvcam99
  • dvcam99s Avatar
  • Offline
  • Expert Boarder
  • Expert Boarder
  • Beiträge: 84
  • Dank erhalten: 29
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

Bitte Anmelden oder Registrieren um der Konversation beizutreten.

Ladezeit der Seite: 0.258 Sekunden
Powered by Kunena Forum