Not MA after ~26934m?

[jokaICS]

I'm currently stuck at ~27km (resticted to 14 kph); possibly due to a missing MA?. Here are the last few targets as calculated by SDM:

Can anybody confirm this issue?

BTW: why does the target type toggle repeatedly between EoA and SvL at ~26850m? @T12z

[JakobGartner]

which track? nominal or “modular” ?

On 18 Nov 2015, at 17:10, Johannes Kastner notifications@github.com wrote:

I'm currently stuck at ~27km (resticted to 14 kph); possibly due to a missing MA?. Here are the last few targets as calculated by SDM:

https://cloud.githubusercontent.com/assets/13429700/11246178/dba04986-8e16-11e5-9789-213ec1031086.png Can anybody confirm this issue?

BTW: why does the target type toggle repeatedly between EoA and SvL at ~26850m?

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/924.

[jokaICS]

Sorry for the incomplete bug report: nominal.

[T12z]

this EoA/SvL toggling is same strange behaviour as I just noticed in #919 The SvL is always double the distance of EoA :confused: and it happend at 4,9 km as well Is there some issue with incomplete messages??

[T12z]

sooo, had look into the SDM code (not running), the doubling is easy explained, I add MA::d_DP_or_OL onto the end-section's location. I know we (Jakob+me) talked about having all locations absolute, so that would be my fault, still taking it as an offset. In this case, this is actually no offset at all - which is totally valid! @JakobGartner I fix this interface-issue by removing the add-operator and pass the value as is absolute. Why on earth .q_overlap or .q_dangerpoint is toggling (which is the only reason for the toggling after all), is another issue. Mind you, EoA and SvL (aka DP/OL) are calculated differently, even if on the same location. So this is still a bug.

[JakobGartner]

yes I confirm.

all locations are absolute

and on our track the offset between end section location and dp is 0

On 18 Nov 2015, at 22:09, Thorsten Schulz notifications@github.com wrote:

sooo, had look into the SDM code (not running), the doubling is easy explained, I add MA::d_DP_or_OL onto the end-section's location. I know we (Jakob+me) talked about having all locations absolute, so that would be my fault, still taking it as an offset. In this case, this is actually no offset at all - which is totally valid! @JakobGartner https://github.com/JakobGartner I fix this interface-issue by removing the add-operator and pass the value as is absolute. Why on earth .q_overlap or .q_dangerpoint is toggling (which is the only reason for the toggling after all), is another issue. Mind you, EoA and SvL (aka DP/OL) are calculated differently, even if on the same location. So this is still a bug.

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/924#issuecomment-157864039.

[T12z]

thanks, so, is the DP always valid? In that case a switching between EoA and SvL before reaching it can happen, due to the different calculation algorithms ... I will upload the anti-doubling fix in a minute ...

[T12z]

I can answer that myself, yes. Even if it was not a valid DP, then the EoA is always the SvL / DP :dizzy_face:

[JakobGartner]

if I remember right, the DP is always valid but with a distance = 0 (it seems it is only there to define a release-speed via national values)

the OL is always invalid

On 18 Nov 2015, at 22:18, Thorsten Schulz notifications@github.com wrote:

thanks, so, is the DP always valid? In that case a switching between EoA and SvL before reaching it can happen, due to the different calculation algorithms ... I will upload the anti-doubling fix in a minute ...

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/924#issuecomment-157866316.

[jokaICS]

The changes to SDM partially mitigated the EoA/SvL toggling. However, the MA problem remains: the MA sent by the RBC @ 22756m (~100m beyond BG416) seems to be ignored by the EVC:

Maybe this is due to linking errors? I don't know where to look to identify these issues...

[JakobGartner]

As just discussed with Bernd,

no changes pushed from TrackAtlas since about 4 weeks

We will look fir discrepancies on the track

This may be linked to the bad data introduced by the bogus BG (“0”) we found and transcribed from the JRU data (where also the link distance was not fitting the rest of the data and which was not present in the different packets covering the same area

On 19 Nov 2015, at 09:29, Johannes Kastner notifications@github.com wrote:

The changes to SDM partially mitigated the EoA/SvL toggling. However, the MA problem remains: the MA sent by the RBC @ 22756m (~100m beyond BG416) seems to be ignored by the EVC: https://cloud.githubusercontent.com/assets/13429700/11265825/ced7487e-8e9f-11e5-8787-bc4713ca4bb0.png Maybe this is due to linking errors? I don't know where to look to identify these issues...

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/924#issuecomment-157988079.

[jokaICS]

The latest updates didn't solve the problem. The MA sent (and acknowledged) 100m after BG416 does not take effect.

[BerndHekele]

This error is also visible in the new build. Last Msg 3 is sent at m 22752

We see the EB - this implies we have EOA reached. Unfortunately, no SDM input in Debug window due to optimisation. We see the reference of the Message is also passed already - may we have a problem caused by a wrong reference point.

I will provide more symptoms tomorrow.

[BerndHekele]

@JakobGartner Update to this issue: We have an track error here: the direction of the packets 15 and 21 is wrong in this place.

Can you please check with the original JRU and update the packets accordingly?

[JakobGartner]

Ok

Sent from my iPhone

On 20.11.2015, at 13:23, Bernd Hekele notifications@github.com wrote:

@JakobGartner Update to this issue: We have an track error here: the direction of the packets 15 and 21 is wrong in this place.

Can you please check with the original JRU and update the packets accordingly?

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

[BerndHekele]

I see a similar picture in the trackviewer for other LRBGs: LRBG 426: LRBG 431:

I will provide quick-fixes for these problems.

[BerndHekele]

I jusr pushed corrections for the track. @jokaICS Can you please update the track for the viewer as well? Thanks.

kr Bernd

[jokaICS]

done.

[T12z]

@jokaICS please close if finished

[jokaICS]

Solved.