Guys,
Thanks for all the replies. It shows you have had a good think about it for me, and thats appreciated! You have also come up with a number of the options I considered too, which shows Im probably on the right track.
Just as a side note, Im very new to all this microprocessor stuff (probably shows 
) but my old man was into HAM radio so I have a little bit of electronics understanding, plus lots of background in perl coding (plus dribs/drabs of other languages like ObjC+Cocoa and Java).
MrOmani - Ive spotted that blog entry previously (Ive spent a number of weeks researching prior to making this post). It looks useful, but not to the level of what I need to achieve. I did have a think about only updating the laptimes at the end, but we need real-time (or near) in some situations such as qualifying (laptimes are called to drivers on each lap). But potentially I COULD cater for that with a LCD screen.
Ideally though, I really want the data in the computer ASAP
Any thoughts regards Uno versus Mega (I'll get 'proper' Arduinos) as Id like to order today if possible so can play on weekend
My thoughts;
- For that serial comms format, Id be thinking something like;
sLane(int);lap(int);time(long)e as I need to cater for a laptime longer than 65550 millis (max for int). eg s1;25;123500s
By my calcs, that will typically be around 13 bytes of ascii, and thats more than 1ms of serial transfer time at 57600 (or is there a serial send buffer as well which I could fill more quickly ??)
If im using arrays of longs to store laptimes, then 2k on the UNO is only going to give me a max of 512 laps (eg ~125 laps per lane) and thats not enough to cater for some races.
(I also looked into using microsd cards, but it looks like they have horriffic latency for file writes).
I'll talk about the various use-cases a little later to provide some more background, but some of the race types we have to deal with are enduros, which typically are 12 hours, and have a time between lane-changes of 1 or 2 hours. We typically do up to 800 laps per hour, per lane, in an enduro, so I dont think even the Mega will have sufficient RAM to cope with storing all the laptimes until the end of the race.
- ISRs or tight loop?
If ISR's, then the only way I could see an UNO doing this is to have ALL the lanes fire the same ISR (or 2 lanes per ISR) and then poll the state of all the lane inputs in the ISR (which I understand is quite a slow process). UNO has 2 external ISR's, Mega has 6.
Korman. Thanks for all your thoughts.
I had a rat around under the track last night, and its looking better and better. The guy who did the last setup has helpfully used DB25's for connecting the lanes to the circuitry, and then has an output for a blinky light box, as well as the keyboard. What that means is that I should be able to run my system in tandem with the current system during testing (and use it to do initial data captures for testing under race conditions), and those are all connected up with DB9s 
Additionally, it looks like they have already done a hardware based de-bounce circuit as theres a board with some caps + resisters and 555 chips plus another chip which I forget the number of.
That board then feeds into another board which feeds the keyboard (presumably does the logic to provide correct voltage / phasing to the keyboard switches).
So yeah, all looking promising on the hardware side, I should be able to make up my own input circuitry for testing (which is what I had intended), and swap and match bits to suit AND test alongside the production system