Do I need a Lokprogrammer

[s55evo]

Hi All, I am a bit of a novice when it comes to DCC sound, I think it has now reached the stage were it is worth experimenting with.

Most of my locos are kit built and steam, there are sound files available for a percentage of these and others that maybe close enough.

Do I need a Lokprogrammer? Can I buy a used decoder and reblow it to a sound file that is more appropriate for me? I think I undersatnd that I can alter the chuff rate etc, using my dcc controller.

What do I need to understand?

Tony.

[bandmbill]

If you haven’t gone down the sound route yet then go Zimo - I have consistently got really good results from Zimo - less successful with Loksound….

[s55evo]

Thank you, that's worth knowing.

 

[Nigelcliffe]

Do you need a LokProgrammer or the Zimo equivalent MXULF ?      Answer no, you probably don't. 

 

Where those devices are useful is 

 

a)    You write your own sound files.  ie. you have your own recordings, and an audio editor, and want to learn how to chop things up to make your own sounds.  This is another hobby in its own right, with a fairly big starting-curve.  

 

b)    You have access to publicly available sounds for locos, and want to mix up your own combination. (But there are very few sound files for UK outline locos available publicly for editing,  so its really a non-starter for UK outline.   Other country prototypes it might be a credible route  ). 

 

c)    You live outside the UK and thus its a pain-in-neck to get decoders with sound files loaded exported from the UK to your country, and its easier/cheaper to buy the sound decoder blank locally and then buy a sound file from the UK, delivered by email,  to load onto a specific decoder.   Unlikely cheaper this way if you live in the UK, as the blank decoder saving will be negligible.    (This works by each decoder having a unique serial number, and the sound provider can generate an "lock code" which will allow the compiled sound file to work on that specific individual decoder.  You can't load the sound file onto a different decoder (different serial number), and comes as a compiled file so can't get access to the component sounds to mix your own later).  

 

d)    You really really need to update the firmware on a decoder.   Its very rare to find a bug which actually needs fixing.  (I have a couple of times in best part of 20 years of doing DCC, but I tend to do experiments near the edge of new features). 

 

 

For most people in the UK, modelling UK outline, its way simpler to buy decoders with the sound files you want pre-loaded from the sound maker.  

 

Editing of advanced decoder features is possible via a DCC handset,  or JMRI* and a computer linked to DCC system will present computer screens to do it.   For most DCC systems a computer interface is cheaper than either of the programming devices. 

  

 

(*  there are other packages around which can program some decoders, but no other packages come close to the range of decoders covered in JMRI). 

 

 

- Nigel

 

 

[charliepetty]

In reality the Zimo & ESU Decoders are very similar, the big difference is the available sound projects on ESU to Zimo, there are far more ESU main stockists who actually create the sound projects than on Zimo.

 

Legomanbiffo - DCKits

Wheeltappers - DCKits

Howes of Oxford

South West Digital

Coastal DCC

Digitrains

Jamie Goodman

Olivia Trains (Sheffield)

 

The Warranty seems to be superior with most ESU suppliers, but Zimo is a quality product too so the difference is  mainly on availability, range and price.

 

On the Lok Programmer, most sound files can be ordered online via some suppliers websites, also the ESU Lok-Programmer is currently available Online too.

 

https://www.dckits-devideos.co.uk/index.php?route=product/product&path=59_84&product_id=476

 

Online Sound Files:

 

https://www.dckits-devideos.co.uk/index.php?route=product/category&path=282

 

The programmer also make it simpler to amend CVs and adjust things.

 

See this link for more information:

 

Edited July 8, 2023 by charliepetty

[bandmbill]

The Zimo repair scheme is that if you break the decoder you pay £20 for a replacement - I’ve broken two so far out of 20 - both my fault.   
 

Most of my Zimo sound decoders have come from Digitrains - the sounds are very good even through the small speakers that fit in my 7mm/ft narrow gauge locos - there are 150 UK sound sets on the Digitrains website .

 

Usual disclaimer - just a very happy Digitrains customer!
 

 

[Pete the Elaner]

I have a Lokprogrammer &  Zimo MXULF.

 

The Lokprogrammer is really good. It allows functions to easily be re-mapped & create new ones (Like red at rear only for Hatton 66 for tailing in top & tailing, which is not available on the provided project). This can also be done with JMRI though.

Lokprogrammer is great for re-blowing a sound project yourself & I have re-blown a newer project onto an older model before. The accompanying software is Windows only, so unless you are a skilled programmer, it is of no use for Linux or Mac.

 

The MXULF? - I have had it for about 2 years & not found it useful yet. In USB stick-driven mode, it just doesn't recognise the file on the USB stick & indicate if the decoder's firmware is out of date. It has an otherwise obsolete USB connection (USB-A?) & after eventually finding a lead which will work, I discovered that the PC software was in German only so it was meaningless to me.

[Kaput]

The Lokprogammer is handy but I'd recommend getting some sort of generic computer connection (like a Sprog) to use with JMRI to deal with the general programming of CV's first.

Its so much easier to deal with function mapping via PC interface than trying to individually program CV's via your controller.

 

If you do find yourself wanting to reblow sound files or make your own then look at a lokprogrammer further down the line.

 

The Zimo MXULF-A is honestly a bit useless unless you want to reblow sound decoders or update firmware, it doesn't provide any real advantages for programming CV's.

[bandmbill]

6 minutes ago, Kaput said:

The Lokprogammer is handy but I'd recommend getting some sort of generic computer connection (like a Sprog) to use with JMRI to deal with the general programming of CV's first.

Its so much easier to deal with function mapping via PC interface than trying to individually program CV's via your controller.

 

If you do find yourself wanting to reblow sound files or make your own then look at a lokprogrammer further down the line.

 

The Zimo MXULF-A is honestly a bit useless unless you want to reblow sound decoders or update firmware, it doesn't provide any real advantages for programming CV's.

Agree on the use of JMRI - my roster is on JMRI - easy to edit decoder settings - all in one place for all makes of decoder.

 

I bought the Zimo MXULFA recently to be able to update decoder software (does that very well) and to upload sound sets - I have done that a couple of times and it has worked.  I wouldn’t  use it to program CVs - that is what JMRI does really well.

 

 

 

 

[charliepetty]

15 hours ago, charliepetty said:

In reality the Zimo & ESU Decoders are very similar, the big difference is the available sound projects on ESU to Zimo, there are far more ESU main stockists who actually create the sound projects than on Zimo.

 

Legomanbiffo - DCKits

Wheeltappers - DCKits

Howes of Oxford

South West Digital

Coastal DCC

Digitrains

Jamie Goodman

Olivia Trains (Sheffield)

 

The Warranty seems to be superior with most ESU suppliers, but Zimo is a quality product too so the difference is  mainly on availability, range and price.

 

On the Lok Programmer, most sound files can be ordered online via some suppliers websites, also the ESU Lok-Programmer is currently available Online too.

 

https://www.dckits-devideos.co.uk/index.php?route=product/product&path=59_84&product_id=476

 

Online Sound Files:

 

https://www.dckits-devideos.co.uk/index.php?route=product/category&path=282

 

The programmer also make it simpler to amend CVs and adjust things.

 

See this link for more information:

 

The DCKits Legomanbiffo & Wheeltappers range, includes Diesels, Electrics, DMUs & EMUs plus Gas Turbines and replacements for the new Accurascale models along with Standard Gauge & Narrow Gauge steam projects.  These include 155 Modern image projects & 120 Steam projects.

The stock carried of ESU decoders is vast, especially in these difficult times.

Edited July 9, 2023 by charliepetty

[SRman]

Agreeing with a few other posters here, I have both LokProgrammer and Zimo MXULFA because:

 

1. I do reblow sounds fairly regularly on both ESU and Zimo decoders
2. It is much easier to buy the decoders locally and buy the sounds from the UK suppliers. The sound files are emailed to me locked to the decoders' particular serial numbers.

3. The Zimo MXULFA is not especially useful apart from updating firmware and reblowing sounds. JMRI is much easier to use for simple reprogramming of CVs or remapping functions.
4. The LokProgrammer reads and writes the ESU decoders much faster than JMRI does (in my experience).

Both devices are expensive, but for the above reasons were worthwhile investments for me here in Australia. As an added bonus, I have been able to reblow and reprogram decoders for others who live in my neck of the woods - no cost to them, I don't mind helping friends. 🍺

[s55evo]

Hi,

Thanks Nigel I appreciate what you are saying, and thanks Charlie, the videos were very instructive and I can see that any adjusting of sounds is going to be time consuming, so I think I conclude that a Lokprogammer would be a nice to have but not a real necessity, so maybe I will get one later.

Thanks to every one else for taking the time to reply.

Regards Tony.

[Nigelcliffe]

5 hours ago, s55evo said:

Hi,

Thanks Nigel I appreciate what you are saying, and thanks Charlie, the videos were very instructive and I can see that any adjusting of sounds is going to be time consuming, so I think I conclude that a Lokprogammer would be a nice to have but not a real necessity, so maybe I will get one later.

 

Other than the time to read-in CV's to get a base-line for the decoder, JMRI is actually easier and quicker to adjust sounds than a LokProgrammer.   JMRI does "programming on the main",  so once the base values are recorded(*),  you can tweak values for sounds, synchronisation of chuffs, lighting effects, etc.. etc..   in JMRI whilst the loco is being driven on the layout, and the results are instant.   Unlike LokProgrammer which requires looking at performance on the layout with your existing controller, deciding what to change, move and re-rail loco on LokProgrammer setup, make change,  move loco back to layout, run again, decide if its what you wanted,  repeat adjustments on LokProgrammer, check again on the layout - a really slow process.     The JMRI user interface for ESU decoders is very similar to the LokProgrammer (because the person who wrote the JMRI interface spent ages discussing details with ESU directly). 

 

Plus JMRI lets you adjust almost every other maker of decoders devices as well.  

 

 

(*  if a sound provider would give you the values of all the decoder's CV's from a LokProgrammer, the file can be imported into JMRI, saving that reading time.    The difference in the one-off read-in time is due to the LokProgrammer using an ESU proprietary communications method with the decoder, which is much faster than reading one CV at a time, which is what JMRI has to do.   Though it does it very quickly considering there are well over a thousand to read.   You can just leave a loco sitting there and go away whilst JMRI reads in all the values to get the initial values for the loco,  you don't have to sit there watching it.    )

 

 

 

- Nigel

  

[bandmbill]

4 hours ago, Nigelcliffe said:

 

Other than the time to read-in CV's to get a base-line for the decoder, JMRI is actually easier and quicker to adjust sounds than a LokProgrammer.   JMRI does "programming on the main",  so once the base values are recorded(*),  you can tweak values for sounds, synchronisation of chuffs, lighting effects, etc.. etc..   in JMRI whilst the loco is being driven on the layout, and the results are instant.   Unlike LokProgrammer which requires looking at performance on the layout with your existing controller, deciding what to change, move and re-rail loco on LokProgrammer setup, make change,  move loco back to layout, run again, decide if its what you wanted,  repeat adjustments on LokProgrammer, check again on the layout - a really slow process.     The JMRI user interface for ESU decoders is very similar to the LokProgrammer (because the person who wrote the JMRI interface spent ages discussing details with ESU directly). 

 

Plus JMRI lets you adjust almost every other maker of decoders devices as well.  

 

 

(*  if a sound provider would give you the values of all the decoder's CV's from a LokProgrammer, the file can be imported into JMRI, saving that reading time.    The difference in the one-off read-in time is due to the LokProgrammer using an ESU proprietary communications method with the decoder, which is much faster than reading one CV at a time, which is what JMRI has to do.   Though it does it very quickly considering there are well over a thousand to read.   You can just leave a loco sitting there and go away whilst JMRI reads in all the values to get the initial values for the loco,  you don't have to sit there watching it.    )

 

 

 

- Nigel

  

Agree about using JMRI for all programming - my whole roster is in JMRI - it does take a while to read in all of the values of a decoder but as you say you can just leave it going.    Once you have the decoder in the roster then programming on the main is very easy.