popufare/experiment/production/PIU-Notes.md

PIU Notes

These are notes for the a PIU upgrade to include newer hardware.

Overview

The PIU should be able to accept a variety of fare media, including magstripe cards (multiple track), RFIDs (125kHz and Mifare) and barcode/QR codes using a camera.

The display should be such that communication is given back to the rider. The camera can also be used to potentially help with QR code alignment to the (down facing) camera.

There's some investigation that should be done in terms of what, if any, gets offloaded to a microcontroller but the basic idea is:

• The Raspberry Pi (Zero) manages the HID devices, camera and screen
• The camera can be used to scan for QR codes
• For QR code scanning, a passthrough of the camera to the screen can be used for alignment
• The touch screen can be used for confirmation if need be
• Whatever is used for communication back to the DIU can use the same protocol already in place

By having a microcontroller (Arduino, say) that's in charge of communication or the RFID and Magstripe devices, this provides an 'instant on' for that portion of the PIU. Putting everything behind the Raspberry Pi is conceptually simpler but is sluggish to boot up.

Requirements

• Housing
• 12-24v in (requires buck converter)
• Display
• RFID reader (125kHz and Mifare?)
• Magstripe reader (3 tracks)
• Camera
• Arduino

RFID Reader

Some electronics speak "Wiegand Protocol".

There's an Arduino library that has appropriate code (from monkeyboard).

I'm also unclear as to what the current system RFID media uses.

Display

There's a 2.8 inch touch display that could be a candidate (MZDPI).

Apparently there's a simple install script:

cd ~/
git clone https://github.com/tianyoujian/MZDPI.git
cd MZDPI/vga
sudo chmod +x mzdpi-vga-autoinstall-online
sudo ./mzdpi-vga-autoinstall-online
sudo reboot

Camera

I would recommend a Pi NoIR that can be hooked into the Pi Zero (Adafruit).

I've had success in getting it up and running with a Raspberry Pi Zero before and it might be easy to set up and fast enough to use.

Notes

Some of the peripherals act as keyboard input devices. In order to not have them pollute input, they need to be taken over by a process.

SO has an article on it. More investigation needs to be done but the basics look to be:

• Use the "event device interface" /dev/input/event* to look for the device
• Use an ioctl EVIOCGRAB call to get exclusive use of the device

---

cat /proc/bus/input/devices  | grep -P '^[NH]: ' | paste - -

---

There's a Python tutorial that looks to have an easy way to do this:

import evdev
import asyncio
dev = {}

evfns = [ "/dev/input/event0", "/dev/input/event1", ... , "/dev/input/event12" ]

for evfn in evfns:
  _dev = evdev.InputDevice(evfn)
  if dev.name == HID_NAME:
    dev = _dev
    break

dev.grab()

async def print_events(device):
  async for event in device.async_read_loop():
    print(device.path, evdev.categorize(event, sep=': ')

for device in dev:
  asyncio.ensure_future(print_events(dev))

...

The above has to be played around with but it looks like the seeds are there.

References

• SO: Ownership of HID device
• Python evdev tutorial
• GitHub: monkeyboard/Wiegand-Protocol-Library-for-Arduino).
• 2.8 inch touch display
• GitHub: tianyoujian/MZDPI