Jump to content

Loetkolben

Members
  • Gesamte Inhalte

    1.191
  • Benutzer seit

  • Letzter Besuch

Posts erstellt von Loetkolben

  1. da bin ich überfragt...

    Meiner Einschätzung nach ist dann der Abstand zwischen den beiden Antennen auch zu berücksichtigen.

     

    Stimmt. Dieser Abstand ist aber durch die Gehaeuseform (Loecher) vorgegeben.

     

    Spielen diese 5cm bei 2,4GHz eine Rolle oder nicht? Google und das Internet machen mich auch nicht schlauer.  :-\  Wenn ich es ausprobiere wird es gehen, aber wie gut? Habe ich 0% der Qualitaet (und somit Error-Free-Range) eingebuest oder doch vielleicht 40%??

     

     

    Wenn du wegen der Abschlusswiderstände eine Stehwelle hast, verlierst du auf jeden Fall jede Menge Leistung.

     

    Der elektrische Abschluss ist ja die Antenne und somit ist das kein Problem.

     

     

    Der Loetkolben

  2. Hallo reinweb.

     

    Bei den Kabeln kann ich nichts machen. Die sind fertig konfektioniert.

    Es gibt wohl welche fuer 15, 25, 30 cm. Meine sind nun 15 und 20 cm. Also auf den Milimeter habe ich es nicht genau ausgemessen, aber das kann ich gerne machen, wobei es aber nichts an der Tatsache aendert, dass ich die Laenge nicht andern kann.

     

    Ich mache mir eigentlich Gedanken ueber die Signallaufzeit, weil eben der Sinn der beiden Antennen ist aus der Laufzeitdifferenz einen Qualitaetsgewinn, sprich 150mBit, zu errreichen.

     

    Machen also die 5 cm die eigentliche Diversity Funktion zu nichte?

     

    Der Loetkolben

     

  3. Meine Frage hier wäre: Wenn du den Brick über die API Bindings resettest tritt das Problem dann auch auf?

     

    ICH? API?  ;D  Ich frage den Stack per TCP aus der Ferne ab und nutze die API der Bindings nicht.  ;)  Daher kann ich das so nicht nachstellen.

     

    Meine Erwartung ist, dass ein Reset per Software funktioniert und dass das Problem nicht durch den Reset an sich ausgelöst wird.

     

    Ok, verstanden. Das wuerde auch  dazu passen, dass der Verify in der Ursprungsversion nur bis 96% anzeigt, obwohl er wohl durchgelaufen ist. Der Rechner ist wirklich klein und ein wenig langsam.

     

    Ich habe dir eine weiter Version angehängt. Diese hat jetzt ein --restart-delay Argument:

     

    ./brick-flash-cmd-loetkolben -p /dev/ttyACM0 -f brick_master_firmware_2_3_1.bin --restart-delay 500

     

    Damit wird vor dem Restart 500 Millisekunden gewartet. Meine Erwartung ist, dass das einen Unterschied macht, da ich vermute, dass das Problem durch die engen zeitliche Abfolge der einzelnen Schritte entsteht. Dabei setzte ich voraus, dass nicht schon ein Neustart per API Reset() Funktion das Problem erzeugt :)

     

    Auch verstanden.

     

    Wenn es dir zu heikel ist das zu testen, dann können wir auch hier stoppen und uns mit der Erkenntnis begnügen, dass das Problem ohne Reset am Ende nicht auftritt. Dann würde ich einfach dem Script in der nächsten Version die --no-restart Option mitgeben und der Brick muss dann nach dem Flashen manuelle resettet werden.

     

    Heikel ist das falsche Wort, aber bei jedem Hardreset eine PC, und das noch in der Ferne, laueft einem Gaensehaut ueber den Ruecken, zumal es sich in diesem Fall noch um ein Flashmedium handelt. Das System braucht mit zweimaligem Reboot und Filecheck gerne 10 Minuten bis die Pings wieder beantwortet werden. Das ist eine seeeeeeehr lange Zeit wenn man darauf wartet. Das System ist aber nicht lebensnotwendig und so werden wir es mal antesten.

     

    Eine Antwort kommt also.

     

    Danke.

     

    Der Loetkolben

  4. Hallo zusammen,

     

    mal in die Technikrunde gefragt: Ist es ein Problem wenn man an einem WLAN Modul, was 2 Antennenanschluesse hat, eine Antenne mit 15cm Kabel und eine Antenne mit 25cm Kabel zu verwenden?

     

    Es geht um einen Banana Pi Router der das WLAN Modul an einer Seite hat, aber eben fuer ein passendes Gehaeuse 2 unterschiedlich lange Kabel benoetigt.

     

    Workaround waere natuerlich 2 25cm lange Kabel, aber da muesste ich eines schon fast "aufwickeln". ;-)

     

     

    Der Loetkolben

  5. Kurzer Feedbackbericht:

     

    # ./brick-flash-cmd-loetkolben -p /dev/ttyACM0 -f brick_master_firmware_2_3_1.bin --no-restart
    step: write...
    Writing firmware: 0 / 544
    Writing firmware: 1 / 544
    Writing firmware: 2 / 544
    Writing firmware: 3 / 544
    ...
    Writing firmware: 542 / 544
    Writing firmware: 543 / 544
    Writing firmware: 544 / 544
    step: verify...
    
    Verifying written firmware: 0 / 544
    Verifying written firmware: 1 / 544
    Verifying written firmware: 2 / 544
    ...
    Verifying written firmware: 542 / 544
    Verifying written firmware: 543 / 544
    Verifying written firmware: 544 / 544
    step: flag...1
    step: flag...2
    step: flag...3
    step: flag...done
    skipped step: restart
    
    Firmware successfully written, Brick should restart automatically   (<- Falscher Text. Ist aber klar warum.)
    #
    

     

    Tut!  :D

    Brick musste per USB-ab-an-stoepseln neu gestartet werden. Also wie erwartet. Alles gut! Brick laeuft, Rechner haengt nicht. Tip-top.

     

    Ich bin zufrieden, aber warum?  ;D  Soll heissen, ich wuerde gerne noch die Ursache finden.

     

    Lohnt sich der Aufwand das herauszufinden oder koennt ihr einfach die Programmparameter einschliesslich der der Pakethochzaehlanzeige mit in das Programm einbauen und in ein neues *.deb Paket verpacken. (Wenn denn mal Zeit ist.)

     

    Edit: Was ich nicht probiert habe ist ein Programmdurchlauf ohne alle Parameter mit der neuen Programmversion, da ich wieder "Angst" hatte, dass sich der Rechner weghaengt.

     

    Mein Tip aus dem Kaffeesatz ist immer noch, dass durch den Reset an Ende des Programms auch die "USB-Boot-Platte" kurzfristig mit abgehaengt wird.

     

    Danke!

     

    Der Loetkolben

     

  6. So, tut wieder nicht. Wie erwartet ist das flashen an sich fertig und der Verify auch. Der Verify ist ca. 6 mal schneller als der Flash durchgelaufen, aber ohne irgendwelche Auffaelligkeiten.

     

    # brick-flash-cmd -p /dev/ttyACM0 -f brick_master_firmware_2_3_1.bin
    Writing firmware: 0 / 544
    Writing firmware: 1 / 544
    ...
    Writing firmware: 542 / 544
    Writing firmware: 543 / 544
    Writing firmware: 544 / 544
    
    Verifying written firmware: 0 / 544
    Verifying written firmware: 1 / 544
    Verifying written firmware: 2 / 544
    Verifying written firmware: 3 / 544
    ...
    Verifying written firmware: 542 / 544
    Verifying written firmware: 543 / 544
    Verifying written firmware: 544 / 544
    _   <- Cursor, aber kein Shellprompt.
    

     

     

    Hier die Infos aus einem 2. Fenster in dem ich die ACM Devices geprueft habe.

     

    ## VOR dem flaschen!
    # ls -la /dev | grep ACM
    crw-rw---T  1 root dialout 166,   0 Mär 15 16:19 ttyACM0
    
    ## Waehrend des flashens
    # ls -la /dev | grep ACM
    crw-rw---T  1 root dialout 166,   0 Mär 15 16:21 ttyACM0
    
    ## NACH dem flashen.
    # ls -la /dev | grep ACM
    crw-rw---T  1 root dialout 166,   0 Mär 15 16:22 ttyACM0
    crw-rw---T  1 root dialout 166,   1 Mär 15 16:22 ttyACM1
    

     

    Also:

    Warum gibt es nach dem Flash 2 ACM Devices?

    Warum kommt das Flash Programm nicht in den Promt zurueck? (CTRL-C nicht moeglich).

    Warum kann ich "ls" Kommandos absetzen, aber kein "ps" mehr?

    Wie kann man alternativ eine Prozessliste ausgeben um den haengengebliebenen Flash-Prozess zu killen?

    Hat das doch was mit der "USB-Platte" zu tun, dass die iergendwie "abgehaengt" wird?

    Ein "reboot" wird zwar noch angenommen, aber es passiert nichts. Keine Reboot.

     

    Ein "reboot -f" ging dann "doch" noch.  :'(

     

    Ich brauche Hilfe!  :-\

     

     

    Der Loetkolben

     

  7. Heute mal ein Update bei den beiden Masterbricks auf Masterfirmware 2.3.1 versucht. Die Aenderungen an "/usr/bin/brick-flash-cmd" (s.o.) habe ich nicht gemacht gehabt.

     

    Er ist wieder bei Verify 96% haengengeblieben nach dem flashen des ersten Masterbricks haengengeblieben. :-(

    Der Rechner ist erstmal nicht abgestuerzt. Ich konnte mich weiter darauf umsehen (ls, etc.)

     

    Interesanterweise waren dann aber 2! ACM Devices vorhanden. (Vor dem Flaschen war definitiv nur ein Device da!). Kann das damit was zu tun haben, dass eben 2 Masterbricks im Stack sind oder das der Reset des ersten Masters nach dem flaschen nicht sauber im System war? Woher kommt ACM1?

     

    # ls -la /dev|grep -i ACM
    crw-rw---T  1 root dialout 166,   0 Mär 15 15:58 ttyACM0
    crw-rw---T  1 root dialout 166,   1 Mär 15 15:58 ttyACM1

     

    ABER:

    Als ich dann ein "ps -ef" gemacht habe ist die Ausgabe haengengebleiben, so als ob das ps Kommando auf die Rueckmeldung eines Prozesses wartete. Ein Einloggen oder andere Kommandos waren nicht mehr moeglich. :-) Also nur ein Hardreset.

    So, in Teil 2 wird der andere Masterbrick geflasht mit der Aenderung in " /usr/bin/brick-flash-cmd"

     

    Der Loetkolben

  8. Hallo.

     

    @photron:

    Die Idee hatte ich auch schon, aber ich finde das ca. 4 Jahre zu frueh. In 2 Jahren duerfen die Stecker "halbwegs verbreitet" sein, aber entweder teuer oder es gibt noch Inkompatibilitaeten bei den chinesischen Herstellern. Das war bei USB1.1 und USB2.0 nicht anders. Die ersten Kabel waren Mist.

    Der (Zwischen-)Schritt auf Micro-USB ist da wohl noch sinnvoll, oder.  ;)

     

    @derAngler:

    Das bleibt doch gehuepft wie gesprungen!

    a) Ich habe viele (Handy) Netzteile mit festem Micro-USB Stecker, aber eigentlich keine mit festem Mini-USB Stecker. ;-)

    b) Die Netzteile die eine "grosse" USB Buchse haben, habe ich auch, aber rate mal welche Kabel ich da oefters beim Kauf beigelegt bekommen habe?  ;) Richtig. Micro-USB. Soll heissen: Bei mir im Netzteilsammelsurium ist Micro-USB (mittlerweile) weitaus oefters vertreten. (Insbesondere durch die Handy-, Foto- und Zubehoerindustrie).

    Es gibt zwar auch Adapter, aber das macht den Stackanschluss dann sehr empfindlich.

     

    Viele Gruesse

     

    Der Loetkolben

     

  9. Hallo zusammen,

     

    waere es nicht sinnvoll in Zukunft die Bricks mit Mirco-USB anstelle von Mini-USB Anschluessen auszustatten?

     

    Auch wenn die Mini-USB Anschluesse vielleicht? mechanisch stabiler sind, so kommen doch alle neuen Geraete (Handy, Foto, Toaster) mit Micro-USB Anschluss auf den Markt und somit hat man viele Micro-USB Netzteile im Umlauf die man fuer die Stacks verwenden kann. Wie sieht es eigentlich mit der Strombelastung der Stecker aus?

     

    Gibt es dazu Bedarf oder bin ich der Einzige der diese Ueberlegung hat?

     

    Viele Gruesse

     

    Der Loetkolben

     

     

  10. Hallo zusammenn,

     

    mit Ueberraschung habe ich den Blog gelesen, dass es die Masterbricks nur noch mit 12 mm Steckern geben wird.

     

    Auf der einen Seite verstehe ich es, auf der anderen Seite wird ein Stapel aus 3 Masterbricks nun "viel" hoeher als Notwendig. - Na gut.  :-\

     

    Meine Bitte:

    Nennt den neuen Masterbrick dann bitte "Masterbrick 2.1b". Solltet ihr die gleichen (schon hergestellten) Platinen (PBC) verwenden, dann beschriftet beim Versand die Masterbricks doch mit einen "b" oder macht einen kleinen Aufkleber drauf. Warum?

    Sollte man mal einen Masterbrick gebraucht kaufen oder ueber so einen Masterbrick sprechen, dann kann man ihn besser unterscheiden und man muss nicht erst wegen den Steckerhoehen nachfragen.  ;)

     

    Weiterhin waere es vielleicht interessant im Shop, solange Vorrat reicht, beide Versionen anzubieten. So hat jeder die Moeglichkeit sich zu entscheiden.

     

    Viele Gruesse

     

    Der Loetkolben.

     

    PS: Ich wuerde in Zukunft wohl noch 2 Masterbrick 2.1 (9mm) benoetigen. Was muss ich tun?

     

  11.  

    Fuer:

     

    - Servo

    - Dual Button

    - Dual Relay

     

    Brauchst du NUR den Servobrick, an den du 7 Servos und 2 Bricklets anschliessen kannst. Die Verbindung zum PC erfolgt dann via USB.

     

    Am Master kannst du 4 Bricklets, aber keine Servos anschliessen. Anschuss an den PC auch via USB.

     

     

    WENN du nun lokal Daten sammeln willst, DANN kannst du einen RED Brick nehmen der Daten sammelt, speichert und logische Aktionen "Wenn - Dann" "vor Ort" ausfuehren kann.

     

    Wie geht gesagt: Ohne RED Brick muss die Logic und das Datensammeln auf einem PC stattfinden.

     

     

    Der Loetkolben

     

  12. Hallo zusammen,

     

    entschuldigt bitte diese Ueberschrift, aber ich habe in meiner Wohnung einen Geist den ich zu erlegen suche!

     

    Phaenomen 1:

    Wohnzimmer: 1 Meter links der Tuer Funksteckdose, 1 Meter rechts der Tuer RemoteSwitchBricklet. Steckdose EINschalten funktioniert. Beim AUSschalten kommt der Geist!

    Wenn ich im Nachbarzimmer bin, dann kann ich 10 mal den AUSschalten Befehl senden, es passiert nichts. Bin ich in dem Zimmer wo Steckdose und Bricklet sind und stehe in der Naehe der Funkstrecke, dann kann ich die Steckdose sofort ausschalten. Gestern 5 mal reproduzierbar durchgefuehrt. Der Verstand sagt, dass es eigentlich anders sein muesste.

     

    Phaenomen 2:

    Im einem anderen Zimmer steht eine Fritzbox (als ATA) und mach WLAN-AP. Im Keller (2 Etagen tiefer) ist ein Tinkerforgestack. Dieser hat 3 Bricklets die jede Minute abgefragt werden. Aufgrund der "duennen" Verbindung koennen nicht immer alle 60 Werte pro Stunde abgefragt werden, so dass ich einen Mittelwert aus den 1 bis 60 Werten bilde. So weit, so nachvollziehbar.

    Nun aber: Wenn ich die Wohnung verlasse kann die Software keinen einzigen Wert vom Stack abrufen, als ob die WLAN-Verbindung unterbrochen waere. Das sind 3*60 verlorene Werte pro Stunde. Pings sind auch nicht moeglich.

     

    Komme ich zurueck in die Wohung und gehe dort rum, koennen wieder Werte abgerufen werden. (Ping geht auch wieder durch). Typischerweise werden 40  bis 50 Werte pro Stunde, beim Abfrageintervall von einer Minute, gesammelt. Hier bin ich natuerlich den Funkwellen NICHT im Weg, da die Ausbreitung senkrecht, mit waagerecht angebrachten Antennen, ist.

    Auch hier muesste doch eine bessere Funkverbindung da sein, wenn niemand da ist.

     

    WARUM IST DAS SO??? Ich werde bekloppt!  :o  >:(

     

    Wer gerne Spot ablassen moechte darf das tun; vielleicht kommt da noch eine Seitenidee bei rum. Ansonsten freue ich mich ueber jede Anregung wie man der Sache auf den Grund gehen koennte.

     

    Ein paar Eckdaten:

    2.4 Ghz AP der FritzBox

    2 bis 3 Mittelschwache Fremd-WLANs sichtbar, aber Frequenzverschoben.

    4 bis 7 schwache Fremd-WLANs, meistens an den Fensterns zu messen

    Licht wird ausgeschaltet wenn ich nicht in der Wohnung bin.

    Nutze Gluehbirnen, Leutstoff- und LED Lampen gemischt.

    Mache 2 Monitore an wenn ich in der Wohnung bin.

    Ein Klein-PC und ein NAS laufen immer durch.

    Soll heissen: Wenn ich nicht da bin, ist weniger HF-Muell in der Luft.

     

    Ansonsten wuensche ich schoenes Wochenende.

     

     

    Der Loetkolben

  13. Die Sache ist, dass das Bricklet Zeit braucht um die Datenpakete "in die Luft" zu senden. Du kannst ja auch z.B. die Anzahl der Wiederholungen einstellen.

     

    Du musst das Bricklet abfragen ob es mit dem Senden fertig ist und dann den Auftrag fuer die naechste Steckdose schicken.

     

    BrickletRemoteSwitch.get_switching_state

    Returns the current switching state. If the current state is busy, the Bricklet is currently sending a code to switch a socket. It will not accept any calls of switch_socket until the state changes to ready.

     

    Wenn das nicht so waere, muesste das Bricklet eine unbestimmte Anzahl von Auftraegen puffern koennen.

     

    Solange nur ein Programm auf den Stack zugreift, kannst du auch mit deinem Workaround arbeiten wenn du weisst wie lange der Versand eines Funkbefehles ueber die Luft dauert.

     

    Alternativen: 2 Steckdosen auf die gleiche Adresse setzen oder 2 Remote Switch Bricklet benutzen.

     

     

    Der Loetkolben

  14. Wusste nicht dass es um RED geht. Da war doch mal was mit Wifi und RED:

     

    Hier:

    Re: RED Brick: WiFi

    kann ich dir sagen, dass die WiFi Extension noch nicht unterstütz wird, soll aber kommen. Bis dato benötigst du einen WLAN USB Stick.

     

    und hier:

    RED Brick

    Die WIFI Extension wird zur Zeit nicht unterstützt. Wir empfehlen die Nutzung eines WLAN Sticks um den RED Brick ins WLAN zu bringen.

     

    und andererseit steht das:

    Die genutzte Schnittstelle kann im Configuration Abschnitt eingestellt werden. Als erstes muss die Schnittstelle gewählt werden (Ein USB Ethernet Stick wird als ethX, eine Ethernet Extension als tfX und ein USB WIFI Stick als wlanX angezeigt (X ist eine Zahl). Abhängig von der gewählten Schnittstelle gibt es verschiedenen Einstellungsoptionen:

     

    Da kann Tinkerforge ggf. noch mehr zu sagen.

     

    Mir wuerde eine Dokuseite gefallen wo die 5 "Problemchen" der Hardware aufgelistet sind. Wie Masterbrick 2.0 mit Wifi/LAN flashen oder eben dies.  ;)

     

    Danke

     

    Der Loetkolben

  15. Hallo zusammen,

     

    Ich wuerde gerne die Version des Brickd mir im Brickv anzeigen lassen um eben Updatenotwendigkeiten zu erkennen. So viel ich mich erinnere gab es das Thema schon mal aber ihr hattet es beiseite gelegt, da der Brickd aus python bestand und es dadurch schwierig war? Mittlerweile ist es ja ein Binary.

     

    Waere es mittlerweile (sinnvoll) moeglich dies zu implementieren? Z.B. bekommt der Brickd genauso eine API wie der Masterbrick und wird ggf. sogar mit enumeriert als zusaetzliches Brick(let) angezeigt?

     

     

    Viele Gruesse

     

    Der Loetkolben

     

     

    Hier noch ein paar alte Beitraege die aber das Thema nur tangieren:

    Version von BrickDaemon und -Viewer

    Versionierung

  16. Das Zugriffsproblem war (wie wohl von den Spezialisten sofort erkannt) das fehlende "sudo" beim Aufruf des BrickViewers.

    -->In der Anleitung fehlt die Angabe, dass der BrickViewer für das Flashen als sudo gestartet werden muss.

     

    Vielleicht muss aber auch nur die Berechtigungen fuer das /dev/flash_device angepasst werden oder eine /etc/group richtig gesetzt werden?

     

    Gemäss Beschrieb muss der Erase-Button gedrückt gehalten werden und dann mit gedrücktem Button der USB Anschluss eingesteckt werden, damit Power am Brick ankommt und dieser startet.

    [Danach bitte den Erase Button loslassen] Und dann soll auch noch Reset gedrückt werden... eine Hand zu wenig?

     

    Nein, kein Problem ->einfacher: USB Power anschliessen, Brick starten lassen, Erase Button drücken und während gedrücktem Erase noch Reset kurz drücken, fertig.

    Oder ist das ein "unsauberer" Weg?

     

    Ne, macht im Prinzip das gleiche.

     

     

    Der Loetkolben

×
×
  • Neu erstellen...