alles Mius
meinst du "Minus"?
Alle dBm Werte kleiner als 1mW sind negativ, per Definition. 0 dBm entspricht 1 mW, also 3dBm = 2* 1mW und -3dBm = 1/2 mW
Worauf es ankommt ist (Anzahl unkorrigierter Fehler)= 2540 postBER= 0
unkorrigierte Fehler sind Bit-Fehler im roh empfangenem Signal. Da die Bitfolge bei digital modulierten Signalen mit Fehlerkorrektur codiert ist,
koennen einzelne Bit Fehler fast immer rekonstruiert werden. Wenn dann postBER =0 rauskommt, ist dein Signal perfekt.
dvb-t2 Signal= -62,00dBm S/R= 21,00dB UCB
Eselsbrücke 1: 3 dB entspricht in etwa Faktor 2
Eselsbrücke 2: 10 dB entspricht Faktor 10.
Das reicht fast immer.
Dezibel sind ein logarithmisches Mass, deshalb gilt 3dB + 3dB = 2*2 = 4.
20 dB= 10dB + 10 dB = 10*10 = 100
dBm ist das Verhältnis zu 1mW an 50 Ohm.
dB ist einfach ein Faktor (der Leistung, nicht der Spannung)
also: -62 dBm = -50 -12 = 1/ 10^5 / 2^4 = 1/ (100000*16) = 1/1600000 mW. (12dB = 4*3dB = 2*2*2*2 = 16)
und : 21dB = 7*3dB, also 2^7 = 128.
Wobei bei einem DVB-T Signal von -62 dBm und 21 dB S/N das Signal optimal sein müsste, also die Bitfehlerrate nahe Null sein sollte.
Manche Empfänger geben eine Empfangsqualität an, die sollte in diesem Fall 100% sein, sofern keine Interferenzen im Signal vorhanden sind.
ich bestelle regelmässig bei Aliexpress in China, aber nur Kleinzeug. Da fällt normalerweise keine Zollgebühr an, aber die Mehrwertsteuer wird seit Juli 22 automatisch erhoben.
Wenn man hin und wieder Kleinteile bestellt, dauert die Lieferzeit im Durchschnitt 3 Wochen.
Wenn man mehrere Posten gleichzeitig bestellt, wird man oft "upgeraded" zu "10 days Delivery". Die Teile werden dann irgendwo in Deutschland zu einem einzigen Paket zusammengepackt, und die Lieferzeit ist tatsächlich ca. +/- 1 Woche.
Sehr schlechte Erfahrungen mache/machte ich mit Prozessoren, speziell denen die bei serioesen Liferanten (Farnell, Mouser, RS, Reichelt...) nicht mehr lieferbar sind. Z.B. einen Atmega328P oder ATtiny85 würde ich nie wieder in China bestellen. Sie liefern zur Zeit nur Fakes oder 2.Wahl. Letzter Versuch im Sommer '22: 5 St. Attiny2313 bestellt, davon waren 4 bei Eintreffen kaputt. Sofort reklamiert, nach 3 Tagen rückerstattet.
Bevor man Prozessoren oder hoeherwertige IC's in China bestellt sollte man auf jeden Fall schauen ob die einschlägigen Distributoren die Teile auf Lager haben. Wenn nicht, Finger weg!
Zur Ehrenrettung von Aliexpress muss ich sagen dass sie alle meine Reklamationen ohne weiteres rückerstattet haben, ich musste die Ware mit einer Ausnaheme nie zurücksenden.
Wenn eine Lieferung nach 60 Tagen nicht bei mir eintrifft, erstattet Aliexpress die Kosten anstandslos zurück.
Während der C Geschichte gabs hin und wieder Probleme mit der Post, wenn Lieferungen als geliefert gemeldet wurden aber nie bei mir angekommen sind. Da zahlt Aliexpress nicht, das ist super ärgerlich aber nicht zu ändern. Inzwischen läuft das aber wieder wie geschmiert.
Viel Erfolg beim Implementieren des Protokolls.
AndrePi: Achtung Ironie!
Ich rate dir dringend: versuch es erst gar nicht.
Hier muss man nicht um den heißen Brei herum reden, sondern einfach nur sagen, und die Frage des TO beantworten: -> "Es geht !" oder "Es geht nicht !"
Es geht!
Der Rest ist Geschmacksache.
Die Idee mit dem USB Cardreader ist insofern ungünstig als der Zero nur einen einzigen USB Port hat und der würde hier vom AVR Brenner benutzt. Ein zweites USB Gerät koennte man also nur mittels USB Hub anschliessen.
Die Idee mittels extra SD Karte bestimmte/neue Dateien auf das System zu spielen finde ich auch ziemlich bloed, da ist SSH/FTP über WiFi wesentlich praktischer. Das System Einrichten, Autostart konfigurieren, Python Programm entwickeln/ueberspielen etc muss der TE sowieso auf der SD Karte im Slot machen. SD Karte rein-raus-rein-raus ist am Raspberry etwas problematisch, mir sind auf die Weise schon zwei Raspberries (Mk1 VersionB) kaputt gegangen.
Aber wie gesagt das ist Geschmacksache.
Deshalb schrieb ich in Beitrag #6:
Praktischerweise würde ich einen Zero W nehmen, der hat WiFi und damit tut man sich enorm viel leichter beim Entwickeln, Uebertragen von Dateien und Warten des Systems, weil man mittels SSH vollen Zugriff auf den Raspberry hat.
soll dieser eine USB Anschluß des Zero's nur für 350 mA ausgelegt sein
Und wo ist jetzt das Problem? Der Brenner nimmt < 10mA
wie auch den SD-Kartenlaser darüber betrieben
eben nicht. Der Raspbery Pi Zero W hat bereits einen SD Kartenleser integriert.
Und der Brenner muss ja nicht über USB versorgt werden.
nicht notwendigerweise, aber wenn es der o.g. DIAMAX Brenner sein soll dann schon.
ist das Dateisystem dieses RasbianOS nicht ohne weiteres und mit Hilfe eines Windows-basierten PCs zu beschreiben.
Fake News. Von der Raspberry Pi Foundation gibt es den "Raspberry Pi Imager" welcher auf meinem Windows 10 einwandfrei funktioniert. Daneben gibt es eine Reihe weiterer Tools wie z.B. den Win32DiskImager.
Die Idee mit dem Raspberry Pi Zero ist aus meiner Sicht ebenfalls die beste und einfachste Herangehensweise. Ich hab interessehalber ein wenig gesucht ob es kleine mobile Systeme mit Linux drauf gibt, aber was ich gefunden habe sind mehr oder weniger nur experimentelle und/oder Bastler Loesungen. Praktischerweise würde ich einen Zero W nehmen, der hat WiFi und damit tut man sich enorm viel leichter beim Entwickeln, Uebertragen von Dateien und Warten des Systems, weil man mittels SSH vollen Zugriff auf den Raspberry hat.
Ein SD-Kartenleser muss wohl auch noch dran.
Muss er nicht, weil der Raspberry Pi Zero sein Betriebssystem und sein Filesystem auf einer Mikro-SD Karte hat. Das ist schon einmal eine Komponente um die du dich dann nicht mehr kümmern musst.
Ich gehe mal davon aus du machst das Raspberry OS (light Version) auf die SD Karte, zusammen mit avrdude und einem Verzeichnis in dem die hex Dateien stehen.
Der AVR Brenner wird an dem (einzigen) USB Port angeschlossen den der Zero hat.
Wie man ein paar Taster und LED's an den Raspberry hängt steht in jeder Anleitung für Raspberry Pi Anfänger.
Das ganze mit einem Python Programm zusammen gehängt, ist das problemlos zu machen.
Ist das mit einem PICO überhaupt umsetzbar ?
die Hardware ist kein Problem.
Ich sehe allerdings ein grosses Problem bei der Software: Auf dem Pico läuft kein Linux. Und damit ist es wieder ein Problem mit der Hardware.
Das heisst du musst den Code der den ATTINY85 flasht irgendwo als Source nehmen (z.B avrdude) und auf dem Pico umsetzen. Ich kann mir nicht vorstellen dass das jemals jemand versucht hat.
Der burn-o-mat benutzt hoechstwahrscheinlich avrdude als im Hintergrund laufende Software zum Flashen. Der AVR Brenner setzt die von avrdude kommenden Kommandos auf den ISP (SPI Interface) um. Die Brenner Software gibt es für Arduinos zusammen mit der Arduino IDE. Den Source Code von avrdude gibts auch, ist aber ziemlich komplex und du müsstest den Code irgendwie auf deine Bedürfnisse herunterbrechen.
Vielleicht hat jemand eine Idee ob es eine Platform gibt auf der ein minimales Linux OS läuft so dass man avrdude leicht(er) portieren kann?
Also weil du mich gerade verunsichert hattest, habe ich es nochmals mit einem minimal Beispiel probiert, aber der zeigt definitiv eine 0 bei den verfügbaren Geräten an, egal ob 1 oder 2 Sensoren angeschlossen sind
jetzt hast du mich verunsichert, deshalb hab ich nochmal in meinem Sketch nachgeschaut und getestet, bei mir funktionierts einwandfrei.
Zwischen Einschalten der Versorgungsspannung und begin() habe ich 10ms delay gesetzt, und zwischen begin() und sensors.getDeviceCount() ebenfalls 10ms. Warum weiss ich nicht mehr.
Meine Version der Bibliothek ist allerdings schon etwas älter, Version 3.7.2
Das ist bei mir beim testen immer 0 gewesen, obwohl ich Temperaturen auslesen konnte. Frag mich nicht wieso,
kann ich dir beantworten: du musst, bevor du irgendwas machst, sensors.begin() aufrufen. Das wird (leider) nicht im Konstruktor gemacht.
Edit: sorry ich seh grad du machst das ja im setup() - dann hab ich erst mal keine Erklärung!
wenn z.B überhaupt kein Sensor gefunden wird, ist tempC == 0 was groesser als -100 ist.
Mir fallen zwei drei Loesungen ein:
1. initialisiere tempC mit etwas das kleiner oder gleich -127.0 ist.
2. (meine Präferenz) verlasse die Schleife mit break; statt der unschoenen Zuweisung tempC=-127.0;
3. Besser: die Anzahl der gefundenen Sensoren bekommst du mit sensors.getDeviceCount(). Dann kannst du es mit einer for Schleife abarbeiten.
@McFlyD Danke für das Video. Du triffst hier meinen Nerv weil ich derzeit herumprobiere womit ich am besten zurecht komme.
Ich habe früher wxWidgets in C++ verwendet, aber fand es umständlich. Der einzige Vorteil ist dass wxWidgets den Code direkt in der Zielsprache ausgibt.
Leider ist der Sound deines Videos bei mir extrem leise, ich musste mich in einem stillen Kämmerchen einschliessen um zu hoeren was du sagst.
Dein Video hab ich ganz durchgearbeitet und auch alles verstanden, nur die Tatsache dass du immer zwischen dem QT5 Designer und dem Editor (Spyder) umschaltest hab ich anfangs nicht mitbekommen, weil du es nicht explizit ansagst. Ich dachte das ist im QT Designer enthalten, fand aber nicht wohin ich klicken muss. --- Bis ich auf die Kopfzeile geschaut hab. Soll keine kritik sein, nur ein Verbesserungsvorschlag für evtl folgende Videos. Ansonsten 
Leider nicht, ich finde auch kein Datenblatt.
Ich habe hier ein Datenblatt der Firma Bopla, da kostet das DAE satte 8 Euro/St. Aber die sagen auch nicht welches Material sie genau verwenden.
vielen Dank für die Tips!
Als Sensor werde ich wohl diesen hier verwenden.
Zur Entlüftung schwebt mir sowas vor:
Das sprengt den Preisrahmen nicht, und E-PTFE ist nach meinen Recherchen ebenfalls hydrophob, sollte also auch gehen, oder?
bevor man auf den Port schreibt muss man ihn oeffnen. Es fehlt in deinem Code
ser.open()Bei meinen Funksensoren hab ich es bisher immer so gemacht:
Im Gehäuse sind Oeffnungen zur Luftzirkulation, der Sensor ist im Inneren des Gehäuses und der Sensor ist, wenn er im Freien oder im Kühlschrank bzw. Gefrierfach platziert ist mit einer Schutzkappe versehen. Diese Schutzkappe (Datenblatt im Anhang) ist laut Hersteller Luftdurchlässig aber nicht wasserdurchlässig.
Das einzige Problem: Wenn ich den Sensor zwecks Batteriewechsel aus dem Gefrierfach nehme geht die warme Luft schnell ins Gehäuse rein und die Leiterplatte wird logischerweise nass.
Das heisst, ich muss sowohl Platine als auch Gehäuse erst mal abtrocknen lassen, bevor ich eine neue Batterie einsetzen kann.
Ein Kollege von mir schlägt nun vor, das Gehäuse absolut luftdicht zu verschliessen und einen externen Sensor zu benutzen. Mein Verständnis dazu ist, dass dann im Gefrierfach die warme Luft im Inneren des Gehäuses relativ schnell kalt wird, früher oder später der Taupunkt unterschritten wird und sich im Gehäuse Kondenswasser bildet bzw. sogar Eiskristalle. Das kann ich gar nicht brauchen. Abgesehen davon braucht man eine Druckausgleichsmembran, welche Luftdruckschwankungen ausgleicht. richtig?
Frage an die Experten/Physiker unter euch: liege ich mit meiner Einschätzung richtig?
Können die DHT-Sensoren überhaupt sinnvoll im Kühlschrank / Gefrierfach funktionieren?
Andreas hat es etwas verklausuliert audgedrückt, aber die klare Antwort ist: Nein.
Der DHT22 ist nicht betauungsresistent und liefert unter 2.96V Betriebsspannung falsche Werte.
Ich hatte vor Jahren 5 St. gekauft, davon funktioniert nur noch einer, die anderen zeigeten immer 100% RH oder mehr an. Der gute ist bei mir im Keller wo das ganze Jahr mehr oder weniger konstante Temperaturen herrschen.
Neulich hatte ich einen der "kaputten" DHT22 aus der Schublade genommen und ausprobiert, und ploetzlich ging er wieder einwandfrei. Ich hab echt keine Ahnung wie sowas sein kann.
Als Alternative setze ich seit Jahren SHT21 bzw. SHT31 ein.
ich habe mich mit dem Thema schon jahrelang beschäftigt.
Das mit dem 1Ohm Widerstand in Serie hat bei mir nie wirklich funktioniert, obwohl ich ein gutes Oscilloskop besitze.
Für statische Anwendungen verwende ich ein handelsübliches, aber professionelles Multimeter, das einen µA Messbereich hat.
Zum Start schalte ich in den mA Bereich, und wenn der µC in den Schlafmodus gegangen ist, schalte ich in den µA Bereich um.
Bei billigen Multimetern funktioniert das nicht, da diese beim Umschalten den Stromkreis kurz unterbrechen.
Für dynamische Anwendungen denke ich ist der CurrentRanger dein Freund. Selbst habe ich tiefer in die Tasche gegriffen und mir einen R&S NGMO2 geholt.
Damit kann ich den Strom über die Zeit auch von schnellen Pulsen messen auch wenn der Puls über mehrere Strom Messbereiche geht. Tolles Gerät.
ch denke nurazur meint es anders.
Du sollst dein Wort "Test" in minicom schreiben.
So wars ursprünglich gemeint.
Wenn ich nurazur richtig verstanden habe, löst der echo Befehl einen Reset des Nano aus. Dadurch würde der gesendete Befehl entweder während des Reset oder im void setup() ankommen. Mir ist das zwar neu, könnte aber durchaus sein.
ich kann dir versichern, das ist wirklich so. Das muss auch so sein, denn sonst koennte man den Arduino nano nicht mit dem seriellen Interface flashen ("It is not a bug, it is a feature!"). Dass der echo Befehl nach Beenden von minicom jetzt funktioniert, ist jetzt mir neu, ich würde so aber nicht arbeiten wollen. Der Vorschlag war nur zum Testen gedacht.
Ich habe übrigens was Falsches geschrieben, der FTDI Chip ist mit DTR verbunden, nicht RTS, ich habs in meinem Beitrag korrigiert. Man koennte jetzt theoretisch, um den Reset zu vermeiden, den Kondensator entfernen der zwischen der DTR Leitung und den Reset Pin liegt, aber dann kann man den nano nicht mehr flashen.
jrx , ich loese solche Dinge mit Python. Das ist DIE Sprache für den Raspberry Pi, und Python ist vorinstalliert. Da braucht man nicht kompilieren.
Die einzige Hürde ist dass man das Modul pyserial noch extra installieren muss. Ausser dass man etwas Python Grundlagen verstehen sollte.
