• Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Radio tag on PCB to communicate with PIC16F18856

Status
Not open for further replies.

Flyback

Well-Known Member
Hello,

We wish to configure our offline LED lamps at the end of the production stage. We therefore wish to put a M24LR64-R radio tag on the PCB, and connect it to our PIC16F18856 micro which is on the lamp's PCB.

We can then transmit to this radio chip and “tell” the lamp what power its supposed to run at, etc etc....

The problem is the datasheet doesn’t give a recommended footprint for the PCB antenna that is needed. Do you know of one? Also, what do we use to actually transmit data to the antenna of the chip?
Presumably the M24LR64-R needs to have its clock and data lines connected to the TX/RX pins of the micro? Also, how does the micro know when we have loaded the M24LR64-R with the data?.....i mean, when we power up the lamp, and haven’t yet sent the configuration data to the M24LR64-R, then how does the micro know that it must wait for us to send the data?

What if we send the wrong data to the M24LR64, and then wish to re-send the data...how will the micro know that we want it to re-read the M24LR64? (and scrap the first lot of data)

M24LR64-R datasheet
https://www.st.com/en/nfc/m24lr64-r.html
 

dknguyen

Well-Known Member
Most Helpful Member
Also, how does the micro know when we have loaded the M24LR64-R with the data?.....i mean, when we power up the lamp, and haven’t yet sent the configuration data to the M24LR64-R, then how does the micro know that it must wait for us to send the data?
Maybe designate two message buffers in the RFID tag and they must match for a command to be valid. Then always write to each message buffer separately with its own write command. Never write to both message buffers with the same wireless write command.

What if we send the wrong data to the M24LR64, and then wish to re-send the data...how will the micro know that we want it to re-read the M24LR64? (and scrap the first lot of data)
You might just have to poll it since it's I2C.

Are you sure you can actually "send" commands wireless to this RFID chip? Because that sounds more like a radio than an RFID chip. I could be wrong, but my understanding was RFID just replies with a set message whenever it receives a matching transmission.
 
Last edited:

JonSea

Well-Known Member
Most Helpful Member
....Presumably the M24LR64-R needs to have its clock and data lines connected to the TX/RX pins of the micro? Also, how does the micro know when we have loaded the M24LR64-R with the data?.....i mean, when we power up the lamp, and haven’t yet sent the configuration data to the M24LR64-R, then how does the micro know that it must wait for us to send the data?.....
The chip uses an I2C interface. It's not connected to a UART interface. Fortunately, the 16F18856 supports 2 I2C interfaces, which use SDA (data) and SCL (clock) lines.

How does the micro know if the setup info is loaded? You should have some default setup in the code. Then, when powered up, the micro reads to eeprom to see if anything is loaded, and if not it uses the default settings.

Screenshot_20180807-100010.jpg
 

rjenkinsgb

Well-Known Member
Most Helpful Member
Flyback - do you realise that part is tagged "Not recommended for new designs", which usually means it is being discontinued?

It looks like the ST25DV series are the replacements, eg.
https://www.digikey.co.uk/product-d...onics/ST25DV16K-IER6S3/497-17125-1-ND/6691438

You can also get example boards with antennas - https://www.digikey.co.uk/product-d...onics/ST25DV16K-IER6S3/497-17125-1-ND/6691438


To verify the config data is valid, take a CRC of it (eg. CRC32). If the data read by the PIC does not have matching CRC, ignore it and assume the config is invalid.

Use the same CRC algorithm on the config data block you send via the RFID system


To check for updates, add a release date to the config data at a fixed location, or just a UNIX timestamp which gives it down to the second.
Read that only (just a few bytes) during program initialisation and compare to the date/time in the locally stored version.

If it's different, copy the new config to a temporary area, do the CRC verification and copy to the permanent config storage if the CRC is OK.
If it's not, ignore the temp data and do another check after a few seconds or minutes
 
Status
Not open for further replies.

Latest threads

EE World Online Articles

Loading
Top