[Event] Bestmed Tour Of Good Hope

[Guest Lancesball]

Why did they move to the 6th this year?

 

I heard something about the stadium being booked on the 13th, so what happened at the stadium last Sunday?

 

I can't remember the event but something else had been booked on the Cities calendar for that weekend and it wasn't based on the Stadium availability.

The a small event called Epic happened on Sunday so that alone could not have both events on the same weekend/day.

 

Epic had to move a week earlier due to other international events that if was held later the usual Euro Pros wouldn't attend. 

 

Kevin asked Dave to move the Argus and he laughed at Kevin. 

[Guest Lancesball]

The pass is tar road.

thats the one they used

[andydude]

I can't remember the event but something else had been booked on the Cities calendar for that weekend and it wasn't based on the Stadium availability.

The a small event called Epic happened on Sunday so that alone could not have both events on the same weekend/day.

 

Epic had to move a week earlier due to other international events that if was held later the usual Euro Pros wouldn't attend. 

 

Kevin asked Dave to move the Argus and he laughed at Kevin. 

 

But then Dave did move the CTCT a week earlier! So the conspiracy goes it was for Kevin and he just used the other events excuse for the public

 

No special event at the stadium on that original CTCT weekend, although other smaller events around CT like any other weekend.

 

Edit: Used Argus instead of CTCT

[Shebeen]

Kevin asked Dave to move the Argus and he laughed at Kevin.

I saw Kevin doing the argus seemed happy. Saw Dave the next week doing African X,was taking a bit more strain!

[BDF]

thats the one they used

Yip.

[Mobii]

It was not a manual system just a poor electronic one, it users "newer" technology chips than racetec and therefore does not have mats, but if more than 4 people cross the line near each other it does not read the chips. 

 

I have no idea what people were doing with stop watches and paper at one stage. 

 

I also have a feeling it would be a bit of a push for racetec to time a race in the week of the expo registration, but I am sure if ASG wanted to make it happen they would.

Hi Everyone, a bit late to this topic but was asked to take a look here. Our system is absolutely rock solid in reading tags, the hardware is regularly tested internationally to read up to 400 tags per second, so I don't know where these statements are coming from.

 

There is no similar system in action anywhere globally and everything is designed and developed by our team in Cape Town.

 

We are developers of the system and will only be present at events where we train customers how to use our system, from there onwards we have no influence or control over how the event is run.

 

I have actually followed the background to this event and believe me when I say that there were factors outside the control of our timing system that lead to problems at this event. In terms of raw performance, tags were read as designed, but there are other components to making the timing of an event successful apart from the hardware.

 

If you want to understand more about how the system works from a technical point and why this is the future over traditional expensive mats, then here is a video taken from a Road Cycling event that we attended and documented: 

Our system is now actually used internationally in 12 countries representing sports from motor racing to kite surfing.

 

Happy to answer any technical questions you may have.

 

[Patchelicious]

Hi Everyone, a bit late to this topic but was asked to take a look here. Our system is absolutely rock solid in reading tags, the hardware is regularly tested internationally to read up to 400 tags per second, so I don't know where these statements are coming from.

 

There is no similar system in action anywhere globally and everything is designed and developed by our team in Cape Town.

 

We are developers of the system and will only be present at events where we train customers how to use our system, from there onwards we have no influence or control over how the event is run.

 

I have actually followed the background to this event and believe me when I say that there were factors outside the control of our timing system that lead to problems at this event. In terms of raw performance, tags were read as designed, but there are other components to making the timing of an event successful apart from the hardware.

 

Happy to answer any technical questions you may have.

 

I'm sorry but that's not entirely true. There were several tags that were read incorrectly or not at all. I had the raw data and saw this for myself. Several times people on my team as well as other had to have their times verified by video because times were not recorded by device.

 

As mentioned before, this was not that main contributing factor in this mess, but it definitely was one.

 

But this type of post is to be expected, each person points fingers to the other and at the end only we suffer.

[Mobii]

I'm sorry but that's not entirely true. There were several tags that were read incorrectly or not at all. I had the raw data and saw this for myself. Several times people on my team as well as other had to have their times verified by video because times were not recorded by device.

 

As mentioned before, this was not that main contributing factor in this mess, but it definitely was one.

 

But this type of post is to be expected, each person points fingers to the other and at the end only we suffer.

Thanks for the reply, I will explain one of the aspects.

 

On the first days of the event, the pods were not configured correctly for Road Cycling. They were configured to wake the tags and ask them to transmit at 50ms beacon intervals instead of the recommended 10ms intervals when approaching the finish line. This means that as each cyclist approached the finish line, the Pod on the line with the incorrect configuration setting, was not able to produce a result from some tags as we require a minimum of two reads per passing to produce a result. The raw data, when analysed, by our team after the event, showed many tags with individual tag reads for each registered tag per passing which we ignore.

 

Typically we set this at a 10ms minimum level for Cycling and in motor sport where, for example, a Super Bike may travel in excess of 270 km/h, the pods should be configured to wake tags at 1ms intervals when passing over a line.

 

With the incorrect settings applied, some tags where thus not read in the event to produce a result, but individual beacons were. One of our crew attended Stage 4 and configured the pods correctly, having come from the Cape Rouleur in the days before and tags operated as designed, however, with the other factors affecting the timing from the previous days, it is almost impossible to recover at that point so late in the event.

 

There were many other contributing factors at this event, this was one of them.

[GLuvsMtb]

Thanks for the reply, I will explain one of the aspects.

 

On the first days of the event, the pods were not configured correctly for Road Cycling. They were configured to wake the tags and ask them to transmit at 50ms beacon intervals instead of the recommended 10ms intervals when approaching the finish line. This means that as each cyclist approached the finish line, the Pod on the line with the incorrect configuration setting, was not able to produce a result from some tags as we require a minimum of two reads per passing to produce a result. The raw data, when analysed, by our team after the event, showed many tags with individual tag reads for each registered tag per passing which we ignore.

 

Typically we set this at a 10ms minimum level for Cycling and in motor sport where, for example, a Super Bike may travel in excess of 270 km/h, the pods should be configured to wake tags at 1ms intervals when passing over a line.

 

With the incorrect settings applied, some tags where thus not read in the event to produce a result, but individual beacons were. One of our crew attended Stage 4 and configured the pods correctly, having come from the Cape Rouleur in the days before and tags operated as designed, however, with the other factors affecting the timing from the previous days, it is almost impossible to recover at that point so late in the event.

 

There were many other contributing factors at this event, this was one of them.

Its a moot point at this stage. A new timing company has been confirmed for next year and the results are still a f-up. 'Setting the record straight' is not going to change either aspect.

[Mobii]

Its a moot point at this stage. A new timing company has been confirmed for next year and the results are still a f-up. 'Setting the record straight' is not going to change either aspect.

 

My intention with the post is to correct the speculation regarding the performance of the timing hardware. We have no interest in which events or timing partners that make use of our system, our focus is on development and introducing new functionality to the system.

Regardless of which timing system is used, an event can only be successfully timed if registration data entered into the system is correct and controlled properly, race packs and tags are correctly packed and assigned to participants according to registration data, timing equipment is configured correctly and sufficiently skilled trained timing crew is available at the event. When results need to be imported into a third party program before updating on a website then you automatically start working with disconnected data.

 

We have worked closely with this timing partner in some events and he always provides a professional service. However, to be fair, he was not in control of all the factors that lead to a successfully timed event.

[Bianchisti]

Is the corrected results available now or is that like beating a dead snake?

 

We try again next year?

[Bub Marley]

So basically just to summarize, everything was a **** up. The other jibberish you posted should be discussed between yourselves and the race organisers. I don't think the participants give two hoots really. At the end of the day, they paid big money for this event and the results were a complete mess.

[Bianchisti]

So basically just to summarize, everything was a **** up. The other jibberish you posted should be discussed between yourselves and the race organisers. I don't think the participants give two hoots really. At the end of the day, they paid big money for this event and the results were a complete mess.

Hehehe. You should add...... while all the service providers (including mobii) probably took payment for their services up front with heaps of promises smiling all the way to the bank.

 

Kapeeesh.

[Pure Savage]

Hi Everyone, a bit late to this topic but was asked to take a look here. Our system is absolutely rock solid in reading tags, the hardware is regularly tested internationally to read up to 400 tags per second, so I don't know where these statements are coming from.

 

There is no similar system in action anywhere globally and everything is designed and developed by our team in Cape Town.

 

We are developers of the system and will only be present at events where we train customers how to use our system, from there onwards we have no influence or control over how the event is run.

 

I have actually followed the background to this event and believe me when I say that there were factors outside the control of our timing system that lead to problems at this event. In terms of raw performance, tags were read as designed, but there are other components to making the timing of an event successful apart from the hardware.

 

If you want to understand more about how the system works from a technical point and why this is the future over traditional expensive mats, then here is a video taken from a Road Cycling event that we attended and documented: https://youtu.be/P9qFqE8Y09g

Our system is now actually used internationally in 12 countries representing sports from motor racing to kite surfing.

 

Happy to answer any technical questions you may have.

 

It's just a pity that with an opportunity to impress cyclists with a different timing company the amazing tech was let down by admin issues.

 

The fact the results are still not correct.

[GLuvsMtb]

My intention with the post is to correct the speculation regarding the performance of the timing hardware. We have no interest in which events or timing partners that make use of our system, our focus is on development and introducing new functionality to the system.

Regardless of which timing system is used, an event can only be successfully timed if registration data entered into the system is correct and controlled properly, race packs and tags are correctly packed and assigned to participants according to registration data, timing equipment is configured correctly and sufficiently skilled trained timing crew is available at the event. When results need to be imported into a third party program before updating on a website then you automatically start working with disconnected data.

 

We have worked closely with this timing partner in some events and he always provides a professional service. However, to be fair, he was not in control of all the factors that lead to a successfully timed event.

Ok so basically the timing company got it wrong/were not properly trained to program the timing chips. Pity it took 4 stages to work this out. I'm sure Racetec will have all this sorted next year without tech partners having to add their 2c almost a month after the event.

[Bianchisti]

Eish 2017....

 

Who'll be gunning for a spot among the 500 available slots?

 

Don't think I can fit in a qualifying event. I wonder how many of this year's entrants the qualifying will eliminate.

 

The guest house I was staying had about 10 people who were just joy riding and in the open seeded we often caught the team riders fairly early.

 

Any thoughts?