Forums

Hello Ray,

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 the
identification 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 ASCII
character G, carriage return and line feed. Each time that a new identification is stored in the
identification memory the ASCII character G, the transponder type character, space, the actual
memory count number, space, application code, space, identification code, carriage return and line
feed are transmitted via the interface.
When the identification is stored in location 909, the warning * MEMORY FULL, carriage return and line
feed are also transmitted to the PC. After the warning the GATE mode is still active but no more
identifications are transmitted to the PC.
When GATE mode is selected the K command is disabled as it is not possible to have GATE mode in
Multipage 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!

Regards,

KSA

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?

Kind Regards
Ray

Ray,

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:

SCBU028 1.3.2:

'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.

Best regards,

Klemens

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

Ray

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.

Thanks

Ray