I have a requirement to capture data (probabaly struct) of up to 100 pairs of:
BoxID (up to 20 characters, this is barcode scanner captured text)
Quantity (int)
using one arduino and make that information available to another arduino, which will be not too far from the first one (up to 4 meters).
My initial plan was using NFC tag to write the data, and extract NFC tag data at another arduino. But from research I've done storage on these tag can be up to 8kb only.
Now I'm thinking of implementing communication between the two using transceivers.
I prefer NFC solution if possible due to other considerations, but it looks like it may not be possible.
My question is:
is 8kb enough to store struct above, or is there any better way to process capturing data in the program other than struct so that achieving efficiency in order to be able to store within less than 8kb memory
BUMPing after 10 hours is unreasonable - people have to sleep. After 48 hours would be OK.
I don't understand how you are thinking of using NFC tags. That sounds like you need something attached to the Arduino that reads the barcodes so it can write the data to the tag and then something attached to the other Arduino so it can read the tag - not to mention the person required to bring the tag from the first Arduino to the second Arduino.
What are the other considerations that attract you to NFC tags - that may influence the advice you get here.
You are describing a data struct with 22 characters. If you repeat that 100 times it amounts to 2200 characters - a lot less than 8k.
yeah sorry about impatience, have looked at it for few days and got frustrated a bit and needed an answer. never really got my head around all bit and bytes, hex, chars and similar concepts more heavily used in C rather than OO languages such as Java. from what I understand char is one byte therefore 20 char string plus 2 bytes for int is 22 you are referring to?
why NFC is because as part of tge process a box that has nfc sticker/card attached to it will move from one arduino to another hence indifference to having nfc. if it wasn't for that using transceivers would have been more elegant solution.
mshukhrat:
why NFC is because as part of tge process a box that has nfc sticker/card attached to it will move from one arduino to another hence indifference to having nfc.
If an NFC tag is already an integral part of the system then using it to carry the data seems sensible.
mshukhrat:
I have a requirement to capture data (probabaly struct) of up to 100 pairs of:
BoxID (up to 20 characters, this is barcode scanner captured text)
Quantity (int)
That's 22 bytes for each data point; 2,200 bytes total. An Uno (ATmega328P processor) has 2048 bytes of RAM available. That sounds like a serious problem to me. As you have only 100 different boxes there should be ample opportunity to reduce that 20 characters to maybe just one (a single byte can store 256 different values). Same for quantity: will that ever be greater than 255? If not, use byte. Then you can bring back your data to just 2 bytes per data point, or 200 bytes total.
using one arduino and make that information available to another arduino, which will be not too far from the first one (up to 4 meters).
String a wire between the two; use Serial communication. Or attach NRF24L10 modules to both and transmit your data wirelessly.
My initial plan was using NFC tag to write the data, and extract NFC tag data at another arduino. But from research I've done storage on these tag can be up to 8kb only.
You plan to manually move the NFC tag from one to the other to transfer the data?
wvmarle:
As you have only 100 different boxes there should be ample opportunity to reduce that 20 characters to maybe just one (a single byte can store 256 different values).
I have been assuming that he wishes to retain the original barcode ID for other purposes.
You plan to manually move the NFC tag from one to the other to transfer the data?
I get the impression from Reply #3 that the NFC tag is already part of the system.
I was reading up on bytes, etc. I can use byte for Q as per item Q will never be more than 100. With regards to boxID, they are just movie barcodes on the back of cases. They look like: "5051892164726" for example or could be mixture of letters and numbers.
What data structure would you recommend for boxID, is "char boxID[]" appropriate?
With regards to NFC, yes NFC sticker will be part of a moving product as mentioned earlier. However, I ran into problem with NFC library not allowing reading the same card continuously so having been thinking using transceivers as this is something I can change in the design. I already ordered these https://www.amazon.co.uk/gp/product/B010N32SGM/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1
I wanted to go into details as I did in my initial ever post but it was commented to be too detailed. hence did not want to bore you with design details.
We don't normally complain about too much detail. Usually it's not enough detail.
Those modules should do just fine for simple wireless point to point communication.
A char array is a good solution for your bar code as it has a mix of numbers and letters - make sure it's long enough to hold the largest such code as you can ever get; if this can be different lengths you need one extra character for the null termination. So for barcodes of up to 20 characters it's
char boxID[21];
It's easiest to use an array of struct as you can then combine it with the quantity:
struct box[50] {
char boxID[21];
byte quantity;
};
[/code[
You still have the problem of very limited memory - just 2048 bytes of RAM on the Arduino, after all the other stuff you need you can store no more than about 50 pairs of boxID and Q: the above struct takes some 1100 bytes of RAM already!
mshukhrat:
However, I ran into problem with NFC library not allowing reading the same card continuously
I have not used NFC tags but I don't understand that statement on two levels.
What do you mean when you say it does not allow a card to be read continuously? What does it allow? Is this a restriction of the library or of the NFC technology?
Box which will have NFC sticker/card embedded onto needs to loaded with CDs, which will be counted using load sensor (1 cd = 16 grams). So when every disc case barcode is scanned CD/CDs in it is/are put into weighs. Quantity of CDs and barcode are saved into data structure. When the whole process finished for all CDs then array of structs is saved to NFC memory card.
so box of CDs is not decoupled until all scanning and weighing are done so NFC should be in contact with RF522 reader throughout this time. The library from miguelbalboa sets card to Halt and Ready states in turn for some reason (this is probably the worst explanation). I did dig further in the library code, and in combination with almost faulty 4k memory card I had received, I decided to explore transceiver option. With my limited knowledge it did look like a library restriction/how it works rather than NFC technology. I may go back and dig a bit further.
On a related note, I came across your comments in on of the topics on compatibility of Arduino MKR1000 with nRF24L01 transceivers, if in the context of this topic I decide to go with transceivers, will I be able to to get the two working do you think? The reason I ask is due to memory restriction on Leonardo as my board to hold an array of structs up to 100 elements, I can use transceivers to pass on structs as they are created and pass on a task of creating array of structs to a more powerful Arduino MKR1000.
mshukhrat:
On a related note, I came across your comments in on of the topics on compatibility of Arduino MKR1000 with nRF24L01 transceivers, if in the context of this topic I decide to go with transceivers, will I be able to to get the two working do you think? The reason I ask is due to memory restriction on Leonardo as my board to hold an array of structs up to 100 elements, I can use transceivers to pass on structs as they are created and pass on a task of creating array of structs to a more powerful Arduino MKR1000.
Sorry, but I can't make sense of that. You need to post a link to my comment and explain why you talk about both MKR1000 and Leonardo.
In general, keep in mind that I don't know what you are thinking.
Sorry it was middle of the night and I wanted to save time (obviously I did not). I'm surprised you even bothered to reply to my garble.
So I have the following newly emerged problems on this particular project:
NFC appears to be out of questions so I need to use transceivers
Master transceiver may end up communicating with 6 slaves, who potentially, though unlikely, can send array of up to 100 structs that has (boxID=byte, and char[30] ==> this is revised requirement now), previously was 20 chars)
So Master node should have plenty of RAM just to cater for peak push of data from slaves however unlikely it may be.
correct me if I'm wrong, I make a memory requirement of 6 X (100 X 32 bytes) = 19,200 bytes or 19KB?
mshukhrat:
So I have the following newly emerged problems on this particular project:
NFC appears to be out of questions so I need to use transceivers
I have seen no evidence of that, although the solution might be a little more complex than was first thought. However it is your decision.
Master transceiver may end up communicating with 6 slaves, who potentially, though unlikely, can send array of up to 100 structs that has (boxID=byte, and char[30] ==> this is revised requirement now), previously was 20 chars)
So Master node should have plenty of RAM just to cater for peak push of data from slaves however unlikely it may be.
correct me if I'm wrong, I make a memory requirement of 6 X (100 X 32 bytes) = 19,200 bytes or 19KB?
The only boards that have that kind of memory are:
You need to study the problem in more detail before dismissing an Uno (or, say a Mega with 8k of SRAM) coupled to an SD card.
Of course the other option is to use a RaspberryPi or a cheap laptop as the master (which is probably what I would do).
If this is a project to be used in a work environment where its failure would be inconvenient and perhaps expensive in terms of lost data or lost time then you should put a great deal of effort into making sure everything (software and hardware) is easily understood by someone else who could maintain and repair it if you are not available.
That may mean that the desirable solution is not the cheapest.
Or use an ESP8266.
More than enough memory (some 48 kB RAM), built-in WiFi for communication (a few of them can form their own network - just put the master in "host" mode and have the slaves connect to it), and you can use the built-in flash (3 MB of it, leaving 1 MB for the sketch) as external memory.
Cheaper than Arduino + SD card + networking kit (cost is about the same as an Arduino clone - the NodeMCU development board is going for <USD3 a piece).