Nanocom (Evolution) Bug Report and Wishlist
Reply With Quote
Hiya bell1975
Wow that is some wish list
However you have to appreciate that the Evolution, as complex as it is, has been designed and built without the benefit of a huge budget, and for a much more limited market, and so cannot really do the same sort of tricks and have the graphic detail possible on many portable devices flooding the market with their high end resolution, colour and processing capabilites.
Perhaps when we have added more models to the nanocom coverage, as the P38 is now almost completed, it may well be that we can make the unit popular enough to justify the cost of making some visual enhancements and certainly we would happily re order INST screens or produce multiple options according to poular demand.
Anyway for now i have to state most honestly that we are really not at the wishlist fulfilling stage although we are now significantly closer to that.
To give you and everyone a bit more of an insight into the current state of things, perhaps its best i give a litttle information and fill in a few blanks You first have to appreciate that i took on / rescued the Nanocom almost overnight, not even knowing it's current state of affairs, or if it even could be saved. I simply recognised it as a popuar product with a good name and what looked like advanced hardware technology with the EVO, although a bit school project looking, that offered very good features at the price point.
It was very much a gamble that looked like a very bad one when i discovered that due to existing errors or bugs in released software, it was actually impossible to even produce a software upgrade that existing owners of either Nanocom One or EVO owners could actually install.
There were also growing numbers of problems being reported by ever more demanding and upset owners suffering seemingly inexplicable problems with settings changing when they should not and so on.
Worse still the previous owner had made rash promises of adding further system coverage in the software but did not even have the time to deal with sales enquiries, let alone support problems and certainly did not have the time to get into the tedious workload of developing new system coverage.
Clearly it was going to take a massive amount of time, money and effort to save this product, but i was willing to give it a go as clearly it is a great product with huge potential, and of course it meets our own "best equipment for the money" objectives.
The first job was quite obvious, fix the broken upgrade paths for both Nanocom one and Evolution systems.
The second job was to re design the Evolution hardware into something far more modern, desirable, robust and hopefully smaller.
The third job was to add coverage for the missing SRS, Autobox and V8 Petrol vehicle systems and look into adding further model coverage as per origional intent.
The fourth job is to debug the software functionality to our own renowned standards.
The fifth job is then to add any and all possible improvements, canvassing suggestions ;-)
Despite our many troubles and woes with massive power outage disruptions and re locating, we have none the less achieved the first 3 jobs in just a few months, and i am certainly a little self proud of this.
In respect of the fourth job of debugging, we have started to look at quite a few reports now, temp alert, boost pressure accuracy, and even Plip programming, and are making good progress, but very significantly I have very recently validated the true cause of these wierd BCU settings problems being due to something i have suspected all along.
It seems that the BCU setting functionality on the Nanocom was derived by monitoring / reverse engineering a third party tool that in turn derived it's capabilty from monitoring / reverse engineering our ROVACOM.
Unfortunately there is a world of diffence between developing something by reverse engineering someone elses work and self development with true understanding, and in the case of the BCU, there is a small but significant factor that would be missed and would cause such results.
In fact as far as i know, there have only ever been two pieces of equipment availaible that correctly handle BCU settings in all situations and cases, the first has been the origional Land Rover Testbook and the second our own Rovacom / Faultmate equipment. However having validated my suspition, quite shortly, we will be adding another by ensuring that the Nanocom One and EVO also handle this correctly too.
This it truly where BBS's long experience and knowlege can help the Nanocom.
I mention this here, as it is really such a significant bug i believe many owners will have suffered from in some seemingly inexplicable form or other, to the degree they may even feel un inclined to change any setting in the BCU for fear of getting into trouble, which is such an opposite aspect as to how owners of our ROVACOM / FAULTMATE owners feel. I believe that when fixed it will represent a really major imrovement to the Nanocom and fix a good percentage of problems in one hit, thus leaving us more time to sort the rest out.
[/IMG]
Originally Posted by Pedro_The_Swift
Bookmarks