Will GP Software communicate with an Arduino?

[fidoracing]

With the newer versions of GPRM, the Arduino and the GPRM software will sometimes butt heads if they are not "synced" properly. (By "synced", I mean at the same point in the race) I've noticed that there is a very specific order things have to be done initially to get them to play nice now, or they get out of sync with each other and they don't work properly.

The first thing I do when I set my track up is to plug it in electrically, reset the track, then start a race and finish it manually (trip all of your lane sensors). Then start the GPRM software, and then plug the USB cable in. Then I will go into the hardware test function of the GPRM, and run a test race, resetting the track with the test software. Run another manual race, and if everything works at that point, we are usually good.

Also, leave the track in the post race, but not yet reset mode when you start the racing in the GPRM software. I've had problems with that this year also.

I'm not sure why these issues appeared with the newer GPRM versions, but I didn't notice them when I first developed the timer. Not sure if its a software issue, or if I just got lucky initially and didn't notice it.

One last tip - make sure your driver for the serial conversion chip on the Arduino matches your Arduino. The drivers are not all the same, and no all the same for the various OS. You said you are getting info, so you should be ok, but if all else fails it might be worth a check.

[gpraceman]

GPRM V11 did have some interface changes. With any custom timer, it is best now to have the timer send a response to any command that it receives from GPRM. This can be a simple CRLF, but can really be anything you like. Having the responses will reduce any lag time within GPRM, as it goes about interfacing with the timer.

You might want to check out Indy's firmware. He's already made adjustments for that change. http://www.derbytalk.com/viewtopic.php?p=61706#p61706

If you are having any specific issues with the newer GPRM interface, you can email me your HardwareDebug.log file and I can take a look at it.

Also, leave the track in the post race, but not yet reset mode when you start the racing in the GPRM software. I've had problems with that this year also.

Not sure what you mean by this.

[CaveGimp]

Thanks for the help guys. I ended up going back to the v10 GPRM and once I got everything hooked up the race ran fine. I did find some issues even talking nice with v12 so I will have to take a look at the firmware update you mentioned.

Fido, I hear you on having a specific sequence for setting things up. Even my display boards sometimes won't work right unless a specific sequence is followed. Thanks for the tips.

Everyone loved the sounds from RaceFX so that was a bit hit. I will have to check out Indy's latest firmware and see if it helps. Again, thank you all.

[fidoracing]

Glad you got it to work, and were able to perform your Derby. That is, after all, the whole point!

I used the v10 software this year too. I saw the upgrade, but there are always issues with the upgrades and just didn't have time to work the bugs out this year. I'll do it in my "spare time", so god only knows when that will happen. For now I'll keep v10 on the laptop in case I don't have time to look at it. I'll post the new code if I do.

"Leave the track in post race but not yet reset...." - Once the race is over, and all of the lane sensors have been tripped, the track waits for the reset command from the track. If you leave it in this state, (race over, but not yet reset), when you start the actual racing part of the program, and then reset or "ready" the track with the software, the two seem to "get on the same page" easier and you can avoid issues.

[gpraceman]

"Leave the track in post race but not yet reset...." - Once the race is over, and all of the lane sensors have been tripped, the track waits for the reset command from the track. If you leave it in this state, (race over, but not yet reset), when you start the actual racing part of the program, and then reset or "ready" the track with the software, the two seem to "get on the same page" easier and you can avoid issues.

I would look at your firmware. When you click on the Ready Timer button, the sequence that follows is what should get both on the same page. That should complete with the software ready to receive times and the timer ready to start timing.

[fidoracing]

I've tried fixing this issue a few times in the past, and it just doesn't seem to get better. If one gets a step ahead or behind, neither can compensate for the other. I don't know if there is a disconnect between what the track needs, and what the software needs to get on the same page, but its been an issue since the timer was built. The arduino timer was built to take commands from the GPRM software, and then react based on thos commands. I'm not sure what I can do to the firmware on the timer end to work around this, any advice would be helpful.

If you just do it in order, it works. I'll play with it when I get time, but you know how that goes. Between me not having time to play with it, and the subtle differences with the software versions, its hard for me to devote enough time every year to keep up. If anyone has a work around for this, I'm listneing, but for for now, we can work around it using those steps.

[gpraceman]

I'm not sure what I can do to the firmware on the timer end to work around this, any advice would be helpful.

Have you checked out Indy's firmware to see if that will resolve the problem?

[fidoracing]

I have looked at his program, and although they do operate in a similar fashion logically, his is quite a bit different from mine.

Also, like I said, I'm not sure what the communication issue really is between the two, so I'm not even real sure what I should be looking for.

At this point, all I know is if they get off the same step, the only fix is to reset the track and start over.

[gpraceman]

I have looked at his program, and although they do operate in a similar fashion logically, his is quite a bit different from mine.

Well, you could always give his a try and see if that resolves the problem.

[fidoracing]

Like I said, although similar logically, they are quite a bit different. I would have to change a lot in his program to make it work with mine, or change my hardware. At this point, it works fine, just as long as you follow the correct steps to get them on the same page. Lots of other things need my attention at this point.

[gpraceman]

Like I said, although similar logically, they are quite a bit different. I would have to change a lot in his program to make it work with mine, or change my hardware. At this point, it works fine, just as long as you follow the correct steps to get them on the same page. Lots of other things need my attention at this point.

Well, I assume that you have a subroutine for processing commands coming from the computer. I would at least recommend adding an acknowledgement response for each command. Some parrot back the command that was received. Indy sends back a ".". The acknowledgement can really be anything that you like. I would also recommend putting in a response for a command that the timer did not understand, like a "?".

Having these acknowledgements reduces the lag time in GPRM when it sends commands, but it is also a useful troubleshooting tool when looking at the communications log file. The serial interface is a dance between the timer and the computer. You can see better when things get out of step if you can see those dance steps in the log.