Forum: Mikrocontroller und Digitale Elektronik MQTT unterbrechungsfrei senden


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 Pat (elpat)


Lesenswert?

Hallo!

Ich möchte von einem Gerät ca. alle 0,5s eine Nachricht per MQTT an 
einen Mosquitto-Server senden. Die Abstände zwischen den Nachrichten 
müssen nicht exakt eingehalten werden, aber mehr als 1s sollten sie 
nicht sein.
(Eine Überschreitung führt nicht zur Katastrophe, sollte aber so selten 
wie möglich vorkommen...)

Ich habe dazu den ESP32 und einen SIM7000G ins Auge gefasst.

Habt ihr Erfahrungen mit dieser Kombination? Könnt ihr mir vielleicht 
sagen, worauf ich achten sollte, um möglichst wenig Aussetzer zu haben?
(Die Anwendung ist mobil, aber stets in einem mit Mobilfunk gut 
abgedeckten Gebiet...)

Danke im Voraus!
Pat

von Helmut -. (dc3yc)


Lesenswert?

Pat schrieb:
> Ich habe dazu den ESP32 und einen SIM7000G ins Auge gefasst.

Verwende eine Übertragungsschicht, deren Latenz du selber im Griff hast. 
Mobilfunk gehört nicht unbedingt dazu. Wenn du es in dem Zeitraster 
brauchst, sende einen Zeitstempel mit. Oder überlege, ob du es wirklich 
so schnell brauchst.

von Rüdiger B. (rbruns)


Lesenswert?

Ein ESP01 Modul in meinem Stromzähler macht alle 1s ein Update auf der 
Weboberfläche, bei Tasmota lässt sich m.W.n. der MQTT Abstand aber nicht 
so eng einstellen.

von Pat (elpat)


Lesenswert?

Helmut -. schrieb:
> Verwende eine Übertragungsschicht, deren Latenz du selber im Griff hast.

Danke für den Tipp, leider bin ich allerdings auf das Mobilfunknetz 
angewiesen, da das Gebiet, das abgedeckt werden soll, einfach zu groß 
ist. Es muss eine ganze Stadt abgedeckt werden. Ich dachte auch schon an 
LORA, aber wegen der Gebäude in Kombination mit der Größe des Gebietes 
ist das einfach keine Option.

Aber es muss doch möglich sein, über Mobilfunk innerhalb einer Sekunde 
etwas zu übertragen!? Man kann ja über das Mobilfunk auch telefonieren, 
das braucht ja viel weniger Latenz!?

Rüdiger B. schrieb:
> Ein ESP01 Modul in meinem Stromzähler macht alle 1s ein Update auf der
> Weboberfläche, bei Tasmota lässt sich m.W.n. der MQTT Abstand aber nicht
> so eng einstellen.

Danke für deine Erfahrung!

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Magst Du denn verraten, aus welchem Grund so eine häufige und schnelle 
Übertragung notwendig ist?

von Rüdiger B. (rbruns)


Lesenswert?

Das ist wie immer hier im Forum Streng geheim, jemand könnte ja die Idde 
klauen.
Spielen wir einfach mit dem Gedanken das Radioaktivität und Position 
erfasst wird.

von Jens M. (schuchkleisser)


Lesenswert?

Pat schrieb:
> Aber es muss doch möglich sein, über Mobilfunk innerhalb einer Sekunde
> etwas zu übertragen!?

Wenn du im Monat 2,7 Millionen Gespräche aufbaust oder 750 Stunden mit 
deiner Flatrate telefonierst, wird dir dein Anbieter den Vertrag noch 
vor der ersten Abrechnung kündigen.

Pat schrieb:
> Es muss eine ganze Stadt abgedeckt werden. Ich dachte auch schon an
> LORA, aber wegen der Gebäude in Kombination mit der Größe des Gebietes
> ist das einfach keine Option.

Na, wenn LoRa bzw. LoRaWAN nicht genau dafür erfunden wurde....
Aber auch hier: solche Datenraten = Nö.

Die Werte eine Stunde speichern und als Klotz übertragen ist keine 
Option?
Warum bitte muss man von einem Fahrzeug aus eine Live-Verbindung haben? 
Das ist das Ziel von 5G (Jede Milchkanne und so), aber selbst da ist es 
weder Live noch Dauerhaft geplant, einfach weil das Netz das nicht 
hergibt.

von Εrnst B. (ernst)


Lesenswert?

Vielleicht ist es auch zweimal pro Sekunde ein Ultra-Hochauflösendes 
Bild?

> The MQTT protocol itself defines a MQTT PUBLISH payload size limit of 256MB.

Ohne weitere Einschränkung seitens des TO:
512 Megabyte / Sekunde geht nicht über Mobilfunk. Das SIM7000G limitiert 
schon bei deutlich weniger als einem Tausendstel davon.

Insofern: Nein, geht im Allgemeinen nicht. Aber vielleicht hat der TE ja 
einen ganz speziellen Sonderfall, in dem es doch geht.

von Pat (elpat)


Lesenswert?

Sorry, dass ich das nicht gleich schrieb:
ein Paket hat nur ca. 100-200 Byte, wenn man die reine Payload 
hernimmt...

Es geht nur darum, dass die Pakete sich nicht mehr als 0,5 Sekunden 
verspäten sollen, also dass die Verbindung stabil bleibt.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Pat schrieb:
> Aber es muss doch möglich sein, über Mobilfunk innerhalb einer Sekunde
> etwas zu übertragen!?
Meistens schon. Manchmal nicht.

Pat schrieb:
> dass die Pakete sich nicht mehr als 0,5 Sekunden verspäten
Das musst du mit deinem Handynetzanbieter/Verbindungsprovider 
vereinbaren. Der wird dir das nicht (auch nicht für viel Geld) 
garantieren.

Pat schrieb:
> Es geht nur darum, dass die Pakete sich nicht mehr als 0,5 Sekunden
> verspäten sollen, also dass die Verbindung stabil bleibt.
Beschreib doch mal das Problem, und eben nicht nur deinen derzeitigen 
Lösungsansatz für das Problem.

: Bearbeitet durch Moderator
von Steve van de Grens (roehrmond)


Lesenswert?

Pat schrieb:
> Es geht nur darum, dass die Pakete sich nicht mehr als 0,5 Sekunden
> verspäten sollen, also dass die Verbindung stabil bleibt.

Das kannst du im Mobilfunk Netz vergessen. Es wird nur zeitweise 
zufriedenstellend funktionieren.

von Pat (elpat)


Lesenswert?

Steve van de Grens schrieb:
> Das kannst du im Mobilfunk Netz vergessen. Es wird nur zeitweise
> zufriedenstellend funktionieren.

Warum? Man kann doch auch über Mobilfunk Videotelefonate führen!?

Wie gesagt, dass es nicht zu 100% immer klappt, das ist ganz klar.
Was ich vor allem wissen möchte, ist, was ich tun kann, dass es so gut 
klappt wie technisch MÖGLICH.

Also z.B. welche Einstellungen ich beim SIM7000G vornehmen soll, was ich 
in einem selbst gehosteten Mosquitto konfigurieren kann, etc., damit 
wirklich nur mehr die absolut unvermeidbaren Latenzen übrig bleiben.

(Es gilt ja auch bei einer Verzögerung > 0,5s -> je kürzer, umso 
besser!)


Lothar M. schrieb:
> Beschreib doch mal das Problem

Es sollen Datenpakete mit 100-200 ASCII-Zeichen 2x pro Sekunde von einem 
Fahrzeug zu einem Server gesendet werden. Dies soll insbesondere während 
der Fahrt (bei max. 50km/h) ebenfalls möglich sein. Es ist wichtig, dass 
diese Datenpakete in den meisten Fällen rechtzeitig (<0,5s Latenz) 
ankommen. Wenn mal nicht, dann so zeitnah wie möglich.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Ich würde das mit normalem MQTT over HTTP(S) probieren und entsprechende 
Zeitstempel mitschicken. Wenn man die Zeitpunkte der Messung sehr genau 
braucht oder die Latenz messen möchte, dann beide Seiten (Sender und 
Server) mit GPS-Zeit synchronisieren. Das wird dann gehandhabt wie 
normaler HTTP(S)-Datenverkehr wie bei einem Handy, aber wie schon 
geschrieben wurde, die einzelnen Pakete kommen mal schneller und mal 
langsamer an.

Anders geht's am Ende wahrscheinlich sowieso nicht bzw. wird aufwendig 
und sehr sehr teuer. Man könnte sich natürlich einen eigenen 
Datenfunk-Kanal registrieren, mit genug Sendeleistung reicht es dann für 
eine Stadt... aber bezahlen will man das nicht.

von Pat (elpat)


Lesenswert?

Warum über http(s)? Minimiert das Verzögerungen gegenüber normalem 
MQTT(S)?

Wie sieht es aus mit den Funkstandards? Ist zB 5G zuverlässiger, als 4G? 
4G zuverlässiger als 3G bzw 2G?
4G hat ja auch noch Abstufungen mit Advanced, etc…
Könnte da jemand vielleicht einen Überblick geben?

So genau, dass man sogar die Uhr des Servers synchronisieren muss, muss 
es nicht sein. Es geht nicht um jede Mikrosekunde.
Die Daten haben ohnehin einen Timestamp, das ist nicht das Problem. Es 
geht mehr um die Echtzeit (Abweichungen bis 1s stören wenig, darüber 
hinaus wird‘s unangenehm) -Beobachtung von Signalen aus dem Fahrzeug.

von Joe L. (joelisa)


Lesenswert?

Pat schrieb:
> Es
> geht mehr um die Echtzeit (Abweichungen bis 1s stören wenig, darüber
> hinaus wird‘s unangenehm) -Beobachtung von Signalen aus dem Fahrzeug.

Weisst du was "Q" - ev. schaust Du auch nur zu viel James Bond?

von Abdul K. (ehydra) Benutzerseite


Angehängte Dateien:

Lesenswert?

Über LTE Basisstation 1km entfernt

von Steve van de Grens (roehrmond)


Lesenswert?

Pat schrieb:
> Man kann doch auch über Mobilfunk Videotelefonate führen!?

Ja kann man. Diese funktionieren einigermaßen zufriedenstellen, weil sie 
besonders priorisiert werden. Auf die Priorisierung hast du als "kleiner 
Mann" aber keinen Einfluss.

Wenn du das Netz mal eine ganze Woche lang durch testest, bekommst du 
ein eigenes klares Bild. Dann musst du nicht über Vermutungen 
diskutieren. Ich habe das gemacht und ich kenne das Ergebnis.

von Jens M. (schuchkleisser)


Lesenswert?

Das ist doch die Lösung: Am Fahrzeug eine Kamera, die die Zeiger filmt.
Das geht mit höchster Prio durchs Netz, also live wie gewünscht.
Am anderen Ende ein Fernseher der das ganze anzeigt und ein RPi mit 
Kamera beobachtet das Bild und via KI erkennt er die Zeigerstellungen. 
Das kann man dann per LAN mit geringster Verzögerung als MQTT 
weitergeben.
Problem gelöst! Oder?

Komisch finde ich, das keine genaue Zeit erforderlich ist, aber 
Zeitstempel mitgegeben werden.
Dann muss man unter einer Sekunde Latenz bleiben, sonst wirds 
unangenehm. Nimmt aber ein Übertragungsprotokoll und -system das vor 
Zuverlässigkeit kaum noch laufen kann.

Das wirkt immer mehr wie eine hemdsärmelige "VW, BMW und Mercedes können 
das nicht, aber ich schon"-"Lösung", oder ein klassisches XY-Problem 
"ich will das das so geht!!!".

von Benedikt L. (Firma: Dem Ben seine Leiche) (dembenseineleiche) Flattr this


Lesenswert?

MQTT war für sowas nit gemacht.

von Pat (elpat)


Lesenswert?

Also, um da einige Unklarheiten auszuräumen:

1. Es ist wichtig, wann das Signal entstanden ist, daher der Timestamp.

2. Das Signal wird für einen bestimmten Zweck live verarbeitet (daher 
das Verzögerungslimit) und für einen bestimmten anderen Zweck später, 
das ist zeitunkritisch.

3. Es ist wichtig, dass das Signal so gut wie möglich mit einer 
Verzögerung von höchstens 0,5s-1s ankommt. Wenn mal nicht, ist's nicht 
so schlimm, solange das selten ist.

---------------------------------------------------------------

Ich habe heute einen ersten Test gemacht und bemerkt, dass es 
zuallermeist gut läuft, ab und an (ca. 1-2 Mal pro Stunde) jedoch 
Nachrichten erst ca 5-8 Sekunden später eintreffen (dann aber alle auf 
einmal).
Wodurch kann das verursacht werden?
(Der Test war noch statisch am Fensterbrett)

Wäre das mit MQTT over HTTP besser?

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Also sorry... aber solange Du mir nicht plausibel erklärst, zu welchem 
Zweck diese Messwertblöcke zeitkritisch innerhalb von 0,5s ankommen 
müssen, bin ich raus. Ich werde Dir mir den bereits rausgerückten 
Informationen alleine auch gar nicht weiter helfen können, denn

> Ich habe heute einen ersten Test gemacht und bemerkt, dass es
> zuallermeist gut läuft, ab und an (ca. 1-2 Mal pro Stunde) jedoch
> Nachrichten erst ca 5-8 Sekunden später eintreffen
> (dann aber alle auf einmal).

ist genau was ich erwartet hatte bzw. ich hätte angenommen, daß diese 
Hiccups noch deutlich öfter vorkommen. Erst recht wenn die Daten von 
einer Karre übermittelt werden sollen, die sich durch eine Stadt bewegt. 
Stichworte Netzlast und Funkzellenwechsel.

Den eigenen Datenfunkkanal auf einer zugewiesenen Frequenz möchtest Du 
ja nicht... das ist dann natürlich Pech.

von Pat (elpat)


Lesenswert?

Was genau übertragen wird ist doch irrelevant. Es sind 100-200 
ASCII-Zeichen, die zeitnah von einem fahrenden Straßenfahrzeug bei max 
50km/h zu einem Server müssen. Mehr Info braucht man doch nicht, um das 
eigentliche Problem zu diskutieren.

Wenn ihr mir nicht helfen wollt, sagt es einfach. Ich habe gedacht, wir 
können uns austauschen. Ich hätte auch meine Ergebnisse hier mitgeteilt. 
Dann könnten andere auch was davon haben. Aber ich war wohl zu 
optimistisch, dass soetwas möglich ist.
Noch vor einigen Jahren hat man hier echt Hilfe bekommen.

Seht euch mal StackOverflow an. Es steht dort die Frage und darunter die 
Antwort.
Keiner schreibt, man solle doch eine Uhr filmen und per Video 
übertragen.
Und niemand jammert, dass nicht das ganze Programm, sondern nur der 
relevante Teil hochgeladen wurde. So bekommt man auch Hilfe, wenn man 
nicht sein ganzes Projekt der Öffentlichkeit vorstellt oder gar zur 
Verfügung stellt. Es wird einfach geholfen und Hunderttausende können 
dort ihre Problemchen nachschlagen, die sie beim Programmieren haben. 
Die fragen dann nicht mehr. Soetwas bräuchte man auch für 
Elektrotechnik.

Ich bin enttäuscht.

: Bearbeitet durch User
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

GRRRRRRRRRR **keyboard abbeiß**

> Was genau übertragen wird ist doch irrelevant.
Stimmt. Mir ist egal WAS Du da übertragen willst.
Ich hätte gerne gewusst WARUM bzw. warum das so zeitkritisch ist.

> Mehr Info braucht man doch nicht, um das
> eigentliche Problem zu diskutieren.
Mein Problem ist, daß ich Dein Problem nicht verstehe. Ich kann nicht 
einschätzen, ob eine zeitkritische Übertragung über irgend einen 
Internet-basierten Kanal wirklich erforderlich ist, oder ob man eine 
Lösung finden kann, die weniger zeitkritisch ist, so daß dieser 
Übertragungsweg ausreichend gut funktioniert.

> Wenn ihr mir nicht helfen wollt, sagt es einfach.
Kommt jetzt die Heulsusen-Nummer?
Vergisses! **Schrotflinte durchlad**

> Ich hätte auch meine Ergebnisse hier mitgeteilt.
> Dann könnten andere auch was davon haben.
Wenn es ein so offenes Projekt ist, wieso kannst Du dann nicht 
offenlegen, was Du vor hast? Ist es so geheim? Hängt für Dich eine 
größere Geldmenge dran? Kleiner Tip, die Wichtigkeit eigener Projekte 
für andere wird sehr oft massiv überbewertet. Ich kann mir z.B. nichts 
vorstellen, wofür ich jetzt gerade eine zeitkritische Übertragung 
irgendwelcher Messdaten aus meinem Auto besonders dringend brauchen 
würde. Ich wüsste daher auch nichts, wieso ich Dir eine Idee oder was 
immer Du das hast "klauen" sollte.

> Aber ich war wohl zu optimistisch, dass soetwas möglich ist.
> Noch vor einigen Jahren hat man hier echt Hilfe bekommen.
**augenroll**

> Seht euch mal StackOverflow an. Es steht dort die Frage und
> darunter die Antwort.
Na dann geh zu StackOverblow und poste Deine Anfrage dort genau so, wie 
Du sie hier gepostet hast. Der Tag ist ja noch jung, heute abend will 
ich die Antwort sehen. Viel Glück!

> Keiner schreibt, man solle doch eine Uhr filmen
> und per Video übertragen.
Habe ich auch nicht.

> Und niemand jammert, dass nicht das ganze Programm, sondern nur
> der relevante Teil hochgeladen wurde. So bekommt man auch Hilfe,
> wenn man nicht sein ganzes Projekt der Öffentlichkeit vorstellt
> oder gar zur Verfügung stellt.
Dann haben die es wahrscheinlich geschafft, genug benötigte 
Information zur Verfügung zu stellen oder das Projekt offengelegt, wie 
es zur Nutzung der Schwarmintelligenz manchmal erforderlich ist.

Ich kann Deine Sorgen ja verstehen, ich bin auch kein Fan davon und ich 
möchte Dich auch nicht überreden, irgendwas offenzulegen (ehrlich 
gesagt, so sehr interessiert es mich noch nicht mal persönlich, ich habe 
genug andere Projekte, die ich erstmal fertig kriegen muss). Aber wenn 
ich bei einem Problem nicht weiterkomme, dann geht's manchmal nicht 
anders und dann lege ich es auch offen. Oder ich gebe es einem Freund, 
der mit der Thematik (bei mir z.B. Mechanik, ganz besonders 
Feinmechanik) besser klarkommt als ich. Sicherlich kommen bei einem 
Forum dann Stimmen wie "na das ist ja lame" oder "wozu brauchst du 
sowas, niemand will sowas haben" und Argumente wie "weil ich es schön 
finde" oder "ich will wissen wie das funktioniert" stoßen auf wenig 
Gegenliebe - aber wenn nur einer dabei ist, der hilft, dann hat es sich 
schon gelohnt. Gerade dieser Fall ist in diesem Forum sehr häufig, hat 
leider mit dem Aussperren von Gästen etwas abgenommen, aber meistens 
findet sich irgend eine einzelne Person, die das Problem sehr 
zufriedenstellend für ein "danke dir" lösen kann.

Mach Dir mal Gedanken drüber, oder gib ein (gutes!!, bitte nicht mit 
viel Rätsel raten) Beispiel für ein vergleichbares Projekt oder 
Anwendungszweck. Dann kannst Du Deines geheim halten. Also warum muss 
die Bereitstellung einer Information aus einer mobilen Quelle auf einem 
MQTT-Server so dermaßen zeitkritisch erfolgen.

> Es wird einfach geholfen und Hunderttausende können dort ihre
> Problemchen nachschlagen, die sie beim Programmieren haben.
Wie gesagt, dann mach das doch. Du hast aber kein Problemchen beim 
Programmieren (z.B. wie man eine double precision floating point 
division auf einer 8 Bit CPU hinkriegt könnten Dir hier viele sofort 
erklären), sondern Du hast ein Infrastruktur-Problem. Dir steht kein 
Datenkanal mit ausreichend geringer Latenz und gleichzeitig hoher 
Zuverlässigkeit zur Verfügung. Es gibt nun zwei Wege, das Problem 
anzugehen: Entweder man schafft sich so einen Datenkanal - das halte ich 
für eher schwierig bzw. sehr aufwendig (Funk) oder teuer (kommerzieller 
Funk) - oder man sucht eine Möglichkeit, die ohne eine derart schnelle 
bzw. höchst zuverlässige Verbindung auskommt.

Wenn es die Datensätze hergeben (z.B. beim GPS-Tracking eines Autos oder 
bei einer Temperaturüberwachung), könnte man aus vorangegangenen 
Datensätzen z.B. versuchen, zukünftige Datensätze vorauszuberechnen und 
diese so lange anzunehmen, bis sie von mit Zeitstempel eintreffenden 
realen Datensätzen korrigiert werden (und eine neue Vorausberechnung 
angestoßen wird).

Oder lässt sich der MQTT-Server mobil am Ort der Datenquelle betreiben? 
Dann verschiebt sich die Verbindungslatenz-Problematik zur weiteren 
Datenverarbeitung, zwischen Datenquelle und MQTT-Server ließe sich dann 
eine sehr gute (weil kurze) Verbindung herstellen.

Aber leider sind solche Überlegungen komplett hinfällig weil man nicht 
weiß worum es bei Deinem ach so großartigen Geheimprojekt geht, ob so 
ein Ansatz dabei möglich ist oder ob man doch was ganz anderes braucht 
und ich jetzt wieder nur 'nen dummen Spruch von Dir bekomme, daß ich mit 
meiner Vermutung der Echtzeitüberwachung der Auspufftemperatur Deines 
Elektroautos leider daneben gelegen habe.

> Die fragen dann nicht mehr. Soetwas bräuchte
> man auch für Elektrotechnik.
Eine große Tüte Mitleid. Schade, habe ich gerade keine mehr da.

> Ich bin enttäuscht.
Ich auch. Da probiert man zu helfen und dann kommt sowas hier. Aber 
kennt man ja nicht anders. Und nein, ich will kein Mitleid dafür, ich 
überlebe in diesem Forum schon jahrelang ohne. Man gewöhnt sich (leider) 
an alles.

von Ein T. (ein_typ)


Lesenswert?

Pat schrieb:
> Was genau übertragen wird ist doch irrelevant. Es sind 100-200
> ASCII-Zeichen, die zeitnah von einem fahrenden Straßenfahrzeug bei max
> 50km/h zu einem Server müssen. Mehr Info braucht man doch nicht, um das
> eigentliche Problem zu diskutieren.

Weißt Du, hier schlagen ziemlich häufig Menschen auf, die zwar keine 
Ahnung haben, wie sie etwas machen sollen, sich aber schon sehr fest auf 
eine ganz bestimmte Teillösung festgelegt haben. Vermeintlich haben sie 
alles andere bereits gelöst, nur dieser eine kleine Teil... also...

Dabei stellt sich bei näherem Hinterfragen oft heraus, daß nicht nur 
diese eine Teilaufgabe, sondern schon der ganz grundsätzliche 
Lösungsansatz eher suboptimal ist, und die ungelöste Teilaufgabe bei 
einem anderen Ansatz gar nicht notwendig wäre. Insofern wäre es 
sicherlich sinnvoll, wenn Du etwas präziser ausführen könntest, was Du 
eigentlich vorhast.

> Wenn ihr mir nicht helfen wollt, sagt es einfach. [...]
> Ich bin enttäuscht.

Und Du glaubst wirklich, es würde irgendwen weiterbringen, wenn Du 
denen, die Dir helfen sollen, zuerst Informationen vorenthältst und Dich 
dann bitterlich über deren angeblich mangelnde Hilfsbereitschaft 
beklagst?

von Steve van de Grens (roehrmond)


Lesenswert?

Mich irritiert die Widersprüchliche Angabe zur benötigten 
Übertragungszeit:

> Wenn mal nicht (innerhalb 0,5s-1s ankommt), ist's nicht so schlimm,
> solange das selten ist.

Und direkt danach schreibst du im selben Beitrag:

> bemerkt, dass es zuallermeist gut läuft,
> ab und an (ca. 1-2 Mal pro Stunde) jedoch Nachrichten erst
> ca 5-8 Sekunden später eintreffen

1-2 Mal pro Stunde ist doch selten, oder nicht? Oder sind dir die 5-8 
Sekunden (selten) zu viel.

Vielleicht drückst du dich mal eindeutig aus, was du wirklich brauchst.

: Bearbeitet durch User
von Purzel H. (hacky)


Lesenswert?

Die Anforderungen sind ueberzogen, nicht bezahlbar. Ein konzeptueller 
Furz. Reich Details rueber. Wir sortieren dann raus, wie man's machen 
sollt.

: Bearbeitet durch User
von Rüdiger B. (rbruns)


Lesenswert?

Ich stelle mir gerade vor das du 8 Stunden lang die sekündlichen Daten 
beobachtest.

von Purzel H. (hacky)


Lesenswert?

Da ist dann eine Echtzeit Auswertung dahinter.
- Wenn der Wagen fuer eine Sekunde von der Route abweicht, wird er .. 
abgebremst und blockiert, verriegelt, allenfalls selbstzerstoert.
- Es werden alle kommenden Ampeln immer auf .. rot oder gruen geschalten
- Ein Angestellter ueberwacht jeden Datensatz

Alles nicht-Echtzeit-, kann eigentlich im Auto aufgezeichnet werden
Alles Echtzeit- kann eigentlich im Auto selbst ablaufen
Autos verfolgen wie im Film .. aber ja doch. Allerdings kann das Watsup 
schon von selbst

: Bearbeitet durch User
von Le X. (lex_91)


Lesenswert?

Pat schrieb:
> Seht euch mal StackOverflow an. Es steht dort die Frage und darunter die
> Antwort.

Für viele Fragen ist Stackoverflow tatäschlich der bessere Ort.
Dort reicht es, wenn man eine abstrakte und kontextunabhängige Frage 
stellt, solange sie einigermaßen präzise ist.
Dann gibt es auch eine ebenso präzise Antwort auf diese Frage.
Diese Sensationsgier, den TE erstmal für blöd erklären und ihn sich bis 
auf die Unterhose nackig machen zu lassen, das gibts da tatsächlich 
nicht.

Ich denke nicht dass du hier sämtliche Details liefern musst, aber ein 
bisschen Quantifizierbares (wie oft sind Ausfälle in welcher Länge OK?) 
sollte noch kommen.

Mit deinen Angaben würde ich nämlich der Meinung von Steve anschließen 
und  auch sagen es passt wie es ist.
Steve van de Grens schrieb:
> 1-2 Mal pro Stunde ist doch selten, oder nicht? Oder sind dir die 5-8
> Sekunden (selten) zu viel.

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.