RailPro User Group
RailPro => RailPro Specific Help & Discussion => Topic started by: robert.h.giffin on December 31, 2017, 12:42:27 AM
-
When moving sound files (tried GE 7FDL-16 and ULT) to the LM-3S at different points for each attempt it fails with a message 'Cannot Connect'. I have placed the controller at various distances from the decoder with no luck. I have also updated both the HC-2b and the LM-3S to the most recently released firmware. Since I removed the standard diesel sounds to make room for the desired file, the decoder no longer has sound. I have also tried two separate decoders with the same issue. This is not looking good at the moment BUT so far this is the only real insurmountable issue I have found. But it's a big one.
-
Is there a switching power supply nearby? If so, move it.
I had a situation where an operating power supply was sitting on the bench and anytime the line of sight from the HC to the LM was anywhere close to passing near the power supply the connection would drop. Moving the power supply totally fixed the problem.
-
Something like that. My testing setup right now is a single piece of flex track that I'm powering with alligator clips. I had the power supply on top of the desk but it wasn't in the direct line of sight of the radios, however, I do know how power supplies can affect certain frequencies so your suggestion made sense. It actually turned out that probably one of the alligator clips (or both) were likely not making great contact so I did two things, 1) lengthened the leads to put the power supply on the floor masked by the workbench and 2) re-positioned the alligator clips to make better contact (I know, I should solder to the rails). And step 2 worked. Makes sense, error message being 'Cannot Connect' meaning the radios intermittently drop power, shows up more on larger files like sound, the reason I was able to do lights and pictures but not sound files. Now to try the ULT series sound files.
Thanks for the suggestion. It set me on the right path!
-
Yes, make sure those clips have good contact. Or like you said, solder the leads on. With a file as large as the ULT files you will need to be sure that there is no possible way for the signal to be dropped.
You'll love that 7FDL-16 ULT sound file....it is truly excellent.
-Kevin
-
I find that downloading sound files is extreemly slow. They are big files so I am OK with that, I just want to make sure I am not the only person with that situation. I also found that if I have another locomotive next to the one I am trying to load files to I get the cannot connect message. I have only done a couple of engines but it looks like once I get the sound file on the Hand Held, I can just load more locomotives without going back to the Ring site.
Ken Z
-
Ken, yes the files are very slow to load. Have you tried moving the second locomotive a few feet just to verify that this is the cause? I have not had that experience. You should be able to copy files no matter where the locomotives are.
-
I have also experienced the connection lost issue randomly with the larger ULT files. I never thought to move the locos apart when this has happened, and come to think of it, this has probably only been an issue when I am programming in pairs.
I will have to try that.
Sadly I have a RailPro system coming back to me because of this issue too. I'm going to follow up with Ring Engineering on this.
-
FYI, I tried both, having both locomotives on the track and also with only one. Still had the issue so doubtful this is the answer. The files are just WAY large. I note that when downloading them from the server they come in two parts (or it does it twice), so there is a three part process. 1) download from the server to the Assistant; download from the Assistant to the controller, twice (or two files or a UDP file transfer being done again to recover bad packets), 3) download to the locomotive (only success was the GE 7FDL16 file, ULT file always failed and the last time I tried it it caused the decoder to go a bit kaddywompus - never did figure out what happened). When you get my one working decoder back you should look at it.
-
Robert,
Tim Ring suggested in an email today that he is confident he could have helped you overcome the issues you were having. If you still have your product, I would encourage you to followup with him and see if you can get this working for you. Failing that, I will have my first return.
Again, I'm sorry you had such a tough go of it.
All the best!
-
I wonder if it is possible for Ring to provide a flash drive solution. Can't get it working on the web - request a flash drive be sent.
-
No, the frustration was too much. I am also a fly fisherman and I find that to be relaxing, as it should be, as I thought I remembered this hobby being. I don't fish primarily to catch fish, I fish to get away. But getting back into the hobby after 40 years away from it was a mistake. And, you have my other frustrations in the emails I sent you, it wasn't just this issue. I deal with troublesome technology at work as an IT Director, I don't need it in a hobby. Tying flies is about as technical as I need to get. Plus, recent health issues did not help any.
Don't feel bad, just didn't work out. I have been keeping a document of suggestions that I would be happy to send you if you wish. Like the one that was just submitted - a direct connection between the HC and the decoder using USB or some other connector to attach the decoder to the controller for direct disk access. Files would be slow to come down from the Ring servers but quick to place on the flash in the decoder that way. Would be good for initial setup before you put it in the locomotive.
-
By the way, I am also sending the two locomotives back as well. I can reuse some of the tools on the fly tying bench or give them to my son who models stuff (not railroads). I'll lose a bit of money on the re-stocking fees but I will recover some of it. All part of the game.
-
From the research I've done, the radios use UDP to transfer the files. This will usually result in them taking a long time as packets have to be re-sent if they didn't come through the first time and fail the error protocol. I understand the use of UDP for small radio based systems because TCP overhead is much greater. But TCP brings packet acknowledgement to the table and often, when you think you are saving using UDP, you actually are not because of all the packet retransmission and error handling that has to happen with UDP. It can often take longer with UDP than with TCP. Based on my limited experience with these systems, this seems to indeed be one of the issues. Sorry if I sound like I'm guessing.
I think there are other options. But most of them would require some form of re-architecture of the system to implement. Not sure Mr. Ring would be open to that.
-
I also have a few suggestions about the operation of the controller and Assistant. You should be able to quickly download the files from the server to Assistant using the full stack of TCP available on the computer. You should be able to store those in Assistant, you should also be able to preview the sound files and preview pictures through Assistant. Then you should be able to pick from those and COPY them to the controller, keeping them in Assistant so you don't have to go back to the server every time you need that file or files. I think there are a lot of UI improvements that could be valuable additions and would help to warm the technically challenged folks to the technology.
Again, I was keeping a file with all of these that I had planned to send to either you or Mr. Ring. Would still be happy to provide. Sorry for the multiple posts, just got me thinking...
-
Robert,
Please feel free to send your ideas to me and to Mr. Ring.
As far as local storage, the RPA software does store the files locally after downloading, you just need to choose them from the second row of buttons in the RPA. I agree, this could be laid out better and be a little more seamless in execution.
-
William,
I will admit that it was the smoked decoder that was the 'last straw'. I did nothing but solder a speaker to the two brown wires and it smoked. I was excited up until that point and I was hoping to hear the sound through this bigger speaker as the other one I was using was one of those puny iPhone speakers (on the other decoder), and then it all came crashing down. Everything up until that point was simply annoying, frustrating enough but easy enough to surmount. Can't fix a toasted, melted device, and I even carefully stepped up to this point.
-
As big of a RailPro fan as I am I can understand Robert's frustration. The whole Ring file update/transfer process SUCKS. It is about as user friendly as a .gov website. RailPro may be the best thing ever but if the end user can't update a simple file easily and quickly then the allure of this 'advanced' system will fade. Our current interface reminds me of the green screen Mac I had back in third grade. This segment of RailPro has got to be fixed ASAP.
-
I just went down and put an ohm meter on the terminals on ALL FOUR of the speakers I have (2 iPhone and 2 SoundTraxx). They all do the same thing, peg the meter, indicating a short in the speaker. Not being much of an audio guy I don't know if this is normal (I'll Google it maybe), however, one of those speakers was the little iPhone speaker I was using on the first decoder and it was working fine. It pegged the meter as well. And two of these are new in package (one of each type).
This tells me that the speaker was not defective (I have yet to test the audio performance on it because I really have nothing to test it with). And, as stated in the email I sent to Ring Support, it melted the decoder right at the area where those two brown wires enter the 6-pin connector. I initially thought I had put the soldering iron on something and it was burning because I couldn't believe that I smoked a decoder, the reason it took a little longer to yank the locomotive off the tracks.
It's good and melted, for sure. It will be on the way back the Ring Engineering tomorrow or the next day.
-
Sounds like a short in the amp. I had one module that melted like that, but I can't remember the circumstances because it was years ago. Sent it back to Ring and they sent a new one free of charge. You didn't solder the speaker wire while the locomotive was on the tracks, right?
Regardless, issues like this sometimes pop up, but on the whole the system is relatively bulletproof. I've had my share of issues with both hardware and software, but after Ring and I identify the problem we get it resolved and it makes the product better in the end. I'm pretty sure he made me a beta tester because I was a magnet for issues.
I do agree that the downloads take way too long for how big they are. I would love this aspect of railpro to change. It really should be a matter of a few seconds and not tens of minutes. But I'm not a software engineer so I'm have no idea what is involved in making this change.
Kevin
-
No, I soldered the speaker to the 6-pin harness, plugged that harness into the decoder, and then plugged the decoder into the locomotive with an 8-9 pin adapter harness. Then I placed the locomotive on the track.
-
Robert, you said the module shorted at the connection of the speaker wires. Could there possibly be a short in the harness or in the module connector itself?
-
Very well could be. I will see what Ring says about it.
-
Speakers are typically spec'd between 2 ohm and 8 ohm impedance. The rating is nominal because frequency changes impedance. Impedance is the combination of resistance and phase in a device driven by an AC signal. Your meter supplies a DC voltage to measure resistance. There is no phase angle of a DC source. As a result, the DC resistance measurement will be less than the AC impedance spec of the speaker. A 2 ohm speaker will look like pegging the meter because the DC resistance will be less than 2 ohms. A 4 ohm speaker would measure an ohm or two. An 8 ohm speaker is usually around 6 ohms. Your meter needs to be accurately calibrated on a low range scale (100 or 10 ohm FS) to measure such low resistances without looking like the meter is pegged.
-
If I remember right my short was from a loose piece of solder inside the module itself. The install went well and the locomotive worked fine for a bit, including sound, but then out of the blue the locomotive made a very loud, strange sound, and then went completely dead. The module was very hot/melted where the two speaker wires went into the module. Ring inspected it and apparently a small piece of solder had broken loose somehow inside the module and ended up across the leads to the amp, shorting it out. Killed the module at the same time. Like I said before Ring replaced it at no charge. I've never had that problem since.
-Kevin
-
Well, this is sad news that it's come to this for someone.
Always late to the discussion from the time difference I'll still respond.
From the research I've done, the radios use UDP to transfer the files.
UDP is most definitely used to transfer the files from Rings server to RailPro Assistant. This was discovered ages ago. I don't know what protocol is used between the transmitters in the products, I haven't the tools to find that out. I don't know what's used to transfer files between RPA and the HC / CI-1, that's still on the todo list.
In Tim Rings mind UDP was probably the best choice, less over head etc as you mentioned. That choice has caused a few issues for some but for different reasons. I've studied and am still studying the Ring file transfer and going back on what I've said previously from recent study the data transfer seems pretty robust, just very slow. I haven't seen a dropped packet yet but I'll still studying.
The transfer speed from Rings server to RPA could probably be a lot higher (the files are not actually that big in computing terms), heck have you ever streamed anything on your computer or skyped etc, that's going to be almost 100% of the time UDP. It's without the checking that RE performs but it's still UDP and it's usually fast. There's probably a couple of things at play here:
Rings file server is not a webserver in some datacentre with a huge backbone but from what can be identified right now it's a server sitting in an office on a residential/business DSL connection. Uploads (what's happening when you get sent a file) are notoriously slow due to "plan shaping" for want of a better word.
In the old days files were downloaded directly to the HC from the file server. I imagine the speed was made slow to begin with due to the speed at which the HC could accept input through it's serial connection. We may just be still using this speed even though now files are downloaded to RPA first before being copied to the HC.
You should be able to quickly download the files from the server to Assistant using the full stack of TCP available on the computer.
Agree. This would require Ring moving the file server to a proper webhosting scenario.
You should be able to store those in Assistant
It does.
you should also be able to preview the sound files and preview pictures through Assistant. Then you should be able to pick from those and COPY them to the controller, keeping them in Assistant so you don't have to go back to the server every time you need that file or files.
It does and you can. You cannot preview sounds (it should not be hard for him to add the code to do so) but you can preview pictures. All files that you download are stored in RailPro Assistant. If you delete a file from the HC then you can just copy it to the HC again without having to download it again from the file server. The RailPro Assistant manual and the guides available here would have covered this.
I wonder if it is possible for Ring to provide a flash drive solution. Can't get it working on the web - request a flash drive be sent.
This raises a good question. How does Ring get the programs and files on in the first place. It won't be by RF from a HC I'll bet. If he doesn't have them preloaded by the chip manufacturers then there must be a direct wired way. While I built my testing board to make loading things to modules easier a USB device with a 9 pin plug and the required software for loading files to a module would be great.
It is about as user friendly as a .gov website... Our current interface reminds me of the green screen Mac I had back in third grade.
No argument on that one. Ring really needs to drop the current UI for RailPro Assistant, to heck with making it look like the HC screen, just make it a functional piece of software using standard forms (Winforms, GTK etc) and be done with it. You can make the UI attractive using those form systems.
The UI for the HC and CI-1, that I feel could be made much better too, but that's going to be a subjective argument, what looks really good to me might look bad to someone else..
- Tim (not the RE one)
-
Obviously I should have put some more effort into the RPA. I just didn't feel like it was that robust. I even tried to find the sound files in the file system thinking that I could just play them but there was no file structure containing anything that looked like a sound file so my assumption was that it did not store those files in the RPA. Thanks for the clarification.
The other issue that I initially had was that there was no place in the documentation that indicted that the RPA was even required. I plugged the HC into a USB port thinking that maybe the driver package was loaded from the USB to the computer and that it used the computer simply as a network bridge (yes, this CAN be done but it's quite rare). Not once in the documentation is it mentioned that you need to download and install the RPA and THEN plug the HC in. I had to find that here in the RPUG. The documentation should state that the first thing you need to do is download and install the RPA (and give a link), update the firmware in both the HC and the decoders (it should actually do this automatically, like a Windows Update), and then download the sound, pictures, and light effects that you want. Seems like a normal thing to anyone with a smartphone but keep in mind that your customers are DCC folks and are probably not expecting that. A LOT of product failings can be addressed with proper documentation. I don't know what the RailPro staff looks like but it seems like it is more of a community-supported thing.
I also understand the hosting situation for the Ring server. It's a business decision to move it to a data center. But not moving it and providing a realistic architecture will negatively impact the adoption of the system.
Thanks for the comments Tim.
-
... A LOT of product failings can be addressed with proper documentation...
Amen brother. That shortcoming has been articulated many times before. Tim Ring may be a talented engineer but his documentation skills leave a lot to be desired. He would do well to hire a professional technical writer. Same goes for most DCC manufacturers.
-
If it has been articulated many times and it STILL hasn't changed, then that indicates a real problem. Documentation is an easy fix. Has anyone volunteered their time to maybe get a group of folks together and improve the documentation? If the system is so well liked by the people in this group then I would expect that many people would be open to volunteering a documentation improvement effort. Just a thought.
-
We must be mindful that Ring Engineering, like so many MRR suppliers, is a very small business with limited resources. Having said that, I still firmly believe in your statement - proper documentation is key. Imagine how much email and phone time Tim could eliminate by simply having well structured, comprehensive documentation.
As an example... see how long it takes you on the website or in the manuals to find the spec for maximum load on a LM3 output pin.
-
The other issue that I initially had was that there was no place in the documentation that indicted that the RPA was even required
I just checked and you are right, all the manuals say is that you can update and load stuff and to go to the RailPro software link on their website. Not a great way to convey that message!
I'd also say the just plugging the controller in and expecting it to self update over the internet is not what anyone would expect; certainly I know of no consumer device that does that, and frankly I wouldn't want a device that does; I'll choose what and when thankyou.
I don't know what the RailPro staff looks like but it seems like it is more of a community-supported thing.
No, RailPro is not a community supported thing, Tim Ring supports his products 100% and if asked for help he will respond to it; he has never in our knowledge pointed anyone in our direction to get help. In fact you could say he doesn't acknowledge that this group exists (that in itself is another problem).
Has anyone volunteered their time to maybe get a group of folks together and improve the documentation? If the system is so well liked by the people in this group then I would expect that many people would be open to volunteering a documentation improvement effort.
Unfortunately volunteering to do that would get a big thanks but no thanks. There is some behind the business reasons for it which I will not go on about but some of us here have tried to improve the situation. I have written 3 users guides aimed at the new user which are all available here on RPUG, and another member has just recently done an instructional video, also available from here on creating and loading pictures.
Imagine how much email and phone time Tim could eliminate by simply having well structured, comprehensive documentation.
As an example... see how long it takes you on the website or in the manuals to find the spec for maximum load on a LM3 output pin.
Imagine how much email and phone time Tim Ring could eliminate as well by pointing people to RPUG for community help, we've even solved things he couldn't!
Find the spec for the maximum load on an LM3 output pin? that spec doesn't exist in any published form. We definitely need better and more technical documentation.
Cheers,
- Tim
-
I was ALMOST convinced to keep my stuff and continue to try and contribute to improving the product. But I know people like Tim Ring who want to keep everything close to the vest and who refuse help from anyone, regardless of how much it may be needed or the sincerity of the offer. While I was still a member of the HO Scale Model Railroading group on FaceBook, one of the primary 'complaints' about RailPro was that it is proprietary and a relatively closed system, I can now agree with this assessment. I'm not interested in contributing when my contribution is unwanted by the owner of the product. It is really disturbing that Tim Ring doesn't even acknowledge this user's group. That statement that he refuses any offer of help speaks volumes.
He should adopt a few methodologies from the open source community. Otherwise, the product WILL go the way of so many great ideas that came before that were kept under wraps for whatever business reasons.
Thanks for the information.
-
Before we get into a complete bashing scenario here, let's think about a few things.
I would agree with many of the points presented, as I am one of the folks who have offered to help Tim Ring market his business on more than one occasion. Ring Engineering is a very small operation. I have a feeling it is being run from a residence, as the Google map shows a strip mall that has no signage on the storefronts indicating a presence of RE. Perhaps it is because of the small size that Tim takes the time and effort to be extremely helpful to his customers. He has never ignored an email or phone call, and we have exchanged many. He has gone out of his way to help with unique problems over the years and that is certainly to his credit. The product itself is a revelation in model railroading and puts DCC to shame in many ways.
There are download issues and there have been glitches in the products along the way, but many of them have been handled. He is constantly working to update the products at no charge to customers, while adding new capabilities to the RP system. Of late, it would seem that the thrust has been on designing and bringing to market LM modules for G and O scale. I'm sure that has taken up the bulk of his time.
Perhaps the aforementioned problems will be addressed at some point, but for now, I wouldn't trade RP for anything else on the market. Having done business with many companies, I have never been more impressed with the customer service as I have with Ring. Just my two cents.
-
I'm not bashing, just presenting reality. Eventually if he is successful the support calls will overwhelm him and he'll have to hire staff to handle the volume. It's a delicate balance but if he isn't embracing his early adopter community, that is a huge mistake, in my humble opinion. I was willing to put the effort into it but if it is unwelcome, I will move on.
This community could be a great deal of help to him if only he would open himself to accepting it. Too bad he is so closed about this.
-
I was willing to put the effort into it but if it is unwelcome, I will move on.
This community could be a great deal of help to him if only he would open himself to accepting it. Too bad he is so closed about this.
Before you decide that Ring is not willing to accept your effort, talk to Him on the phone and decide for yourself. Don't let the conclusions of people here dissuade you from making your own contact and thus making your own decision. Who knows, your input might be the voice that brings a sea-change at Ring Engineering in this area.
I have noticed several significant changes in approach from Ring Engineering in the last month or two and perhaps your voice will add some momentum. I believe we all, including Tim Ring, want to see this product continue to improve.
-
... I wouldn't trade RP for anything else on the market.
Agreed.
I prefer to think of our comments as constructive criticism. An attempt to make a great product even better.
There is no question about Tim Ring's responsiveness. It is superb. I merely question whether superb responsiveness is the best front-line solution. Seems like a terribly labor intensive way to go about it. As a consumer the last thing I want to do is call customer support. It means I have encountered a problem I cannot solve for myself with the product support materials. It also means I am experiencing some level of frustration. Neither is good. I can understand it for odd situations far out in left field. I cannot understand it when all I want to know is an output pin spec or the possible reasons why my RP product won't connect. Mr. Giffin's experience and reaction is case in point that great after-purchase customer support is no guarantee of a satisfying user experience. That has to start when one first opens the box.