2019-07.5: Common questions for Matt

06 Aug 2019

TMTV
Rating: 
3.625
Average: 3.6 (8 votes)
Summary: 
25:56 - July 2019 Bonus - Common questions for Matt (2019)
Description: 

We put Matt Herman from ESU/Loksound in the hotseat to answer common questions. Will he squirm or just burst into flames?

Comments

The video mentions that the new version of Cab Control (Command Station and throttle) will fix most of the problems with the previous versions.  That's cool but what about us folks who bought the original.  Will there be a firmware upgrade that fixes the issues mentioned?

Also no mention of when and if LNet will be enabled.

 

Cheers

Peter

Just a correction to Matt's comments on running LokProgrammer software on a Mac "in emulation". That's about 15 years out of date, and it's good news for ESU.

Since about 2005, Mac computers have run on Intel CPUs - real genuine Intel chips designed and made by Intel. Not special Mac CPUs, either: exactly the same chips used in Windows PCs.

You'll need to install Windows on your Mac (the hardware box) - real genuine Microsoft Windows, talking to that real genuine Intel CPU.

So when you install the LokProgrammer software, it's installed in and running in real, genuine Microsoft Windows, running on a real, genuine Intel CPU. No emulation: the real stuff.

There are a couple of options: "boot camp" - rebooting the Mac (hardware box) in Windows, so it's just a Windows PC that for the moment (until the next boot-up) doesn't run the Mac OS;  or using third-party software like Parallels - there are others - that lets Windows and Mac OS run at the same time in different windows and share resources. Whichever way you go, nobody is pretending to be something it isn't (ie, "emulation").

So, you DO need a copy of WIndows to run the LP software, and if you don't want to reboot your Mac you'll need something like Parallels. But you will not be emulating - you'll have full speed, full power, native operation of LokProgrammer on a Macintosh box.

So, I hear its better for me to get a PC system ($300+) to do what you folks want for me to use your system. I'd love to try LokSounds, but being a Mac person for the past 30 years, I have to succumb to a PC version becuase the Mac version woudl cost too much? I'm sorry but thats lame as an excuse. Guys. you've got a great product, Take the market by proviing a Mac verison on the software. It won't make the cost double. It wont...Mac insn't the <10% of the market nowafays. Get up to speed with the others. Thanks!

 

tpmarshall's picture

Hi "Gizbab":

I hear you - I'm a Mac person too: have beeen since 1987. But used PCs are super cheap, so I bought a refurbished IBM Thinkpad laptop (with a warranty, no less!) from a local computer dealer and use it in my workshop. I use it for the LokProgrammer and for JMRI.

It's an option you may want to consider.

Happy modelling!

- Trevor

As an IT guy by day, I run into this platform dependance problem all the time. First let me say, I LOVE Windows, it breaks all the time and I make a good livelihood from it. I love that joke, but the truth is, I subscribe to the use the best tool for the job mentality, and sometimes (just sometimes my Apple and Linux folks) Windows is the best utility. However, I very much dislike Windows for a primary JMRI station. My preference is JMRI on Linux, installed on a Raspberry Pi. This means no update to my workstation, be it my Mac machines or Windows machines, impedes my ability to run trains. Yes, as an IT guy, I have a range of Windows, Mac, and Linux systems and servers at home. But for others, they should be able to make whatever decision they want for a computer, these days this often comes down to what ecosystem you live in. A nice feature in JMRI is the network connection component, so I run JMRI on a RasPi in headless, then use a range of different systems running the same version of JMRI to connect to it. This is great for me, allowing a programming station (there are other details for this), and especially useful for my dispatch stations and interlockings running PanelPro. Not everyone would need or want this complexity, but it's nice to have it. And the network connection makes this platform agnostic. I have JMRI as server on RasPi, then JMRI PanelPro on a Windows multi-monitor monster for my dispatch, on another RasPi for an interlocking tower, and on my MacBook for programming. Choice is a good thing, and the network makes this platform or operating system agnostic.

As to a solution to the platform dependance issue; two options:

1) Open Source. Just as JMRI is Open Source and many folks work on it, you benefit from a community. I understand there may be a reluctance to open any propriatary parts of this equation, however this should not be required. Simply with some API's, developers could provide the community all the software we desire. There's virtually no negative for ESU, as they aren't trying to sell software, just hardware.

2) Web based front end. I have moved nearly all my personal development and railroad controls development work over to web based systems. Including me working on a distribution for RasPi providing a very easy to roll up JMRI instance, with additional items such as MQTT, HomeAssistant, MotionEye for camera's, etc., some 18 or so software solutions, a distribution tailored for model railroaders.

The web technologies used to be limited and pretty much awful replacements for desktop software, however with HTML5, JavaScript, and Python it's really quite competent these days and likely well suited to use cases such as using the LokProgrammer or interacting with the cab control system. It also requires very little hardware to embed a web browser into the product, at a couple US dollars or less this could be compelling. By all means, leave the USB-B connector so one could direct connect. However, you could simply have it fire up, produce a local access point, join it with your phone or computer and be presented a captive portal style page (this is the page you get when you join wifi at a hotel and a site opens up to allow you to input your room number, credentials, etc., and accept the usage agreement). From here you could input your local wifi credentials, so it would simply join your wifi and could then be used by any computer on the network, or use it on a direct wifi link without joining it to another network. This also means you could do the same things with a phone or tablet which is very future proof as so many people only have these devices.

That option would be compelling if I were the manufacturer, or if the LokProgrammer had a Linux compatible interface, I could do it myself. But also, this is still possible to convert to wireless connection, by using a utility on Linux that permits usb-over-network connection type. But the limitation of the software running only on Windows persists. While it may be possible to reverse engineer it, I think ESU is a solid company for our hobby, I have standardized on ESU decoders, and I think they are searching for and headed toward the right solution and such reverse engineering is not in the best interest of collaboration. But this may take some time, and we may have to have some work arounds in the meantime. I've found solutions that satisfy my needs, but it does require me to keep purchasing Windows licenses (not really as I have them) and maintaining antimalware subscriptions. One note, it is more than just a Windows computer, one) cheap Windows computers aren't much good and have a pretty short life, statistically, ymmv, two) updates and maintaining it, sometimes this may cost, but it for sure costs time to maintain one correctly, and three) antivirus/antimalware are effectively required.

I think ESU is really onto something with the focus and quality of thier products, and the option to purchase a LokProgrammer nearly single-handedly commits me to ESU as my standardized decoder in all my equipment. Plus Full Throttle doesn't hurt... I think they are on the right track, but this is a hard market for manufacturers of products for niche markets such as our hobby. I see a bright future for ESU against the other competitors in this field. Despite it being more difficult with the wealth of DIY solutions currently as well as the difficulties in procuring and maintaining supply chains for components and this isn't likely to get easier. But there are some challenges that ESU despirately needs an impressive solution to and sooner is always better. I watch with baited breath...  And thanks TMTV for this very good segment!