Hallo! Wir haben gerade ein Projekt am laufen bei dem bei einer elektronischen Abstimmung bis zu 100 Handsender an einen Empfänger ihre Stimme senden sollen. Natürlich müssen bei den Sendegeräten eine eineindeutige Seriennummernvergabe vorhanden sein damit keine Fehler auftreten. Wir haben uns bereits ein wenig über dieses Thema informiert und auch schon 1-Wire-Devices oder ID-Chips in Erwägung gezogen, da wir jedoch nicht die besten Programmierer sind, haben wir uns gedacht, dass wir einfach einen 8 poligen Dip-Schalter einbauen, die Seriennummer manuell einstellen und diese dann einlesen und als Dezimalzahl mitsenden. Was haltet ihr von der Idee? Bzw habt ihr bessere? Danke schonmal im vorraus. mfg
Absoluter Humbug eine FESTE Seriennummer per DIP Schalter zu realisieren. Dann noch lieber Löt-Jumber auf der Platine, dann kann sie a.) nicht so leicht ändern und b.) zahlt man nicht auch noch ein Bauteil mit. Einfacher wäre es, die Nummer direkt bei der Programmierung ins Flash oder EEPROM oder wo auch immer hin zu speichern. 1-Wire Seriennummern gehen natürlich auch. Kosten aber extra. Aber was ist das bitte für eine armselige Ansage, dass ihr nicht die besten Programmierer seid? Wie habt ihr dann überhaupt das Programm für euer Gerät gemacht? Das passt doch nicht zusammen. Klingt wieder mal nach Elektroniker-Lego ala Arduino. Wir haben da xyz gemacht aber keine Ahnung davon weil wir nur zusammenstecken und fertigen Code benutzen. gruß cyblord
Christof K. schrieb: > dass wir einfach > einen 8 poligen Dip-Schalter einbauen, die Seriennummer manuell > einstellen Wo dann jeder dran 'rumspielen' kann? :-/ Als mechanische Lösung würde ich evtl. die eigentliche DIP-Schalter-Einstellung direkt verlöten.
Theoretisch kann man das schon machen. Man könnte auch individuelle Seriennummern beim Programmieren in einen EEPROM schreiben. Gegenüber den ID Chips hat es aber den Nachteil, dass man trotzdem gleiche IDs vergeben kann. Je nach Erreichbarkeit des DIP Schalters würde ich mir auch sorgen machen, dass da mal ein Spaßvogel dran rumspielt.
cyblord ---- schrieb: > Absoluter Humbug eine FESTE Seriennummer per DIP Schalter zu > realisieren. > Dann noch lieber Löt-Jumber auf der Platine, dann kann sie a.) nicht so > leicht ändern und b.) zahlt man nicht auch noch ein Bauteil mit. Oder die Umkehrung. 8 Leiterbahnen, die man gezielt mit dem Messer durchtrennt.
Karl Heinz schrieb: > 8 Leiterbahnen, die man gezielt mit dem Messer durchtrennt. Oder ohne abrutschen ;-) Vias auf die Leiterbahnen und entsprechend aufbohren.
weil es "nur ein paar Stück" werden sollten, hab' ich mal die Seriennr. fest ins Programm eingebaut, also in ein serialno.h. Mit "make flash" wird die von einem Script hochgezählt, der Compiler und dann das Flash-Programm gestartet. Das funktioniert bei inzwischen 220 Stück immer noch ;)
Leiterbahnen zertrennen ist mMn. quatsch, ein Fehler und es stimmt doch was nicht. Klar man kann die auch noch aufkratzen und wieder brücken, aber das sieht nach pfusch aus. Welchen µC benutzt ihr? Könnt ihr nicht dessen Interne ID nutzen?
eagle user schrieb: > weil es "nur ein paar Stück" werden sollten, hab' ich mal die Seriennr. > fest ins Programm eingebaut, also in ein serialno.h. Mit "make flash" > wird die von einem Script hochgezählt, der Compiler und dann das > Flash-Programm gestartet. Das funktioniert bei inzwischen 220 Stück > immer noch ;) Ich würde einfach direkt das Hexfile manipulieren, das ich Flashe. Musst dir halt die Adresse freihalten, an der die Seriennummer stehen soll. Einfacher gehts nicht. Du willst ja nicht 100*8 Jumper konfigurieren..
Die Methode mit dem geringsten Aufwand ist der 1-wire Baustein. Kostet halt 1,50€ und ist einmal etwas Aufwand eine 1-wire Bibliothek zu suchen, aber das war es dann. Dann kann dir auch kein Fehler mit einer doppelt vergebenen Seriennummer passieren.
Wenn ihr ein uC von ST eingebaut habt: diese haben schon einen eigenen Seriennummer...
Die Seriennummern von Controllern oder anderen Bausteinen müssen aber auch erst an der Auswertezentrale eingelernt werden. Da ist es einfacher Sender zu haben die nur 0-99 senden.
> Kostet halt 1,50€
bei Reichelt kosten die bloss 29 Cent: 24AA02E64-I/SN und Du bekommst
sogar 2-wire ;)
Christof K. schrieb: > da wir jedoch nicht > die besten Programmierer sind Was soll das heißen? Seid ihr nicht in der Lage, die Seriennummer aus einem fertigen Bauteil für diesen Zweck (z.B. DS28CM00) per I²C auszulesen? Oder per 1-wire, z.B. DS2401? Dann frage ich mich allerdings, wie ihr den Rest des Projekts hinbekommt. Einen DIP-Schalter könnnt ihr ja offensichtlich auslesen ... Was spricht dagegen, allen Handsendern manuell eine Seriennummer in einen bestimmt irgendwo vorhandenen nichtflüchtigen Speicher einzuprogrammieren? Der Aufwand kann es kaum sein - die DIP-Schalter müsste man schließlich auch einstellen. Kurz: Ohne Information, was ihr könnt (nicht was ihr nicht könnt) und welche weiteren Randbedingungen hier einfache und naheliegende Lösungen verhindern, wird euch kaum zu helfen sein.
...-. schrieb: >> Kostet halt 1,50€ > > bei Reichelt kosten die bloss 29 Cent: 24AA02E64-I/SN und Du bekommst > sogar 2-wire ;) D.h. nur 14,5 cent pro Wire!!
Christof K. schrieb: > 1-Wire-Devices oder ID-Chips in Erwägung gezogen, da wir jedoch nicht > die besten Programmierer sind, haben wir uns gedacht, dass wir einfach > einen 8 poligen Dip-Schalter einbauen, die Seriennummer manuell > einstellen und diese dann einlesen und als Dezimalzahl mitsenden. Wer lötet denn eure Handsender zusammen ? Ihr selber ? Dann könnt ihr statt DIP Schaltern auch Lötbrücken setzen. Und wenn ihr bestücken lasst, dann werden 8 Drahtbrücken gesetzt. Oder man baut einem Spannungsteiler aus 2 Widerständen und liest den Wert per A/D Wandler, da kann die Bestückungssoftware die Werte aus den vorhandenen auswürfeln. Ist nur 1 vorhanden, kann man wiederum 7 davon bestücken/nicht bestücken.
MaWin schrieb: > Oder man baut einem Spannungsteiler aus 2 Widerständen und liest den > Wert per A/D Wandler Klingt nach einer wenig zuverlässigen Methode, wenn man will das sich die IDs nicht ändern und überall unterschiedlich sind.
Uwe Bonnes schrieb: > Aktuelle Kontroller wie die STM32 haben schon selbst eine eindeutige > Nummer... Die sind aber meist sehr groß. Oftmals 96 bis 128Bit! Willst Du die bei jedem Telegram mitschicken wenn du von Anfang an weist, dass es nur 100 Handsender sind? Hätte auch Lötjumper oder DIP-Switches genommen. Je nach dem wie oft sie gewechselt werden sollen. Ins Flash schreiben, hat für mich schon wieder was in Richtung UID.
Hallo, danke für die vielen Antworten :) cyblord ---- schrieb: > Aber was ist das bitte für eine armselige Ansage, dass ihr nicht die > besten Programmierer seid? Mit nicht die besten Programmierer hab ich gemeint dass wir noch Anfänger sind, aber Hilfe bekommen falls wir sie wirklich brauchen. Aber es ist eh alles in den Datenblättern gut dokumentiert. sebi707 schrieb: > Je nach Erreichbarkeit des DIP Schalters würde ich mir > auch sorgen machen, dass da mal ein Spaßvogel dran rumspielt. Herumspielen würden an den Schalter keiner weil sie in einem Gehäuse verpackt werden. und wenn jemand mit dem Schraubenzieher anfängt rumzuspielen wird das schon auffallen :) Ich glaube wir werden die IDs einfach von 0 bis 99 in den Speicher einprogrammieren, wird nicht mehr Aufwand sein als die ganzen Dip-Schalter einzustellen und billiger ist es auch. Fritz schrieb: > Kurz: Ohne Information, was ihr könnt (nicht was ihr nicht könnt) und > welche weiteren Randbedingungen hier einfache und naheliegende Lösungen > verhindern, wird euch kaum zu helfen sein. Hoffe aber doch dass wir nicht ganz versagen werden ;) mfg christof
Hallo, Christof K. schrieb: > Ich glaube wir werden die IDs einfach von 0 bis 99 in den Speicher > einprogrammieren, wird nicht mehr Aufwand sein als die ganzen > Dip-Schalter einzustellen und billiger ist es auch. Nicht vergessen, die Speicher nach dem Programmieren entsprechend zu beschriften ;-) Mit freundlichen Grüßen Guido
Ralf G. schrieb: > Oder ohne abrutschen ;-) Oh! All das viele Bluuuut.... Ok das mit den durchrennten Leiterbahnen ist weit verbreitet. Aber mit dem Messer? Die Lösung die Nummern zu speichern wäre auch mein Favorit. Ich hoffe man vergißt beim Programmieren nicht die Nummer bei jedem Gerät zu ändern.^^ @Christof Wird das eine eimalige Sache? Nur mal so gefragt ob 100 bzw 256 IDs dauerhaft ausreichen. Wenn man später mehrere Sendersets mit jeweils bis zu 100 Teilnehmern hat, so sollen die vermutlich nicht durcheinander geraten können.
:
Bearbeitet durch User
Carsten R. schrieb: > Wird das eine eimalige Sache? Nur mal so gefragt ob 100 bzw 256 IDs > dauerhaft ausreichen. Wenn man später mehrere Sendersets mit jeweils bis > zu 100 Teilnehmern hat, so sollen die vermutlich nicht durcheinander > geraten können. ja die 100 Stück sind schon großzügig gewählt, wahrscheinlich werden nicht mehr als 90 gleichzeitig verwendet, aber eine zweite Garnitur von Sendern + Empfänger ist nicht geplant. :) mfg Christof
Guido C. schrieb: > > Nicht vergessen, die Speicher nach dem Programmieren entsprechend zu > beschriften ;-) > Wir haben das auch so gemacht und die Nummer ins Edelstahlgehäuseeingeschlagen. Beim Progen steht die Nummer schon am Gehäuse und braucht dann nur noch ins Flash geschrieben werden. Verwendet wurden zwei Byte, da ist dann auch noch Platz für die Projektnummer und Jahreszahl. Kurt
Du könntest beim ersten Programmstart eine Zufallszahl (mit recht vielen Bits) erzeugen und ins EEprom ablegen.
> mit recht vielen Bits
Je mehr Bits die Zahl hat, umso unwarscheinlicher werden duplikate. ich
dachte dabei an wenigstens 32 Bit.
Überleg dir mal, woher du die Zufallszahlen bekommen willst. Danach verstehst du den "Witz" von Carsten.
In der Tat gehen die meisten Foristen davon aus, dass der TE zwingend eine "Kanalnummer" zwischen 0 und 99 haben möchte. Allerdings hat der TE selbst, ID-Chips mit langer eindeutiger Kennung ins Spiel gebracht, und nur wegen fehlender Programmierkentnisse verworfen. Also wird doch eher eine lange UID gesucht. Grundsätzlich hat sowas Vorteile weil es keine Verwechslungen gibt. Erfordert aber natürlich ein Einlernen (ähnlich wie bei Garagentoröffnern usw.). Bei nur sehr wenigen realen Geräten, macht eine gute Zufallszahl als solche Kennung durchaus Sinn. Das Risiko einer Doppelbelegung ist bei 32 Bit oder mehr verschwindend gering. Und man spart sich (ähnlich wie bei Verwendung von ID-Chips) eine Speicherung der letzten ID. gruß cyblord
stefan us schrieb: > Du könntest beim ersten Programmstart eine Zufallszahl (mit recht vielen > Bits) erzeugen und ins EEprom ablegen. Gute Idee aber bei meinem Glück hab ich da ne ID doppelt :DD
Ich würde einen oneWire Chip draufmachen und gut ist. Das anlernen der Seriennummern ist auch nicht nötig. Es gibt 100 Sender, die alle unterschiedliche SN haben. Ziel ist es doch zu erkennen wie viele senden. Das bekommt man so auch raus. Und wenn mal einer defekt ist, einfach den nächsten Sender austeilen - fertig... nitraM
Gespeichertes Datum + (sekundengenaue Uhrzeit statt Nummer) löst auch manches Garantie- und Versionsproblem?
einfach auf alle die gleiche Software flashen. Bei der ersten Kommunikation mit dem Master (in einem speziellen Anlernmodus) teilt dieser dem Handgerät eine ID mit, die das Gerät ins Eeprom schreibt. In dieser Phase kann man dann auch gleich den Schlüsselaustausch machen, um im Produktiveinsatz die Kommunikation abzusichern (Verschlüsselung + Signatur um Fälschung zu vermeiden).
:
Bearbeitet durch User
Man benutzt keine Zufallszahlen für Seriennummern! Seriennummern haben eindeutig zu sein. Es gibt kaum etwas nervigeres zu debuggen als zufällige Fehler(durch zufällige Duplikate). Zufallsgeneratoren zu programieren sind eine Sache für sich. Normalerweise kommt nämlich immer das Selbe bei einem Programm raus. Also wird es etwas komplizierter und/oder man bedient sich weiterer Mittel. Sich mit dem Thema zu befassen ist nicht wirklich einfacher als einmal die 100 Nummern Reihum zu verteilen. Normalerweise wird in irgendeinem Schritt von Produktion bis Inbetriebnahme eine eindeutige Nummer aus einem gültigen Adresspool zugewiesen. Vlad Tepesch schrieb: > Bei der ersten Kommunikation mit dem Master (in einem speziellen > Anlernmodus) teilt dieser dem Handgerät eine ID mit, die das Gerät ins > Eeprom schreibt. Genau so wird es gemacht wenn man es am Ende bei der Inbetriebnahme machen will. Allerdings sind die meisten Methoden für so eine einmalige Sache unnötig aufwändig. Daher bietet sich "einfach hochzählen" an. Entweder macht man es selbst oder so wie eagle user es beschrieb. Beitrag "Re: Seriennummernproblem" Nop schrieb: > Ins Flash schreiben, hat für mich schon wieder was in Richtung UID. Wo es gespeichert wird ist doch egal, eher wie. Unveränderlich oder nicht, wobei es ohnehin oft bei der Startvorgabe bleibt.
:
Bearbeitet durch User
Christof K. schrieb: > Hallo! > > Wir haben gerade ein Projekt am laufen bei dem bei einer elektronischen > Abstimmung bis zu 100 Handsender an einen Empfänger ihre Stimme senden > sollen. Funk? Da lauert sowieso noch ein Problem. Denn die 100 Handsender können nicht gleichzeitig losplärren. D.h. können tun sie schon. Nur wird der Empfänger dann nichts verstehen. Das ganze muss also sowieso geordnet ablaufen. Der eine Empfänger benötigt noch einen Sender und jeder Handsender muss auch einen Empfänger haben. Das zentrale Auswertegerät frägt nacheinander die ihm bekannten Seriennummern ab und das jeweils so angesprochene Handgerät antwortet mit seiner Stimme. Von daher würde ich die Handgeräte ganz einfach durchnummerieren. Wenn du in einer einigermassen kontrollierbaren Umgebung arbeitest, sollte das auch keine Probleme geben. Eine 12 stellige Seriennummer braucht niemand wirklich im Fernsehstudio in dem "Wer wird Millionär" gedreht wird. Wichtig ist, dass die jeweilige Auswahl A, B, C oder D zur Zentrale kommt und das jedes Stimme nur einmal gezählt wird.
Karl Heinz schrieb: > Denn die 100 Handsender können nicht gleichzeitig losplärren. Wen interessiert's? Einfach nochmal drauf drücken oder das Datenpaket in variierenden Abständen mehrfach widerholen lassen. Ich glaube nicht, daß es gefordert ist daß jeder Knopfdruck ankommen muß. Und Handbetrieb ist so langsam, je dach Datenpaketgröße, die dürfte klein sein, sind da Kollisionen selten solange sie nicht wie bei des Fernsehshow alle gleichzeitig drücken, selbst bei 100 Teilnehmern. Ohne Rückkanal, da "Handsender", wird es ohnehin schwer ein koordiniertes Protokoll mit bestätigter Zustellung hinzubekommen. Da die Abstimmung nicht sehr zeitkritisch ist kann an auch die ID als Zeitverzögerungsparameter verwenden um das Rudelklicken beim Senden zeitlich zu streuen.
:
Bearbeitet durch User
Carsten R. schrieb: > Es gibt kaum etwas nervigeres zu debuggen als > zufällige Fehler(durch zufällige Duplikate). Sicher richtig, nur bei 100 Geräten und einer 32-bit Zufallszahl wäre die Wahrscheinlichkeit 6 Richtige im Lotto zu haben (1 : 14 Mio) höher als 2 Geräte mit gleicher Nummer (1 : 43 Mio) ;-) Funkbasierte Abstimmungsgeräte kling für mich allerdings nach hohem Hack-Value? Wo genau wird das nochmal eingesetzt werden? Und auf welcher Frequenz wird da gesendet...?
Damit wird in den USA der nächste Präsident gewählt. Es muß ja mal wieder einer aus dem Bush-Clan ran. :P Natürlich ist ein Mehrfachtreffer unwahrscheinlich in diesem Fall, aber auch nur weil es sehr, sehr, sehr wenige Adressen gemessen zur Poolgröße zu ziehen sind. Aber man macht es prinzipiell nicht. Bei MAC-Adressen hat man noch mehr Bits. Mit Zufallsszahlen wäre es lustig. Sobald man den Pool auch nur etwas mehr auslastet bekommt man unerwartet hohe Kollisionswahrscheinlichkeiten. Die Wahrscheinlichkeit, daß 2 oder mehr Schüler einer kleinen Klasse am selben Tag Geburtstag haben liegt auch schon über 50 %. Dabei wurde der Pool nicht einmal zu 10 % ausgelastet. Solche Sachen will man nicht jedesmal für die jeweilige Anwendung ausrechnen um dann das Fehlerrisiko zu berechnen. Bewußt Fehlermöglichkeiten einzubauen ist irgendwie Käse. Man hat schon genug mit unplanmäßigen Bugs zu tun. Zudem wäre es hier viel zu aufwändig einen Zufallsgenerator einzubauen.
:
Bearbeitet durch User
Carsten R. schrieb: > Zufallsgeneratoren zu programieren sind eine Sache für sich. > Normalerweise kommt nämlich immer das Selbe bei einem Programm raus. Das kommt wohl etwas drauf an, wie durchdacht das Verfahren ist. Da Computer deterministisch sein sollten, kommt mit einem Programm unter gleichen Bedingungen natürlich immer das selbe raus. Wäre ja schlimm, wenn nicht. Man braucht schon einen vernünftigen Samen.
Genau das! Darum meinte ich auch zu Beginn dazu. Carsten R. schrieb: > heraus kommt: > 42, 23.... und immer abwechselnd 42 und 23 Weil normalerweise immer das Selbe herauskommen sollte. Und genau diese sonst gewünschte Eigenschaft muß man hier auf geeignete Art und Weise umgehen/ändern. Da ist es doch einfacher einmal eine Variable beim Flashen um eins hochzuzählen.
:
Bearbeitet durch User
Vlad Tepesch schrieb: > einfach auf alle die gleiche Software flashen. > Bei der ersten Kommunikation mit dem Master (in einem speziellen > Anlernmodus) teilt dieser dem Handgerät eine ID mit, die das Gerät ins > Eeprom schreibt. > In dieser Phase kann man dann auch gleich den Schlüsselaustausch machen, > um im Produktiveinsatz die Kommunikation abzusichern (Verschlüsselung + > Signatur um Fälschung zu vermeiden). Genau so würde ich es auch machen. Die Sender müssen sich beim Master melden und bekommen vom Master eine Nummer. Der Master sorgt dafür, dass die Nummer nur einmal vergeben wird. Der Sender speichert sich die Nummer in EEPROM und weis so, dass er nicht nochmal fragen muss. Machbar und zuverlässig oder ? Hat ein bisschen was von DHCP...
:
Bearbeitet durch User
> Sobald man den Pool auch nur etwas mehr auslastet bekommt man > unerwartet hohe Kollisionswahrscheinlichkeiten. Mag sein, der TO hatte allerdings klargestellt, dass er maximal 100 Geräte unterscheiden möchte. > Zudem wäre es hier viel zu aufwändig einen Zufallsgenerator einzubauen. Echt? Ich brauche dafür nur die avr-libc, sowie geschätzt ca 5 Zeilen Code für eine ausreichend "zufällige" Initialisierung mit Hilfe des ADC und irgendeiner instabilen Signalquelle (z.B. Batteriespannung, eine rauschende Diode, oder auch das Rauschen ds ADC selbst).
Easylife schrieb: > nur bei 100 Geräten und einer 32-bit Zufallszahl wäre > die Wahrscheinlichkeit 6 Richtige im Lotto zu haben (1 : 14 Mio) höher > als 2 Geräte mit gleicher Nummer (1 : 43 Mio) ;-) Ich weiß nicht, wie du auf diese Zahl kommst, aber sie ist falsch. Tatsächlich ist die Wahrscheinlichkeit dafür 1:867671 (Geburtstagsparadoxon), aber das ist gar nicht der Punkt. Der Hinweis kam doch schon: Carsten R. schrieb: > Bewußt Fehlermöglichkeiten einzubauen ist irgendwie Käse. ... vor allem wenn es praktikable Alternativen gibt. Stefan us schrieb: >> Zudem wäre es hier viel zu aufwändig einen Zufallsgenerator einzubauen. > > Echt? Ich brauche dafür nur die avr-libc, sowie geschätzt ca 5 Zeilen > Code für eine ausreichend "zufällige" Initialisierung mit Hilfe des ADC > und irgendeiner instabilen Signalquelle (z.B. Batteriespannung, eine > rauschende Diode, oder auch das Rauschen ds ADC selbst). Die Selbsteinschätzung des TE bezüglich Programmierkenntnissen gelesen? Woher weißt du, dass das Gerät batteriebetrieben ist? Woher weißt du, dass der avisierte µC (noch freie) AD-Wandler hat? Machst du dem TE die Untersuchung, dass diese Methode ausreichend streut?
Noch ein Vorschlag: Keine Seriennummer einbauen, sondern diese vom Benutzer bei der allerersten Inbetriebnahme über die Abstimmtasten eintippen lassen und dann dauerhaft speichern.
Stefan us schrieb: >> Sobald man den Pool auch nur etwas mehr auslastet bekommt man >> unerwartet hohe Kollisionswahrscheinlichkeiten. > > Mag sein, der TO hatte allerdings klargestellt, dass er maximal 100 > Geräte unterscheiden möchte. Und ich hatte klar unterschieden zwischen dem speziellen Fall mit 100 Adressen aus dem Pool und der von dir nun oben zitierten Aussage, welche sich auf die allgemeine Situation bei solchen Strategien bezieht. Das kann nämlich ganz schnell in die Hose gehen. Fritz schrieb: > Ich weiß nicht, wie du auf diese Zahl kommst, aber sie ist falsch. > Tatsächlich ist die Wahrscheinlichkeit dafür 1:867671 Und siehe da, wer sagt's denn. ;-) Die Wahrscheinlichkeit ist deutlich höher als ursprünglich angenommen. Was dann wenn man 1000 aus den 2^32, also über 4 Milliarden Möglichkeiten, hätte haben wollen. Da wäre der Pool bei weitem nicht einmal zu einem Millionstel ausgelastet. Ich muß mal meinen Taschenrechner rauskramen... Das ist eine sehr holprige Arbeitsweise mit schwer nachvollziehbaren Konsequenzen. Das ist einfach Käse. Na toll! Nun habe ich Hunger!^^
Carsten R. schrieb: > Ich muß > mal meinen Taschenrechner rauskramen... Nicht nötig ;) Bei 1000 aus 2^32 sind es nur noch 1:8599.
Ich bin da in der Stochatik wohl etwas eingerostet um die Formeln auf handhabare Zahlen zu kürzen. -.-
Ich auch nicht. Aber mein Taschenrecher kommt bei n über k irgendwann an seine Grenzen.
Fritz schrieb: > Bei 1000 aus 2^32 sind es nur noch 1:8599 Ich komme da auf 1:8581 Komma nochwas (500500/2^32)
Ah, sch**** Denkfehler... Sind natürlich 8598,5... Nicht 1+2+3+4...+998+999+1000 sondern nur bis 999...
Christof K. schrieb: > Hallo! > > Wir haben gerade ein Projekt am laufen bei dem bei einer elektronischen > Abstimmung bis zu 100 Handsender an einen Empfänger ihre Stimme senden > sollen. > Natürlich müssen bei den Sendegeräten eine eineindeutige > Seriennummernvergabe vorhanden sein damit keine Fehler auftreten. > Wir haben uns bereits ein wenig über dieses Thema informiert und auch > schon > 1-Wire-Devices oder ID-Chips in Erwägung gezogen, da wir jedoch nicht > die besten Programmierer sind, haben wir uns gedacht, dass wir einfach > einen 8 poligen Dip-Schalter einbauen, die Seriennummer manuell > einstellen und diese dann einlesen und als Dezimalzahl mitsenden. > > Was haltet ihr von der Idee? > Bzw habt ihr bessere? > > Danke schonmal im vorraus. > > mfg Wieso nimmste nicht einfach für die 100 Leute entsprechend einfache 100 Stück 1-Kanal-Handfunksender - Stück um 2 € im Selbstbau. Mit dem HT 600 als SENDE-CHIP + 433 / oder 868 Mhz-Sender + 1 Taste + Funksende-Modul PRO Handsender / bzw. das Empfängermodul mit dem HT 614 (der kann ja auch wie der SENDER-IC bis zu 16, 4 Milionen Codiermöglichkeiten!!!) ALLE individuell einmal codierten Sender empfangen und auswerten!) Jeder HT 600 - SENDER kann codiert auf einen individuellen CODE(ebenfalls 16,4 Millionen Möglichkeiten über 8 Codier-Eingänge (PLUS / MINUS oder OFFEN-Codiert!) eingestellt und codiert werden! Der EMPFÄNGER HT 614 wertet die Handsender einzeln unterschieden EINDEUTIG aus- wo ist das Problem? Naja - AHNUNG muss man schon haben, WIE man den SENDER-IC und den EMPFÄNGER dann "programmiert" durch Lötbrücken / oder DIP-Schalter. Und man benötigt weder eine UNSINNIGE Seriennummer ( und / oder aufwendige Programme ect!!) Also manche haben Vorstellungen............ Nun, man kann sich es ja schwer machen, wenn man sonst keinen Job hat.. Umständlichkeiten kann man eben nicht einfacher gestalten - so ein altdeutscher Dichter das verfasst hatte mal anno 1700 oder so .. Eulenspiegel machte es auch komplizierter als es eigentlich ist - Von nem Haufen Baumschnittholz den UNTERSTEN Stamm zuerst rausziehen und abwarten, was passiert... Leute, geht arbeiten, dann fällt es euch leichter, sich in der Welt da draussen zurecht zufinden. Elektronik und Hobby über das Forum hier ist wohl doch nichts für Euch. Gebts zu wenigstens. Man bekommt bei den Postings hier nämlich üble Lachkrämpfe... Nicht unterkriegen lassen - Elektronik sollte man verstehen uind auch beherrschen können, dann seids einen Schritt in richtiger Richtung unterwegs. Glaubts mir. Harald S Gruß aus Koblenz
Fritz schrieb: > Ich weiß nicht, wie du auf diese Zahl kommst, aber sie ist falsch. > Tatsächlich ist die Wahrscheinlichkeit dafür 1:867671 Habe 1 : 2^32 genommen, in der irrigen Annahme, wenn man 100 Zahlen von 2^32 wegnimmt, spielt das keine Rolle. Danach habe ich mich dann noch direkt um 2 10er Potenzen verguckt... tsss... Der Hinweis auf das Geburtstagsparadoxon (Paarbildungsmöglichkeiten) ist hoch interessant. Bzw. erschreckend, ich komme mit Excel auf ca. 1:650000, deine Zahl ist wohl die Richtige. Dankesehr für den Hinweis.
Christof K. schrieb: > Wir haben gerade ein Projekt am laufen bei dem bei einer elektronischen > Abstimmung bis zu 100 Handsender an einen Empfänger ihre Stimme senden > sollen. Wie werden die Daten gesendet? Wenn ihr Bluetooth verwendet, ist die Seriennummer als MAC-Adresse bereits vorhanden. Die DIP-Schalter-Lösung finde ich gar nicht so schlecht, wenn ihr ein verschlossenes Gehäuse habt. Notfalls muss man das Gehäuse noch versiegeln oder mit exotischen Schrauben zumachen. Oder braucht ihr völlige Manipulationssicherheit? Max
Max G. schrieb: > Wie werden die Daten gesendet? > > Oder braucht ihr > völlige Manipulationssicherheit? Wir senden die Daten über Funk mit RFM12 Funkmodulen. Den Teilnehmern sollte man in unserem Fall vertrauen können dass sie das Gehäuse nicht aufschrauben. :)
Ich würde die Nummer fest im Controller beim programmieren hinterlegen. Wenn doch alle Geräte die gleiche Software bekommen sollen und die Adresse hardwaremäßig eigestellt werden sollen würde ich aber auf den Schalter verzichten. Da würde ich lieber "Lötklecksjumper", zwei nah beieinander liegende SMD Pads die einfach mit Lötzinn gebrückt werden können, verwenden. Ein Schalter müsste auch gelötet werden, und für nur einmal einstellen nun nicht wirklich notwendig.
Oder vielleicht 7 Lötpunkte vorsehen (reicht für 2^7 = 128 Nummern) und beim ersten Einschalten dort ein Bitmuster anlegen. Das Programm liest die Bits aus, speichert sie und ignoriert die Lötpunkte für sein restliches Leben.
Ich würde das so machen. 3-4 Löcher ins Gehäuse und Testpads dahinter. (ggf im Batteriefach oder so) Die Pins verbindest Du ohne Pegelwandler mit dem UART. Wenn das Teil startet wird ein kleines primitives Menü gestartet, auf dem man die Nummer einstellen, bzw auslesen kann. Willst Du das ganz nobel machen, dann kannst Du sogar noch einen Etikettendrucker parallel schalten (mit Schalter). Du schaltest den dann hinzu, drückst eine Taste und das Teil schickt die notwendigen Steuerbefehle an den Drucker. Das alles ist schnell programmiert und kostet gar nichts in Hardware pro Gerät. Die Basisstation ist trivial und kommt ohne Spezialsoftware aus. Der normale Nutzer wird die ID nicht versehentlich ändern können, es gibt aber die Möglichkeit bewusst IDs zu ändern (wenn man Teil 43 mal austauschen möchte, o.Ä.) und das alles ist so einfach gehalten, dass es auch noch von Leuten in 50 Jahren verstanden wird.
Carsten R. schrieb: > Man benutzt keine Zufallszahlen für Seriennummern! GUIDs (nix anderes als 128Bit-Zufallszahlen) sind sogar DIE Standardlösung für eindeutige Seriennummern, wenn es nicht möglich ist, diese auf einer zentralen Instanz zu erzeugen. Und oft genug auch dann, wenn es eigentlich möglich wäre. Und warum ist das so? Bestimmt nicht, weil alle Ingenieure dieser Welt nur Schwachköpfe sind und du der einzige bist, der Ahnung von der Sache hat. Ich würde sogar soweit gehen, zu behaupten, daß es in Wirklichkeit genau andersrum ist.. > Zufallsgeneratoren zu programieren sind eine Sache für sich. Ohne Zweifel. Das Problem ist dabei weniger der Generatoralgorithmus als vielmehr die Gewinnung eines wirklich zufälligen Startwertes für diesen Algorithmus. > Normalerweise kommt nämlich immer das Selbe bei einem Programm raus. Nicht, wenn man es richtig macht. Du kannst es wohl nur nicht. Du bist nicht in der Lage, Zufallsquellen im System zu finden und als solche nutzbar zu machen. Aber, daß DU unfähig dazu bist, heißt doch noch lange nicht, daß es nicht möglich wäre...
Du redest hier aber auch von 128 bit. Da liegt die Wahrscheinlichkeit bei 1000 Zahlen zwei gleiche zu erwischen bei 1:6*10^32. Bisher war allerdings die Rede von 32 bit Zufallszahlen. Fällt dir der Unterschied auf?
c-hater schrieb: >> Zufallsgeneratoren zu programieren sind eine Sache für sich. > > Ohne Zweifel. Das Problem ist dabei weniger der Generatoralgorithmus als > vielmehr die Gewinnung eines wirklich zufälligen Startwertes für diesen > Algorithmus. > >> Normalerweise kommt nämlich immer das Selbe bei einem Programm raus. Jetzt hast du aus dem Hinweis das sich Software + CPU für gewöhnlich deterministisch verhält geschlossen, daß das System um etwas zufälliges ergänzt werden muß. Yeeehaaaa. Dann ist der Wink mit dem Zaunpfahl ja angekommen. c-hater schrieb: > Du kannst es wohl nur nicht. Du bist > nicht in der Lage, Zufallsquellen im System zu finden und als solche > nutzbar zu machen. Völlig anmaßende Schlußfolgerung. Völlig anmaßend! Geschlossen nur aus dem Umstand, daß ich auf die Beschränkungen deterministischer Systeme hinweise und im Kontext mehrerer erheblich einfacherer Lösungsansätze (einfach war gefordert) kein Faß aufmache und keine Lösung präsentiere wie dies auf völlig unbekannter Hardware, ohne Information ob überhaupt Zufallsquellen verfügbar sind (ob und nicht welche!), zu lösen wäre. Erkläre doch bitte mal Christof mit wenigen Sätzen bei aktueller Informationslage über die Hardware wie er da ein echt zufälliges System ausreichend zuverlässig in sein Gerät bekommt ohne Hardware anzubauen die komplexer als Jumper/Lötpunke ist. Es ist ja auch soooo sinnvoll das breitzutreten und diese Lösung durchzuprügeln weil es ja soooo viel einfacher ist als bis 100 zu zählen. Einfachheit war gefragt. Da ist es hinreichend zu erkennen ab wann es die geforderte Einfachheit übersteigt. Es ist nicht notwendig die übermäßig komplexen Totgeburten auch noch detailiert zu sezieren. c-hater schrieb: >> Man benutzt keine Zufallszahlen für Seriennummern! Das ist zugegeben etwas dogmatisch formuliert. Asche auf ein Haupt. GUID ist aber auch nicht die Standardlösung bei Mikrocontrollern der Größenordnung ATTiny oder Atmega. Hiermit reiche ich den in diesem Forum nahezu allgegenwärtigen Kontext Mikrocontroller nach. In einer Umgebung in der das Geburtstagsparadoxon noch für Überraschungen sorgt, ist eine solche Gundregel aber auch gut angesiedelt. Davon abweichen sollte man nur wenn bestimmte Vorraussetzungen gelten. Diese hast Du teilweise (implizit) selbst genannt. -Situationen in denen es keine Alternativen gibt. -Situationen in denen die Einsatzbedingungen geeignet sind und dafür ein ein Framework zur Verfügung steht daß sich um das drumherum kümmert! Denn hinter GUID steckt geringfügig mehr als die 128 Bit. JEEHHAA, ein Bit für jedes Gerät und ich habe noch massig Bits übrig. Dann erkläre bitte auch hier mal Christof in wenigen Worten wie er das auf seiner Hardware implementieren kann, und zwar so, daß er es schneller und einfacher implementieren kann als eine Zahl hochzuzählen. Kannst du es? Kein Chipupgrade wegen Speicherplatz erlaubt. -Leute die genau wissen was sie tun und die Wahrscheinlichkeiten ausrechnen können. z.B. Einsatzradius im Sinne der gezogenen Poolgröße abschätzen, eingrenzen, Kollisionswahrscheinlchkeiten bei 128-Bit in Relation eines Hardwarefehlers (z.B. gekipptes Bit) setzen. Man springt nicht lachend von einer Klippe. Natürlich gibt es auch Profis die das mit einem Wingsuit tun und Spaß dabei haben. Grundsätzlch ist das aber erst einmal keine so gute Idee. Ausnahmen kann man mit der passenden Ausrüstung (Fachwissen + Framework) machen.
Vergebliche Mühe, mit ihm hier diskutieren zu wollen. Dann auch noch mit Argumenten!
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte 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.