Beiträge von peuler

    Mit "von Hand" meinte ich, dass man auch das GUI so zusammenbauen könnte, dass man jedes Element programmiert um zum Beispiel zu einem Menü zu kommen. Das macht aber keiner (mehr). In den Anfängen von grafischen Benutzeroberflächen ging es aber kaum anders.

    Du nennst QT ein Toolkit, für mich ist es ein Baukasten: aus fertigen Elementen kann ich etwas zusammensetzen und muss dann in meinem eigenen Programm auf die Ereignisse reagieren, die von dem zusammengesetzten Ergebnis ausgehen.

    Wenn Du in einer Suchmaschine mal "Vergleich Programmiersprachen" eingibst, wirst Du einiges an interessanten Berichten finden. Auch lohnt sich ein Blick auf diesen Beitrag in diesem Forum betreff C.

    Nach meinem Eindruck solltest Du zwei Begriffe mehr voneinander trennen, die Du vermutlich im Kopf zu dicht nebeneinanderlegst: Die IDE zur Unterstützung der Entwicklung und die Sprache, in der der Code geschrieben ist.

    Ferner baut man Programme mit GUI nicht mehr von Hand sondern per Baukasten wie QT etc.

    Ein Lehrgang ist per se was feines aber ich würde Dir empfehlen, die ersten Schritte alleine zu gehen und dann einen Lehrgang auszusuchen. Wie bei allen anderen Themen auch gibt es gute und schlechte Kurse und das kannst Du als Einsteiger nicht beurteilen.

    Für mich waren manche Tutorials auf Youtube hilfreich.

    Der Hinweis aus Beitrag #2 ist goldwert: Mit einer Sprache, die zwar Deinen Zweck erfüllt aber mit der Du nicht klarkommst, wirst Du weder Spaß noch Erfolg haben. Einach mal ausprobieren und die ersten 1000 Zeilen Code zusammenbauen und Erfahrungen sammeln.

    Zu Beitrag #4:

    Leider liegst Du mit einigen Punkten daneben.

    Beispiel #1: "Das Rem ist immernoch recht gebräuchlich, sehr viele Geräte stammen noch aus der Zeit damals und sind noch in Betrieb..."

    Ein Gerät, das aus einer Zeit stammt, zu der Rem noch eine gültige Messeinheit war, ist so alt, dass man diesem - im Vergleich zu aktuellen Gerät - kein Vertrauen schenken sollte. Diese Geräte haben Kennlinien und diese verändern sich im Laufe von Jahrzehnten und geben damit falsche Messwerte vor. Ein solch altes Messgerät gehört durch ein aktuelles ausgetauscht, auch aus Gründen der Zuverlässigkeit im Allgemeinen. Rem ist keine gültige Messeinheit mehr, dies zu akzeptieren gehört nicht zum guten Stil sondern ist schlicht eine internationale Vereinbarung.

    Beispiel #2: "Biologische Wirksamkeit bezieht sich ausschliesslich auf die Teilchensorte."

    Schlicht falsch: es geht sowohl die Art der Strahlung ein als auch die Energie der Teilchen. Richtig ist, dass es Faktoren gibt, mit denen die Art der Strahlung in das Maß der Schädigung eingerechnet wird. Richtig ist aber auch, dass der Ort der Bestrahlung (mein Beispiel waren die Füße und der Kopf) auch in die Äquivalentdosis eingeht.

    Beispiel #3:

    "Das Geigerzaehlerprojekt wie oben beschrieben ist völlig in Ordnung, mit der Messung kann man gut was anfangen -- wenn man weiss wie und was."

    Aus meiner Sicht zählst Du nicht zu denen, die das wissen. Du scheinst der Aussage des Herstellers blind zu vertrauen, dass das Gerät kalibriert sei. Es gibt weder einen Hinweis, wie die Kalibrierung durchgeführt wurde noch wurde ein Zertifikat oder ähnliches angegeben, was die Glaubwürdigkeit der Kalibrierung belegt. Das gehört aber zum Mindeststandard um den Messaufbau halbwegs ernst nehmen zu können. Da das Gerät wohl aus China stammt, könnten böse Minen sich ihren Teil denken.

    Beispiel #4:

    "...bestrahlungsdosis(leistung). Die kann man in pulsen/zeit ausdrücken oder eben auch in Rem, Gray oder Sievert pro Zeit. Man ey. Kann man doch überall nachlesen..."

    Du wirfst hier Begriffe wie Dosis, Dosisleistung zusammen mit Becquerel, Gray und Sievert in einem Topf, die aber getrennt gehören, auch wenn es Überleitungen zwischen den einzelnen Begriffen gibt. Der vom Threadopener beschriebene GMZ gibt als Messergebnis Sievert oder Sievert pro Zeit an; je nachdem, welchem Teil der Beschreibung man glauben schenken will oder welchen Teil der Grafiken man anschaut. Das ist nicht eindeutig und damit ist Anwendbarkeit des gesamten Aufbaus anzuzweifeln.

    Beispiel #5:

    "Über das (unbekannte) Energiespektrum der detektierten Strahlung muss man Annahmen machen." Leider findet sich zu den Annahmen kein einziger Hinweis in der Produktbeschreibung des GMZ. Stattdessen wird als Messbereich eine Äquivaltendosis angegeben. Ein weiterer Hinweis dafür, die Finger von dem Gerät zu lassen.

    Dein Projekt hat mehrere interessante Ansätze, die ich zunächst einmal positiv herausstellen will: die Verwendung der PiTS-Managementsoftware war mir neu, ebenso auch die Verwendung des NE555.

    Aus physikalischer Sicht jedoch hat das Projekt aus meiner Sicht einige Schwächen, diese sind im Einzelnen:

    1) In der Produktbeschreibung zu dem DIY Geiger-Müller Zählrohr (GZM) wird erwähnt, dass es eine Äquivalentdosisleistung zwischen 20 und 120 mR/h messen kann. Die Verwendung von R (Rem) als Einheit für die Äquivalentdosis ist seit 1985 abgeschafft, bereits seit 1975 lautet die Empfehlung der SI hier Sv (Sievert) zu nehmen. Ein Hersteller, der dies nicht weiß, ist m.E. nicht auf der Höhe der Zeit und nur bedingt ernst zu nehmen.

    2) Die Äquivalentdosis beschreibt (grob zusammengefasst) das Ausmaß der Schädigung von menschlichem Gewebe aufgrund ionisierender Strahlung. Leider fehlen in der Produktbeschreibung jegliche Hinweise, in welcher Position relativ zum menschlichen Körper das Gerät aufgestellt werden muss. Oder anders ausgedrückt: eine Bestrahlung der Füße (Gerät liegt auf dem Fußboden) hat eine viel schwächere Schädigung des menschlichen Gewebes zur Folge als eine Bestrahlung des Kopfes (Gerät ist auf Augenhöhe installiert). Das Gerät wird aber auf dem Fußboden die gleiche Äquivalentdosisleistung ausweisen wie direkt unter der Decke und damit kann das Messergebnis nicht mehr korrekt sein.

    3) In der Produktbeschreibung findet sich eine sehr merkwürdige Angabe betreff Betastrahlung: "... 100 ~ 1800 aus Variablen / Punkte / cm 2 des weichen Betastrahls." Da das Zählrohr offensichtlich aus Glas (oder einem ähnlichen Werkstoff) besteht, kommt sogenannte "weiche Betastrahlung" gerade eben nicht in das Innere des Zählrohrs, sie wird abgeschirmt. Nur harte Betastrahlung erreicht das Innere aber dafür scheint das Gerät nicht ausgelegt zu sein. Die Angabe mit Variablen und Punkten ist nicht nachvollziehbar. In der englischen Übersetzung ist das nicht besser.

    4) In der Beispielgrafik für den Messverlauf wird in der 3. Zeile hinter "Äquivalentdosis" ein Wert für die "Äquivalentdosisleistung" angegeben. Das passt nicht zusammen und stellt einen groben Schnitzer in der Darstellung der Daten dar.

    5) In Deinem Beitrag schreibst Du "Damit kann man auch als interessierter Maker-Laie und ambitionierter -Einsteiger einfach und effektiv die Radioaktivität zusammen mit einem Raspberry Pi messen" und "Die radioaktive Belastung im Büro wurde zuverlässig gemessen und aufgezeichnet." Das ist in mehrfacher Hinsicht leider falsch. Das Messen von Radioaktivität ist ein weites Feld, weil unter dem Begriff Radioaktivität sehr viel verschiedenes verstanden werden kann, was zwar mit einander zusammenhängt aber dennoch nicht das gleiche ist. Konkret kann darunter nur die Zählung von Strahlungsereignissen pro Zeit verstanden werden, was gleich der Zählung von Zerfallsereignissen pro Zeit ist, ausgedrückt in Becquerel. Siehe dazu auch die unterste Grafik, die die Radioaktivität als cpm (counts per minute) ausweist statt korrekt in Becquerel. Auch kann unter Radioaktivität die Messung einer Äquivalentdosis verstanden werden, was der Summe aller Schädigungen auf ein menschliches Gewebe entspricht, ausgedrückt in Sievert. Hinzu kommt, dass gerade im Büro die Belastung durch Radon sehr wichtig zu wissen wäre, das ist aber ein Alpha- und Betastrahler. Gerade Alphastrahlung erfasst das GMZ erst recht nicht, die Alphateilchen werden zu 100 % durch das Glas abgeschirmt. Tückisch an Radon ist, dass es sich um ein Edelgas handelt und eben mit der Atemluft aufgenommen wird. Das müsste Dein Aufbau auch irgendwie berücksichtigen.

    Du hast zwar erfolgreich eine Langzeitmessung hinbekommen aber von Messen von Radioaktivität kann hier leider nicht die Rede sein. Ferner hast Du nur einen recht kleinen Bereich an Äquivalentdosisleistung gemessen; einen Strahler, der mit dem x-fachen an Äquivalentdosisleistung im Raum versteckt gewesen wäre, wäre entweder gar nicht bemerkt worden oder diese Werte wären einfach zu den vorhandenen dazugeschlagen worden. Ebenso wäre ein Strahler nicht korrekt erfasst worden, der mit mehr als etwa 0,5 Becquerel strahlt: das GMZ kann in der genannten Konfiguration laut Produktbeschreibung nur 25 Ereignisse je Minute zählen. Diesen Wert halte ich übrigens für erheblich zu niedrig, vielleicht waren 25 Ereignisse je Sekunde gemeint.

    Fazit aus dem ganzen: Ich halte es für völlig falsch bis grob fahrlässig, mit solchen Aufbauten ohne das nötige Fachwissen zu hantieren und dann auch noch ganze Landstriche mit sogenannten Messstationen zu überziehen-so klasse ich die Idee einer gemeinsamen und geteilten Messung auch finde.

    Mir kommt das Vermischen von physikalischen Fachbegriffen und das Ziehen völlig falscher Schlüsse irgendwie sehr bekannt vor: Das war schon 1986 nach dem Unfall in Tschernobyl so und auch bei Fokushima waren einige Berichte das CO2 nicht wert, um sie um den Erdball zu senden. Auch dieser Beitrag ist ein Beispiel dafür, dass es wohl nicht ganz einfach ist, sich mit der Materie zu beschäftigen.

    Ich gebe Dir den Rat, erst einmal Grundlagenforschung zu betreiben, bevor Du Dich mit dem Thema weiter auseinandersetzt - auch im Interesse Deiner eigenen Gesundheit, denn darum scheint es ja primär zu gehen.

    Der C++ Standard in der Version 17 ist der aktuelle. Es wird gerade an einer Verison 20 gearbeitet, aber dieser kommt nach Plan eben erst 2020 raus. Selbst Wenn das Buch nur die Version 14 oder gar nur 11 abdecken sollte, ist das für einen Einsteiger immer noch eine enorm hohe Hürde. Keine Sorge, Du hast die aktuelleste Fassung vorliegen, genau die gleiche habe ich mir Ende letzten Jahres bestellt, weil sie auch erst Ende 2017 im Rheinwerk-Verlag erschienen ist.

    Wenn man den Ball in Alu-Folie einwickelt, dann könnte es auch mit Radar gehen.

    Wenn die Farbe, mit dem das Leder des Fußballs lackiert ist, genug Blei enthält, kann man die Alufolie außen rum weglassen.

    Eine Bemerkung am Rande, die fast schon offtopic ist:

    Dein Sourcecode hat mit C++ nicht rasend viel zu tun, Du bist viel dichter an C dran als an C++. Konkretes Beispiel ist Dein Nichtverwenden der String-Klasse. Stattdessen bist Du mit arrays unterwegs. Das ist per se erst einmal kein Fehler denn diese Art der Verwaltung von Zeichenketten ist ja in C++ nicht explizit ausgeschlossen. Ist aber eben auch kein C++-Stil und damit verbaust Du Dir auf lange Sicht die Chance, die Stärken von Klassen bzw. von Objekten auszureizen.

    Da ich ja Dein Lernziel nicht genau kenne, kann ich auch nicht sagen, ob Du eventuell eine komplette Neujustierung Deiner Arbeitsweise brauchst. Oder anders ausgedrückt: Zurück auf Los und Neustart.

    Eine Empfehlung wäre noch, dass Du mal in Youtube nach Tutorials schaust. Die Perlen zu finden ist nicht einfach aber ich habe auch dort für mich was gefunden, was gerade den "Umstieg" von C nach C++ für mich etwas erleichtert hat.

    Vielleicht ist es etwas zu pessimistisch, aber lass Dir gesagt sein: die ersten 10.000 Zeilen Sourcecode sind alle Mist - danach fängt es an Spaß zu machen und raketenstarke Programme kommen dann dabei heraus! Nicht aufgeben, weitermachen!!

    Für mich hat das Programm in der aktuellen Fassung einen grundlegenden Designfehler was die Ermittlung der Umrechnung betrifft.

    Zunächst hast Du für jede mögliche Kombination für die umzurechnenden Währungen je eine Konstante definiert. Bei Deiner recht übersichtlichen Zahl an verschiedenen Währung kann man das gerade noch so hinnehmen, im Hinblick auf den Ausbau auf weitere Währungen ist das aber eine Sackgasse, weil die # Kontanten deutlich schneller wächst als die # Währungen. Ferner baust Du redundante Informationen in den Sourcecode ein.

    Besser wäre es hier, ein Array mit Kursverhältnissen relativ zu einer Referenzwährung anzulegen. Als Referenzwährung kannst Du an Position 0 den € nehmen und diesen mit 1 belegen (€ zu € ist 1) und dann die anderen Währungen im Verhältnis zum € ergänzen. Damit wächst die Datenbasis exakt gleich mit der # Währungen mit und es gibt keine Redundanten Informationen mehr.

    Aus dem Designfehler mit den vielen Konstanten folgen dann die vielen if-Abfragen in den switch-Statements. Hier ist zu erkennen, dass eine angemessene Wartbarkeit des Sourcecodes schon nicht mehr wirklich gegeben ist.

    Wie nun anders bzw. besser vorgehen?

    Nachdem Du den Betrag, die Quell- und die Zielwährung ermittelt hast, brauchst Du nur noch herausfinden, an welcher Position in dem eingangs erwähnten Array sich die Quell- und die Zielwährung befindet. Dann lautet die Berechnung zur Umrechnung recht einfach:

    <Betrag der Zielwährung> = <Betrag der Quellwährung> / <Kursverhältnis der Zielwährung> * <Kursverhältnis der Quellwährung>

    Du kannst mit einer Tabellenkalkulation recht schnell ausprobieren, wie das Prinzip dahinter aussieht.

    Mit dem beschriebenen Verfahren wird Redundanz vermieden und Wartbarkeit des Sourcecode erhöht.

    Vielleicht kannst Du mit einem Linux das Programm gparted starten und dann einen Blick auf die Karte werfen. Wenn das gelingt, kannst Du sie damit auch neu partitionieren (z.Bsp. die vorhandenen Partitionen alle löschen) und anschließend mit einem neuen Filesystem formatieren. Wenn das gelingen sollte, ist die Karte vielleicht doch nicht defekt.

    Eine recht elegante Variante, an das erwähnte gparted zu kommen, ist die Nuzung der PC-Version des Raspian und das Installieren des geparted (habe ich eben ausprobiert).

    Mir ist es egal, dass Microsoft nun Github gekauft hat. Habe nur ein Projekt auf Github abgestellt. Wenn es Microsoft tatsächlich gelingen sollte, dass sie mein Projekt in deren eigene Produkte einfliessen zu lassen, na, dann bin ich stolz drauf.

    Ich habe leicht reden, weil ich keine kommerziellen Ziele verfolge. Wenn dem aber so wäre, dann würde ich mir die Nutzungsbedingungen von Github sehr genau durchlesen und mich vielleicht anwaltlich beraten lassen. Der Grund: ich schließe nicht aus, dass Microsoft sich auf irgendeinem Weg ein Verwertungs- oder gar Nutzungsrecht für die Projekte erkauft hat. Auch Microsoft stellt sich immer wieder die Frage nach "Make or buy" und hat in seiner Unternehmensgeschichte immer wieder Produkte anderer Hersteller in seine Palette eingebaut. Manche Firmen sind auch aufgekauft worden, um einen Wettbewerber loszuwerden. Und auf gerade diese Karte setze ich persönlich und habe eben gerade die Homepages von Tesla und Ferrari nach Spielzeug durchforstet ^^.

    Zu Beitrag #1:

    Wenn Du als User pi den Desktop startest, dann werden die Programme, die Du mit dem Desktop startest, auch mit den Rechten des Users pi gestartet. Das ist kein Fehler sondern ein Feature.

    Bei mir hat zum gleichen Problem betreff dem Deinstallieren von Pakete diese Vorgehensweise geholfen:

    Stoppen des Desktop, sodass ich wieder in einem Terminal lande. Dazu muss natürlich das OS so konfiguriert sein, dass es beim Starten nicht den Desktop automatisch startet sondern nur bis zum Terminal (CLI).

    Dann wird der Desktop mit root-Rechten wie folgt gestartet:

    sudo startx

    Nun kann man fast alle Programme mit root-Rechten nutzen.

    Sofern der Weg mit sudo immer noch nicht zum gewünschten Effekt führt, kann man noch einen Schritt weitergehen:

    Desktop stoppen und im Terminal dies eingeben:

    su root

    startx

    Wurde schon einmal versucht mit journalctl etwas herauszufinden?

    Um den genauen Zeitpunkt des Stillstandes zu ermitteln bzw. festzuhalten würde ich mir ein kleines Shell-Script bauen, das einfach alle 1-5 Sekunden mit dem touch-Befehl immer wieder die gleiche Datei anlegt. Nach dem Aufhängen des Pi und anschließendem Neustart kannst Du dann mit Blick auf die Datei dann auf wenige Sekunden eingrenzen, wann das Aufhängen genau passiert ist (ls --full-time <Datei>).

    Edit: Ich glaube, ich habe das Problem eingrenzen können, laut dieser Seite:

    http://doc.qt.io/qt-5/qsignalblocker.html

    ist QSignalblocker erst ab Version 5.3 vorhanden:

    Since: Qt 5.3,aber apt-cache show qt5-default sagt mir Version: 5.2.1

    Betreff der Version scheint etwas nicht ganz korrekt installiert worden zu sein: in der virtuellen Maschine, in der die Desktop-Variante von dem Raspian läuft (wie oben als Tipp ausgeführt), läuft bei mir QT in der Version 5.7.1. Es sieht danach aus, dass Du nicht die aktuellste Version hast.

    Unabhängig davon habe ich in der virtuellen Maschine die vermisste Include-Datei aber auch nicht gefunden.

    EDIT:

    In meinem C Programm soll zudem ein HTTPS Get ausgeführt werden. Momentan benutze ich diese Funktion:

    Code
    system("curl -u user:pass https://url.com/?action=zu_übertragende_daten > /dev/null 2>&1");

    Wie kann ich diese Code Zeile verbessern? Und wie ersetze ich " zu_übertragende_daten" mit einer Variable?

    Anstatt mit der Funktion system ein anderes Programm aufzurufen, solltest Du besser gleich die CURL-Bibliothek in Dein Programm einbauen, diese liegt ebenso als C-Code vor und lässt sich recht einfach für eigene Programme nutzen.

    Und wenn Du das hinbekommen hast, dann weißt Du auch, wie man in C Strings aneinanderketten kann.