Multiple Presence Maps at Start of FAST Message

, ,
1

Imported from previous forum

2

I have a situation in a FAST stream which is two presence maps at the beginning of the message:

First column, byte value as received, second column with stop bit removed.

225 97 (presence map i)
224 96 (presence map ii)
132 4 (template id 4)
216 88 X

This occurrs due to a templateref as per the below extract from the FAST spec:

“A static reference specifies that processing should continue with the referred template as the current template. A static reference does not imply that there is a presence map or template identifier in the stream”

Question is, how do I know how many presence maps are following on before I get to my template Id?

Thanks.

3

Vaughn,

not sure how you arrive at the conclusion that there are two pmaps?
Which feed is this data from?

Best,
Rolf

I have a situation in a FAST stream which is two presence maps at the beginning of the message:

First column, byte value as received, second column with stop bit removed.

225 97 (presence map i)
224 96 (presence map ii)
132 4  (template id 4)
216 88 X

This occurrs due to a templateref as per the below extract from the FAST spec:

“A static reference specifies that processing should continue with the referred template as the current template. A static reference does not imply that there is a presence map or template identifier in the stream”

Question is, how do I know how many presence maps are following on before I get to my template Id?

Thanks.

4

I have a situation in a FAST stream which is two presence maps at the beginning of the message:

What makes you think the second field is a presence map?

First column, byte value as received, second column with stop bit removed.

225 97 (presence map i)
224 96 (presence map ii)
132 4  (template id 4)
216 88 X

The first field is a presence map: 225 → 0xE1 → 0b1110 0001
Removing the stop bit gives a presence map of 110001 (which you show as 97)

Because the first bit if the presence map is a 1 the next field MUST be the template ID. The template ID for this message is 96.

If 96 is not a valid template ID then there is template mismatch between encoder and decoder or there is a bug in the encoder that produced this message.

This occurrs due to a templateref as per the below extract from the FAST spec:

“A static reference specifies that processing should continue with the referred template as the current template. A static reference does not imply that there is a presence map or template identifier in the stream”

To elaborate on the statement from the specification:

You could copy the fields from the referenced template and paste them in place of the templateRef tag and the FAST encoded data would be exactly the same.

There is no reason to send the template id for the referenced template. It is already known.

The set of fields defined by the referenced template is well defined and never changes (i.e. it is static) therefore fields included by a static template reference can safely use the presence map of the enclosing field set. (in this case the field set is the message.)

Question is, how do I know how many presence maps are following on
before I get to my template Id?

Answer: there will always be exactly one.

Dale

Thanks.

5

I have a situation in a FAST stream which is two presence maps at the beginning of the message:

What makes you think the second field is a presence map?

First column, byte value as received, second column with stop bit removed.

225 97 (presence map i)
224 96 (presence map ii)
132 4  (template id 4)
216 88 X

The first field is a presence map: 225 → 0xE1 → 0b1110 0001
Removing the stop bit gives a presence map of 110001 (which you show as 97)

Because the first bit if the presence map is a 1 the next field MUST be the template ID. The template ID for this message is 96.

If 96 is not a valid template ID then there is template mismatch between encoder and decoder or there is a bug in the encoder that produced this message.

This occurrs due to a templateref as per the below extract from the FAST spec:

“A static reference specifies that processing should continue with the referred template as the current template. A static reference does not imply that there is a presence map or template identifier in the stream”

To elaborate on the statement from the specification:

You could copy the fields from the referenced template and paste them in place of the templateRef tag and the FAST encoded data would be exactly the same.

There is no reason to send the template id for the referenced template. It is already known.

The set of fields defined by the referenced template is well defined and never changes (i.e. it is static) therefore fields included by a static template reference can safely use the presence map of the enclosing field set. (in this case the field set is the message.)

Question is, how do I know how many presence maps are following on
before I get to my template Id?

Answer: there will always be exactly one.

Dale

Thanks.

Thanks, had a feeling the encoder was doing something really odd as I’ve never seen two presence maps at the start of a message before.

Will get feedback from the exchange in question.

Thanks!!