Just a quick update on the Pit-Entry limitations I warned about in my previous update.
I’ve been emailing a support guy at Phidgets in Canada, who has been very helpful. He came up with a couple of IR sensor config options for me to try on their faster 8/8/8 card. I couldn’t get this card to work in previous attempts so went back to their 0/16/16 card and decided to live with that card’s shortcomings.
The first and easiest option he proposed worked amazingly well. A few of us will do some comprehensive testing on Saturday. But in my testing today, it seemed to detect every pit entry I could throw at it. And, to my surprise, it detected six cars entering the pits simultaneously. That indicates that the 8/8/8 card might just work for now on SR3–the 0/16/16 card had trouble detecting three simultaneous pit entries.
Anyway, time will tell, but it does appear that the pit-entry speed limitations on SR3 are removed, which is a good thing. No idea if it’ll support any conceivable “Hail Mary” drop into the pits, but I couldn’t perform an entry that it did not detect.
So, never mind my earlier update post. SR3 pit-entry speed limitations appear to be resolved.
Stewart Raceway is back in business. I’d like to get at least six drivers over for a track day either Saturday, May 14, 2022 or Saturday, May 21, 2022.
We need to run the new track through the paces and make sure everything works as expected, barriers are solid and in the proper places, and no gremlins exist. The first track day will be on the road course. You’ll want to make this track day or the very next to get used to the different pit-entry style on SR3. I also want to run a 25-30 lap race on SR2 to make sure the intermittent pit entry miss is resolved there.
Hopefully, we can get enough guys over on the 7th to flush out the road course. If so, we’ll do the same thing the following Saturday to flush out the oval course. The first “official” race of our next series is slated for Saturday, May 28, 2022. Details to follow soon…
While I was consumed with trying to deal with Phidget problems on SR3, I was also working with Dave Aufderheide, the developer of Race Coordinator (RC), to support power-cycling when out of fuel.
RC always supported fuel racing but it just quit counting laps when you ran out of fuel. It has audio to inform you you’re low or out of fuel but it did not “stutter” power to make it painfully obvious you were out of fuel.
In the midst of working with SlotTrak to resolve the SR3 pit-entry detection issues, I also reapproached Dave at RC to support the power “stuttering” feature exclusive to SlotTrak fame. If RC could support that feature, it would certainly make RC a comparable alternative to SlotTrak, which appeared to have serious issues with fuel racing on SR3 at the time.
Dave is a remarkable and clever guy and one who seems to enjoy solving complex technical problems…if he has the time among being a husband, father, and very busy professional software developer. I first approached Dave on this feature several years ago but he felt that I was the only one out there requesting it and didn’t give it too much thought back then.
A few years–and a little spare time–later, he came up with a possible way to do it. RC has a mechanism called “Extended Protocol” that allows technical track owners to add custom features to RC largely independent of the actual RMS system. These features actually run on a Arduino microcontroller in a software environment called a “Sketch.” This is a C++-based programming environment that allows you to write code that interacts with RC to accomplish some purpose like controlling LED’s, lights, lane switching, audio, whatever you can think of that RC may not do but the independent Sketch can.
In this case, Dave determined that the Arduino Sketch could actually “stutter” or cycle individual lane relay power independently without having to change the code in RC. This, of course, is very desirable to a developer since he doesn’t have to change the main program and then support the new features into perpetuity.
So, after just a couple of weeks of finding time to test and write code, and retest, Dave came up with a Sketch that does the job quite nicely. All you have to do is “tweak” the Sketch code to communicate with your track hardware, configure the “stuttering” pattern, upload it to the Arduino, and bingo! When a car runs out of fuel, the relay simulates an out-of-fuel situation just like SlotTrak.
“So what,” you say? Well, there are only two systems out there that support this feature: SlotTrak and now Race Coordinator. I’m very pleased and glad I have an alternative to SlotTrak in this regard.
We haven’t used RC much over the last couple of years for serious racing. Mainly because SlotTrak’s fuel features had the “stuttering” capability and most drivers prefer that over the–not always reliable–audio alert when running out of fuel. Now we have two options. Both systems have their strong points, different features, functions, etc. RC is a very customizable RMS, whereas SlotTrak is pretty much a closed system with relatively little customization possible by the user.
I love them both. But I sure wish they both supported the same hardware, which is frustrating, but they are exceptional RMS solutions that have unique features which make it difficult to always run one over the other.
After walking away for a while from the challenge of getting SR3 operational, I came to the realization that it always was “operational.”
The bottom line is SR3 works and will be available for racing soon. Stay tuned for details on the next series at Stewart Raceway.
Read on for details. Otherwise, I hope to see you racing on SR3 soon…
To recap, the problem I was trying to solve was related just to fuel racing, which most of us prefer to old-school traditional slot racing. Yes, the track worked fine in all aspects except fuel racing.
So, I spent as much time as I could over a roughly 60-day period trying to solve the problem. Again, the hardware options for a six-lane, dual gantry track are very limited. Dual gantries for pit stops are the most desirable solution because just using a single lap count sensor setup is very difficult for most drivers to reliably and quickly trigger a pit entry and refuel.
So, I tried everything to resolve the technical shortcomings of Phidget cards, which are currently the only way to support dual gantries on a six-lane track using SlotTrak as the race management system. I even took a tremendous amount of time writing code for an Arduino microcontroller to capture the pit entry signals and pass them to the much slower Phidget card. This actually worked beautifully but the Phidget and Elexol relay cards that SlotTrak support generate too much EMI noise and interfered with the very sensitive Arduino card. A real bummer since that approach was the cheapest and most flexible solution to this type of problem.
So then I moved on to the Medanic Solution. Actually, Steve Medanic, the accomplished racer and controller genius, came up with a hardware solution for these very problems years ago. Unfortunately, I could not successfully build his circuit design and, after two attempts, called it quits on that option. Yes, Steve proved that it does work but I was unable to get my own circuits to work on my track. Steve is awesome when it comes to helping out but he was off traveling in Europe and obviously unable to help me resolve the build problems.
So I then moved on to the next possible solution which was a different and faster Phidget card. The 8/8/8 Phidget card has a much quicker Low Voltage Trigger time (4ms vs the 0/16/16’s 16ms). So the theory was that it might just catch the faster speeds that SR3 presents for pit entries. Unfortunately, the 8/8/8 card wasn’t a simple swap with the 0/16/16 card. It’s what is known as an active-low digital signaling device, the opposite of the active-high 0/16/16 card. Sounds simple enough but I could not get the 8/8/8 card to detect my IR sensor’s open logic levels (when a car passes under the gantry, the IR beam is broken and the output goes to zero volts). This was very frustrating but I could not find a way to terminate the sensor outputs that would trigger the 8/8/8 card.
So, all that said. I simply have given up on trying to “fix” the problem. Instead, I’m just going to live with it. In retrospect, it’s actually not really a problem. In full-scale racing, pit entry is always serial and speed regulated. The SR3 problem is related to high-speed pit entry, which is not how full-scale racing works.
In slot car fuel racing, drivers strive to time the fastest possible entry into the pit area. The larger the pit area, the easier that is to accomplish. This works well at Thunder Road Raceway and Stewart Raceway 2. Both tracks utilize a Trackmate SCL3 card for lap and pit entry/exit and generic 4-relay cards for individual power. The SCL3 card is specifically designed for slot car racing and has been refined over the years to the point of near perfection. Consequently, the card captures extremely fast sensor signals and works quite well.
This is not the case with Phidget cards. In fact, without Medanic’s hardware fix, the Phidget card is useless as a lap count detection device and marginally useful as a pit-entry detection device. Yes, it can work on small tracks or where the speeds through the sensors are relatively slow but will not detect a typical pit entry on SR3.
So, what does all this mean to you? Well, the bottom line is that you’ll just have to forgo the slick “quick drop” into the pits on SR3. You’ll have to slow way down prior to passing under the pit entrance gantry to trigger refueling. If you don’t, you’ll have to do another lap and enter again at the proper speed. Again, this is how full-scale racing works and, in my opinion, isn’t really a problem that should prevent us from enjoying fuel racing on SR3. Yea, it’ll be different than most tracks, including SR2. But it’s really just a characteristic of a new track right now.
Yes, I suspect this issue will be resolved at some point by new hardware, Medanic’s solution, or even the Arduino hardware/software solution. The reality is that I just don’t have any more time to spend on those possibilities and I want to get back to racing on both tracks–ASAP.
Well, sometimes you just have to throw in the towel and move on to other things…
After figuring out a way to help Phidget cards detect fast cars breaking IR beams using an Arduino microcontroller, I discovered that Phidget cards are also terrible at suppressing EMI spikes.
Seems the Phidget 0/0/4 relay cards that SlotTrak supports for individual lane power are horribly noisy when they all switch on or off at the same time. This issue is exacerbated when you multiply things by six (6-lanes).
Yes, so after hours and hours of hacking software to get the 0/16/16 card, used for Pit-Out (in this case) to detect fast cars, I discover that the 0/0/4 relay EMI pulses cause false triggers on the Arduino card the software is running on. Basically, when one or more cars run out of fuel and begin pulsing the relays, the Arduino card either triggers the Pit-Out sensors when you’ve actually stopped in the pits, or it misses the Pit-Out trigger and thinks you are in the pits when you’ve blown through the pits.
So, back to the drawing board on fuel racing for SR3. There are a couple of possible solutions left to try but I’m taking a break to reset, regroup, and reassess things. Oh, and tend to some other stuff that people tell me is more important than slot car racing. Yea, some people are into “other” things it seems.
I know a few guys are anxious to get back to racing again regularly, sorry for interrupting the momentum we had going there. Unfortunately, SR2 also had problems with intermittent missed pit entries, which is very frustrating and has cost several of us dearly. I don’t want to continue racing until I’m confident that the problem is behind us. I’ve upgraded the track’s Trackmate SCL3 card’s firmware and gone to the latest SlotTrak version, which seems to have resolved this problem (in my testing anyway).
In other news, SlotTrak has indicated that they “may” introduce some new hardware in future releases of their software soon. From what I know, the new hardware is cheaper, faster, and is expected to solve some of these crazy Phidget issues I’m experiencing on SR3.
So, for now, I’ll take a little break and get away from this problem for a spell and hope SlotTrak can integrate and test the new hardware and software quickly. In the meantime, I’ll try a couple more things with what I have to work with and see where that goes.
If all the above fails, there is one more possibility: Race Coordinator (RC) and I have been working on some mods to that RMS to support “out of fuel” power pulsing, which SlotTrak does very well. Dave at RC is doing this out of the kindness of his heart and with any spare time he may have. It’s not a trivial project but we’ve made some progress that looks promising. SlotTrak is still my preference for race days due to their superior reporting capabilities but if I can’t get fuel racing to work, I’ll switch to whatever system that can support it–with power pulsing.
And now for the good news…
It looks like Sac is heating up as the NorCal hotspot for H.O. Racing. Ted Essy just held his second event in Loomis, at Thunder Road Raceway, that single event attracted 16 drivers!