No characters detected when using pcProx USB Badge Reader

[baghdasaryan]

Hello!

I got the host shield working correctly (characters get printed in Serial Monitor) with a USB keyboard using USBHIDBootKbd sketch example from the library, but I am having issues when connecting a USB Badge reader that's supposed to operate just like a keyboard.

Whenever I scan a card on the badge reader, it is supposed to print a 7 digit number and then a new line character. Badge reader works correctly when connected to a computer (tested on Mac, Windows and Raspberry Pi without any special drivers) but does not produce any output when connected over USB Host Shield to ESP8266. So, whenever I scan a card, badge reader beeps and flashes green LED (indicating that the card was read), but there is nothing printed in serial monitor.

I am wondering if you have any advice on how I could debug this issue? Details below.

Thanks for all the help!

Badge reader I use: http://www.rfideas-shop.com/en/pcprox-enroll-hid-iclass-pearl-usb-reader.html

Following are some details/pictures of my setup: #263 (comment)

Output of running USB_desc sketch:

01
--

Device descriptor: 
Descriptor Length:	12
Descriptor type:	01
USB version:		0110
Device class:		00
Device Subclass:	00
Device Protocol:	00
Max.packet size:	08
Vendor  ID:		0C27
Product ID:		3BFA
Revision ID:		0942
Mfg.string index:	01
Prod.string index:	02
Serial number index:	00
Number of conf.:	01

Configuration descriptor:
Total length:		0022
Num.intf:		01
Conf.value:		01
Conf.string:		00
Attr.:			80
Max.pwr:		32

Interface descriptor:
Intf.number:		00
Alt.:			00
Endpoints:		01
Intf. Class:		03
Intf. Subclass:		01
Intf. Protocol:		01
Intf.string:		00
Unknown descriptor:
Length:		09
Type:		21
Contents:	10010001224B000705

Endpoint descriptor:
Endpoint address:	81
Attr.:			03
Max.pkt size:		0008
Polling interval:	0A


Addr:1(0.0.1)

Outputs I am getting printed out when uploading sketches to the board after setting "#define ENABLE_UHS_DEBUGGING 1". The information gets printed to serial (after the "Start" log) on connecting the USB device card reader device. Nothing gets printed when I scan a key card on the card reader.

Output when using https://github.com/felis/USB_Host_Shield_2.0/blob/master/examples/HID/USBHIDBootKbd/USBHIDBootKbd.ino sketch:

Start
BM Init
Addr:01
NC:01
HID_PROTOCOL_KEYBOARD
bNumEP:02
Cnf:01
bIfaceNum:00
bNumIface:00

Interface:00
PROTOCOL SET HID_BOOT rcode:00
SET_IDLE rcode:00
RPIPE rcode:00
BM configured

Full output from Serial is here: https://pastebin.com/NCgEGfC7

Output when using https://github.com/felis/USB_Host_Shield_2.0/blob/master/examples/HID/USBHIDMultimediaKbd/USBHIDMultimediaKbd.ino sketch:

Start
HU Init
Addr:01
NC:01
Cnf:01
NumIface:01
SetIdle:00
HU configured

Output when using https://github.com/felis/USB_Host_Shield_2.0/blob/master/examples/HID/USBHIDBootKbdAndMouse/USBHIDBootKbdAndMouse.ino. sketch:

Start
BM Init
Addr:01
NC:01
HID_PROTOCOL_KEYBOARD AND MOUSE
bNumEP:02
D1
BM Init
Addr:01
NC:01
HID_PROTOCOL_KEYBOARD
bNumEP:02
Cnf:01
bIfaceNum:00
bNumIface:00

Interface:00
PROTOCOL SET HID_BOOT rcode:00
SET_IDLE rcode:00
RPIPE rcode:00
BM configured

[Lauszus]

My guess is that you need to modify the parser for your needs. Please run the following example: https://github.com/felis/USB_Host_Shield_2.0/blob/master/examples/HID/USBHIDBootKbd/USBHIDBootKbd.ino, but add the following code at this line https://github.com/felis/USB_Host_Shield_2.0/blob/master/hidboot.cpp#L128:

Notify(PSTR("\r\n"), 0x80);
for (uint8_t i = 0; i < len; i++) {
        D_PrintHex<uint8_t > (buf[i], 0x80);
        Notify(PSTR(" "), 0x80);
}

Then you it should print the raw incoming bytes.

[baghdasaryan]

I'd be happy to to write a new parser to make it work for my use-case. Just need to get something being printed out to Serial, so I can analyze it and get started on the parser.

Modified hidboot.cpp file as you mentioned. KeyboardReportParser::Parse function now looks as follows:

void KeyboardReportParser::Parse(USBHID *hid, bool is_rpt_id, uint8_t len, uint8_t *buf) {
        // Print out all incoming bytes for debugging purposes
        Notify(PSTR("\r\n"), 0x80);
        for (uint8_t i = 0; i < len; i++) {
                D_PrintHex<uint8_t > (buf[i], 0x80);
                Notify(PSTR(" "), 0x80);
        }

        // On error - return
        if (buf[2] == 1)
                return;

        //KBDINFO       *pki = (KBDINFO*)buf;

        // provide event for changed control key state
        if (prevState.bInfo[0x00] != buf[0x00]) {
                OnControlKeysChanged(prevState.bInfo[0x00], buf[0x00]);
        }

        for (uint8_t i = 2; i < 8; i++) {
                bool down = false;
                bool up = false;

                for (uint8_t j = 2; j < 8; j++) {
                        if (buf[i] == prevState.bInfo[j] && buf[i] != 1)
                                down = true;
                        if (buf[j] == prevState.bInfo[i] && prevState.bInfo[i] != 1)
                                up = true;
                }
                if (!down) {
                        HandleLockingKeys(hid, buf[i]);
                        OnKeyDown(*buf, buf[i]);
                }
                if (!up)
                        OnKeyUp(prevState.bInfo[0], prevState.bInfo[i]);
        }
        for (uint8_t i = 0; i < 8; i++)
                prevState.bInfo[i] = buf[i];
};

Works correctly when connected to an external USB keyboard - bytes get printed out.

Still not working with the card reader. Nothing gets printed out to Serial when I scan the card... Is there a lower-level location I can insert the logging statement at?

[gdsports]

The problem might be a lack of power. A 9V battery does not provide much current. The ESP8266 can take 250-300 mA @ 5V. The RFID reader might also take a couple hundred mA. Instead of the battery, plug a wall adapter in to the breadboard power supply. 9V 1A or 12V 1A should be more than enough.

Check the docs for the maximum input voltage before trying 12V. Even if 12V is permitted, the power supply may get very hot so watch out.

USB keyboard usually draw less than 100 mA so may work when other devices fail.

[baghdasaryan]

Thanks for the suggestion, @gdsports. This was one of the things I didn't try.

The card reader is intended to work as a USB 2.0 Keyboard, and when I connected it to my laptop or a Raspberry Pi it works fine. USB 2.0 ports generally provide 5V 0.5A (according to wiki), so I am concerned about testing the device at voltage beyond 5V.

I updated setup by connecting an external power supply (5V 1A) straight to the card reader (through USB Host Shield) and another external power supply directly to ESP8266 (so they don't interfere with each other) and re-tested the setup. Unfortunately, the result was the same - nothing printed on Serial terminal when scanning my card. The card reader blinks its LED (from red to green and then back to red) and Beeps as expected (just like when connected to a laptop) indicating that the card was successfully read, but I still see nothing on the terminal...

Not really sure what to try next...

[Lauszus]

Thanks for your suggestion @gdsports!

Try to dig deeper into the lower layers of the library. It's hard for me to debug it since I do not have the hardware.

[baghdasaryan]

While I continue debugging, my most recent find is that a different code execution path is used with a standard keyboard vs my card reader.

When using a standard keyboard, the following if statement in Usb.cpp gets executed: https://github.com/felis/USB_Host_Shield_2.0/blob/master/Usb.cpp#L276-L283
When using my card reader, a different if statement gets executed: https://github.com/felis/USB_Host_Shield_2.0/blob/master/Usb.cpp#L235-L240

[Lauszus]

@baghdasaryan see: #174.

[baghdasaryan]

I was able to bypass the issue by removing this if statement: https://github.com/felis/USB_Host_Shield_2.0/blob/master/Usb.cpp#L235-L240
After doing that, all characters started getting printed correctly to the console, as expected.

@Lauszus I also tested with changes referenced in #174 pull request, and everything worked as expected.

I suggest we close this issue and continue tracking in #174, as that pull request describes the same problem and contains the fix.

@Lauszus, thanks for all the help in debugging this issue!