Announcement: there is an English version of this forum on 
Florian S. schrieb: > bei unseren Tests erhalten wir wie gewünscht identische Dateien beim > Download von https://batronix.com/magnova/dist/stable/1_2_1.updt und > https://batronix.com/magnova/dist/stable/latest.updt. Welchen Link hast > du verwendet? > > Gibt es ggf. ein Caching-Problem? Welche Version wird nach dem Update > angezeigt? Beim Versuch, 1_2_1.updt mittels Webbrowser herunterzuladen, bekomme ich einen Fehler 404 angezeigt. latest.updt herunterzuladen funktioniert hingegen. Was die Datei enthält, kann ich mangels Magnova nicht sagen. Ein Hexdump der Datei beginnt mit: 00000000h: 53 61 6C 74 65 64 5F 5F 5A 0E CC A1 10 B2 DF 13 00000010h: E1 21 54 26 AF 45 72 DB 2E 56 72 FB 60 86 73 4C 00000020h: C5 FE BC 00 F3 1D F7 83 45 AA C0 4E 15 A4 7B 5D 00000030h: 8D 09 C3 3E 0B 56 C0 3E BD 26 BC ED 86 A4 13 3B
Angehängte Dateien:
Michael L. schrieb: > Bei 10 Jahren mach ich mir eher Sorgen um die LR44. Wieso? Die Batterien sind seit ungefähr 2010 im der Waage. Ich wiege mich fast täglich. Hatte ich damals umgebaut (Batteriehalter links), weil die Knopfzellen so schnell leer waren. Das einzige worum ich mich sorge, dass der kleber wieder nicht hält.
Andreas S. schrieb: > Beim Versuch, 1_2_1.updt mittels Webbrowser herunterzuladen, bekomme ich > einen Fehler 404 angezeigt. latest.updt herunterzuladen funktioniert > hingegen. Was die Datei enthält, kann ich mangels Magnova nicht sagen. Hallo Andreas, du hast natürlich Recht: Ich habe die URL nicht korrekt angegeben. https://batronix.com/magnova/dist/stable/v1-2-1.updt sollte problemlos funktionieren.
:
Bearbeitet durch User
Andre schrieb: > Ja, beim Magnova lässt sich die Batterie recht einfach wechseln. Auf der > Rückseite des Geräts befindet sich eine Abdeckung, die durch das Lösen > von vier Schrauben (TX10-Kopf) entfernt werden kann. Darunter befinden > sich sowohl der Steckplatz für das Generatormodul als auch der > Batteriehalter. Danke, dass für den Batteriewechsel nicht das komplette Gerät zerlegt werden muss, wie z.B. bei Keysight (gefühlt 38 Schrauben). Nichtmal bei JBC, die ansonsten an alles denken, kann man die RTC-Batterien in den Lötstationen so ohne weiteres wechseln. + 2!
Sind die Dinger eigentlich "hackbar", so wie die Konkurrenz aus dem Land des Honigbären?
Ich hätte mal zwei Fragen zum UI: 1. Kann man den Kanal, auf den der Trigger reagiert, auch irgendwie mit weniger Klicks wechseln? 2. Kann man die Anzahl der Divs konfigurieren? Ich hätte in der Vertikalen gerne 10 statt 8. Ich kann zwar unter Anzeige auf Fine umstellen, aber dann bekomme ich nur mehr durchgezogene Linien (was leider nicht wirklich gut benutzbar ist, da es keine Unterteilung zwischen "Linie auf einem Label" und "Unterlinie" gibt. So kann man nur sehr schwer ablesen.) und mir geht es vor allem um die Anzahl der Labels zum Ablesen eines Messwertes. Klar, es gibt Tools dazu, aber warum soll ich rumklicken, wenn man mit einer intelligenten Labelwahl es einfach schnell ablesen kann, egal wo?
Beitrag #7795947 wurde von einem Moderator gelöscht.
Angehängte Dateien:
Christian schrieb: > Ich hätte mal zwei Fragen zum UI: > > 1. Kann man den Kanal, auf den der Trigger reagiert, auch irgendwie mit > weniger Klicks wechseln? Ja, das geht mit dem Antippen bzw. Anklicken des im Triggerbereich angezeigten Triggerkanals (siehe Screenshot). Nachtrag: Sorry, den Screenshot habe ich doppelt angehängt. Beide Screenshots sind identisch. >> 2. Kann man die Anzahl der Divs konfigurieren? Nein, die Anzahl der Divs kann nicht umgestellt werden.
:
Bearbeitet durch User
Andre schrieb: > von > > Andre Wenn du tatsächlich sogar der Chef von dem Laden bist, bessere Werbung kann man gar nicht machen. Ich schrieb schon oben, dass ich von deinem Laden richtig viel halte und immer zunächst bei euch schaue, wenn es um Messtechnik geht. Ich finde das super! Dann möchte ich dir und deinen Mitarbeitern, neben dem wirtschaftlichen Erfolg, schöne Weihnachten und einen guten Rutsch wünschen!
:
Bearbeitet durch User
Markus L. schrieb: > Ja, das war wohl ein Caching-Problem. Wenn ich einen anderen Browser > nutze, dann wird die korrekte Datei runtergeladen. Update direkt über Netz hat kein Caching-Problem - lies sich hier darüber perfekt updaten auf jetzt 1.2.1. :-)
Ich hätte jetzt auch mal eine Frage zu dem Magnova, obwohl ich als Rentner aus finanziellen Gründen nicht die Zielgruppe bin. Es geht um die FFT Funktion, welche implementiert ist. Dazu muss ich aber etwas weiter ausholen. Bei den Oszillografen welche ich kenne ( dazu gehört auch die MSOX Serie von Agilent ) wird der Frequenzbereich immer zwischen 0Hz und der halben Samplingrate berechnet. Die Anzahl der Stützstellen beträgt meist 1024 Wenn man jetzt aber eine hohe Mittenfrequenz bei einen kleinen Span sehen will, wird bei den meisten Oszillografen einfach die X-Achse gedehnt, so das die Anzahl der Stützstellen sich um den Zoomfaktor verringert. Damit ist die FFT Funktion für mich jedenfalls nur sehr eingeschränkt nutzbar. Wenn man z.B. bei 100MHz einen Span von 10KHz einstellen will, sieht man garnichts mehr , es sei denn man erhöht die Anzahl der Stützstellen ( was bei dem Magnova als einer der wenigen Oszillografen möglich wäre aber extrem rechenintensiv ist). Mein uralter FFT Analyzer HP3562 geht da anders vor. Er digitalisiert das Signal mit voller Samplingrate und mischt das Signal digital vorher auf eine niedrigere Frequenz welche dann bei den 1024 Stützstellen den kleinen Span ermöglicht. So kann ich z.B. den Sekundentakt des 77,5KHz Signals im Frequenzspektrum sichtbar machen. Die Zeit bis das Spektrum sichtbar ist, beträgt natürlich mindestens 1 / Stützstellenabstand. Das ist aber physikalisch bedingt. Für mich wäre es z.B. hilfreich wenn ich die Seitenbänder eines mit 1KHz modulierten 145MHz Trägers sichtbar machen könnte. Ist es angedacht bei dem Magnova dies auch so zu implementieren? Wird es irgendwann mal einen Batteriezusatz geben, welches man hinten dran schnallen kann? Der Magnova wäre ja prädestiniert für den Einsatz im Feld, wo nicht immer eine Steckdose vorhanden ist. Ralph Berres
> Es geht um die FFT Funktion, welche implementiert ist. Bedenke folgendes. FFT ist bei Oszis ja letztlich nur drauf gesetzte Software. Ausser bei den ganz alten Kisten da war es vermutlich auch noch eine Frage der Resourcen, also wieviel Ram hatte die Kiste. Man kann da sehr viel wollen. Ein sehr schoenes Beispiel dafuer was man kann wenn man nur will war das Hameg HMO2022/4. Ein schoenes Beispiel deshalb weil es die groesste und fetteste Kiste der Firma Hameg war. Da will eine Firma! Bei anderen Kisten, wie z.B meinem RTB2004 sind das aber eher die Einsteigermodelle. Die werden ganz bewusst etwas kastriert damit Leute die ernsthaft FFT brauchen die teuren Geraete kaufen. Dazu kommt noch was anders. Bei Oszis mit 8Bit Aufloesung ist FFT, naja irgendwie mal nett, aber auch eher bescheiden. So ab 10-12Bit bist du zwar immer noch weit weg von dem was ein echter Spektrumanalyzer kann, andererseits mag das fuer so manche Anwendung bereits brauchbar sein. Wenn der Hersteller auch noch Spektrumanalyzer verkauft dann mag er das vielleicht nicht so. .-) So gesehen kannst du also beim Magnova hoffen. Die haben keine eigenen Spekkis, die sind neu im Haifischbecken und muessen Aufmerksamkeit erregen. Da kann etwas preiswerte Innovation (Software ist ja immer umsonst :-) nicht schaden. > Der Magnova wäre ja prädestiniert für den Einsatz im Feld, wo nicht > immer eine Steckdose vorhanden ist. Echt? Das waer mir nun wirklich als letztes eingefallen. Im Feld brauchst du eher Geraete die nicht zu teuer sind weil sie mal in den Regen kommen oder mal irgendwo runterfallen und den ganzen Luxuskram braucht man eher nicht weil man da nicht entwickelt sondern nur Fehler sucht und das auch nur kurz weil Entwickler keine Sonne aushalten. :-D Vanye
Also bei meinem Rigol MSO5000 ist die FFT auch bei 8 Bits gut brauchbar und auch bei meinem Keysight DSOX20000A ist die gut. Jeweils mit ordentlich Punkten und auch halbwegs schnell. Normalerweise nutze ich die nicht, aber wenn ich sehen möchte ob ein schneller Takt funktioniert oder ob über ein schnelles LVDS Paar Daten laufen, dann geht das auch dank FFT mit einem günstigen Gerät. Einen 1 GHz LVPECL Takt sehe ich single-ended-gemessen noch als schönen Peak in der FFT. Klar über dem Rauschen. Auch im normalen Signalverlauf verschwindet der im Rauschen weil weit jenseits der Analogbandbreite (für -3 dB).
> Normalerweise nutze ich die nicht, aber
Das ist auch meine Beobachtung. So oft wird diese Funktion garnicht
genutzt und wenn dann eher von Leuten die sowieso einen echten Spekki
rumstehen haben. Da fragt sich vielleicht so mancher Hersteller wieso er
da Aufwand reinstecken soll.
Persoenlich finde ich da Bodeplotfunktionen VIEL nuetzlicher. Aber auch
die nutzt man nicht jeden Tag.
Vanye
Nun, ein Hersteller kann da jetzt für jeden Wunsch den ein paar Leute haben eine Funktion einbauen und damit den Preis für Alle hochtreiben und macht es doch Manchen wieder nicht Recht ... oder er stellt gute APIs zur Verfügung. Vielleicht auch mit SDK. Wenn man den Generator selber einstellen kann und dann gemessene Spannungswerte vom Oszilloskop-Teil lesen kann, dann kann man sich selber basteln was man braucht. Meine Meinung ist, dass das Gerät gute Standardfeatures haben soll, also die klassischen Oszilloskopeigenschaften. Dann noch gute Triggermöglichkeiten. Und den Rest würde ich dem Nutzer überlassen. Gerne wie bei anderen Herstellern bei denen man direkt Matlab Sktipte auf dem Gerät laufen lassen kann. Oder eine GUI wie bei Gnuradio. Man hat seine Blöcke und die kann man dann am Oszi verbinden und parametrisieren wie man will. Und natürlich soll es möglich sein auch eigene Blöcke hinzuzufügen.
Gustl B. (-gb-) 20.12.2024 12:38 >Gerne wie bei anderen Herstellern bei denen man direkt Matlab Sktipte >auf dem Gerät laufen lassen kann. Die Matlab-Lizenzen sind extrem teuer, deshalb hatten wir auf Python umgestellt. Ich bin eigentlich eher Matlab, aber mit der Zeit gewöhnt man sich auch an Python. Daher: Python wäre wichtig, das ist auch mit dem vermutlich darunter liegenden Windows kompatibler.
Vanye R. schrieb: > Bedenke folgendes. FFT ist bei Oszis ja letztlich nur drauf gesetzte > Software. Nö. Ich gehe sehr schwer davon aus, dass in dem Magnova ein Zynq Ultrascale o.ä. steckt und die FFT und viele andere Funktionen im PL ablaufen. Genau dafür sind ja solche Bausteine prädestiniert. Und die Logik im PL würde ich nicht als Software bezeichnen, da die Abläufe doch deutlich anders aussehen. > Wenn der Hersteller auch noch Spektrumanalyzer verkauft dann mag er das > vielleicht nicht so. .-) Ich war vor einiger Zeit von der FFT-Darstellung eines R&S RTO2000 ziemlich beeindruckt. Die war wesentlich besser als die meines alten Tektronix TDS5034B. Daran merkte man schon sehr gut, dass die HFler von R&S wohl einiges zur Bedienung beigetragen haben. > So gesehen kannst du also beim Magnova hoffen. Die haben keine eigenen > Spekkis, die sind neu im Haifischbecken und muessen Aufmerksamkeit > erregen. Da kann etwas preiswerte Innovation (Software ist ja immer > umsonst :-) nicht schaden. Vor allem muss Batronix keine Oszilloskopaltlasten herumschleppen. Da laufen bei manchen anderen Herstellern, z.B. auch in München, ganz andere Sachen ab... >> Der Magnova wäre ja prädestiniert für den Einsatz im Feld, wo nicht >> immer eine Steckdose vorhanden ist. > > Echt? Das waer mir nun wirklich als letztes eingefallen. Der mobile Einsatz kam mir auch in den Sinn. Allerdings kann ich auf der Rückseite nicht erkennen, dass dort irgendetwas vorbereitet wurde. Allerdings kann ich auch sehr gut verstehen, dass sich Batronix bei der ersten Geräteserie auch deutlich auf das Wesentliche beschränken musste, um innerhalb einer erträglichen Entwicklungszeit ein brauchbares und lieferbares Produkt auf den Markt zu bringen. Ansonsten kann man sich als Hersteller da ziemlich verheddern. > Im Feld > brauchst du eher Geraete die nicht zu teuer sind weil sie mal in den > Regen kommen oder mal irgendwo runterfallen Das sind vielleicht Deine Anforderungen, die Du auf Dritte projizierst. Und die werden von den Unmengen an (leistungsschwachen) Handheldoszilloskopen ausreichend bedient. Ein Magnova passt dann eben nicht. > und den ganzen Luxuskram > braucht man eher nicht weil man da nicht entwickelt sondern nur Fehler > sucht und das auch nur kurz weil Entwickler keine Sonne aushalten. :-D Das ist vielleicht in Deiner sehr kleinen Welt so. Neben dem Feldeinsatz für Techniker gibt es auch andere halbmobile Anwendungen, bei denen ein leistungsfähiges Oszilloskop wichtig sein kann. Einer dieser Fälle wäre z.B. die Arbeit ohne Massebezug bzw. auf deutlich abweichendem Potential. Bei einem meiner Kunden liegen wirklich wichtige Teile der Elektronik auf +50 kV bis +400 kV. Aber auch wenn es nur um die Vermeidung von Brummschleifen geht, bieten sich mobile Messgeräte an. Da sich viele bessere Oszilloskope auch per PC aus der Ferne fernsteuern lassen, ist so etwas mittels WLAN oder LWL-Netzwerkstrippe durchaus leicht machbar. Und üblicherweise regnet es dann auch nicht, und es fällt auch nix herunter.
Soeben habe ich gesehen, dass der Einführungsrabatt verlängert wurde bis zum 15.01.2025.
> oder er stellt gute APIs zur Verfügung. Vielleicht auch mit SDK. > Wenn man den Generator selber einstellen kann und dann gemessene Ja sicher waer das optimal, fuer uns Kunden. :-D Hab ich ja oben auch schon mal erwaehnt. Vergleich das z.B mal mit dem HP48, oder seinem Vorgaenger dem HP41. Dafuer gab es tausende von Programmen die jedes Mathematische Problem perfekt abgebildet haben und die du heute noch im Internet runterladen kann. Sowas koennte und wuerde sich dann sehr schnell auch fuer Oszis entwickeln. Das Teil koennte jede denkbare Funktion fuer FFT, Bodeplot vom feinsten, Transistortester, Terminalsoftware, Logicdecoder fuer jeden denkbaren Bus, Software definded Radio, usw... Einfach weil es fuer jedes Thema immer einen faehigen Freak gaebe der sowas programmiert und zehn andere die es verbessern. Das Problem ist nur das die grossen Hersteller bei ihren dicken Oszikisten die Kohle ja auch ueber solche Softwaresachen machen. Ich denke im uebrigen das sowas kommen wird, aber erst in 3-4Jahren. Auf der Embedded gab es ja schon ein Oszi das man in Python(Oerks) programmieren konnte. Da kommt schon noch was... > Nö. Ich gehe sehr schwer davon aus, dass in dem Magnova ein Zynq > Ultrascale o.ä. steckt Klar, wenn sowas da ist dann ist es da und macht die Sache etwas schneller. Aber unbedingt brauchen wuerde man es erstmal nicht. Selbst mein Handy ganz schon ganz passable FFT fuer kostenlos. > Daran merkte man schon sehr gut, dass die HFler von > R&S wohl einiges zur Bedienung beigetragen haben. Gerade bei R&S merkst du aber auch sehr gut das die einfachen Modelle weniger koennen wie die teuren. Das mag manchmal auch an teurer Hardware haengen, aber ich bin mir sicher das es oft auch nur ein define im Buildtool waere. Sowohl mein RTB wie auch das HMO davor hab ich beide mit allen Lizenzen gekauft. Beide waren damit doppelt so teuer wie das Standardmodell mit nix. Und beide hab ich als irgendeine Weihnachtsaktion gekauft wo die Lizenzen kostenlos dabei waren. Das HMO hab ich im uebrigen damals gekauft weil es fuer ein Agilent, was ich auch ins Auge gefasst hatte, so eine Aktion nicht gab. Es waere deshalb 2000Euro teurer gewesen. Das sagt einem doch einiges oder? > Das sind vielleicht Deine Anforderungen, die Du auf Dritte projizierst. Selbstverstaendlich! Genauso wie du deine Anforderungen projizierst. Ein Hersteller muss sich aber Fragen ob es genug von einer Sorte gibt um eine spezielle Hardware zu rechtfertigen. ES reich ja auch nicht einfach ein Loch zu lassen wo man einen Bosch 18V Akku reinschiebt. (schade eigentlich) Da kommt dann noch der ganze Zoo an eigenem Akku, Ladegeraet, Zoll und zertifizierung-spass zum Akkuversenden per Luftfracht, Recyclingvorschriften fuer Akkus und und und. Kennst du ja bestimmt... > Das ist vielleicht in Deiner sehr kleinen Welt so. ts, ts.. Meinst du deine Welt ist gross genug um ein paar tausend Stueck zu kaufen? Damit es sich lohnt? Und projizierst du da nicht deine kleine Exotenanwendung auf andere? .-) BTW: Waer doch eigentlich ein cooles Weihnachtsprojekt. Ihr macht euer Oszi auf, schaut mal was da fuer ein STandardnetzteil mit welchen Spannungen drin ist, baut dann ein eigenes Schaltnetzteil und lasst hinten ein Loch fuer den Bosch/Makita/Aldi-Akku den ihr sowieso habt. Andererseits, es gibt doch keinen Techno-influenzer mehr der einem nicht die neueste Lithiumkiste mit 230V Ausgang fuer die naechste Dunkelflaute aufquasseln will. Vielleicht einfach sowas zu kaufen. Vanye
Vanye R. schrieb: >> Normalerweise nutze ich die nicht, aber > > Das ist auch meine Beobachtung. So oft wird diese Funktion garnicht > genutzt und wenn dann eher von Leuten die sowieso einen echten Spekki > rumstehen haben. Da fragt sich vielleicht so mancher Hersteller wieso er > da Aufwand reinstecken soll. > Persoenlich finde ich da Bodeplotfunktionen VIEL nuetzlicher. Aber auch > die nutzt man nicht jeden Tag. > Bei dem Zeug was wir unter anderem machen wird die FFT (LeCroy irgendwas mit 8bit/500MHz) sehr oft genutzt, denn wenn man mit irgendwelchen nichtlinearen, auf Resonanz und mit Leistung angesteuerten Piezoteilen herumwerkt sind die Spannungen besser über breitbandige Diffprobes bzw. Stromzangen handhabbar als über das, was ein normaler SA so bietet. Der Erkenntnisgewinn ist - obwohl wir das eh schon lange machen - immer wieder erstaunlich wenn dieses Gerätefeature einfach so funktioniert und nicht erst ein anderes Gerät aus dem Kasten geholt werden muß. Dafür können auf normalen SAs Signale sichtbar gemacht werden die man mit einem normalen Oszi nicht mal ansatzweise sieht. iaW: wir nutzen die FFT während der Entwicklung ziemlich häufig, die FFT-Fähigkeit war mit ein wichtiges Kaufkriterium für das Magnova (und hat uns bei einem FU schon gut weitergeholfen)
Gustl B. schrieb: > oder er stellt gute APIs zur Verfügung. Vielleicht auch mit SDK. Das wäre zwar eine gute Idee, aber für das erste Produkt einer Modellreihe sollte man als Hersteller so etwas nicht zu früh veröffentlichen, denn dadurch schlägt man gewisserweise Nägel ein. Zum einen benötigt solch ein API/SDK eine umfangreiche Dokumentation, die sich nicht einfach so selbst schreibt, sondern vor allem wichtige Ressourcen in der Entwicklung benötigt. Für den größten Teile eines normales Benutzerhandbuches reicht hingegen ein technischer Autor, der sogar vorzugsweise nicht zu den Produktentwicklern gehört. Ein schon veröffentlichtes API kann man als Hersteller auch nicht einfach mal ändern, sondern muss hierzu immer kompatibel bleiben. Und der Support hierfür frisst auch wieder Entwicklerkapazitäten. > Wenn man den Generator selber einstellen kann und dann gemessene > Spannungswerte vom Oszilloskop-Teil lesen kann, dann kann man sich > selber basteln was man braucht. Abgesehen von der geringeren Geschwindigkeit bzw. höheren Latenz lässt sich doch so etwas auch über eine normale SCPI-Schnittstelle von außerhalb steuern? Und die ist ja in Arbeit bzw. kürzlich veröffentlicht. > Meine Meinung ist, dass das Gerät gute Standardfeatures haben soll, also > die klassischen Oszilloskopeigenschaften. Dann noch gute > Triggermöglichkeiten. > Und den Rest würde ich dem Nutzer überlassen. Nö, als normaler Anwender will man eine aufgeräumte, aber dennoch vollständige Benutzeroberfläche vorfinden, ohne gleich programmieren zu müssen. Ein Oszilloskop ist primär ein Werkzeug, das nicht nur von engagierten Bastlern genutzt wird, sondern vorrangig von eher desinteressierten Leuten, die sich nur auf Druck ihres Vorgesetzten damit beschäftigen müssen. > Gerne wie bei anderen Herstellern bei denen man direkt Matlab Sktipte > auf dem Gerät laufen lassen kann. Das bedeutet hohe Lizenzkosten in der Serie, die sich eher nur bei High-End-Oszilloskopen lohnen. > Oder eine GUI wie bei Gnuradio. Man hat seine Blöcke und die kann man > dann am Oszi verbinden und parametrisieren wie man will. Und natürlich > soll es möglich sein auch eigene Blöcke hinzuzufügen. Daran habe ich tatsächlich auch schon gedacht. Im ersten Schritt würde es ja ausreichen, entsprechende Streaming-Quellen und -Senken per Netzwerk bereitzustellen, wobei natürlich die Bandbreite deutlich beschränkt wäre.
Vanye R. schrieb: > Gerade bei R&S merkst du aber auch sehr gut das die einfachen Modelle > weniger koennen wie die teuren. Das mag manchmal auch an teurer Hardware > haengen, aber ich bin mir sicher das es oft auch nur ein define im > Buildtool waere. Bei einigen Funktionen würde das aber auch bedeuten, Features der neueren oder höherpreisigeren Familien auf die kleineren Modelle portieren zu müssen. Wenn sich dies nicht durch den Marktdruck oder zusätzliche Einnahmen rechtfertigen lässt, unterbleibt es einfach. Oder ein Feature wird nur deswegen auf einer bestimmten Baureihe implementiert und ausdrücklich nicht auf anderen Baureihen portiert, weil dahinter ein bestimmter Auftrage eines Großkunden steckt. Über R&S weiß ich es aus erster Hand, dass so etwas bei deren Kommunikationstestern erfolgt. > Sowohl mein RTB wie auch das HMO davor hab ich beide > mit allen Lizenzen gekauft. RTB ist eine R&S-Entwicklung, HMO stammt noch aus der Hameg-Historie. > Beide waren damit doppelt so teuer wie das > Standardmodell mit nix. Und beide hab ich als irgendeine > Weihnachtsaktion gekauft wo die Lizenzen kostenlos dabei waren. Das HMO > hab ich im uebrigen damals gekauft weil es fuer ein Agilent, was ich > auch ins Auge gefasst hatte, so eine Aktion nicht gab. Es waere deshalb > 2000Euro teurer gewesen. Das sagt einem doch einiges oder? Diese Vertriebsmasche funktioniert doch schon seit langem bei allen großen Herstellern. Gerade die Sonderaktionen führen dazu, dass man nur noch darauf schaut, wie viel man wirklich einspart, ohne zu schauen, welche Zusatzfeatures man wirklich gekauft hätte. Natürlich kann man es sich als Kunde schönreden (Und wenn nächste Woche ein neuer Kunde auf der Matte stünde, bräuchte ich vielleicht doch sofort den ARINC-429- oder Flexray-Protokolldekoder!). > ES reich ja auch nicht einfach > ein Loch zu lassen wo man einen Bosch 18V Akku reinschiebt. (schade > eigentlich) Da kommt dann noch der ganze Zoo an eigenem Akku, > Ladegeraet, Zoll und zertifizierung-spass zum Akkuversenden per > Luftfracht, Recyclingvorschriften fuer Akkus und und und. Kennst du ja > bestimmt... Wesentlich entscheidender ist aus Herstellersicht, welchen Aufwand man bei Geräten betreibt, deren Kunden eben nicht das Zubehör kaufen. Den entsprechenden Hebel kann man leicht ausrechnen. Ein Mehraufwand von z.B. 5 EUR für den Einbauplatz einer Erweiterung, die nur 1% der Kunden kaufen, kostet dann nämlich effektiv jeweils 500 EUR pro Gerät. "Ein Loch" im Grundgerät bedeutet: - Steckverbinder auf der Hauptbaugruppe - Funktionstest für den Steckverbinder - Fräsen des Metallgehäuses - Gewinde schneiden - Entgraten - Abdeckung für die ungenutzte Öffnung - Schrauben für die Abdeckung - Montage der Abdeckung - Qualitätskontrolle der montierten Abdeckung - 1, 2 Blätter mehr in der gedruckten Bedienungsanleitung (pro Sprache) - 1 Blatt in dem gedruckten Pamphlet mit Sicherheitshinweisen (pro Sprache)
:
Bearbeitet durch User
> RTB ist eine R&S-Entwicklung, HMO stammt noch aus der Hameg-Historie. Ist grundsaetzlich richtig, aber da muss schon viel parallel gelaufen sein. Wuerdest du verstehen wenn du beide Teile mal besessen haettest. Da ist einiges an Source rueberkopiert worden. > noch darauf schaut, wie viel man wirklich einspart, ohne zu schauen, > welche Zusatzfeatures man wirklich gekauft hätte. Bei den Einsteigerkisten von denen wir hier reden sind die Zusatzfeatures IMHO alle ziemlich unverzichtbar. Aber das aendert sich natuerlich bei den teuren Teilen. Und wenn du dann alles im Paket fuer umsonst bekommst dann ist es ja egal. Vanye
[x] Magnova bestellen
Vanye R. schrieb: >> RTB ist eine R&S-Entwicklung, HMO stammt noch aus der Hameg-Historie. > > Ist grundsaetzlich richtig, aber da muss schon viel parallel gelaufen > sein. Wuerdest du verstehen wenn du beide Teile mal besessen haettest. > Da ist einiges an Source rueberkopiert worden. Verschiedene Sparten/Abteilungen von R&S waren jahrelang meine Hauptkunden. Daher kenne ich "zufälligerweise" auch einige der Rivalitäten zwischen den Abteilungen und Entwicklungsstandorten.
Hallo zusammen, wir hoffen, dass wir mit dem SCPI-Update vor Weihnachten weitere Erwartungen erfüllen konnten und dass alle hier erfolgreich ins neue Jahr gestartet sind. Während die Entwicklung an Firmware-Verbesserungen ebenso wie die Enwicklung neuer Features für das Magnova weiter voranschreitet, endete gestern der Zeitraum des Magnova-Einführungsrabattes (die "Kunden der ersten Stunde" haben ihre Geräte vor mittlerweile vier Monaten erhalten). Ab heute Tag gilt ein neues (UVP-)Preisschema für Magnova-Oszilloskope:
1 | Bandbreite | Standard | Nichtkommerziell (NC) |
2 | ----------------------------------------------- |
3 | 100 MHz | 2999 € | 2599 € |
4 | 200 MHz | 3749 € | 2999 € |
5 | 350 MHz | 4499 € | 3749 € |
(UVP ohne MwSt.) Wir haben uns entschieden, Privatkunden, Bildungseinrichtungen und gemeinnützigen Organisationen den Zugang zu erleichtern, indem wir separate Preise für nichtkommerzielle Zwecke einführen. Das Prinzip ist einfach: Nichtkommerzielle Kunden erhalten zum gleichen Preis die nächsthöhere Bandbreitenstufe, ohne jegliche Einschränkung der Funktionalität. Bei Fragen hierzu steht der Batronix-Service wie immer gerne zur Verfügung. Mit freundlichen Grüßen im Namen des Batronix-Teams Florian Schmidt
Gibt es Neuigkeiten zum BMO-AWG? Wird er "irgendwann" dieses Jahr verfügbar sein, oder kann man schon etwas konkretes sagen?
Markus M. schrieb: > Gibt es Neuigkeiten zum BMO-AWG? Wird er "irgendwann" dieses Jahr > verfügbar sein, oder kann man schon etwas konkretes sagen? In der verbindlichen Auftragsbestätigung meiner Bestellung ist der BMO-AWG für "Anfang Q2 2025" avisiert.
Angehängte Dateien:
-
magnova_p5050_SQ500.png
110 KB -
magnova_trigger.png
40 KB -
magnova_drift.png
230 KB
Seit ein paar Tagen habe ich nun auch ein BMO350 im Einsatz und bin auf der einen Seite recht begeistert von der gelungenen, aber noch nicht perfekten Benutzerführung bzw. Bedienbarkeit. Leider muss ich aber auch die schlechte Tastkopfkompensation bemängeln. Im Anhang befindet sich ein Bildschirmfoto mit zwei unterschiedlichen Tastkopftypen. Oben ein Tektronix P5050, unten ein Sensepeek SQ500. Bei dem P5050 ist der Überschwinger etwas geringer als beim SQ500. Zum Vergleich habe ich auch mal die Messungen mit dem Rechteckgenerator meines Tektronix TDS5034B durchgeführt, aber dieser niederfrequente Überschwinger sieht in beiden Fällen gleich aus. Einen Unterschied gibt es aber: das TDS5034B hat eine Anstiegszeit von unter 10 ns, das BMO350 aber nur 80 ns. Weiterhin bin ich sehr erstaunt über die sehr starke Drift der Nulllagen; insbesondere in den Bereichen <= 1 mV liegt der "Strahl" bei kaltem Gerät sogar teils außerhalb des Bildschirms. Nach dem erst ordentlichen Aufwärmen ließ sich eine ordentliche Selbstkalibrierung durchführen. Nach einer anschließenden Betriebspause von ca. 1,5 h und erneutem Einschalten dauerte es aber auch recht lange, bis die Nullagen wieder passten, siehe Bildschirmfoto. Die SCPI-Unterstützung ist beim derzeitigen Firmwarestand V1.2.1 noch äußerst rudimentär, d.h. die Befehle "*ESE?" und "*ESR?" liefern eine Leerzeile statt des Fehlercodes; "*OPC?" liefert "+1" statt "1". Letzteres ist zwar möglicherweise nicht explizit falsch, aber so ungebräuchlich, dass viele bestehende Skripte sicherlich auf "1" prüfen und damit irregeführt werden. Aber das sollte sicherlich alles in den nächsten Versionen glattgezogen sein. Bei einem Portscan mittels "nmap -p1-65535 -T4 -A -v 192.168xxxx" stürzt das Magnova übrigens völlig reproduzierbar ab. Als offene TCP-Ports werden 8080 (Webserver mit keiner leicht zu erratenden Seite, vermutlich für einen späteren Zugang vorbereitet), Port 30431 mit einer offenen libiio-Shell und Port 35601 mit unbekannter Funktion gemeldet. Noch ein Verbesserungsvorschlag: Für die Umschaltung der Triggerquelle muss man erst "umständlich" ins Triggermenü wechseln, obwohl Knopf 2 nicht verwendet wird. Daher wäre es durchaus sinnvoll, mit Knopf 2 die Quelle durchschalten zu können. Das sollte sich auch sehr schnell und einfach in der Firmware implementieren lassen.
:
Bearbeitet durch User
Was im Bild bei der Kompensation im Bereich von geschätzt 5 µs abläuft, ist bei meinem Keysight MSOX3102T nach wenigen ns zuende. Sowohl mit den Originaltastköpfen von Keysight (N2843A, 500 MHz, 10:1) als auch mit den unlängst erworbenen SQ500, von denen ich übrigens hellauf begeistert bin. Bei meinem alten HMO3524 mit den dazugehörigen Tastköpfen HZ350 sieht das Kompensationsergebnis ebenfalls wesentlich bessser aus. Dauer: wenige ns, ganz leicht unterkompensiert als beste einstellbare Form, von der Amplitude vergleichbar wie mit dem P5050 im obigen Bild. Sorry, das liegt wohl weniger an den Tastköpfen, als offenbar an der Eingangsschaltung.
Angehängte Dateien:
-
Trigger-QuickChannelSelect.png
110 KB -
TT-HF-612RA-100usDiv.png
100 KB -
TT-HF-612RA-10usDiv.png
100 KB
Andreas S. schrieb: > Weiterhin bin ich sehr erstaunt über die sehr starke Drift der > Nulllagen; insbesondere in den Bereichen <= 1 mV liegt der "Strahl" bei > kaltem Gerät sogar teils außerhalb des Bildschirms. Nach dem erst > ordentlichen Aufwärmen ließ sich eine ordentliche Selbstkalibrierung > durchführen. Hallo Andreas, Bitte führe direkt nach dem Start des Magnovas eine Kalibrierung im kalten Zustand durch. Achte darauf, dass im Kalibrierfenster noch "Temperatur cold" angezeigt wird. Dadurch wird die starke Offsetdrift bei deinem Gerät behoben und sie wird dann auch nach Neustarts stabil bleiben. Diese zusätzliche Kaltkalibrierung erfolgt normalerweise bereits in der Fertigung. Warum sie bei deinem Gerät fehlte, werden wir in den Fertigungsdaten prüfen. Bitte entschuldige den Umstand. > Die SCPI-Unterstützung ist beim derzeitigen Firmwarestand V1.2.1 noch > äußerst rudimentär, d.h. die Befehle "*ESE?" und "*ESR?" liefern eine > Leerzeile statt des Fehlercodes; "*OPC?" liefert "+1" statt "1". > Letzteres ist zwar möglicherweise nicht explizit falsch, aber so > ungebräuchlich, dass viele bestehende Skripte sicherlich auf "1" prüfen > und damit irregeführt werden. Aber das sollte sicherlich alles in den > nächsten Versionen glattgezogen sein. > Bei einem Portscan mittels "nmap -p1-65535 -T4 -A -v 192.168xxxx" stürzt > das Magnova übrigens völlig reproduzierbar ab. Als offene TCP-Ports > werden 8080 (Webserver mit keiner leicht zu erratenden Seite, vermutlich > für einen späteren Zugang vorbereitet), Port 30431 mit einer offenen > libiio-Shell und Port 35601 mit unbekannter Funktion gemeldet. Vielen Dank für den Hinweis zu den SCPI-Commands sowie den Portscan-Ergebnissen. Wir werden das prüfen und per Update beheben. > Im Anhang befindet sich ein Bildschirmfoto mit zwei unterschiedlichen > Tastkopftypen. Oben ein Tektronix P5050, unten ein Sensepeek SQ500. Bei > dem P5050 ist der Überschwinger etwas geringer als beim SQ500. Zur Tastkopf-Kompensation: Je nach Tastkopf sind 1% bis 2% Overshoot zu erwarten. Bei den beim BMO350 mitgeliefertern Testec TT-HF-612RA Tastköpfen um die 1%. > Noch ein Verbesserungsvorschlag: > Für die Umschaltung der Triggerquelle muss man erst "umständlich" ins > Triggermenü wechseln, obwohl Knopf 2 nicht verwendet wird. Daher wäre es > durchaus sinnvoll, mit Knopf 2 die Quelle durchschalten zu können. Das > sollte sich auch sehr schnell und einfach in der Firmware implementieren > lassen. Die Triggerquelle kann bereits ohne den Umweg über das Triggermenü umgeschaltet werden. Tippe oder klicke dazu auf die Triggerkanalanzeige im Triggerbereich (siehe Mauszeiger im Screenshot). Der zweite Drehencoder ist bei manchen Triggern frei verfügbar, aber nicht bei allen. Bei Triggern mit mehreren Triggerkanälen (z. B. Delay-Trigger, siehe Screenshot) steuert der zweite Drehencoder die zweite Triggerquelle. Viele Grüße André
Ab heute steht eine neue Firmware-Version (1.3.1) für das Magnova zur Verfügung. Außerdem gibt es ein neues Zubehörteil - den Batronix BMO-FS Fußschalter. Er löst das klassische Problem, dass man beim Messen öfter eine "dritte Hand" braucht. Während beide Hände für die Tastköpfe benötigt werden, können so Aufnahmen bequem per Fuß gestartet, angehalten oder einzelne Aufnahmen ausgelöst werden. Mehr Infos dazu: https://www.batronix.com/versand/zubehoer/BMO-FS.html Nachfolgend die Änderungen von Firmware-Version 1.2.1 auf 1.3.1: Neue Funktionalität: - Single-N-Modus hinzugefügt. - Cursor-Unterstützung für Mathematik-/Referenzkanäle hinzugefügt. - Mathe-Kanäle können jetzt in Formeln referenziert werden. - Die Lautstärke für Tonsignale (Maskentests) ist nun einstellbar. - Die Unterstützung für den Magnova-Fußschalter wurde hinzugefügt. - Konfigurierbare Hotkeys für die Tastaturbenutzung wurden hinzugefügt. - Eine gewünschte FFT-RBW kann nun im FFT-Dialog gesetzt werden. - Die Schriftgröße für die Rasterbeschriftung ist nun einstellbar. Optimierungen: - Die FFT-RBW ist dauerhaft in der Steuerungswahl sichtbar. - Peaks in der Peak-Tabelle und Marker in der Marker-Tabelle können angetippt oder angeklickt werden, um die Anzeige auf deren Frequenz zu zentrieren. - Trendcharts werden nur noch bei absoluter Notwendigkeit oder bei Clear zurückgesetzt. - SCPI-Befehle für X/Y hinzugefügt. - Die mathematische Vertikalskalierung kann nun auf höhere Werte gesetzt werden. - Die Funktion des Drehknopfes kann nun auch mit der rechten Maustaste aktiviert werden. - Die Pegeleinstellung für UART wurde präzisiert. Fehlerkorrekturen: - Absturz beim Abbrechen eines Updates behoben. - Neue Mathematikkanäle wurden unter Umständen nicht korrekt angezeigt. - Problem mit der statischen Netzwerkkonfiguration behoben.
Andre schrieb: > Zur Tastkopf-Kompensation: Je nach Tastkopf sind 1% bis 2% Overshoot zu > erwarten. Bei den beim BMO350 mitgeliefertern Testec TT-HF-612RA > Tastköpfen um die 1%. Nichtsdestoweniger würde ich gerne mal die ersten 10 ns nach der Flanke sehen. Das lässt sich doch bestimmt machen? Zeitbasis aufdrehen auf 10 ns/div?
Andre schrieb: > Außerdem gibt es ein neues Zubehörteil - den Batronix BMO-FS > Fußschalter. Ambitioniert bepreist: € 139,- Netto € 165,41 inkl. 19% MwSt.
Manfred P. schrieb: > Ambitioniert bepreist: Findest Du? Für einen USB Fussschalter eines hochpreisigen Oszis eher preiswert. Der pure Schalter kostet ja schon 40€. https://de.rs-online.com/web/p/fussschalter/1253709?gQT=1
Michael schrieb: > Der pure Schalter kostet ja schon 40€. Und der Rest geht dann für das Kabel und das passende Paar Schuhe drauf ;-) Mein Vorschlag: eine USB-Tastatur, die man per Hand, Fuß oder auch Nase antippen kann. Da bin ich aber wohl zu schlicht gestrickt.
Mi N. schrieb: > Kabel Ein wenig mehr als ein Kabel gehört schon dazu. Zur Erinnerung: Das Magnova richtet sich an eine kaufkräftige Schicht mit hohem Anspruch. 160€ für einen Fussschalter, da überleg ich nicht mal 2min wenn ich Bedarf für sowas habe. Bei R&S würde der gleiche Schalter wahrscheinlich 720€ kosten. Es spricht für Batronix so eine ungewöhnliche Lösung anzubieten. Lassen wir die also leben und hetzen einfach mal nicht nach dem letzen Cent der sich vortrefflich in einem China Sweatshop herauskratzen lässt.
> Mein Vorschlag: eine USB-Tastatur, die man per Hand, Fuß oder auch Nase > antippen kann. Da bin ich aber wohl zu schlicht gestrickt. Das ist doch alles Loserkram! Eigentlich braeuchte man eine Spracherkennung die bei "Bug" auf Single oder Stop drueckt. Muesste man doch heute eigentlich einfach an GPIB dran stricken koennen. Ich rufe aber immer nur den Namen das Arbeitskollegen. Der muss dann fuer mich druecken! Vanye
Michael schrieb: > Das Magnova richtet sich an eine kaufkräftige Schicht mit hohem > Anspruch. > 160€ für einen Fussschalter, da überleg ich nicht mal 2min wenn ich > Bedarf für sowas habe. Die Preisgestaltung ist mir schnuppe. 'Erschreckend' finde ich, daß man für eine simple Tasterabfrage schon USB bemühen muß. Vanye R. schrieb: > Ich rufe aber immer nur den Namen das Arbeitskollegen. Der muss dann > fuer mich druecken! Aber bitte auf Zuruf und nicht mit Fußstritt ;-)
Mi N. schrieb: > simple Tasterabfrage schon USB Workarround. Oder hat das Magnova frei programmierbare IOs die man dafür belegen könnte? Natürlich kann man auch jeden beliebigen Fusstaster auf Ext. Trigger legen. Batronix hat ne Lösung für 160€. Fertig. Next.
Mi N. schrieb: > Mein Vorschlag: eine USB-Tastatur, die man per Hand, Fuß oder auch Nase > antippen kann. Da bin ich aber wohl zu schlicht gestrickt. Niemand hält Dich davon ab, so etwas zu realisieren. Der Fußschalter des Magnova ist auch ein ganz normales HID. Man darf nicht vergessen, dass man bei dem Originalfußschalter nicht nur diese Hardwarekomponente selbst bezahlt, sondern auch die Integration ins Magnova selbst. Was würde es einem nutzen, wenn der Schalter nur EUR 40,- kosten würde, man aber eine Softwareoption für EUR 200,- dazukaufen müsste. Ich finde den Fußschalter übrigens schön schwer und robust gelungen. Die Anschlussleitung ist zwar etwas steif, aber dafür auch hinreichend lang. In der Praxis wird man natürlich des öfteren mal mit dem Fuß an der Leitung hängenbleiben bzw. den Schalter auch mit dem Fuß verschieben. Aus dem Grund ist es auch sicher sinnvoll, eine nicht allzu filigrane Anschlussleitung gewählt zu haben.
Vanye R. schrieb: > Muesste man > doch heute eigentlich einfach an GPIB dran stricken koennen. Du musst ganz tapfer sein: das Magnova hat gar keine GPIB-Buchse.
Mi N. schrieb: > 'Erschreckend' finde ich, daß man > für eine simple Tasterabfrage schon USB bemühen muß. USB ist eh vorhanden für Maus und Tastatur. Und der Fußtaster ist auch ein normales HID, so dass hierfür sowohl dieselbe/gleiche Hardwareschnittstelle (USB-Strippe) als auch dieselbe Software (USB-Stack und -Zugriffbibliothek) genutzt werden kann. Und vor allem muss keine Hardware im Grundgerät vorgehalten werden, die von den meisten Kunden nicht genutzt würde. Da auf dem Magnova ein "ganz normales" Linux läuft, ist auch eine USB-Hub-Unterstützung dabei. Somit benötigt man auch keine spezielle Batronix-Hardware, sondern kann ggf. einen USB-Hub von der Stange einsetzen. Der USB-HID-Ansatz ermöglicht es zudem, komplexere Bedienelemente, z.B. einen Doppelfußschalter, zu realisieren, ohne dass dies von vornherein auf Hardwarebeschränkungen am Grundgerät träfe. Und vor allem steht auch eine 5V-Versorgung am Bedienelement zur Verfügung, im Gegensatz zur hochohmigen Speisung bei einem einfachen Schaltkontakt.
> Du musst ganz tapfer sein: das Magnova hat gar keine GPIB-Buchse.
Ja stimmt, in der letzten Zeit zuviel Alteisen in den Fingern gehabt. :)
Aber ist ja fast noch einfacher mit Wlan ins Netz zu gehen und dann ein
Kommando an die Kiste zu schicken.
Vanye
Vanye R. schrieb: ... > Aber ist ja fast noch einfacher mit Wlan ins Netz zu gehen und dann ein > Kommando an die Kiste zu schicken. > Vanye Das sehe ich anders... Ich vermute, die Latenz im WLAN ist deutlich höher als die Nutzung eines USB-Tasters. Old-Papa
Old P. schrieb: > Latenz Ich glaube es gibt nicht viel was noch langsamer wäre als ein Mensch der HEUREKA ruft und auf den Fußschalter tritt.
Michael schrieb: > Old P. schrieb: >> Latenz > > Ich glaube es gibt nicht viel was noch langsamer wäre als ein Mensch der > HEUREKA ruft und auf den Fußschalter tritt. Das gilt aber auch für irgendeinen Aktor, den der gleiche Mensch über WLAN auslöst. Die menschliche Latenz ist also gleich... ;-) Old-Papa
> Die menschliche Latenz ist also gleich... ;-)
Sie ist in diesem System aber auch dominant.
Ich hatte uebrigens gerade noch eine brilliante Idee! Man braeuchte
einen kleinen Aufsatz auf die Nase, nennen wir ihn den
Nasenwackeldetektor NWD. Der merkt dann, oh, die Nase hat 1x oder 2x
gezuckt und schon sendet er 1-2 Kommandos. Geht aber wohl nur mit BLE
weil fuer Wlan die Batterie zu gross waere. Aber irgendwas ist ja
immer...
Vanye
Vanye R. schrieb: > noch eine brilliante Idee! Man braeuchte > einen kleinen Aufsatz auf die Nase, nennen wir ihn den > Nasenwackeldetektor NWD. Nein. Das ist keine brilliante Idee.
Andreas S. schrieb: > USB ist eh vorhanden für Maus und Tastatur. Und der Fußtaster ist auch > ein normales HID, Das ist schon alles klar. Hast Du ein Gerät und kannst Du sagen, ob der pediale Trigger auch mit einem bestimmten Tastencode funktioniert? Dann bräuchte man bei seltenem Bedarf nur eine billige Tastatur und eine Flex ;-)
hallo Michael meine Frage bezüglich FFT vom 20.12.2024 09:41 ist immer noch offen. Kannst du diese mal beantworten? Ralph
Angehängte Dateien:
-
2025_02_20__3_screen.png
110 KB
Hallo, ich beschäftige mich momentan mit dem Triggerausgang (AUX OUT). Hierbei stellt sich mir die Frage, wann der Ausgang wieder auf 0 zurückgeht. Hintergrund ist folgende Messaufgabe: Ich muss Impulse zählen, die mindestens 10 uSekunden breit sind (die Frequenz liegt bei einigen hundert Impulsen pro Sekunde). Meine Idee ist, den Trigger entsprechend zu konfigurieren und den externen Triggerausgang an einen Frequenzzähler anzuschliessen. Leider geht der Trigger scheinbar nicht mehr auf 0 zurück. Kann ich irgendwie anders die Triggerfrequenz erfassen? Vielen Dank, Markus
Markus L. schrieb: > stellt sich mir die Frage, wann der Ausgang wieder auf 0 zurückgeht. Am Bildschirm wird der Trigger out vermutlich so lange high sein, wie aquiriert wird. -> Stell die Zeitbasis passend ein, daß am Bildschirm nur ein Puls zu jeder Zeit sichtbar ist.
Thomas W. schrieb: > -> Stell die Zeitbasis passend ein, daß am Bildschirm nur ein Puls zu > jeder Zeit sichtbar ist. Hab ich probiert. Funktioniert nicht. Es werden nicht alle Impulse gezählt.
Markus L. schrieb: > Kann ich irgendwie anders die Triggerfrequenz erfassen? Ob das jetzt eine Kernfunktion des Magnova sein muß? An CH1 liegt doch ein ganz sauberes Digitalsignal. Nimm einen passenden RC-Tiefpass und stell den Trigger Deines Frequenzzählers so ein, daß erst Impulse >= 10 µs die Triggerschwelle überschreiten. Die Funktion kannst Du dann gut mit dem Oszilloskope überprüfen.
Für die Decoderfunktionalität habe ich noch ein paar Vorschläge: 1. Für die UART-Dekodierung mit ASCII-Darstellung sollte es in der Tabellenansicht möglich sein, nicht nur ein Zeichen pro Zeile darzustellen, sondern eine per CR, LF oder CRLF terminierte Textzeile. 2. Der Decoder sollte standardmäßig die Farbe des zugehörigen Kanals annehmen, zumindest in Betriebsarten mit nur einem Eingangssignal, z.B. UART. 3. Die Default-Schwellwerte für High und Low sollten auch bei 10:1-Tastköpfen bei 2,3 V und 1 V statt 23 V und 10 V liegen.
Andreas S. schrieb: > 1. Für die UART-Dekodierung mit ASCII-Darstellung sollte es in der > Tabellenansicht möglich sein, nicht nur ein Zeichen pro Zeile > darzustellen, sondern eine per CR, LF oder CRLF terminierte Textzeile. Danke für den Vorschlag! Wir nehmen das gerne in unsere Update-Wunschliste auf. > 2. Der Decoder sollte standardmäßig die Farbe des zugehörigen Kanals > annehmen, zumindest in Betriebsarten mit nur einem Eingangssignal, z.B. > UART. Die Farbe des Dekoderkanals kann bereits individuell eingestellt werden. Eine feste Zuordnung zur Kanalfarbe wäre auch bei UART nicht für alle Nutzer ideal. Eine optionale Einstellung, bei der sich die Dekoderfarbe automatisch an die Kanalfarbe anpasst, wäre natürlich machbar. Wir werden das intern besprechen, ich kann aber noch nichts zusagen. > 3. Die Default-Schwellwerte für High und Low sollten auch bei > 10:1-Tastköpfen bei 2,3 V und 1 V statt 23 V und 10 V liegen. Wenn der Teilerfaktor nach der Einstellung der Pegel geändert wird, werden die eingestellten Pegel mit "angepasst". Dieses Verhalten ist nicht optimal, und wir planen, es in einem der nächsten Updates zu verbessern, so dass die Pegel auch bei einer Änderung der Teilerfaktoren beibehalten werden.
> Danke für den Vorschlag! Wir nehmen das gerne in unsere > Update-Wunschliste auf. Fuck! Ich hasse es wenn ein Hersteller sowas sagt weil mein Oszi von einer anderen Firma ist...... Ich hoffe ihr fuehrt mich nicht in Versuchung und baut noch ein VT100 Terminal ein. Vanye
Andre schrieb: > Andreas S. schrieb: >> 1. Für die UART-Dekodierung mit ASCII-Darstellung sollte es in der >> Tabellenansicht möglich sein, nicht nur ein Zeichen pro Zeile >> darzustellen, sondern eine per CR, LF oder CRLF terminierte Textzeile. > > Danke für den Vorschlag! Wir nehmen das gerne in unsere > Update-Wunschliste auf. Sowas in der Art wäre tatsächlich sehr "cool". Ich habe zwar noch kein Magnova, aber wenn das AWG-Modul fertig ist und es ein attraktives NC-Bundle gibt könnte das durchaus passieren ;-) Als TO: Danke für die regelmäßige Rückmeldungen und das Mitlesen von Batronix hier, ich hoffe wir können diesen Thread möglichst "clean" halten.
Ich fänd es ganz nützlich, wenn beim Protokolldecoder eine Mathekanal als Quelle angegeben werden könnte. So wäre es dann möglich z.B. RS485 direkt zu debuggen. Markus
> So wäre es dann möglich z.B. RS485 direkt zu debuggen.
Warum nimmst du nicht einfach einen Kanal? Oder traust du deiner
Uebertragung nicht?
Vanye
Vanye R. schrieb: > traust du deiner Uebertragung nicht Im Zweifel nicht. Idealer Weise würde ich für die differenziellen Signale jeweils einen Kanal nehmen und subtrahieren, so wie es die (zu debuggende) Hardware auch macht. Und das Ergebnis dann in einen UART-Dekoder einspeisen. Ich könnte natürlich einen Kanal nehmen und die GND-Klemme auf das negative Signal klemmen. Das klappt aber nur, solange ich nicht noch ein weiteres Signal mit Massebezug oszillografieren muss. Markus
> Im Zweifel nicht. Dann schau kurz auf beide Kanaele, entscheide ob gut oder schlecht und mache dann weiter. Und im Zweifel greife hinter deinem RS485 Wandler ab weil du dann dessen Differenzbildung testest und nicht die andere Differenzbildung deines Oszis. > Ich könnte natürlich einen Kanal nehmen und die GND-Klemme auf das > negative Signal klemmen. Das klappt aber nur, solange ich nicht noch ein > weiteres Signal mit Massebezug oszillografieren muss. Gewisslich nicht. Du nimmst einfach das "normal" GND das du immer nimmst. Das geht schon. .-) Vanye
Vanye R. schrieb: > Dann schau kurz auf beide Kanaele, entscheide ob gut oder schlecht und > ... > Das geht schon. .-) Ja, natürlich geht das so. Man kann sich immer irgendwie "behelfen", aber aus meiner Sicht wäre das ein nützliches Feature. Das müssen wir hier aber nicht ausdiskutieren. Markus
Markus L. schrieb: > aber aus meiner Sicht wäre das ein nützliches Feature. So findet jeder ein Feature was ihm persönlich nützlich erscheint. Wenn all diese Wünsche implementiert werden, dann wird das Scope unbrauchbar. Es kann dann irgendwann "alles" aber nichts mehr richtig. Dazu bleibt dann weniger Zeit, um Bugs zu beheben. Hab ich selber schon öfter erlebt. Statt nervige Bugs zu beheben gibt es ein neues Release mit neuen Features die 2.3% der Anwender braucht. Der Bug der mich aber täglich stört, der bleibt. Noch ist das Scope wahrscheinlich gut.... Diese Nachricht ist insbesondere auch an Batronix gerichtet ;) Just my 2 cents
:
Bearbeitet durch User
900ss schrieb: > Es kann dann irgendwann "alles" aber nichts mehr richtig. Da könnte was dran sein. Ich habe schon Geräte auf dem Tisch gehabt, die mit allerlei Schnickschnack-Funktionen heillos überfrachtet waren. Dafüt fehlten dann essenzielle Funktionen wie Tastkopfreadout oder interner 50-Ohm-Abschluss.
900ss schrieb: > So findet jeder ein Feature was ihm persönlich nützlich erscheint. > Wenn all diese Wünsche implementiert werden, dann wird das Scope > unbrauchbar. > Es kann dann irgendwann "alles" aber nichts mehr richtig. Das ist ja meistens so. Und wenn man doch nach Jahren mal die xyz-Funktion benötigt, quält man sich erst durch ellenlange Handbücher und dann durch tief gestaffelte Untermenues. Old-Papa
:
Bearbeitet durch User
900ss schrieb: > Es kann dann irgendwann "alles" aber nichts mehr richtig. > ... > Dazu bleibt dann weniger Zeit, um Bugs zu beheben. > ... > Noch ist das Scope wahrscheinlich gut.... Da hast Du wahr.
Andreas S. schrieb: > Vanye R. schrieb: >> noch eine brilliante Idee! Man braeuchte >> einen kleinen Aufsatz auf die Nase, nennen wir ihn den >> Nasenwackeldetektor NWD. > > Nein. Das ist keine brilliante Idee. Wenn man den Faden weiterspinnt wird etwas daraus. Bspw. mit einem ESP32/Raspi mit Kamera eine Gesichtsmimikerkennung bauen. Praktisch HotKeys mittels Gesichtsgrimassen. Nur wird das nichts für <= 160,- Euro für einen Oszi Hersteller. So, weiter im Text, sehr informativer Thread über das neue Magnova.
Hallo, @ Batronix Ihr habt bewusst die BNC Anschlüsse an die Seite verlegt. Ist okay. Nun sieht man auf euren Schaltschrankbildern die notwendigen Bögen in der Verlegung der Tastkopfleitung. Konsequent wäre nun eure Tastkopfleitungen mit gewinkelten BNC auszustatten. Oder gibt es technische und andere praktische Gründe die dagegen sprechen?
Veit D. schrieb: > Wenn man den Faden weiterspinnt wird etwas daraus. Bspw. mit einem > ESP32/Raspi mit Kamera eine Gesichtsmimikerkennung bauen. Och nö, gibt es doch alles schon, aber viel einfacher und auch ohne Fußschalter: Beitrag "Tastkopf mit Knopf für Run/Stop Funktion"
Hallo, haben jedoch nur deren aktive Tastköpfe. > Konsequent wäre nun eure Tastkopfleitungen mit gewinkelten BNC auszustatten. > Oder gibt es technische und andere praktische Gründe die dagegen sprechen? Wenn ich meinen Gedanken weiter verfolge, so könnten alle Hersteller von Tastköpfen ihre Leitungen mit abgewinkelten BNC anbieten. Dann würde der Grund wegfallen warum Batronix die Anschlüssen an die Seite verlegt hat. Dann hätten alle mehr Platz vorm Oszi. Ich lasse mir den Gedanken umgehend patentieren. :-)
Veit D. schrieb: > Dann hätten alle mehr Platz vorm Oszi. Ich lasse mir den Gedanken > umgehend patentieren. :-) Aber nur, wenn Du es schaffst, den wertvollen Platz an der Oszi-Front dafür nicht zu verschwenden ...
Angehängte Dateien:
-
2025_05_15__1_screen.png
110 KB
Ich habe heute die Meldung
"Ein kritischer Fehler ist aufgetreten! Ein Neustart ist erforderlich".
bekommen. Bevor die Meldung eingeblendet wurde, hat der Trigger (Puls
>10ms) nicht mehr ausgelöst (bzw. konnte mit der Maus nicht mehr
aktiviert werden).
Nach dem Neustart funktioniert wieder alles wie gewohnt.
Was kann die Ursache für diesen "Absturz" sein?
Markus
:
Bearbeitet durch User
Hallo Markus, ich möchte dich bitten, über "Einstellungen" --> "Informationen" --> "Logs speichern" die Log-Daten abzurufen und uns das Ganze über das Ticketsystem ( https://support.batronix.com/ ) bzw. per Mail an magnova@batronix.com zu übermitteln. Anhand dessen werden wir dann gerne prüfen, welche Ursache (und Lösung) in Betracht kommt. Beste Grüße Florian
Florian S. schrieb: > Ticketsystem ( https://support.batronix.com/ ) Das Ticket ist erstellt. Viele Grüße, Markus
Moin Markus, da hier noch weitere Personen mitlesen, wollte ich auch an dieser Stelle noch einmal kurz antworten. Wie in meiner Antwort geschrieben, haben wir bereits Einblick in den Sachverhalt genommen (danke für die Bereitstellung der Informationen). Da ein weiterer Firmware-Release zeitnah bevor steht, werden wir uns nach dessen Bereitstellung eingehend des beobachteten Fehlers annehmen und versuchen, ihn auf unseren Bestandsgeräten nachzustellen. Wir schätzen es aktuell so ein, dass das zugrundeliegende Problem (in dem Rahmen, auf den wir es bisher eingrenzen konnten) überhaupt nur sehr vereinzelt auftreten kann. So wie ich es verstanden hatte, warst du erstmalig auf dieses Fehlverhalten gestoßen und konntest es durch einen Neustart tatsächlich abstellen. In jedem Fall werden wir prüfen, wie wir das Auftreten des Fehlers zukünftig verhindern können, denn so oder so soll die Funktion der Magnovas zu jeder Zeit sichergestellt sein. Viele Grüße, Florian
Florian S. schrieb: > warst du > erstmalig auf dieses Fehlverhalten gestoßen und konntest es durch einen > Neustart tatsächlich abstellen Ja, das ist korrekt. Ich habe das Magnova seit etwa 5 Monaten in Betrieb und dieses Verhalten erstmalig am 15.5. festgestellt. Nach dem Neustart funktionierte das Scope wieder und das Problem ist auch nicht mehr aufgetreten. Markus
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.