At the receiver end, the LPC2148 must be recognized as a HID keyboard. The data sent by the USB keyboard on the transmitter end would be received by the receiver LPC2148. It can communicate with the host PC as a keyboard only if it is configured as a USB HID device. An easier option would have been to communicate with the Host PC via UART. However, this limits the output to a COM port application such as PuTTy. 

The support for HID devices is readily available on the ARM website. The standard example implements a general purpose input/output HID device. According to the USB protocol, changing the descriptors should actually be enough to make the LPC to behave as any other peripheral compatible with USB. The documentation on the ARM website mentions that the only descriptor needs to be changed is the report descriptor. However, this failed to work. The error that showed up when it was connected to the host PC was 'Device Descriptor Request Failed'. Changing other descriptors had no effect and the errors persisted. A few other errors that popped up during enumeration was 'Invalid Configuration Descriptor'. The device was also tested on Ubuntu, again to no avail. 

USBView is a Windows debugger which gives the details of all the components connected to the USB ports of the host PC. It also shows the exact configuration, device, endpoint, interface and HID class descriptors of connected devices. By connecting the USB keyboard directly to the host PC, these values were noted down. The receiver LPC was then configured using these values, but the host PC still failed to recognize it as a valid USB device. The descriptors of other devices were also tried, including a USB mouse. Surprisingly, the LPC was detected as HID-compliant mouse for a short while. After that, enumeration failed as usual. 

Turns out that the value of the descriptors determines which systems the device could be detected on. With some help, we were able to configure the LPC as a HID keyboard. However, this only worked on Lenovo machines running on Windows 10. 

Another change that was required in the default code was the IN report. This has an 8 byte format. The first byte is the modifier, which indicates the status of the shift, control and alt keys. he next byte is reserved. The other bytes represent the keycodes. In this project, we only use the first one.