Kabel Deutschland bietet eine kostenlose Nummer für die Technik an. In Wirklichkeit fragen die aber nur die Uptime und die Werte des Modems ab und lassen dann die echten Techniker von 08:00 bis 22:00 anrufen bzw leiten in dieser Zeit weiter.
Nunja um 22:20 habe ich dort nach kurzer Wartezeit tatsächlich jemanden erreicht. Daten aufgenommen. Passt :-) Allerdings sollen die Techniker jetzt um 8:00 morgens anrufen , eine Zeit zu der ich an dem Tag nicht zu erreichen bin. Also rief ich wieder an. 50 Minuten Warteschleife, dann habe ich mit dem Handy übernommen. Inzwischen bin ich seit zusätzlich 3,5 Stunden der nächste Kunde...
Ich vermute das läuft noch bis 8 Uhr morgens weiter und dann ist für den Techniker bei mir besetzt :D
Man kann denke ich annehmen, dass niemand mehr als 3 Stunden wartet. Ich würde hier von einer FIFO Queue ausgehen und eventuell zusätzlich, dass Kunden vom Handy bevorzugt behandelt werden, da hier die Terminierungsentgelte wesentlich höher sind als aus dem eigenen Festnetz.
Da ich keine Lust habe mit der nervigen Ansage einzuschlafen lege ich jetzt auf :)
Jul 18, 2013
[review] mobiles Klimagerät Nanyo 35AA
Das mobile Klimagerät Nanyo 35AA gibt es zur Zeit im Hornbach Baumarkt zu kaufen.
Ich habe das Gerät ca. eine Woche getestet und es kühlt ;-)
Folgende Kritikpunkte sind mir bis jetzt aufgefallen:
Die Fernbedienung ist unidirektional. Tasten die auf der Fernbedienung gedrückt werden gehen immer von dem auf der Fernbedienung angezeigten Zustand aus und überschreiben den am Gerät eingestellten Mdous.
Generell hat man bei Klimageräten mit nur einem Schlauch das Problem, dass die erzeugte Abluft auch irgendwo her kommen muss. Hat man irgendwo ein Fenster auf, wird daher dort wieder warme Luft angesaugt.
In einer ca. 80m³ großen Dachgeschosswohnung schafft das Gerät im Dauerbetrieb tagsüber die Temperatur von ~30°C auf 23-24°C herunter zu kühlen (mit Zusatzwasser).
Wenn man bereit ist ein paar der erwähnten Nachteile zu akzeptieren, hat es wohl ein gutes Preis/Leistungsverhältnis.
Update: Nach 2 Wochen hat Hornbach den Link hier her aus den Kundenbewertungen entfernt und es sind dort 3 neue (positive?!) Bewertungen bzgl. der Lautstärke aufgetaucht... Sowas ;-)
Ich habe das Gerät ca. eine Woche getestet und es kühlt ;-)
Folgende Kritikpunkte sind mir bis jetzt aufgefallen:
- keine Batterien für die Fernbedienung dabei
- die Abdeckung für den oberen Filter rastet bei mir nicht ein
- Der Aktivkohlefilter schaut für mich aufgrund des grobmaschigen Aufbaus nicht aus, als würde er irgendwas filtern
- An der seitlichen Luftansaugung befindet sich kein Aktivkohlefilter
- Die seitliche Abdeckung klappert bei mir - ließ sich allerdings mit einem kleinen Keil beseitigen
- Die Bedienungsanleitung könnte etwas übersichtlicher sein. Zum Beispiel könnten die Gliederung deutlicher sein und die Modi einzeln aufgeschlüßelt erklärt werden
- Sehr wenige Details auf der Verpackung. Das Gerät gibt es auch noch mit Heizung und Ionisator
- Der Automatikmodus schaltet den Kompressor immer 1-2°C über der gewünschten Zieltemperatur ab. Dadurch bleibt er nicht sonderlich lange ausgeschaltet
- Der Luftstrom wird nicht automatisch geschwenkt. Man kann ihn nur manuell einstellen
- Die seitliche Ablenkung des Luftstroms hat kaum Funktion
- Das Design der Fernbedienung ist aus dem letzten Jahrhundert und in einem dreckigen grau gehalten
- Der Abluftschlauch ist nicht isoliert und gibt Wärme wieder an den Raum ab
- Die Lautstärkenangabe mit max. 65 dB (A) habe ich verifiziert. Ist aber trotzdem laut. Lauter als Zimmerlautstärke, lauter als eine normale Unterhaltung.
Die Fernbedienung ist unidirektional. Tasten die auf der Fernbedienung gedrückt werden gehen immer von dem auf der Fernbedienung angezeigten Zustand aus und überschreiben den am Gerät eingestellten Mdous.
Generell hat man bei Klimageräten mit nur einem Schlauch das Problem, dass die erzeugte Abluft auch irgendwo her kommen muss. Hat man irgendwo ein Fenster auf, wird daher dort wieder warme Luft angesaugt.
In einer ca. 80m³ großen Dachgeschosswohnung schafft das Gerät im Dauerbetrieb tagsüber die Temperatur von ~30°C auf 23-24°C herunter zu kühlen (mit Zusatzwasser).
Wenn man bereit ist ein paar der erwähnten Nachteile zu akzeptieren, hat es wohl ein gutes Preis/Leistungsverhältnis.
Update: Nach 2 Wochen hat Hornbach den Link hier her aus den Kundenbewertungen entfernt und es sind dort 3 neue (positive?!) Bewertungen bzgl. der Lautstärke aufgetaucht... Sowas ;-)
Jul 8, 2013
[rev] Fiat Punto CNG ECU / Metatron disassembly
Some of the Fiat Puntos (~6-7 years ago) were shipped with CNG. This CNG system (4100120/PN 55204807) was manufactured by Metatron. Currently a friend with such a system had the problem that the CNG was not useable anymore - no CNG injection, no LEDs lit on the (ugly) user interface. The garage analysed and suggested to replace the CNG ECU. Prices vary from 700-1100 Euro for new ones.
So it's the time to disassemble and take a look inside ;-)
On the Metatron site (outdated version of Typo3 :) ) I just could find three quite useless PDFs about the three different systems they produced.
Let's start with the deattachment from the car. The ECU is attached with non-stainless screws, which are twice as long as needed, close to the battery in a provisional looking arrangement (like the complete system).
The controller itself seems to be closed by 5 screws and a membran on the other side. Unscrewing these screws is just 10% of the work to open it. Those screws seems to be there just to put pressure during production. The complete cover is glued with a kind of silicone. I suggest to break away the cover on both sides of the lower egdes (opposite side of the connector) and saw a cut underneath the connector. With some force it is then possible to open it. Probably this guarantess the waterproof level (and prevents repair).
On the right side are several voltage regulators (2x 5V, 1.2V, 3.3V, 12V). Below the big 5V regulator is a K-Line controller. At the bottom is a Freescale MCU with an external eeprom (probably for the car individual settings). In the middle seems to be a mixed-signal ASIC produced by AMS (Now I understand the insane price) and a CAN controller. On the left side are some FETs and close to it is a quad power driver IC L9338D from ST. Might be that this one is used to drive the injectors.
First step was to figure out the power pins. Looking inside some datasheets and connecting it to the car I could easily find out GND. Actually two GNDs are connected (Pins 27/28). One to the frame/cover and the golden frame around the PCB. Close to the golden frame you find two plus symbols. I think those are for the alignment during production and not related to the voltage level. The real 12V goes to pin 1. Reversing and checking a bit the regulators - there's a 5V regulator output connected to pin 2 for the outside world. In my case this does not provide 5V... ;-)
For debugging I bridged the FET (?) at the top right below the transient filter. Else no input voltage was provided to the defective 5V regulator. Probably there is another input that triggers this with the car keys.
So it's the time to disassemble and take a look inside ;-)
On the Metatron site (outdated version of Typo3 :) ) I just could find three quite useless PDFs about the three different systems they produced.
Let's start with the deattachment from the car. The ECU is attached with non-stainless screws, which are twice as long as needed, close to the battery in a provisional looking arrangement (like the complete system).
The controller itself seems to be closed by 5 screws and a membran on the other side. Unscrewing these screws is just 10% of the work to open it. Those screws seems to be there just to put pressure during production. The complete cover is glued with a kind of silicone. I suggest to break away the cover on both sides of the lower egdes (opposite side of the connector) and saw a cut underneath the connector. With some force it is then possible to open it. Probably this guarantess the waterproof level (and prevents repair).
On the right side are several voltage regulators (2x 5V, 1.2V, 3.3V, 12V). Below the big 5V regulator is a K-Line controller. At the bottom is a Freescale MCU with an external eeprom (probably for the car individual settings). In the middle seems to be a mixed-signal ASIC produced by AMS (Now I understand the insane price) and a CAN controller. On the left side are some FETs and close to it is a quad power driver IC L9338D from ST. Might be that this one is used to drive the injectors.
First step was to figure out the power pins. Looking inside some datasheets and connecting it to the car I could easily find out GND. Actually two GNDs are connected (Pins 27/28). One to the frame/cover and the golden frame around the PCB. Close to the golden frame you find two plus symbols. I think those are for the alignment during production and not related to the voltage level. The real 12V goes to pin 1. Reversing and checking a bit the regulators - there's a 5V regulator output connected to pin 2 for the outside world. In my case this does not provide 5V... ;-)
For debugging I bridged the FET (?) at the top right below the transient filter. Else no input voltage was provided to the defective 5V regulator. Probably there is another input that triggers this with the car keys.
Jun 11, 2013
Limited device count on Intel USB 3.0 eXtensible host controller/C216?
Just got notified by my system that I'm attaching more than the allowed devices to the Intel USB 3.0 eXtensible host controller/C216. First I tried to connect through some hubs - than directly to the notebook in case the USB hub chain is too long ;-) I was still unlucky. I do not want to remove other devices!
Upgrading the driver to the latest found on Intel page did not change anything.
Additonally it seems that all external ports on the Asus N56VZ are connected to this controller - even there is one totaly unused controller inside (what is the reason that this one is not forwarded to the outside world?).
Since I'm running a USB docking station with a lot of devices connected it might be that I just crossed the 127 device limit, which I could hardly believe. USBDeview just shows up 36 connected devices in total (none related controller included).
Since I could not find any information on the web about it, my last step was to contact Intel. Let's see what they will reply.
Ah... and the notification message can be found in the localization part of the driver :-)
Another thought is that the connected USB hubs reserve slots even they are currently not in use. USBView tells that there 15 connected devices (1 not working due to the limits) and 16 free slots. So this is also not the case. Maybe they limit the total number of endpoints?
Playing with two devices that have a different count of endpoints confirms that :( A device can have upto 32 endpoints. This number is close to the free+used slots which I found on USBView. Maybe it has todo something with that... (like the connected devices are counted as endpoints for the root hub)
Next update: What a mess!!! I uninstalled this Intel driver, so it showed up as unknown device in device manager. I easily could extend the USB ports to 34. I could use minimum 20 USB devices now. More I could not test, since not enough devices laying around. This means it is a software limitation by the Intel driver. And also very interesting (this is what I mean with mess): It was now using the USB ports which formerly I thought are not routed to the outside of the notebook. On device manager and USBView my devices werde definately shown on the other USB hub, even after reinstalling the Intel drivers. I think next startup they will be back to the problematic Intel USB hub.
Conclusion is, that this Intel driver provides a virtual USB hub - maybe like advised by the driver name (eXtensible) it just provides extra features to USB. Need to read documentation? :-)
Keyword: vendor limitation!
Next step: Change it to have more than 15/16 devices.
Solution for me: I manually installed the desktop drivers for C220 (hub+xhci, not the PCI drivers in HCSwitch folder) instead of the recommended C216 ones. Looks like I can use 2 more devices with that, which is currently enough for me.I also tried to patch the drivers, but w/o luck so far. iusb3mon.exe seems to be there only for user feedback (tray balloons). (It's possible to set a timeout and a debugging flag in registry, but this did not change anything for me)
Conclusion: Too much time wasted; Should be documented somewhere!
Next update... it's getting annoying. The root hub was replaced by old drivers automatically and new devices were not enumerated correctly. I installed the version again that comes from Asus. The latest driver from Intel seems to be not stable during installation ("Does not meet system requirements", Aborts installation in middle, brings bluescreen during install and startup). Even after removing all components manually, so should be now leftovers from my previous tries :(
An employee of Intel replied:
Asus replied me with a new driver (not latest like from Intel page). Same device limit :-/
Update 25.09.2013:
I had a few mail contacts with ASUS. They are quite friendly and dived a bit into the problem (asking their technicals and contacted Intel). Intel replied them with a screenshot of USB deview and told that not each device has only one endpoint and it's an endpoint limit. The ASUS translation was not completly correct, but luckily they included the original answer. I asked ASUS to tell me the limit of endpoints. No reply since 1 month :(
Also I counted the endpoints on my system and found out that more than 86 endpoints are connected to the Intel 3.0 Host. The exact number i was not able to figure out because on viewing my Displaylink (is another story that I could tell :)) device Deview just crashes. Additonally there are 10 endpoints connected to the internal hosts.
I also tried to disassemble the driver, but since I do not know the exact count it's quite difficult to find the comparation. Additionally the error strings are all in one function (quite a mess) - probably generated by the compiler.
So far I decided to disconnect devices and connect other devices. Ugly task :)
Upgrading the driver to the latest found on Intel page did not change anything.
Additonally it seems that all external ports on the Asus N56VZ are connected to this controller - even there is one totaly unused controller inside (what is the reason that this one is not forwarded to the outside world?).
Since I could not find any information on the web about it, my last step was to contact Intel. Let's see what they will reply.
Ah... and the notification message can be found in the localization part of the driver :-)
Another thought is that the connected USB hubs reserve slots even they are currently not in use. USBView tells that there 15 connected devices (1 not working due to the limits) and 16 free slots. So this is also not the case. Maybe they limit the total number of endpoints?
Playing with two devices that have a different count of endpoints confirms that :( A device can have upto 32 endpoints. This number is close to the free+used slots which I found on USBView. Maybe it has todo something with that... (like the connected devices are counted as endpoints for the root hub)
Next update: What a mess!!! I uninstalled this Intel driver, so it showed up as unknown device in device manager. I easily could extend the USB ports to 34. I could use minimum 20 USB devices now. More I could not test, since not enough devices laying around. This means it is a software limitation by the Intel driver. And also very interesting (this is what I mean with mess): It was now using the USB ports which formerly I thought are not routed to the outside of the notebook. On device manager and USBView my devices werde definately shown on the other USB hub, even after reinstalling the Intel drivers. I think next startup they will be back to the problematic Intel USB hub.
Conclusion is, that this Intel driver provides a virtual USB hub - maybe like advised by the driver name (eXtensible) it just provides extra features to USB. Need to read documentation? :-)
Keyword: vendor limitation!
Next step: Change it to have more than 15/16 devices.
Solution for me: I manually installed the desktop drivers for C220 (hub+xhci, not the PCI drivers in HCSwitch folder) instead of the recommended C216 ones. Looks like I can use 2 more devices with that, which is currently enough for me.I also tried to patch the drivers, but w/o luck so far. iusb3mon.exe seems to be there only for user feedback (tray balloons). (It's possible to set a timeout and a debugging flag in registry, but this did not change anything for me)
Conclusion: Too much time wasted; Should be documented somewhere!
Next update... it's getting annoying. The root hub was replaced by old drivers automatically and new devices were not enumerated correctly. I installed the version again that comes from Asus. The latest driver from Intel seems to be not stable during installation ("Does not meet system requirements", Aborts installation in middle, brings bluescreen during install and startup). Even after removing all components manually, so should be now leftovers from my previous tries :(
An employee of Intel replied:
Ivy Bridge xHCI hosts are limited to 64 endpoint rings, including control endpoint rings. I can see that limit easily being hit by 15-18 devices.Intel support sent me a link to the datasheet with more than 500 pages. Actually could not easily find anything mentioned about the limits inside.
Asus replied me with a new driver (not latest like from Intel page). Same device limit :-/
Update 25.09.2013:
I had a few mail contacts with ASUS. They are quite friendly and dived a bit into the problem (asking their technicals and contacted Intel). Intel replied them with a screenshot of USB deview and told that not each device has only one endpoint and it's an endpoint limit. The ASUS translation was not completly correct, but luckily they included the original answer. I asked ASUS to tell me the limit of endpoints. No reply since 1 month :(
Also I counted the endpoints on my system and found out that more than 86 endpoints are connected to the Intel 3.0 Host. The exact number i was not able to figure out because on viewing my Displaylink (is another story that I could tell :)) device Deview just crashes. Additonally there are 10 endpoints connected to the internal hosts.
I also tried to disassemble the driver, but since I do not know the exact count it's quite difficult to find the comparation. Additionally the error strings are all in one function (quite a mess) - probably generated by the compiler.
So far I decided to disconnect devices and connect other devices. Ugly task :)
Jun 5, 2013
[rev] a small ARM riddle
Today I just looked over some ARM binary and found this interesting piece:
So, let's start my new blog with a small riddle ;-)
I'll soon provide a sample calling this method and later a full explanation.
Update 1:
The function is called from thumb mode like this
Update 2:
Since I'm frustrated with DisplayLink and Intel... let's use the time to explain.
BX PC changes the mode from thumb to arm. Inside LR we have the next address that should be executed on a return. This is still in thumb mode (which is offset+1). So the LDRB will load 0x06 to R12. What is not visible, is that R3 is loaded with a value. In the next instruction this value is compared with the currently loaded byte. LDRCCB (UAL instruction) will load LR + R3 to R3 if R3 is lower than R12. Else it will use the R12 value. At the end it will jump to R3 << 1 offset from LR. So we have a jumptable (switch). The first byte after the call (BL) tells us the entries. The next one is the default branch. The left shift by two is done so it will always go to valid thumb mode instructions again.
If you have a valid IDA license you can follow the following instrcutions :-)
47 78 BX PC 46 C0 NOP E5 5E C0 01 LDRB R12, [LR, #-1] E1 53 00 0C CMP R3, R12 37 DE 30 03 LDRCCB R3, [LR, R3] 27 DE 30 0C LDRCSB R3, [LR, R12] E0 8E C0 83 ADD R12, LR, R3, LSL#1 E1 2F FF 1C BX R12
So, let's start my new blog with a small riddle ;-)
I'll soon provide a sample calling this method and later a full explanation.
Update 1:
The function is called from thumb mode like this
0xB8: FX XX FX XX BL func 0xBC: 06 04 16 1B+ DCB 6, 4, 0x16, 0x1B, 0x20, 0x57, 0x5C, 0x61
Update 2:
Since I'm frustrated with DisplayLink and Intel... let's use the time to explain.
BX PC changes the mode from thumb to arm. Inside LR we have the next address that should be executed on a return. This is still in thumb mode (which is offset+1). So the LDRB will load 0x06 to R12. What is not visible, is that R3 is loaded with a value. In the next instruction this value is compared with the currently loaded byte. LDRCCB (UAL instruction) will load LR + R3 to R3 if R3 is lower than R12. Else it will use the R12 value. At the end it will jump to R3 << 1 offset from LR. So we have a jumptable (switch). The first byte after the call (BL) tells us the entries. The next one is the default branch. The left shift by two is done so it will always go to valid thumb mode instructions again.
If you have a valid IDA license you can follow the following instrcutions :-)
- Rename the switch function to switch or whatever
- Right click and set it will not return. This prevents parsing of the switch byte table.
- Place your cursor on a BL switch and choose Edit -> Other -> Specify switch idiom
- Address of jump table set to 0xBC (modify to meet the count entry in your case)
- Number of elements to the first byte + 2 (8)
- Size of table element to 1 (one byte for one switch case)
- Element shift count to 1, this is the LSL#1
- Input register to R3 (does not really matter)
- First(lowest) input value to -1 (because of the count at the beginning, so it will align switch cases correctly)
Subscribe to:
Posts (Atom)