Skip to main content

You may have seen the posts about my Remote Train Control (RTC) program that I wrote which lets me control my MTH engines from my PC.

 

The limitation of that program has been that it required a wired RS-232 connection between the PC and TIU. This wired connection meant that the PC could only control one TIU (there were work-arounds to get past this) and when the PC was communicating with the TIU, other Remotes were locked out.

 

I've now been able to figure out a solution to this by working out a method to connect the PC to TIU over a radio just like the Remote.

 

I've been working on understanding the interface between the Remote and TIU for several years. I started with the work done by Mike Hewett in about 2011. He investigated the wired connection (using a phone handset cord) between the two. He figured out a lot of the interface. It was RS-232 (using 0v and 3.3v levels). It was 9600 baud, 8 data bits, no parity, 1 stop bit. He could  see command packets going between the Remote the TIU. He wrote software to capture those packets, store them on a PC and send them to the TIU on request.

I took the work that Mike did and expanded on it. I developed a better understanding of the command packet from the Remote and the response packet from the TIU. I put all that I learned into a program called Remote Train Control.

I was still using a wired connection between the PC the TIU. I thought that I could figure out how the radio connection worked.

Searches on Google developed a few leads:

1. Frequency requests to the FCC for Hand Held RF module and for Base RF module:

https://fccid.io/OT8RFMR#axzz3RPE7qRYL
https://fccid.io/OT8RFMT#axzz3RPE7qRYL

This showed that the Remote transmitted on  916.5 MHz and the TIU transmitted on 905.8 MHz

2. This I found this post on an SDR web site:

SDR-noob needs help. Want to decode 9600bps OOK signal at 905.8MHz.

submitted 17 Nov 2014 by playaspec

Hi all. I've been trying to reverse engineer the protocol used by a toy train with little luck. Through a great deal of digging through Google, I've discovered that the remote and the base communicate at 905.8MHz, using OOK at 9600bps. I would like to snoop this protocol to bring the train under computer control. Can anyone lend a hand?

If I've left out any key information, just ask! Thanks for taking a look.

The radio chip in the receiver (and I assume the transmitter) is a TI TRF6901


He never got any responses, except from me, and could not add to his comment. I don't know if he ever got to a solution.

But at least, if he was right, I could search for OOK and the TRF6901.

3. On the TI web page, the device was listed as "NRND" - TI speak for "Not Recommended for New Designs". I downloaded the data sheet and saw that the chip supported FSK (Frequency Shift Keying) and OOK. So the Remote and TIU probably spoke either FSK or OOK. I found this article: "I'm OOK, You're OOK?" from Maxim. Another bit hint was the comment on the TI TRF6901 web page that stated:  "Replaced by CC1101".

4. I needed to find out if anyone sold a radio board using the TRF6901. Searching the Internet turned up nothing.

5. Since the TRF6901 was obsolete, maybe the CC1101 could be used. The data sheet said that it could do OOK. It was worth investigating.

6. Now did anyone make a board using the CC1101? I found Erwan's Blog which talks about connecting a CC1101 to an Arduino. Then I found the panStamp web site and product called the "panStamp AVR 1". Exactly what I needed, an Atmega328p MCU and CC1101 on a small circuit board along with a carrier board containing a USB port for a PC. I've used the Atmega328p MCU in other projects so I was familiar with it. Easily covers the two frequencies I needed to cover. I ordered one. Took about 2 months to get it from Spain - I didn't get the expedited shipping. Next time, pay for the faster shipping.

7. The Atmega328p MCU is programmed using the standard Arduino IDE and board files from panStamp. Their web page shows you everything you need to know about installing the IDE with panStamp support. I learned that panStamp supported the CC1101 using only a protocol called "SWAP". A very complex high level protocol. For most users it is the best choice - as long as the radio on the other end of your connection is speaking SWAP. I needed to be speaking OOK.

8. I learned how to program the CC1101 from scratch. I searched the Internet and got little bits of help. Months of digging through the CC1101 data sheet and test code for the Atmega328p MCU finally led me to a working receiver. Then a working transmitter. I wrote a program based on the example program "modem.ino". I could communicate between the PC and the TIU with my Remote Train Control program. (note: this paragraph took about 5 months actual work.)

9. To program the CC1101, I took the code written by the panStamp developers that supports SWAP, deleted all of the SWAP routines and added routines to implement OOK.

 

That was the good news, here is the bad news: the panStamp AVR 1 is no longer available. Their web page promises that there is going to be a panStamp AVR 2 soon. Maybe in September.

 

As with the RTC program, once I port this OOK code to the panStamp AVR 2. I will give the code to anyone who wants to try it.

 

A video and other information on my web page:  http://www.silogic.com/trains/...Radio%20Support.html

 

Mark

Original Post

Replies sorted oldest to newest

 I'm not sure if you want replies here?

I love this program and it has helped not only run the trains better, but also it has helped in troubleshooting DCS bugs or problems.

 My G scale wouldn't load new engines into the remote outside. This program ran them fine. So it helped eliminate things and speed up the process telling me where to look. It also helps me make sure engines run without the hastle of loading them into my remote which is near full. The program will run the engine by it's address stored on it's board. The read function finds them easily. I have yet to see the dreaded error messages. ( I did once, when the TIU was left unplugged from the computer by accident.)

 The fact that you can go radio now, is a big deal to me! I can only say thank you! I look forward to more progress on this program that already is running very well for me.

I've built a small demonstration control that I call the Retro Transformer. It uses a panStamp radio board in a box with a few switches, pushbutton, and a potentiometer. The switches cause the panStamp to send simple "transformer" operations to an engine (via the TIU) over the radio.

 

There is a video and short description on my web page:

 

http://www.silogic.com/trains/...Radio%20Support.html

 

Mark

I've been working on my radio interface and now have two different implementations.

I had previously written about my panStamp version which uses an Arduino like design along with a TI CC1101 radio chip.

I've have a different implementation now that uses an actual Arduino (I used a Uno) and the CC1101 chip on a small board designed and built by a company called ElecHouse.

The panStamp implentation is nice because of its small form factor and its low current draw (can run off of 2 AA batteries).

The Arduino Uno implentation is nice because now you can use all of the Arduino shields and many great libraries.

 

http://www.silogic.com/trains/...ol%20%28radio%29.pdf
http://www.silogic.com/trains/OOK_Radio_Support.html

Also, I've finally posted my write up that discusses the protocol in detail. Some of you have already seen it but now its out there for everyone to read.

 

http://www.silogic.com/trains/...tream%20Decoding.pdf
http://www.silogic.com/trains/RTC_Running.html

For sometime now, I've had version 3.1 of the RTC Program available for download from the RTC Running web page.

http://www.silogic.com/trains/...ng.html#RTC_Download

All of my programs are covered by the GNU General Public License and the documentation is covered by the GNU Free Documentation License. They all remain (C)opyright by Mark DiVecchio.

Last edited by SanDiegoMark

One of the barriers to using the RTC program with a radio is the soldering involved in putting the radio together and the programming involved with compiling the RTCModem program for downloading into the radio.

Now panStamp sells a complete, assembled version of the AVR2.

I ordered several and I have ported my RTCModem code to run on it.

From the panStamp store, you need to order a few  items (you can use the links):

1.  "panStick 4.0" module and SMA connector assembed with option (very important) "panStamp AVR2 @  902-928 MHz"   PS0002.  panStamp supplies these components assembled and tested.  Now there is NO soldering necessary.
2.  "SMA articulated antenna" AN0003 
3.  If you want to get fancy, you can order a small plastic box "Enclosure for mini-carrier boards" EN0005

You will need a USB cable (USB A Male to USB Micro B) to connect the board to your computer.

Here is a photo of the radio as you can order it from panStamp.

panStamp AVR2 with panStick 4.0 & SMA connector - assembled

Once you get the radio, I have worked out a small program which can directly download the compiled version of RTCModem into the panStamp.  You can find that program "XLoader" along with instructions at this link: http://www.silogic.com/trains/...Support.html#XLoader .

Attachments

Images (1)
  • panStamp AVR2 with panStick 4.0 & SMA connector - assembled: panStamp based radio for use with RTC
Last edited by SanDiegoMark

Home grown WIFI versus the MTH next generation APP?

Suggestion:  Wait for the MTH next generation APP to see what the full implementaion of DCS looks like.

Although I have the current MTH WI FI system my preference would be a next generation TIU that includes WIFI.

Since I use DCS Passive Mode I would be interested in a downsized version of the WIFI compatible TIU that does NOT include TIU input channels.

 

My radio was first implemented on a panStamp which is ATMega328 based. I then ported the code base to a standard ATMega328 Arduino board (the Infiduino which runs at 3.3v). This opened up a world of possibilities of what could be done using this non-PC based and battery operated approach.

I had developed a Retro Transformer - a standalone box containing a panStamp radio. This little box could control the main functions of MTH engines (startup/shutdown, speed, direction, horn and bell).

Another developer, Ray, used this same approach but he built up a Retro Transformer using an Infiduino and an Elechouse CC1101 radio. He sent me a video which I put on my web page:

http://www.silogic.com/trains/...dio_Support.html#Ray

It amazes me that some of you out there can do this stuff, my hat is off to you all. I thank you for posting it here and making it available for us to learn from (or at least try to). I have a lot of things I would like to do, but I am not sure I have the capabilities for some of them and this would certainly be one (way over my head here). Anyway, I really enjoy reading about it and following your work. Please keep it up, I will be lurking and trying to take in as much as I can.

Version 3.16 of the RTC program is available on my page. Major new addition is the support for Routes and Scenes. You can get it at:

http://www.silogic.com/trains/...ng.html#RTC_Download

 

Release notes:

1. I added a Super TIU mode selection on the setup window. This is my best guess at how it works but it remains largely untested because my layout doesn't need it. Feedback appreciated. Debug Mode only. If you don't know to get into Debug Mode, contact me.  I'll move this out of Debug mode once a few people use it.

2. I did some more testing and fixups on the code which allows the use of Engine #0 - the factory reset engine. You can control, rename and renumber factory reset engines. Debug Mode only. If you don't know to get into Debug Mode, contact me. I'll move this out of Debug mode once a few people use it.

3. I added the ability to create Routes and Scenes. They are not separate things as in the Remote but can contain both switches and accessories. Up to 256 can be created. Each can contain an unlimited number of switches and accessories (although only 500 (250 switches and 250 accessories) can be connected to the maximum 5 AIU on 5 TIU). They can be "Activated" to presets or "Reset" to defaults. Unlike the remote, you set an accessory to turn off when a Scene is activated.

The Route/Scene windows works in a similar manner to the LashUp Window.

Right Click on the Route/Scene window for Help.

4. I cleaned up the operation of the AIU Control window. Now double clicking on an accessory or switch will toggle the state of that device. The state is now shown with a cute Icon rather than works.

5. Added "All" Accessory and Switch operation to the AIU Control Screen. Turns On/Off all accessories connected to the TIU or sets all switches connected to the TIU to straight/diverge. ALL switches and accessories connected all AIU connected to the selected TIU. Debug Mode only. If you don't know to get into Debug Mode, contact me. I'll move this out of Debug mode once a few people use it.


Mark

I've setup a mailing list for anyone interested in the Remote Train Control [RTC] program.

I'm going to use that mailing list to send updates on the program's status and to have users field and answer questions.

Recently on that list, I announced that v3.17 was released (right on the heels of v3.16) to fix a visual problem with the Engine List.

If you would like to subscribe to that list, send an empty email to
remote-train-control+subscribe@googlegroups.com

To just visit the group to read the messages, click here:
https://groups.google.com/group/remote-train-control

I've released a new version of the RTC program on my web page:

http://www.silogic.com/trains/...ng.html#RTC_Download

v0.0.3.18 AKA v0.3.18.0

0. I changed the version numbering scheme because I find that I am
sending out RTC to my alpha testers between releases. I need a way to distinquish
these. This would have been v3.18 but I just moved the numbers one position
to the left. So this is version 3.18.0. I will use the last digit position
for intermediate releases.

1. On the Operations screen, the Boost and Brake buttons will increment/decrement
the speed by 1 Smph if clicked. If held down, they will increment/decrement the
speed by 1 Smph every second. I also made them a little larger so my aim on my
touchscreen did not need to be so precise.

2. I spent the last week finally digging into the way that Engines report which
hotkeys that they respond to. In response to an Interrogate command, the Engine
reports back 80 bytes of data. 26 of those bytes indicate hotkeys based on bit position
where there is a '1' bit. I was able, using the RTCEngineE Arduino program, to set
all of those bits to '1' and feed them to a Remote. The Remote then listed all
of the hotkeys when I pressed the "S4"/"more" button. I've been able to detect 70
hotkeys and the exact bit in the Interrogate command response that causes
that hotkey to be displayed by the Remote. Once I could do that, I could just
press the hotkey on the Remote and watch (again using RTCEngineE) exactly
what command the Remote sent for that hotkey function.

Using what I learned, I modified the Operations and Sound Control Windows to
show only controls for hotkey functions that are actually supported for each
engine. So if the engine does not support the Crossing Signal, for example, that button
will not appear in the window.

This includes switches and buttons on the Operations Window for:
    Firebox Glow (LFB)
    Headlight (something different than the HDLT button on the Remote)
    Mars Light (LMA)
    Ditch Lights (LDI)
    Interior Light (LIN)
    Marker Lights (LMK)
    Beacon Light (LBE)
    Number Boards (LNB)
    Running Lights (LRL)
    Track Inspection Lights (LTI)
    Auxiliary Lights 1 (LA1)
    Auxiliary Lights 2 (LA2)
    Auxiliary Lights 3 (LA3)
    Crossing Signal (SXS)
    Pantograph Menu (MOP)


And on the Sound Control Window for:
    Coors Delivery (Start/Stop/Doors Open/Doors Close) (CDS, CDO, CDC)
    Boiler Startup/Release
    Train Wreck (STW)
    Coupler Slack (SCS)
    Coupler Close (SCC)

If you want to understand the gruelling details of the hotkey encoding,
on my web page, look for the file "Command ('Ixxx') Response.xls". I haven't
completed this yet. Some of the hotkeys, like Engine and Idle Sounds,
are not used by RTC so I haven't yet determined their exact bit position.
I'll do it when I need it.

I'd appreciate feedback on how well this works. If you look at the hotkeys
on a Remote, RTC should show the same set of hotkeys from the list above.
Remember though, I don't have hotkeys for Engine Sounds or Idle Sounds and
other hotkey functions are handled in the background by RTC.

RTC does not handle Doppler or Trolley functions. RTC does not yet handle
the quillable whistle but I know the hotkey commands to do it. Let me know if
you have an engine with such a whistle.

As an aside, in looking in detail at hotkeys, I can see a lot of erroneous
hotkey information in the Engines. For example, I see many cases where
a Marker Light hotkey is reported by the Engine but that Engine did not
have any Marker Lights. I have a Doddlebug that reports a Pantograph Menu.

3. Hotkeys not tested because my engines don't have them:
    Beacon Light
    Running Lights
    Firebox Glow
    Mars Light
    Auxilary Lights
    Pantograph
    Coors Delivery
    Boiler Startup/Release

4. On the Operations Window, I deleted the "LIN Light" switch as it
now is handed by the hotkey code. I added a "Sounds" switch which
will mute the engine sounds.

5. Generally cleaned up a lot of labels and Hints.

6. I realized that if communications fails while playing back a saved
recording, I needed to do something drastic. So now if comm fails (after
the set number of retries), RTC will send an Emergency Stop to all TIU's.

7. Dumb typing mistake in the LashUp window code prevented start up of a
good LashUp.

8. I generally made buttons bigger where I could mostly to help when
using a touchscreen.

9. Rule 17 lighting - almost. My P&LE GP-7 #1501 (PS3) headlight dims when
it is stopped. A nice feature not even listed on the MTH webpage (but
the webpage advertises lighted marker lights and there are none). I've added
a setup option to RTC which automatically turns off the headlight when your
engines are stopped. Not exactly correct but its there if you want to
use it. Defaults to off, if set, it applies to all engines.

Version 3.20 of the Remote Train Control program is available on the web page.

http://www.silogic.com/trains/RTC_Running.html

The big addition are Hot Buttons. This a window of 20 buttons that you can program to perform most any operation, on any engine, on any TIU or AIU. So if there are functions that you do over and over, on any TIU or to any engine, you can setup this window to do that function with one click of a button. You can popup this window and keep it on the screen to use as needed.

The program and source code are freely distributed under the Gnu Public License v3.0.

Mark

v 0.3.20.0

1. Added Hot Buttons:

 Up to 20 Hot Buttons can be defined. Once defined, a click on the button will immediately send that command. To open the Hot Buttons Window, click on the [Hot Buttons] button on the Main screen.

 To edit a button, right click on that button. Fill in the fields:
  - Button Label that will appear on the Hot Buttons Window. Use "&&" for "&", ie "P&&LE".
  - Command to be executed selected from the drop down Command List
  - TIU Number 1-5
  - Engine/Lashup Number: Engines 1-99, All Engine Operation 100, or LashUp 101
  - for AIU commands, the AIU Number 1-5 and the Port Number 1-10
  - for LashUps, the LashUp String - engine numbers separated by commas, using a minus sign to indicate Reverse Running.
  - for engine sounds, enter the sound number 1-255

Press the [OK] button to accept that command.

To undefine a button, right click on it, press [Clear] and then press [OK].

A special function "Playback of a Recorded File" lets you associate a recorded file with a hot button. When you press the button, the recorded file will play. You can cancel playback by pressing the [Cancel] button on the playback popup. You can repeat the playback by checking [X]Repeat.

The program, internally, maintains the Command list. If you want to add a command, right click the Hot Buttons Window outside of the Hot Buttons themselves and select "Edit Command List". Each line in this list is a command. The format is "Command Description"="Command". Press [Done] to save the edited list. The edited list is saved in the RTC folder with the name "HotCommands.txt". You can delete this file at any time to return to the internally maintained list.

2. Moved position of Quick Controls button

3. The buttons for Startup All Active Engines and Shutdown All Engines have been removed. To perform these functions, right click on the Main Window and when you get the popup menu, you can select these functions.

4. In the setup, you can select [X]Allow 255 Sounds. This sets the Engine Sound knob on the Sound Controls window to show sounds 1-255 on the knob. With this, you can play all 255 sounds in the engine. On the remote, "S01" hot key selects sound 177, "S02" selects sound 178 and so on. The 1-255 number corresponds to the index into the sound file as shown by the ADPCM program. http://www.silogic.com/trains/ADPCM.html

4a. For touch screen users, I added up/down buttons to both the Engine and Idle Sounds knobs. With a touch screen, the knobs are too hard to accurately control. The knobs themselves may disappear someday.

5. Totally rewrote the recorded file playback routine. Now when you select a recorded file for playback from either the Setup window or the Hot Buttons window, the playback runs as a separate thread. That means you can do other operations or even other playbacks while the playback is running.

Version 3.21.0 of RTC is available on my web page:

http://www.silogic.com/trains/...ng.html#RTC_Download

Updates:

1. Hot buttons would not work if you had no AIU, ouch. Fixed.

2. Bug fixes in Quick Controls. Enhancements in Quick Controls.

3. General code cleanup and communications speed up.

4. General improvement in how Conventional Mode works. RTC now puts
the channel into Variable mode when you select the [VarX] button.

5. Added a button on the operations screen that causes the bell to sound with
the Horn/Whistle and with the Crossing Sound. The setting of this button is saved.

Now this button and 3 others have been relocated on the operations screen:
    Rule 17 Lighting - turns off the headlight when stopped
    Ring Bell w/Horn - causes the bell to sound with the Horn/Whistle and
        with the Crossing Sound
    Auto Bell/Whistle - relocated from a switch. Sounds the horn/whistle when
        engine is starting moving from a dead stop
    Auto Labored Smoke/Auto Rev Exhaust - For steam engines, increases smoke
        output when laboring. For diesel engines, increases exhaust output
        when Revs are increased.

The settings of these 4 switches are saved with the engine.

6. Super TIU Mode operation improved. Setting screen added from "Super TIU Mode" button
on Setup window.

7. Added the ability to increase the size of the Quick Controls window. It also increases
the size of all of the buttons and controls for easier touch screen use. The size can
be set to 1.0, 1.1, ... 2.0 of the normal size

The 3.22.0 version of the RTC program is available on my web page:

http://www.silogic.com/trains/...ng.html#RTC_Download

Here are the v3.22.0 release notes:

1. I found the Hot Buttons to be so useful that I added 4 more windows of them so
their total is now 100. Right click on [Hot Buttons] to bring up a popup menu
where you can select from the 5 windows. Left click on [Hot Buttons] brings
up buttons 1-20 just as before.

2. Added support for Alternate Sound, SAH. This button, on the operations
window, plays sound 243. If the engine supports the SAH button, it will appear
automatically on the operations window when the engine is started up.

3. Yet another attempt to fix the sticky buttons problem. In the Windows message
based execution environment, I delayed the processing of the mouse button up message
until after the mouse button down message processing is complete.

Mark,

I received the Panstamp receiver today, and got everything going after some trial and error. I discovered that the range on my Panstamp wasn't nearly as good as the MTH DCS Remote but never the less it worked quite well once I got that figured out!

Seeing how the Panstamp works, is it possible to interface to a z4000 remote receiver?  The DCS remote can talk directly to the receiver, so in theory it should be possible, right?

Thanks for all of your hard work on this project!!! 

H1000

Glad you got it working. The radio in the panStamp has both a more powerful transmitter and a more sensitive receiver than the radio used in the remote & TIU. You should find that the range is better than than the remote.

I've not looked at the Z4000 receiver so I don't know how it communicates. I don't have any Z4000 hardware.

When I purchased the Panstamp, I opted for the SMA connector and the Antenna. I was in the next room on my desktop when testing and had to have the Panstamp held in in a certain position and location for it to work reliably.  The DCS remote was next to it and didn't seem to have any trouble. 

My main issues resulted in the program continuously popping up and saying "TIU not responding" & "Check Track". Once I held the Panstamp a little higher in the room it seemed to work a lot better. However, in my typical operation I will have a laptop in the same room with the Panstamp located much closer to the TIU.

H1000

 

Last edited by H1000

I've made some pretty good progress on my RFID train detection scheme and I've integrated it into the RTC program. It is now very reliable and I feel comfortable leaving the layout room (but not going to far!) with the trains running.

Three new videos on my web page http://www.silogic.com/trains/RFID.html

videos #13, 14 and 15. For higher resolution videos, go to my YouTube page:

https://www.youtube.com/channe...hcs3d9jtOEQMjEW9Fp7Q

In video 15, I've moved the RFID detectors to my layout (from the carpet) and show the RTC program along with the detectors running three trains. I used this during my TTOS SP Layout Open House Tour on the 28th of last month.  The program kept 3 trains running on my layout for 4 hours while I talked with the visitors.

Mark

I haven't used this program for some time now. I lost my older computer finally (crashed) and had to go back to an even older one downstairs for sound file changes, etc.

I'll have to boot it up and see what version of RTC is in there. (I think it's the 3.23 in my post above).

What is the latest version now? 4.0 out yet?

I read your page about the program changing to keep up with MTH's change from DCS 5.x to 6.x. I'm just not sure if we're using your program

3.27 or wait for 4.0? ( or beta 3.99?) I didn't see the proper link?

 I see something about the older versions won't work with the new 6.x versions of DCS?

MTH changed the commands for LashUps in DCS v6.00 (I think to better mesh with the WIU).       Version 3.27 of RTC was the first to support the new command format. But it was only an issue with LashUps.

Version 3.99.x is the latest on my web page right now. Its going to become v4.00 as soon as I get some feedback about its operation. If you search for "v3.99" on the RTC_Running.html page, you should see the download link.

That version uses some of the RAM mappings that I figured out and it has the Lua scripting language so everyone can automatically control their trains.

One new window available from the Operations window popup menu is "Engine Status" which uses the RAM mapping to show the status of lights on the engine. It also shows the trip odometer in almost real time and the set/instantaneous engine speeds.

SanDiegoMark posted:

With the help of a few of you, I've been able to figure out how to access the RAM memory in the engine and what some of those memory locations mean.

I noticed one of the parameters in your documentation is the "scale factor."  I've known for a long time that the number of motor revolutions per distance traveled is embedded in the loco's "personality file."

Could you use your program to tell me which MTH locos have the lowest gear ratio (or at least the maximum number of motor revolutions per inch?)  This is super-important to the operating characteristics of a loco, but it's not usually published in the specs.  Being able to read it from a downloaded "personality file" might save me the need to take it apart and count the revolutions manually. 

I also thought about inferring the ratio by swapping the file into a known loco, and measuring the magnitude of the error in speed and distance, but this is still a lot of work.  Thanks!!

Last edited by Ted S

You can actually find that out yourself. On each engine's page, there is usually a Support page with a link to the Sound File. Download that file and look at bytes 0x08 and 0x09. That is what I call the Scale Factor but I really don't know what it is or what it does other than enabling my RTC program to calculate the DOD and DTO values as I describe in my RAM mapping document.

Engine RAM Mapping.pdf

I'd be interested in seeing the results of your analysis.

Ok... I downloaded several sound files and looked at bytes 0x08 and 0x09.  I think byte 0x08 might be a representation of motor revolutions per distance traveled.  It seems to be "54" (decimal 84) for all diesels.  Every MTH diesel I know of has a gear ratio of 10.5:1, and wheels that are about 0.875 over the traction tires.

So what is byte 0x09?  Well, in order to determine motor RPM and train speed, the tach sensor has to count stripes, or at least interpolate the motor RPM by measuring transitions between light and dark marks on the flywheel.  The relationship between number of transitions and train speed is a function of the RPM, but also of the flywheel diameter, the number of stripes, and the width of those stripes. 

I know from my own experience that the flywheel diameter varies by application, even among diesels.  @gunrunnerjohn, is it true that all locos have 24 stripes from the factory?  I know that you've researched the characteristics of the sensor... From your experience, as the motor RPMs increase, does the tach signal increase linearly, logarithmically, exponentially, or ??

Bottom line, if I were to swap the file into a known loco, the error between the observed speed and the commanded speed could be due to a different gear ratio.  But it could also be due to a different flywheel diameter, stripe width, number of stripes, etc.  Why don't they just put the gear ratio on the darn box!?  

Last edited by Ted S

Add Reply

Post
The DCS Forum is sponsored by
×
×
×
×
Link copied to your clipboard.
×
×