# Application processor datasheet **URL:** \ **Category:** mangOH Red\ **Created:** [August 1, 2018, 4:59pm UTC](https://mangoh.discourse.group/t/application-processor-datasheet/1786 "2018-08-01T16:59:40Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![fgodfrey](https://avatars.discourse-cdn.com/v4/letter/f/f475e1/32.png) [@fgodfrey](https://mangoh.discourse.group/u/fgodfrey)\ **Post date:** [August 9, 2018, 1:31pm UTC](https://mangoh.discourse.group/t/application-processor-datasheet/1786/6 "2018-08-09T13:31:13Z")
The GPIO numbering situation is… “interesting”… on these modules. The GPIO number if you’re in user space is the same as the name of the PIN in the schematic. This is because Sierra Wireless uses a translation table to translate from user GPIO numbers to “real” GPIO numbers. However, if you’re in the kernel, and you need the “real” GPIO number, you need to manually do the translation, which you can pull out of the table in drivers/gpio/gpiolib-sysfs.c: > [@GPIO Interrupts on WP7702 Module](https://mangoh.discourse.group/t/gpio-interrupts-on-wp7702-module/1616/2): > > If anyone else stumbles across this… I figured out my issue. It turns out that Sierra Wireless goes to great lengths to hide Linux’s idea of the “real” GPIO number from you. This is “great” if you’re in user space since the GPIO on the schematic matches the number in Linux’s sysfs interface. Unfortunately, if you’re in the kernel, this doesn’t work at all; you need to request the real GPIO number. My hint was when I hit one of the “wakeup” pins (GPIO36) and the message printed to the consol… --- _[View the full topic](https://mangoh.discourse.group/t/application-processor-datasheet/1786)._