End of Mission: Radio Message not received at the EVC

[BerndHekele]

After changing from Level 2 to level ntc the radio message to disconnet from Radio is not seen.

[Rainer-Lampatzer]

Sorry, I cannot replicate this. Due to a segmentation fault in the testbench, I can not drive until the point where the error occurs.

Even if this segmentation fault would not occur, it is time consuming to run the whole line for test of this feature only. For a quicker way to find the error a slightly modified track file would be helpful. This track file should have the fallback to NTC as early as possible, but not before pos. 4000.

Thanks a lot in advance for helping me and contributing to a quicker result.

[Rainer-Lampatzer]

I suggest to move (and rename) balise group 443 to the place of balise group 360 in the new track file. Thanks a lot in advance.

[JakobGartner]

I disagree

We have the hard requirement to use the original track topology with the original engineering . Only for additional scenarios (13-16) we can be creative

However for demo economics we are using the original layout even there and will overlay the track with the US scenarios.

Mairamou and I are however working on modularising the track so that the different US can be looked at independently from each other

On 14.11.2015, at 02:10, Rainer Lampatzer notifications@github.com wrote:

I suggest to move (and rename) balise group 443 to the place of balise group 360 in the new track file. Thanks a lot in advance.

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

[BerndHekele]

I plan to repeat this test anyway. I will provide sufficient symptoms to solve the issue.

[Rainer-Lampatzer]

@JakobGartner I do not intend to change the demo. I only need this for testing. Otherwise I have no way to analyze the problem as I can not replicate it.

We have the hard requirement to use the original track topology with the original engineering . Only for additional scenarios (13-16) we can be creative

I suggest to move (and rename) balise group 443 to the place of balise group 360 in the new track file. Thanks a lot in advance.

[JakobGartner]

Ok

Then I think this will be covered by the modular track version

On 15.11.2015, at 09:02, Rainer Lampatzer notifications@github.com wrote:

@JakobGartner I only need this for testing Otherwise I have no way to analyze the problem as I can not replicate it.

We have the hard requirement to use the original track topology with the original engineering . Only for additional scenarios (13-16) we can be creative

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

[Rainer-Lampatzer]

Thank U Where can I find the modular track version?

[JakobGartner]

@Mairamou is working on it

On 15.11.2015, at 10:07, Rainer Lampatzer notifications@github.com wrote:

Thank U Where can I find the modular track version?

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

[BerndHekele]

Here are some screenshots when the last 136 message is received at the RBC-System:

Next layer (ping):

[Rainer-Lampatzer]

Hi Bernd,

thank you for helping me.

According to the first picture, the session termination request (Msg 24 with packet 42) is sent. Afterwards the flag is reset in order not to send this twice.

If it is lost on the way or inside the EVC, then I can change the logics so that the session termination request is repeated UNTIL the session has really been terminated.

I will start tomorrow in the late morning, so you still have time to decide.

I wish you a nice Sunday.

Rainer

[BerndHekele]

Dear Rainer, the trigger is not sent in this scenario. (trigger = false) The message is not triggered. As I see the problem the RBC needs to evaluate the valid flag og the packet which is part of the input.

[Rainer-Lampatzer]

Dear Bernd

thank you.

If it is lost on the way or inside the EVC, then I can change the logics so that the session termination request is repeated UNTIL the session has really been terminated.

I did not implement this because nobody required. I introduced a force trigger instead.

Rainer

[BerndHekele]

Dear Rainer, can you please tell me which model part is sending the trigger - just to see where the trigger shall come to live.

cu Bernd

[Rainer-Lampatzer]

Hallo Bernd,

Im Fall einer EoM:

1. OBU sendet "End of Mission" (Msg 150)
2. RBC sendet "Session Management - Termination Request" (Msg 24 + Pkt 42)
3. OBU sendet "Termination" (Msg 156)
4. RBC sendet "Termination Acknowledgement" (Msg 39)

Ansonsten kann auch RBC selbst den Verbindungsabbruch initiieren und fängt mit 2. an.

VG, Rainer

[BerndHekele]

@Rainer-Lampatzer According to our user story the event is triggered by MSG 136 (Position Report with NTC information). What makes you think about the Msg 150 as a start?

[Rainer-Lampatzer]

There is an "End of Mission " procedure that triggers the session termination by closing the desk.

The user story that terminates the sessioin in casre of level NTC is not covered by the SRS. Nevertheless I started implementing it.

According to the meeting of yesterday, the priority of this feature has been reduced in order to make new RBC messages for US13..15 first.

What about the "modular track"?

[Rainer-Lampatzer]

RBC sends Packet 42, but EVC does not answer with a Msg 156. In case the packet is expected with other values please inform me.

MSG 24 @32078.5 m nid_message: 24 t_train: 1519800 m_ack: 0 nid_lrbg: 351 t_train_ref: 0 nid_em: 0 q_scale: 0 d_sr: 0 t_sh_rqst: 0 d_ref: 0 q_dir: 0 m_version: 15

0) Pkt042 nid_packet: 42 q_dir: 1 q_rbc: 0 nid_c: 426 nid_rbc: 16383 nid_radio: 500 q_sleepsession: 0

[BerndHekele]

A correction in the position report (LRBG) solved the problem. Solution is tested.