This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ISO15693 protocol selection for noisy environment

Other Parts Discussed in Thread: RF430FRL153H, TRF7960, RF430FRL152H, MSP430F2013

Hi,

I was wondering what the pros/cons of single vs dual subcarriers would be? The same question applies to 1-in-4 vs 1-in-256. 

If dual subcarrier give a slightly faster data rate (26.69kbits vs 26.48kbits) then what is the trade off?

Is seems that if you want a fast data rate then 1-in-4 is preferential, so then why would you choose 1-in-256? Is it slower but with better noise resilience?

I'd just like to know what sort of decisions drive the protocol selection.

  • Stephen - 

    Protocol is already chosen....data coding and rate are the details you are asking about

    the 1 of 256 was made available originally because the allowed power output was limited much lower than it is today (since early 2000's, don't remember exact date) so it was for regulatory purpose where back in "the day", with high power readers, we were passing data at a very slow rate of speed to pass testing....

    now then - with the question of ASK (single) vs. FSK (dual)...sure...if you are in noisy environment, FSK is always the way to go...its a special case when its really/absolutely needed though - most applications can use 1 of 4 and ASK uplink with no impact on performance . 

  • Josh,
    In my current project I will be making both the tag (when the RF430FRL153H shows up) and the reader (with a TRF7960) so expect to have free choice of all options within the 15693 protocol. Against that background, then:

    If FSK is better in a noisy environment, is there ever any reason not to use it instead of ASK?

    Since it is no longer "back in the day", is there ever any reason not  to use 1-in-4 instead of the slower 1-in-256 encoding?

    Thanks,

    Phil Ekstrom

  • PN is RF430FRL152H :)

    Personally, i would say there is never any reason to use 1 of 256 on low power reader solution like what the TRF79xxA devices offer. (high power in this case meant 4W to 10W)

    ASK vs. FSK...there is a very slight timing advantage to using double subcarrier (300nSec per bit)

  • Searches on the site for RF430FRL153 today return no matches, but there is an ad window on the same page advertising the part and linking to the same product preview as we have had for a long time. A link for samples and pricing sends you off to to suppliers, who disclaim any knowledge.

    What is up? Is introduction still scheduled for December 2014?

    Also, does the SD14 ADC exist in any other part so I can get some experience with it?

    Phil Ekstrom

  • Phil - 

    the RF430FRL152H, -153H and -154H are still slated to be launched in Dec. 2014. Planning and collateral are well in progress for that. 

    The closest SD14 that comes to mind is on the MSP430F2013, however - the one in the RF430FRL was created for it, so its not exactly the same - if that helps.

  • Josh,

    Thanks for the reassuring update on the -FRL153H.


    I know the SD16 (that appeared first in the F2013 and is now in other F2x and F4x units)  well, having evaluated it for use as a Random Number Generator (RNG). Most units work beautifully in that application, BTW, passing the entire NIST battery of RNG tests. There is a simple test usable in production to weed out the roughly 30% that like to make excess even numbers and won't pass.

    I will need a RNG on both ends of my link and it needs to be on-chip with the encryption (though not necessarily with the radio) at both ends for security reasons, so the SD14 is of interest for that same off-label use in the FRL153H. The SD14 is claimed to have a first order modulator instead of a third order one, and presumably has a correspondingly simpler filter, so it will be different but my guess is that it will also make a good RNG if we can get access to the bottom bits of its filter register as we do in the SD16.

    There is a likely work-around to try even if we can't see those bits, and if this were not the SD14's first appearance I would check out those issues now, but I guess I'll find out about all that in December.

    Again, thanks.

    Phil Ekstrom