codrus (Forum Supporter) said:
Tom1200 said:
I really am a pain in ass. I still want to know the difference between our current method and this system.
Well, if it's like other forms of motorsport that have used in-car flag display (F1, say) it's a supplement to the physical flags rather than a replacement. If you've got all the same flags that you used to, PLUS a display/alert (with sound?) in the car, then that's better at providing notification to the driver. I can see it being adopted by club racing organizations fairly easily -- if SCCA or NASA says you have to have it to compete people will grumble but in the end it's not significant compared to the existing costs so it won't make any difference to participation.
I do NOT see it being adopted by track day groups as described. They're specifically designed to appeal to much more "casual" customers who are not going to buy their own in-car hardware or pay subscription fees. The "track day organizer supplies rental units" model doesn't work either -- most track day groups don't have $25-30K ($250 each times 100-120 cars) of spare capital to burn and it becomes a huge logistical nightmare to charge them all up before an event, hand them out to the drivers, collect them at the end of the day, keep track of who got what and did they return it, deal with lost or damaged units, etc. Locally BMWCCA runs a data-based coaching add-on for advanced drivers, and just dealing with handing out 15 or so solo 2 systems is enough of a challenge.
What I can see showing up at track days would be a system that's just an app you run on your smartphone. Everybody's got one of those, many drivers are already mounting them in the car to do timing and/or video. If you've got a "Flagger" system at the track for the event, it should be fairly straightforward to run an app on the smartphone that acts like the dedicated in-car unit. Use cell data for the flag info (very low bandwidth requirements), GPS for location, and the app shows the flag whenever you're within N feet of the corner location that it specifies. Ideally it would be one where the "Flagger" system generates a standard protocol that third party apps can tie into so that instead of having to use a flagging-only app, the flag stuff can be an extension to whatever your favorite timing app is.
Tom1200 put what I was trying to get at in my original post much more succinctly. Sure, it's *just* a $100 per year, but it's still $100 per year. Possibly from *everyone*. It's much better to look at what they're asking for in aggregate than individually. They're nominally asking for $6 million over the next 5 years (or so, given what the true adoption rates will be, etc.). That is still a lot of money, and really out to have at least a little bit of data backing up that it offers some sort of improvement. Unless there are some strict rules on mounting location to make sure it's in an improved LOS location, it's ultimately just as easy to miss as a flag.
codrus (Forum Supporter) said:
What I can see showing up at track days would be a system that's just an app you run on your smartphone. Everybody's got one of those, many drivers are already mounting them in the car to do timing and/or video. If you've got a "Flagger" system at the track for the event, it should be fairly straightforward to run an app on the smartphone that acts like the dedicated in-car unit. Use cell data for the flag info (very low bandwidth requirements), GPS for location, and the app shows the flag whenever you're within N feet of the corner location that it specifies. Ideally it would be one where the "Flagger" system generates a standard protocol that third party apps can tie into so that instead of having to use a flagging-only app, the flag stuff can be an extension to whatever your favorite timing app is.
That's an interesting idea but I'm not confident that it would be reliable enough to be practical. Even if it was reliable I think the latency might by a problem. There's also the issue of there still being tracks in some parts of the country with little to no cell coverage.
In reply to Tom1200 :
Hi Tom, I get your question and understand you don't just want to hear testmonials (which there are many). We will certainly be collecting the data ourselves but you also have to have some original data to compare it to. In short, we just brought out the system this summer and there is still very little data collected. All I can give you now would be testimonials. I'll say this, the first day in a big race I had about 5 drivers tell me personally the Flagger device went off in their car and it made them look up to see the corner worker and the incident. I know the Flagger n-Car Alert System has already kept secondary impacts/incidents from happening so I believe the data will be interesting as it comes in. It might end up being tough to compare data if organizations don't have good, tallied data from their years of records.
APEowner said:
codrus (Forum Supporter) said:
What I can see showing up at track days would be a system that's just an app you run on your smartphone. Everybody's got one of those, many drivers are already mounting them in the car to do timing and/or video. If you've got a "Flagger" system at the track for the event, it should be fairly straightforward to run an app on the smartphone that acts like the dedicated in-car unit. Use cell data for the flag info (very low bandwidth requirements), GPS for location, and the app shows the flag whenever you're within N feet of the corner location that it specifies. Ideally it would be one where the "Flagger" system generates a standard protocol that third party apps can tie into so that instead of having to use a flagging-only app, the flag stuff can be an extension to whatever your favorite timing app is.
That's an interesting idea but I'm not confident that it would be reliable enough to be practical. Even if it was reliable I think the latency might by a problem. There's also the issue of there still being tracks in some parts of the country with little to no cell coverage.
Assuming you have decent coverage there's no reason why latency should be an issue. Yes, tracks with no coverage would be a problem (looking at you, Laguna Seca), but hilly tracks are going to have problems with any system that uses a local transmitter in the paddock as well.
Honsch
New Reader
1/7/21 1:31 p.m.
Technically, this is a simple problem.
Commercial off-the-shelf LoRa radios will do the data just fine, and the software side isn't very complex.
$200 for the in-car box is fair, but any subscription fee for the in-car box is not. The only reason you would need software updates is to fix bugs or add features. If it's just a flagging box, the feature set is tiny and fixed, so only bug fixes should be needed. If a bunch of new features are added, it's fair to charge for the upgrade.
codrus (Forum Supporter) said:
APEowner said:
codrus (Forum Supporter) said:
What I can see showing up at track days would be a system that's just an app you run on your smartphone. Everybody's got one of those, many drivers are already mounting them in the car to do timing and/or video. If you've got a "Flagger" system at the track for the event, it should be fairly straightforward to run an app on the smartphone that acts like the dedicated in-car unit. Use cell data for the flag info (very low bandwidth requirements), GPS for location, and the app shows the flag whenever you're within N feet of the corner location that it specifies. Ideally it would be one where the "Flagger" system generates a standard protocol that third party apps can tie into so that instead of having to use a flagging-only app, the flag stuff can be an extension to whatever your favorite timing app is.
That's an interesting idea but I'm not confident that it would be reliable enough to be practical. Even if it was reliable I think the latency might by a problem. There's also the issue of there still being tracks in some parts of the country with little to no cell coverage.
Assuming you have decent coverage there's no reason why latency should be an issue. Yes, tracks with no coverage would be a problem (looking at you, Laguna Seca), but hilly tracks are going to have problems with any system that uses a local transmitter in the paddock as well.
The problem with latency is that you have no control over how the network traffic is prioritized. Just for kick I just spent some time pinging google from my cell phone on a full 5 bar 4G signal. Each cycle is 20 packets. Most of the time the ping time is less than 100ms and once the cycle starts it's pretty consistant with average ping times of around 60 ms. If it always did that it would be great but every 10th cycle or so something in the network path decides that my initial packet is a low priority and it can take up to 20 seconds for the first ping to return. That's with empty packets and no processing time at the server end. You can't send data directly from one cell phone to another or from a computer directly to a cell phone. It has to go through a server of some sort so there's also the issue of the service having enough servers and server processing power to handle all of the traffic.
I suppose that the track software could host a website and the cell phones could be logged into that website but there's still going to be some inconsitant latancy. Heck, my office is fiber from the wall to the IXP and I still sometimes have to wait for the GRM forum to load. There's just no way to do what's essentiallly real time control through the internet.
It's also worth mentioning that the Flagger system forms a mesh network between cars and corner stations, meaning it's not reliant on one central antenna or cell service to reach the far corners of the track. In theory, that should make it much more reliable than a smartphone.
APEowner said:
The problem with latency is that you have no control over how the network traffic is prioritized. Just for kick I just spent some time pinging google from my cell phone on a full 5 bar 4G signal. Each cycle is 20 packets. Most of the time the ping time is less than 100ms and once the cycle starts it's pretty consistant with average ping times of around 60 ms. If it always did that it would be great but every 10th cycle or so something in the network path decides that my initial packet is a low priority and it can take up to 20 seconds for the first ping to return. That's with empty packets and no processing time at the server end. You can't send data directly from one cell phone to another or from a computer directly to a cell phone. It has to go through a server of some sort so there's also the issue of the service having enough servers and server processing power to handle all of the traffic.
I suppose that the track software could host a website and the cell phones could be logged into that website but there's still going to be some inconsitant latancy. Heck, my office is fiber from the wall to the IXP and I still sometimes have to wait for the GRM forum to load. There's just no way to do what's essentiallly real time control through the internet.
If you're seeing 10% ping traffic loss (delays of 20 seconds are effectively traffic loss) then either the network is totally broken or the server is de-prioritizing replying to them. The latter is possible -- Google's servers are there to provide specific services and acting as ping mirrors for random people trying to do network performance analysis isn't really one of them. Barring network failure, it's a simple engineering exercise to get latency down to less than a second which is plenty for this application. People play FPS games over LTE connections, remember. :)
Also keep in mind that even if the network does fail, any electronic flagging system is always going to serve as a supplement to having proper corner workers (those workers are still needed as eyes and ears if nothing else).
No, you wouldn't use a web site. You'd have a central db, clients would register what track they were at and the db would push out notifications for flag events (flag going up, flag coming down) at particular corners. The only even semi-"real time" aspect would be deciding when the phone should display the flag, and you'd do that in the client application. Put a track map in there and it can use GPS to figure out what corner it's in. It gets a notification for "yellow in turn 4, laguna seca", it knows it's currently going down the front straight, so it waits til you get to T2 to display the big warning.
(It's not relevant to the topic at hand, but the part about cell phones not being able to talk to each other is only sort-of correct. Networks are built in layers -- different protocols are stacked on top of each other in order to provide different types of services. Phones do not talk to each other at the cellular level ('data link' layer), but there is no technical reason why they can't do it at the IP layer ('network' layer). The service provider may well have security/firewall rules in place to prevent them from doing it (because it's not the sort of thing that customers generally want to do), but in principle they can.)
In reply to Matt Eastling :
Matt thank you so much for answering and being so open and honest. It sounds like your initial data supports the product.
As a professional pain in the ass (aka Purchasing Analyst) I really do appreciate it your straightforward open answers. That is always a good sign with a supplier.
