How long does it take to discover all the CV values on a typical modern decoder (like Tsunami2) using Sprog and JMRI?
With my Power Cab hooked up and Decoder Pro working properly: <1 min to read and display all the CVs. While I do NOT need the Sprog to assist with that, I'm guessing with other DCC throttles that do it would be about the same.
Tom
https://tstage9.wixsite.com/nyc-modeling
Time...It marches on...without ever turning around to see if anyone is even keeping in step.
There are two factors:
° Speed of you computer
° Speed of your DCC system
Jim
Modeling BNSF and Milwaukee Road in SW Wisconsin
Hi,
I just happened to have a Tsunami 2 in my Amtrak SDP-40F sitting on my test track so I did a read full page on the CVs and it took 10 min. 43 seconds using JMRI 4.8 on a Intel i5 2400s @ 2.50 GHz Windows 10 computer.
Hope that helps,
Ed
Very interesting. Does Decoder-Pro allow you to choose whether to use "bit-by-bit" comparison as an option when you perform a "read full page"? It seems like that would take 8 acks per CV (as opposed to up to 256 acks per CV) which would account for the speed difference (1 min vs 10 minutes).
passenger1955Does Decoder-Pro allow you to choose whether to use "bit-by-bit" comparison as an option when you perform a "read full page"?
It gives you a choice between "Direct Bit" or "Paged" for programming mode.
I just read the full sheet in both modes from a TCS EUN651 (non-sound) decoder. Direct Bit took 3 minutes 55 seconds, Paged took 7 minutes 22 seconds.
This is with a Sprog IIv3 with a 3.4 Ghz quad core i5 running Windows 10. JMRI 4.8
I have the right to remain silent. By posting here I have given up that right and accept that anything I say can and will be used as evidence to critique me.
I think Tom is just being optimistic. There's no way any system will read the whole decoder in 1 minute or less.*
DecoderPro allows you to pick modes available on the system connected - in the case of SPROG, that's Direct Bit and Paged, not every system supports the Direct Bit method. Some use Direct Byte, which infortunately does not just read the value liek it sounds, that is the mode that can take up to 256 tries to get a value. Paged is compeltely different and harkens back to early decoders that only had a small handful of CVs to program. It does allow access to the whole decoder on newer ones.
* not entirely true - ESU decoders support, in addition to NMRA and Marklin protocols, a proprietary one that can read or write the entire decoder in seconds. It uses this protocol to upload the sound files as well. You can imagine how useless it would be if it took a hour to upload a sound clip into the sound decoder. If you look at Rich's thread on Loksound silent startup, they have a table of 40x16 CVs for function control mapping. 480 CVs. If each one needed 8 reads to do direct bit, that's 3840 reads, assumign flawless operation. Even at a rate of 1 per second, that's 64 minutes to read all that. Actual read speed is a bit better than that, but just try that with DecoderPro. Good luck getting all of them on a single pass, too - your program track and the wheels and pickups need to be absolutely clean so it never misses a bit. In contrast, the Lokprogrammer will use the proprietary method and read those 480 CVs plus all the others in the decoder in seconds.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
rrinker I think Tom is just being optimistic. There's no way any system will read the whole decoder in 1 minute or less.*...
I'll take your work on it, Randy. I remember reading decoders using Decoder Pro in the past but maybe that was an initial read, or I was reading a non-sound decoder.
Would a non-sound decoder take less time or the same amount of time to read as a sound decoder?
tstageWould a non-sound decoder take less time or the same amount of time to read as a sound decoder?
Compare my measurement to Ed's. Fewer CV's to read takes less time.
Carl,
It looks like your computer's CPU is faster than Ed's (3.4GHz vs 2.5GHz) so maybe that's part of the reason for the quicker read time? And, albeit a 0 or a 1 - it's still a CV value either way and must be read. If there are fewer CVs in a particular decoder then I would expect the read time to drop.
I certainly do not completely understand the ins-and-outs of indexed CVs other than, like human DNA, they can get pretty complicated — fast.
While watching the Decoder Pro screen "do its thing" reading the Tsunami 2, it seemed like it would read the entire list of CVs, then go back and spend time re-reading certain CVs.
There are three "pages" of indexed CVs on a Tsunami 2.
http://www.dccwiki.com/Configuration_Variable
I presumed these were the indexed CVs which took up a good portion of the reading process. I have to believe it would take longer to read a Tsunami 2 over say a TCS A4X.
Maybe I'll read several more tonight and report back.
Regards, Ed
Does anyone know roughly how many CVs are in the Tsunami2?
With an indexed CV, a single CV effectively has multiple values, depending on what the index is set for. One way to think of it is to think of a page with a table on it. You have, say row 3, column 4, and there is a value. With an indexed CV, now you have the index, think of that as a page number. So if the index is 1, roe 3, column 4 is some value. Set the index to 2, and now you are on page 2, which ALSO has a row 3, column 4, but since it's on a different page, it's a different value, with a different meaning.
For both reading AND writing indexed CVs, you have to set the index, and then access the CV.
For paged CVs it makes it sound like the decoder maintains its own database of values, and you use the page system to gain access to all those values (via a limited number of CVs). Question: Aren't there 10-bit CV addresses (1024)? Is there no way to access all the CVs on a Tsunami2 (for example) via 10-bit CV addresses? Is page mode the only way to get to them all? Do you still use page mode when doing a direct bit manipulation?
tstageIt looks like your computer's CPU is faster than Ed's (3.4GHz vs 2.5GHz) so maybe that's part of the reason for the quicker read time?
Being in the storage business for a lot of years, one of my favorite quotes has always been "all CPU's wait at the same speed".
There's very little "compute" going on when decoderpro is reading the CV's. I'm 99% sure it's because a sound decoder has way more CV's to read. Remember that decoderpro knows about the decoder before hand so he doesn't have to try and read all the sound related CV's just in case it's a sound decoder.
passenger1955 For paged CVs it makes it sound like the decoder maintains its own database of values, and you use the page system to gain access to all those values (via a limited number of CVs). Question: Aren't there 10-bit CV addresses (1024)? Is there no way to access all the CVs on a Tsunami2 (for example) via 10-bit CV addresses? Is page mode the only way to get to them all? Do you still use page mode when doing a direct bit manipulation?
10 bit CVs? Never heard of such a thing. All CVs are 8 bits wide. It's just a byte in the non-volatile memory of the microcontroller.
There are CV NUMBERS higher than 255, which means more than 8 bits to ADDRESS them, but the data is still 8 bits wide. Not all earlier DCC systems can address a CV number greater than 255. But even with higher CV numbers, again see the recent discussion on Loksound, we're talking CV numbers over 400 there - there is STILL an index, because the total number of CVs is still potentially greater than 1024 (when you have 480 JUST for the function mapping it's not too hard to get more. And some regions are reserved for future use in the NMRA specs)
Using an index CV is not the same as paged mode. Paged, Direct, and Direct Bit are methods of accessing the CV data, doesn't matter if it's a plain ordinary CV like CV2, or an indexed CV. ANd even indexed CV use isn't standard - QSI implemented a system whereby there were TWO index pointers and then a signle CV to set. Effectively that made a total of 3 CVs able to represent 255 CVs. Tsunamis did something similar where the same base CVs controlled the mixer levels, equalizer levels, and reverb settings - all depending on how you set the index CV.
passenger1955Maybe that wasn't clear. I asked are there 10-bit CV "addresses" (not CVs that contain 10 bits of data). Can a command station make calls to CV number 257 using 9 bits for that address?
Amazing what you can learn by reading the manual.
https://www.nmra.org/sites/default/files/s-9.2.1_2012_07.pdf
Page 8 answers your question.
In case you're a "just give me the fish" guy...
The short form CV access instruction uses a 4 bit address
The long form CV access instruction uses a 10 bit address
carl425Amazing what you can learn by reading the manual.
...and spoil all the fun?
Here is the Tsunami 2 users manual as well:
http://www.soundtraxx.com/manuals/usersguide_diesel.pdf
Good Luck, Ed