RBC-System not working properly when Position report is sent in correct frequency.

[BerndHekele]

When the position report is sent in a more realisitc way the trigger for messages 3 are not sent.
@JakobGartner
@Rainer-Lampatzer

This needs to be imfroved for a realistic presentation of the message flow.

[JakobGartner]

that is not very surprising...

At the moment the triggers fire when the train is detected in a very close range around the location where it was sent also according to the JRU data.

If now the frequency of the position reports is lower, we are likely to miss them.

We must therefore define a different position window for firing the triggers, as we will probably not be able to use a more intelligent (meaning including some operational logic) mechanism.

If we really send the position report only every 30s, this might be tricky as the train may move at up to 44m/s ...

If I have a concrete idea before tomorrow I will post it .

Sent from my iPhone

On 14.11.2015, at 21:30, Bernd Hekele [email protected] wrote:

When the position report is sent in a more realisitc way the trigger for messages 3 are not sent.
@JakobGartner
@Rainer-Lampatzer

This needs to be imfroved for a realistic presentation of the message flow.

—
Reply to this email directly or view it on GitHub.

[BerndHekele]

I would l9ike to see a more fault-tollerant implementation in this place.
Is'nt it a realistic solution at least for the MA to fire the trigger as soon as the train has passed this position?
It is not such an issue if we receive the messages a bit later - but it is an issue if important messages are lost.

[JakobGartner]

We can have a wider trigger window .
Meaning that if the position report is received at a certain distance before or after the location it will be triggered .

The only issue is that at the beginning of the track , the distances between the LRBGs are shorter . But also, there, we drive slower.

I will analyze the JRU data one more time and come back to you .

On 15.11.2015, at 10:47, Bernd Hekele [email protected] wrote:

I would l9ike to see a more fault-tollerant implementation in this place.
Is'nt it a realistic solution at least for the MA to fire the trigger as soon as the train has passed this position?
It is not such an issue if we receive the messages a bit later - but it is an issue if important messages are lost.

—
Reply to this email directly or view it on GitHub.

[jokaICS]

Please correct me if I'm wrong, but the triggering of radio messages is evaluated against the LRBG, isn't it? So widening the trigger window may not suffice, if we never receive a position report with the required LRBG (which might happen, if the position report is sent only every 30s).

We have two other options:

• implementing a dynamic MA in the RBC logic
• triggering against absolute train position

[JakobGartner]

I thought the triggering was against LRBG + Distance?

If it is just LRBG: we sometimes have multiple message events with identical LRBG

On 16 Nov 2015, at 08:42, Johannes Kastner [email protected] wrote:

Please correct me if I'm wrong, but the triggering of radio messages is evaluated against the LRBG, isn't it? So widening the trigger window may not suffice, if we never receive a position report with the required LRBG (which might happen, if the position report is sent only every 30s).

We have two other options:

implementing a dynamic MA in the RBC logic
triggering against absolute train position
—
Reply to this email directly or view it on GitHub #915 (comment).

[jokaICS]

I thought the triggering was against LRBG + Distance?

You're right, I just was a little bit lazy when I typed the comment: it's LRBG+Distance

[BerndHekele]

The SRS makes sure you get a position report for every passed BG. In addition a timer is used and some other indicators like level change.

[BerndHekele]

This issue is still pending.
Any ideas on how to solve the issue?

[jokaICS]

I think we have three options to solve this issue:

1. widening the trigger window, as Jakob suggested
2. using the "scripted track" operator as is (meaning radio messages are triggered at absolute positions, not w.r.t reported distance from LRBG)
3. using a modified "scripted track" operator that triggers radio messages correctly according to distance from LRBG

Option 2) is currently implemented by the ROOT_Scripted operator (and it should work regardless of position report frequency)

[BerndHekele]

I see 2) as a default is no better solution is available.
Can we proceed on option 1)?
Is this correction part of the RBC-System

[jokaICS]

Is this correction part of the RBC-System

not the RBC-System itself; but the story wrapper needs adjustment (which is part of the RBC project).

On a different, but related topic: for US13-15 we probably need some means to dynamically trigger messages from the SimCtrl UI (e.g. a Msg18, or a new MA after it was shortened/ the train was tripped by Msg16)? We can inject messages dynamically in ROOT_Scripted; but for the standard test bench we need to add some mechanism to the standard track or the RBC-System? @JakobGartner

[BerndHekele]

I agree with your statement.
We also have the open issue to trigger a MA when the train is in standstill at the signal.
But I believe we are running out of time.

[BerndHekele]

I'm now having a run based on the use of the scripted track.
I got nealry stuck at position 4982 m (LRBG 42600362).
Rest of the track works fine.
Can we adjust this msg on the track?

[jokaICS]

I'm now having a run based on the use of the scripted track.
I got nealry stuck at position 4982 m (LRBG 42600362).

Just to be clear: did you get stuck with "ROOT_Simulation" or "ROOT_Scripted"?

[BerndHekele]

Issue needs to be addressed after ITEA project