Professional Documents
Culture Documents
INTERFACE SPECIFICATION
Ref
K
TITLE DWG NO
APPLICABLE DOCUMENTS
SAE J1708 Rev. OCT93 SURFACE VEHICLE RECOMMENDED PRACTICE
INTENT
The Farebox shall support the relevant subset of PIDs in a manner fully
compliant with SAE J1708 Rev. OCT93. Such compliance specifically includes
full adherence to:
< Mid > := MID, Generic Module other than Farebox, e.g., 188
< Pg1 > := PID, Generic Page 1, i.e., 0 <= Pg1 <= 254
< Pg2 > := PID, Generic Page 2, i.e., 256 <= Pg2 <= 510
The SAE J1587 specification provides four (4) PIDs that enable the farebox
to request specific data elements from other networked components and,
similarly, enable those units to make requests of the Farebox. These are
divided into two categories: (1) component-specific requests, i.e.,
requests made of a specific component on the network, and (2) requests made
of the network as a whole. While all four PIDs are briefly described below,
only the component-specific PIDs 128 and 384 are supported for transit-
related messaging.
Attempts to request PID 192 information from the Farebox are not
supported.
Note: The request for PID 194 data was initially proposed as a
means of polling the Farebox, i.e., as a way of determining that
the Farebox was on line. While still supported, the preferred
approach is to issue a component specific request for PID 378
Fare Collection Unit Status. Please see PID 378 for further
details.
Comments: As previously noted, this PID would be required to send PID 234,
Software Identification, if the combination of Farebox, Operator
Control Unit, and TRiM Software Identification (including
delimiters) were to exceed 17 characters. This is because all
Page 1 variable length messages require 4 bytes of overhead (MID,
PID, Cnt, & Csm), and no message may exceed 21 bytes under normal
operation.
EXAMPLE: Broadcast
Reference: MID 192 Cnt Pg1 s/s cnt ddd ddd ddd ddd ddd ddd ddd ddd
========= === === === === === === === === === === === === === ===
Section 1: <Src> 192 17 234 16 20 ‘1’ ‘1’ ‘1’ ‘1’ ‘1’ ‘1’ ‘*’ ‘2’
‘2’ ‘2’ ‘2’ ‘2’ ‘2’ ‘*’ <Csm>
Section 2: <Src> 192 8 234 17 ‘3’ ‘3’ ‘3’ ‘3’ ‘3’ ‘3’ <Csm>
Attempts to request PID 239 position data from the Farebox are
ignored unless issued by the data’s source in an effort to
confirm reception.
EXAMPLE: Broadcast
<Cnt> := 3
<aaa> := seconds, unsigned short, 0.25 seconds/bit
<bbb> := minutes, unsigned short, 1 minute/bit
<ccc> := hours, unsigned short, hour/bit
Attempts to request PID 251 clock data from the Farebox are not
supported.
EXAMPLE: Broadcast
<Cnt> := 3
<aaa> := day, unsigned short, 0.25 days/bit
<bbb> := month, unsigned short, 1 month/bit
<ccc> := year - 1985, unsigned short, 1 year/bit
Attempts to request PID 252 date information from the Farebox are
not supported.
EXAMPLE: Broadcast
EXAMPLE: Broadcast
(*) Note: SAE J1587, PID 378 defines the status byte value of 24
as indicating “maintenance access - in service, and a status byte
value of 25 as indicating “maintenance access - out of service”.
The Farebox, however, knows only that it is in a “logged on” or
“logged off” state. Rather than have “logged on” and “logged off”
serve as a proxy for “in service” and “out of service”, transit
industry experts, in consultation with GFI Genfare, resolved
that:
EXAMPLE 2: Broadcast
Format: <Src> 255 192 <Cnt> <Pg2> <s/s> <cnt>|<ddd> <Csm> , where
Attempts to request PID 448 information from the Farebox are not
supported.
Comments: See SAE J1587 Revised JUL 1998, Appendix A.502 and A.503
PID 502 and PID 503 are not supported. These two PIDs define
relatively complex, application specific multi-parameter message
structures which prove to be inappropriate and/or unworkable as
standard mechanisms for conveying the data elements covered.
Most damaging is the PID 502 requirement that: “If this parameter
is received by the farebox, values shall be accepted the same as
if entered at the farebox control panel.” Unfortunately, while
PID 502 declares 10 distinct data elements, it provides no means
for assigning values to a subset of these elements. It is
impossible, for example, to assign direction via PID 502 bit-
mapped character 1 without (inadvertently) reassigning fare
preset along with 8 other attributes.
EXAMPLE: Broadcast
Comments: As previously noted, PID 448 would be required to send PID 508,
Transit Route Identification, if the combination of route, run,
and block information (including delimiters) were to exceed 16
characters. This is because all Page 2 variable length messages
require 5 bytes of overhead (MID, 255, PID, Cnt, & Csm), and no
message may exceed 21 bytes under normal operation.
EXAMPLE: Broadcast
Reference: MID 255 192 Cnt Pg2 s/s cnt ddd ddd ddd ddd ddd ddd ddd
========= === === === === === === === === === === === === === ===
Section 1: <Src> 255 192 16 252 16 17 ‘4' '4' '4' ‘4’ '*' '5' '5'
‘5' ‘5’ ‘5’ ‘*’ ‘6’ ‘6’ <Csm>
Section 2: <Src> 255 192 14 252 17 ‘6’ ‘6’ ‘6’ ‘6’ 251 6 ‘1’
‘2’ ‘3’ ‘4’ ‘5’ ‘*’ <Csm>
Finally, note that the PID 507 Driver Identification message has
been included at the end of Section 2. This is possible because
EXAMPLE: Broadcast
Format: <Src> 254 <Dst> {DATA} <Csm> , where {DATA} is vendor defined.
For GFI Data Escape Messages, the first two bytes of this {DATA} stream are
specified to contain escape message type (Emt) and data byte count (Cnt)
information, resulting in the following generic format …
Format: <Src> 254 <Dst> <Cnt> <Emt> {type-specific data} <Csm>, where
Format: <Src> 254 <Dst> <Cnt> <Emt> <f/s> '*' <dir> <Csm> , where
‘0’ = North
‘1’ = South
‘2’ = East
‘3’ = West
‘4’ = Inbound
‘5’ = Outbound
‘?’ = not set
The Farebox will always send fare set but will not send direction
if that feature is not implemented.
<Cnt> := 1
<Emt> := ‘1’
EXAMPLE: Request
Format: <Src> 254 <Dst> <Cnt> <Emt> <Org> '*' <Dst> <Csm> , where
The zones are in the range of 0-15 but are or’d with an
ASCII ‘0’ to be transmitted in a hex range from 0x30-0x3f
The message <Src> may transmit either or both zones. In all cases
the field delimiter is required.
EXAMPLE: Driver sets Origination Zone to 3, but does not change the
destination which is still ‘4’.
EXAMPLE: Driver sets destination zone to 5 but does not change the
origination zone which is still 3.
<Cnt> := 1
<Emt> := ‘3’
The external wiring and connector to connect to the base casting terminal
block will be provided by the Transit Authority or the AVL system integrator.
J1708Mid: The device MID the farebox will interface with on the J1708.
Range 128 – 255
OptionFlags3: Contains six flags, which will enable the J1708 and determine what data
is sent. The following is a definition of the flags:
bit definition
0 J1708/J1587 enabled
1 Store J1708/J1587 diagnostic date transaction
(transaction is saved and sent to the data system, for
GFI use only)
2 ignore date/time data received
3 send any driver/route data changes
4 send farebox alarms
5 store transaction if a bad time/date received
(GFI use only)
NOTE: If the configuration for RUN is set for BLOCK in the gfi.ini file
for the farebox, then the BLOCK sent/received on the J1708 will be
for the RUN. If the RUN is configured for RUN then the BLOCK
sent/received on the J1708 will be used in the TRIP field in the
farebox.
J1708Poll: Contains three flags and a time period of how often to poll the
farebox is to poll for position
bit definition
0 – 4 Poll time in multiples of 10 seconds (i.e. 6 = 60 sec)
5 Poll for stop (unused at this time)
6 Poll for position
7 request data that was just sent by farebox
(Used to confirm data sent by farebox was received)
Logon: One bit (bit 6) in this flag used to determine if PID 254 is to be used
to send/receive fareset/direction.
Hourlyevent: Contains two flags. One flag (bit 3) is used to select if the
“IDLE LINE DETECT” is used to detect the end of an incoming message.
If the “IDLE LINE DEETEC” is used, some messages will be concatenated by
the farebox when sending data on the J1708 port. If the “IDLE LINE
DETECT” is not used, the farebox will not concatenated any messages and
will assume all messages received will also not be concatenated.
The second flag (bit 5) is used to delay the request for route for
about 20 seconds after the farebox has just sent the route data. (Used
in conjunction with J1708Poll (see J1708Poll-bit 7).
RevStatus: Contains one flag (bit4) that is used to determine if PID 501 is to be
used. This is a special feature added for one costumer and should not
be set because the farebox may modify the current route or run based on
information received.
OptionFlags7: One bit (bit 0) in flag is used to see if the Zone System is enabled to
determine if zone data is to be sent/received via PID 254.
OptionFlags6: Four bits (bits 12-15) used as a timer in minutes to reset the J1708 com
port after no activity. Range is from 0 to 15 minutes. A zero disables
disables the timer.
(end of document)