TheRailwire
General Discussion => DCC / Electronics => Topic started by: davefoxx on October 30, 2018, 10:12:18 AM
-
I am standardizing on ESU sound decoders in all of my locomotives. I have been successful modifying the CVs on these decoders through JMRI to tweak the settings for improved train handling and sound effects. So, this week, I bought an ESU Lokprogrammer, so I can update the software on my decoders, e.g., upgrade a few Loksound Select decoders to Full Throttle. Yay! But, I can't get it to work. Boo!
Admittedly, I am not computer savvy. Disclaimer: I am attempting to run this hardware through a Mac, and Lokprogrammer is only compatible with Windows. So, I went to Codeweaver and purchased the CrossOver software to run Windows programs on a Mac. (An older version of this software is what I have successfully used in the past to run AnyRail on my Mac). After a lot of trial and error last night (mostly error), the Lokprogrammer software is installed and will open on my Mac. Success! However, . . .
THE PROBLEM: I cannot get the USB/serial cable to be recognized by my Mac. In other words, while the Lokprogrammer software will run, I cannot get the Mac and the Lokprogrammer to communicate with each other, because the cable is not recognized. I need help in a bad way. I did download the drivers for the USB cable from ESU. I believe that I have set it up through CrossOver, but it just won't work, regardless of which USB port I plug it into on the Mac. Help!
DFF
-
Just covering all the bases here, are you using the USB-Serial cable supplied with the LokProgrammer? It requires a specific cable type. My LokProgrammer arrived without the cable, but I wanted to use it now so I bought a (not so cheap) one from BestBuy, but like you nothing was recognized. Once ESU's cable arrived, everything ran perfectly and I returned the BBY cable.
-
Just covering all the bases here, are you using the USB-Serial cable supplied with the LokProgrammer? It requires a specific cable type. My LokProgrammer arrived without the cable, but I wanted to use it now so I bought a (not so cheap) one from BestBuy, but like you nothing was recognized. Once ESU's cable arrived, everything ran perfectly and I returned the BBY cable.
Thanks for responding, Mark. Yes, the Lokprogrammer came with the USB cable, and I downloaded the driver from ESU's website. I'm sure I'm doing something wrong, but I don't have any more ideas. Interestingly, I also tried the USB/serial cable that I have that does work on this Mac for JMRI (to connect to my NCE command station), but it also wasn't recognized. D'oh!
DFF
-
I don't know why they still use the serial port. USB/Serial cords are hit and miss in compatability because there is something wrong with the converting chip in them. There are ways around it but if you're not tech savvy it's hard to find what to do. I don't know why esu hasn't made the new programers straight USB
-
There are ways around it but if you're not tech savvy it's hard to find what to do.
This is exactly what I am up against. I was hoping somebody here could somehow walk me through it. :(
DFF
-
So, I went to Codeweaver and purchased the CrossOver software to run Windows programs on a Mac. (An older version of this software is what I have successfully used in the past to run AnyRail on my Mac). After a lot of trial and error last night (mostly error), the Lokprogrammer software is installed and will open on my Mac. Success! However, . . .
THE PROBLEM: I cannot get the USB/serial cable to be recognized by my Mac. In other words, while the Lokprogrammer software will run, I cannot get the Mac and the Lokprogrammer to communicate with each other, because the cable is not recognized. I need help in a bad way. I did download the drivers for the USB cable from ESU. I believe that I have set it up through CrossOver, but it just won't work, regardless of which USB port I plug it into on the Mac. Help!
DFF
I am sad to say, CrossOver won't work. I had the same experience that you did. After much fussing getting the right pieces of .NET installed and other Windows parts I got the LokProgrammer software to mostly work. But it won't talk to the USB ports. No way, no how. I Googled and Googled and found several supposed fixes but none worked.
As far as I know the only way to run the LokProgrammer software and have it talk to the hardware on a Mac is by using a PC emulator with actual Windows. I use Oracle's VirtualBox and Windows 7 Pro. Dave Sands of the JMRI and LokSound groups uses Parallels and others have used VMWare Fusion. The problem with this approach is that you have to also buy Windows. But there is no other way around this. If I were you, I'd use VMWare Fusion. I've used it before and it's pretty simple to set up and use. I switched to Oracle VirtualBox for some techy reasons (running Linux systems on my Mac) which wouldn't help you. Then again, VirtualBox is free, Fusion is about $50 I think.
Sorry, Dave. :(
I don't know why they still use the serial port. USB/Serial cords are hit and miss in compatability because there is something wrong with the converting chip in them. There are ways around it but if you're not tech savvy it's hard to find what to do. I don't know why esu hasn't made the new programers straight USB
macOS has several USB/serial drivers already installed. The FTDI driver and pl2303 are the most common. I use several FTDI based cables and haven't had any problems.
-
I used to use VMware's Fusion, but then I decided that if I'm running Windows anyway, it would be easier just to dual boot it and run Windows natively via Bootcamp. So that's what I did. Eventually I bought a new MacBook, and the old one now just sits in my work room running Windows for just this purpose.
But . . . you might be able to pick up a used, older laptop or desktop (if you have an extra monitor lying around) with Windows already installed for not much more than you'd pay for a retail version of Windows, and just dedicate that to your JMRI/LokProgrammer setup. Used computer equipment is really, really cheap, and you don't need much horsepower for this.
John C.
-
John,
As always, thank you sharing for your vast knowledge. You have confirmed my worst fears. Oh, well, the only real loss is the new subscription to CrossOver. I'll probably look into VMWare and Windows. I wish there was an el cheapo PC that I could buy that would include Windows and avoid this whole Mac complexity. I could just make this my dedicated JMRI/Lokprogrammer computer.
DFF
EDIT: HAHA! Love the simultaneous post, John!
-
...
But . . . you might be able to pick up a used, older laptop or desktop (if you have an extra monitor lying around) with Windows already installed for not much more than you'd pay for a retail version of Windows, and just dedicate that to your JMRI/LokProgrammer setup. Used computer equipment is really, really cheap, and you don't need much horsepower for this.
John C.
Black Friday is around the corner. JMRI/LokProgrammer will run on the lowest spec laptops which many will be priced lower than the LokProgrammer itself.
https://www.bfads.net/
Oh, well, the only real loss is the new subscription to CrossOver.
If it didn't support the program you intended it for, you can probably get your subscription refunded, or at the very least the remaining subscription pro-rated back.
-
If it didn't support the program you intended it for, you can probably get your subscription refunded, or at the very least the remaining subscription pro-rated back.
No biggie. I can use it for AnyRail, but I may need to renew that, too. :facepalm:
DFF
-
Black Friday is around the corner. JMRI/LokProgrammer will run on the lowest spec laptops which many will be priced lower than the LokProgrammer itself.
Anyone want to recommend a cheap laptop that will run LokProgrammer? It would also need to have WiFi, so I can get internet access to download programs from ESU for decoder and LokProgrammer updates.
Thanks,
DFF
-
There are perfectly acceptable laptops from HP, Dell and Lenovo listed on Amazon in the $150 range, with WiFi and Windows. Not the speediest, nor biggest displays, but just fine for LokProgrammer and JMRI.
-
https://www.discountelectronics.com/dell-latitude-e6400-windows-7-pro-laptop/
(just one example; there are a bunch of places on the net that sell used/refurbished laptops).
John C.
-
That Dell Latitude is decent (for a Windows PC :trollface: ). when I worked as a contractor at GE that's what they gave me but with 8GB memory. 4GB will run JMRI or LokProgrammer just fine.
-
There are plenty of refurbed laptop deals on ebay. Few years ago I bought a Dell Latitude E6410 laptop (it was fairly vintage even then) for couple hundred dollars. It has Win 7 Pro (64-bit) installed. Intel Core i5 2.6GHz, 4GB RAM, 250GB hard drive. I also pickled up a docking station for it to get the serial and parallel ports, and couple additional video ports. That is actually the laptop on which I'm typing up this message. I run all sorts of software on it (including the LokProgrammer). Plenty of "horsepower" for what I do on it.
-
There are plenty of refurbed laptop deals on ebay. Few years ago I bought a Dell Latitude E6410 laptop (it was fairly vintage even then) for couple hundred dollars. It has Win 7 Pro (64-bit) installed. Intel Core i5 2.6GHz, 4GB RAM, 250GB hard drive. I also pickled up a docking station for it to get the serial and parallel ports, and couple additional video ports. That is actually the laptop on which I'm typing up this message. I run all sorts of software on it (including the LokProgrammer). Plenty of "horsepower" for what I do on it.
Hey, what a coincidence, that’s exactly what I have too for my dedicated train computer including the docking port. The later stays in the garage with the layout. Works just fine and dandy.
-
I'm going on a weak memory here, but... as I remember it, you have two separate things to download from the ESU web site. I downloaded both any started each up and ran into the same problem. As it turns out, the system is specific about which you load into your computer first. I redid the loads in reverse order and all has been fine since.
-
I broke down and bought a cheap laptop on the way home from work tonight. I spent a little bit more than if I were patient and had ordered one online, but I'm dying to play with this LokProgrammer. Stay tuned.
DFF
-
I broke down and bought a cheap laptop on the way home from work tonight. I spent a little bit more than if I were patient and had ordered one online, but I'm dying to play with this LokProgrammer. Stay tuned.
DFF
A man after my own heart. If I added up all the "I've got to have it now" premiums I've paid over my life, I'd probably be able to afford a small island in the Caribbean . . . :facepalm:
Let us know how it goes.
Do you have the link for the updated LokProgrammer manual from the ESU Yahoo list? If you don't have that, it's VERY useful (unlike the rest of ESU's manuals), probably because it was written by an end user, as opposed to coming from ESU . . . If you don't have it, e-mail me directly at jdcolombo at gmail and I'll send it to you.
John C.
-
Success! While the new laptop isn't the fastest computer that I have, I was able to successfully download the necessary software and set up the LokProgrammer in a fraction of the time that I farted around with the Mac last night. I'm now going through videos and trying to learn how to use it right now.
John, your timing is perfect. I don't have that ESU manual, so expect an email. Thank you!
DFF
-
Success! While the new laptop isn't the fastest computer that I have, I was able to successfully download the necessary software and set up the LokProgrammer in a fraction of the time that I farted around with the Mac last night.
You don't need a fast computer for any of the DCC stuff we use. None of it is is computationally- or graphic-intense. Not as if you were playing some high-res VR game. :D
Nice to see you being able to get your new "toy" and play with it.
-
Thanks, Pete!
I was up early this morning, so I decided to download a new sound file for an Atlas GP40. This locomotive's factory sounds on the ESU LokSound Select decoder sounded fine, but it was lacking the Full Throttle features. The new laptop took much longer to load the software to the locomotive than the expected twenty to thirty minutes (probably closer to forty-five to sixty minutes). But, that's not a huge problem, because it's not like I'm going to be doing this every day. Before I had to run out the door to work, I quickly changed the decoder address on the LokProgrammer and placed the locomotive back on the layout. It worked! This GP40 now has a different recording for a GP40 prime mover, which will be great in a consist. Besides, I don't really want every Geep I own to sound exactly the same.
I'll just need to go back and modify certain settings to lower the volume and to speed match the locomotive to the rest of the fleet again. But, I'm ecstatic. I have at least one or two more locomotives that need to be upgraded to Full Throttle, so this is fantastic. My favorite feature is Drive Hold, so I was disappointed when I learned that a few of the locomotives that I had purchased were lacking this feature. But, with the LokProgrammer, I was able to fix the issue without even having to remove the shell.
I guess once I'm finished tweaking the settings, I'll want to go back into JMRI and read the decoder into that to store the decoder's settings there, too. Is that what you all do, or do you not bother, since it's saved through the LokProgrammer?
DFF
-
Hi Dave.
I don't attempt to save all of the LokSound decoder's settings on JMRI. I use the LokProgrammer software to save all that info (and I back it up religiously). The reason is that it takes forever for JMRI to read all the ESU CV's - easily an hour, sometimes 90 minutes. However, I DO enter my locos in the JMRI roster. The main reason for doing this is that then I have a convenient list of everything I have AND it also allows me to edit the labels of functions keys that show up on the Wi-Throttle or Engine Driver apps that I use with my ESU Mobile Control II or old Apple iPhone 5's for throttles. With JMRI, I can tell the apps to show only the function buttons I want my operators to see - usually that's F0, F1 (bell), F2 (horn), F4 (Drive Hold, remapped), F5 (Independent brake, remapped) and F8 (sound on/off). And instead of numbers, the buttons have actual English labels. F1's button doesn't say "F1" - it says "Horn". Much better, especially for guys who come over once every couple of months to operate.
If you really want to save all the decoder info to JMRI, there is a much faster way to do it than having JMRI read the decoder's CV values. That way involves having the LokProgrammer export all the CV values to a file, then using the import function in JMRI to import those values. Rick Brodzinsky has a post somewhere that gives the exact instructions for doing this. But I figure that for any complicated programming, including changing the volume of individual sounds or remapping function keys, I'm going to use the LokProgrammer. So there is no need to have the CV's stored in two separate places and I just use JMRI for basic roster info.
John C.
-
I'm not sure that I want to save the data to JMRI, since it will be saved through the LokProgrammer. But, it would be an easy way for a back up, and I would avoid the problem of accidentally overwriting the decoder with old data on JMRI. Since I won't have a huge fleet, it really isn't a big problem to also load the information to JMRI if I decide to do so.
DFF
-
Export from LokProgrammer and import into JMRI is VERY VERY VERY VERY easy.
In LokProgrammer: when you have the project setup as you want it, select "Tools | Export CV List..." This will create a text file with all the CVs
In JMRI: First, create a roster entry for the loco. Fill in any of the "basic info" data you want. One thing I always do is put the ESU project number into the comment field on the basic tab. The select "File | Import | LokProgrammer CV list file..." and select the file you made when exporting, above.
The import will take a few moments, but now all the CVs from LokProgrammer are in your JMRI roster entry. Even if you don't plan to use DecoderPro for your routine programming of these decoders, it is a good idea to do this import, just in case you have an "oops moment" in DP and hit "write full sheet" instead of "write changes" on a tab. I find using DP much easier for the speed matching and speed table settings (Program on Main stuff); while I use LP for most of my sound adjustments.
-
Thanks, Pete!
The new laptop took much longer to load the software to the locomotive than the expected twenty to thirty minutes (probably closer to forty-five to sixty minutes). But, that's not a huge problem, because it's not like I'm going to be doing this every day.
DFF
Dave, I believe that the slowest piece of hardware is the serial connection between the laptop and programmer. Even if you had the fastest computer in the world, the bottleneck (and slowness) would be at the serial port connection. So I wouldn't be so quick blaming the slowness on your laptop. :D
I'm also puzzled as to why ESU has not yet re-spun the LokProgrammer hardware to directly use a USB 2.0 interface, instead of relying on a 50+ year old serial RS232 (or whatever it is) port interface
-
I'm also puzzled as to why ESU has not yet re-spun the LokProgrammer hardware to directly use a USB 2.0 interface, instead of relying on a 50+ year old serial RS232 (or whatever it is) port interface
Oh, Pete. You know why. $$$ A redesign would cost and the thing works as it is. There might be some setup problems from time to time but that doesn't bother the corporate leadership. I don't think switching to all USB would make it faster anyway. The bottleneck is probably the speed of sending the data to the decoder.
-
Oh, Pete. You know why. $$$ A redesign would cost and the thing works as it is. There might be some setup problems from time to time but that doesn't bother the corporate leadership. I don't think switching to all USB would make it faster anyway. The bottleneck is probably the speed of sending the data to the decoder.
You do have a point John. I just didn't want Dave feeling disappointed with his inexpensive laptop - it is not the reason for the apparent slowness of the programming process.
-
You do have a point John. I just didn't want Dave feeling disappointed with his inexpensive laptop - it is not the reason for the apparent slowness of the programming process.
No, you're correct in that. It's the downloading of up to 4MB of data into the decoder chip that is the slowness.
-
Now that I have switched over to NCE for my new HOn3 layout (just for a change and my Digitrax went with my layout when sold) I needed to purchase a serial port to USB cable from ESU (best one to purchase) so I can connect my old laptop to the NCE command station according to JMRI experts to be able to adjust the sounds and other features in my Blackstone K27's. The NCE command station I have only has a serial port with which to connect to a PC.
Folks much smarter than me strongly suggested not to purchase any other brand.
Rod.
-
Now that I have switched over to NCE for my new HOn3 layout (just for a change and my Digitrax went with my layout when sold) I needed to purchase a serial port to USB cable from ESU (best one to purchase) so I can connect my old laptop to the NCE command station according to JMRI experts to be able to adjust the sounds and other features in my Blackstone K27's. The NCE command station I have only has a serial port with which to connect to a PC.
Folks much smarter than me strongly suggested not to purchase any other brand.
Rod.
The USB/serial converter cables actually have some intelligence built-in to translate the USB protocol to the serial port type protocol. There are several types of that "translator" chip used in those adapter cables. Some types only have limited capabilities. That is why some are better than others. There can also be different versions of the Windows drivers for those various translator chips. The brand of cable ESU sells just happens to be one of the "good" ones.
-
Now that I have switched over to NCE for my new HOn3 layout (just for a change and my Digitrax went with my layout when sold) I needed to purchase a serial port to USB cable from ESU (best one to purchase) so I can connect my old laptop to the NCE command station according to JMRI experts to be able to adjust the sounds and other features in my Blackstone K27's. The NCE command station I have only has a serial port with which to connect to a PC.
Folks much smarter than me strongly suggested not to purchase any other brand.
Rod.
I switched over to NCE when I started this newest layout, too. Nothing against the Digitrax system that I had on the old layout, which served me well for many years on a couple of layouts. But, the distinct advantage of advanced consisting on NCE makes it a lot easier to use the Full Throttle features in a consist. I have upgraded an Atlas GP40 and an Atlas GP40-2 to Full Throttle, and last night, I consisted them together and, using Drive Hold, was able to run them both up to Notch 8 before they started moving. Sweet.
Tonight, I hope to watch a video that I found on YouTube about speed-matching with an Accutrack II speedometer and LokProgrammer. Since I have both of these pieces of hardware, I want to check out if this is the new way I will speed-match.
DFF
-
Tonight, I hope to watch a video that I found on YouTube about speed-matching with an Accutrack II speedometer and LokProgrammer. Since I have both of these pieces of hardware, I want to check out if this is the new way I will speed-match.
DFF
FWIW, I've used an Accutrack, and although its fun to see the digital readout of the speed as the engine runs through it, I've found that the "old fashioned" method actually works better (plus you can't really use the Accutrack to adjust momentum). That method is this:
1. Find out which engine you are matching is the slowest in unmodified running.
2. Set the 3-point speed curve (CV's 2, 5 and 6) to get what you want for start, mid and max speed. Turn momentum off (e.g., CV3 and CV4 = 0).
3. Put the same CV values as you got in Step 2 into the engine you want to speed match (the faster one). It's momentum should be off, too.
4. Put both engines on the track, separated by about 4 inches. Consist them. Crack open throttle and observe. The faster engine probably will close slightly on the slower one, although maybe not at speed step 1, which will be mostly controlled by BEMF anyway. Adjust CV2 using ops mode programming in that engine to match the slower engine if need be.
5. Separate engines by 4" again. Advance the throttle to 50%. Observe. The faster engine will close on the slower one. Adjust CV6 on the faster engine until it matches speed.
6. Advance throttle to 100%. Repeat the observe/adjust for CV5.
7. Adjust momentum for slow engine to what you want (ESU uses a default of 80 for files equipped with Drive Hold, and I find this to be pretty good).
8. Put same values in Engine 2.
9. Check acceleration momentum matching by putting engines on track, separated by 4", consist, and turn throttle up quickly to 100%. If they don't match, adjust Engine 2's CV3. Then crank the engines up to 100% throttle, quickly turn throttle to zero, and observe whether braking momentum matches. If not, adjust CV4.
You're done. This sounds harder that it is, although I've never tried it with an NCE system (I use Digitrax). But I do get perfectly matched engines this way.
BTW, if you have grades on your layout, you might find that adjusting the BEMF cutoff (CV56) is useful to keep consisted engines from "bucking" going downgrade (maybe upgrade, too, although that's usually not a problem). If bucking is a problem going downgrade (or any time), set CV56 in each engine to 120. If bucking persists, lower the value in CV56 until it disappears (but don't go below about 50 - you need BEMF on at low speed for best low-throttle response).
John C.
-
FWIW, I've used an Accutrack, and although its fun to see the digital readout of the speed as the engine runs through it, I've found that the "old fashioned" method actually works better (plus you can't really use the Accutrack to adjust momentum). That method is this:
1. Find out which engine you are matching is the slowest in unmodified running.
2. Set the 3-point speed curve (CV's 2, 5 and 6) to get what you want for start, mid and max speed. Turn momentum off (e.g., CV3 and CV4 = 0).
3. Put the same CV values as you got in Step 2 into the engine you want to speed match (the faster one). It's momentum should be off, too.
4. Put both engines on the track, separated by about 4 inches. Consist them. Crack open throttle and observe. The faster engine probably will close slightly on the slower one, although maybe not at speed step 1, which will be mostly controlled by BEMF anyway. Adjust CV2 using ops mode programming in that engine to match the slower engine if need be.
5. Separate engines by 4" again. Advance the throttle to 50%. Observe. The faster engine will close on the slower one. Adjust CV6 on the faster engine until it matches speed.
6. Advance throttle to 100%. Repeat the observe/adjust for CV5.
7. Adjust momentum for slow engine to what you want (ESU uses a default of 80 for files equipped with Drive Hold, and I find this to be pretty good).
8. Put same values in Engine 2.
9. Check acceleration momentum matching by putting engines on track, separated by 4", consist, and turn throttle up quickly to 100%. If they don't match, adjust Engine 2's CV3. Then crank the engines up to 100% throttle, quickly turn throttle to zero, and observe whether braking momentum matches. If not, adjust CV4.
You're done. This sounds harder that it is, although I've never tried it with an NCE system (I use Digitrax). But I do get perfectly matched engines this way.
This is exactly what I do, too, except I like the speedometer to set max speed at 70 smph and mid speed at 35 smph on all locomotives. If I can get the locomotives within 1 smph of each other, they seem to consist just fine, but, as you noted, momentum is by trial and error only to really get them matched perfectly.
BTW, if you have grades on your layout, you might find that adjusting the BEMF cutoff (CV56) is useful to keep consisted engines from "bucking" going downgrade (maybe upgrade, too, although that's usually not a problem). If bucking is a problem going downgrade (or any time), set CV56 in each engine to 120. If bucking persists, lower the value in CV56 until it disappears (but don't go below about 50 - you need BEMF on at low speed for best low-throttle response).
This is good information! I though BEMF had to be on or off. Good to know that it's adjustable! Thanks for the suggestions on settings, John. Actually, my mainline is level, but I do have a grade on the branchline. However, since the planned staging yard will be so short, the trains going up the hill will only be one locomotive and two to three freight cars. So, hopefully, I will have no troubles with BEMF.
Thanks,
DFF
-
BTW, if you have grades on your layout, you might find that adjusting the BEMF cutoff (CV56) is useful to keep consisted engines from "bucking" going downgrade (maybe upgrade, too, although that's usually not a problem). If bucking is a problem going downgrade (or any time), set CV56 in each engine to 120. If bucking persists, lower the value in CV56 until it disappears (but don't go below about 50 - you need BEMF on at low speed for best low-throttle response).
John C.
There was just a thread (Subject:CV 56 and Consisting!!!) on the LokSound Yahoo group about this. One poster recommended starting at 20 if you had this bucking problem. I have not verified since I my flat door has no grades but if you find going down to 50 hasn't solved it then lower apparently isn't necessarily bad.
-
Yeah, actually I used the speedometer to set the mid and max speeds on my reference unit. Then I matched everything to that. In theory, at least, I can consist any of my 40 diesels with any other one - they all have ESU decoders, though about a third of them have LokPilot V.4's instead of LokSound. In practice, I tend to keep the same units consisted forever - so much so that I ended up using the "hard" consist method (setting each unit's address to the lead unit), since Digitrax doesn't accommodate advanced consisting very well. NCE is MUCH better for that and makes Drive Hold a lot easier to use.
John C.
-
With ESU decoders, I have found that I can near perfectly speed match (momentum aside) simply by setting the max speeds with the Accutrax II, and then setting a linear speed table (after doing the BEMF auto set). I have yet to find locos which don't consist nicely having done this. If throwing a non-ESU decoder into the mix, wel....
But, yes, I still step each loco through a number of other speed steps to validate. And, if I plan to run in permanent consists, I always plan to tweak using the above method; just haven't had to change any CVs in the speed table in over a year while "tweaking".
-
With ESU decoders, I have found that I can near perfectly speed match (momentum aside) simply by setting the max speeds with the Accutrax II, and then setting a linear speed table (after doing the BEMF auto set). I have yet to find locos which don't consist nicely having done this. If throwing a non-ESU decoder into the mix, wel....
But, yes, I still step each loco through a number of other speed steps to validate. And, if I plan to run in permanent consists, I always plan to tweak using the above method; just haven't had to change any CVs in the speed table in over a year while "tweaking".
Hmmm. That's an interesting tidbit. I'll have to try that with the new SD35 I got to test out Atlas' sound installation (which is very good, BTW - better than IM's first iteration in the SD40-2).
John C.
-
Do you guys find a difference in speeds between a cold and warmed-up loco? That is, at a certain speed step the loco will run at different speed depending whether it is cold (at the start of an operating sessison, after sitting for few days) and when it is warmed up (after running for several minutes).
-
Not too much. I will run a loco for 15-20 minutes at around 75% throttle before doing any speed setting / matching, though. If the loco is brand new from the factory, I try to put at least 45 minutes on it before performing any installs or adjustments (which basically exposes any mechanical issues).
My train shed is not continuously heated in winter (only when I am out there), but I've never noticed any issues. Of course, we are only talking about San Francisco Bay Area weather. And I've never noticed an issue at show venues when firing up the layout in the early mornings (before the venue's heat has kicked in).
-
There was just a thread (Subject:CV 56 and Consisting!!!) on the LokSound Yahoo group about this. One poster recommended starting at 20 if you had this bucking problem. I have not verified since I my flat door has no grades but if you find going down to 50 hasn't solved it then lower apparently isn't necessarily bad.
I saw the same thread on the Yahoo group too. Good to know and something I may try if needed.
-
Do you guys find a difference in speeds between a cold and warmed-up loco? That is, at a certain speed step the loco will run at different speed depending whether it is cold (at the start of an operating sessison, after sitting for few days) and when it is warmed up (after running for several minutes).
I don't really notice a difference, but I haven't actually run an experiment with the Accutrack to see. Plus I figure that when I do an op session, everything is "cold" - I run the engines a couple of days before the session just to make sure none have developed issues, but they've been sitting for a couple of days by the time the session starts. And during a session, the road diesels don't see a lot of action (maybe 5 minutes of running before they hit Bellevue and we do a power change). So when I do speed matching, I don't run the engines around to warm them up first.
John C.
-
I once read that it was wise to warm the locomotives up first before speed-matching. In my experience, I have found that if I use the speedometer when they're cold, they might run at, say 66 smph and then go to 67 smph, and then 68 smph without touching the throttle after a couple of laps around the layout. Nothing more than a couple of smph, though. That's why I only warm them up for five or ten minutes.
DFF
-
Thanks for the info guys. I suspected that locos which have been sitting for a while (cold) would run slower than warmed up ones. But it appears that it is just couple of scale MPHs.
-
When talking speedmatching, throw out the Accutracks. Nothing even comes close to the ease of using the Boulder Creek Engineering Onboard Speedometer (http://www.bouldercreekengineering.com/rollby.php). It is by far my favorite and best ROI MRR accessory.
I couple the boxcar to the locomotive and get a real-time readout of it's SMPH displayed on my phone. After clearing the mainline, set the throttle to 50, adjust CV6 until the Speedometer reads 50. Set throttle to 100, then adjust CV5 the same. Dial the throttle down to 75, confirm speedometer reads 75, dial throttle to 35, 25, and 10 and you should see the speedometer read the same. With ESU decoders, it's almost always right on the money. TCS decoders will vary +/-3smph, but I think that's close enough. And I think I've only ever had to adjust CV2 once. The whole process takes as little as 30 seconds per locomotive, yes 30 seconds, and I am able to consist any unit with any other unit, including mixed decoders.
-
When talking speedmatching, throw out the Accutracks. Nothing even comes close to the ease of using the Boulder Creek Engineering Onboard Speedometer (http://www.bouldercreekengineering.com/rollby.php). It is by far my favorite and best ROI MRR accessory.
I couple the boxcar to the locomotive and get a real-time readout of it's SMPH displayed on my phone. After clearing the mainline, set the throttle to 50, adjust CV6 until the Speedometer reads 50. Set throttle to 100, then adjust CV5 the same. Dial the throttle down to 75, confirm speedometer reads 75, dial throttle to 35, 25, and 10 and you should see the speedometer read the same. With ESU decoders, it's almost always right on the money. TCS decoders will vary +/-3smph, but I think that's close enough. And I think I've only ever had to adjust CV2 once. The whole process takes as little as 30 seconds per locomotive, yes 30 seconds, and I am able to consist any unit with any other unit, including mixed decoders.
I was hoping you would pipe in on this.
I saw Mark use this at the NSC train show and it blew me away.
Thanks for posting this mark because I forgot to ask you where you got it.
-
OK. That's impressive. I'm sold!
John C.
-
Very cool!
DFF
EDIT: D'oh! The website says it's good for 3 smph to 200 smph. The Accutrack II will display speeds less than 1 smph, and I like to use 1 smph as the starting speed (CV2) when speed-matching.
-
Very cool!
DFF
EDIT: D'oh! The website says it's good for 3 smph to 200 smph. The Accutrack II will display speeds less than 1 smph, and I like to use 1 smph as the starting speed (CV2) when speed-matching.
Yes, the RollBy works by counting magnetic field rotations, so going super slow is prone to variance. But how often do you run at a constant 1smph? I find as long as things match up at 10smph, momentum takes care of the slower speeds.
-
Yes, the RollBy works by counting magnetic field rotations, so going super slow is prone to variance. But how often do you run at a constant 1smph? I find as long as things match up at 10smph, momentum takes care of the slower speeds.
Honestly, I use it often for coupling. I have Sergent Engineering couplers, and, like the prototype, I like to bring the motive power up to the cut of cars; stop; align the couplers, if necessary; and then couple up using speed step 1, so I don't shove the cars into the next county. Sometimes, I may have to back up and make a run at it to get the pin to drop, also like the prototype. But, generally, I try to use reasonable car handling to make this as realistic as possible.
But, back to my initial point, I just like to use 1 smph as the starting point for speed step 1 for consisting. I do like to see the power begin moving together and not bucking, or one unit not dragging the other. This has worked for me. YMMV.
DFF
-
I don't actually try to measure the scale speed at step 1. What I do is adjust CV2 (and sometimes I'll need to adjust the slow-speed BEMF parameters, although this is unusual) so that the engine just creeps as slowly as possible without any jerky motion at step 1/128. I just measured a set of 3 of my Atlas GP9's (a mix of non-dcc-ready and dcc-ready engines that I previously speed matched) at 96 seconds over 1 foot of track, or a scale speed of about 1 smph (technically 1.14 smph), without any jerky motion from any of the engines. Good enough. Like Dave, I want to make switching moves as realistic as possible, and that means ultra-slow at coupling (if my MT couplers are properly aligned, they will couple perfectly at this speed; in fact, that's how I tell whether I've got them aligned properly or not).
I credit the ESU decoders for their outstanding slow-speed control (Zimo is even better, IMHO, but ESU's sound decoders are a better choice for me, so I've standardized everything on ESU). I could never get this kind of slow-speed performance from TCS or Digitrax (although admittedly I have not used the most recent iteration of Digitrax decoders; I quit on them about five years ago, when I installed my first ESU LokSound).
The thing I like about the Onboard Speedometer is not so much for speed matching, but to get a better sense of operational scale speeds. One of the things I noticed about putting sound in my locomotives is that it immediately caused me to do everything more slowly. Hearing steam engine chuffs, in particular, is a pretty good antidote to doing switching moves at 50 smph. Similarly, hearing the diesel prime mover notch up and down keeps my speeds in check. But it would be fun to actually measure the speeds I use for mainline running, switching, yard work, etc. and the Accutrack really can't be used for a lot of this (it's too big to fit across a single yard track, for example).
John C.
-
I have actually found that, on some of my units, the Accutrax times out before the loco makes it through to the second sensor! The loco is moving nice and slowly (these are typically switchers, where I’ve set the max speed to about 50smph) so I don’t worry about it.
I got to play with Mark’s speedometer at last June’s n-Scale Convention in SLC, along with my Accutraxx. The two were in good agreement on scale speeds at normal operational speeds.
I agree with John, ever since I started adding more sound, I have found myself running at lower speeds. Makes opening up the throttle on those long stretches of FreeMoN country-side modules more fun.
-
Haha! I cheated last night. I put each locomotive on the tracks to see how the updates to the decoders on the LokProgrammer changed the running characteristics. As expected, they were off, as CV2, CV5, and CV6 were essentially restored to factory defaults. But, I pulled up the JMRI files (from my Mac) on each locomotive and used the numbers in the CV settings saved there, restoring the speed matching immediately. They all worked out perfectly with no further tweaking necessary.
Speed step 1: 1 smph
Speed step 63: 35 smph
Speed step 126: 70 smph
Today, I hope to download JMRI to the new laptop, so I can easily import the new information from the LokProgrammer files.
DFF
-
I have had much success with the LokProgrammer, with one exception. I have reprogrammed an SCL GP40, C&O GP40-2, A&R GP38, and SCL U36B. They all consist well with speed-matching, and I have even modified horn and bell settings to try to match the prototype. I may have to tweak these settings due to some educated guesses for horns and bells for these units in the mid-1980s. I have set them up, so that Mute (F8), Drive Hold (F9), Independent Brake (F10), and Dynamic Braking (F4) all work in a consist. Notably, I set up A&R #400 (without dynamic brakes) to go to Coast when the other units in a consist go into dynamic braking. It's cool to hear all of the units throttle back and then the fans kick in, except on No. 400, which stays in idle. Excellent!
The one problem that I haven't yet figured out is on my U36B, which has a Mars light in the nose. It flashed fine before I reprogrammed it. Now it's on all of the time (when I press F6), except when I activate the horn. Then, the Mars light flashes, but it goes back to "steady on" after a number of seconds (like it's set up for ditch lights). I have to figure out the setting that will allow it to flash all of the time when F6 is pressed.
DFF
-
Hi Dave.
You probably need to set the "Function Outputs" configuration correctly for whatever auxiliary function you are using for the Mars light.
First, determine what auxiliary function is controlling the Mars light via the Function Mapping screen. You know it turns on when you press F6, so look at the function mapping for F6 and see what it is turning on. Probably Aux1, but it might be something else (the choices would be head light, rear light, Aux 1, Aux 2, Aux 3, and Aux 4).
Once you determine what auxiliary function is controlling the Mars light, go to the Function Outputs screen on the LokProgrammer software, select that function from the list (for example, if Aux 1 is controlling the Mars light, select Aux 1 from the list). Now in the Output Mode (effect) drop-down list, select Mars Light. Set the brightness (I use full-on, or a setting of 31), and deselect Rule 17 and Dimmer.
Write the changes to the decoder. Now try F6.
John
-
Thanks, John!
That was the instruction that I needed. I determined that it was set up for AUX 1 and AUX 2 as ditch lights. I changed that to only AUX1, and that controlled the light on and off. What I didn't know how to do was to then go to Function Outputs screen. That was a part of the puzzle of the LokProgrammer that I was missing. There, I changed the function to Mars Light AND turned off the Grade Crossing function (that's what was making it flash only if I honked the horn). It works!
I then changed AUX1 to Gyra Light, which actually better represents the light fixture in the prototype SCL No. 1776. I was using "Mars light" generically, which I shouldn't have done. But, my ignorance of prototype railroad operation shows. Again, the Gyra light on Aux 1 with the brightness setting of 31 nails the look of what the light did before the upgrade to the software. I couldn't have done this without you. As always, thank you for your time and expertise.
DFF
-
Hi Dave.
You're welcome. ESU has a variety of different lighting effects; finding the right settings to properly employ them, however, is not exactly intuitive. This is one of the areas that I think JMRI actually does better than the LokProgrammer.
But once you understand that all this is "hidden" in the Function Outputs pane, it's pretty easy to access from the LokProgrammer.
John C.
-
Hi Dave.
You're welcome. ESU has a variety of different lighting effects; finding the right settings to properly employ them, however, is not exactly intuitive. This is one of the areas that I think JMRI actually does better than the LokProgrammer.
But once you understand that all this is "hidden" in the Function Outputs pane, it's pretty easy to access from the LokProgrammer.
John C.
I have learned a ton since I started playing with the LokProgrammer just a few days ago, and I'm sure that I haven't even scratched the surface on what it can do. However, as I become more comfortable with the LokProgrammer, I am now finding much and much less use for JMRI. I haven't even bothered to download JMRI to the new laptop yet.
DFF
-
The best thing for JMRI use is all those tweaks that can be done with PoM in real time: sound and volume adjustments on the different sound slots (with immediate feedback); lighting functions and brightness adjustments; momentum; speed tables; etc. Then, when everything is just how you like it, go back to LP and read the decoder back into its project, and write again, with “set as default” checked. Then, a decoder reset gets you back to YOUR base settings.
-
. . . and write again, with “set as default” checked. Then, a decoder reset gets you back to YOUR base settings.
I didn't even know that this was a thing! Good to know.
Thanks,
DFF