Bluetooth Woes

[Baychattan]

I have 11 locos which have HM7000 sound decoders. When my layout is operating all are normally powered, but the ones not running are in sidings (separate power district). I have other non-HM7000 locos.

Four of the HM7000 locos are now giving me grief, in that that the bluetooth part is not working. When I start up the HM-DCC app, 7 locos are found, with the first marked as 'host' with a little blue 'H' next to its blue Bluetooth symbol. The four troublesome locos have red Bluetooth symbols, and don't respond to any commands (motion, lights or sound) from the app.

The HM-DCC is running on an Apple iPad mini 6, iPadOS 17.2 (ie latest). The decoders are all up to date with the latest bluetooth firmware.

If I put any of the four locos on my programming track, and write 0 into CV12 (ie control handed to DCC not bluetooth), when back on the main track they operate normally from my Elite DCC controller, including lights and sound.

The 11 HM7000 locos are listed in the app in the order that they were installed. The first loco listed is a 'good' one, the second and third are troublesome ones. If I start up the layout (or just restart the HM-DCC app) with the first, 'good', loco off the track (ie unpowered), the app 'finds' the second ('troublesome') loco, and it gets a blue 'H' and a blue Bluetooth symbol. But none of the other locos are 'found' by the app and stay with red bluetooth symbols. So the 'troublesome' locos are not forming a mesh with anything else. And, the loco will not respond to commands from the app, ie no movement, lights or sound. But the app is resetting CV12 to 2, so the loco needs another trip to the programming track before it will run from the Elite controller again.

What are peoples' thoughts? Send the decoders back as faulty? (one is in a sound-fitted 9F).

[96RAF]

Hornby interim advice is to rebuild the mesh by unlinking and deleting ALL decoders then rescanning them back in again. A pest to be sure but the problem is under their investigation.

[Pete aka Spanner]

I'm having the same issues..

I only have three locos, the latest one was fitted with it's decoder today.

Yesterday I had absolutely no issues, neither of the locos had little blue "H" and both responded perfectly to commands from my android tablet..

Today I received a new decoder from Hornby, exactly the same as fitted to my existing locos (HM7000-8TXS) I fitted it to my 08 shunter and sat it on the track all alone to do the downloads/updates etc. All went well, everything worked as it should so off I went to put the body back on... returned to the track and put all three locos on to have a play.. that didn't go well. my existing locos connected but the 08 wouldn't, I thought I'd pinched a wire or something but no, all looked good. I tried it on it's own, still would have no of it.. Anyway to cut a long story short.. It would appear that I now have a "Host" loco which can be the 08 if it's on the track alone, If I add another loco (my 55) whilst the 08 is host then the 55 doesn't connect until I restart the app but then the 55 becomes host and the 08 won't connect.... If I then add my 47 it connects straight away.

I just cannot get all three to connect at the same time.. very very annoying and puzzling..

Pete

[Pete aka Spanner]

Thanks RAF

I'll give it a go.. at least I only have three to do..

[96RAF]

@peter

Not having an H at all seems very odd.

[Baychattan]

Hornby interim advice is to rebuild the mesh by unlinking and deleting ALL decoders then rescanning them back in again. A pest to be sure but the problem is under their investigation.

 

 

Doing that with 11 decoders is going to take best part of a day by the time that several decoders have needed their sound files loaded more than once to make them ‘stick’. And the issue could repeat.

 

 

For many months my decoders were ‘H’ free, the ‘H’ only appeared when decoders started dropping out of the mesh. At a guess the HM-DCC app is supposed to be the host. Now, when the ‘host’ loco (only) is powered down the whole mesh collapses and all locos lose connection to the HM-DCC app.

 

 

Methinks I will leave the ‘malignant’ decoders set to DCC operation, and change over the others as and when their bluetooth ‘fails’. Much easier. I will leave rebuilding the system until Hornby have fixed the problem. If any of the decoders get near to a year old before the fix appears then that decoder will be returned as defective - defective firmware is still defective goods.

[96RAF]

There is no need to reload any or all of your sound profiles. All you have to do is disconnect all the decoders from the app, power cycle everything, then reconnect them again. The whole process for 11 decoders should take 20-30 minutes tops.

You misunderstand how the mesh works...

A mesh must comprise more than one node. You cannot have a single node mesh.

Each decoder is part of the mesh as a mobile node and one of them takes host to organise the mesh, i.e. the one with the strongest signal. If any decoder drops out of mesh the mesh finds it as soon as possible and helps it back into mesh.

If the host drops out of mesh say by moving out of range or into a dead spot, the mobile node with the next strongest signal takes over.

The app takes no active part in hosting. If anyone has not had an H showing then likely they are running in Legacy (BLE) mode as opposed to Standard (Mesh) mode.

To improve mesh reliability static nodes will take priority as host over mobile nodes, e.g. HM6010 acc decoder or HM7040 dongle.

[Daedalus]

The Host is what is normally termed a Proxy Node that allows a Bluetooth LE device to "talk" to the Mesh. Bluetooth LE is incompatible with Bluetooth Mesh they are different protocols. The Mesh is not set in stone and manufacturers can modify it to meet their needs.

It normally allows as many Proxy Nodes as you wish but I think Hornby have used Groups so when multiple users are using the layout each can have their own Proxy Node and control their own Group in the Mesh. This does not prevent all nodes relaying packets to all other nodes. Mesh uses packet flooding of the whole Network.

It would help if Hornby at least outlined how they have implemented the mesh.

I don't think the App bothers checking the signal strength it just "works through" its list of nodes till it finds a Proxy node to be the Host. All Hornby encoders can be a Proxy Node which is not always the case in Meshes. Light bulbs can be a node in a Mesh and only have to process on/off which could be used to control a point motor, which hopefully will be implemented in the furure.

[96RAF]

@Baychattan or anyone else who is unable to resolve their problem by following the regular troubleshooter guide.

Hornby suggest you contact them by email at HM.customercare@hornby.com or customercare@hornby.com for direct help with your problem.

[Baychattan]

There is no need to reload any or all of your sound profiles. All you have to do is disconnect all the decoders from the app, power cycle everything, then reconnect them again.

 

 

I have done this, and all the locos are now behaving (at least for the moment).

[GR77]

My advice is get rid of them all i tried to install my first in a bachmann loco and with all the help I received also from hornby change this CV change that cv in the end I scrapped it load of rubbish 

[sir john]

@GR77 don't know why you would advise people to get rid of them I have 4 in bachmann locos 2 deltics 2  2 v2's all run flawlessly both on the app and dcc via my nce powercab 

[SteveM6]

@GR77 of all the HM7K decoders sold very few have failed. Also the majority of issues encountered in setup have been down to the user, often by not following the instructions or the various guides freely accessible on this forum.

Go back to basics, go through those documents and follow the recommendations contained therein particularly around tablet and power source compatibility, wifi and Bluetooth requirements and setting permissions on your device.

[ColinB]

5 minutes ago, SteveM6 said:

@GR77 of all the HM7K decoders sold very few have failed. Also the majority of issues encountered in setup have been down to the user, often by not following the instructions or the various guides freely accessible on this forum.

Go back to basics, go through those documents and follow the recommendations contained therein particularly around tablet and power source compatibility, wifi and Bluetooth requirements and setting permissions on your device.

Actually the HM7K is not the easiest of applications to use it is not the sort of App you can leave for 6 months and come back to. It is obvious that it is done by an outside resource because the simple easy things aren't fixed. My one on Sunday told me to reset the device, so I scrabbled around to find the reset code then realised a Bluetooth scan app would give it to me. So as the Hornby app does a similar scan to look for the device, it could so easily just do the Reset by itself. Simple things that make its use easier.

I have a SYNC device in my car controls the aircon, radio, phone, nav and I have never read the manual, its software is so user friendly that there is no need. Obviously if I want to perform an obscure function then yes, I read the manual, that is the mark of good HMI design. You guys don't notice its faults you are part of the testing team, you use it every day so you can't understand why people that computing isn't second nature have difficulties. I have also had it where it gets in an infinite loop, my pet hate with any app.

So basically it works, I have had one that failed, but other than that mine all work fine.

[96RAF]

The vast majority of 'failures' both of the app, decoders and associated profile loading and connection issues have been proven to be finger trouble. There have been genuine failures and glitches but well documented and promptly resolved.

The fact that very few folk cannot get them to work at all has been proven to be a set-up issue once the decoder is found to be good upon test at return to works. Some folk do come back and report themselves as the problem, but the odd few remain firm that the product is at fault when there are literally tens of thousands of these decoders working perfectly fine from the app and/or via a DCC controller. Hornby have many 'other make' controllers to hand for testing so when someone reports an issue they can usually adopt the same set-up in order to try to emulate the problem.

I would like to be able to do an HRMS and remote control a users kit and prove to them where the problem is but I can't. I have however hand-held a user step-by-step thru' connection problems and in the end they got everything working, just a case of chipping away at it until it surrenders and complies.

[Tomasz-1303413]

I consider myself to be somewhat technology adept, however the setup was not straight forward even for me.

Might be just the batch of decoders I received, but each one upon initial scan and link would require an update, which would fail on the first try. Then I would have to kill the app, since there is no way to exit the update screen and do a rescan, where the decoders would show up as resettable. Knowing that the reset code is just the bluetooth MAC made it easy to find them with a scan tool, but yeah, there shouldn't be reason for that, the app already knows the MAC address of each. This seems to be some sort of a theft deterrent, but is this really an issue for most people? I doubt someone will break into my house just to steal my locos 😛

After reset and relink the update would sometimes work on a second try or I would have to go thru the steps again. After doing this a few times I decided to take a closer look at the versions. The decoders were shipped to me with bluetooth version 0.7 and ROM version 1.4.1, yet the app says the newest versions are 0.6.1 and 1.4.0. So the shipped versions were updated yet the app info was not, resulting in a version mismatch and the app trying to DOWNGRADE my decoders to what it thinks is the newest version. Not cool. Once I realized that, I managed to force the app to use the remaining decoders without doing the "updates", but I won't go into the steps required to do that, it's not easily repreducable. 

Bottom line is, I agree with previous posters, the app is unnecessarily cumbersome and is not being kept updated along with the hardware, resulting in issues. I can work thru them, but I do feel for your average Joe out there. 

[ColinB]

5 hours ago, Tomasz-1303413 said:

I consider myself to be somewhat technology adept, however the setup was not straight forward even for me.

Might be just the batch of decoders I received, but each one upon initial scan and link would require an update, which would fail on the first try. Then I would have to kill the app, since there is no way to exit the update screen and do a rescan, where the decoders would show up as resettable. Knowing that the reset code is just the bluetooth MAC made it easy to find them with a scan tool, but yeah, there shouldn't be reason for that, the app already knows the MAC address of each. This seems to be some sort of a theft deterrent, but is this really an issue for most people? I doubt someone will break into my house just to steal my locos 😛

After reset and relink the update would sometimes work on a second try or I would have to go thru the steps again. After doing this a few times I decided to take a closer look at the versions. The decoders were shipped to me with bluetooth version 0.7 and ROM version 1.4.1, yet the app says the newest versions are 0.6.1 and 1.4.0. So the shipped versions were updated yet the app info was not, resulting in a version mismatch and the app trying to DOWNGRADE my decoders to what it thinks is the newest version. Not cool. Once I realized that, I managed to force the app to use the remaining decoders without doing the "updates", but I won't go into the steps required to do that, it's not easily repreducable. 

Bottom line is, I agree with previous posters, the app is unnecessarily cumbersome and is not being kept updated along with the hardware, resulting in issues. I can work thru them, but I do feel for your average Joe out there. 

Ok why is there not an agree option on the emojis? Yes, you have summed it up quite well. I can get the app to work but I feel for the average user. I generally delete it and reload it every time I want to program a new device, that way it doesn't get confused with the old ones it did 6 months ago. There are things that the app should do like check current version against database version and only update if the database version is later. I did mention this earlier. I have already mentioned the reset issue. Then we have the issue that anything involving bit maps seems to be flaky. I have lost count on the posts involving issues involving any CV. Normally it gets blamed on the operating system like it works on IOS but not Android, that is a very poor excuse.

[Fishmanoz]

I agree with previous posters too - Steve and Rob.

[Rallymatt]

I am about as far away from a computer nerd as you can get. If I can do it, it really can’t be that hard.

I must admit I did cheat though, I read the instructions and followed them. 

 

[SteveM6]

8 minutes ago, Rallymatt said:

I must admit I did cheat though, I read the instructions and followed them. 

 

I believe that is referred to a 'mike drop'.😉

I know I've said this before but I (deliberately) did the opposite. Apart from reading the early comments on here when the iOS version launched and listening to the conversations within the test group in readiness for the Android launch, I didn't read the manual so as to simulate the actions of the many that seem to view reading instructions as a challenge to their manhood.

It all worked, first time, no issues and app did not get itself in a muddle.

Any issues I (and the other testers) did have were fed back to the developers and where necessary, fixes were rolled out. Bear in mind we were tasked with pushing the system to its limits to find out specifically what 'quirks' it may have had.

[96RAF]

58 minutes ago, SteveM6 said:

we were tasked with pushing the system to its limits to find out specifically what 'quirks' it may have had.

But as ever, no matter how much testing you do, gen-pop will break it within minutes. Thats why Amstrad left all quality control to the customer. If it breaks give them another one, don't need the old one for repair, just bin it. Pile them high, sell them cheap. The best no cost quality and test team ever.

[Rallymatt]

Amstrad… a byword for outstanding quality. Alan Sugar was overjoyed when he learned he could save $2 on each computer by not fitting a cooling fan, it was even caught on TV but was probably his Ratner moment. 

[Tomasz-1303413]

4 hours ago, SteveM6 said:

It all worked, first time, no issues and app did not get itself in a muddle.

Any issues I (and the other testers) did have were fed back to the developers and where necessary, fixes were rolled out. Bear in mind we were tasked with pushing the system to its limits to find out specifically what 'quirks' it may have had.

I have no doubt it worked when it first rolled out with the exact same data that was used to so thoroughly test it. No one is questioning the job the testers have done. But since then the versions have changed, the data has been updated and the app has not and what worked then doesn't work now. Initial testing is great, but unless the app is kept up-to-date and follow-on testing is done, it's pretty meaningless long term. 

[SteveM6]

Test team was given access to the app and profiles which were tested in 'live' conditions on real layouts using our existing variety of controllers and devices.

As issues were fixed, those fixes were applied to the app we were all using and tested in live conditions before the development team approved release to the general population.

Every update to either the app or existing profiles has also been through the 'live' test environment before the public ever see them.

New sound profiles are also put into the test environment before general release.

What the test and development teams cannot do is replicate every possible combination of possible setups across the whole of the general population.

To suggest releases/updates post launch were untested is wrong in every way.

[Tomasz-1303413]

I'm not suggesting the updates are untested. I'm suggesting the updates are not happening when they should. The decoders are shipping with bluetooth version 0.7 and ROM version 1.4.1, the app insists that newest versions are 0.6.1 and 1.4.0, tries to downgrade them and fails. The app likely worked fine when it was last updated, but it wasn't updated when the new versions came out. Simple as that.