That's more or less what I'm beginning to think, the Arduino might not be quite enough for this project.
I've done some basic calculations to determine how big the "temporary" buffer in RAM would need to be like so:
((9bytes per message)1000messages per second60seconds in a minute20 minutes of logging)/(10241024) = about 15 megabytes of temporary data that need to be written after a race.
This seems to be significantly outside of the range of expandable SRAM chips that can be addressed, is this a reasonable assumption? Or am I missing something?
You mentioned ArduLog, I have never heard of it until now but I suppose it seems reasonable; I'm not a great programmer and would prefer to take the hardware option as much as possible. I'm just curious how this avoids that same problem I'm dealing with now, does the ArduLog have it's own buffer; how does it not have the same long write issues I'm having now?
nr1224:
I've done some basic calculations to determine how big the "temporary" buffer in RAM would need to be like so:
((9bytes per message)1000messages per second60seconds in a minute20 minutes of logging)/(10241024) = about 15 megabytes of temporary data that need to be written after a race.
This seems to be significantly outside of the range of expandable SRAM chips that can be addressed, is this a reasonable assumption? Or am I missing something?
Yes, I'd say that's a bit outside the range of expandable RAM, or at least economically.
Another approach might be to come up with a more compact storage methodology. Your messages are 9 bytes long. Are there any parts of the message that are unmportant? By that, I mean that, supposing you have a message containing RPM. Could you store that as a 2 byte value (0-65535 RPM), plus a single byte message type identifier? Another possibility, again with RPM, is if the RPM could be to the nearest hundred RPM, you could store 0 to 25,500 RPM in 100 RPM increments, and along with the message identifier, that would take 2 bytes per entry.
You might also want to look at how many packet types you are interested in. If that number is anywhere up to 16, your could use a single byte to identify the next two messages, using high byte/low byte values.
How about keeping track of the last values for each message type. If you get a duplicate (RPM has not changed, EGT is the same, etc.), there is no need to store it.
Just some brainstorming here. Perhaps it will trigger some ideas on your part.
Sorry I let this sit for a while, I was out of town.
I've been working on filtering out some blank messages, but because we use a certain software tool to actually graph and analyze the recorded CAN data, they're expecting it in a certain format. I've been trying to see what I can do to speed some processes up as far as data grabbing goes.
I already watch for repeat packages, I don't know how effectively though.
I've attached a sample data gathering file if you are interested.
Does anyone have any experience of strong opinions about either option? I have no idea how "good" the adapter option is, but I'd really prefer to stay in an Arduino environment than start over from scratch!
As an update, I'm moving to the RasPi, and not using the bridge converter shield.
I've also attached my more or less final arduino code; it's functional if not complete, and might end up being used if I end up being really bad at figuring out the Raspi.