In April I bought a BLI Paragon3 Consolidation. It sounds good and runs well, except for one really bad issue.
If 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.
Anyone have any idea how to fix this really obnoxious behavior? If not, on Monday I'll call BLI.
Mark P.
Website: http://www.thecbandqinwyoming.comVideos: https://www.youtube.com/user/mabrunton
Mark, I do not own any Paragon 3 steamers, but I have read about a similar problem on other forums. Closely check the plug that connects the tender wiring to the engine. Make sure that the plug is firmly seated.
Rich
Alton Junction
Ha ha! I just bought one and I noticed the same thing. The thing just stops on a dime detailing the cars behind it! Anyway, I cleaned the wheels and it did seem to help. Also, I noticed that anywhere the DCC bus crossed the track, the loco would stop there. Maybe a bit of crosstalk? I just finished moving the bus Away from the track and now we are problem free.
JJF
Prototypically modeling the Great Northern in Minnesota with just a hint of freelancing.
Yesterday is History.
Tomorrow is a Mystery.
But today is a Gift, that is why it is called the Present.
JDawgHa ha! I just bought one and I noticed the same thing. The thing just stops on a dime detailing the cars behind it! Anyway, I cleaned the wheels and it did seem to help. Also, I noticed that anywhere the DCC bus crossed the track, the loco would stop there. Maybe a bit of crosstalk? I just finished moving the bus Away from the track and now we are problem free.
Rich, I checked the plug and it's fine. I also did a hard reset on the decoder and that didn't help.
I've posted a short collection of raw video clips to illustrate what the problem is. The last couple of clips I have the loco inverted and am powering it through test leads. Note that the sound never stops, but the motor does, and when power is actually interrupted, the motor tries to play "catch up for a second or so before slowing back to the throttle setting.
By the way, all my other locos navigate these same areas without hesitation. Cleaning the track does help, but with six pick-up points on each side of the loco (4 drivers and two tender wheels), there should not be an issue.
Anyway, here's the video:
I'll be calling BLI on Tuesday - apparently tech support isn't open Mondays. If they can't alleviate this problem, they'll find they have one less BLI customer.
Wow, that is worse than I imagined.
Let us know what BLI has to say when you call.
If you don't interrupt the power by removing the clip lead does it continue to run?
If it does it seems like it must be losing power when it is running on the track but turning it upside down changes something..
Same goofy performance here. Ordered one in March, 2021. Didn't notice the "catch up" problem because my track must be OK. I tried it today with intentional power interuptions and sure enough! I did notice that, compared to an older BLI 2-8-0, they've added a keep alive to the sound decoder but not to the motor portion. I will be standing by for details on BLI's respons.
mvlandswIf you don't interrupt the power by removing the clip lead does it continue to run? If it does it seems like it must be losing power when it is running on the track but turning it upside down changes something..
The track is very clean. The problem lessens when I run a brite boy over the track, but I'm not about to start doing that every time I fire up the layout. Especially when 0-6-0s and my Bachmann 10-wheeler run just fine on the same track.
I have a love/hate relationship with BLI. Up until the introduction of Paragon 3 it was more love. After P3 is when the real disappointment began.
Mind you, their tech support has been very helpful and they don't hesitate to send replacement motors and decoders for me to do the repair rather than sitting in Ormond Beach for weeks (months?).
My latest two PRR K4s exhibited the exact problem you are experiencing. They would abruptly stop at specific points on my layout, now get this, the streamlined K4 stopped dead at locations A, B, C & D. The other K4 with practically identical running gear would stop at point C and two other spots E & F. nearly every time.
Emails to BLI got me two replacement decoders which demonstrated the exact same behavior. Yes, I believe there is a good-sized capacitor on the board but it has no relationship to the motor drive.
For that I installed a "Go-Pack" BLI's new motor capacitor add-on.
BLI_K4_cap2 by Edmund, on Flickr
If your board is Revision G or later there is a socket on the board for it. In the photo above I soldered it directly to the PC board per their instructions. This solved the problem. In the photo below I show the plug-in, rev. G board.
BLI_K4_cap by Edmund, on Flickr
There were other programming headaches with several other P3 locomotives I have. Also the three P5a's have had their motors and decoders replaced. These locomotives also suffer from intermittent motor stoppage. I have them MUed and as one stalls the other two pull the trio along until it begins to rev up just as another one will stall a few feet farther down the track.
All three of these will soon be getting a Soundtraxx Current Keeper II.
Recently I've been "evaluating" many of my older QSI and early Paragon BLI engines. I've replaced the stock decoders with Tsunami 2s and I'm vert satisfied with the results. I also upgrade the speakers, do a COT&S, swap out any incandescent lamps and look for potential problems.
On two of the PRR I1sas I tore apart I found all five of the left driving wheels were not picking up current from the rails! These are heavy engines. It took a while but I found one place where the engine PC board screws to the frame and this screw is supposed to conduct power from a pad on the frame to a pad on the PC board where the screw passes through.
There is a chemical blackening material applied all over the frame and I believe this was acting as an insulator. Once I filed that off, cleaned the solder trace at the hole in the PC board and everything returned to normal.
My first Paragon 3 was a PRR H-10 2-8-0. This thing ran like, well, awful. I pulled off the tender shell to search for a loose wire or pinched wire but didn't see anything.
When the engine would die, I could very lightly tap the open tender, VERY lightly, and the engine would take off again. While giving the engine a careful exam I could see a gray wire with a brass terminal sitting between the third and fourth driver!
IMG_5134 by Edmund, on Flickr
This wire, which had never been screwed down from the factory, carried power from the left drivers (again) and I thought repairing it would have cured the problem but it didn't.
As I recall it went back to BLI and they sent me a replacement which seems to be running OK, although I had better check, I haven't run her in a while.
Same with a PRR L1 2-8-2. I was just evaluating it last night and, sure enough, it runs a few feet and dies. This engine will be getting a Tsunami next week.
With over fifty BLI engines on my roster most of them run trouble-free, going back almost twenty years to the very early GG1 and NYC Hudsons. Mechanically the locomotives are quite robust and run smoothly. My frequency of troubles really increased with the Paragon 3 and the "Rolling Thunder", which I gave to Cuda Ken.
Hopefully the Paragon 4 will cure the ills inherent in the P3 architecture. Again, for all these recent (past five years?) faults, BLI has been good at trying to cure them. I'll give them credit for that.
As for your engine you might want to consider the $25 for the "GO Pack". Seems a shame to have to spend money to cure something that should never have been a problem but, it IS a workable cure.
Good Luck, Ed
So having worked on BLI engines for years, I can say for a fact you do not have a GoPack and that the issue will more than likely be with the motor. Paragon 3 does not have a GoPack built in like Paragon 4, and the caps on it would only keep the engine running in the miliseconds if power is interrupted. Unless a GoPack was soldered on the decoder, that would not be the issue. Also too, while Paragon 4 may have it built in, it is much "smaller" than the GoPack is. So often when I upgrade say Paragon 2 or such to Paragon 4, many still opt for the full size GoPack (as it still has the plug for it), and I usually recommend it for large/heavy engines, or if pulling a heavy load, or lots of uphill grades, etc. as the larger the load, the less run time you get with a GoPack/Current-Keeper, etc).
If the decoder is a newer revision Paragon 3, it would have a new motor controller chip on it (you can tell if yuo look at the instructions for soldering a GoPack on their decoder, because one of the leads goes to the motor controller chip, which would look different if you have a newer one). That chip is a very good thing because it will stop the decoder from burning up due to a bad motor, but can cause fustruation as many have not the greatest understanding in the electronics and "blame" it on the decoder, etc. The chip they use now has its own built in protection in the chip for over current conditions from the motor. Meaning if the motor trys to draw to much current, the chip itself will cut power off towards the motor. So my guess is that it starts to over draw, the chip cuts power, then it seens its current "requirement' lower, so it lets it run again.
If you have a DC power supply, you could test this by taking the shell off of the engine and attaching the motor leads (usually I remove the 2 wires from the connector on the decoder and clip in there) and hold the flywheel and set the power supply to allow, say, 3A of power. The shell being off is mostly so you can hold the flywheel to test it under load, without holding the wheels from the bottom which can risk stripping gears. If it is drawing over 2A of power, then you have a bad motor and should replace it. BLI is pretty good about just sending parts if people already troubleshoot the issue and its clear where the issue is at. All in all, I know many here do not like Paragon 3 and such, but what many do not know/understanding is that in most cases, the issues were due to bad motors and not necessairly the decoders themselves (at least for their HO scale decoders). Even know they had built in CV's to watch for overcurrent, to try to protect the motor controller, those CV's could be tweaked, or still could over time if boarderline bad, still cause the motor controller chip to burn out. Of course with the later Paragon 3 and all Paragon 4 decoders, the chip has it built into it now, so that should never be an issue again (at least due to the motor being bad). Often that why when people ask me if its worth upgrading their old QSI ones to say PAaragon 3 or 4 over buyign new, I often say yes, because the motors are really good on the old, and often they run smoother after the upgrade due to better speed control/electonics, etc.
Thanks for all the helpful suggestions and feedback, everyone.
I talked with a very nice lady in BLI Tech Support today. She basically said this is an issue with, in particular, the Consolidations. She offered two options - send the entire loco back and they would replace the decoder - 6-8 weeks' lead time - or remove the decoder and send it in and they would send me a new one - about a week's lead time.
I asked about the "Go Pack," and she said theose were designed expressly because of the Consolidation's sensitivity to power interruptions. The decoder's on board capacitors keep the sound going across minor power interruptions, but not the motor.
Because all my turnouts are dead frog, I opted to add the Go Pack and see if that resolves the issue. She said she thought it probably would, but if not, they would still replace the decoder. I'm a big fan of keep-alives anyway, so the Go Pack is on order.
Ed, your detailed explanation of the Go Packs you've installed, and the problems you've had with the Paragon3 units was especially helpful.
tsd, my Consolidation is very recent (Tech Support could tell from the item number), so the decoder is rev. H. It has the socket for the Go Pack, so it should be a matter of five minutes to get it installed and running once it arrives. I don't know about the motor current, and while I have an MRC Tech 2 power pack, I don't have a way of testing the amperage draw at stall (or maybe I do. I have a RRamp meter and could probably use that...). With the latest revision of decoder it's probably got the overcurrent protection you talk about.
I have four early-era BLI Mikados that I might be interested in upgrading to Paragon4 if it's not too difficult. I don't suppose you'd be willing to post a detailed set of instructions? A YouTube video would be even more helpful... IF you don't have a YouTube channel you could send a video to me and I could post it on my channel (with proper credit to you, of course.).
Thats good, then it honestly should not be a bad decoder anyways. I usually recommend GoPack's as well for any of my customers, even with a Paragon 4 because more capacity can't hurt if talking about reliability for power, and the relativly low cost of them.
A test that you may be able to do, to rule out it being a motor verses power issue would be to simply take alligator clips and clip track power to the tender wheels and then run it upside down. Put light pressure on the wheels to simulate a load, and see if the issue replicates. If it does than a GoPack would not fix that; either the decoder, or the motor (my money is the motor) is bad. I know BLI has done it, as I have repaired engines that BLI had replaced the decoder in but the issue was the motor, causing the decoder to fail again later , and I know I have had a few where I replaced the decoder but did not check the motor and ultimatly the engine came back and at that point I test the motor and verify it was actually bad (of course with the later Paragon 3 and all Paragon 4 decoders, the chip itself will not blow now due to a bad motor).
In watching your video again, I just do not believe it is going to be a power issue. Generally if it is, the engine will completly power down, sound and all. The fact that it stops very abruptly like that and then starts again would really indicate to me that the motor controller just stops sending power out to the motor, and then the draw goes down, so it allows power to go back to the motor. Generally too if its a case of loosing power, I tend to see a little more momentem in the engine when it looses power, and then it may start back up, but would go through startup sounds. Does it happen on just speed step 1? Or again if you have the engine on the side or upside down with power to it, so no load, does it happen?
I know people give Paragon 3 a bad rap and hope 4 is better, but most do not understand that the majority of the issues are/were due to the motors or pickups issues and not necessairly the decoder. Most of those issues at this point are resolved as they were related to the factory. Paragon 2, Paragon 3, Paragon 4 are essentially just "upgraded" from eachother. So Paragon 3 is basically the Paragon 2 decoder but "tweaked/upgraded" hardware and software updated for the changes. Paragon 4 is more less the same, but they did decide to change the code revision back to 1 verses the 20 or so they were at between Paragon 2 and 3, and of course they added in the mini GoPack (just changed the cap on it to the new setup. I know the engineer who developes the decoder, hardware and software of it so I am very well aware how the electronics and it all works together.
So with that said, any reliable Paragon 2 engine, or Paragon (QSI, etc), would have no issue with a Paragon 3 or 4 decoder in it and would not have any issues like many may have had with a brand new Paragon 3 engine. Just some added background, but I have looked at/repaired/upgraded around 200 BLI engines this year and around that many for the past few years. Many are just people wanting the newer electronics in their engines, to shorts, old QSI ones that have shot decoders since BLI does not have them anymore, etc. Infact, I have an old Brass Hybrid on my bench right now that I guess has been to BLI a couple of times, never fully resolved the issue, and come to find out, the rear wheel set insulator is bad now, shorting across (now to my surprise, BLI has replacemts still for it which I will be picking up tomorrow). The only thing I do not really work on is mechanical issues. So most of those numbers would be decoders or electrical issues, shorts, etc. So even with hardly any true Paragon 4 releases out there, I have been putting them in engines now for the past 6 months or so. I get a number of people who like the idea of a GoPack but can't fit it in the engine, so many just have been buying Paragon 4 decoders from me to swap out themselves.
For your early era engines, I assume your talking about with QSI electonics inside? I don't have any videos that I publish for it, but I do include the information necessary with the decoder when someone buy's a decoder to upgrade an older engine or non BLI engines from me (which I program when purchased, so it always has the latest code from BLI). So kind of like a self upgrade kit for those who want to use their decoder in, well, really any engine. I have had some buy it and put it in 30 year old brass engines. Essentially you have 6 wires from the tender, usually ordered the same, so you just cut them inside the tender from the connector and solder on the new wires, push them in the connectors and then mount the board (often I use a good double sided sticky tape if the decoder mount holes do not match the new). Some have grain-of-wheat bulbs for the headlight, so those also would have to be replaced with an LED (no resistor has to be added inline for it). I typically do not do that work myself, upgrading a non BLI engine, but I don't mind supplying to others who want to do it, and BLI has given me approval to do that as well.
Sorry for a second comment. Mine are being "approved" right now and I went back to the video again you had posted, and of course is what I get for not watching it to the end. It looks like at one point with the aligator clips on the wheel directly it did the same thing as well at some point? If thats the case and to make it easy, just connect both leads to the tender and run it, putting a little but of a load on the drivers and see if the same thing happens.
What I don't get is that with no power to it, the sounds did stay on. That would tell me it must have a GoPack or is not rev H but is rev I which has the mini GoPack built into it. Rev I close to what is being called Paragon 4, but the true Paragon 4 is called 400-A now, looks the same as rev I but has 1 additional small plug on it, like the GoPack one but a 4 wire, and is for future use. Rev I if on the latest code for that would have pro mode for lighting.
This is important because it may be able to be tweaked via CV as there is a CV as to how long it should keep the motor powered when it looses power. You can check CV11 and increase it. Of course that CV only matters IF cv29 bit 2=0. CV12 is what is used before it shuts everything down. So it can be setup so if power is lose, motor shuts down first, and then it shuts sound/lights down.So it may be worth a look at those CV's anyways.
tsdI went back to the video again you had posted... It looks like at one point with the aligator clips on the wheel directly it did the same thing as well at some point? If thats the case and to make it easy, just connect both leads to the tender and run it, putting a little but of a load on the drivers and see if the same thing happens. What I don't get is that with no power to it, the sounds did stay on. That would tell me it must have a GoPack or is not rev H but is rev I which has the mini GoPack built into it. Rev I close to what is being called Paragon 4, but the true Paragon 4 is called 400-A now, looks the same as rev I but has 1 additional small plug on it, like the GoPack one but a 4 wire, and is for future use. Rev I if on the latest code for that would have pro mode for lighting. This is important because it may be able to be tweaked via CV as there is a CV as to how long it should keep the motor powered when it looses power. You can check CV11 and increase it. Of course that CV only matters IF cv29 bit 2=0. CV12 is what is used before it shuts everything down. So it can be setup so if power is lose, motor shuts down first, and then it shuts sound/lights down.So it may be worth a look at those CV's anyways.
The loco did not do the same thing inverted that it does on the track, unless I very briefly (short fraction of a second) break electrical contact by lifting the clip from the wheel. I think that's what you saw. With a longer break in contact - closer to a full second and then on up) the motor reengages and races a bit, like the loco is trying to get back to where it should have been if it hadn't stopped. Really weird.
In perusing the Paragon 3 tech manual, I see that CV 29 bit 2 is defaulted to 1. Since I haven't changed it, that means CV 11 is inert (I think). CV 11 is labeled as "Packet Time-Out Value", so how does that impact the motor being powered from the GoPack? Right now it doesn't seem to be getting any power from that source. What is CV 12? Is that the one that controls GoPack power to the motor? The tech manual doesn't talk about CV 12.
The latest thing I could find on the BLI website was a decoder Rev H, but that was in the section about how to attach a GoPack. If there's one built in (and tech support confirmed that there is - see the next paragraph), I'm not surprised it's a rev higher than H.
I got an email from BLI Tech Support today. They looked at my video, and think there is something definitely wrong with the loco. They provided an RMA number and promised a one week turn around on repair (which will probably be just replacing the decoder, based on what I was told on the phone yesterday). The email also confirmed that the decoder has a built-in GoPack, so they asked if I wanted to go ahead with my order for one. The tech person seems very concientious - they said there is a problem that an added GoPack may cover up, but the basic problem will still be there. They suggested fixing the loco, then adding a GoPack later if I still want one.
While the problem with the new loco is annoying, the attention BLI's Tech Support is giving me in trying to resolve it is outstanding, and will keep me a customer.
Yup, their support/repair is really among the best in the business, even if at times their turnaround can be quite a while, and they always strive to go above and beyond for their customers. The decoders have the revision on it so if you took the shell off you would more than likely see it is I rev which would have 3 caps on the end and the PCB is extended out instead of just on the side of the cap on the older revisions. If it was the "true" Paragon 4 then it would also have an extra small 4 pin connector between the speaker and 5 pin for additional lighting and such. So makes sinse that they confirmed it is a higher revision then since it runs like that. I probably should have just checked as well, but when I go into the folder for I rev software and go into the Consolidation folder, it showed the 2021 Consolidation run, effectivly confirming that is what was used.
Some of those CV's were just never put into the Paragon 3 manual because they were really going to be a Paragon 4 thing. If you look at the Paragon 4 manual, you will find those CV's listed there. BLI also outlines those CV's in one of their own YouTube videos when they discussed the GoPack, which would have been on Paragon 3 and they mentioned those CV's there.
So the manuals can be decieving though as they are not specific to each engine they produce. So it may be a default CV but they may have changed the default of certain CV's to be something else for that production run. Those all go in with the sound fine as well. So when I program a decoder, the sound file is what then sets any "Default" CV's to be something else. Best case would be to just read it on the track and see what it is (I programmed one on Paragon 4 board and checked what CV's the code I have is for, which may have been updated already by them though).
So CV 11 would be related to when it shuts the motor down due to not receiving any DCC packets. It should be default of 2 based on the manual, which would be 2 seconds. But its possible it could just be off or a null value. CV 12 would be the timeout for the entire engine. So if CV12 is set to 5 but CV11 is set to 0 then when it looses power, the engine will stay powered up still and play sounds, but the motor would stop. Of course only if the other CV bit 2 is 0. The motor going quickly after it gets power back is because the decoder sees the motor as not moving at all, so it thinks it just had a really big load, so now that its sending power again, it gives it more juice. Once it knows there is not much load it then slows back down.
Of course I am not saying it is not a decoder issue here, especially being one of the first production runs of the new design, but it is possible CV's were just not set right for defaults if say the factory used the new boards but the sound file was not tweaked yet for the new boards. So those CV's may be there but may not actually be set right.
I appreciate clarificaion on the video as well as it was a little hard to see exactly what was going on with the lead on the wheels, etc.
I programmed a decoder using what I have for it (though into a Paragon 4 decoder but using what was in the Rev I folder, as I used up the rest of the Rev I that I had a couple months ago) and read the following CV's:
cv29=6
cv11=6
cv12=5
CV247= (I did not check but though of this after) Would recommend checking anf seeing to 255 to disable it, in case it is set really low. Its for overcurrent protection, which was how they tried to protect before the newer motor controller chip that has its own built in protection.
Unfortunately my tests were a little bit harder as well because I just had a motor connected, so no load. So if running on high and I unplug the motor, it still has momentum, so it slows down more slowly. I was going to try to play with those CV's to see if I could get it to behave the same, but I do not have an actual engine handy to test with right now that would have a load (even just being attached to a gearbox and wheels would be a load for that purpose).
Wonder if it would be an issue in DC and not DCC. Not sure if you tried that or not? And also maybe clip both leads to the tender and push down a little bit on the drivers to simulate load. If it indeed is only when power comes off and back on, then to me, that really indicates some CV's that are not right. So I would not be surprised if its mostly about replacing the decoder so the CV's are correct verses having you update a number of them but then have to write them down in case you ever defaulted the engine.
In any case, I am sure they will get it taken care of fo you, and even if it was CV's not defaulted right, its still best anyways to have either yours reprogrammed, or replaced (assuming the issue does not replicate with it on its back and a load simulated anyways, as I have seen motors do that, intermittantly spike but only when under load).
Speaking of Paragon 3:
I recently dusted off the three P5as and put them on the head end of a fifteen car passenger train. As built these engines are not very good pullers and I believe BLI did not consider any type of suspension (equalization) of the six drivers.
I have them all addressed with the same engine number to "MU" them.
After observing the three engines I found the drivers were randomly stopping and restarting as the train was progressing around the layout. All three of these engines have had the motors and decoders replaced by me using parts sent by BLI. A total of ten wheels pick up current from the rails. How can there be interruptions?
On the test track using a SproggII and JMRI I discovered that from a standstill, if I advanced the speed step too abruptly, say 0 to 30 the sounds would accelerate but not the motor. The only way to get the motor to respond was to reduce to speed 0 and wait for the air brake sound.
When I brought the throttle to idle, then advanced the speed say two or three speed steps at a time the engine would accelerate normally.
I had several Go Packs, Current Keepers and TCS Keep Alives® in the parts drawer and decided this was going to be a necessary "fix" short of replacing the decoders completely.
This was a successful operation overall. I had to remove the speaker enclosure to make room for the Go Pack but the sound didn't seem to degrade at all and, to my ear, it actually improved.
On the third P5a I discovered that the replacement board BLI had sent me was a revision H so it was a simple matter of plugging the cap in. In reality I had used up the BLI caps and installed the TCS one, soldered to the clipped-off BLI 3 pin plug.
Right now, for any of the P3 decoders I'm going to keep I plan to add a keep alive.
I wonder how BLI feeds power to the TWO motors in the GG1? The most recent one I bought is a P3 and it exhibits no operational problems whatever.
Tonight I'll give them a road test. For some reason the Revision H board is giving me a headache in trying to get the headlights to function properly
I'll get into that next time.
Cheers, Ed
gmpullman Speaking of Paragon 3: I recently dusted off the three P5as and put them on the head end of a fifteen car passenger train. As built these engines are not very good pullers and I believe BLI did not consider any type of suspension (equalization) of the six drivers. I have them all addressed with the same engine number to "MU" them. After observing the three engines I found the drivers were randomly stopping and restarting as the train was progressing around the layout. All three of these engines have had the motors and decoders replaced by me using parts sent by BLI. A total of ten wheels pick up current from the rails. How can there be interruptions? On the test track using a SproggII and JMRI I discovered that from a standstill, if I advanced the speed step too abruptly, say 0 to 30 the sounds would accelerate but not the motor. The only way to get the motor to respond was to reduce to speed 0 and wait for the air brake sound. When I brought the throttle to idle, then advanced the speed say two or three speed steps at a time the engine would accelerate normally. I had several Go Packs, Current Keepers and TCS Keep Alives® in the parts drawer and decided this was going to be a necessary "fix" short of replacing the decoders completely. This was a successful operation overall. I had to remove the speaker enclosure to make room for the Go Pack but the sound didn't seem to degrade at all and, to my ear, it actually improved. On the third P5a I discovered that the replacement board BLI had sent me was a revision H so it was a simple matter of plugging the cap in. In reality I had used up the BLI caps and installed the TCS one, soldered to the clipped-off BLI 3 pin plug. Right now, for any of the P3 decoders I'm going to keep I plan to add a keep alive. I wonder how BLI feeds power to the TWO motors in the GG1? The most recent one I bought is a P3 and it exhibits no operational problems whatever. Tonight I'll give them a road test. For some reason the Revision H board is giving me a headache in trying to get the headlights to function properly I'll get into that next time. Cheers, Ed
I get that one and the GG1 confused at times as I am going on memory, but one of them uses 1 motor and the one with 2, they are wired in parallel to eachother. So just 1 wire set to the connector on the decoder for the motor, but then splits off for the motors in parallel. So the biggest issue with that is that if either or both motors are slightly out of spec and draw to much current, then you can run into issues. Luckily I have not seen many here at all for that as their factory must have known how important it was for good motors for that, having to have 2 of them in the engine.
Something to note with GoPack's though is that it does not necessairly provide power to say lights, smoke, etc. as it primarly is for the motor and then sound. So if power issues are occuring, then when it goes on that power, the headlight may flicker as it looses and regains power.
For engines that have limited room and not wanting to invest a lot of time to make room for a GoPack, I do generally find that the Rev I or 400-a (Paragon 4) usually works just fine as well as it has just enough of a GoPack built in to cover small issues. Of course if there is room to easily/quickly plug in the GoPack, I usually offer that as well to people and most take it for the added capacity.
Really, just one man's opinion, but for years we have continually read about BLI decoder issues, day after day, week after week. Maybe it's time to say enough of purchasing their products. I can't think of any other decoder manufacturer that has as many issues. And the sad part is they don't seem to be getting any better. Why don't they just totally change their product philosophy and put 3rd party decoders in their products. Why do they think their decoders are better than Tsunamis, LokSound or TCS? Just my $.02
Tophias Really, just one man's opinion, but for years we have continually read about BLI decoder issues, day after day, week after week. Maybe it's time to say enough of purchasing their products. I can't think of any other decoder manufacturer that has as many issues. And the sad part is they don't seem to be getting any better. Why don't they just totally change their product philosophy and put 3rd party decoders in their products. Why do they think their decoders are better than Tsunamis, LokSound or TCS? Just my $.02
Well, if you recall, at the start, BLI did use 3rd party decoders for their product. Mostly QSI and I believe some ESU. I believe (and making an assumption) what drove them to what they did was wanting full control of the product as to what they wanted to do. It also allows them to go and get their own sounds as well, which they have done by hiring or using an in house sound engineer to go to train yards to get their sounds. If they wanted to add a feature or change something, they could not simply just tell/ask QSI to add features just for them, etc. but if they make/design/engineer their own decoder, then they can add whatever features they want. And that did not mean oursourcing the actual development either like many US based companies do, but they actually have on their payroll as a direct employee an engineer who developes the hardware and software of their decoder. Many of the issues people have had with them are actually not related to the decoder, but due to a lack of understanding as to how it all works together just end up blaming the decoder. This is why I have had 0 issues with people when I upgrade their old QSI Paragon series to say Paragon 3 or Paragon 4 now. I've never had a decoder failure over all the years I have been doing that, except on the older ones in the off chance the motor was bad but not seen to be bad at the time and it causing the decoder to fail. For every one of those cases (few), when the motor is replaced (with the decoder for the older ones or just replacing the motor if its a newer one with the newer motor controller chip), they never have issues again.
tsd, with all respect, I think we must be reading the multitude of posts here in regard to BLI with very different understanding. I will agree that BLI shifting from QSI to proprietary decoders at first was a good move. That QSI no longer exists substantiates that. I'm just suggesting that it might be time for them to be making another switch to any/all of the LokSound, TCS, Tsunami products available. It seems to be working well (certainly not perfect) for Athearn, Atlas, Walthers, Scaletrains, Rapido, Bower, Intermountain, et al.
Tophias tsd, with all respect, I think we must be reading the multitude of posts here in regard to BLI with very different understanding. I will agree that BLI shifting from QSI to proprietary decoders at first was a good move. That QSI no longer exists substantiates that. I'm just suggesting that it might be time for them to be making another switch to any/all of the LokSound, TCS, Tsunami products available. It seems to be working well (certainly not perfect) for Athearn, Atlas, Walthers, Scaletrains, Rapido, Bower, Intermountain, et al.
Well, I like to think of it as competition. If everyone used the same decoder, then there would be little reason for them to improve and make it better right? BLI does tend to respond well to customers and makes changes based on that to improve their product as well, which is why they went from BlueLine to Paragon 2, Paragon 3, and Paragon 4 with the built in mini GoPack, which I personally find to be fantastic, and designed to overcome issues with certain programming methods that hisorically do not work with GoPacks/Current-Keepers/Keep Alive's. Most of the changes and features and reasons they have "upgraded" their decoders were based on customer feedback. I have had very good feedback of my customers after putting in Paragon 4 into their older QSI ones or even Paragon 2 engines. I have had a number of people actually buy them from me to put in MTH, Atherns, and old brass engines. Of course if track is perfect, pickups cleaned/well designed, etc. then it would never be needed (the mini GoPack built into Paragon 4). I personally know their engineer who develops their stuff, and no, I am not an employee of BLI. So that is why I have very good knowledge/understanding of their product.
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.
Mike
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.
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.
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.
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.
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 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.
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 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.
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.
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.
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.
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.