X7 S Class Spec

[Matthew Burdett]

Hi all

I hope you're well.

Does anyone have the pdf with addresses for the signalling elements on the X7 signalling area? 

Thanks, trying to make some sense of this S class stuff. I've got TD stuff coming through for my local area, converting the data from hex to binary (eg e3 to 11101000) but apart from seeing which bit changes for the same address I've got no idea where to go from there 🤣

It's all Greek to me.

[David Watkins]

 I can't really help I'm afraid except to offer some encouragement.  I recently did the same for the WS area near Euston and it's a bit mind scrambling.

My most effective strategy was to write a program to print out the binary values as they come in (e3 is 11100011 not 11101000 BTW)  with the relevant opentraintimes map alongside on the same screen.

Then I recorded the computer screen for a few hours and played it back to compare changes on the opentraintimes map with the data that had just come in.  ('Standing on the shoulders of giants' and all that ).

Hopefully you can find documentation for the area you want.

Good Luck.

[Matthew Burdett]

Thanks, sounds ok as X7 is quite a small route.

I've done the C class before and have done a map with moving trains but never the S stuff.

--
You received this message because you are subscribed to the Google Groups "A gathering place for the Open Rail Data community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openraildata-t...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openraildata-talk/CAJzO0N5X0MkFipMF63oXvxSExVGt2oCxU7HVA8EYy9rHddVZsA%40mail.gmail.com.

[QRail Comms]

And this highlights perfectly a gap which we had been working with NR to try and resolve (before everyone left) DOCUMENTATION... (Or rather the lack of.) This is also something that has been raised with the RDG with a view to hopefully having something via the RDM when it comes.

No one can make heads nor tales of the S-Class data without copies of the signal tables, route tables, block schematics, and in some cases plans (for things like track circuits) yet NR now refuse to publish *any* of that data under the 'excuse' of 'security'... As a result unless you have an existing commercial relationship or have other methods it is impossible to get access to the data that's needed to actually make use of the feeds. It also leave those with commercial agreements at an unfair advantage  over anyone else who stands (currently) no chance of access.

The irony is that TfL/RfLi released there full scheme plans, technical documents and all sorts of other documentation under FoI for the Cross Rail (Core) work. It's funny they didn't have any 'security' issues with the release yet NR just keep doubling down without offering any evidence or engagement on how to move forward.

As a community this is something we need to work out how to progress this... The entire mantra was supposed to encourage development, use and commercial gain through the open data project, yet the very people who encourage that now block all access to the material needed in order to use it...

To quote from the transparency site (https://www.networkrail.co.uk/who-we-are/transparency-and-ethics/transparency/open-data-feeds/network-rail-infrastructure-limited-data-feeds-licence/)

"Network Rail is freely releasing specific sets of its data here for developers and researchers to use in their software, services, and projects. We encourage the innovative use of these specific data feeds provided that it’s in compliance with the terms of the Open Government Licence."

And the open gov site also says (https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/)

"You are free to:
copy, publish, distribute and transmit the Information;
adapt the Information;  

exploit the Information commercially and non-commercially for example, by combining it with other Information, or by including it in your own product or application."

[Matthew Burdett]

Will maybe write a quick FOI or something and see what happens. 

To view this discussion on the web, visit https://groups.google.com/d/msgid/openraildata-talk/176e0522-db6f-42a2-86a6-cfaa1129f81cn%40googlegroups.com.

[QRail Comms]

It *Will* be blocked. There have been things going on in the background and NR are being very militant and are not releasing  any documentation under FoI so for the moment save your fingers...

[Russell Bowman]

I've a set of software that trundles through the TD data looking for the relationships between berth and signal events.  Since I work off recordings of the data it can look through a day's worth in a minute or so.  When it works it works and when it doesn't ... well you can finish that sentence.  I let it run through the X7 data from yesterday and the initial result fell into latter category.  When I've a moment I'll try it again as I might have the settings wrong and/or yesterday was Sunday so perhaps movements were rubbish or something else.  (Also I should look up where X7 'is'!)

Russell

[Matthew Burdett]

No problems, I think I understand it enough anyway to know what to look for. One of the bits will change for red/not red, that's all I'm after at this time. 

Getting a load of duplicate SF messages for some reason, sometimes 10 with the same timestamp...maybe my connections haven't closed properly...

To view this discussion on the web, visit https://groups.google.com/d/msgid/openraildata-talk/aa45c55d-11f1-4d4e-b3bb-0a5957a11fd7n%40googlegroups.com.

[Matthew Burdett]

X7 is Brighton to Ashford, plumpton to Ashford, Lewes to Seaford, unless the Ashford part falls under AD.

Imagine it's quite new as there's no pdf document linked on the wiki.

To view this discussion on the web, visit https://groups.google.com/d/msgid/openraildata-talk/41b73334-4332-4336-8576-f57b86cef6b5n%40googlegroups.com.

[Adrian Bradshaw]

We do something similar - log S and C class data and try to work-out the relationships in a semi-manual fashion. It's beyond me, but a couple of our volunteers have enough knowledge of signalling to make sense of it (mostly). It's a long laborious task which could be avoided if the information were to be published.

Adrian

---

Adrian Bradshaw – Director

Railcam UK Limited

@: adr...@railcam.uk

Railcam.uk – Bringing The Lineside To Your Armchair

Railcam UK Limited | Registered in England and Wales | registration number 10167844

Thomas House | Meadowcroft Business Park | Pope Lane | Whitestake | Preston | PR4 4AZ

-------- Original Message --------

Subject:	Re: [openraildata-talk] X7 S Class Spec
Date:	2023-07-17 14:50
From:	Russell Bowman <russell....@gmail.com>
To:	A gathering place for the Open Rail Data community <openrail...@googlegroups.com>

To view this discussion on the web, visit https://groups.google.com/d/msgid/openraildata-talk/41b73334-4332-4336-8576-f57b86cef6b5n%40googlegroups.com.

[Tom Cairns]

I think it’s a little bit of a stretch to suggest that no-one can make anything of the S class data without the SOPs or ECS, as there have been some very successful attempts to do that and the wiki has quite a few areas documented with user sourced decoding. I think Phil Wieland did some very good work in this area for one (and while I’ve been writing this I note others have also said as such!)

 

I am going to talk purely from a technical perspective as I do not wish to get involved in the politics around this. One of the challenges involved with releasing the tables is that there is no one size fits all solution to all signalling areas. I can think of, off the top of my head, at least five or six different formats that S class decoding tables can be distributed in: some are machine readable, some are PDFs that can be easily copied out of (or OCR) and some that have been printed and scanned in. There also isn’t really a centralised repository of all of this – Peter has stated that before on this group.

 

Doing work inside the industry around this data has been extremely painful sometimes and I think it would be fair to say that we sometimes deliberately shy away of certain areas due to how much of a challenge they can be. I think there’s enough data out in the open already that it could be worked out which ones they are…

 

In any case, I know of at least of three different active, or very recently finished, projects across the industry in the area of further liberalising railway understanding and data – and this includes the set of S class decoding tables. There are members of this group who are involved in these. These feel like they’re making a significant amount more progress than we’ve seen before but it is all a little way off and subject, as ever, to funding. A lot of the parties involved with it were, however, from the very early days of the open data world so there is a level of commitment there.

 

A lot of the open data we now have comes as a by-product of industry requirements and need. At the moment a lot of S class decoding datasets are held by individual suppliers and they understandably would rather keep it under lock and key due to the investment that is placed into getting it collated. There is definitely an increasing awareness in NR outside of the transparency sphere and others of the need to own a set of this data. That will unlock the key.

 

Tom

 

 

From: openrail...@googlegroups.com <openrail...@googlegroups.com> On Behalf Of QRail Comms
Sent: Monday, July 17, 2023 2:36 PM
To: A gathering place for the Open Rail Data community <openrail...@googlegroups.com>
Subject: Re: [openraildata-talk] X7 S Class Spec

 

And this highlights perfectly a gap which we had been working with NR to try and resolve (before everyone left) DOCUMENTATION... (Or rather the lack of.) This is also something that has been raised with the RDG with a view to hopefully having something via the RDM when it comes.

To view this discussion on the web, visit https://groups.google.com/d/msgid/openraildata-talk/176e0522-db6f-42a2-86a6-cfaa1129f81cn%40googlegroups.com.

[Matthew Burdett]

Thanks Tom. I agree more data to work with would be good. I'll probably just watch OTT or something on a signal by signal basis and see what comes in through the feed. 

Did a few signal maps albeit class C only a few years ago, but I was never happy with the layout. Only bothering with my local line as I don't have time to produce maps for everywhere.

To view this discussion on the web, visit https://groups.google.com/d/msgid/openraildata-talk/PRAPR02MB7858F7BA7862C2BB25F3DCC8E73BA%40PRAPR02MB7858.eurprd02.prod.outlook.com.

[QRail Comms]

Attempts do not help build something that is accurate and there in lies the problem... Yes people like Phil have done a lot of work to try and decode things, but I see lots of gaps and errors still. I note others have contributed other data (all gleaned from other accurate sources) but that has dried up now as well.

There was a single source of current and up coming changes but all that has been withdrawn now to everyone beside the special few, and that worked fine (granted it wouldn't help with anything existing) until someone started rocking the boat causing NR to take a deeper look into things.

Yes having things in a nice defined format would be excellent, but frankly a SOP/ECS in any format is better than none. Maybe we should run a quiz; identify a specific bit on a TD, or locate a track circuit on a layout. lol

[Peter Hicks]

Having spent most of the last decade trying to get a consolidated set of TD reference data together, I can categorically say that it's very difficult.  Knowing what maps where is one thing, but then you need to know where that thing is, and where it is in relation to other things.  And then you need change management surrounding updates, and a versioned set of data.  Check RSSB's T1246 project - Development of a Sustainable Berth to Signal Mapping - I've commented on a bunch of these things at the end of the report.

When you say 'special few' (and you probably need to review your language, because it makes you sound bitter rather than putting up a fair argument), I think you mean 'bona fide system integrators and industry partners'.  Giving those parties access to information on what's changing, rough and ready as though it may be at times, is far less risky than having an email from somebody with a generic role-based GMail account, who could be anyone.  In response to your point about the Crossrail Core signalling plans and train describer interface specifications being FOI'd... different organisations will have different risk profiles.

Remember: FOI releases are to the world at large, and once you've released more than you should have, it's impossible to get it back.  Ask the company who had all of its recorded announcements leaked on a WDTK page.

Peter

To view this discussion on the web, visit https://groups.google.com/d/msgid/openraildata-talk/fb9483b3-d5f9-446b-b6cc-683c9a53afb4n%40googlegroups.com.

[Matthew Burdett]

I'm guessing signal STLW5, address 54, has packed up somehow as it is showing red on opentraintimes maps permanently and I can't see any changes on the bits when a train passes this signal.

Other than this thanks for the help I've got several signals working.

To view this discussion on the web, visit https://groups.google.com/d/msgid/openraildata-talk/CAKGkhzZ98Snzq40%2BOSEY9KAFQsX4L9Ha%3DOYq4i5o%3DP%3Di%2BTsotA%40mail.gmail.com.

[Matthew B]

Hi

Sorry to bump an old message, I just wanted to clarify something. I am converting the data part of S class SF message to base 2, 8 bits (eg 11110000 ) but when I compare the bit changes to the SOP published on the WIki (eg TB three bridges), the bit string actually needs reversing, so this would be 00001111). Is this to be expected?

For example in the Wiki for area TB, is: TB2E:3 -> R368A

But when the route is set for 368A its actually position 4 in my string that turns to 1, not position 3.

Maybe i'm overcomplicating things, when I worked out the X7 in 2023 I have all my recordings the reverse way round compared to the mappings on the Wiki. 

Just starting to play around with this again.

Kind Regards

[Peter Hicks]

Hello

On Wednesday, 19 November 2025 at 15:23, Matthew B <matthewbu...@gmail.com> wrote:

Sorry to bump an old message, I just wanted to clarify something. I am converting the data part of S class SF message to base 2, 8 bits (eg 11110000 ) but when I compare the bit changes to the SOP published on the WIki (eg TB three bridges), the bit string actually needs reversing, so this would be 00001111). Is this to be expected?

For example in the Wiki for area TB, is: TB2E:3 -> R368A

But when the route is set for 368A its actually position 4 in my string that turns to 1, not position 3.

There are no guarantees as to whether the reverse-engineered data on the wiki is correct, up-to-date, or is MSB or LSB ordered.  You might even find that some data is MSB-first and some is LSB-first.

Peter

[Jonnyboi]

Sorry for the delay, Hope this helps 

thanks Jon