Home Esplora
Accedi
clementinecomputing
/
popufare
1
0
Forka 0
File Problemi 12 Pull Requests 0 Wiki
Albero (Tree): 3d8e67a0c8
Rami (Branch) Tag
popufare
/
experiment
/
production
/
PIU-Notes.md

PIU-Notes.md 6.0 KB
Cronologia Originale

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.

UPDATE

The proxmark3 is a general purpose RFID hardware tool that can be used to read and write low frequency (125 kHz - 134 kHz) as well as high frequency (12.57 MHz). The code is under LGPL and I assume the hardware files are under the same or similar license. The hardware files don't have a license on them but I think the proxmark3 is marketed as an open source hardware project so it's probably safe to assume this was the intent.

The proxmark3 is sold in the $250-$300 (as of this writing) but there are clones available at a fraction of the cost ($60-$80) on eBay.

The proxmark3 can read HID class cards so I think it's an ideal candidate to use as a general purpose RFID reader. At the least, this will be a relatively low cost solution that will read a variety of cards that any organization can use. If needed, there is the possibility of using it as a writer, either in the field or offline, for custom RFID tags.

Magstripe Reader

The current PIU has a dual head, 3-track magstripe reader. As of this writing, single head 3-track USB magstripe readers sell for around $15. I see some alternatives on Aliexpress and Alibaba that are in the range of $10 in single units and $6 in quantity 5k+.

Dual head, 3-track magstripe USB readers sell for around $60 on Amazon and Ebay.

The possible solutions to this are:

  • Use the $60 'off-the-shelf' solution
  • Buy two USB off-the-shelf single head USB readers and make a housing via 3d printing, say, to put both heads in for 1/3 to 1/6 the cost.
  • Live with single head magstripe reader

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.

zbar-tools (perhaps mcheheb/zbar?) looks to be a tool to scan QR codes.

Here's an example:

$ sudo apt-get install zbar python-zbar
$ git clone https://github.com/mchehab/zbar
$ cd zbar/python/examples
$ python ./scan_image.py ../../examples-qr-code.png
('decoded', 'QRCODE', 'symbol', '"https://github.com/mchehab/zbar"')

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