FAT or FAT32 for Nanocom EVO?

Quote:

---

Originally Posted by applemac

As I stated before I'm not having a problem with the unit reading or writing to the SD Card. I haven't used it much either. Copied my fuel map, disabled fob immobilizer, checked for faults, and that's all I needed it for right now.

If you are working closely with BBS and you claim that you've had no issues with 8GB SD cards for a long time and no reported issues from other users, why then their manuals give the opposite impression ?

On page 13, regarding the formatting of SD cards they even state: " This information from one of our beta testers may prove useful in the process"

"MAY"....that's reassuring. I'm sure they don't mean the month of the year.

OK, lets agree to disagree. :angel:

---

I said that the documentation was pretty bad in the past, but has been significantly improved recently. I didn't say that it was perfect - parts like the SDCard section could do with work. What I have been suggesting to you is the best available information on how to format SDCards based on the experience of myself and others.

My take is the SDCard advice in the manual retains material pertaining to older versions of the firmware which didn't support FAT32, so there is a conflict of recommendations between sections. Most OS disk formatting utilities will not give you the option of formatting cards larger than 2Gb to FAT file system so the user guide admonition to do so is a bit silly. Strictly speaking it can be done on OSX but it is only possible from the command line: Partition USB disk with FAT16 on Mac OS X | Martin Bergek

The reason the manual says "MAY" is because BBS staff were not able to replicate the issue I and others were having. As they couldn't recreate the original issue, they couldn't verify the work around was effective, so they are relying on the word of people like myself. For me it was a clear cut case - with OS utility formatting the .map upload would consistently fail, with SDFormatter and Logical Address Adjustment option .map uploads would consistently succeed.

By default OS utilities format the disk in such a way that the number of sectors varies depending on the logical location of track. This optimises available storage space. Logical Address Adjustment/Format Size Adjustment formats the disk in a way that every track has the same number of sectors. My theory is that the code required to read data stored on tracks with identical number of sectors has less processing overhead than the code required to read tracks with variable numbers of sectors. I'll hazard a guess that FAT16 uses the fixed sectors per track method of formatting.

My personal view is that the ideal solution would have been for BBS to change to use a faster, more efficient FAT file system library but I recognise that would have involved a rewrite of every module, so probably wasn't practical.

From firmware v1.12 the way Td5 .map loads are done was changed and this makes the whole process far more reliable. In previous versions the .map file was loaded directly from card to the ECU so any issues reading from the card would crash the firmware write process. The result of this was a bricked ECU. The revised process now reads the .map file into a buffer memory on the Nanocom and then verifies the .map before uploading to the ECU. With this scheme card read issues don't risk compromising the ECU.

What I think the sections on SDCards should say is:

Quote:

---

SDHC cards up to 8Gb can be used in the Nanocom Evolution.
All cards should be formatted using SDFormatter application https://www.sdcard.org/downloads/formatter_3/
Cards of greater than 2Gb capacity should be formatted with Logical Address Adjustment (OSX)//Format Size Adjustment (Windows) option turned on.

Important: Using the disk utilities supplied with Windows and OSX to format SDcards larger that 2Gb can result in problems reading and writing to file. It is strongly recommended that SDFormatter be used to format cards to avoid these issues.

---

cheers
Paul

Quote:

---

Originally Posted by applemac

I don't see what your problem is mate, if you can't handle criticism you shouldn't have or be in an open forum. You don't need to be so defensive about it.

---

funny i thought the above more suited your responses than his.

if you cant keep a civil tongue in your head i suggest you go bang away somewhere else.

the guy is trying to help you, God only knows why...

Quote:

---

Originally Posted by incisor

funny i thought the above more suited your responses than his.

if you cant keep a civil tongue in your head i suggest you go bang away somewhere else.

the guy is trying to help you, God only knows why...

---

Hope you have the decency to take it all back. That is insulting and not what this thread was about.

I placed a post here to clarify an obvious problem, that's what forums are for, or aren't they.....you seem to miss the point !!!!?
I did not insult anyone, indeed I thanked Paul for his reply, if you bother to read the all thread.

It's also obvious that Paul has a personal interest in Nanocom and can't handle someone pointing out that there is a problem.
Instead, his initial reply was "go and read the updated manual...you should be on top of the updates". If you read the entire thread you realize that I did......and I maintain the same view.
Why being so protective of Nanocom bits me.

You should take the criticism as constructive, because what I've bee pointing out all along is the obvious.

I suggest you to take back what you just said and bang away yourself.

Applemac please take this as a friendly observation....

I have read the thread I have no interest in what you guys are talking about, however I note that your responses did seem a little strong..perhaps thats not the way it was intended or perhaps it was because you took offence to what was said by off track (most of what i read of his seems to be trying to help???)...I'm not sure but I can see why Incisor said what he said.

can I suggest we all just take a step back and a deep breath and perhaps just agree to disagree.

the thread is already treading a very fine line to what we call the name and shame rule so the fact that the thread is even still here surprises me to be honest.


if the thread carries on the way it is people are going to start getting in to trouble.....so lets just bring it down a couple of pegs:)

Quote:

---

Originally Posted by dullbird

Applemac please take this as a friendly observation....

I have read the thread I have no interest in what you guys are talking about, however I note that your responses did seem a little strong..perhaps thats not the way it was intended or perhaps it was because you took offence to what was said by off track (most of what i read of his seems to be trying to help???)...I'm not sure but I can see why Incisor said what he said.

can I suggest we all just take a step back and a deep breath and perhaps just agree to disagree.

the thread is already treading a very fine line to what we call the name and shame rule so the fact that the thread is even still here surprises me to be honest.


if the thread carries on the way it is people are going to start getting in to trouble.....so lets just bring it down a couple of pegs:)

---

Let's agree to disagree it's exactly what I said not log ago, but you couldn't help yourselves and carried on, insulting.

I'm the one that thanked Paul for his reply at the beginning.

In several occasions I mentioned that there was no problem with the EVO itself as far as I could see.

The issue i raised was simply related to the manual and the way it's written. If this is an offense to anyone in AULRO I'll be damned.

"I'm not sure but I can see why Incisor said what he said."
I beg your pardon?
"if the thread carries on the way it is people are going to start getting in to trouble..."

Go on, delete it......I've got a copy of the entire thread. There's plenty of other discussion groups on the web I can post it in.

Quote:

---

Originally Posted by applemac

Let's agree to disagree it's exactly what I said not log ago, but you couldn't help yourselves and carried on, insulting.

I'm the one that thanked Paul for his reply at the beginning.

In several occasions I mentioned that there was no problem with the EVO itself as far as I could see.

The issue i raised was simply related to the manual and the way it's written. If this is an offense to anyone in AULRO I'll be damned.
"I'm not sure but I can see why Incisor said what he said."
I beg your pardon?
"if the thread carries on the way it is people are going to start getting in to trouble..."

Quote:

---

Go on, delete it......I've got a copy of the entire thread. There's plenty of other discussion groups on the web I can post it in.

---

---

hahahah your so funny...

You are exactly right though, that there are other places to discuss these things so go ahead and discuss it else where. :)

We have name and shame rules for a reason which is why we tell people to actually go to other forums that do allow such discussion to air a grievance or other things they feel they need to say about a company.

No Skin off my nose but if you want to sit here and argue with everyone begging peoples pardons then I will just delete it anyway because the discussion is obviously not going anywhere productive and is just a total waste of bandwidth.

Quote:

---

Originally Posted by applemac

It's also obvious that Paul has a personal interest in Nanocom and can't handle someone pointing out that there is a problem.

---

actually, you couldn't be further from the truth if you tried.

so i'll leave you with it ........

I'm sensing a serve of apple fritters. :rolleyes:

This thread = [FishSlap]

Quote:

---

Originally Posted by OffTrack

I said that the documentation was pretty bad in the past, but has been significantly improved recently. I didn't say that it was perfect - parts like the SDCard section could do with work. What I have been suggesting to you is the best available information on how to format SDCards based on the experience of myself and others.

My take is the SDCard advice in the manual retains material pertaining to older versions of the firmware which didn't support FAT32, so there is a conflict of recommendations between sections. Most OS disk formatting utilities will not give you the option of formatting cards larger than 2Gb to FAT file system so the user guide admonition to do so is a bit silly. Strictly speaking it can be done on OSX but it is only possible from the command line: Partition USB disk with FAT16 on Mac OS X | Martin Bergek

The reason the manual says "MAY" is because BBS staff were not able to replicate the issue I and others were having. As they couldn't recreate the original issue, they couldn't verify the work around was effective, so they are relying on the word of people like myself. For me it was a clear cut case - with OS utility formatting the .map upload would consistently fail, with SDFormatter and Logical Address Adjustment option .map uploads would consistently succeed.

By default OS utilities format the disk in such a way that the number of sectors varies depending on the logical location of track. This optimises available storage space. Logical Address Adjustment/Format Size Adjustment formats the disk in a way that every track has the same number of sectors. My theory is that the code required to read data stored on tracks with identical number of sectors has less processing overhead than the code required to read tracks with variable numbers of sectors. I'll hazard a guess that FAT16 uses the fixed sectors per track method of formatting.

What I think the sections on SDCards should say is:

Quote:
SDHC cards up to 8Gb can be used in the Nanocom Evolution.
All cards should be formatted using SDFormatter application https://www.sdcard.org/downloads/formatter_3/
Cards of greater than 2Gb capacity should be formatted with Logical Address Adjustment (OSX)//Format Size Adjustment (Windows) option turned on.

Important: Using the disk utilities supplied with Windows and OSX to format SDcards larger that 2Gb can result in problems reading and writing to file. It is strongly recommended that SDFormatter be used to format cards to avoid these issues.
cheers
Paul

---

Thank you for understanding my point all along and editing your previous reply.
That is the best reply I had in this entire thread. It clears the all mess.

Hope you understand that there was never an intention to insult, It simply became increasingly frustrating knowing that what I was pointing out was plain English and no one was getting it.