Esu ecos and HM7000

[andys steam dayz]

Hi

Was just wondering if anybody has tried using the ecos controller with hm7000 dcc decoders that have been down loaded with sounds I just want to know wether the ecos would be compatible to use with hm 7000

[96RAF]

The ECOS puts a compliant DCC signal to track therefore it should operate 7000 series decoders in DCC mode and the app should see the track power as satisfactory for purpose of operating in Bluetooth mode.

[HST Mainline]

Of course it will. ECoS supports DCC.

I have operated my HM 7000 with a Märklin Central Station 3, and programmed them, without any issues whatsoever.

[phil_dalton]

I operate my HM7000 chips from an ECOS 50200 with full capability and no problems

[540itouring]

Hi , I have a ecos esu command station 50200 and can not get it to work with a hornby Hm7000 decoder. The problem is that when I try to add this to the command station while it starts to detect the decoder the track power cuts off. Two trains do the same thing so is not the trains. the current trip is set at 4000mA and have also tested at 6000mA but the same problem.  other trains with other mages hornby , esu etc all work fine. I called hornby but they said they do not have a esu command station to test the hm7000 decoders due to high cost of controller. any help please. all firmware on decoders and command station are up to das as of 3/9/24

 

Edited September 3 by 540itouring
spelling

[96RAF]

Are you trying to add the decoders as DCC or are you expecting the Ecos to pick them up on bluetooth.

What is the track voltage the Ecos is feeding to the rails.

Others have reported in this thread their Ecos works 7K decoders OK on direct DCC commands.

[The Equalizer]

They all work fine on my ECoS 50220, voltage set to 18V if that helps. I've not tried to read the HM7000 decoders through ECoS, no need, the Bluetooth method of CV editing is faster and easier to me.

[540itouring]

I am trying to detect the hm7000 with the ecos 50200. the Bluetooth via the app works fine but want to add this loco via DCC to work with the ecos. 

how did you add the hm7000 to your 50220 if you have not detected the decoder ?   please can you explain how you done this as I only know how to detect the decoders / Read them but that does not work as just trips the track power off while reading the decoder with my ecos

track voltage tested at 14 , 16 and 18volts but same fault

 

Edited September 3 by 540itouring
extra info

[nigeb]

I have ESoS 50200. Once the HM7000s are set to DCC they work as expected in operation under DCC. I have noticed that long loco addresses seem to need to be set twice and the CVs refreshed in the HM7000 App but then they work.

I do see a problem though with all the 11 HM7000 decoders I just received. Programming does not seem possible from the ECOS on the programming track or program on the main. On programming track the ECOS immediately goes to STOP (Short). In POM it simply reports Error. I do have another DCC system but I haven't had time to try that yet.

Unfortunately I don't get a huge amount of time to check things, so I'll see if ECOS have an update in case it's that.

If anyone else has any info/solution would be glad to hear.

[540itouring]

Yes that is the problem i have with the ecos detecting a short circuit during reading or writing to the hm7000 . This must be a Hornby problem as all other decoders work fine with the ecos. Hornby say they could not test the Hm7000 with the ecos as the ecos was too expensive for they to get one to test it. 

[96RAF]

16 hours ago, 540itouring said:

I am trying to detect the hm7000 with the ecos 50200. the Bluetooth via the app works fine but want to add this loco via DCC to work with the ecos. 

If the Ecos uses Railcom to conveniently find and identify a decoder then you are out of luck as 7K decoders do not support Railcom as explained in the manua.

You cannot (as previously advised) find a 7K decoder using bluetooth from the Ecos, only from the app. The Ecos as others have said should work the decoders using regular DCC.

[The Equalizer]

15 hours ago, 540itouring said:

I am trying to detect the hm7000 with the ecos 50200. the Bluetooth via the app works fine but want to add this loco via DCC to work with the ecos. 

how did you add the hm7000 to your 50220 if you have not detected the decoder ?   please can you explain how you done this as I only know how to detect the decoders / Read them but that does not work as just trips the track power off while reading the decoder with my ecos

track voltage tested at 14 , 16 and 18volts but same fault

 

I simply add the HM7000 equipped locos manually in ECoS.

[nigeb]

11 hours ago, 96RAF said:

If the Ecos uses Railcom to conveniently find and identify a decoder then you are out of luck as 7K decoders do not support Railcom as explained in the manua.

You cannot (as previously advised) find a 7K decoder using bluetooth from the Ecos, only from the app. The Ecos as others have said should work the decoders using regular DCC.

I've base configured the HM7000 decoders from the App, then switched them to DCC. I've turned off RailCom and Marklin modes on the ECOS, I'm just using plain DCC but I still get the Short circuit with the HM7000 decoders, even just trying to read the settings. I have 30+ other sound and non-sound DCC decoders from many different manufactures including Hornby, Bachmann, ESU, ZTCControls... and they can all be programmed fine - I did check just in case the ECOS had developed a problem. Program on the main (POM) doesn't work either with the HM7000. It might be an update issue for the ECOS, it's a while since I updated it due to not having too much time the last couple years. I'll check and report back in a few days.

[540itouring]

Looks to me if you read or write anything to a hm7000 with the ecos it will short and got to STOP

Set up all settings in bluetooth via app , switch to DCC and then add loco manualy on the ecos. All controls work fine then.

[96RAF]

Spoke with Hornby Tech and they do have an Ecos, albeit an old one, and the say their testing with 7K decoders turned up nothing untoward.

The Ecos is presumably NMRA compliant thus would only put a short low potential programming burst to the service track. Programming on the Main sends standard commands at full potential. I am at a loss as to how a decoder in a properly wired loco or test rig could cause a short.

[nigeb]

4 hours ago, 96RAF said:

Spoke with Hornby Tech and they do have an Ecos, albeit an old one, and the say their testing with 7K decoders turned up nothing untoward.

The Ecos is presumably NMRA compliant thus would only put a short low potential programming burst to the service track. Programming on the Main sends standard commands at full potential. I am at a loss as to how a decoder in a properly wired loco or test rig could cause a short.

Hi 96RAF - I just sent a note to Hornby too. I've got loads of other decoders, even Hornby TTS and they program fine on the ECOS, I even just checked again last night in case something might be failing in the controller. The DCC control itself works perfectly, just the programming that fails. Program on the main just returns Error, it doesn't go to Stop.

I'm also a bit confused that a short should occur, even just sending a CV read immediately sets it to Stop. This is what happens when a short it detected but... I've just recently seen the ECOS do this when the list of loco's is edited and one is edited and tried to be given the same short code reference as an existing one so it may not actually be a short. I didn't get chance yet as pesky work gets in the way but at the weekend I'll see if there's a later firmware and see what happens. I've also got an old ZTCControls controller so I'll try it and see what happens.

For me it's just inconvenience as can still update using the app if needed, just a bit slower waiting while blue tooth connects, especially if only one loco is powered and it drains the phone/tablet battery a bit (glad I have a battery bank or two) 😄 

[540itouring]

I have the latest firmware for my ecos 50200 and hm7000 is also upto date so that does not solve the shorts. The short seams to happen when the loco motor is being pulsed while reading the hm7000

 

All works fine when set up with app via bluetooth and then use dcc and manually enter in the ecos.

 

The point is that this has not been tested with the later ecos controllers because Hornby do not have the money to buy a later ecos controller.  How can that be the customers fault ?

[96RAF]

2 minutes ago, 540itouring said:

The point is that this has not been tested with the later ecos controllers because Hornby do not have the money to buy a later ecos controller.  How can that be the customers fault ?

How can this be Hornby's fault. Using the same train of thought maybe Ecos should test their controller with every known decoder. Do you expect Hornby to buy every make and model of dcc controller at every update state to satisfy your suggestion. They design and build their kit to be compliant with NMRA specs as should every other manufacturer's product. At present there is no NMRA spec for the bluetooth but, but the dcc bit is compliant. In fact Hornby is one of the few manufacturers who actually submits kit for certification, which is much more than declaring compliance.

[SteveM6]

1 hour ago, 540itouring said:

The point is that this has not been tested with the later ecos controllers because Hornby do not have the money to buy a later ecos controller.  How can that be the customers fault ?

Ridiculous. What about the bloke who cobbled together a controller from who knows where and from parts bought for the cheapest price on AliExpress or Temu (unknown provenance). Should Hornby ask him for schematics so they can build their own 'just on case'.

As Rob says, they are NMRA compliant, job done.

[LTSR_NSE]

It certainly isn’t the customer’s fault.

If either Controller or Decoder is definitely not NMRA compliant then that is the most likely culprit.

However if both are NMRA compliant then there must be a currently unknown unintended conflict between them.  In that scenario contacting both manufacturers & reporting the issues to their respective technical support departments seems the most sensible way to get them to (jointly) resolve the conflict.

Edited September 6 by LTSR_NSE

[dBerriff]

There is always some variation in electronic components. Reading a decoder on a programming track requires some clever modulation of currents. Let's say one side is 5% over and the other by bad luck 5% under. That 10% variation in expected current might be enough to persuade the ESU it is seeing a short circuit. I don't know - just speculating.

[nigeb]

Yes, let's see if the issue can be analysed - I don't look for blame, whether Hornby or ECOS, it about finding root cause and solving it. Let's not say it's us or them, let's find the problem and solve it. These things are complex and there are variations, at the end of the day both are said to be NRMA compliant so it's probably something relatively simple, rather than a complex issue.

[Deem]

I have been asked to look into few decoders which my friend used them with ECOS 50220 because I have Elite. Once I get these HM7000 Decoders, I will test them and hopefully share my findings with you guys. Apparently all of them or most of them stop working, so he put them aside and got ESU sound decoders. I was just talking to him about something else, the conversation changed to HM 7000 decoders, so I offered my service to help him out.

[Deem]

I was scrolling and came across this picture, if we go by the picture, ECOS should be supported and should work with HM7000.

[ColinB]

On 06/09/2024 at 12:15, dBerriff said:

There is always some variation in electronic components. Reading a decoder on a programming track requires some clever modulation of currents. Let's say one side is 5% over and the other by bad luck 5% under. That 10% variation in expected current might be enough to persuade the ESU it is seeing a short circuit. I don't know - just speculating.

Actually it is normally timing of edges. Sometimes on some systems you get "ringing" on the leading edge or alternatively the edge could rise slowly because of capacitance. On Can systems we have a parameter called "bit timing" which tells the receiver where on the waveform to sample the data. So it all depends on what waveform the ECOS is pumping out. I must admit I find it all a bit weird. I must admit even though I use Digikeijs all the time for controlling the locos I have only ever programmed my HM7000s with my Elite. It could be the length of time the voltage being applied to the track during programming mode.