WIFI Extension Diskussion

[borg]

Bevor wir die WLAN Erweiterung in großer Stückzahl produzieren lassen sollten wir vielleicht einmal kurz vorstellen wie wir uns die Hardware vorgestellt haben:

 

Da bei der Chibi Extension bemängelt wurde das man sie nur schwer in ein Gehäuse einbauen kann haben wir uns nun folgendes Konzept ausgedacht:

 

Die Platine verfügt über einen fest aufgelöteten U.FL Stecker (das ist so ein Miniatur Stecker der für WLAN verwendet wird). Für diese Stecker gibt es günstige Kabel die auf SMA umsetzen. Damit ist es dann möglich den SMA Stecker in ein Gehäuse zu schrauben.

 

Zusätzlich soll es aber natürlich auch möglich sein SMA Antennen anzuschließen ohne das ein Gehäuse benötigt wird. Dafür würden wir dann eine kleine Halterung mit einem Mini U.FL Kabel anbieten welches den SMA Stecker so nach draußen legt wie es bei der Chibi Extension der Fall ist.

 

Was haltet ihr davon?

 

PS: Ob wir das so machen ist auch abhängig davon ob wir so eine Halterung hinreichend günstig hergestellt bekommen, es kann also sein das wir hier über Sachen diskutieren die sich als unökonomisch herausstellen.

[ThomasKl]

welchen Vorteil hätte den der U.FL Stecker? kann man nicht auch von eine SMA Buchse aus mit einem Adapterkabel verlängern und zu einem eventuellen Gehäuse legen?

[borg]

Der Vorteil ist das kein Stecker vorne rausguckt der im Weg sein könnte.

[Christian]

Klingt für mich erstmal sehr Plausibel und gut :-). Dieser UFL Stecker, ist das sowas wie diese auf den Notebook-Funk-Steckkarten?

 

dieses Bracket lässt sich doch sicher als "billiges" Kunststoff-Spritzteil herstellen, oder? Und erste test-Modelle könnten ja aus dem 3D Drucker kommen :-).

 

Gruß Christian

[ArcaneDraconum]

Ich weiss nicht, wie oft sich diese U.FL-Verbindungen auseinander und wieder zusammenstecken lassen....

Was spricht dagegen, dass das WLAN-Modul an oberster Stelle im Stack sitzen muß (so wie das Powersupply ganz unten sitzt)? Dann könnte die die SMA-Buchse ziemlich mittig senkrecht nach oben zeigen. Und da kommt man auch gut ran mit dem anschrauben von Antennenkabeln, oder man schraubt die Antenne direkt an.

[Nic]

Wenn es irgendwie geht, so flexibel wie möglich das WIFI gestalten.

Ich hatte in der Verg. öfters die Situation, z.B. den Stepper unter, dann wieder über den Chibi zu stecken. Nur on the top schränkt die Stackfreiheiten zu sehr ein. Und das der Stecker bündig zur Platinenkante sein soll, wäre prima.

[Christian]

Ich weiss nicht, wie oft sich diese U.FL-Verbindungen auseinander und wieder zusammenstecken lassen....

 

also ich denk, dass die U.FL-Buchsen an sich schon einige Steckzyklen aushalten. nur die Stecker sind halt an sich relativ empfindlich glaub ich. Glaub nicht, dass diese mehr als 10-20 Steckzyklen mitmachen. aber das ist ja wahrscheinlich das geringste Problem. Ständig wirste das ja zum einen auch nicht umbauen, und so ein Käbelchen wird dann auch nicht die Welt kosten

 

Gruß

Christian

[The_Real_Black]

Kurze Codeseite Frage zum WLan: Wenn ich eine mobiles Gerät am WLan habe und einen anderen Masterbrick am PC direkt... geht dies dann über eine IP Connection? Oder brauche ich dann 2?

 

Beispiel:

- "Bodenstation": (Master + 2 Joysticks und ein Poti zB)

- "Roboter": (WLan, Stepper, Servo, IR usw...)

Müsste ich Code anpssen um von der Bodenstation dann den Stepper zu bedienen?

[Christian]

gute Frage. Ich denke mal das man 2 Verbindungen irgendwie starten muss. Eine Localhost die andere für WLAN-IP...

 

wie siehts eigentlich IPv6 Unterstützung aus? is zwar jetzt fast a bissl off Topic, aber das Thema wird ja immer konkreter...

[The_Real_Black]

@Christian: Wenn dass so wäre, dann müsste ich meine Singeltons in Doubeltons (lol, oder so) umwandeln. Im Moment habe ich alles mittels Singeltons implementiert da werde ich einiges ändern müssen.

[AuronX]

Also grundsätzlich wären 2 IPConnections nötig, aber ich denke es sollte gehen, dass man den Brickd dazu ermächtigt andere Brickd's zu kontaktieren und als "local" einzubinden. Also ich hoffe zumindest, dass es dort keine Protokoll-seitigen Einwände gibt. Die Idee wäre, dass der lokale Brickd-Service so tut als hätte er angeschlossene USB-Devices obwohl er nur andere Brickd's kennt.

 

Achso, die Frage nach der IPv6-Unterstützung ist ja gar nicht so blöd ^^ Aber ich befürchte, dass selbst heute noch die vorherrschende Meinung ist: "Darüber kann man später mal nachdenken"

[Nitram]

IPv6 ist eigentlich pflicht Program, da man sonst in den nächsten Jahren erst anfängt etwas zu entwickeln, dass eigentlich schon Standard sein müsste.

 

Selbst die großen ISPs kommen langsam auf den Trichter das man IPv6 braucht, und sobald der erste große ISP (z.B. Telekom) auf IPv6 umstellt, werden alle anderen und super viele Webseiten etc. nachziehen müssen. Wenn mann dann nicht schon passendes Know-How in dem Bereich gesammelt hat, beginnt die Suche nach dem Schuldigen im Unternehmen .

 

Ansich ist IPv6 im Heimbedarf ziemlich wurst. Der private Adressraum kann nicht überfüllt sein, da hinter jedem NAT ein neuer beginnt. Jedoch wäre es einfacher wenn alles einheitlich und gleich ist, dazu müssen einfach alle Netzwerkgeräte IPv6 können. Zugleich hohlt man sich mit IPv6 einige Sicherheitsprobleme ins Haus, die bislang wenig bis kaum gelöst wurden.

Beispielsweise gerade das NAT das im IPv4 Bereich stark verbreitet ist sollte im IPv6 bereich weniger stark bis gar nicht genutzt werden (so die "experten"). Gleichzeitig bietet NAT jedoch eine gute Basis-Sicherheit für Netzwerke und damit auch für Geräte wie den Brick.

 

Ich fände es schon wichtig wenn TF bei allen Geräten IPv6 direkt dazu plant, da in meiner Firma dies bereits seit 2 Jahren der Standard ist. Wer IPv6 kann, hat keine Nachteile, wer nur IPv4 kann verliert.

 

Wäre also schön wenn TF Zukunftsorientiert entwickelt!

Danke für das tolle Produkt

[Loetkolben]

Zum einen gebe ich euch Recht mit IPV6, zum anderen stelle ich mir vor wie viele User IPV6 mit den Bricks nutzen wuerden. 1 oder doch 2?

 

Ich denke Tinkerforge ist nicht dazu da den IPV6 Gedanken voranzubringen wobei man im richtigen Moment dabei sein sollte. Wenn andere, die es machen muessen (Telekom), IPV6 voranbringen, dann wird es sicherlich auch eine IPV6 Variante/Update geben.

 

Ergo: Es ist auch auf absehbare Zeit kein Bedarf vorhanden, sofern man in geschlossenen privaten Netzen arbeitet. Wenn es an eine direkte Internetconnection geht, sehe ich auch IPV6 auch als Pflichtuebung an.

 

Warum bleibt es intern noch laaaaange auf IPV4? Es muss im internen LAN noch IPV4 geben, selbst wenn es im Internet nur noch IPV6 geben sollte. Ich denke mal ueber Satreceiver, Drucker, Telefonanlage, Hifianlage, Powerswitch, Heizung, etc nach. Die haut niemand weg, nur weil es im Internet IPV6 gibt.

 

Das neue Pflichtfeld der Heimrouter heisst dann "IP-Translation im Heimnetz".

 

Der Loetkolben

[Nitram]

jo, sag ja NAT+Translation im Heimnetz wirds geben, die Sache ist nur bei Hardware oft etwas limitiert und wenn man mit IPv4 plant und keinen freien Speicher für deutlich größere IPv6 mehr hat, dann kann man schlichtweg nicht auf den Zug springen, weshalb es von vornherein geplant sein sollte. Geplant bedeutet ja nicht umgesetzt, lediglich die Möglichkeit vorgehalten.

[borg]

Kurze Codeseite Frage zum WLan: Wenn ich eine mobiles Gerät am WLan habe und einen anderen Masterbrick am PC direkt... geht dies dann über eine IP Connection? Oder brauche ich dann 2?

 

Beispiel:

- "Bodenstation": (Master + 2 Joysticks und ein Poti zB)

- "Roboter": (WLan, Stepper, Servo, IR usw...)

Müsste ich Code anpssen um von der Bodenstation dann den Stepper zu bedienen?

 

Mhhh, so wie es im Moment gedacht ist müsstest du bei der Initialisierung zwei IPConnections aufmachen, könntest aber danach alles so nutzen wie jetzt auch.

[borg]

@IPv6: Für Vorschläge von WLAN Modulen mit CE/FCC Abnahme die IPv6 können und in einen 3x3.5cm Platz passen sind wir offen .

 

Ich befürchte sowas gibt es nicht.

[Einstein]

@IPv6: Für Vorschläge von WLAN Modulen mit CE/FCC Abnahme die IPv6 können und in einen 3x3.5cm Platz passen sind wir offen .

 

Ich befürchte sowas gibt es nicht.

 

Ist IPv6 nicht einfach nur eine Frage des IP-Stacks - sprich Software?

 

@Nitram

eigentlich ist NAT kein sicherheitsfeature. Man könnte denken es hilft etwas aber es ersetzt nie eine richtige Firewall.

 

Gruß

 

P.S.: Also ich nutze IPv6 mittlerweile schon seit 2007/2008 und es läuft wunderbar ohne Probleme mit vielen Geräten bis so etwas exotisches wie den Fernseher (Samsung). Der Drucker jedoch kann es ohne Probleme (HP von 2009).

[Imbafestor]

Hm IPv6 wäre sicherlich interessant, aber ich halte es (derzeit) eher noch für unnötig, da die Bricks ja wenn eh nur im heimischen WLAN (mit IPv4) betrieben werden. Der Router soll dann eben für die IPv6 Verbindung nach außen sorgen.

Also ich denke für die meisten wäre das eher unwichtig.

 

Wichtiger in meinen Augen ist eher, dass die gängigen Verschlüsselungstechniken wie WPA, WPA2 unterstützt werden.

 

Schöne Grüße

[ArcaneDraconum]

Ich sehe es auch so, daß auf absehbare Zeit Zuhause ein IP4 reichen sollte. Für die meisten hier dürfte eine günstige Variante die höchste Priorität haben.

 

Wenn ich mir das Forum hier so anschaue, sehe ich 2 Lager: Die Hobbybastler, die ein günstiges, modulares System wollen und auch bekommen. Und da sind noch die Vollprofis, die hier viele Funktionen wünschen. So z.B. GPS, GSM, PoE ...

 

Die Frage die sich mir bei solche "Luxusteilen" stellt: Wie viele Abnehmer wird es dafür geben?. Irgendwie muß sich das Ganze ja finanzieren. Ich befürchte, daß irgendwann eine Querfinanzierung stattfindet. Damit dann ein GSM-Modul günstig genug angeboten werden kann, werden dann Massenteile wie Temperaturbricklet 1-2 Euro teurer werden.

 

Wollen wir das? Muß immer jedes neue Feature eingebaut sein?

[Loetkolben]

Die Frage die sich mir bei solche "Luxusteilen" stellt: Wie viele Abnehmer wird es dafür geben?.

 

Mein Reden. Vielleicht sollte man nur "guenstige" Connectivity Bricks anbieten an den man sollche Devices anschliessen kann.

 

Der Loetkolben.

[borg]

Ist IPv6 nicht einfach nur eine Frage des IP-Stacks - sprich Software?

Für uns kommt nur ein Modul mit integriertem IP Stack in Frage. Der Zeitaufwand von RS485 und die Probleme mit Chibi haben gezeigt das wir die low-level Protokollebene besser nicht selber implementieren sollten.

 

Der momentane Prototyp basiert auf diesem Modul: http://www.rovingnetworks.com/products/RN_171

 

Falls jemand von euch dazu einen Alternativvorschlag hat bitte her damit. Noch ließe sich das ändern. Irgendwann ist aber natürlich der Punkt gekommen wo wir soviel Zeit in die Implementierung gesteckt haben das wir nicht mehr wechseln können.

[AuronX]

Kurze Codeseite Frage zum WLan: Wenn ich eine mobiles Gerät am WLan habe und einen anderen Masterbrick am PC direkt... geht dies dann über eine IP Connection? Oder brauche ich dann 2?

 

Beispiel:

- "Bodenstation": (Master + 2 Joysticks und ein Poti zB)

- "Roboter": (WLan, Stepper, Servo, IR usw...)

Müsste ich Code anpssen um von der Bodenstation dann den Stepper zu bedienen?

 

Mhhh, so wie es im Moment gedacht ist müsstest du bei der Initialisierung zwei IPConnections aufmachen, könntest aber danach alles so nutzen wie jetzt auch.

 

@Borg: Der brickd ist in Python geschrieben oder? Ich würde mal schauen wie gut es möglich ist den von mir gemachten Vorschlag umzusetzen (brickd kann "IP-Devices" anbinden), vielleicht kannst du da auch ne Einschätzung zum Aufwand abgeben.

[Nitram]

@ArcaneDraconum grundsätzlich stimme ich dir zu, dass die Implementierung jedes noch so kleinen Features kosten produziert die am Ende ggf. quer Finanziert werden. Dennoch sollte man auch bedenken, das gerade der gewerbliche Einsatz, der mit dem modularen Konzept durchaus machbar ist, auch den Vorteil großer Abnahmemengen bringen kann.

 

Wenn jedoch im Vorfeld direkt gesagt wird, dass das Ziel nur Private Abnehmer in kleinen Stückzahlen ohne große Anforderungen ist, dann frage ich mich für was es "Reseller" Preislisten gibt. (http://www.tinkerforge.com/reseller_conditions)

 

Wir nutzen das hier für Entwicklungen im gewerblichen Umfeld, weil wir mit der Tinkerforge Lösung erheblich schneller und kostengünstiger Entwickeln können, als mit herkömmlichen Bauteilen. Aufgrund der meist individuellen Entwicklungen, lohnt der Aufwand eigener Boards und Co für uns nicht. Für uns sind ein paar Zukunftsaussichten wichtig, da sonst TF als Basis dafür schlichtweg nicht geeignet wäre. Ich denke das dies anderen potenziellen gewerblichen Abnehmern ähnlich geht.

 

@IPv6 - Wenn das Modul das nicht kann ist das halt schade aber genau deshalb hatte ich es angesprochen. Insofern es (und da kenn ich leider gar keine) ein Modul mit IPv6 gäbe, wäre dies schon schöner.

[borg]

@Nitram: Diese WLAN Module mit integriertem IP Stack sind ja eigentlich gerade für industrielle zwecke gedacht:

Applications:

Remote equipment monitoring

Asset tracking and telemetry

Industrial sensors and controls

Home automation

Medical devices

 

und gerade in diesem Umfeld (Maschinen über Ethernet steuern etc) ist IPv6 leider so gut wie gar nicht verbreitet. Deswegen gibt es da auch noch keine Unterstützung.

 

Dazu sollte man auch noch anmerken dass der Hersteller des Moduls (Roving Networks) dem RN-171 jederzeit IPv6 per Softwareupdate beibringen kann. Der IP Stack auf dem Modul ist ja ganz normal in Software auf einem ARM7 implementiert und Updates dafür gibt es alle paar Wochen. Bevor IPv4 anfängt nicht mehr nutzbar zu sein weil alle umgestiegen sind gibt es da sicherlich ein Firmware Update .