Hallo Leute, ich befinde mich am Anfang einer Idee bei der ich gerne eure Meinung einholen möchte. Es ist nichts neues. Nur ich bin neu in diesem Gebiet und benötig Erfahrene, die mir Tipps geben bzw.ob sowas grundsätzlich realisierbar ist und wenn ja was für Hardware dafür geeignet wäre etc. Generell bin ich an einem Austausch mit euch interessiert. Ok los gehts. Ich würde gerne ein Ortungssystem mit LoraWan bauen. Dafür möchte ich den Round-trip Time of Flight (RToF) Alghoritmus verwenden. Stellt euch bitte folgendes vor: Ich habe eine Basisstation mit 3 Antennen (Anker) und 200 "portable" Antennen (Tags). Nehmen wir an ich möchte den Antenne mit der ID Nummer 10 orten. Meine Basis broadcastet ein Signal und fragt nach Tag Nummer 10. Natürlich soll dann nur dieser antworten. Aus der Round Trip time (abzüglich Verarbeitungszeit) berechne ich durch Triangulation die Koordinaten relativ zur Basisstation. Meine Fragen: - Gibt es schon fertige oder halbfertige Module für die Basisstation die ich nur noch zu kombinieren brauche. Wenn ja welche sind diese? Ich habe von RN2483 und SMA Antennen gelesen. Ich weiß nur nicht ob es für meine Zwecke das richtige ist und was ich dafür noch brauche. - Welche hardware brauche ich für die Tags? Diese sollen Energieeffizent (langlebig) sein und batteriebetrieben. - Ist LoRa für diese Anwendung geeignet? - Welche wichtigen Fragen sollte ich mir noch stellen? jede konstruktive Meinung ist sehr wertvoll und wird wertgeschätzt. vielen Dank. Rabik
Stell dir folgende Fragen: 1. Ist die Verarbeitungszeit konstant? 2. Misst du immer den direkt Weg oder erreicht dich das Signal vielleicht über Reflexionen? 3. Welche Genauigkeit willst du erreichen und kann man das mit Anforderung 2 in Einklang bringen?
Rab Y. schrieb: > Danke soweit. Welche hardware könnt ihr mir dafür empfehlen? Bevor du nach Hardwareempfehlungen fragst, müsstest du erstmal deine Anforderungen formulieren.
Rechne auch mal wir groß die zeitdifferenzen zwischen den Empfänger sind. Du brauchst sehr guten sync zwischen deinen "ankern" und musst am Ende eine rückgewinnung der Info machen wo Symbole anfangen. Theoretisch sollte das hinreichend gut gehen wird aber aufgrund der kleinen Bandbreite haarig
Der sx1280 kann lora auf 2,4GHz und einfaches Ranging in Hardware. GPS Module sind auch nicht mehr teuer..
icke schrieb: > GPS Module sind auch nicht mehr teuer.. Wer weiss, ob die Tags überhaupt freie Sicht zum Himmel haben. Bei den billigen GPS Modulen wird man mit einer Genauigkeit von einigen Metern leben müssen. Und RTK wird doch deutlich aufwändiger, auch wenn man damit auf einen Zentimeter kommt.
Hi und danke für eure Antworten: Also bzgl. der Anforderungen: Die Tags sollen mit minimaler Hardware auskommen. Also mit minimal meine ich nur das nötigste um auf einen request zu antworten. (mikropozessor, batterie, lora modul, led ...) Ob die Verarbeitungszeit immer konstant ist, muss ich ehrlich gesagt herausfinden. Die Genauigkeit sollte ca. 6 Meter sein, da an den Tags eine Led angebracht werden soll, die bei einem request durch die basis eine zeit lang blinkt. Ist reflexion/Mehrwegausbreitung bei einer Genauigkeit von 6-7 Meter kritisch? Die sind nicht immer unter freien Himmel, eher Indoor. Die Reichweite soll so um die 7 km liegen. Bei GPS mache ich mir sogen um die batterielaufzeit. Das ist ja das tolle an Lora,die geringe Energieaufnahme. Wegen der Synchronisation zwischen den Antennen: Ich glaube nicht das bei Round-trip Time of Flight eine Synchronisation der Basis Antennen nötig ist oder?Die basis weiß ja wann die Antennen das signal geschickt hat und berechnet nach dem ankommen der Antwortzeiten an der jeweiligen Antenne den jeweiligen Radius. Aus dem schnittpunkt der triangulation ergibt sich die Koordinate. Bei Time diffrence of Arrival (TdoA) ist unbedingt eine synchrinisation nötig aber wie gesagt nicht bei RTof. Korrigiert mich bitte ob ich falsch liege. Das das Gateway/Basistation ist selbstverständlich fest und wird mit normaler Spannung versorgt.Ich weiß nicht ob zwischen den BasisAntennen und den Tags hardwaretechnisch überhaupt ein großer Unterschied vorhanden ist. Prinzipiel haben diese ja die selbe Hardware oder? Sind beide Transeiver. Habe ich irgendwas vergessen? Nochmal danke für eure Mitwirken.
Rab Y. schrieb: > Die Genauigkeit sollte ca. 6 Meter sein ... Die Lichtgeschwindigkeit (ja, die gilt auch für Funkwellen) kennst du? Ein Weg von 6 Metern entspricht also einer Laufzeit von 20ns. Mit welcher Taktfrequenz läuft dein Prozessor und wie genau kannst du dein Funksignal detektieren (Phase von Sender- und Empfängeroszillator)? > Ob die Verarbeitungszeit immer konstant ist, muss ich ehrlich gesagt > herausfinden. Wenn du die direkt zur Zeitmessung verwenden möchtest, muss sie das sein . und zwar auf den Taktzyklus genau.
Jugend forscht hat einen schönen Beitrag dazu gebracht und wird hier genau beschrieben: https://www.instructables.com/id/Distance-measurement-with-radio-waves/
> Die Lichtgeschwindigkeit (ja, die gilt auch für Funkwellen) kennst du? Ja kenne ich und klar gilt diese auch für Funkwellen. > Ein Weg von 6 Metern entspricht also einer Laufzeit von 20ns. Mit > welcher Taktfrequenz läuft dein Prozessor und wie genau kannst du dein > Funksignal detektieren (Phase von Sender- und Empfängeroszillator)? Ich habe mich noch für keinen Mikroprozessor entschieden. Ich bin gerade erst in der Anforderungsphase. Ich komme darauf zurück, sobald ich mich für einen entschieden habe und schreibe es dann hier rein, aber deine Anmerkung war sehr hilfreich. > Wenn du die direkt zur Zeitmessung verwenden möchtest, muss sie das sein > . und zwar auf den Taktzyklus genau. Da hast du recht, danke für diesen Tipp. Heißt das ich brauche einen externen Oszillator? Die internen sollen ja sehr zu einem Drift neigen oder? Wie könnte ich diesen am besten immer synchron halten?
pegel schrieb: > Jugend forscht hat einen schönen Beitrag dazu gebracht und wird hier > genau beschrieben: > > https://www.instructables.com/id/Distance-measurement-with-radio-waves/ Super, danke ich lese es mir durch.
Ok, nach einer suche von mehreren Stunden nach einem geeigneten Mikroprozessor habe ich nun mehr den Überblick verloren als behalten. Könnt ihr mir vielleicht einen Mikroprozessor empfehlen, der für meine Zwecke geeignet ist? Der Mikroprozessor des Ankers muss Ethernet unterstützen, für die Tags brauche ich das nicht. Die Frage nach der dem Takt des Prozessors beantwortet sich durch die Anforderungen. Also wenn ich auf www.newmark.com gehe und unter dem embedded interface Filter Ethernet auswähle, dann kommen keine unter 72Mhz. Kann ich für meine Zwecke den hier https://www.newark.com/nxp/lpc2364fet100-518/mcu-16-32bit-arm7-72mhz-tfbga/dp/42AC0885 nehmen?
Hallo, du solltest erstmal die Grundlage (Zeitmessung mit sehr hoher Genauigkeit) verstehen und die notwendigen Anforderungen daraus ableiten, und dann entscheiden, ob du ein FPGA/programmierbare Logik brauchst oder einen schnellen Prozessor. Bei Realisierung mit Prozessor hängt es auch noch an der Wahl des OS und weiterer Dinge im Umfeld ab. Mit <20ns Auflösung/Genauigkeit misst man nicht einfach mal "so". Weiterhin sind die Sleep-Modi der Tags wichtig (Funkkommunikation), um die Messung einzuordnen, und dann wären da noch Störungen auf der Frequenz zu betrachten. Und Multipath ist Indoor immer ein Thema und natürlich die eigentliche Funkstrecke (inkl. Wände/blockierende Objeakte). Weisst du, ob LoRa überhaupt dafür geeignet ist (Protokolle, Laufzeiten der uC usw.)? LoRa arbeitet ja nach meinem Wissen mit teilweise sehr niedrigen Datenraten mit geringer Anforderung an die Clock-Synchronität. Da passt eher eine Anforderung im ms bis Sekunden-Bereich dazu. Ich würde darauf so etwas nicht darauf aufbauen wollen. Woher kommt diese "Aufgabe"? Gruss
Hallo, Hast du dich mal mit LoRaWan etwas genauer auseinander gesetzt? Ich glaube in errinerung zu haben, das aus energie spar gründen die geräte die meiste zeit schlafen und daher von aussen nicht erreichbar sind. nur zu den zeitpunkten an denen die Geräte aufwachen können diese daten vom Master empfangen. somit ist ein Bradcast nicht direkt möglich. Es stellen sich noch ein paar weitere fragen für mich: 1. Wie lange sollen die Geräte wartungsfrei arbeiten können? 2. Wie sieht die umgebung aus in der du das betreiben wills? In door / outdoor Wald ... Alle mir bisher bekannten Trekingsystem auf LoRa oder GSM baisis sei es Trailer Container KabelRolle (die ganz grossen aus holz) arbeiteten mit GNSS Modulen und ggf noch nen bewegugssensor alle N minuten die position errmitteln und diese dann über LoRa verschicken. Als erweiterung ggf den trecker nur dann aufwecken wenn der Bewegungssensor sich meldet.
123 schrieb: > Hast du dich mal mit LoRaWan etwas genauer auseinander gesetzt? > Ich glaube in errinerung zu haben, das aus energie spar gründen die > geräte die meiste zeit schlafen und daher von aussen nicht erreichbar > sind. nur zu den zeitpunkten an denen die Geräte aufwachen können diese > daten vom Master empfangen. somit ist ein Bradcast nicht direkt möglich. LoRaWan ist nicht LoRa, sondern LoRa stellt den physikalischen Layer für LoRaWan dar. Was die darüber liegende Protokollebene macht, steht auf einem anderen Blatt.
Hallo HF-Werkler, danke für deine Antwort. >Woher kommt diese "Aufgabe"? Diese "Aufgabe" kommt aus Folgendem: Ein Freund arbeitet in einer Produktionsfirma und diese stellen Stapler her. Nach dem der Stapler vom Band gegangen ist, muss dieser noch an etlichen Stationen überprüft werden. Diese gehen nicht mehr duuch ein Tracking System. Die Stapler sind plump gesagt mal hier und mal dort bis diese dann endgültig raus in den Hangar gehen und dann je nach Bestellung ausgeliefert werden. Das Problem hierbei ist bevor diese in den Hangar gehen (und das hat mich auch extrem verwundert), sind die Stapler nicht mehr so schnell auffindbar sind, weil die Stätte so groß ist. Jemand muss sich dann eben auf die Suche machen und das dauert (das ist auch nicht zu glauben) manchmal den ganzen Tag und bei mehreren manchmal bis zu 1 Woche, die Stapler sehen halt alle gleich aus. Ich weiß man könnte hier unendlich viele Verbesserungen an den Prozessen vornehmen, damit sowas nicht passiert, aber das ist nicht mein Problem. Mein Freund hat mir gesagt, es wäre so was von toll, wenn man diese orten könnte. Ich habe mir Gedanken gemacht, wie man ohne den Produktionsprozess großartig zu verändert eine Ortung vornehmen könnte. Die Idee ist diese: Am Dach des Staplers ist ein Barcode, der den Stapler kennzeichnet eine Art ID, die dem Stapler zugeordnet ist. Hier kommt mein Tag ins Spiel. Ich möchte, dass der Tag quasi am Dach angebracht werden kann und Dieser hat ebenfalls einen Barcode der die ID des Tags kennzeichnet. Der Stapler läuft durch einen Scanner, der beide Barcodes scannt und dadurch in einer Datenbank die ID des Staplers der ID des Tags zuordnet. Nach dem der Stapler durch diese ganzen Stationen zur Qualitätssicherung durchlaufen hat, muss dieser in den Hanger. DBevor das passiert, wartet am Tor der nächste Scanner, der die Zuordnung der beiden ID's wieder aufhebt, sodass der Tag an einem anderen Stapler wiederverwendet werden kann. An einem Computer (GUI im Intranet des Unternehmens), kann jetzt im Fall, dass ein Stapler gesucht wird nach der ID des Staplers gesucht werden. Im Hintergrund sucht das System die zugeordnete ID des Tags heraus, schickt diese an den Anker (Gateway), der ein Signal mit der ID des Tags broadcastet. Alle Tags gleichen diese Information mit deren ID ab und der betroffene antwortet. Den Rest kennt ihr oder könnt ihr euch denken. >LoRa arbeitet ja nach meinem Wissen mit teilweise sehr >niedrigen Datenraten mit geringer Anforderung an die Clock-Synchronität. Bzgl der Datenrate gehe ich nicht davon aus, dass es da zu Engpässen führen wird, da ja nur eine ID zwischen Anker und Tag abgeglichen wird, es werden ja nicht mehr Informationen geschickt. nur eine ID. Das Problem ist wie Du sagtest die Zeit korrekt messen zu können. >Du solltest erstmal die Grundlage (Zeitmessung mit sehr hoher >Genauigkeit) verstehen und die notwendigen Anforderungen daraus >ableiten, und dann entscheiden, ob du ein FPGA/programmierbare Logik >brauchst oder einen schnellen Prozessor. Da hast du Recht. Vielleicht bin auch auf dem völlig falschen Dampfer. Ich habe diese Thread eröffnet um genau über diese Fragen diskutieren zu können und herauszufinden ob und wie so etwas realisiert werden kann. Zu Lora kam ich aufgrund der Reichweite. >Es stellen sich noch ein paar weitere fragen für mich: >1. Wie lange sollen die Geräte wartungsfrei arbeiten können? >2. Wie sieht die umgebung aus in der du das betreiben wills? In door / >outdoor Wald ... Indoor, und über die Frage der Laufzeit ohne Wartung, habe ich noch nicht so gründlich nachgedacht. >Alle mir bisher bekannten Trekingsystem auf LoRa oder GSM baisis sei es >Trailer Container KabelRolle (die ganz grossen aus holz) arbeiteten >mit GNSS Modulen und ggf noch nen bewegugssensor >alle N minuten die position errmitteln und diese dann über LoRa >verschicken. Als erweiterung ggf den trecker nur dann aufwecken wenn der >Bewegungssensor sich meldet. Danke dafür, ich glaube ich habe einen hierbei auch einen Denkfehler gemacht. Die Tags müssen ja wach sein um auf nachrichten lauschen zu können. Danke. Meine grundsätzliche Frage ist nach all diesen Informationen. Wie muss ich ansetzen , welche Hardware brauche ich um diese (zumindest Anker und Tag aufbauen zu können). Unabhängig von der genauigkeit und die mehrwegausbreitung / Laufzeit zu betrachten. Ich will sowas wie einen abgespreckten lauffähigen Prototypen. Danke.
:
Bearbeitet durch User
Nimm Bluetooth low energy tags und (viel) mehr Basis stationen.... Macht selbst mcdoof in den neueren Restaurants so
Rab Y. schrieb: > Am Dach des Staplers ist ein Barcode, der den Stapler kennzeichnet Reich es dann nicht, an den Fahrstrecken ein paar Barcode-Reader aufzustellen, so dass jeder Stapler ab und zu mal registriert wird und der Zentralrechner dann weiss, in welchem Bereich sich die Kiste befindet?
Ich sehe deine Idee als nicht sinnvoll an: - LoRaWan ist der falcher Ansatz (falsches Protokoll, falsche Technik) - Die meisten Indoor-Systeme zur Lokalisierung sind viel teurer und auswendiger, als du es dir vorstellst - Auch haben diese Systeme oft eine geringe Reichweite (ev. ca. 100m) - Bei grossen metallischen Objekten (Gabelstapler) leidet die Genauigkeit sehr stark durch Multipath Mein Alternativvoschlag: Mehrere Kameras mit Sicht von Oben auf die Dächer der Stapler mit dem grossen Barcode drauf. Ich vermute mal, das ist einfacher umzusetzen. Alternativ installiert man in den Fahrwegen mehrere Barcodescanner Wenn es outdoor ist, kann man eine Lokalisierung mit GPS und Funk aufbauen. Warum scannt der Fahrer, der das Ding bewegt, nicht einfach den Stellplatz-Barcode?
Prinzipiell gute Idea mit dem stellplatz scannen. Nur menschen sind fehlbar und genau der schritt wird irgend wann mal ausgelassen / weggelassen. Aus welchen gründen auch immer. und dann sucht man wieder. Und rausbekommen wer das war geht vermutlich auch nicht. derjenige meldet sich sicher nicht freiwellig bzw weiss der noch nach tagen / wochen wann er welchen stabler woanders hingestellt hat. Da kommt mir grad noch was anderes von wegen baacodes auf dem dach. könnte man ggf eine drohne durch die halle fliegen lassen die alle paar stunden bilder aufnimmt die dann ausgewertet werden?
Martin schrieb: > Nimm Bluetooth low energy tags Kann ich nur zustimmen. Eine große Firma bei der ich mal war, findet damit sogar ihrer Werkzeuge wieder, bzw. sendet Werkzeugdaten damit. Drehmoment, Akkustand u.ä.
Hallo Leute, ok also LoRa ist anscheinend der falsche Ansatz. Das mit den Barcodescanner auf den Fahrwegen ist gar nicht mal verkehrt. Ich werde das mal mit meinem Freund diskutieren. Danke. Mit Bluetooth Low Energy werde ich mich jetzt mal beschäftigen und auf euch zurück kommen. Vielen Dank Leute. Echt tolle Community hier.
Tinyos mit diversen motes könnte dies. HW ist im Bereich von 12 Euro. Wenn da wirklich barcodescanner funktionieren würde dann wurde ich IR tags verwenden.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.