Los Angeles Transit Access Pass about metrodroid

[micolous]

Oh cool. It looks like that the TAP Card is also made by Cubic, and using a
similar design. I'll have to look into the stop IDs.

Can you please send me an export of your card and it's number by email (my
github username at Gmail.com)? I'll see if I can find a difference between
this card and my Go card.

On Sat., 17 Sep. 2016, 10:54 steets250, [email protected] wrote:

Hi Micolous,

I have an "add my transit provider" request. Unlike other requests, you've
already done most of the work. I live in Los Angeles, which uses the
Transit Access Pass card, also known as TAP. When used with Metrodroid, it
is recognized as the Go Card (SEQ), with the correct serial number showing.
The card balance and history tabs are sometimes accurate but usually show
incorrect data. It would seem that the Go Card and TAP Card share record
types, but have varying sectors for where the records go. Using your
description of the record types, I was able to correctly extrapolate data
from my card scans including tap, top-up, and balance records. The
Metrodroid app is able to do this, but it only works on certain
transactions.

I created a wiki page similar to your existing ones with information about
the TAP card, including the data locations of the card. Unfortunately, a
total noob at programming, so I can't offer much help with the actual
coding. It seems that this card is pretty similar to the ones you have
already added to this app. I am able to provide more data about the card if
needed, including actions that the app currently does and does not read
correctly. Would implementing this card be hard to accomplish? I

Thanks, Steven

Transit Access Pass (TAP).txt
https://github.com/micolous/metrodroid/files/477886/Transit.Access.Pass.TAP.txt

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#17, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPEP2x29bdntyoNJfUolP8fGkFYEEgYks5qqzpDgaJpZM4J_dvb
.

[micolous]

I've got the files from Steven. It looks like that the system is also Cubic Nextfare, and it uses some features of the system which Brisbane's Go card doesn't use. The majority of travel is done on monthly travel passes.

I'll need to refactor the Go card reader in order to handle this better -- but this isn't going to happen before I cut the next release.

I need to analyse Steven's dumps and my own card dumps and determine what differences there are.

[micolous]

Generic Nextfare support is implemented using the extra information in this document. I've also made the Go card use the same reader, and it appears to be functional. The next step will be implementing the LAX TAP-specific features on the card, like station IDs etc.

[micolous]

Updated the reader so that the nonsense top-ups (>$327.68) are gone. Still trying to figure out some quirks with getting the travel passes to be read correctly.

I've also updated the documentation so that there is a generic Nextfare document which the Go card documentation references instead.

[steets250]

Attached is a list of the stop IDs that I've been able to get so far. Each item includes the number indicated by the hex value of the field in the tap record, stop name, as well as the rail lines that it serves. If possible, maybe the rail lines served could be indicated in the app. Let me know if you need any more details about the stations.

tapstops.txt

[micolous]

Thanks! I'll end up pulling this into a separate database tool like with seq_go.

For Metro Bus and Rail services:

• https://gitlab.com/LACMTA/gtfs_rail/blob/master/stops.txt
• https://gitlab.com/LACMTA/gtfs_bus/blob/master/stops.txt

I've ended up learning a lot more about SEQ's Nextfare implementation as a result of this data. I'm nearly happy enough with the Nextfare reader to proceed with implementing LAX-specific bits.

[steets250]

I'm glad to hear that the data has been helpful to you. Thanks for sending the links!That's actually where I got the list of train stops for the list I sent to you. I excluded all of the data except the stop names, since the stop numbers don't match to those shown on the tap card. I'll have a change to ride on the remaining lines, and can pretty much complete the stop list for rail.

[steets250]

Sorry, clicked wrong button😅

[micolous]

I think I can now detect the travel passes a little better, and I've cleaned up some of the code around it. I can see how unused travel passes work.

From what I'm reading of Los Angeles Metro's public docs, travel passes seem to have several variables:

• Class of travel: regular, student ...
• Duration: 1 day, 7 days, 30 days ...
• Operator: Multi-operator, single operator ...

But only one travel pass can be loaded on the card at a time.

Once the pass is in use, the expiry date is set properly.

If you have some examples of these differences with your own cards, please email them through.

[micolous]

I've put in a mapping.csv file for LACMTA Metro. This isn't wired up inside Metrodroid just yet, but makes it a little easier to contribute those station codes across.

I've used the S suffixed station codes, as these don't have extra notes on which lines are at that station if it is an interchange between multiple lines. This way the station names are nice and short.

[micolous]

...and now that mapping file is wired up. But I think I will need to change the table schema a bit in order to allow each agency to have it's own "scope" of stop_ids, and possibly also handle stop_ids indicating routes.

I can only see two different Metro Bus station IDs in the dataset you've provided, but there's a total of three different Metro Bus routes represented in the dataset, and you've pointed out some occasional conflicts.

If you can catch 1 other different Metro Bus route, that would help to sort out if that stop_id data is actually meaningful, and if the conflicts are just a case of the driver not entering the route number on the ticket machine.

I've started writing notes on https://github.com/micolous/metrodroid/wiki/Transit-Access-Pass for TAP-specific behaviours I'm noticing.

If you're making builds from the git repository yourself, you should be able to see where I'm up to with all this, and everything is coming together. 🎉 🎈

[steets250]

It works!! 🎉 🎉 It got the history and subscriptions perfectly!

As for busses, 33055 is route 733 west, 32788 is route 733 east, and 32952 is route 720 west. I took the 720 three times at different stops. The sectors when I took that route are below.

720 actions.txt

[micolous]

So it looks like I'm going to need to tweak the database a little more to be able to handle the different routes on Metro Bus.

I'm thinking of putting them in as a static list, because Metrodroid doesn't actually ever display route maps, and the GTFS data that Metro provide for busses doesn't differentiate routes based on direction, and merges several lines.

[micolous]

I've done the work now to get that agency-keyed database working right. Metro Buses also look good now.

[micolous]

The reader for this card is rolling out in 2.9.29 officially now.

[denysvitali]

I have a 2014 TAP card, unfortunately I don't have the keys. Isn't it the same for everyone?
Has anyone got the key and can send it to me (or post it here)?

At the moment I don't have my NFC reader to crack the Mifare Classic key, if it is the same for everyone I'll post it here as soon as I have some spare time

[micolous]

Everyone has different keys. You need to crack your own card to get the keys. Pretty sure this is noted in the docs already.

…

On Mon., 5 Dec. 2016, 22:27 Denys Vitali, ***@***.***> wrote: I have a 2014 TAP card, unfortunately I don't have the keys. Isn't it the same for everyone? Has anyone got the key and can send it to me (or post it here)? At the moment I don't have my NFC reader to crack the Mifare Classic key, if it is the same for everyone I'll post it here as soon as I have some spare time — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPEP6djTbsfOQec_R-YEZoU1jSYYNGYks5rE_w0gaJpZM4J_dvb> .

[micolous]

I confirmed this on the TAP Card dumps I have -- everyone has different keys. You need to crack your own cards. This is true for all Cubic Nextfare Mifare Classic cards, even very old ones. They use a key diversification function, which may mean that they share a common key/function, but these are unknown, so every card has effectively different keys for every sector. See the wiki for pointers on what tools to look at and hardware to get. Because I have no intention of providing a help forum for using other people's tools, I'm locking this bug. If you have issues to report with the TAP reader that are not to do with cracking keys, please open a new issue. Thanks!

…

On 5 Dec. 2016 22:49, "Michael" ***@***.***> wrote: Everyone has different keys. You need to crack your own card to get the keys. Pretty sure this is noted in the docs already. On Mon., 5 Dec. 2016, 22:27 Denys Vitali, ***@***.***> wrote: > I have a 2014 TAP card, unfortunately I don't have the keys. Isn't it the > same for everyone? > Has anyone got the key and can send it to me (or post it here)? > > At the moment I don't have my NFC reader to crack the Mifare Classic key, > if it is the same for everyone I'll post it here as soon as I have some > spare time > > — > You are receiving this because you modified the open/close state. > > > Reply to this email directly, view it on GitHub > <#17 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAPEP6djTbsfOQec_R-YEZoU1jSYYNGYks5rE_w0gaJpZM4J_dvb> > . >