Jump to content

Race Coordinator

Members
  • Content Count

    327
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Race Coordinator

  1. That doesn't sound right unless they both share the same shortcut. Feel free to email me the xaml and I'll take a look at it. Although you get no guarantees as to what shortcuts I take and which I keep if you send it to me (:
  2. If you need help running it down let me know. It should be really easy to find.
  3. That's an error in some of the custom xamls out there. It means you have two shortcut keys assigned to CTRL-1. If you search the file for CTRL-1 you should find both and you can decided to delete one or both to fix the problem.
  4. Hey guys, haven't been on Auslot in a long time... but was looking over some of the more interesting posts. RC now supports segment timing via the arduino track interface. You need a custom UI to display them, but otherwise you can set them up and RC will display/export them to xls. Also, there's a new app called "Drag Race Coordinator" that is exactly what it sounds like. If you're into drag racing you should check the alpha version of it out.
  5. The "Invert Relay" checkbox switches RC between expecting NO and NC relays. I don't remember which way it defaults, but if your power is the opposite of what it should be during a race, then that's the box to use. As said, just change it from checked to unchecked or vice versa (all depending on how its set when you enter). And after you change it, as mentioned make sure to hit "update" to save your setting. For what its worth the config screen is only useful in figuring out if the relays are working. There's no way to tell if the check Invert Relay checkbox is set correctly or not until you actually run a race.
  6. Actually if you delete the rc.db file it will wipe out all your configurations (drivers, races, track and all). I don't think RC will recreate it, I think you'd have to create everything from scratch. If you go that route and want a "reset to factory" you can delete the rc.db file (and all the files/folders in the directory it is in, and then run the installer again. That will reset things. I much simpler/safer thing to do is run the Expert Guided Race Setup. It'll start asking you questions, when you get to heat rotations select Practice. It'll take all of about 2 minutes and maybe 5 questions to get it done.
  7. This crash is now fixed. I just haven't released a patch for it. For now, simply remove the extra pin configurations and you'll be fine. ***NOTE: even after I post the fix, you really should only configure pins that are connected to the arduino. Bad things can happen if you configure random pins that aren't wired to anything.
  8. Just a heads up but be careful with the group options. The group leader board will show the individual group rankings, but the main leader board will show the overall standings. The overall standings always includes N number of drivers from each group at the top. That may or may not be what you're looking for...
  9. Definitely post this on the other thread. But what I'll say is that although your race format and conditions can guarantee all drivers in a heat will be on their last heat at the same time, not all configurations will. That makes this situation a very special case. One of the hardest things to deal with in RC is how to add a feature that works with any/all race setups. Not just a single one in particular. If tons of people say they race this way, then even a specialized feature like this one can be considered would be worth doing, otherwise it poses a lot of problems. I'm not saying no, but I'm saying it'll take a lot of thought/consideration and off the top of my head it isn't likely.
  10. V8, Did you post to the "RC 2.0 Feature Requests" topic on SF? I don't want to link it here because that just doesn't seem right. But you should post your requests there so they're properly tracked. #1 is a very good idea as an option. Not sure how many people would want it, but it seems like a fair thing to do to me... #2 is harder. I'm not sure RC can figure out where a car is when a heat ends and the car doesn't go over the finish line one last time. In the example you give it makes total sense to allow the last heat a driver is in to force this situation, however what happens in the other cases where one driver is on their last lap but one or more other drivers on the track are not... now you have a big mess. Right now the idea is basically for the Race Director to manually add in the lap sections. For what its worth, there's also a suggestion to somehow display the drivers previous lap sections so placing a driver back onto the track where they left off would be easier to do. If you run all of a drivers heats one after another this isn't too big a deal, but if you don't it would be a huge help.
  11. If it's analog and it has its own base and therefore protocol then RC probably doesn't support it.
  12. I've never actually seen the SSD power base I support so somebody else will have to tell you if that's it. Sorry.
  13. Is that the "SSD" power base? If so, I have an RMS called RCD written specifically for SSD. In fact we're in development now on a new beta release. Just trying to iron out a few issues then start adding new features in. Give it a shot and let me know if you have any suggestions/issues. -Dave
  14. My brain is officially blown. But I say whatever works works... I think as many users will have problems modifying the sketch as building the circuit you have. Whichever is easiest is the way people should do it... I'll have to find time and double check that the arduino interface is working the way its supposed to with the bi-colored LEDs. I'm not sure if it is or not based on your description. In theory you can do basically any LED work you can dream up inside the sketch. I provide race state information you can key off of that includes the countdown tree as well as things like yellow flags and the like. If its not in there, the intent was to add to the extended interface as users needed features. I know one user uses it to trigger a pin high for 5 seconds when the heat ends. That triggers some flag thing on his track that signals the end of the heat... Anyway, like I said, whatever is best for each user... And you're right, doing things like that in a circuit prevents you from dealing with sketch upgrades. Although if you make the sketch changes "right" it should be easy to merge any new sketch I provide with your changes...
  15. You guys know that with bi-color (red/green) LEDs the arduino supports driving red/green/yellow colors on the start tree. All you have to do is have the bi-colored LEDs and configure it. I can't remember anymore what the circuit you did is buying you. Maybe you're doing something beyond what I support... There is also extended data in the arduino sketch that is unused. But if you use it, in general you can do whatever you want with LEDs coming on/off, blinking, etc. You just have to modify the sketch to do whatever it is you want.
  16. That's a VERY dangerous thing to do. They'll both use the same database and RC doesn't work if you update to a new version then downgrade that version. That is, if you downgrade, there's a very good chance you'll corrupt the database, so if/when you do eventually update you could be totally hosed. It's not 100% assured anything bad will happen, but if it does, odds are you'll only know it once you update versions. And the damage will almost certainly not be fixable by me or anybody else which means you'll have to wipe everything out to get back to a stable situation. If you want to go between versions, you can backup the database folder so you have a copy for the old version and a copy for the new version. But then any races run while you use both versions will only be saved in one or the other databases... Generally speaking I suggest updating if/when the timing is good and if/when you need something in the build you're updating to. And once you update, I do not recommend going back in any way shape or form, including backing up the database folder (because mistakes can be made). If you update, and there's an issue, I can assure you it'll be addressed as fast as possible. But that could still be days or longer depending on the problem and how well you work with me to resolve it. This simple fact is why I only recommend updating when it's a "good time" to. -Dave
  17. I'm just hoping nobody needs to hard code anything anymore... I'm pretty sure the problem is taken care of. Obviously if things are working then you don't "need" to update to it, however, since its a buffer overrun there's no telling what is actually getting overrun. There may be a looming problem you haven't seen. For that reason alone really anybody with more than 8 inputs or 8 outputs should update to this new sketch, even if you still have to hard code the pinModes (which hopefully you do not). -Dave
  18. <whew>. Thanks Phil. That one was a doozy. It turns out the hard coding you were doing was accidentally fixing the accidental problems caused by the overflow. At least now people don't need to do that non-sense to make it work. -Dave
  19. I just posted a new beta release of RC. It's v1.8.1.8. This beta includes the fix to the buffer overrun in the arduino sketch. I'm going to post more details on that in the official RC sub-forum, but can you guys install this beta and see if the dim LED is fixed once you upload the new sketch (which is 1.0.0.8) to the arduino. I'm really hoping this fixes it... Thanks and let me know -Dave
  20. Nice screen by the way. If you have late joiners coming you might want the "defer heat" option as a button on that screen. That's a new feature in a fairly recent release and it allows you to automatically move the current heat to the end of the heat list in the event a driver is running late and you feel like being nice (:
  21. FYI, I figured out the voltage problem. It's a buffer overflow in the sketch caused by RC sending a lot of pin data configuration. I can't explain why your hardcoding fixes it but the overflow is 100% for sure and when I fixed it my dim leds went away. It would appear the overflow is turning the pullup resistor on for random pins. That would explain everything I've seen and that you guys have reported... The curious thing is that the overflow happens after your fix would kick in so I can't explain how/why it actually works. Lucky I guess. It doesn't look like I can attach the sketch here so I'll pull a new RC release together shortly with it in. If you want it to test sooner than that shoot me an email and I'll mail it out. -Dave
  22. The protocol between RC and the sketch is that RC first sends which pins it wants to read data from (INPUT) pins. RC then sends the pin set it wants to write data to (OUTPUT) pins. The if statement you're looking at figures that out. It also determines if its an analog pin or digital pin and therefore what pin number it needs to set the pin mode on. It's curious but I think the most likely possibility is that when the pins are set to read pins, maybe... not likely, but maybe something is setting the read pin high. according to the link you sent, that would enable the internal pullup resistor. It seems to me though that once the pin is set to OUTPUT that the pullup resistor should be disabled regardless. So I'm still confused. Anyway, if you're curious the RC sketch can be put into debug mode easy enough. You comment in the line at the top that defines WITH_SERIAL_DEBUG. If you upload the sketch with that defined, RC will no longer work but you can then use the serial port monitor that comes with the arduino stuff to send commands to the board. If you want to simulate what RC does you can do the following: ***NOTE: This is all off the top of my head. It's close if not correct. I should have time to fool around tonight ***NOTE: With the SERIAL_DEBUG line defined, you can only set D0 through D9. Basically it only accepts single character pin numbers because the code blindly converts the ascii value to an int with no double digit conversion support. I think this is still enough though. From what I've seen you could set A0 through A5 and then D0 through D9 and see the dim LEDs... Set all the analog pins for input (sensors) PI6A0A1A2A3A4A5; Set all the analog pins for output (leds) PO6A0A1A2A3A4A5; Then you can set the state of the output pins like this Set A0 to high OA01; Set A5 to low OA50 Now, here's what RC will typically do based on your configuration: # configure input pins PI5D4D5D6D7D12; # configure output pins PO9A0A1A2A3A4D8D9D10D11D12; After you do that if you want D8 high you'd do: OD81;
  23. Yeah I don't think the board matters. I've seen it on a real Uno and a real Mega. The funny thing is we've all seen it with nothing plugged into the board. According to the arduino forums that's either a measurement error or damaged pins. Neither is likely considering how many different people have seen the same thing... And I've never plugged anything in but a few LEDs so it's not likely I've fried my boards... Hopefully I'll have time to workup the test sketch tonight. We'll see. -Dave
  24. Okay this is good information. It's still crazy town, but good to know. I'm going to try and break the sketch down to a series of hardcoded read pins then write pins. What I want is the smallest sketch possible that does basically what RC is doing. Hopefully this tiny sketch will show the problem off... We'll see
×
×
  • Create New...