I am trying to find a way to receive tag numbers from an RFID reader at up to 5 a second, attach a time stamp to each one and buffer them ready to send to a PC without losing any! The reader has an RS232 interface which is configurable as does the PC, all data is ASCII. I was thinking that the DS1307 clock could be used to timestamp each tag. Could anyone give me suggestions as to how all this might be done please? Not in any great detail as I would like to have a go myself, just don't know where to start. I guess to reliably store the data that quickly I would need at least 2 PICAXE, one to receive data the other to transmit it. Is a PICAXE solution possible?
RFID suggestions please
- Thread starter budge
- Start date
hippy
Ex-Staff (retired)
A PICAXE solution is potentially possible, but I suspect it would be much easier to timestamp the data in the PC.
Presumably you will have some PC software which would read the RFID data and the timestamp received and store it away on disk or otherwise process it, so it shouldn't be that much more difficult to have the PC software add the timestamp itself.
This is an easier and potentially cheaper solution than adding PICAXE's - A PC executes about 100,000 times faster than a PICAXE, PC serial has buffering so much less chance of missing data, and PC clocks can be set as accurately as using a DS1307 with NIST or NTP servers if you have an internet connection.
If you don't have an internet connection and the PC's clock isn't reliable enough, it would be possible to have a PICAXE handling a DS1307 and create a simple hardware mechanism to allow the PC to select between the RFID data stream and the PICAXE on a single serial line, or even more simply, put that on a separate serial port. The PC clock is probably accurate in the short term, so the DS1307 only needs reading when the PC or RFID handling application starts up.
There are all sorts of problems in using a PICAXE to handle back-to-back and high-speed serial data, and especially so when asynchronously receiving and transmitting, and you would probably be creating a lot of unnecessary, difficult and time-consuming work using PICAXE's to do this. There's no guarantee that what you want would even be implementable using PICAXE's.
Presumably you will have some PC software which would read the RFID data and the timestamp received and store it away on disk or otherwise process it, so it shouldn't be that much more difficult to have the PC software add the timestamp itself.
This is an easier and potentially cheaper solution than adding PICAXE's - A PC executes about 100,000 times faster than a PICAXE, PC serial has buffering so much less chance of missing data, and PC clocks can be set as accurately as using a DS1307 with NIST or NTP servers if you have an internet connection.
If you don't have an internet connection and the PC's clock isn't reliable enough, it would be possible to have a PICAXE handling a DS1307 and create a simple hardware mechanism to allow the PC to select between the RFID data stream and the PICAXE on a single serial line, or even more simply, put that on a separate serial port. The PC clock is probably accurate in the short term, so the DS1307 only needs reading when the PC or RFID handling application starts up.
There are all sorts of problems in using a PICAXE to handle back-to-back and high-speed serial data, and especially so when asynchronously receiving and transmitting, and you would probably be creating a lot of unnecessary, difficult and time-consuming work using PICAXE's to do this. There's no guarantee that what you want would even be implementable using PICAXE's.
Hippy,
Thanks for the reply, it makes sense. I was trying to relieve the PC of doing real time data transfer as it may be busy collating results, trying to print or whatever windows gets up to when it's bored! I guess the easiest way is to use another PC (perhaps a non windows, handheld) for the data transfer and time stamping. It would have been nice to use a PICAXE though.
Thanks for the reply, it makes sense. I was trying to relieve the PC of doing real time data transfer as it may be busy collating results, trying to print or whatever windows gets up to when it's bored! I guess the easiest way is to use another PC (perhaps a non windows, handheld) for the data transfer and time stamping. It would have been nice to use a PICAXE though.
hippy
Ex-Staff (retired)
Although Windows et al can go off and twiddle its thumbs unexpectedly, a large serial buffer will ensure no loss of data, and even with a small one, data can be pulled off and put into a buffer under program control. In fact, the quicker the hardware/OS buffer can be emptied the sooner it can be time stamped, and more accurately.
I don't know of that many situations where Windows locks out entirely, and the PC only needs a very short period while other things are happening to unload the serial buffer. I wouldn't have thought there'd be a problem.
It's true that Windows isn't a proper real-time OS, but its multi-tasking does mean that there shouldn't be much jamming it up.
If you do need spot-on time stamping, although the PICAXE isn't really suitable, many other micro's will be.
I don't know of that many situations where Windows locks out entirely, and the PC only needs a very short period while other things are happening to unload the serial buffer. I wouldn't have thought there'd be a problem.
It's true that Windows isn't a proper real-time OS, but its multi-tasking does mean that there shouldn't be much jamming it up.
If you do need spot-on time stamping, although the PICAXE isn't really suitable, many other micro's will be.
I would have thought you have a reasonable chance of succeeding. You would certainly need a PICAXE capable of having a 16Mhz resonator to maximise the processing power.
Some random design thoughts:
- you are building a real-time system, so a sound design is an absolute must
- you have up to 200mS to deal with each 'RFID' so you'll be able to run a reasonable number of lines of code plus a 'sertxd' at 19200 baud to the PC
- if you need comms from the PC to the PICAXE, then that's much more difficult to sort out, Even impossible perhaps, since the PICAXE has to wait for a serial 'in' transmission and can't be doing anything else at the time
- using a DS1307 to timestamp should be fine. Use the 0.5 second SQW output as an interrupt to the PICAXE. Use Hippy's XOR masking trick (search to find it) to only process every other interrupt so that once per second you read the 1307 and put the time in the PICAXE
RAM. Then when you want to timestamp, just use the values in RAM - the interrupt will keep them updated 'in the background'...but only to 1 second resolution. Is that sufficient granularity?
- I know nothing about RFID detectors so can't help on that part.
The biggest problem is designing to not 'lose' any RFID. What would happen if you did lose one, ie what is the application? If it was safety-critical, financially-critical or 'production-line'-critical, then you would find a PICAXE solution relying on 200mS being available for every RFID all day every day probably totally inadequate...you would need most likely need some transactionally secured shared buffer/cache meory that the RFID wites into and the PICAXE reads from - so that you could survive comms problems (the most likely gotcha) to the PC for a period of time.
Edited by - MartinM57 on 6/11/2005 7:01:08 PM
Some random design thoughts:
- you are building a real-time system, so a sound design is an absolute must
- you have up to 200mS to deal with each 'RFID' so you'll be able to run a reasonable number of lines of code plus a 'sertxd' at 19200 baud to the PC
- if you need comms from the PC to the PICAXE, then that's much more difficult to sort out, Even impossible perhaps, since the PICAXE has to wait for a serial 'in' transmission and can't be doing anything else at the time
- using a DS1307 to timestamp should be fine. Use the 0.5 second SQW output as an interrupt to the PICAXE. Use Hippy's XOR masking trick (search to find it) to only process every other interrupt so that once per second you read the 1307 and put the time in the PICAXE
RAM. Then when you want to timestamp, just use the values in RAM - the interrupt will keep them updated 'in the background'...but only to 1 second resolution. Is that sufficient granularity?
- I know nothing about RFID detectors so can't help on that part.
The biggest problem is designing to not 'lose' any RFID. What would happen if you did lose one, ie what is the application? If it was safety-critical, financially-critical or 'production-line'-critical, then you would find a PICAXE solution relying on 200mS being available for every RFID all day every day probably totally inadequate...you would need most likely need some transactionally secured shared buffer/cache meory that the RFID wites into and the PICAXE reads from - so that you could survive comms problems (the most likely gotcha) to the PC for a period of time.
Edited by - MartinM57 on 6/11/2005 7:01:08 PM
Thanks both for all the help. The application is race timing so is not any of the criticals you mention just annoying for the runners that get missed with no easy way of finding where they were.
The one second update sounds like an excellent idea as we currently only work to a second for the distance events anyway.
The races I am doing it for are around 500 runners (except for the charity marathon which should have just over 1,000) so perhaps I could handle a loss of comms by dumping the tag and time stamp in a buffer large enough to take all the data just in case comms isn't restored. We wouldn't get real time results but at least we could sort it out later.
The PC doesn't need to talk to the PICAXE so nothing to deal with there. Perhaps I am "lowering the bar" a bit but am more hopefull of a PICAXE solution now.
The one second update sounds like an excellent idea as we currently only work to a second for the distance events anyway.
The races I am doing it for are around 500 runners (except for the charity marathon which should have just over 1,000) so perhaps I could handle a loss of comms by dumping the tag and time stamp in a buffer large enough to take all the data just in case comms isn't restored. We wouldn't get real time results but at least we could sort it out later.
The PC doesn't need to talk to the PICAXE so nothing to deal with there. Perhaps I am "lowering the bar" a bit but am more hopefull of a PICAXE solution now.
<<so perhaps I could handle a loss of comms by dumping the tag and time stamp in a buffer large enough to take all the data just in case comms isn't restored.>>
That's an interesting piece of design to be done!
If you use 'sertxd' to send data to the PC (as I do in on of my apps to send non-critical status data to a PC, if it happens to be there), it doesn't matter if the PC is connected or not.
In fact the PICAXE can't tell (as far as I know) if there is a PC there or not. So how do you know when to buffer?
Maybe you could buffer all the time (to what? - need to think about that. i2c EEPROM maybe?) and do a 'sertxd' as well. Then you need some reconciliation/buffer processing to sort it out later if the comms has gone wrong (or you think it might have gone wrong!).
If I was a runner and the system messed up my finish time I might not be too pleased ;-)
As I said, I think you're in with a chance, but it won't be easy to make a fault-tolerant solution
Edited by - MartinM57 on 6/11/2005 9:27:46 PM
That's an interesting piece of design to be done!
If you use 'sertxd' to send data to the PC (as I do in on of my apps to send non-critical status data to a PC, if it happens to be there), it doesn't matter if the PC is connected or not.
In fact the PICAXE can't tell (as far as I know) if there is a PC there or not. So how do you know when to buffer?
Maybe you could buffer all the time (to what? - need to think about that. i2c EEPROM maybe?) and do a 'sertxd' as well. Then you need some reconciliation/buffer processing to sort it out later if the comms has gone wrong (or you think it might have gone wrong!).
If I was a runner and the system messed up my finish time I might not be too pleased ;-)
As I said, I think you're in with a chance, but it won't be easy to make a fault-tolerant solution
Edited by - MartinM57 on 6/11/2005 9:27:46 PM
hippy
Ex-Staff (retired)
An intersting application. Presumably there's already a manual mechanism for determining official results and times, so I'd still be tempted to go for a purely Windows software solution and see if it works.
If there were problems with Windows going off 'to do its own thing', I'd then look at using a PC running MS-DOS so the software had the PC to itself when running.
I'm still sceptical about a PICAXE solution, but it's your baby and your choice. I would be interested in hearing how you get on, and would be delighted if you prove my scepticism unfounded.
If there were problems with Windows going off 'to do its own thing', I'd then look at using a PC running MS-DOS so the software had the PC to itself when running.
I'm still sceptical about a PICAXE solution, but it's your baby and your choice. I would be interested in hearing how you get on, and would be delighted if you prove my scepticism unfounded.