Engines cutting out issues

20-20718-1 I worked on like that and I would suggest you try a feature n factory reset on both engines then readd engine with dcs

Alan

Both these engines exhibit the exact same behavior? ……They work fine on the bench? ……are you using a different command set up on the bench than what’s on the layout?

Pat

Alan, feature reset was done on both.

Pat, yes the bench is a different setup than the layout, two TIU's in supermode. With the Mikado I will mention that when the sound cuts out all I can get it to do is fwd and rev but no movement with sounds that cut in and out. I have an SD-40 20-20412 on this system that runs fine (different track though). I haven't yet, but will try the Mikado on the bench this afternoon and report back.

Mikado checked out on the bench. Did another reset and now works fine on the layout. The 44 toner however still has issues. As before it starts up fine under DCS, but after about 10 seconds the sounds quit followed by the smoke alarm noise.

The 44-toner engine could have board issues! I would suggest have an ASC TECH check out your board on their test fixture! If you do a feature reset and factory reset the smoke unit will shut down! then start up engine with dcs again!

Alan

The 44 tonners have poor ground pickup due to very limited truck movement.  Are both outside rails tied together?  Is the track level?  Grades?

Jon, I do have all my outside rails tied together and track is level.

I was able to do a little more testing this morning prior to game time. I put the 44 tonner back on the bench to confirm it's operation. I had it running back and forth (3ft piece of Gargraves, one outside rail grounded), couples, sound up and down for about 10 minutes without issue. I then moved it around my layout to see if location had anything to do with it. Each time it acted the same. It's starts up fine but after about 1 to 2 minutes the regular engine sound gets interrupted by the smoke alarm noise or what sounds like some kind of alien communication, lol. During the communication, fwd/rev and couplers work just fine, even the volume adjustment works. On top of that I also get excellent track signal test.

During my test I pulled out a couple of other engines (one PS2 3v, one PS3) and the worked just fine, go figure.

Is it possible there is something corrupt in the sound file? This being a PS3 engine it has a chain too, correct?

I would turn the smoke unit off in dcs and then try it smoke unit can be causing your problem!

Alan

I'd have to double check, but I don't believe these have smoke.

@milwrd posted:

I'd have to double check, but I don't believe these have smoke.

I've never heard of any O Gauge 44 tonner that had a smoke unit.

Does sound like corrupt SF.  I would reload flash and sound file.  G

Per GGG's advice I am tempting to reload the flash/chain and sound files. Went to the MTH site, typed in the product number (20-20719-1) and clicked on the Proto 3 Sound tab to get the file(s). There is two different files, one from 2017 and 2020. Thinking the 2020 file may be an updated version I unzipped it and added it to my MTH sound file folder. One of them is 6KB and the other 74KB. Is the 6KB file the chain file?

The 3.2 Meg is the sound file.  They have 2 flash codes, not sure why.  There is no 6k file.  I would load e 2020 flash code and the sound file.  G

I finally got around to reloading the files. I also tried both flash files. No difference in regards to how it operates. Works just fine on the bench. When I move it over to the layout it powers up just fine but after about 5/10 seconds the sound goes into smoke alarm mode. All other functions operate as normal, fwd/rev and couplers. Even get a 9/10 for signal strength. I put two other different PS3 engines on the layout and they operate just fine. At this point it's above my pay grade.

Is it upside down when bench testing?  What is different on the bench versus your layout.  Can you take it to a club or shop layout and test it to see how it performs?  When you say smoke alarm.  Is it beeping or is it a screech sound?  Really odd.  G

I'm using a section of Gragraves with alligator clips on my bench. The bench setup is a "I" ver TIU and a Cab-1 base. Layout is a "L" ver TIU Cab-2 and Cab-1 base with one of Dales TMCC boosters. In regards to the smoke alarm noise, it's a high pitch constant screeching sound. As mentioned above I tried two other PS-3 and a PS-2 engine on my layout without issue. I do currently have a Weaver TMCC/EOB engine w/MTH passenger cars and a Lionel Legacy engine w/K-line passengers cars also on the track.

Note: when reloading the the flash and sound files I had an error and had to click retry to keep loading. This happened both times I tried it in about the same place while loading the files. Might this be a file issue?  

Try turning down the amplitude of the TMCC signal with the pot on the TMCC buffer.  The reason for the pot was to tune the boost of the TMCC signal to minimize any interaction with the DCS signal.

For the interest of trouble shooting I took all TMCC Cab-1 & 2 related devices off line. Makes no difference. This PS-3 engines still exhibits the the same boot up, about 5 seconds of regular engine sounds followed by a high pitch constant whine akin to a smoke alarm with all other functions working just fine.

When I've had symptoms like that, generally it turns out to be sound or chain file issues.

Try picking a totally different engine and load the chain/sound files and see if it behaves.  It won't sound right, and stuff like lights may not work correctly, but we're just seeing if it's a sound file issue at this point.

Up date. I pick a VO-1000 for a test subject. I just flashed the chain file for the 44 ton (no sound file yet). At the end it went though a boot up as it did prior after witch the the engine emitted the high pitch whining sound. So maybe the chain is corrupt?

I though I'd also mention there is two chain files for this 44 ton engine, one from 2017 and one from 2020. I chose the 2020 file.

After loading chain files that are different, the board compares the file to current.  When power is off it will emit morse code as it compares them.  Processor shuts down before completing so on re application of power the comparison starts over.  Once done engine starts up.

After loading SF some engines emit that screech until a power cycle.  That final power cycle has the flash code and SF sync up an run normal.  I had run across boards (early PS-3) that would have similar sound issue going from a good sound to the screech.  Have not seen that in recent years.  You need to make sure your allowing time between flash load, and sound file load.  You also need a clean load.  Try DC power.

But it is still odd it would work on bench, but not layout.  Unless that is just random.  If you get a clean load and it still does it, I would suspect bad board issue with processor/memory.  G

@Alan Mancus posted:

20-20718-1 I worked on like that and I would suggest you try a feature n factory reset on both engines then readd engine with dcs

Alan

Agreed a factory reset of the engine might be better than delete and relearn

Update: a VO-1000 is the test subject here. I tried two attempts each with AC and DC power. Each time I got the Morse code prior to power down and after power up.  I deleted both engines from the remote. Loaded sound file for the 44 Ton and each time out of the four attempts it still adds as the VO-1000. Is there some way to delete the files in the memory or does this process just overwrite what's on the board?

If you have the consumer loader you cannot change the serial data which presents name.  The Flash and sound file will provide the correct softkeys and such, but permanent name change requires dealer loader.

Having said that, after you load flash and program ends.  Turn off power.  After waiting 30 sec turn on power.  After morse code and start up, turn power off.  Once engine shuts down, turn power back on.  Engine should stay silent.  If it does Flash code loaded successfully.  Now load new Sound File.  Follow same turn off, no morse code, and power back on.  Now it should run properly.

If you do keep getting morse code, that is a load glitch requiring MTH to reflash the processor.  Use to happen early on, but have not seen that in several years so firmware corrections may have resolved it.  G

What he says.  I know that for some boards I had to do several power cycles for them to get their mind right.  However I agree, if you keep getting the code on every power cycle, you aren't going to be able to fix that, only MTH can.

First, thank you GGG for refreshing my memory with the consumer loader not being able to change the name in the remote. Using DC power worked much better the AC.

I did indeed get the correct files loaded and working. After deleting these two engines from the layout remote I put the now donor VO-1000 with the new files on my layout and it works just fine, go figure. I then deleted it and placed the 44 ton back on the layout, added it the remote (via add MTH engine) and hit the start up button. As before it's starts just fine but within 5/10 seconds it went berserk. Only this it was all sorts of random noise, all the other functions worked fine.

Just a follow up on this. I'm not sure what changed here if anything. I changed the VO-1000 back to it's original personality, that's good to go. For the heck of it I thought I'd give the 44 Ton another try, only this time I used DC power. Low and behold I believe I worked. Put it back on the layout and so far so good.

I'm not sure if this was the magic pill or not, but I know when I was using AC power there was two times (out two tries) where the loader was requesting a "Retry Sector 4046-4049" or see the pic below. Using DC power everything seemed to go so much smoother.

I use DC for PS/3 loads all the time now, it's much more consistent than AC power when loading.  Remember, the DCS signal is riding on the track power, any distortion of the power will affect the DCS signal to some extent.

@milwrd, Curious question, what "REV" is your TIU?

I tested the whole AC vs. DC and a 25 foot long connection wire between the TIU & track and never found any difference in the results. One big difference is the REV. G TIU I used previously was terrible at uploading files to any PS3 engine. It did exactly what @milwrd had going on. The REV. G did work great for both varieties of PS2 engines though.

H1000, the TIU on my bench (the one I use for loading files) is a Rev. I. The one on my layout is a Rev. L.

I've actually found that there is a difference between AC and DC loading, it's really noticeable with PS/3 loads as they're much larger files.  I think the AC loading tended to drop to low speeds at times when loading.  I have used a Rev. L TIU for years for all my loads, so it's not the version of the hardware.

I hasten to add, though I don't do it routinely, the test bench at the old MTH plant had the 25-30 foot set of leads between the TIU and the loading track, apparently the people that build the stuff thought it helped.

It would make sense that DC should be better for this as AC power run through a transformer can be influenced easily by a lot of things in a household.  I remember running trains when I was younger and my mom would get mad because the trains running through the ZW in the basement caused considerable static interference on the TV upstairs.

Just for reference, I uploaded a PS3 file to an engine last weekend (using AC power). The max communication speed of the TIU from your PC to the Track is 9600 baud (9,600 bits per second). The file was 3,044 Kilobytes (3.044 Mb / 24,352,000 bits) and it took right at 43 minutes to finish. That's pretty much a perfect time given the file size.

@H1000 posted:

It would make sense that DC should be better for this as AC power run through a transformer can be influenced easily by a lot of things in a household.  I remember running trains when I was younger and my mom would get mad because the trains running through the ZW in the basement caused considerable static interference on the TV upstairs.

Just for reference, I uploaded a PS3 file to an engine last weekend (using AC power). The max communication speed of the TIU from your PC to the Track is 9600 baud (9,600 bits per second). The file was 3,044 Kilobytes (3.044 Mb / 24,352,000 bits) and it took right at 43 minutes to finish. That's pretty much a perfect time given the file size.

Well, I don't want to call your timing into question, but there's additional framing overhead for the serial communication, so that seems somewhat outside reality.  For one major point, there are ten bits for each byte because you have the start bit and stop bit for every byte.  For ASYNC serial data, there is a 25% overhead for 8-bit data with no parity bit.  So using your computations, assuming no parity on the transmission, it should have taken at least 53 minutes to send that file assuming perfect transmission and no protocol overhead.  Of course, there is protocol overhead, and gaps between blocks, so that 53 minute number is low.

@gunrunnerjohn posted:

Well, I don't want to call your timing into question, but there's additional framing overhead for the serial communication, so that seems somewhat outside reality.  For one major point, there are ten bits for each byte because you have the start bit and stop bit for every byte.  For ASYNC serial data, there is a 25% overhead for 8-bit data with no parity bit.  So using your computations, assuming no parity on the transmission, it should have taken at least 53 minutes to send that file assuming perfect transmission and no protocol overhead.  Of course, there is protocol overhead, and gaps between blocks, so that 53 minute number is low.

I don't think I want to make an almost hour-long video of the whole process 😏 but as uploading files is something I generally don't watch the entire process, I use a screen timer to note when there is an error and/or when the process finishes. That particular upload was logged at exactly 43:02 from the time the first block was written and the last block was verified.  When I upload a true 4Mb file then I've noted around 55 to 56 minutes. The little 1 Mb files take 13 to 14 minutes. YMMV.

They're obviously not sending all the bytes, as it would be impossible to cram them into that timeframe.

I haven't done a PS2 upgrade in years (still have a couple of kits) and zero PS3's. Hopefully I'll get some done yet this season. I gotta tell though, I have to concur with John on this one. It seemed to me to take a lot less time to load the files (not to mention smoother), both flash and sound files. But hey, I'm just a wingnut when it comes to part of our fine hobby. I'm happy that I was able to get that 44 Ton going again. Gosh that sound was annoying.

WOW. 45min to 1 Hr?  I use Original Rev L and HO DC power pack fixed voltage.  My PS-3 loads at worst run 25mins.  Loading PS-32 boards is shorter.  The only time I had a long load was DOWNLOAD only done once.  That took about 45 mins.  G

Mine don't take that long either George.  I'm sure much of the size of the PS/3 file is stuff they don't have to transmit, or it simply wouldn't get there in the times we're discussing either.  I do figure on about half an hour to load the PS/3 sound file, but at least the chain files are much quicker.