Perhaps there is something diagnostic in that the cab light doesn't come on and go off in precise 'sync' with the stopping. I know nothing about what functionality switches the cab light but it's not synchronized to the prompt stop.
PruittIf power to the loco is interrupted at all, the loco comes to a screeching halt for about a second or so! Then it starts moving again. Sound isn't interrupted and lights stay on, so there must be a keep alive circuit on the decoder. In fact, the sound continues for about 15 seconds after power is removed from the rails. But the loco goes through what I can only describe as a really idiotic startup routine for even the briefest power interruption - the loco stops dead and the cab light comes on for a second, shutting off after the loco starts moving again.
The more I look into this, the more I'm convinced the problem wasn't actually caused by interruptions in power. Going back to your video, when you were running the loco with the clips and temporarily removed power, the loco would go right back to running and the cab light would not come on. When the loco would stop while on the layout the cab light would come on and it would take a second to go back to running. After seeing the "fix" this kind of makes since. The decoder is seeing these broadcast stop packets (or what it thinks is broadcast stop) and thinks it's supposed to stop so it does and turns on the cab light.
This could partly explain why some people seem to have so much power pickup problems with some BLI locos while others do not - for some it could be this issue instead that they are actually seeing.
I'm still not actually convinced that it's broadcast stop packets that the loco is seeing, however. I just have a hard time believeing that if NCE was actually sending them there wouldn't be problems with other locos. I wonder if they could be misinterpreting idle packets as stop packets. There is no standard for how often or even if the command station sends idle packets. With the stop packet count set to 6, the default for Paragon3 steam, it's entirely possible for NCE to sometimes send six or more consecutive idle packets while other command stations may not. I may have to set up a DCC++ system and modify it to send differing amounts of idle packets to test my theory at some point because now I'm really curious about it.
Overmod CV 244 is one of those in the 'manufacturer reserved' range, so someone needs to consult both BLI and NCE to see what they have the 2s and 4s in their binary representation doing -- both will be important to this issue, or the value would be 36 or 34 respectively.
CV 244 is one of those in the 'manufacturer reserved' range, so someone needs to consult both BLI and NCE to see what they have the 2s and 4s in their binary representation doing -- both will be important to this issue, or the value would be 36 or 34 respectively.
As I stated before, according to the reference manual the "2s" and "4s", as well as trhe "1s", (bits 2, 1 and 0) are the number of boradcast stop bits required to stop the loco and setting all three to 0 disables the broadcast stop function on the decoder.
tsd...I would be curious as to what you read that CV as if you reset the engine. I honestly just wonder if that production was incorrectly set on that CV to something else, or left "blank". That would explain why your other BLI engines did not have that issue while this one did.
The only reference I saw to other BLI engines of his he described as "early-era". If they are Paragon2, according to the steam reference manual the default value of CV 244 was 0 in the Paragon2.
CSX Robert Pruitt Anyway, the note that came back with the loco said "If this decoder ever has to be reset, be sure to set CV244=32 if it is being run on an NCE system." That is interesting. According to the Paragon 3 steam technical reference manual that CV controls two things: the upper four bits control if and how much the loco slows when the break squeak is activated and the lower three bits control how many consecutive broadcast stop packets the decoder can see before stopping. The default setting of 38 enables the slowdown and sets the stop packet count to 6, changing the setting to 32 enables the slowdown and disables the stop packet count. If that CV really works as described, then is the NCE unit really sending these broadcast stop packets? If so, why, and why are other locos not stopping? Is NCE sending something else that the decoder is falsely decoding as stop packets (that's what I'm currently inclined to believe)? Many people won't care as long as it works, but some of us would really like to know what is actually going on. I kind of wish I had an NCE system to test with.
Pruitt Anyway, the note that came back with the loco said "If this decoder ever has to be reset, be sure to set CV244=32 if it is being run on an NCE system."
That is interesting. According to the Paragon 3 steam technical reference manual that CV controls two things: the upper four bits control if and how much the loco slows when the break squeak is activated and the lower three bits control how many consecutive broadcast stop packets the decoder can see before stopping. The default setting of 38 enables the slowdown and sets the stop packet count to 6, changing the setting to 32 enables the slowdown and disables the stop packet count. If that CV really works as described, then is the NCE unit really sending these broadcast stop packets? If so, why, and why are other locos not stopping? Is NCE sending something else that the decoder is falsely decoding as stop packets (that's what I'm currently inclined to believe)? Many people won't care as long as it works, but some of us would really like to know what is actually going on. I kind of wish I had an NCE system to test with.
I would be curious as to what you read that CV as if you reset the engine. I honestly just wonder if that production was incorrectly set on that CV to something else, or left "blank". That would explain why your other BLI engines did not have that issue while this one did.
CSX Robert Actually, according to page 205 of the Paragon 3 steam technical reference manual, the default is 38 (it does appear to be 32 for the diesels).
Actually, according to page 205 of the Paragon 3 steam technical reference manual, the default is 38 (it does appear to be 32 for the diesels).
Oops, because of topic drift I had diesel in my head and looked at that manual and not the steam manual.
PruittAnyway, the note that came back with the loco said "If this decoder ever has to be reset, be sure to set CV244=32 if it is being run on an NCE system."
CNR378 Reviewing the BLI manual and the defintion in JMRI, it looks like 32 is the default setting for CV 244. So if you reset the decoder then CV244 should = 32 Peter
Reviewing the BLI manual and the defintion in JMRI, it looks like 32 is the default setting for CV 244.
So if you reset the decoder then CV244 should = 32
Peter
That is assuming that it was not tweaked or incorrectly set from the factory. That is why you and JMRI CANNOT just take the "default" CV values out of the BLI manual and call it a day.
tstage I was told by a few modelers here that both the Paragon2 & 3 SW7s don't go very fast. The 2009 MR review of the Paragon2 SW7 listed a top speed of 28 sMPH. I tried resetting the Paragon3 decoder to factory settings. I also tried adjusting CVs 5 & 6. I even replaced the Paragon3 with a TCS LL8 decoder. No change in top speed from any of the above adjustments. If it isn't gearing then it's possible that BLI might have used a low RPM motor? Tom
I was told by a few modelers here that both the Paragon2 & 3 SW7s don't go very fast. The 2009 MR review of the Paragon2 SW7 listed a top speed of 28 sMPH.
I tried resetting the Paragon3 decoder to factory settings. I also tried adjusting CVs 5 & 6. I even replaced the Paragon3 with a TCS LL8 decoder. No change in top speed from any of the above adjustments.
If it isn't gearing then it's possible that BLI might have used a low RPM motor?
Tom
I'ts certainly possible on the motor end of it. Next time I have one of those switchers here, I'll mess around with it and see if I can get more speed by tweaking CV's and putting in say AC6000 sounds/code in the Paragon 3/4 decoder for kicks.
In any case, glad you shared that information as to what CV was causing the issue / helped. I've saved that here in the event I have a customer ask me about it through my website, that I can recommend them trying that. Sort of how I have a CV in the event JMRI/NCE cannot program/read CV's, that once tweaked, fixes that issue.
As a side point, part of the issue with this industry is that not everything works or is a perfect standard and percise. So many of these CV's exist to try to work around issues that could come up for various reasons. A motor could be slightly out of spec or take more energy to pulse when it comes to programming, or in this case related to how that spcific controller works. Or again, could just be the default was not tuned right. For the CV you listed:"The locomotive is slowed when the brake squeal is activated. The rate the locomotive slows is determined by values sss. bbb = 0-7 [0=disabled; 1-7=consecutive broadcast packets received] Some controllers can send broadcast stop packets which will halt the locomotive. The amount of consecutive broadcast packets may be set by placing a vale of 1-7 for bbb. "
maxmanAnd that setting was....?
Anyway, the note that came back with the loco said "If this decoder ever has to be reset, be sure to set CV244=32 if it is being run on an NCE system."
So that implies that there is something peculiar about how BLI locos respond to NCE systems. Very interesting. I'd sure like to know what that is.
But I'm keeping that note in the box the loco came in so I don't lose it.
While BLI was very helpful through the entire issue, and they suggested I don't buy the "go pack" (their version of a keep-alive), since the loco already has one incorporated into the decoder (although they said the decoder will accept one, and it would probably eliminate the issue. They said it would not solve whatever the underlying problem was, but would mask the symptom), it would have been nice if the rep I spoke to knew about this setting. Had she suggested the CV change, I would have saved nearly $50 in shipping costs to send them the loco (and would have saved them the return shipping cost).
Still, I'm a very satisfied customer at this point. They fixed the problem at no cost other than shipping, for which I couldn't reasonably expect them to reimburse me. The loco runs great, and I know what to do in the future if I buy another one (as is likely at some point) and it displays the same behavior.
Mark P.
Website: http://www.thecbandqinwyoming.comVideos: https://www.youtube.com/user/mabrunton
https://tstage9.wixsite.com/nyc-modeling
Time...It marches on...without ever turning around to see if anyone is even keeping in step.
tstage I have purchased only one BLI diesel: A Paragon3 SW7 switcher. While the sound and motor-control is fine, the gearing is waaaay too slow. Wide open it will only achieve 20sMPH. No, I'm not a fan of hyper-speed operations. However, I do want to see a locomotive that will actually reach its prototype max speed, which in the case of the EMD SW7 is 65 MPH - BION. Even 45 MPH would be acceptable to me. 20 MPH...no
I have purchased only one BLI diesel: A Paragon3 SW7 switcher. While the sound and motor-control is fine, the gearing is waaaay too slow. Wide open it will only achieve 20sMPH.
No, I'm not a fan of hyper-speed operations. However, I do want to see a locomotive that will actually reach its prototype max speed, which in the case of the EMD SW7 is 65 MPH - BION. Even 45 MPH would be acceptable to me. 20 MPH...no
Just wondering, but you ever try adjusting CV66 to something like 200 or 255 and see if its much faster in forward direction? If so then adjust CV95 for the reverse direction as well. I know there are some things that can be tweaked to help improve. I've programmed the wrong code before into one of their switchers decoder and it ran pretty quickly. So I don't believe its always just because of gearing. Like if you take the shell off and run it at full speed, my guess is that the motor itself is just not running very fast.
I don't recollect purchasing any new BLI steamers since they released their Dreyfuss Hudson back in 2010. I'm quite content with my two Hudsons (steamlined & un-streamlined), two Mohawks, and one Blueline Niagara so I don't expect to make anymore BLI steam purchases in the foreseeable future. That said, if they brought out a 2-8-2 H-10a Heavy Mike or a L-2a Mohawk - with the "unibrow" EFW heater over the front boiler plate - I would give those some serious consideration.
No, I'm not a fan of hyper-speed operations. However, I do want to see a locomotive that will actually reach its prototype max speed, which in the case of the EMD SW7 is 65 MPH - BION. Even 45 MPH would be acceptable to me. 20 MPH...no.
I picked up the Walthers SW7 switcher earlier this year and it's a sweet li'l locomotive. It runs great and has better/correct detail compared to the BLI SW7. I'll probably eventually sell the BLI SW7 to someone who will appreciate it more.
I feel fortunate that I stopped acquiring BLI locomotives over the past seven years. For one thing, other makes and models, such as the Rapido RS18 and the Atlas RS3 that I caught in that time, were my choices to add to the stables. But, and I'm an ardent fan of BLI steam, I sensed they were going through a tough time between about 2016 and until about the midpoint of last year. I have no Paragon 3 versions of anything because none of it appealed to me and because of complaints.
Recently, I purchased a 4000 series Mikado from the Santa Fe because it looked to be a substantial improvement in detailing over the USRA versions in P3 variety. I'm happy to report that it is indeed beautiful to behold up close, and it runs so very much better with a cap installed. This will be my go-to from now on. I find DCC works very well for me, some intransigent steamers notwithstanding, and with so many new releases of all kinds coming with caps installed, it just makes the whole enterprise so much more fun.
I'd like to know too, but I doubt I will every own a BLI for the reasons stated above and in nearly every thread about BLI
Henry
COB Potomac & Northern
Shenandoah Valley
Their diesels can have issues too, will never buy another one.
It doesn't speak well of BLI's quality control department that so many problems would be so common. Earlier BLI steamers had an all too common problem of not getting electrical pickup from the drivers on boths sides which appears to be a wiring issue. It would cause stalls when the powered tender wheels passed over an insulated frog. At one time, I thought the problem was confined to my K4 but after some testing, I discovered 4 other BLI steamers with the same issue. I think the others weren't giving me problems because the tenders had pick up in both front and rear trucks. There is a lot to like about BLI locos but because they have done such a poor job of quality control, they are dead to me.
I would like to know as well what exactly it was.
PruittThe loco came back from BLI about three weeks ago. According to the repair sheet, they just changed a setting on a CV. The sheet also implied that this is an issue with NCE systems.
And that setting was....?
I just realized I hadn't closed out this story.
The loco came back from BLI about three weeks ago. According to the repair sheet, they just changed a setting on a CV. The sheet also implied that this is an issue with NCE systems.
Seems like it would save them and the buyers time and money (shipping costs, if nothing else) if they'd put an info sheet in the packages saying to change that setting if you have an NCE DCC system.
Funny thing - I could swear I tried changing the setting they say they did.
But in any case, the loco runs great now! I'll certainly keep that repair sheet in the box so I'll have it if I ever need to reset the decoder.
No problem. I know theres a ton of things that it could be CV wise is all and thats at least the one he said is not always right out of the gate since engines weight and other things can all impact it. From what he told me, it should not be related to the hardware or software of the decoder itself, but going to be something with how it was tuned. Its the same hardware for each HO scale engine, diesel or steam. So if it only happens on some steam and not all, then would point to being a tuning issue for sure. If every single one they do does the the same thing, then maybe it is something else and just never brought to his attention to check into.
Lowering CV5 is one of the first things I do when setting up a new decoder. I set CV5 to where the engine tops out where I want it to, then set CV6 halfway in between the value in CV5 and zero. I don't recall exactly where I set it off hand on those engines. I don't use JMRI (yet) and don't have a good history of writing down the settings. That hasn't bit me yet though as I haven't had to readjust any of them that I recall. The only engine I didn't lower CV5 in was a Bachmann sound value 2-8-2 that was slow to begin with.
Thanks for asking about it though.
Mike
Overmod I suspect this is a buffer problem, and what I'd like to see is some experimentation on exactly how fast the speed steps can be taken before the problem appears. Since there is no reverse communication from decoder to throttle, the decoder will be doing the digital equivalent of 'debouncing' on received changes in commanded-speed value. If that received value changes too rapidly the decoder may not be able to resolve the value, and 'fail safe' (stop, to avoid liability for runaways or run-on issues) until it resolves good speed data. Another potential diagnostic is whether any momentum effects are observable as the decoder 'realizes' the commanded speed and slews the motor output to achieve it. Of course, this could just as easily be an issue with the controller's processing the speed change, especially if the 'speed display' only measures counts off the thumbwheel encoder or voltage differences off a pot, and not the actual code being sent over the DCC to the decoder. I can easily see the internal circuitry not getting a 'lock' long enough to calculate and physically transmit a value... and defaulting to something 'safe' while it resolves its confusion...
I suspect this is a buffer problem, and what I'd like to see is some experimentation on exactly how fast the speed steps can be taken before the problem appears.
Since there is no reverse communication from decoder to throttle, the decoder will be doing the digital equivalent of 'debouncing' on received changes in commanded-speed value. If that received value changes too rapidly the decoder may not be able to resolve the value, and 'fail safe' (stop, to avoid liability for runaways or run-on issues) until it resolves good speed data. Another potential diagnostic is whether any momentum effects are observable as the decoder 'realizes' the commanded speed and slews the motor output to achieve it.
Of course, this could just as easily be an issue with the controller's processing the speed change, especially if the 'speed display' only measures counts off the thumbwheel encoder or voltage differences off a pot, and not the actual code being sent over the DCC to the decoder. I can easily see the internal circuitry not getting a 'lock' long enough to calculate and physically transmit a value... and defaulting to something 'safe' while it resolves its confusion...
Try adjusting CV5. I asked their developer about it and he said that is usually the issue, that it is set too high. Try lowering it and see if it improves. And that would make sense why its not like its all of their engines, etc. The default CV in their manuals are very generic. Each production run/engine gets tuned and the sound file is what has the default CV's for that particular engine.
So try adjusting CV5 to being lower and see if that helps.
I struggle with the idea of it being the controller as I have engines with decoders from QSI, Paragon 2, Paragon 3, Soundtrax, TCS, ESU, NCE, and whoever made the cheap-o bachmann non-sound decoders. The Paragon 3's are the only ones to exhibit this behavior, and I run this way with all of them. There are no momentum effects when it does it either (or at least ridiculously minimal). When I say it stops now, I mean it stops NOW. Kind of like Pruitt's at the start of this thread, but mine is clearly tied to decelerating quickly.
tsd I wonder if its because a very quick throttle change, it does not see any kind of load because of that, if wide enough, and overly slows down then and then realizes.
Water Level Route The ones that jump to mind (and it seems like I'm missing something) is the P2's don't retain momentum settings (BLI confirmed this). As for the P3's, while running, a quick scroll of the thumbwheel (NCE Powerhouse) for a quick reduction in speed step (lets say from speed step 80 to 60) will make the locomotive stop. Completely. Right now. Then it will accelerate to speed step 60. To be clear this is not a pickup issue. It only happens with a quick reduction in throttle. And it happens every time I do a quick reduction in throttle. There are some disappointments in the sound (like the chuff gets noticeably quieter on the P2's when you blow the whistle), but I can put up with a lot of that. Issues that affect performance are another matter.
The ones that jump to mind (and it seems like I'm missing something) is the P2's don't retain momentum settings (BLI confirmed this). As for the P3's, while running, a quick scroll of the thumbwheel (NCE Powerhouse) for a quick reduction in speed step (lets say from speed step 80 to 60) will make the locomotive stop. Completely. Right now. Then it will accelerate to speed step 60. To be clear this is not a pickup issue. It only happens with a quick reduction in throttle. And it happens every time I do a quick reduction in throttle.
There are some disappointments in the sound (like the chuff gets noticeably quieter on the P2's when you blow the whistle), but I can put up with a lot of that. Issues that affect performance are another matter.
Interesting, never seen that myself or had a customer send something in for that kind of thing, but odd indeed. I wonder what would casue it or why they couldnt update their code to fix that kind of thing. Wonder if disabling back emf would make a difference or not. Also maybe CV120. I know I have seen some where the default CV's for the engines tuning maybe was not quite what it should have been, making them either jerky under load, or with no load, or just at slow speed, etc. I wonder if its because a very quick throttle change, it does not see any kind of load because of that, if wide enough, and overly slows down then and then realizes. Will be asking their engineer though about it as I am curious about it. It seems like its an art too at times to have them tuned perfectly, and partly why when I work on engines here, I typically do not include or do that kind of thing for customers, because what I may find is good, they may not and would tweak it anyways.
The chuffing, that I have herd myself and always thought it was quite odd. I don't think Paragon 3 or 4 have that issue, but now I want to program some decoders and plug in a speaker and test haha
tsd Water Level Route I have 7 BLI steamers. 4 have the P2 decoder, 2 have the P3 decoder, and 1 came without a decoder (thank goodness). The P2's and P3's will all have their decoders replaced as time/money allows, starting with the P3's. The issues I've experienced are not anything I was really out in the weeds doing either. Minimal product testing should have brought the issues to light. Here's another vote for BLI to go either with Tsunami/TCS/ESU or offer DCC ready. Just wondering, but what kind of issues with them all? I know a lot come down to personal peference with some things, either around sounds, or say lighting control, etc.
Water Level Route I have 7 BLI steamers. 4 have the P2 decoder, 2 have the P3 decoder, and 1 came without a decoder (thank goodness). The P2's and P3's will all have their decoders replaced as time/money allows, starting with the P3's. The issues I've experienced are not anything I was really out in the weeds doing either. Minimal product testing should have brought the issues to light. Here's another vote for BLI to go either with Tsunami/TCS/ESU or offer DCC ready.
I have 7 BLI steamers. 4 have the P2 decoder, 2 have the P3 decoder, and 1 came without a decoder (thank goodness). The P2's and P3's will all have their decoders replaced as time/money allows, starting with the P3's. The issues I've experienced are not anything I was really out in the weeds doing either. Minimal product testing should have brought the issues to light. Here's another vote for BLI to go either with Tsunami/TCS/ESU or offer DCC ready.
Just wondering, but what kind of issues with them all? I know a lot come down to personal peference with some things, either around sounds, or say lighting control, etc.