New HM7000 Decoder Features

[96RAF]

It tells you in the decoder manual.

[Michael-349955]

Thanks for the pointer. That a NO then. I can understand the CV's return is covered by blue tooth but the HM7000 system has missed a trick by not broadcasting the loco ID for a given track location imho.

[andys steam dayz]

Hi

Does anybody know if you can double head with the new decoders and is this available to do now on the HM 7000 controller

[96RAF]

How would the app know where a loco was without some additional trackside hardware to fix its position. Most loco detection systems rely on isolated blocks, track sensors, etc to trigger Railcom into sending a message to the controller. The Bluetooth system does this for decoder ID and likely in the future given development of associated trackside hardware will also be able to send decoder location, just not by Railcom which is not required.

[96RAF]

Hi

Does anybody know if you can double head with the new decoders and is this available to do now on the HM 7000 controller

 

 

The question has already been covered on the forum. You can double head using DCC but not via the App yet, although this may be a future feature. The use of CV19 for double heading is covered in the decoder manual.

[Rallymatt]

Sometimes I do wonder if people think before they type/speak. How on earth can a decoder tell the app where it is? GPS? ESP?

[Michael-349955]

Hornby says HM 7000 is NMRA DCC compliant but how can it be, RailCom is part of the DCC specification and it's not included!

[Fishmanoz]

I think you’ll find Railcom is optional in the spec. There are lots of things optional or manufacturer-defined.

[Michael-349955]

I think you'll find if you read the spec. (RCN217) that elements of RailCom are optional as stated but the main core of RailCom is part of the DCC spec! The problem RailCom has suffered with in the past is manufactures pick and choose which elements of the spec. they wish to use like supported CV's and Hornby have been classic at that in their decoder designs!

[dBerriff]

A specification is not the same as a requirement.

Why shouldn’t a manufacturer implement a compliant subset of a standard for their intended market?

[Michael-349955]

Hornby's decoders have always been short on functions, that's what you get with a budget priced product! In reality, to add RailCom to a decoder the extra cost is very small so it's not cost it's more about the fuctionalty that Hornby wish or not the consumer to have.

[96RAF]

Railcom - I say again it is not required as the functionality of it is achieved by Bluetooth.

Bi-directional comms has been marked in the NMRA spec as discontinued.

[Michael-349955]

The NMRA are not controlling the DCC specs. in Europe any more, this is controlled by RailCommunity in Germany (railcommunity.org) but the NMRA has a seat on the panel. Specs. RCN217 and RCN218 are current and lay out RailCom and RailComplus within DCC. RailCom is predominantly used in the Europe and was never really taken up in the US due to Digitraxx Transponding system. The European equipment manufactures got so fed up with the way that the NMRA handled the specs. that they setup their own organisation to control the DCC specs. and this is RailCommunity of which most of the main European manufacturers have signed up to.

I would suggest that Hornby has aimed the HM7000 system at the US market where they expect greater sales.

Most of Hornby’s European decoder competitors supply RailCom as a standard feature so, NO RailCom is not discontinued.

The NMRA published specs. have fallen behind the RailCommunity issued ones. 

[Nightraker]

Just one for the Techies among you ..

So we have established the new decoders don't have RailCom enabled to report back Train name or number on let's say

i-Train with a DK5000 and block detection (or Hornby Elite..) What if we added this Item (below) (RailCom Transmitting decoder) to a Train fitted with a HM7000 decoder or to a Carriage /Wagon being pulled by the above said train (only wiring required for this is to pos and Neg power)...this is in parallel with you HM7000 and only run it in DCC not BT...would it conflict with the HM7000 decoder??

[96RAF]

You should be able to do that, as it is no different to running 2 decoders on the same address (say as an HST pair). You would have to run the HM7K in DCC mode anyhow as iTrain cannot command by Bluetooth.

Folk have run a TTS decoder for sound in the same loco piggy-backed with a higher rated decoder to drive a current hungry motor, like Heljan.

[Nightraker]

Cheers 96RAF....I think wrighting the HM7k Decoder...first should set the decoder up normal with the CV train number set to what you want. But when the Train O Matic or ESU RailCom Decoder is done connected second and only write the CV with the Train number as set or written to the HM7k decoder .I think otherwise something may conflict??? does that sound fair???

[Michael-349955]

RailCom transmitters will copy all CV's sent to a decoder in a DCC command over the track and will return the data back via the DCC signal to the detector via the track.

 

The disadvantage of the transmitter approach is any CV modified by the motor

decoder i.e. BEMF (speed), decoder temperature etc. has no means of updating

the transmitter’ likewise all CV’s modified by blue tooth.

 

I do think this is a trick missed by Hornby as it’s being more widely used as people see its potential. The hardware cost to adding RailCom to a decoder design is so small and many decoder manufactures add it as a standard feature these days,

So yes, they'll work but to use full RailCom it's only a halfway house, but what address is were on the layout it will do!

 

Michael

MERG RailCom developer  

[96RAF]

@michael - you would be better taking your proposal direct to George Waller at Hornby on the HM.customercare@hornby.com email.

Put a valid case to him and he will either explain why Railcom was excluded due to HM7K comms being OTA or he will put the proposal forward.