Author: Race Director

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.

Okay, shut up and drive!

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!

Okay, shut up and drive!

I only received one response for an SR3 test session on the 30th and that one was a no-show. So, the April 30th track day is hereby canceled.

Racing will resume at Stewart Raceway as soon as possible after I can get enough drivers together to thoroughly test the new track.

SR2 has undergone a Trackmate SCL3 firmware upgrade and some rail height issues in the pit area have been corrected. However, it too needs some thorough testing to verify that the annoying Pit-Entry issue has been resolved.

Okay, shut up and drive!

I don’t think I’ve ever dealt with a problem so simple yet so difficult to solve. Last week I had finally gotten the Pit-In gantry to detect the fastest pit entries I could produce. That was cause for celebration, which I did, of course.

Right after my celebration, I simulated a race situation and discovered that SlotTrak was not counting the lap after a refuel. Apparently, the configuration I was employing was not adequately tested by SlotTrak.

I reported this issue to Slottrak and they could not duplicate the problem. Not sure why they couldn’t duplicate it but there was clearly no solution coming from SlotTrak to fix things.

So, I then decided to switch the gantry positions (SlotTrak’s suggestion). The normal position is to have the Pit-In gantry positioned ahead of the Pit-Exit/Lap Counting gantry (Start/Finish). This is how SR2 is configured.

It’s not a trivial thing to swap the positions of the gantries but it was worth a try to see if SlotTrak would work at all. Turns out, it did work and did count the lap after a pit stop. Another major celebration!

However, the original Phidget sensor detection problem reared its ugly head yet again. I thought I had this problem solved but because swapping the gantries meant that the speed through the Pit-Out gantry was a whole lot faster, the setup I had developed no longer worked.

It’s complicated but essentially, if you weren’t pitting and blazed through the two gantries, the pit exit was not detected by the slug Phidget card (in spite of my previous hardware and software mods) and SlotTrak would think you had stopped in the pits even though you had no intention of doing so.

At this point, I’m about to abandon slot car racing and move along to shuffleboard and backgammon. But no, I keep at it while my wife is about to commit me for being way too obsessed with toy cars and ignoring all my other interests and responsibilities. Stupid me, I stayed focused on the problem and kept trying everything I could think of to solve it.

I have no idea why SlotTrak ever decided that Phidget cards are useful for anything and SlotTrak does not support using two Trackmate SCL3 cards for fuel management, which would be awesome. Instead, I’m stuck with this incredibly expensive but ridiculously slow Phidget I/O card. I had gotten it to work as a Pit-In gantry but the speeds coming into the pits are much slower than the speed going through the pits. Again, the Pit-exit gantry has to detect a car coming out of the pits as well as a car going through the pits—at a much higher rate of speed.

In the end, I was able to get the Phidget card to detect both Pit-exit and Pit-through at L4 car speeds. This was accomplished with both pull-down resistors on the IR sensors as well as using a much faster Arduino Mega microcontroller card to capture the IR sensor signals and then send them to the Phidget card slow enough for the slug card to detect and report to the SlotTrak software.  Yea, believe it or not, I used a $35 microcontroller card to help a $110 I/O card capture an infrared beam breaking–crazy!

Okay, so my testing shows that my fix works for every scenario except three cars leaving the pits at the same exact time in consecutively numbered lanes. Since I used hardware and software to come up with this solution, I should be able to make it work perfectly but I just don’t think we’ll ever see that particular scenario play out very often, if ever. So, in the interest of staying married to my wonderful wife, I’m done with this project for a while.

I know Ted has a race scheduled at Thunder Road Raceway on April 23.  I’d like to get at least six drivers over the following Saturday (April 30) to test the SR3 road course prior to beginning a new racing series.

Please email me at slotn77@gmail.com and let me know if you can make it. No “official” series racing at Stewart Raceway until the tracks are bulletproof.

FYI: The intermittent Pit-In detection problem with SlotTrak on SR2 is not yet fixed. I’ll work on that problem ASAP but it works flawlessly using an Arduino card and Race Coordinator so it is a Trackmate or SlotTrak issue and probably something I can’t fix.

Okay, shut up and drive!