Now That ATCS Is Mostly Gone

[ak7an]

All of the hardware is in place, they just need to "flip the switch"...

Union Pacific detectors are, as far as I know all running on Ritron analog radios, at least every one that I have seen and or worked on, so not sure of which switch I would flip to magically have the broadcast on NXDN. Even though we all have NX series mobiles and hand held converting every defect detector to NXDN would be a monumental task and expense. As you have so eloquently stated, the RR's love to spend money.., and thinking ahead goes about as fast as our system velocity these days. lol
Cheers
Ed
AK7AN

 

[burner50]

All of the hardware is in place, they just need to "flip the switch"...

Union Pacific detectors are, as far as I know all running on Ritron analog radios, at least every one that I have seen and or worked on, so not sure of which switch I would flip to magically have the broadcast on NXDN. Even though we all have NX series mobiles and hand held converting every defect detector to NXDN would be a monumental task and expense. As you have so eloquently stated, the RR's love to spend money.., and thinking ahead goes about as fast as our system velocity these days. lol
Cheers
Ed
AK7AN

Railroads would love nothing more than to get rid of TDD’s or at least make them not broadcast.

The really important ones could easily be tied into a signal system to hold signals ahead of protected structures then dispatch gets to see the notification.

Regardless I never worked in the signal department, but the maintainers I spoke with gave me the impression that the TDD’s were being upgraded. Perhaps that never happened before the mandate was dropped.

I don’t actually think that the railroads will ever actually switch to NXDN until they’re forced to, but most of the pieces are in place. Considering the number of NXDN radios that were already rolled out a few thousand TDD’s wouldn’t take much.

 

[kg6nlw]

I hope not either.. because SDRTrunk, which is what I'm planning to switch my feeds to next year as time permits, still doesn't support NXDN sadly.

You should use DSDPlus as it supports NXDN. I do believe SDRAngel does as well.

Regards,

-Frank C.

 

[RadioDitch]

Even though we all have NX series mobiles and hand held converting every defect detector to NXDN would be a monumental task and expense.

Already happening in Mexico.

 

[RugbyJunctionWI]

As of March 1st, 2025 in Wisconsin, ATCS Monitor has started "going dark" pretty fast. CPKC's Tomah Sub and part of the Watertown Sub have gone dark. Good portion's of CN's Neenah Sub and Superior Sub have gone dark. I live close to CN's Waukesha Subdivision and loath the day it goes dark.

A Proposed "Plan B" to ATCS Monitor...

On the CN Waukesha Subdivision in Wisconsin, the hot box detectors (HBD) announce:

• train direction
• hotbox detector milepost location
• number of axles
• defect info
• two messages... one at the head of the train and one one the train has passed

See Home - DefectDetector.net to find an HBD near you.

To me, hotbox detectors are our best-bet for creating a system of having some indication of where a train is. My plan, which I've already started working on, is to use real-time speech-to-text transcription software to listen to Broadcastify railroad channels and attempt to convert the "chatter" to a text log. For Broadcastify stations that can pick-up clear (i.e., low noise) HBD messages, transcription does a reasonably good job of converting the audio to text. Windows 11 has a (crumby) speech-to-text tool called Live Captions that transcribes input to the computer's microphone, of which I'm using VB-Audio's Virtual Audio Device app to pipe the Broadcastify stream from the web browser and into my PC's microphone.

The image below shows Live Captions listening to a local Broadcastify railroad channel. It's obviously doing a poor job of transcribing, but it's a start. "WAMX 4170" happens to be a Wisconsin & Southern heritage locomotive that is apparently in the area.



The advantage of speech-to-text transcription is that it can provide a text log of when an HBD was triggered (I'm working on a custom transcription app to add timestamps). This means that you no longer have to worry about missing an HBD broadcast or any radio chatter just because you stepped away from your radio for a minute... you can just look at the transcription log. Once the text exists, software can be written to listen for keywords like, "detector" and then create notifications to alert you that a train just went by a HBD that you care about... and when.

The biggest problem with this "Plan B" is getting a clean HBD feed so that the transcription software stands a fighting chance of being able to do it's job. Unfortunately, all of the Broadcastify feeds near me combine feeds from many railroads into the same feed, causing issues for transcription as there may be overlapping messages, causing a dirty transmission that difficult to transcribe. One can also use rail web cam feeds (like on YouTube) as the source of transcription, but almost all rail web cams also combine multiple audio feeds as well as ambient sounds near the camera, making transcription difficult.

My "dream" would be for railroad-specific and regional Broadcastify channels (with no ambient sounds) so one could transcribe the channel that is relevant to the track he or she might be standing by. In my case, I'd like a CN-specific feed so I didn't have to go trackside and sit there for hours, only to not see a train for hours because one wasn't coming.

 

[nickwilson159]

As of March 1st, 2025 in Wisconsin, ATCS Monitor has started "going dark" pretty fast. CPKC's Tomah Sub and part of the Watertown Sub have gone dark. Good portion's of CN's Neenah Sub and Superior Sub have gone dark. I live close to CN's Waukesha Subdivision and loath the day it goes dark.

A Proposed "Plan B" to ATCS Monitor...

On the CN Waukesha Subdivision in Wisconsin, the hot box detectors (HBD) announce:

• train direction
• hotbox detector milepost location
• number of axles
• defect info
• two messages... one at the head of the train and one one the train has passed

See Home - DefectDetector.net to find an HBD near you.

To me, hotbox detectors are our best-bet for creating a system of having some indication of where a train is. My plan, which I've already started working on, is to use real-time speech-to-text transcription software to listen to Broadcastify railroad channels and attempt to convert the "chatter" to a text log. For Broadcastify stations that can pick-up clear (i.e., low noise) HBD messages, transcription does a reasonably good job of converting the audio to text. Windows 11 has a (crumby) speech-to-text tool called Live Captions that transcribes input to the computer's microphone, of which I'm using VB-Audio's Virtual Audio Device app to pipe the Broadcastify stream from the web browser and into my PC's microphone.

The image below shows Live Captions listening to a local Broadcastify railroad channel. It's obviously doing a poor job of transcribing, but it's a start. "WAMX 4170" happens to be a Wisconsin & Southern heritage locomotive that is apparently in the area.

View attachment 179066

The advantage of speech-to-text transcription is that it can provide a text log of when an HBD was triggered (I'm working on a custom transcription app to add timestamps). This means that you no longer have to worry about missing an HBD broadcast or any radio chatter just because you stepped away from your radio for a minute... you can just look at the transcription log. Once the text exists, software can be written to listen for keywords like, "detector" and then create notifications to alert you that a train just went by a HBD that you care about... and when.

The biggest problem with this "Plan B" is getting a clean HBD feed so that the transcription software stands a fighting chance of being able to do it's job. Unfortunately, all of the Broadcastify feeds near me combine feeds from many railroads into the same feed, causing issues for transcription as there may be overlapping messages, causing a dirty transmission that difficult to transcribe. One can also use rail web cam feeds (like on YouTube) as the source of transcription, but almost all rail web cams also combine multiple audio feeds as well as ambient sounds near the camera, making transcription difficult.

My "dream" would be for railroad-specific and regional Broadcastify channels (with no ambient sounds) so one could transcribe the channel that is relevant to the track he or she might be standing by. In my case, I'd like a CN-specific feed so I didn't have to go trackside and sit there for hours, only to not see a train for hours because one wasn't coming.

Check your private messages. Myself and some others are actually in the planning stages for this very thing.

 

[wpku846]

" They are completely changing protocols from ATCS, which operates on 900MHz primarily and uses FSK data, to the ITCnet system used by PTC, which operates on 220MHz using Pi/4 DQPSK (think a very dumbed down version of wi-fi or cellular transmissions) It's an ENTIRELY different protocol."


It doesn't matter whether the protocol changed or not, the problem for us is the radio emissions are going to encrypted radio channels or fiber optic physical media.

Code line signaling will continue for the foreseeable future but will not be able to be monitored.

That's all I meant. I didn't say nor did I mean to imply the underlying technical details were identical.

The net result is the same: no more useful ATCS monitoring will be possible eventually.

The invective is unnecessary to make your point

"This feels like something J. David Aten would've written.. good god."

Yes going coded into ITCnet encripted for use with PTC . So break out those scanners or find a good broadcastify feed .

 

[TXLoganC]

As of March 1st, 2025 in Wisconsin, ATCS Monitor has started "going dark" pretty fast. CPKC's Tomah Sub and part of the Watertown Sub have gone dark. Good portion's of CN's Neenah Sub and Superior Sub have gone dark. I live close to CN's Waukesha Subdivision and loath the day it goes dark.

A Proposed "Plan B" to ATCS Monitor...

On the CN Waukesha Subdivision in Wisconsin, the hot box detectors (HBD) announce:

• train direction
• hotbox detector milepost location
• number of axles
• defect info
• two messages... one at the head of the train and one one the train has passed

See Home - DefectDetector.net to find an HBD near you.

To me, hotbox detectors are our best-bet for creating a system of having some indication of where a train is. My plan, which I've already started working on, is to use real-time speech-to-text transcription software to listen to Broadcastify railroad channels and attempt to convert the "chatter" to a text log. For Broadcastify stations that can pick-up clear (i.e., low noise) HBD messages, transcription does a reasonably good job of converting the audio to text. Windows 11 has a (crumby) speech-to-text tool called Live Captions that transcribes input to the computer's microphone, of which I'm using VB-Audio's Virtual Audio Device app to pipe the Broadcastify stream from the web browser and into my PC's microphone.

The image below shows Live Captions listening to a local Broadcastify railroad channel. It's obviously doing a poor job of transcribing, but it's a start. "WAMX 4170" happens to be a Wisconsin & Southern heritage locomotive that is apparently in the area.

View attachment 179066

The advantage of speech-to-text transcription is that it can provide a text log of when an HBD was triggered (I'm working on a custom transcription app to add timestamps). This means that you no longer have to worry about missing an HBD broadcast or any radio chatter just because you stepped away from your radio for a minute... you can just look at the transcription log. Once the text exists, software can be written to listen for keywords like, "detector" and then create notifications to alert you that a train just went by a HBD that you care about... and when.

The biggest problem with this "Plan B" is getting a clean HBD feed so that the transcription software stands a fighting chance of being able to do it's job. Unfortunately, all of the Broadcastify feeds near me combine feeds from many railroads into the same feed, causing issues for transcription as there may be overlapping messages, causing a dirty transmission that difficult to transcribe. One can also use rail web cam feeds (like on YouTube) as the source of transcription, but almost all rail web cams also combine multiple audio feeds as well as ambient sounds near the camera, making transcription difficult.

My "dream" would be for railroad-specific and regional Broadcastify channels (with no ambient sounds) so one could transcribe the channel that is relevant to the track he or she might be standing by. In my case, I'd like a CN-specific feed so I didn't have to go trackside and sit there for hours, only to not see a train for hours because one wasn't coming.

I think i saw ur app recently on atcs monitor group, im excited to see where it goes!

 

[atcsisgone]

The tried and true method of listening to the scanner and taking note of what you hear. Both the voice channels and EOT channels can provide useful information.

Until all those scanner channels are scrambled

 

[wa8pyr]

Until all those scanner channels are scrambled

There's a bit of encryption out there (the NS systemwide police channel, for example), but it's unlikely on a wide scale.

Encryption would hamper the ability to interchange and communicate unless every radio in North America uses the same encryption key (which in itself is unlikely as it would be a very quick way to compromise the encryption).

 

[RadioDitch]

There's a bit of encryption out there (the NS systemwide police channel, for example), but it's unlikely on a wide scale.

Encryption would hamper the ability to interchange and communicate unless every radio in North America uses the same encryption key (which in itself is unlikely as it would be a very quick way to compromise the encryption).

The AAR said a long time ago, and thus far has not changed it's position, that encryption is off the table for that very reason. It's impractical and not viable in this application.

And even if telemetry data (EOTD/HOTD/DPU) were ever to be obscured, the mere presence of a signal and it's strength would continue to serve the same purpose.

 

[Falcon9h]

Oh, and enjoy the "old way" while you can. Documents have shown the AAR is looking into a way to transmit voice over ITCnet or a similar broadband radio system as well. So, there's a pretty good chance radio comms as we know it will disappear one day too. Not anytime soon, but eventually.

That would really, really suck. Hope that doesn't happen till I'm out of here. Glad I'm old!

 

[TXLoganC]

As of March 1st, 2025 in Wisconsin, ATCS Monitor has started "going dark" pretty fast. CPKC's Tomah Sub and part of the Watertown Sub have gone dark. Good portion's of CN's Neenah Sub and Superior Sub have gone dark. I live close to CN's Waukesha Subdivision and loath the day it goes dark.

A Proposed "Plan B" to ATCS Monitor...

On the CN Waukesha Subdivision in Wisconsin, the hot box detectors (HBD) announce:

• train direction
• hotbox detector milepost location
• number of axles
• defect info
• two messages... one at the head of the train and one one the train has passed

See Home - DefectDetector.net to find an HBD near you.

To me, hotbox detectors are our best-bet for creating a system of having some indication of where a train is. My plan, which I've already started working on, is to use real-time speech-to-text transcription software to listen to Broadcastify railroad channels and attempt to convert the "chatter" to a text log. For Broadcastify stations that can pick-up clear (i.e., low noise) HBD messages, transcription does a reasonably good job of converting the audio to text. Windows 11 has a (crumby) speech-to-text tool called Live Captions that transcribes input to the computer's microphone, of which I'm using VB-Audio's Virtual Audio Device app to pipe the Broadcastify stream from the web browser and into my PC's microphone.

The image below shows Live Captions listening to a local Broadcastify railroad channel. It's obviously doing a poor job of transcribing, but it's a start. "WAMX 4170" happens to be a Wisconsin & Southern heritage locomotive that is apparently in the area.

View attachment 179066

The advantage of speech-to-text transcription is that it can provide a text log of when an HBD was triggered (I'm working on a custom transcription app to add timestamps). This means that you no longer have to worry about missing an HBD broadcast or any radio chatter just because you stepped away from your radio for a minute... you can just look at the transcription log. Once the text exists, software can be written to listen for keywords like, "detector" and then create notifications to alert you that a train just went by a HBD that you care about... and when.

The biggest problem with this "Plan B" is getting a clean HBD feed so that the transcription software stands a fighting chance of being able to do it's job. Unfortunately, all of the Broadcastify feeds near me combine feeds from many railroads into the same feed, causing issues for transcription as there may be overlapping messages, causing a dirty transmission that difficult to transcribe. One can also use rail web cam feeds (like on YouTube) as the source of transcription, but almost all rail web cams also combine multiple audio feeds as well as ambient sounds near the camera, making transcription difficult.

My "dream" would be for railroad-specific and regional Broadcastify channels (with no ambient sounds) so one could transcribe the channel that is relevant to the track he or she might be standing by. In my case, I'd like a CN-specific feed so I didn't have to go trackside and sit there for hours, only to not see a train for hours because one wasn't coming.

Has there been any progress on your application? I don’t see the post of it anywhere in atcsmon group.

 

[RugbyJunctionWI]

Has there been any progress on your application? I don’t see the post of it anywhere in atcsmon group.

I've stopped working on the transcription web app for now for a few reasons:

• The free browser-based transcription services (Microsoft and Google) are often down / unavailable for days at a time. I feel bad for people who are visually impaired and depend on these services as they're often broken.
• Transcription often gives different results for the exact same audio message. I'd play the same audio recording from DefectDetectors.net over and over and get different results each time.
• Transcription is often very inaccurate for certain words. For example, the transcription services do a horrible job at transcribing terms like "northbound" or "southbound". Instead, I get transcriptions like, "cow found" or "s bound". Without consistent transcription, any train detection app built-on top of the transcriptions would be highly unreliable.
• "False positives" are common. I.e., one day a particular defector was going off every few minutes, yet ATCS didn't show any occupancy in the same block. Turns out there was a long string of MoW vehicles heading north and every one set-off the detector. Granted, this info may still be of interest to some, but it wasn't a train.

While the transcription tool worked well-enough for me, there are now web cams facing all directions for the Class I railroads near me and thus my need of an ATCS alternative isn't quite as urgent. I am working on a different train detection app, but it won't be online anytime soon.

 

[TXLoganC]

I've stopped working on the transcription web app for now for a few reasons:

• The free browser-based transcription services (Microsoft and Google) are often down / unavailable for days at a time. I feel bad for people who are visually impaired and depend on these services as they're often broken.
• Transcription often gives different results for the exact same audio message. I'd play the same audio recording from DefectDetectors.net over and over and get different results each time.
• Transcription is often very inaccurate for certain words. For example, the transcription services do a horrible job at transcribing terms like "northbound" or "southbound". Instead, I get transcriptions like, "cow found" or "s bound". Without consistent transcription, any train detection app built-on top of the transcriptions would be highly unreliable.
• "False positives" are common. I.e., one day a particular defector was going off every few minutes, yet ATCS didn't show any occupancy in the same block. Turns out there was a long string of MoW vehicles heading north and every one set-off the detector. Granted, this info may still be of interest to some, but it wasn't a train.

While the transcription tool worked well-enough for me, there are now web cams facing all directions for the Class I railroads near me and thus my need of an ATCS alternative isn't quite as urgent. I am working on a different train detection app, but it won't be online anytime soon.

This is a stretch but could you send over what you have. I live in the Nashville TN area on the CSX Chattanooga Sub closest cameras to me would be south in Cowan, TN and nothing to the north since it splits off in the Nashville Terminal, For people in my situation it would be nice to have because on CSX the only thing we have is EOTD beeps to decode, defect detectors and crew chatter, ATCS was gone ages ago for us on these lines and now im seeing what i can do with the ptc data maybe buy old equipment (which would need programming)

 

[RugbyJunctionWI]

This is a stretch but could you send over what you have. I live in the Nashville TN area on the CSX Chattanooga Sub closest cameras to me would be south in Cowan, TN and nothing to the north since it splits off in the Nashville Terminal, For people in my situation it would be nice to have because on CSX the only thing we have is EOTD beeps to decode, defect detectors and crew chatter, ATCS was gone ages ago for us on these lines and now im seeing what i can do with the ptc data maybe buy old equipment (which would need programming)

This is the GitHub repo I started with:

GitHub - Somitraa/Voice-To-Text

Contribute to Somitraa/Voice-To-Text development by creating an account on GitHub.

github.com

If you install a virtual audio cable to pipe the sound from your web browser's audio output to your computer's microphone input, you can pretty much use the demo from the above repo to transcribe any audio sent over a web page.

 

[TXLoganC]

Check your private messages. Myself and some others are actually in the planning stages for this very thing.

What did yall plan out?

 

[nickwilson159]

What did yall plan out?

Not much to show for it just yet, but the idea is to train a Whisper library with defect detector clips for more accurate read-outs, then have them monitor the various Broadcastify feeds and pipe the information from detector readouts into a database. From there, this could be displayed on a map, send push notifications, users could subscribe to various lines and/or detectors, etc.

But until we can get a model trained, it’s kind of a moot point since current Whisper libraries don’t produce a reliable enough readout.