We are interested and perhaps concerned about the usable life time of the memory in the MB6....our worry is that we may "wear out" the EEPROM.
One application we are considering uses the "Gate" mode and we decant then erase the stored animal codes periodically about one every 2-3 minutes.
Such an application is in a cattle/sheep sale yard....on a sale day thousands of transactions can occur...the problem is beyond hypothetical.
Is it possible TI will consider replacing the EEPROM with FRAM memory (http://www.ti.com/ww/en/mcu/fram_ultra_low_power_embedded_memory/fram_mcu_faqs.htm#1 )?
I believe even the "Normal" Mode may incur this potential issue, as it stores then erases memory to manage duplicates.
We forecast in some future time perhaps only measured in year(s), that we will witness the loss or corruption of data coming from the MB6 controller....
We would prefer to be prepared for future seemingly "unexplainable" system reading/recording failures...
To replace every MB6 every year or so is plausible but costly....perhaps FRAM memory can forestall this senerio.
Have any members who are long term users of MB2/6 seen this happen yet?...are we jumping at shadows?
Could a TI member care to comment on this eventuality...
Can we order future MB6 with FRAM memory in stead of EEPROM?
Any observation would be appreciated.
the standard EEPROMS used have a cycle life of a minimum of 100000 write/erase cycles. In gate mode IDs are stored up to 999 then no more IDs are stored, the memory is not overwritten therefore no problem with EEPROM failures. The reference guide describes this pretty well:
In the GATE mode each correct identification number is compared with the identifications stored in theidentification memory. If the identification number is new, it is then stored in the identification memory.The ASCII character G activates a continuous readout mode. The TIRIS reader confirms with the ASCIIcharacter G, carriage return and line feed. Each time that a new identification is stored in theidentification memory the ASCII character G, the transponder type character, space, the actualmemory count number, space, application code, space, identification code, carriage return and linefeed are transmitted via the interface.When the identification is stored in location 909, the warning * MEMORY FULL, carriage return and linefeed are also transmitted to the PC. After the warning the GATE mode is still active but no moreidentifications are transmitted to the PC.When GATE mode is selected the K command is disabled as it is not possible to have GATE mode inMultipage transponder mode.
As the plan is to read out and erase the memory every 2 - 3 minutes anyhow, why not reading the IDs in real time and store it in the host system? In addition 999 IDs stored, times 100000 cycles would result in 99.9 Million reads of different IDs...
Therefore no plans to replace the EEPROM with an FRAM!
Thank you KSA....If we offered to pay a premium would TI consider supplying us the MB6 with FRAM?
Your opening paragraph confuses me... me thinks you are in error.. and I ask you to reconsider your conclusion "....the memory is not overwritten therefore no problem with EEPROM failures......."...yes it is? ....I will re-read the reference guide
On a superficial analaysis your 99.9 Million would seem a compelling adequate "full stop" to regard our concern as trivial...but I have an instance worth rethinking on.
Allow me to expand, and ask you to reconsider your conclusion about FRAM... perhaps as I should have done better in the first instance.
At risk to me of being too verbose, I will describe why we think FRAM is worth the effort. In a Cattle sale yard there can be up to 5000 RFID tagged beasts sold on a sale day.
Typically they are sold in "lots" of up to 50...that is, these 50 belong to MrJones, the next 50 belong to Mr Smith...etc...etc
Now you will see there is 5000/50= 100 "weighing plus RFID" sessions per day.
[If each session take 3 minutes then 100x3= 300 minutes= 5 working hours to sell 5000 cattle...this is about right]
Our new "Proof of Concept" system for Australia, is to run 50 beasts onto a "large weigh bridge"....as they enter and then become motionless, their RFID tags are to be read...
We read them as they enter then with an the array of 32 readers surrounding this weigh bridge,we adapt the switching behavior of the reader transmitters.
The Readers now rotary scan/multiplex around the motionless animals...our reasoning being "if you can't move the animals then move the RF field...etc"
By this mechanism and the concept of collision avoidance/mitigation through spatial seperation of a chorous of readers, we can achieve high certainity and for the user we can achieve good speed of commerce.
We have only "one bite at the cherry" here, we must achieve high reading certainity...we must do every thing that is conceivable to read every cow..they won't be comming back.
The total weight of meat is now measured and the new owner of this 50 beasts knows their individual number. A manifest or spreadsheet documents all this...etc
Because as you say, the Gate mode already has the ability to not allow duplicates, it is worth using this, though yes, the duplicates could be removed in the host software...in which case the "Line Mode" woud suffice. No EEPROM to worry about.
We reasoned that 32 readers comming into a host, down 32 RS232 lines (later to be RS485) while primative, would have timing issues in (real-time) Line Mode, if say 4 or 5 readers simultaneously see the same tag...
We decided to make use of the storage capacity in the MB6 and let them hold up to 50 beast numbers (999 cows won't fit on a weigh bridge) and as I have said above, the next 50 beasts may belong to another buyer...we need to clear the memory after the current 50 lot are released from off the weigh bridge...
A button is pushed which opens the exit gate and with the aid of a multiplexer arrangement begins to sequentially decant the 50 recordings from each of the 32 surrounding readers ...ie comPort1 give me your tags, comPort2 give me your tags...comPort32 give me your tags.
When all readers have made their submission then each readers MB6 is sent a Ascii "c" to erase their GateMode memory stack...we only used 50 of their potential 999 capability, but that is no bad thing to us.
Once inside the host software, then it can leisurely scan through all the submitted tags and again remove duplicates.
So, on the basis of one sale-day a week a reader will perform 100 erasures. Over 52 weeks this is now 52X100 =5200 erasures per year...Now if theEEPROM is only good for 100000 write/read cycles this now means 100000/5200=19 years of reliable recording
If there were 2 sale days a week then the EEPROMS are good for 9.5 years
If there were 4 sale days a week (and it may be future possible) then the EEPROMS are good for 4.75 years
In addition the readers may also be used "in the reverse direction", that is as the cattle enter the sale yard they pass through the weighBridgeReader in the opposite direction...they then would be held in holding pens to await the sale.
In this possibility, if this future was to happen, then the EEPROMS would have a working life in our worst case of 4 sale days per week of 4.75/2= 2.375 years.
Allow me to consider now if I had chosen the "Normal Mode" on this 5000 cattle.
The one telegram buffer would be changed as each "nose to tail" serially presented cow appeared...the memory would write/erase 5000 time a "saleDay"...therefore how many sale days before the EEPROM "fades out" =100000/5000=20...yes, thats 20 days!
Yes, I agree, passing the telegrams directly into the host (with some VB eye-candy software) is the ultimate solution...however...however.
I realize it is not your call to get TI to substitute FRAM for EEPROM...I ask you again , can we pay a premium for TI do do this for us anyhow?...we looked far ahead in our design considerations, and we see issues on the horizon for us and our customers.
I apologize for using too many word here, but I attempt to show your 99.9Million is "a red herring"....can I have FRAM if I want to pay for it?
many thanks for the explanation, and sorry I was distracted by EEPROM. No change of buffer memory type is required and R/W cycles should be no problem at all as the buffer is within the RAM of the CTL. Only thing to watch out for is loss of data in case of reset or power down:
'In NORMAL mode (see 2.4.8 and 2.5.3), a correctly received identification number is transmitted via the serial interface only if it is different to the previously received transponder identification. The comparison includes the transponder type (RO, R/W or MPT), read page (if an MPT was read) and the identification number. For this purpose the last transponder information received is stored in an identification data buffer, located in the microcomputer RAM, and each correctly received information together with its transponder type [RO, R/W, and MPT (if in Multipage Transponder mode)] are compared to the content of this buffer. The buffer is cleared by a microcomputer reset or by the PC command CLEAR (2.3.3).'
Please also refer to section 2.5.4 'Battery Backup for Memory' of the CTL Manual SCBU044.
Thanks Klemens...I apologize for my knowledge weakness on this memory business, I suspect I am confusing you and myself.
I think I meant to direct your attention to the "external out-board" SRAM/FlashRam where the 999 cow ID were stored...but it now appears they are contained inside the microprocessor and when "Normal" mode is invoked then only one memory address is repeatedly used...yes/no ?
My concern was for "Write-Endurance" that is , how many Write-Erase cycles the NVRam/FlashRam could endure before the memory deteriorates.
I understand the ID Buffer/Ram could retain the animal ID indefinitely (10 years?) if the battery remained connected as per your reference to section 2.5.4...ok.
I had a mental "older person moment" and got confused with EEPR0M (where probably the MB6 firmware resides) and the fast ID data handling memory external device...perhaps SRAM.
Any how, essentially I wanted to know would it be possible to "wear-out" the Gate Mode memory if I were to keep writing and erasing it say 5000 times a day.
In contrast, the ID inside the tag is stored once and I believe it will still be there in 30 years...yes/no?
I'll drop this now and do some more reflection on the matter.
Thanks for your answer
Klemens..... I continue to need your help on this memory business...please put up with me.
In scbu044.pdf ...fig 2.7 shows a battery backup wiring, suggested as a wise precaution against data loss of memory contents perhaps during a reset....now just what data are we talking about here... is it the 999 tag ID's ?... or is it that plus the new user setting conditions (which I do with S2 utility and S1/1 switched to on?)
We use a 22000uF capacitor as a precaution on the RFM 's VSP power supply line and this may have been or silent saviour in momentary power blackouts....our 24V power source is usually kept metres away hence us having the up close 2200uF along side the MB2/6
Many times I have switched off the VSP power and after minutes/hours when switched on ...then all my S2 settings return as days before I set them.
I have never checked if there were or were not 999tags still in the MB2/6, we just restarted a new session....so I am thinking this memory holdup voltage is related only to animal data only...yes/no?
This now begs my earlier question about the write/erase matter about this EPROM/FlashRam/Sram...whatever....if it "deterioates after say 100,000 cycles...then can you rip it out and replace "it" with FRAM....if we paid to have it done.
Another matter that worries me is that DIP 4pole switch (s1/1=user programming)....just what do the remaining switches (sw1/.2/.3/.4) actually do?????....if they do nothing TI had the chance to delete it off the MB6 as it is also on the MB2...but no it is still there....what do they do, it may or may not be a useful thing for me to know.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.