[wiregate] - √ - Perl TTY falsche Daten

[foobar0815]

Hi,

ich habe heute meinen IR-Schreib-lesekopf fuer den eHZ (volkszaehler.org - wiki - EMH eHZ-H) bekommen (USB-Variante) und hab' ihn gleich ans Wiregate gesteckt.

Egal was ich versucht habe (socat, stty+cat, perl), die Daten entsprechen nicht dem Protokoll. Stecke ich den Leser allerdings an einen anderen PC, funktioniert das gleiche Perl-Skript auf Anhieb (ebenso cutecom, socat).

Habe auch die Einstellungen der Schnittstelle mit stty -F /dev/powermeter0 verglichen, waren identisch.

Das Skript sieht so aus:

my $PORT='/dev/powermeter0';

use warnings;
use strict;
use utf8;
use Device::SerialPort;

my $tty = new Device::SerialPort($PORT) || die "can't open $PORT: $!";
$tty->baudrate(9600)     || die 'fail setting baudrate';
$tty->databits(8)        || die 'fail setting databits';
$tty->stopbits(1)        || die 'fail setting stopbits';
$tty->parity("none")     || die 'fail setting parity';
$tty->write_settings     || die 'fail write settings';
$tty->rts_active(0);
$tty->dtr_active(0);
$tty->read_char_time(0);
$tty->read_const_time(3000);
#$tty->debug(1);

my $timeout = 10;

while ($timeout > 0) {
        my ($num_read, $s) =  $tty->read(316);
        ...
$tty->close || die "can't close $PORT: $!";

Steh' ich auf dem Schlauch oder habe ich noch was vergessen?

Danke!

[makki]

Mal so ein paar Ideen ins blaue (ich hab den Lese-Kopf zwar hier liegen, aber keinen Zähler dazu..):

- /dev/powermeter0 gibts auch? Also defaultmässig ganz sicher nicht!
- falls nicht /dev/powermeter0 sondern eher /dev/ttyUSBx
- sitzt jemand anderes (socat, ser2net, Plugin, ...) drauf:
lsof | egrep "ttyUSB|powermeter|usbserial"

Makki

[foobar0815]

Hi,

- eigene udev-rule, die den Node erstellt (kein Symlink auf einen anderen).
- niemand sonst hat den geoeffnet.

Ausserdem:
- Keine Aenderung durch reboot (also hoffentlich nicht durch esoterische Einstellungen des ttys verursacht)

Diese Antwoerten hab' ich gestern auf dem Wiregate bekommen:

Beispiel:

[COLOR="DarkRed"]15 cd 02 6f 09 89 02 03 09 dd 57 01 fb 15 cd 02 
6f 09 89 02 03 0d dd 57 01 ff 15 cd 02 6f 09 89 
02 03 09 dd 57 01 fb 15 cd 02 6f 09 89 02 03 0d 
dd 57 01 ff 15 cd 02 6f 09 89 02 03 09 dd 57 01 
fb 15 cd 02 6f 09 f4 02 03 07 dc 55 89 ff 15 cd 
02 6f 09 89 02 03 09 dd 57 01 ff 15 cd 02 6f 09 
89 02 03 0d dd 57 01 ff 15 cd 02 6f 09 89 02 03 
09 dd 57 01 fb 15 cd 02 6f 09 89 02 03 0d dd 57 
01 ff 15 cd 02 6f 09 89 02 03 0d dd 57 01 ff 15 
cd 02 6f 09 89 02 03 0d dd 57 01 ff 15 cd 02 6f 
09 89 02 03 09 dd 57 01 ff 15 cd 02 6f 09 89 02 
03 0d dd 57 01 fb 15 cd 02 6f 09 89 02 03 0d dd 
57 01 fb 15 cd 02 6f 09 89 02 03 0d dd 57 01 fb [/COLOR]
15 cd 02 6f 09 89 02 03 0d dd 57 01 fb 15 cd 02
6f 09 89 02 03 0d dd 57 01 fb 15 cd 02 6f 09 89 
02 03 0d dd 57 01 fb 05 cd 02 6f 09 89 02 03 09 
dd 57 01 ff 05 cd 02 6f 09 89 02 03 0d dd 57 01 
ff 05 cd 02 6f 09 89 02 03 0d dd 57 01 fb 05 cd 
02 6f 09 89 02 03 0d dd 57 01 fb 05 cd 02 6f 09 
89 02 03 09 dd 57 01 ff 05 cd 02 6f 09 89 02 03 
09 dd 57 01 fb 05 cd 02 6f 09 89 02 03 09 dd 57 
01 fb 05 cd 02 6f 09 89 02 03 09 dd 57 01 fb 05 
cd 02 6f 09 89 02 03 09 dd 57 01 ff 05 cd 02 6f 
09 89 02 03 09 dd 57 01 fb 05 cd 02 6f 09 89 02 
03 09 dd 57 01 fb 05 cd 02 6f 09 89 02 03 09 dd
...

Aussehen sollte es allerdings wie auf dem PC:

[COLOR="DarkRed"]1b 1b 1b 1b 01 01 01 01 76 07 00 08 00 1e 92 cd 
62 00 62 00 72 63 01 01 76 01 01 07 00 08 00 09 
30 ef 0b 06 45 4d 48 01 04 c5 67 c5 a2 01 01 63 
ef 66 00 76 07 00 08 00 1e 92 ce 62 00 62 00 72 
63 07 01 77 01 0b 06 45 4d 48 01 04 c5 67 c5 a2 
01 72 62 01 65 00 09 ba 7a 77 77 07 81 81 c7 82 
03 ff 01 01 01 01 04 45 4d 48 01 77 07 01 00 00 
00 09 ff 01 01 01 01 0b 06 45 4d 48 01 04 c5 67 
c5 a2 01 77 07 01 00 01 08 00 ff 63 01 82 01 62 
1e 52 ff 56 00 00 06 bb 82 01 77 07 01 00 01 08 
01 ff 01 01 62 1e 52 ff 56 00 00 06 bb 82 01 77 
07 01 00 01 08 02 ff 01 01 62 1e 52 ff 56 00 00 
00 00 00 01 77 07 01 00 0f 07 00 ff 01 01 62 1b 
52 ff 55 00 00 0f 4b 01 77 07 81 81 c7 82 05 ff 
01 01 01 01 83 02 8d ac 6c e0 0d 7a 8f 3f 66 7b 
e4 c4 8a c4 89 3d 09 91 6a 67 4d ff 72 6d 7b 28 
53 8d dc c0 18 f4 59 58 95 35 81 f9 64 5f 1f 19 
8a 27 b2 87 0c f1 01 01 01 63 b0 a5 00 76 07 00 
08 00 1e 92 d1 62 00 62 00 72 63 02 01 71 01 63 
3b e7 00 00 1b 1b 1b 1b 1a 01 00[/COLOR] b1 1b 1b 1b 1b 
01 01 01 01 76 07 00 08 00 1e 92 d3 62 00 62 00 
...

Gerade nochmal auf dem WG versucht, diesmal kommen nurnoch 0en an, es sind aber scheinbar immer 2 Pakete nacheinander, dann wieder kurze Wartezeit, dann wieder 2 usw.

read: 316
data:
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
read: 316
data:
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
...
warten...
wieder 2...

Ideen? Version von Device::SerialPort? aber socat etc wollen ja auch nicht die korrekten Daten liefern.

[foobar0815]

noch ein kurzes Update:

um sicherzugehen, dass auch tatsaechlich auf beiden Kisten das tty gleich konfiguriert ist, hier noch die Ausgabe von stty -g -F /dev/powermeter0, jeweils als das Programm lief:

PC:

1:4:cbd:a30:3:1c:7f:15:4:30:0:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

1:4:cbd:a30:3:1c:7f:15:4:30:0:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

Ideen? Linux-Treiber-Problem?

[Monti]

Ideen? Linux-Treiber-Problem?

Ich habe hier zwei Leseköpfe von volkszaehler.org. Die laufen ohne Probleme am Wiregate, so dass ich ein generelles Treiberproblem ausschließen würde.

[NetFritz]

Hallo
Ich habe auch keine vernünftige Ausgabe bei meinen Easymeter Q3C und WG hinbekommem.
Als Auslesekopf wurde ein gekaufter USB-Auslesekopf und einer von volkszähler.org verwendet.

Ich habe dann den Auslesekopf beim Raspberry Pi angesteckt und konnte sofort in der Konsole die SML Daten sehen.

Im gekauften Kopf ist ein USB to RS232 Wandler FT232BM von FDTI drin und im Auslesekopf von volkzähler.org ein FT232RL von FDTI .

Gruß NetFritz

[foobar0815]

Hi,

wir kommen dem schon auf die Schliche.

Offensichtlich hatte Udo diesmal ein anderes Teil rumliegen:

Bus 002 Device 004: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x Composite Device
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x10c4 Cygnal Integrated Products, Inc.
  idProduct          0xea60 CP210x Composite Device
  bcdDevice            1.00
  iManufacturer           1 Silicon Labs
  iProduct                2 CP2104 USB to UART Bridge Controller
  iSerial                 3 00506C7A
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              254mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              2 CP2104 USB to UART Bridge Controller
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)

[makki]

Das dürfte die Sache erklären: die CP210x sind ganz wilde Buben..

Kernel-Versionen PC, WG? (es gibt einen frischen 3.5.1, wird aktuell aber nur manuell/händisch installiert, da könnte ein neuerer Treiber drinsein..)

Makki

[foobar0815]

Mir dem neuen Kernel gehts, scheint also tatsaechlich am Treiber zu liegen.

Danke!

[makki]

Guad.. Nur für mein Gedächtnis und den nächsten Fall: war aufm WG vorher 2.6.26 oder 2.6.32 drauf?

Makki

[Monti]

Offensichtlich hatte Udo diesmal ein anderes Teil rumliegen:

Der andere USB-Chip scheint das Problem zu sein. In meinem Volszähler-Lesekopf ist folgender verbaut (und er funktioniert am WG):

Bus 002 Device 006: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x0403 Future Technology Devices International, Ltd
  idProduct          0x6001 FT232 USB-Serial (UART) IC
  bcdDevice            6.00
  iManufacturer           1 FTDI
  iProduct                2 FT232R USB UART
  iSerial                 3 AHVFQTEH
  bNumConfigurations      1

[foobar0815]

Makki:

dpkg -l

rc  linux-image-2.6.24                   wg.1.0                     Linux kernel binary image for version 2.6.24
rc  linux-image-2.6.24-etchnhalf.1-486   2.6.24-6~etchnhalf.7       Linux 2.6.24 image on x86
rc  linux-image-2.6.24-wiregate-1.0      1.0                        Linux kernel binary image for version 2.6.24
rc  linux-image-2.6.26-1-486             2.6.26-13lenny2            Linux 2.6.26 image on x86
rc  linux-image-2.6.26-wiregate-1.0      1.0                        Linux kernel binary image for version 2.6.26
ii  linux-image-2.6.32-wiregate-1.31     1.31                       Linux kernel binary image for version 2.6.32
ii  linux-image-3.5.1-wiregate           1.4                        Linux kernel binary image for version 3.5.1-

Seit dem Update bekommt der Kernel allerdings Panik, bisher eingegrenzt auf den per RS232 direkt angeschlossenen Steca Solarregler, ist aber ein anderes Thema und ich hatte bisher keine Zeit, dem auf den Grund zu gehen.


Der aktualisierte Kernel versteht sich praechtig mit dem USB-Chip.

Gruesse

[makki]

linux-image-2.6.32-wiregate-1.31

Nur das wollte ich wissen, nominell hat sich an dem CP21x nämlich seither nichts geändert.. ggü 2.6.26 schon..

Der Kernel bekommt keine Panic, nicht der erste, nicht der zweite und auch ned der letzte 3.5.1 - also da muss was anderes im Busch sein..

Makki

[foobar0815]

Hallo,
Ich hab' mal bisschen rumgeschaut, sieht stark nach
https://bugzilla.kernel.org/show_bug.cgi?id=42586
aus und wurde wohl mit dem Patch
git.kernel.org - linux/kernel/git/stable/linux-stable.git/commitdiff
behoben.

Im 2.6.32 ist der nicht angekommen:

git.kernel.org - linux/kernel/git/stable/linux-stable.git/history - drivers/usb/serial/cp210x.c


Schoenen Abend!

(Wer da auch immer Panik bekommt oder im Busch sitzt, ich werde es mir die Tage mal anschauen und einen extra Thread eroeffnen.)

[makki]

Wiegesagt: der CP21xx war&ist ein Problembär..
Wenns geht: Finger davon.. Das - aus anderen Gründen - "nun mal husch" ein Kernel 3.5.1 (erheblich neuer als aktuelles Ubuntu oder gar Debian [stable ist 2.6.32 -also das was seit Jahren aufm WG druf ist]) gebacken wurde.. naja, hatte andere Gründe..

Ich denke da immer gerne an die Vorwürfe, das das WG mit Lenny/5.0 "zu alt" wäre Wo die meisten DSL-Modems, erheblich exponierter, mit 2.4 auskommen müssen..

Makki