"Quicky mit Ingmar" #18... Telemetrie-Latenz die 2.
- PW
- 
				 Offline Offline
- Moderator
- 
				  
- Beiträge: 9860
- Dank erhalten: 3882
		
		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: 1854
- Dank erhalten: 917
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
- 
				 Offline Offline
- 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 Offline
- Premium Mitglied
- 
				  
- Beiträge: 88
- 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: 294
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 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.153 Sekunden	
	