[mINdAt3z]

Hi,

Is there a way to easilly identify an Oxigen car with a sensor on the track, and not wise versa? That the car identifies S/F Line or Pit-Stop?

The background for the questions is to have sensors that take sector times on the track, and from what I have been told, no car ID is actually sent through the LED, but it basically just lights up the LED to trigger the lane change sensors by the logic of "mostly 1:s".

If there is no identification possibilities on the LED, is this in the plans for future releases of the car chip firmware? Or is it simply considered an inpossibility due to the number of possible cars on the track simultaneously and the pulsating of the LEDs?

Regards,
Mikael

 

[MrFlippant]

I believe you can set the car chip to an SSD compatible mode, whereby it emits a signal all the time, changing it for lane changers. Cars programmed to ID 1-6 in this mode will also register on SSD lap counting tracks.

I think the idea is that, eventually, additional magnets could be placed under the track for sector timing. It would be a matter of programming for an RMS such as PC Lap Counter to understand that multiple magnets are parts of the lap rather than the whole lap.

 

[mINdAt3z]

QUOTE (MrFlippant @ 10 Aug 2012, 01:17) <{POST_SNAPBACK}>I believe you can set the car chip to an SSD compatible mode, whereby it emits a signal all the time, changing it for lane changers. Cars programmed to ID 1-6 in this mode will also register on SSD lap counting tracks.

Well, that will probably solve my personal project in the garage. I will probably never race more then 6 cars at the same time out there.

But I asked more out of a developers view. I am putting together an open-source .Net Framework API for common sensortypes, analog/SSD/Oxigen (hopefully Oxigen, it´s ordered but no stock) on my spare time and was wondering if I somehow can combine an optical sensor to identify both SSD and Oxigen cars for section times.

QUOTE (MrFlippant @ 10 Aug 2012, 01:17) <{POST_SNAPBACK}>I think the idea is that, eventually, additional magnets could be placed under the track for sector timing. It would be a matter of programming for an RMS such as PC Lap Counter to understand that multiple magnets are parts of the lap rather than the whole lap.

That´s my current idea now also. But a crashed car not set back on the exact right place can then result in invalid sector times. But once again, we are not sending people to Mars, so a simple "fuzzy" routine that counts backwards and forwards from SF line on each lap and makes a guess on what sector time is missing if any, should do the trick quite well. Maybe tag that lap as "fuzzy" for reference.

 

[RichG]

QUOTE (mINdAt3z @ 10 Aug 2012, 11:58) <{POST_SNAPBACK}>But I asked more out of a developers view. I am putting together an open-source .Net Framework API for common sensortypes, analog/SSD/Oxigen (hopefully Oxigen, it´s ordered but no stock) on my spare time and was wondering if I somehow can combine an optical sensor to identify both SSD and Oxigen cars for section times.
Greg has answered the oXigen question with respect to oXigen running in SSD compatible mode with up to 6 Cars. Beyond that in pure oXigen mode any sector timing would have to come from the magnet based trigger system. This would then require an oXigen dongle on the PC which your API would have to communicate with to get the data.

The problem is that at the moment a single pulse is used for the Start Finish line & a double pulse (Two magnets) for the Pits. So sector timing would need some additional "mechanism" to differentiate the data. (Unfortunately oXigen uses a unidirectional Hall sensor otherwise that would have provided a possible solution) Also a change to the in-car chip & oXigen Dongle firmware would be required to communicate this data.

So bottom line is that I do not think it is possible at the moment, but could possibly be added later? I may however have missed something, perhaps Maurizio would like to comment?

A question for you. As well as working on an API what are you proposing in hardware terms for the ID detection / decode?

Rich

 

[Slot.it]

Hi.
For now the only possibility is SSD mode as suggested. There is another mode in the firmware, but it is a sort of 'Easter Egg', where cars 1-6 send out a continuos unique ID code which does not change with LC request. It has specific applications that will be shown in a few weeks, but the code is only transmitted for cars 1-6.

 

[mINdAt3z]

QUOTE (RichG @ 10 Aug 2012, 14:21) <{POST_SNAPBACK}>The problem is that at the moment a single pulse is used for the Start Finish line & a double pulse (Two magnets) for the Pits. So sector timing would need some additional "mechanism" to differentiate the data. (Unfortunately oXigen uses a unidirectional Hall sensor otherwise that would have provided a possible solution) Also a change to the in-car chip & oXigen Dongle firmware would be required to communicate this data.

Right, I had forgotten that also with the two magnets in the pit-lane. I thought they simply used northpole / southpole.

QUOTE (RichG @ 10 Aug 2012, 14:21) <{POST_SNAPBACK}>So bottom line is that I do not think it is possible at the moment, but could possibly be added later? I may however have missed something, perhaps Maurizio would like to comment?

Darn it, to use a less strong word then I had wished.

There is a huge problem that I myself can´t find a solution to when using sensors in the car and magnets under the track and that is that no matter what, the car can still de-slot and be put back in the wrong place or one single section could be missed resulting in "sliding" section times in the RMS software.

In theory, I think one could place several S/F magnets on the track. Quote from the reference manual...

"The distance between F3 and P1 must be from 5 to 10 cm. Anyway, the car enters in pit-lane if it reads two magnets within 320ms."

So that sure has to be avoided. Otherwise I think one could "trick" Oxigen into putting more magnets on the track. The "Laptime" data sent must be treated as "section time" and the "Lapcount" data sent must be treated as "section count", and on each real lap, the RMS must do the math and put it all together based on knowing how many sections there is on the track.

That logic would work I think. But it still does not solve the problem of sliding sections, since there is no real reference on the track for any given position. I dont see how that problem can be solved without tossing in yet another magnet on the track and change the logic in the firmware. "3 magnets within XXX ms" or going with the Southpole/northpole sensing maybe.

QUOTE (RichG @ 10 Aug 2012, 14:21) <{POST_SNAPBACK}>A question for you. As well as working on an API what are you proposing in hardware terms for the ID detection / decode?

Good eye there on the confusion.

I was trying to be a bit unclear and avoid writing a long post and by doing so I mix up projects a bit.

I have this idea together with a few others to put together an open-source project webpage for software/hardware/hacks related to slot-cars that can be easilly found, followed and forked. The idea just awoke this summer on vacations, so there is not even a conceptual design of what and how, other then trying to make it highly available, open-source and trying to involve a few people to maintain the website, translate (between C#/VB or for that matter MSP430/Arm/PIC or what ever) and explain published projects.

So far the interest seem to be a bit cold and even with the promise that it will indeed be a spare-time project, I have yet not been able to spark enthusiasm with the few people I have talked to. Time is something we all seem to have too little of.

My own project with the open source .Net Framwork API will be released later this year with or without a common project webpage. It will start out slow with some common analog sensors, SSD and Oxigen and then I´ll simply build on it when time and lust comes to me. I will publish that project here on SlotForum most likely. It´s not as exciting as it might sound since it´s basically a low-level protocol API for different types of hardware that presents a common abstract class that can be used for the common basic/similar functions and then a class derived from this one that does the actual work on the different hardwares.

But maybe it inspires someone to more simply learn the protocols, improve my own code, experiment or come up with some fun projects based on it.

With the sensors and my own build of my track, I would have hoped to use the same concept as SSD to actually identify Oxigen cars with the LED, but I sense it might never be possible.

For my own track, I have the hope to replicate the work done by others (http://www.electricimages.co.nz/(S(xjffkzaejqun0ubxiuisib45))/SSD_Decoder.ashx for instance), but in my case I might base the code on a MSP430 instead of a PIC since I have more experience in coding for that MC.

I also have this naive idea that one could possible use an optosensor outside of the IR spectra and in analog slot car racing detect cars by "lack of light", and in digital mode detect cars by IR light (Oxigen/SSD) and as a last function then, identify car ID on SSD by the width of the pulses.

I had hoped that Oxigen did something similar as SSD. But with support for up to... what is it? 48 cars? I imagine it would be a tight squeeze to put in a clear signal identifying the car using pulses.

Electronics is not my strong side, I am more a software person, so I might end up loosing interest and simply scrap the entire idea of home made LC:s and section sensors if I can not simply replicate someone elses work on the hardware and buy something already made like Oxigens LCs.

But it´s more fun to be able to have section times, and it´s also opens up more possibilities to be able to have open source hardware / software to fiddle around with for the home build and build on it and trigger other events and hardware as lights, crossovers, or what not.

 

[mINdAt3z]

QUOTE (Slot.it @ 10 Aug 2012, 16:51) <{POST_SNAPBACK}>Hi.
For now the only possibility is SSD mode as suggested. There is another mode in the firmware, but it is a sort of 'Easter Egg', where cars 1-6 send out a continuos unique ID code which does not change with LC request. It has specific applications that will be shown in a few weeks, but the code is only transmitted for cars 1-6.

Thank you for the reply. Now I got curious... can´t wait to see what this easter egg turns out to be.

I have to stalk your posts more carefully now.

Is it even discussed tho to ever use the LED to signal some type of Oxigen car Id? Or is it simply impossible due to the number of cars Oxigen supports? The code in the firmware to generate a pulse is already there, so it can´t be an impossible task to change it to send out your own protocol. But with the number of cars supported, I imagine the pulse width would be impossible short or at least much more difficult to get a valid fix on for the MC doing the sensing?

 

[Gysse]

Perhaps RFID may be a solution..........- i have absolutely no idea of the econony involved.......

 

[Slot.it]

The problem I see generating 20 different codes is that it would break compatibility with oXigen selective lane changing.
Originally, we actually made our own finish line and we had the cars transmit 20 different frequencies, cars 1-6 having the same freq. as SSD. It wasn't too reliable though as the distance in terms of frequency between two cars was small, and besides, we came out with the magnet solution for lap counting which is really simpler, cheaper and more reliable.
I reckon that the solution lies in analog Hall effect sensor, to discriminate between N and S poles. Currently we have 'on-off' Hall sensor because it is much cheaper, and the car chip is already quite expensive. However, good news is that the IC pin we read the Hall sensor from is (not surprisingly

) an A/D pin whose A/D capabilities we don't currently use. It would be just a matter of firmware change, provided the Hall sensor was switched to an analog type, to read it properly without breaking compatibility with the existing systems. Yes, we did think about this possibility, when we designed the system, even if we couldn't foresee what it would become useful for. Add to this the fact that the future small chip has got the Hall sensor on a socketed wire, and it becomes in theory possible. I currently can't tell how/if we can tell the controller that the last sensor read is a sector time though, as I haven't been thinking about it and don't want to tell you something wrong ... not until next week.

 

[MrFlippant]

Making the chips read polarity, then having the s/f line opposite polarity as sector times (or vice versa ;-), would solve the problem. As soon as a car saw the s/f line magnet, the system could reset any sector timing information it was keeping. That way, each laps starts new, so if any sectors are missed (such as with a deslot-reslot), it wouldn't matter as soon as the car crossed the line again. This specific implementation is one where Scorpius has an upperhand, since every lane changer has a unique ID that can be used for sector timing and reliable lap counting. They have a big drawback for club or commercial size tracks, though, in their limited number of available "lane brain" ID codes for a track.

 

[mINdAt3z]

QUOTE (Slot.it @ 10 Aug 2012, 23:47) <{POST_SNAPBACK}>The problem I see generating 20 different codes is that it would break compatibility with oXigen selective lane changing.
Originally, we actually made our own finish line and we had the cars transmit 20 different frequencies, cars 1-6 having the same freq. as SSD. It wasn't too reliable though as the distance in terms of frequency between two cars was small, and besides, we came out with the magnet solution for lap counting which is really simpler, cheaper and more reliable.
I reckon that the solution lies in analog Hall effect sensor, to discriminate between N and S poles. Currently we have 'on-off' Hall sensor because it is much cheaper, and the car chip is already quite expensive. However, good news is that the IC pin we read the Hall sensor from is (not surprisingly

) an A/D pin whose A/D capabilities we don't currently use. It would be just a matter of firmware change, provided the Hall sensor was switched to an analog type, to read it properly without breaking compatibility with the existing systems. Yes, we did think about this possibility, when we designed the system, even if we couldn't foresee what it would become useful for. Add to this the fact that the future small chip has got the Hall sensor on a socketed wire, and it becomes in theory possible. I currently can't tell how/if we can tell the controller that the last sensor read is a sector time though, as I haven't been thinking about it and don't want to tell you something wrong ... not until next week.

Any additional reference point on the track would solve the problem in my opinion and offer RMS developers a way to do sectional timing. The suggestion I made to use some fuzzy logic in the RMS, forward and backwards from that reference point should produce good enough accurate timing and the reference point offers the RMS the ability to know what a real lap really is. Adding a 3 magnet reading on the track could work. South pole / North pole would work. And the solution that offers the most possibilities in the future would of course be using the LED in some way to signal the identity of the car.

Thank you for clarifying and letting me know a bit on what´s on the Road Map for the future. My own problem with my build is solved and I also know what to aim for when it comes to the .Net Framework API with the Oxigen Support.

 

[Slot.it]

A system that reads polarity, and uses one pole (the one we use now - S ) to trigger a FL, and N to trigger a sector, can be done, but it will increase cost due to the higher price of Hall sensors. Racers wanting sectors will have to switch the sensor to the analog unit. I believe the same car firmware can cope with both sensors.
Pit lane detection will not change, but once a pit lane is detected, then the 'other' polarity magnets may be used for other purpose, like, for example, detecting a refueling bay.
What I really like about the magnet detection idea, be it unipolar or not, is that the cost is negligible compared to the cost of an electronic board, and the same magnets that end up being removed from the cars can be used. Besides, there's no limit to the number of lanes (and adding one lane = one magnet!) , and the detection area is larger than the optical path of a LED.

 

[mINdAt3z]

It´s a good concept. But at the same time, it leaves the logic up to the car and PC (dongle) and any hardware on the track can´t in any possible way determine what car is where. So if you want to add any other triggers, might it be lights triggered for a specific car to do pit-stop or what ever you can imagine. You are screwed.

The sensor in the track knowing what car actually passes it, is still the most "open" and flexible solution.

Does the magnets work. Yep. Are they good enough. Yep. But the LED signalling a car ID and a clear open source protocol to detect it would open up more possibilities.

Implementing a third Point sensor, might it be a northpole/southpole sensor or simply changing the protocol to allow three magnets to be detected to signal a third Point, would open up more possibilities tho.

Looking forward to receiving my Slot.IT Products. The .Net Framework is already done. Just need the hardware to sort it out now.

BTW, thanx for the Lola, gonna paint two of them this weekend.

Regards,
Micke