Nachdem ich bereits 21 nodes&nrfl2401+ mit einem WLAN GW erfolgreich in Betrieb habe, dort aber bei der Reichweite an die Grenzen der 2,4GHz Funker gekommen bin, habe ich mich dazu entschlossen ein serielles Gateway (Nano Clone)&RFM69HCW(433) einzurichten.
Problem: Das GW legt keine Devices an.
Übersicht Daten:
Gateway:
Arduino Nano (Clone)
Pegelwandler für NSS, MOSI und SCK
rfm69HCW
Verkabelung nach Vorgabe https://www.mysensors.org/build/connect_radio (https://www.mysensors.org/build/connect_radio) > RFM69/95 & Arduino
Aufbau aktuell auf Breadboard (rfm69 verlötet, Nano gesteckt)
Node:
Arduino Pro Mini 3,3V/8MHz
rfm69HCW
DHT22
Verkabelung nach Vorgabe https://www.mysensors.org/build/humidity (https://www.mysensors.org/build/humidity)
Batterie Pin noch nicht angeschlossen
Aufbau aktuell auf Breadboard (rfm69 verlötet, Pro Mini gesteckt, DHT22 gesteckt)
MySensorsVersion: 2.3.1 (GW & Node)
FHEM Hardware: RPI 3b
FHEM Version: fhem.pl:19085/2019-04-01
00_MYSENSORS.pm: 19108 2019-04-04 04:08:41
0_MYSENSORS_DEVICE.pm 19370 2019-05-11 14:49:14
GW in FHEM:
defmod MySensorGatewaySerial1 MYSENSORS /dev/ttyAMA0@115200
attr MySensorGatewaySerial1 autocreate 1
attr MySensorGatewaySerial1 first-sensorid 201
attr MySensorGatewaySerial1 stateFormat connection
attr MySensorGatewaySerial1 verbose 5
setstate MySensorGatewaySerial1 connected
setstate MySensorGatewaySerial1 2019-05-28 21:57:35 connection connected
setstate MySensorGatewaySerial1 2019-05-28 21:57:35 state opened
LogFile bei einem manuellen disconnect>connect:
2019.05.28 22:35:35 3: Opening MySensorGatewaySerial1 device /dev/ttyAMA0
2019.05.28 22:35:35 3: Setting MySensorGatewaySerial1 serial parameters to 115200,8,N,1
2019.05.28 22:35:35 5: MYSENSORS send: Rx: fr=000 ci=000 c=003(C_INTERNAL ) st=002(I_VERSION ) ack=0 ''
2019.05.28 22:35:35 5: SW: 303b303b333b303b323b0a
2019.05.28 22:35:35 3: MySensorGatewaySerial1 device opened
Serial Monitor am Node:
(Die Kommunikation zwischen Node und GW scheint ok zu sein.)
16 MCO:BGN:INIT NODE,CP=RRNNA---,REL=255,VER=2.3.1
28 TSM:INIT
28 TSF:WUR:MS=0
32 TSM:INIT:TSP OK
34 TSF:SID:OK,ID=201
36 TSM:FPAR
1255 TSF:MSG:SEND,201-201-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
1665 TSF:MSG:READ,0-0-201,s=255,c=3,t=8,pt=1,l=1,sg=0:0
1671 TSF:MSG:FPAR OK,ID=0,D=1
3264 TSM:FPAR:OK
3264 TSM:ID
3266 TSM:ID:OK
3268 TSM:UPL
3276 TSF:MSG:SEND,201-201-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
3293 TSF:MSG:READ,0-0-201,s=255,c=3,t=25,pt=1,l=1,sg=0:1
3301 TSF:MSG:PONG RECV,HP=1
3303 TSM:UPL:OK
3305 TSM:READY:ID=201,PAR=0,DIS=1
3315 TSF:MSG:SEND,201-201-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
3532 TSF:MSG:READ,0-0-201,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
3749 TSF:MSG:SEND,201-201-0-0,s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=OK:2.3.1
3766 TSF:MSG:SEND,201-201-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
5781 TSF:MSG:SEND,201-201-0-0,s=255,c=3,t=11,pt=0,l=15,sg=0,ft=0,st=OK:TempHumBatt_433
5797 TSF:MSG:SEND,201-201-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.0
5814 TSF:MSG:SEND,201-201-0-0,s=0,c=0,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
5828 TSF:MSG:SEND,201-201-0-0,s=1,c=0,t=6,pt=0,l=0,sg=0,ft=0,st=OK:
5834 MCO:REG:REQ
5844 TSF:MSG:SEND,201-201-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
6060 TSF:MSG:READ,0-0-201,s=255,c=3,t=27,pt=1,l=1,sg=0:1
6066 MCO:PIM:NODE REG=1
6068 MCO:BGN:STP
8077 MCO:BGN:INIT OK,TSP=1
8091 TSF:MSG:SEND,201-201-0-0,s=0,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=OK:49.7
Hum: 49.70
8108 TSF:MSG:SEND,201-201-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:25.9
Temp: 25.90
Batt Value: 1023.00
Batt Voltage: 5.18 V
Batt percent: 102.30 %
8128 TSF:MSG:SEND,201-201-0-0,s=255,c=3,t=0,pt=1,l=1,sg=0,ft=0,st=OK:102
8136 MCO:SLP:MS=10000,SMS=0,I1=255,M1=255,I2=255,M2=255
Die NodeID (201) habe ich Sketch manuell angegeben (nachdem der Autocreate nicht funktioniert hat):
#define MY_DEBUG
#define MY_RADIO_RFM69
#define MY_RFM69_FREQUENCY RFM69_433MHZ
#define MY_IS_RFM69HW
#define MY_NODE_ID 201
#include <SPI.h>
#include <MySensors.h>
#include <DHT.h>
#include <avr/sleep.h>
#define DHT_DATA_PIN 3
#define SENSOR_TEMP_OFFSET 0
#define CHILD_ID_HUM 0
#define CHILD_ID_TEMP 1
static const uint64_t UPDATE_INTERVAL = 10000; // in MilliSekunden
bool metric = true;
MyMessage msgHum(CHILD_ID_HUM, V_HUM);
MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP);
DHT dht;
float BATTERY_SENSE_PIN = A0;
void presentation()
{
sendSketchInfo("TempHumBatt_433", "1.0");
present(CHILD_ID_HUM, S_HUM);
present(CHILD_ID_TEMP, S_TEMP);
metric = getControllerConfig().isMetric;
}
void setup()
{
dht.setup(DHT_DATA_PIN);
delay(2000);
analogReference(INTERNAL);
}
void loop()
{
dht.readSensor(true);
float humidity = dht.getHumidity();
if (isnan(humidity)) {
Serial.println("Failed reading humidity from DHT");
} else {
send(msgHum.set(humidity, 1));
#ifdef MY_DEBUG
Serial.print("Hum: ");
Serial.println(humidity);
#endif
}
float temperature = dht.getTemperature();
if (isnan(temperature)) {
Serial.println("Failed reading temperature from DHT!");
} else {
temperature += SENSOR_TEMP_OFFSET;
send(msgTemp.set(temperature, 1));
#ifdef MY_DEBUG
Serial.print("Temp: ");
Serial.println(temperature);
#endif
}
float sensorValue = analogRead(BATTERY_SENSE_PIN);
float batteryPcnt = sensorValue / 10;
float batteryV = sensorValue * (5.175 / 1023);
#ifdef MY_DEBUG
Serial.print("Batt Value: ");
Serial.println(sensorValue);
Serial.print("Batt Voltage: ");
Serial.print(batteryV);
Serial.println(" V");
Serial.print("Batt percent: ");
Serial.print(batteryPcnt);
Serial.println(" %");
#endif
sendBatteryLevel(batteryPcnt);
sleep(UPDATE_INTERVAL);
}
Inclusion Mode schalte ich vor dem Boot des Nodes selbstverständlich auf on.
Da mache ich aber schon komische Beobachtungen:
Wenn ich den Inclusion mode auf on/1 stelle, dann wird dieser nach den standardmäßigen 60 Sekunden nicht wieder auf off/0 gesetzt.
Irgendwie werde ich das Gefühl nicht los, dass das GW nicht wirklich sauber in FHEM integriert ist.
Wie kann ich denn prüfen, dass das GW ordentlich mit FHEM plappert?
Ach ja, hier noch der GW Sketch:
#define MY_DEBUG
#define MY_RADIO_RFM69
#define MY_RFM69_FREQUENCY RFM69_433MHZ
#define MY_IS_RFM69HW
#define MY_GATEWAY_SERIAL
#define MY_INCLUSION_MODE_FEATURE
#define MY_INCLUSION_MODE_DURATION 60
#define MY_DEFAULT_LED_BLINK_PERIOD 300
#include <MySensors.h>
void setup()
{
// Setup locally attached sensors
}
void presentation()
{
// Present locally attached sensors
}
void loop()
{
// Send locally attached sensor data here
}
Ich bin mit meinem Latein (und der Google/Forumssuche) leider am Ende und hoffe hier auf Unterstützung.
Weitere Daten/Logs oder sonstige Angaben kann ich gerne nachreichen.
Vielen Dank schon mal.
Gruß
Andi
UPDATE zur Lösung:
Es handelt sich um einen Nano mit FTDI Chip, der zusammen nicht so mit dem RPI kann.
Der Hinweis in der WIKI (https://wiki.fhem.de/wiki/Arduino#FTDI-Resets), die beiden Pins 25 & 26 zu verbinden hat letztendlich das Problem gelöst.
Allerdings musste ich nach dem Löten und dem Wiederanstecken des Nano den RPI, den RPI rebooten. Vorher ging es nicht.
Man wird halt von USB verleitet, dass es auch ohne geht, aber dahinter steckt halt eine serielle Schnittstelle. Und vlt. braucht die den Reboot :-)
Die Details zum Verlauf der Problemlösung könnt Ihr im Folgenden nachlesen.
VIELEN DANK an dieser Stelle nochmal an Beta-User!
Versuch mal ttyS0 oder serial0
Der ttyAMA0 geht beim Pi3 bzw Zero w auf Bluetooth.
Hatte heute das gleiche Vergnügen mit nem CUL
Gesendet von meinem Doogee S60 mit Tapatalk
Da habe ich auch schon verschiedene Varianten durchprobiert.
Mit Deinen Vorschlägen:
ttyS0 > state: disconnected
serial0 > state: disconnected
Die beiden Devices sind aber auch nicht vorhanden :-(
Nur bei ttyAMA0 bekomme ich ein state:opened
Aber danke für Deine Hilfe.
Hmm, aber ttyAMA0 paßt eigentlich nicht zu einem Nano-Klon; das ist irgendwie schräg, dass da überhaupt eine Antwort zu kommen scheint, aber das dürfte daran liegen, dass eine serielle Kommunikation zustande kommt, wenn auch - wie frank_huber zurecht schreibt - mit dem Blauzahn-IO.
Ich gehe mal davon aus, dass du auch keine 2. "MYSENSORS_0" angelegt bekommst, oder?
Liefere bitte mal den output der Linux-Konsole zu ls -l /dev/serial/by-id (bzw. noch ...by-path)
Zitat von: Beta-User am 29 Mai 2019, 07:38:09
Liefere bitte mal den output der Linux-Konsole zu ls -l /dev/serial/by-id (bzw. noch ...by-path)
ls: Zugriff auf '/dev/serial/by-id' nicht möglich: Datei oder Verzeichnis nicht gefunden
Zitat von: Beta-User am 29 Mai 2019, 07:38:09
Ich gehe mal davon aus, dass du auch keine 2. "MYSENSORS_0" angelegt bekommst, oder?
Jetzt stehe ich auf dem Schlauch :o
Wie kann ich das prüfen?
Zitat von: Beta-User am 29 Mai 2019, 07:38:09
Hmm, aber ttyAMA0 paßt eigentlich nicht zu einem Nano-Klon
Das Device wurde aber beim ersten Anstecken des Klons angelegt, bzw. hatte das passende Änderungsdatum.
Ein /dev/serial1 gibt es auch noch, aber mit anderen Rechten und ist nur ein symbolischer Link auf /dev/ttyAMA0.
Die Rechte von /dev/ttyAMA0 sind 0660 user:root, gruppe:dialout
Kurz da mobil : sudo vorneweg
Bin mit su rein, daher kein sudo.
Es gibt kein Verzeichnis /dev/serial :(
root@raspberrypi:~# ls /dev
autofs cuse gpiomem loop1 mem ppp ram14 ram9 snd tty12 tty20 tty29 tty37 tty45 tty53 tty61 uinput vcs4 vcsa6
block disk hidraw0 loop2 memory_bandwidth ptmx ram15 random stderr tty13 tty21 tty3 tty38 tty46 tty54 tty62 urandom vcs5 vcsm
bsg fb0 hidraw1 loop3 mmcblk0 pts ram2 raw stdin tty14 tty22 tty30 tty39 tty47 tty55 tty63 vchiq vcs6 vhci
btrfs-control fd hwrng loop4 mmcblk0p1 ram0 ram3 rfkill stdout tty15 tty23 tty31 tty4 tty48 tty56 tty7 vcio vcsa watchdog
bus full initctl loop5 mqueue ram1 ram4 sda tty tty16 tty24 tty32 tty40 tty49 tty57 tty8 vc-mem vcsa1 watchdog0
cachefiles fuse input loop6 net ram10 ram5 sda1 tty0 tty17 tty25 tty33 tty41 tty5 tty58 tty9 vcs vcsa2 zero
char gpiochip0 kmsg loop7 network_latency ram11 ram6 serial1 tty1 tty18 tty26 tty34 tty42 tty50 tty59 ttyAMA0 vcs1 vcsa3
console gpiochip1 log loop-control network_throughput ram12 ram7 sg0 tty10 tty19 tty27 tty35 tty43 tty51 tty6 ttyprintk vcs2 vcsa4
cpu_dma_latency gpiochip2 loop0 mapper null ram13 ram8 shm tty11 tty2 tty28 tty36 tty44 tty52 tty60 uhid vcs3 vcsa5
Puh, bin etwas ratlos. Das ist doch ein "normales" Raspbian stretch, oder?
udev ist installiert? (müßte eigentlich, irgendwas legt schließlich ttyAMA0 an ??? ; Netzteil ist auch stark genug?)
Evtl. liefert
dmesg | grep -i usb
irgendwas aufschlußreiches? (Ggf. mal ab- und wieder anstöpseln und dann wiederholen und die Unterschiede beobachten).
:-[ :-[ :-[ :-[ :-[
Ich bin es von Linux nicht gewöhnt, dass sich doch mal was verhakt und ein Reboot gut tut...
Nach einem Reboot habe ich nun...
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A90CV4IQ-if00-port0@115200
Nun habe ich weihnachtsnbaumtechnisches Blinken zwischen:
2019-05-29 14:39:07 MYSENSORS MySensorGatewaySerial1 connection: connected
2019-05-29 14:39:07 MYSENSORS MySensorGatewaySerial1 CONNECTED
2019-05-29 14:39:08 MYSENSORS MySensorGatewaySerial1 connection: startup complete
2019-05-29 14:39:10 MYSENSORS MySensorGatewaySerial1 DISCONNECTED
2019-05-29 14:39:10 MYSENSORS MySensorGatewaySerial1 connection: connected
2019-05-29 14:39:10 MYSENSORS MySensorGatewaySerial1 CONNECTED
2019-05-29 14:39:11 MYSENSORS MySensorGatewaySerial1 connection: startup complete
2019-05-29 14:39:12 MYSENSORS MySensorGatewaySerial1 DISCONNECTED
2019-05-29 14:39:12 MYSENSORS MySensorGatewaySerial1 connection: connected
2019-05-29 14:39:12 MYSENSORS MySensorGatewaySerial1 CONNECTED
2019-05-29 14:39:14 MYSENSORS MySensorGatewaySerial1 connection: startup complete
2019-05-29 14:39:15 MYSENSORS MySensorGatewaySerial1 DISCONNECTED
dazu habe ich, glaube ich, hier im Forum schon mal was gelesen....
Ich denke hier:
https://forum.fhem.de/index.php/topic,60917.0.html
Klingt nach dem Test-PIN Problem. Bitte mal abziehen, kurz warten, wieder einstecken.
(Dann ist es wenigstens kein gefakter FTDI...)
Meints Du die Verbindung DI00 > D2 oder den ganzen Arduino abstecken?
Arduino stromlos machen war gemeint (der FTDI geht bei diesem Fehler in Dauerreboot). Bitte im Wiki bei Arduino suchen, da ist auch Abhilfe beschrieben, wenn es das ist.
Ok, danke.
Du beziehst Dich auf das hier aus der Wiki:
2. Manche neueren Boarddefinitionen aus der IDE führen u.U. zu häufigeren Reboots. Seit 1.6.18 scheint das Problem behoben zu sein, ansonsten ist ein Downgrade der Boarddefinitionen für AVR-Boards bis <=1.6.11 zu empfehlen.
Selbiges habe ich eben in dem bereits zitierten Beitrag gefunden:
Zitat von: Beta-User am 18 November 2016, 09:34:08
@All:
Mit dem "Fix" ist der Downgrade der Board-Definitionen gemeint, aus dem Kopf ist das in der Arduino-IDE unter Tools: Board-Manager zu finden. Dort das Board auswählen (Nano?) und dann kann man links in einem drop-down-Feld eine Version auswählen; lt. MySensors-Board sollte höchstens die Version 1.6.11 verwendet werden (in IDE 1.6.12 wird *.14 mit ausgeliefert).
Die Einstellung in der IDE habe ich schon gefunden.
Werde diese nun auf 1.6.11 runterstellen, obwohl eigentlich mit 1.6.23 (welche ich eingestellt habe) keine Probleme bestehen sollten.
Melde mich dann gleich nochmal...
Nein. FTDI Testpin-Bug bei Arduino: https://wiki.fhem.de/wiki/Arduino#FTDI-Resets
ok...dann probiere ich das aus.
Die 1.6.11 hat nämlich nichts gebracht :-(
Hmm, da du das Ding aber dazwischen auch abgestöpselt haben dürftest (?!?), bleibt die bereits vorhin schon mal gestellte Frage nach der Spannungsversorgung.
Liefert das GW denn an einem anderen Rechner an der Konsole einen Output ("Gateway started...") und läuft stabil?
Das GW hängt an einem aktiven USB Hub, da ich den RPI mit einer USB SSD betreibe und von daher sowieso mit der vorhandenen Spannung nicht auskomme.
Die Test-Pin Geschichte...
Den FTDI CHip auf der Unterseite des Nanos, Pin 25 und 26 "kurz schließen"?
Dann würde ich auf Zicken des Hub tippen (das andere GW ist ja auch nicht mehr zu sehen, lsusb würde da ggf. mehr Infos liefern...). Ggf. den mal tauschen.
Ansonsten waren es 2 PINS, die kurzzuschleißen sind, ja. Steht doch da an der verlinkten Stelle im Wiki, oder? (kannst ja vorher mal messen)
Das andere GW ist ein WLAN Gateway.
Hub ist erst zwei Wochen alt.
Ich habe nun mal den rfm69 Chip mit einer autarken Stromversorgung angeschlossen.
Selbiges Bild.
Allerdings, wenn der rfm nicht dran ist, läuft das GW stabil.
Ich tausche jetzt mal das rfm.
Ok, das erklärt das mit dem 2. GW.
Was den Hub angeht: Alter ist kein Qualitätsmerkmal (lsusb...), aber wenn der RFM zu zicken scheint, kommen wir der Sache näher.
Jedenfalls solltest du ohne den RFM jetzt wissen/testen können, was ich mit "MYSENSOR_0" gemeint hatte ;) .
so...
ftdi pins zusammengelötet > keine Änderung
Nano mit extra 9V Stromversorung am VIN > ohne USB Verbindung zum RPI > stabil
Sobald ich das USB Kabel über den Hub am RPI anschließe, fängt der Nano wieder an zu booten.
Da ich jetzt aber auch direkt anschließen kann (Strom sollte der Nano jetzt ja ausreichend über die ext. Versorgung haben), werde ich das jetzt noch machen...
jetzt bin ich dann mit den Probiermöglichkeiten am Ende...
Auch direkt am USB Port des RPI ständig der Statuswechsel...
:'( :'( :'( :'( :'(
Zitat von: Beta-User am 29 Mai 2019, 15:46:17
Jedenfalls solltest du ohne den RFM jetzt wissen/testen können, was ich mit "MYSENSOR_0" gemeint hatte ;) .
Oops, ja, ist nun ein MYSENSORS_DEVICE.
Das wäre nun, wenn direkt am RPI ein "Sensor" Device angeschlossen ist, richtig?
Irgendwie alles sehr dubios.
Nach ein paar Minuten beruhigt sich der Nano, bootet nicht mehr.
Wenn ich dann den Inclusion Mode aktivieren möchte fängt er wieder an zu booten....
Scheint aber insgesamt doch ein FTDI<>RPI Problem zu sein :-(
Habe diese Issues hier gefunden:
https://github.com/raspberrypi/firmware/issues/88 (https://github.com/raspberrypi/firmware/issues/88)
https://github.com/raspberrypi/linux/issues/2406 (https://github.com/raspberrypi/linux/issues/2406)
dwc_otg.speed=1
...finde ich jetzt nicht prickelnd, da dann USB wohl nur noch auf 1.1 Geschwindigkeit ist.
Mit einer SSD dran ist das sehr ungemütlich.
Grummel... Schon wieder so ein Pi-Mist >:( .
(Ich fühle mich mal wieder bestätigt, dass das einfach keine gute Plattform für HA-Zwecke ist und nehme diesen Punkt mit auf meine "schwarze Pi-Liste"; das war bei mir bisher nicht im Fokus).
so....es geht weiter....
Ich bin bei meiner weiteren Recherche über einen weiteren Artikel gestolpert, der das FTDI Test Pin Problem und dessen Lösung (Pin25+26) kurz schließen beschreibt.
https://ai.rs/reviews/rgb-delight-raspberry-pi2-arduino-nano-ws2812b-using-hyperion-on-openelec/arduino-with-raspberry-pi-boot-detection-problem-solved/ (https://ai.rs/reviews/rgb-delight-raspberry-pi2-arduino-nano-ws2812b-using-hyperion-on-openelec/arduino-with-raspberry-pi-boot-detection-problem-solved/)
Hier ist der kleine entscheidende Hinweis:
Nach dem zusammen löten der beiden Pins, den RPI rebooten.
Das habe ich nicht gemacht (oh Gott schon wieder.... :P :P :P).
Was soll ich sagen:
ES LÄUFT!!! ;D ;D ;D
Ich hatte ja schon einen Node fertig, der gleich erkannt und angelegt wurde.
Soll ich den Fred als gelöst markieren?
Hmmm, ich mag zwar nicht recht glauben, dass der Pi-Reboot nötig war, aber wenn es geholfen hat ::) ...
Einbindung des GW ist jetzt auch "by-id", hoffe ich?
Und ja, wenn gelöst, dann [gelöst] ...
(Die Nodes werden angelegt, das war ja das Thema...?)
Na ja, seit dem Löten hatte ich den RPI nicht gebootet.
Aufgrund des andere Artikels habe ich es gemacht und es geht.
Über den Hub angeschlossen ohne ext. Stromversorgung.
Einbindung per "by-id".
Und ja, Nodes werden nun angelegt.
VIELEN VIELEN DANK!!!!
Gruß
Andi
Hast du auch dwc_otg.speed=1 wieder zurück gestellt?
Gesendet von meinem Doogee S60 mit Tapatalk
Zitat von: Frank_Huber am 29 Mai 2019, 19:57:18
Hast du auch dwc_otg.speed=1 wieder zurück gestellt?
Habe ich gar nicht gemacht, da das bzgl. Geschwindigkeit (>USB1.1) nicht in Frage kommt. Eine SSD an USB 2.0 ist ja schon nicht optimal, aber läuft gut, USB1.1 sicher nicht mehr wirklich gut.