Rallymatt Posted June 22 Share Posted June 22 @Daedalus it doesn’t matter if any other locos are toggled HM/DCC or DCC while uploading a profile via the App; because as soon as you open the App and there is track power, the App will communicate with all the HM 7000 decoders linked to the App, so the mesh is automatically created. I merely listed how power was supplied for completeness. I appreciate you use lots of jargon I don’t understand but as an engineer well versed in fault finding, I cannot see how the actual decoders can possibly be the cause of long profile updates; unless I am the luckiest user of HM 7000 Decoders in which case I really should go and buy a EuroMillions lottery ticket. 😁 Link to comment Share on other sites More sharing options...
Daedalus Posted June 22 Share Posted June 22 (edited) 06RAF said; Yes you can but logic says you concentrate on the profiling matter in hand to minimise risk. I didn't when I got "motor overcurrent" ( the loco is back at Hornby ) I reloaded the profile, as the App advised while my other loco was running. I don't know which one was the host. Edited June 22 by Daedalus Link to comment Share on other sites More sharing options...
Daedalus Posted June 22 Share Posted June 22 (edited) 24 minutes ago, Rallymatt said: @Daedalus it doesn’t matter if any other locos are toggled HM/DCC or DCC while uploading a profile via the App; because as soon as you open the App and there is track power, the App will communicate with all the HM 7000 decoders linked to the App, so the mesh is automatically created. I merely listed how power was supplied for completeness. I appreciate you use lots of jargon I don’t understand but as an engineer well versed in fault finding, I cannot see how the actual decoders can possibly be the cause of long profile updates; unless I am the luckiest user of HM 7000 Decoders in which case I really should go and buy a EuroMillions lottery ticket. 😁 I didn't know that I only ran DCC on Arduino before the App was launched. Do you not see even your downloads are very incredibly slow they are only the equivalent of an 8MB file. By the way I'm prepared to live with it. Edited June 22 by Daedalus Link to comment Share on other sites More sharing options...
Rallymatt Posted June 22 Share Posted June 22 (edited) The only thing I see is that I can take any HM 7000 decoder and upload any profile in 10-12 min and it sticks first time. That’s absolutely fine for me and as far as I know it’s what Hornby suggested it can be. Life is too short to worry about stuff that doesn’t matter. Logic says the mesh must be live if there is track power and App is on, or how would anyone use the App to switch between App control or DCC control? You can check at anytime, just look at any other locos in your engine shed and they are all talking to the App. Edited June 22 by Rallymatt Link to comment Share on other sites More sharing options...
SteveM6 Posted June 22 Share Posted June 22 3 hours ago, LTSR_NSE said: I’ve obviously missed something… what does this decoder processor clock speed discussion have to do with this thread? (about inconsistent profile loading times) I believe (unless I’m mistaken) that this & other threads have already reached a consensus that on iOS devices (less than approx 5yrs old) loading times are fairly reliable, consistent, & not too long (approx 20-30 mins max - usually within 20mins). Whereas on android devices (even brand new ones), loading times are extremely inconsistent (between different types) & can easily take longer than 30 mins on certain devices. If that is correct (& I’ll happily be corrected if I’m mistaken) - then any part of decoder cannot be a cause, as it is a constant. Whereas phone/tablet Bluetooth chips (or other device specific components) absolutely will be the cause. I believe that your summary is absolutely correct - load times are device dependent. Every comment after that was unnecessary technobabble.🤐 1 Link to comment Share on other sites More sharing options...
ColinB Posted June 22 Share Posted June 22 5 hours ago, Daedalus said: I 'm not suggesting the schematics are released but they could say what speed it is being clocked at, as they have not scrubbed the manufacturer's part no. from the microcontroller it can not be that sensitive info. If you look at the basic manufacturers spec available online it uses an Arm M0 clocked @ 49 Mhz and 98 MHz oscillator crystals are readily available. I'm just trying to suggest why seeking WiFi and bluetooth LE problems might not be the best use of time if achieving the fastest possible flashing was not a design goal and they settled on slow but reliable instead and concentrated on the sound features etc. Hornby and/or Bryer could clear this up without giving away their secrets. Unfortunately I haven't seen their code but I assume they did it the old way, download a load of bytes wait a defined period then send the next lot. In automotive you download the bytes and then wait for the module to send back a message to say it has done it, plus frame number and checksum of bytes received. If the frame number is wrong you send that frame again, we used to do it 3 times before an error is flagged. You can do it much faster as the flash erase time varies dependant to what is stored in there. If I remember rightly clearing a 0x00 to 0xff takes the most amount of time, so the programming time is not constant. Then you have the Smart phone end, I suspect they have used third party products which are easy to implement but generally very slow, our IT programmers used to always do this. I worked for engineering so I wrote my own interface which was much faster. The other issue you get with 3rd party tools is when they upgrade them, many businesses have got caught out on that one. Either way they are not going to change it, so we are stuck with it. It seems in my case the Android phone is quicker than my Android pad and I definitely am not buying an Apple product on principle. Link to comment Share on other sites More sharing options...
Rallymatt Posted June 22 Share Posted June 22 @SteveM6 sadly my ‘like’ quota is used up but in total agreement. Too much ‘look at the techno twaddle I know’ but failing to see the obvious. When I started a topic ‘too much information’ this was exactly the issue I was referring to. At the end of it all, no one is any better off. 2 Link to comment Share on other sites More sharing options...
LTSR_NSE Posted June 22 Share Posted June 22 17 hours ago, Daedalus said: Do you not see even your downloads are very incredibly slow they are only the equivalent of an 8MB file. @Daedalus you & @ColinB are the only ones who appear to hold (& wish to discuss) concerns with the method/speed of data transfer between device & decoder when it is working consistently & optimally. All other posts in this thread are discussing inconsistent & sub-optimal data transfer (caused by device specific components). I don’t believe that anyone wishes to prevent discussion or sharing of opinions. However if those differing opinions relate to what the topic of a thread is - then that simply creates confusion & nothing productive can be gained. Mods rather than shutting down or deleting anything - could these two separate discussions be split into two threads? (That way both discussions can continue - if there is more to add to either - but neither discussion is confused/derailed by the other.) Mod note - if the discussion wishes to continue then start another thread. This one has been more or less sanitised back to the original topic. 2 Link to comment Share on other sites More sharing options...
Recommended Posts