SteveM6 Posted June 20 Share Posted June 20 Just for comparison I reloaded the 4VEP profile this morning but this time I did it in the shed at the furthest point from my router. WiFi speed was down to 70/40 Mbps (as expected) but the overall load time was still 45mins and loaded first time. Not ideal but manageable. Link to comment Share on other sites More sharing options...
Brew Man Posted June 20 Share Posted June 20 I think unless your WiFi connection is particularly poor, it might be clutching at straws thinking it is the reason for slow loading times. My loading times are typically 30-40 minutes, slower than others are experiencing but I'm not bothered. It takes as long as it does. Do something else while you're waiting. Link to comment Share on other sites More sharing options...
dBerriff Posted June 20 Share Posted June 20 (edited) Where does Wi-Fi come into it? To get the data to your phone or tablet. You could of course use 4G or 5G wireless but will require good reception. Back to domestic Wi-Fi; I should have mentioned fibre-to-the-premises. That helps shift the bytes across from the server at a decent rate. There are many links in the chain. Your download time will be determined by the slowest link. Then there might be dropped data packets and error recovery... Edited June 20 by dBerriff 1 Link to comment Share on other sites More sharing options...
AngryOldMan Posted June 20 Share Posted June 20 I have had a look at the profile update process. The total file size is about 8MB in total. WIFI really isn't a factor in upload times unless you use a 56K modem! I did some testing with Bluetooth on a few old Android devices. I can confirm that those old Bluetooth chips really struggle for 20 minutes or more. A new tablet takes about 10 minutes. So if you use an old phone/device, treat yourself to an upgrade for better speeds. I noticed streaming music to my Bluetooth speakers also increased the profile update time. I would suggest shutting all apps, getting as close as possible to the locomotive, while you do a profile update. P.S. With the way Bluetooth works, someone needs to test a profile update in a busy place. I would bet that a space with hundreds of Bluetooth devices will slow everything down. Link to comment Share on other sites More sharing options...
dBerriff Posted June 20 Share Posted June 20 (edited) On reflection, that is more likely to cause problems I agree. I do not use Bluetooth much so I had not considered congestion in the 2.4GHz band affecting BLE. I also keep my tablet right next to the HM7000 board when uploading and assumed everyone did the same. I have always had reasonably quick installs so I conclude that the HM7000 technology is fundamentally sound. Edited June 20 by dBerriff Link to comment Share on other sites More sharing options...
96RAF Posted June 20 Share Posted June 20 41 minutes ago, AngryOldMan said: With the way Bluetooth works, someone needs to test a profile update in a busy place. I would bet that a space with hundreds of Bluetooth devices will slow everything down. This is what the test team does. When a new profile is launched in beta form, the test team members all give it a go on their different devices to hand and report back loading time, accuracy, profile function content / icons and any glitches, etc. Once the team is happy it launches onto the publish server. Trying to do an install in a busy public place would be fun tho', setting up a bit of track, loco and PSU / controller, etc. That may get you some odd looks in an internet cafe, the local coffee shop or library. Link to comment Share on other sites More sharing options...
ColinB Posted June 20 Share Posted June 20 9 hours ago, 96RAF said: That must have been before they changed their mind on process. As usual always use the latest published information. Historical fact at the time in the Hornby world can be awry, e.g. use of analogue controllers at full whack as a HM7K power supply. To be honest, I still wonder if they are telling you the truth, some of my team frequently told our testing team incorrect information generally because they didn't know the detail. Normally you copy the file then pass it through a process that strips it into bytes of data. On the Pic processors I used to program, I think it was 255 bytes at a time, other processors it was different. Either way it doesn't really matter as whatever the process is, we are not going to change it Link to comment Share on other sites More sharing options...
ColinB Posted June 20 Share Posted June 20 I have got two new ones coming in the next couple of days, seeing as it takes generally 25 minutes to load I will switch off the WiFi once it starts doing the main reprogram. It could be the bluetooth, I know a knowledgeable guy on our audio design team was not impressed with it. 8 Mbytes is a pretty big file to download 8 bytes at a time. Link to comment Share on other sites More sharing options...
96RAF Posted June 20 Share Posted June 20 Back in the day of Elite updates when v1.42 swapped from boot-loader, the manual way, to a simpler .exe installer the test regime had to identify where the bottleneck was and it turned out to be the PC chipset. We tried initially 16 different loading speeds and after logging the PC chipsets settled on the 3 PC types we have in today's Elite firmware update installer. No doubt a similar exercise could be done with Wifi and Bluetooth combos for loading profiles to iOS and Android devices, but is it worth trying to optimise the procedure by invoking a user choice from a drop-down list. Probably not. Link to comment Share on other sites More sharing options...
Daedalus Posted June 21 Share Posted June 21 The elephant in the room is it has nothing to do with WiFi or Bluetooth LE. By the way Bluetooth, Bluetooth LE and Bluetooth Mesh are completely differrent protocols. The microcontroller has a SPI and UART interface for Flash Rom programming as it is referred to as SPIROM one assumes SPI is being used. Both are serial and complete memory blocks have to be Erased then Written, it is not random access. However as it is embedded it is Read parrallel. The Write speed is also dependent on the clock speed of the microcontroller divided by 2 which is the theoretical maximum Write bit rate. No doubt I will be banned again by the bullying moderators who tolerate no correction of their mates posts. Mod note - your silly remark struck thru. No need for it as it detracts from your credible technical explanation. Link to comment Share on other sites More sharing options...
dBerriff Posted June 21 Share Posted June 21 (edited) So why, as an early adopter, did I not see the long download times that others were reporting? The HM7000 boards are the common factor. Minor app glitches apart, everything has gone well here from day one. I use a base-level iPad, 3 or 4 years old as another variable factor. P.S. I ask in the spirit of engineering understanding. I am occasionally asked by members of the public for advice (!) on DCC and I would like to get it right. Edited June 21 by dBerriff add P.S. Link to comment Share on other sites More sharing options...
96RAF Posted June 21 Share Posted June 21 1 hour ago, dBerriff said: So why, as an early adopter, did I not see the long download times that others were reporting? The HM7000 boards are the common factor. Minor app glitches apart, everything has gone well here from day one. I use a base-level iPad, 3 or 4 years old as another variable factor. P.S. I ask in the spirit of engineering understanding. I am occasionally asked by members of the public for advice (!) on DCC and I would like to get it right. I also have had very few problems loading profiles from day 1 with an iPad and I take no special precautions. All my locos are on the layout and my internet connection in the garage train room is by way of a power-line adapter. It does appear to be a cumulative kit problem per user. Some have nothing but problems and others see few or none. Link to comment Share on other sites More sharing options...
ColinB Posted June 21 Share Posted June 21 9 hours ago, Daedalus said: The elephant in the room is it has nothing to do with WiFi or Bluetooth LE. By the way Bluetooth, Bluetooth LE and Bluetooth Mesh are completely differrent protocols. The microcontroller has a SPI and UART interface for Flash Rom programming as it is referred to as SPIROM one assumes SPI is being used. Both are serial and complete memory blocks have to be Erased then Written, it is not random access. However as it is embedded it is Read parrallel. The Write speed is also dependent on the clock speed of the microcontroller divided by 2 which is the theoretical maximum Write bit rate. No doubt I will be banned again by the bullying moderators who tolerate no correction of their mates posts. Mod note - your silly remark struck thru. No need for it as it detracts from your credible technical explanation. I completely agree with you especially your last comment, I too have had issues. That is what I assumed to be the process, I know when I have used SPI devices they have been a pain. I also feel Hornby so called technical guys, are feeding duff information first we have the Powerpack that is controlled by the decoder, when anyone with a basic knowledge of electronics knows you need 3 connections to do this, rather than 2 (2 for power, 1 for control). Similarly the process for this. I have written many reprogramming routines but it wasn't until I saw a German company we dealt with use a different technique which involves command and response system and a retry method for failed blocks. I suspect the mobile phone companies use a similar approach. The old way used to be to use "timeouts", which means the download process is substantially longer than it need be. Mod note - defamatory wording struck thru' for your own protection. Link to comment Share on other sites More sharing options...
SteveM6 Posted June 21 Share Posted June 21 This thread began as a useful sharing of experiences with this particular facet of HM7K performance with a mix of advice direct from the Hornby project team and anecdotal suggestions from users. We have also seen more technical descriptions of how the various systems may integrate, which is useful in adding more layers of information to this obviously contentious subject. For me an area of consensus is that iPad users seem to have fewer issues, provided they are on a recent version of iOS. Does that mean that the slower performance is confined to Android users I wonder? And if so, why? Android tablets can be significantly cheaper than Apple products - do they tend to use cheaper, slower chips to achieve a price point? Is this the root cause of the perceived issues? Is it something inherent in the Android operating system? As the app was, I believe, primarily developed on and for Apple, have compromises been made to adapt it to Android? I don't know the answers to these questions but it would be good to know. Maybe the slower performance of my android tablets is just the way it is with iPad's faster loading something that will always be out of reach. It's curious that I can get faster times on Android if I use a Samsung phone though. Unfortunately I find small screens unusable for loco control. But it does make you think that better, faster components are in those devices. As I said earlier, this thread began as a useful sharing of experiences which has certainly aided my very amateur understandably of the issue, however...........some 'contributions' are less than welcome, with one person determined to 'prove Hornby is lying' and another taking snide potshots at the mods. This is not the place for those behaviours. 5 Link to comment Share on other sites More sharing options...
Bulleidboy Posted June 21 Share Posted June 21 (edited) I think the time it takes for a download is down to the system you are using. Once I got my head around the set-up process I have had no problems whatsoever. I have a very basic set-up consisting of the Hornby Elite (with dongle) and an iPhone 8. I have just, as a test, loaded the 4-VEP on to a loco. There are six other TXS fitted loco's on the track, and the iPhone was next to the loco to be loaded. It took thirteen (13) minutes and loaded first time - sorry Steve - not rubbing it in😃. Edited June 21 by Bulleidboy 1 Link to comment Share on other sites More sharing options...
ColinB Posted June 21 Share Posted June 21 10 minutes ago, SteveM6 said: This thread began as a useful sharing of experiences with this particular facet of HM7K performance with a mix of advice direct from the Hornby project team and anecdotal suggestions from users. We have also seen more technical descriptions of how the various systems may integrate, which is useful in adding more layers of information to this obviously contentious subject. For me an area of consensus is that iPad users seem to have fewer issues, provided they are on a recent version of iOS. Does that mean that the slower performance is confined to Android users I wonder? And if so, why? Android tablets can be significantly cheaper than Apple products - do they tend to use cheaper, slower chips to achieve a price point? Is this the root cause of the perceived issues? Is it something inherent in the Android operating system? As the app was, I believe, primarily developed on and for Apple, have compromises been made to adapt it to Android? I don't know the answers to these questions but it would be good to know. Maybe the slower performance of my android tablets is just the way it is with iPad's faster loading something that will always be out of reach. It's curious that I can get faster times on Android if I use a Samsung phone though. Unfortunately I find small screens unusable for loco control. But it does make you think that better, faster components are in those devices. As I said earlier, this thread began as a useful sharing of experiences which has certainly aided my very amateur understandably of the issue, however...........some 'contributions' are less than welcome, with one person determined to 'prove Hornby is lying' and another taking snide potshots at the mods. This is not the place for those behaviours. It could be the App was initially designed for iPad use and then modified for the Android app, which would make sense since it took considerably longer for the Android app to become available. Hornby are not lying, I just think there is a human interface issue somewhere. Either way it makes little difference we are not going to get it changed I suspect many of the issues are associated with the "bootloader" on the actual HM7000 device, which is virtually impossible to change now the devices have been released. The only issue I have is, if it isn't anything to do with the WiFi, then people are needlessly trying to improve their WiFi (like paying BT for extra devices) when there is no need. Anyway two new devices arrived today so I will do some checking. Link to comment Share on other sites More sharing options...
96RAF Posted June 21 Share Posted June 21 1 hour ago, ColinB said: duff information first we have the Powerpack that is controlled by the decoder, when anyone with a basic knowledge of electronics knows you need 3 connections to do this, rather than 2 Colin I am getting tired of giving you the same reply to the same comment. The PB charging rate is controlled by the resistors, but it does not see power across the circuit until the decoder flips the gate on the transistor to on, then charging can begin. A 3 wire stay alive uses the 3rd wire to monitor charge rate and level according to ESU. Your accusation of Hornby Tech guys struck thru' to keep you out of trouble with their legal department. Link to comment Share on other sites More sharing options...
SteveM6 Posted June 21 Share Posted June 21 Getting back to testing, I have just unlinked one loco from the tablet and have started the profile load using an old Samsung S9 - the SPIROM counter shows a very similar 46 mins estimated time. I will repeat with a Samsung S22 when I get a chance. Link to comment Share on other sites More sharing options...
ColinB Posted June 21 Share Posted June 21 (edited) 1 hour ago, 96RAF said: Colin I am getting tired of giving you the same reply to the same comment. The PB charging rate is controlled by the resistors, but it does not see power across the circuit until the decoder flips the gate on the transistor to on, then charging can begin. A 3 wire stay alive uses the 3rd wire to monitor charge rate and level according to ESU. Your accusation of Hornby Tech guys struck thru' to keep you out of trouble with their legal department. Ok I too am fed up with this. The powerpack has two wires, one I assume goes to ground the other feed Vcc via the diode. Now the transistor could be in the ground return, which is possible, in which case any "stay alive" circuit will work. I must admit I dismissed that as I considered the transistor would be rather large, but it is possible. It can't be in the feed as transistors can only pass current one way, so you would need a separate wire to the charge resistor. End of story, as for Hornby I did not say anything inflammatory, they are being careful with the information they pass to the testing team. As to their legal department they have bigger fish to fry. Actually thinking about it if it does switch the ground it should work with my YouChoos "stay alive" which normally stops you reading parameters on any other decoder it is connected to. Edited June 21 by ColinB Link to comment Share on other sites More sharing options...
96RAF Posted June 21 Share Posted June 21 11 minutes ago, ColinB said: which normally stops you reading parameters The 7K decoder has a short lag before enabling the PB charge, this is a) to offset in-rush current across the layout with many decoders and b) it also allows a programming burst to get thru' before PB charging kicks in and soaks up that signal. Link to comment Share on other sites More sharing options...
SteveM6 Posted June 21 Share Posted June 21 50 minutes ago, SteveM6 said: Getting back to testing, I have just unlinked one loco from the tablet and have started the profile load using an old Samsung S9 - the SPIROM counter shows a very similar 46 mins estimated time. I will repeat with a Samsung S22 when I get a chance. The load completed but failed on the S9 - probably an interruption as I've not switched off any apps. Started the load on the S22 and immediately the estimated time dropped to 31 mins. Same loco, same decoder, same test track, same distance from router, only the device has changed. It does suggest that on Android, it is more device dependent. Link to comment Share on other sites More sharing options...
SteveM6 Posted June 21 Share Posted June 21 22 minutes ago, SteveM6 said: The load completed but failed on the S9 - probably an interruption as I've not switched off any apps. Started the load on the S22 and immediately the estimated time dropped to 31 mins. Same loco, same decoder, same test track, same distance from router, only the device has changed. It does suggest that on Android, it is more device dependent. It was actually faster than the estimate! Closer to 15 mins. It still failed but that's not relevant at this juncture. Link to comment Share on other sites More sharing options...
ColinB Posted June 21 Share Posted June 21 Ok, I have just loaded a profile into my new HM7000. No it doesn't need the WiFi once it gets going, seems to be a bit of slightly incorrect information. One the programming had started I pulled out the power to my BT hub so no wireless, the reflash carried on exactly as it had always done. So it looks like it is as I suspected App copies file to smart device then does it "stand alone". I was surprised that anyone would try and do it any other way. I am now doing it with the WiFi enabled and it is taking the same time. It has to be the bluetooth. Incidentally this App is a xxxxxx if you haven't used it for a while trying to link into decoders that don't exist anymore. Mod note - naughty word edited out. Link to comment Share on other sites More sharing options...
SteveM6 Posted June 21 Share Posted June 21 48 minutes ago, SteveM6 said: It was actually faster than the estimate! Closer to 15 mins. It still failed but that's not relevant at this juncture. Back to the tablet and back to an hour. And it took an absolute age to reconnect/find the decoder To coin a phrase - there's your problem. For whatever reason, this is too device reliant for my taste.🤬 Link to comment Share on other sites More sharing options...
96RAF Posted June 21 Share Posted June 21 53 minutes ago, ColinB said: if you haven't used it for a while trying to link into decoders that don't exist anymore. If you make those decoders/locos inactive the app will not poll them. If not existent then delete them from the app, using force delete if required. Link to comment Share on other sites More sharing options...
Recommended Posts