Forum: HF, Funk und Felder Zeitmessung mit Funk


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Fabian G. (fabian_g)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ich brauche eure Hilfe ;)

Mein Ziel ist es eine Zeitmessung für den Mountainbike-Sport zu bauen.

Um euch zu veranschaulichen wie ich es mir vorstelle, habe ich euch eine 
Zeichnung angehängt.
Die beiden Lichtschranken sollen nur einen Impuls an die Anzeige 
schicken und diese fängt dann an oder hört auf zu zählen.
Ich habe erfahrung mit uC programmieren jedoch keine mit Funk. Ich habe 
viel recherchiert aber ich konnte keinen Anhaltspunkt finden.


Was ist die einfachste und schnellste Variante einen Impuls via Funk zu 
senden und diesen zu empfangen?

Grüsse
Fabian

von CC (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Pi, WLAN, NTP zum Synchronisieren der Uhren? Klingt für mich als 
einfachste Lösung. Was für eine Genauigkeit brauchst Du? Sekunden? 
1/10s? 1/100s?

von CC (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Alle Entfernungen wären auch noch interessant.

von CC (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Alternativ GPS für Zeit...

von Fabian G. (fabian_g)


Bewertung
0 lesenswert
nicht lesenswert
Die Funkdistanz beträgt etwa bis 200m.

Genauigkeit von 10ms wäre in Ordnung, 1ms wäre besser

Ich bin ein kompletter Neuling in Funk.
Eigentlich bräuchte ich nur ein Modul welches den Impuls der 
Lichschranke sendet, oder?
Und dazu natürlich ein Modul welches den Impuls empfängt und es dann 
weiter gibt an einen uC.

: Bearbeitet durch User
von CC (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn Du sicherstellen kannst, dass es in der Zeit garantiert ankommt, 
dann kannst Du einen Impuls senden. Über die Strecke könnte IEEE802.15.4 
noch gehen, je nach Antenne und Umgebung.

Wobei ich wie gesagt die "PC"-basierte Lösung vorziehen würde. Uhren 
sind im Takt, einer sendet die absolute Startzeit, Display fängt an zu 
zählen, Ziel sendet absolute Endzeit. Wenn auf dem Display das dann nen 
Moment weiterläuft, ist das glaube ich (reine Vermutung, nie was mit 
Rennen/Timekeeping gemacht) nicht so dramatisch.

Vermutlich kommen aber gleich die Hardliner, die selbst eine uC-basierte 
Lösung für Overkill halten, weil man das doch sicher mit ein paar 
74er-Gattern und nem 555er erschlagen kann ;-)

von Fabian G. (fabian_g)


Bewertung
0 lesenswert
nicht lesenswert
IEEE802.15.4 ist ZigBee?

Ich denke eine PC-basierte Lösung ist zu viel. Habe noch vergessen zu 
sagen, dass die Lichtschranken Batteriebetrieben sein sollen.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Fabian G. schrieb:
> Genauigkeit von 10ms wäre in Ordnung, 1ms wäre besser

Beim Sport ist doch meist grad mal eine Zehntelsekunde üblich, eine 
tausendstel hab ich noch nirgends gesehen.

von Pandur S. (jetztnicht)


Bewertung
0 lesenswert
nicht lesenswert
Eine Zeitmessung alleine ist doch veraltet. Du musst auch noch die 
Startnummern mit erfassen. Also eine RFID Karte erfassen, beim Anfahren 
und bei der Ankunft.

von CC (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Fabian G. schrieb:
> IEEE802.15.4 ist ZigBee?

Umgangssprachlich schon ;-) ZigBee ist ab Layer 3, 802.15.4 liegt 
darunter.

Mit Akkupacks halten auch Pis recht lange, Zeitsync mit GPS-Modul ist 
auch auf nem uC möglich, IMHO insgesamt aber mit mehr 
Entwicklungsaufwand verbunden, aber dennoch natürlich möglich und ggf. 
eleganter...

von Fabian G. (fabian_g)


Bewertung
0 lesenswert
nicht lesenswert
Sapperlot W. schrieb:
> Eine Zeitmessung alleine ist doch veraltet. Du musst auch noch die
> Startnummern mit erfassen. Also eine RFID Karte erfassen, beim Anfahren
> und bei der Ankunft.

Die Zeitmessung ist nicht für ein Wettkampf. Sie ist Privat zum 
Trainieren. Dort reicht eine normale Zeitmessung.

Bernd K. schrieb:
> Beim Sport ist doch meist grad mal eine Zehntelsekunde üblich, eine
> tausendstel hab ich noch nirgends gesehen.

In unserem Sport gibt es öfters Zeitmessung die auf tausendstel genau 
sind.

CC schrieb:
> Mit Akkupacks halten auch Pis recht lange, Zeitsync mit GPS-Modul ist
> auch auf nem uC möglich, IMHO insgesamt aber mit mehr
> Entwicklungsaufwand verbunden, aber dennoch natürlich möglich und ggf.
> eleganter...

Die Zeitmessung sollte kompakt sein. Meinst du nicht mit dem 
GPS-Modul,Pi und Akku-PAck braucht es zuviel Platz?

Nochmal zur veranschaulichung habe ich ein Beispiel gefunden, wie ich es 
mir vorstelle: 
http://browertiming.com/images/products/tc_system/start_pod/tc_timing_system_3.png

: Bearbeitet durch User
von CC (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Fabian G. schrieb:
> Meinst du nicht mit dem
> GPS-Modul,Pi und Akku-PAck braucht es zuviel Platz?

Ich kenne Deine Anforderungen nicht so gut wie Du :-)
Pi war nur ein Beispiel, weil leicht verfügbar. Linux-basierte Dinge 
gibt's auch in klein, vocore.io zum Beispiel. ESP32 könnte ein 
Zwischending sein.

Oder halt 8-bitter auf eigenem Board.
Wenn Du sicherstellen kannst, dass das Startsignal garantiert innerhalb 
einer bestimmten Zeit da ist, kannst Du Dir die synchronisierung der 
Uhren sparen und es wird wirklich klein. Nur wäre es dann halt doof, 
wenn es erst 3 Retransmissions gibt, weil da ein Störer auf dem Kanal 
war, daher kam meine Idee mit NTP/GPS etc... Was sich aber halt auch auf 
kleinen uCs nachbauen lässt, gar keine Frage.
Je nach Umgebung reichen vielleicht auch diese einfachen OOK-Radios...

von Ralph B. (rberres)


Bewertung
0 lesenswert
nicht lesenswert
schaue mal hier

https://www.reichelt.de/Bausaetze/TX-433-MHZ/3/index.html?ACTION=3&LA=446&ARTICLE=153457&GROUPID=7836&artnr=TX+433+MHZ&SEARCH=funkmodul

und

https://www.reichelt.de/Bausaetze/RX-433-MHZ/3/index.html?ACTION=3&LA=517&ARTICLE=153830&GROUPID=7836&trstct=lsbght_sldr::153457

Damit kannst du deine Impulse übertragen. Für 200m könnte das reichen.

als Antenne an Sender und Empfänger 17cm Draht oder falls damit die 200m 
nicht erreicht werden eine kleine Yagi anschließen.

Ralph Berres

von chris (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Start com gleicher Lichtschranke oder nicht?

von M.A. S. (mse2)


Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Start com gleicher Lichtschranke oder nicht?

Hä?

von Funker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ralph B. schrieb:
> Damit kannst du deine Impulse übertragen. Für 200m könnte das reichen.

Aber nicht, wenn nebenan gerade das Funkthermometer die aktuelle 
Temperatur übermittelt. Um sicher zu stellen, das der Zeitpunkt der 
Lichtschrankenunterbrechung beim Empfänger ankommt, hilft nur eine Art 
Timestamp im Datentelegramm, dass dann ggf. auch später gesendet werden 
kann, wenn die Luft wieder rein ist.

Falls es allerdings unkritisch ist, ob die Unterbrechungsinformation bei 
der Anzeige ankommt, ist die direkte Übertragung des Pulses auf einem 
Funkband, auf dem sich alles möglich rumtreiben kann (bis zu 
Primärnutzern, die minutenlang die Frequenz für sich belegen und das 
nicht nur mit 10mW), sicher eine angemessene Lösung ;-(

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hier eine Funktion welche ich für sowas einsetze, sie gibt einen
Timestamp zurück welcher ins EEprom geschrieben wird und nachträglich
ausgelesen werden kann. Auch können und werden die 15 letzten
timing events in gewissen Zeitabständen neu übertragen werden sowie
eine 16.te Zeit welche eine der EEpromzeiten enthält ausser den letzten
15. Man sollte der cpu ein TXCO spendieren, FOX924B-16.000 oder
FOX924B-10.000 , kann aber auch eine SW korrectur machen.
Sender müssen vor Gebrauch syncronisiert werden mittels Klinkenstecker 
und
RS232 (ttl) Sender über welche auch die HW-ID programmiert werden kann 
sowie
das EEprom ausgelesen werden kann.
Passt aber nicht mit deiner bestehenden Tafelanzeige zusammen, wollte 
nur
zeigen wie es anderswo gelöst wird.



//////////////////////////////////////x///////////////////////


unsigned long
send_time(byte id) {
  byte sum=id<<4; byte i; word w=0; dword ret;
  unsigned long long time;
  uint8_t oldSREG = SREG, t;

#if USE_HAMMING
  byte idx=0; byte buffer[12];
#define send(x)  buffer[idx++]=i=x, sum+=i&0xf, sum+=(i>>4)&0xf, 
sum&=0xf
#define encode()  if(id!=-1) hammingEnc(buffer)  // 24:18 hamming must 
be included
#define transmit()  if(id!=-1) { rfpreamble(5); 
for(i=0;i<sizeof(buffer);i++) rfputch(buffer[i]); }
#define enableTx()
#else
#define send(x)    if(id!=-1) rfputch(i=x), sum+=i&0xf, sum+=(i>>4)&0xf, 
sum&=0xf
#define enableTx()  if(id!=-1) rfpreamble(5);
#define transmit()
#define encode()
#endif

  cli();
  time = timer0_overflow_count;
  i = TCNT0;


  if ((TIFR0 & _BV(TOV0)) && (i < 255))
                w=0x100;

    SREG = oldSREG;

  time<<=8; w|=i; time+=w;

// using prescaler 8 the resolution is 0.5uS
#if MICROS_SHIFT>0
  time <<= MICROS_SHIFT;  // 4uS on prescaler 64 with value 2 (default)
#endif

#if MICROS_SHIFT<0
  time >>= -MICROS_SHIFT;  // 1uS on prescaler 8 with value 1
#endif



  enableTx();

  send(hwid(0)); // 1 Byte

// hours()
  i=0;
  while(time>=36000000000ULL) time-=36000000000ULL, i+=0x10;
  while(time>=3600000000ULL)   time-=3600000000ULL, i++;
  ret =(i>>4)*10+(i&0xf); send(i);

// minutes()
  i=0;
  while(time>=600000000ULL) time-=600000000ULL, i+=0x10;
  while(time>=60000000ULL) time-=60000000ULL, i++;
  ret<<=6; ret|=(i>>4)*10+(i&0xf); send(i);

// seconds()
  i=0;
  while(time>=10000000ULL) time-=10000000ULL, i+=0x10;
  while(time>=1000000ULL) time-=1000000ULL, i++;
  ret<<=6; ret|=(i>>4)*10+(i&0xf); send(i);

// sec_100()
  i=0;
  while(time>=100000ULL) time-=100000ULL, i+=0x10;
  while(time>=10000ULL) time-=10000ULL, i++;
  ret<<=7; ret|=(i>>4)*10+(i&0xf); send(i);

  w=ret;  // binary packed time for sending

// sec_10000()
  i=0;
  while(time>=1000ULL) time-=1000ULL, i+=0x10;
  while(time>=100ULL) time-=100ULL, i++;
  ret<<=7; ret|=(i>>4)*10+(i&0xf); send(i);

//
  send(w); send(w>>8); // 2 Bytes binary packed data.
  send(sum|(id<<4));   // 1 Byte

  encode(); transmit();
  return ret;
}

/////////////////////////////////////////////////////////////
// hardware id(3) + type(1)=0 + data(4)  // timing data
// hardware id(3) + type(1)=1 + subtype(3)
byte hwid(byte type) {
  static byte cycle;
  static unsigned long clock=send_time(-1);
  byte i;
  type&=7;
  if(cycle==0) i=~battery();
  if(cycle==1) i= battery();
  if(cycle==2) i=~clock>>4;
  if(cycle==3) i=~temperature();
  if(cycle==4) i=seq
  if(cycle==5) i=clock>>8;
  if(cycle==6) i=~seq>>4;
  if(cycle==7) i=clock>>16;
  if(cycle==8) i=temperature()>>4;
  if(cycle==9) i= battery()>>4;
  if(cycle==10) i=seq>>8;
  if(cycle==11) i=~clock>>12;
  if(cycle==12) i=~battery()>>8;
  if(cycle==13) i=~seq>>12;
  if(cycle==14) i=HWID>>4;
  if(cycle==15) i=clock;
  if(cycle>=16) i=0x5,cycle=0,clock=send_time(-1); else cycle++; seq++;
  if(!type) {
    return HWID<<5|i&0xf;
  }
  return HWID<<5|0x10|type;
}

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Sender müssen vor Gebrauch syncronisiert werden mittels Klinkenstecker ...

Welch Zirkus. Wenn man sowieso eine Funkstrecke zu Anzeige aufbaut, kann 
man die auch zur Synchronisation nutzten. Was mit Netzwerk mit UDP 
funktioniert, sollte doch auch mit Funkstrecken zu machen sein. Eine 
passende Funklücke im allgemeinen 433MHz-Geplapper wird sich schon 
finden. Das NTP würde genau für die Synchronisierung von Uhren in 
Computersystemen entwickelt.

von M.A. S. (mse2)


Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Sender müssen vor Gebrauch syncronisiert werden mittels Klinkenstecker

Fabian G. schrieb:
> Genauigkeit von 10ms wäre in Ordnung, 1ms wäre besser

Hast Du Dir mal ausgerechnet, wie lange zwei Quarzuhren nach einmaliger 
Synchronisation dafür genau genug beieinander wären?
Ich sage: nicht sehr lange...

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bei mir haben waren nur Sender und keine Tranceiver verbaut,
somit ist keine "funk" syncronisierung möglich. Auch ist diese nicht so 
genau
wie eine richtige Syncronisation mittels Kabels.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.