Question for any operators out there... is anyone having an issue with IC not being able to find IP address from your WiFi and then after 1 - 20 restarts it finally finds an IP address and your ready to go. It's becoming very frustrating having to spend countless amount of hours trying to get all of my Sterns and our Big Buck Hunter Reloaded to connect/find an IP address from our modem/router.

P.S. I have a Comcast Business router - full strength.

If anyone was having the same issue and found a fix... I'd greatly appreciate any insight.

Thanks

wifi signal is a often-discussed problem with these systems. For people for whom it's a blocking issue, they generally upgrade the wifi dongle; there are recommendations for a particular TP-Link model that is compatible with the Stern software. Just do a search for it.

Other options include putting the stock wifi dongle outside the cabinet, by using a USB extension cable, or hard-wiring the network to the Ethernet jack on the motherboard.

Either way, cable passing through the cabinet is something you'd need to figure out. You can run the cable through the topper hole (pop the plug out, assuming no topper is already installed...I guess if one is, this might be a little more complicated depending on the topper), or make a new hole.

Sometimes just reorienting the machine will help, some some parts of the backbox are more opaque to radio signals than others. But if you've got a room full of pins and not many choices for where they all go, this may or may not be feasible.

Occasionally not being able to connect is a fun feature that we all get to experience every once and awhile.

You basically do the same basic steps you would do if your computer lost connection. Rebooting modems, throwing a fit.

Get a WiFi repeater for your location. The signal strength is too weak for the devices attempting to connect to the access point. Additionally, a WiFi repeater can be used to relay a 5GHz/WEP/open connection to devices which only support 2.4GHz/WPA(2).

And make sure it’s a modern one that uses the 802.11ax standard that came out in 2021.

real time updates here .it's 8:35 EST and day has not reset yet. will check again after 9pm lol.

Does anyone know.....

The IC kits you can buy at Pinball Life etc, do the aprons come with the 2 holes for the small LED boards that shine onto the flipper area?

My TMNT Pro has the LED's

Are the apron LED's / holes stock on all games?

Thanks

I noticed that too. Maybe they finally fixed the days / timezones. *gasp* maybe next they will actually do some metrics!!! How much more do I earn on an average Sunday than a Thursday I CAN'T WAIT TO NERD OUT

My read on todays data would seem to support that they changed something.

Yep - Mine has not reset yet, it's 7:45pm. (I'm GMT -7)

Now I'll need to check every hour through midnight.. as I'm stricken with curiosity now.

YES. The apron comes with holes and there are plugs in that you can remove easy. I know I just did it to my TMNT Pro.

10:05pm EST. still same day.

11:18. Still same day. I’d guess it will end up resetting 2am EST (midnight Central time). I won’t be up but if anyone is, do report. Thnx!!

Looks like it resets at 12:00am est.

Yep, It reset at midnight local time.

Looks like it was updated to correct for the GMT global reset, and now is midnight local reset. Much better....

On the one hand it's horrifying it took 10 months to change this teeny tiny little itty bitty bug. On the upside maybe there's just a 10 month delay on creature comforts and this will be the first of many useful improvements. I'm a hopeless optimist.

As soon as I ordered my IC kit I ordered Gotfrogs kit to move the scanner to the coindoor. This came in handy since the EHOH came with docquest apron mods. Really nice to not have the scanner in your face all the time.

https://pinside.com/pinball/market/shops/1295-gotfrogs/05778-metal-stern-insider-connected-qr-code-reader-coin-door-mount

Can you give a quick summary of your programming ability?

The QR reader on our GZ stopped working. No white light, won't scan. Board shows ethernet activity and blue LEDS. Tried unplugging/replugging all cables, testing (with HV switch properly pulled out) and still no response. If I unplug/replug the ethernet cable, the white illumination briefly turns on, then turns off. Any thoughts? Figured I'd ask here before starting a ticket with Stern. Thanks.

There is a design or material defect in the original readers. Open a ticket and get it replaced. They will make you go through your distributor.

Looking at my connected games this morning (3) wish in the app I could challenge others to a game. Would be an awesome feature.

Give yours if you think accounting for GMT vs local time when you already have the numbers should take 10 months. I'm some fucking jabroni and I could learn whatever language they're using in that time. Former network engineer / programmed Cisco gear, used C++ and basic and shit is about 10x easier now.

If you have warranty, put in and get a new reader. Machines cost a lot of coin so they should work.

I have taken one apart and the main issue is the small ribbon cable joining the two pcbs in the scanner. The connectors for the ribbon cable to the pcbs were not very good (flakey contacts), on the newer pcbs there are different connectors for the ribbon cable. Issue resolved.

Opened a ticket with Stern over my QR issues. They had me run a few tests, and concluded the illumination lights were bad. No node board errors (in testing), and it will scan a QR code from my phone if the brightness is turned up. Warranty replacement incoming. There's a backlog, so may take a month or two. Stern customer support has been quite good on this and a few other queries over the year. FYI.

Hello People: please excuse the ignorance of my abbilities, however,I have a Bond Pre on order.I do not posses a cell phone.What am I supposed to do with this IC??Thank-you for reading!!

If you have access to any kind of computer printer, just print the QR code on paper and scan that.

Also, for your own machine, you will probably find it convenient to use the "Home Team" feature, so you'll only have to scan the QR code once. After that, you just hold down the left flipper button, which will take you to an interface where you can select your account, along with other family or friends that you've added to the "Home Team" list, without having to use the QR scanner at all.

Pete-d Thank-you for your suggestion!!

We printed ours and made them into key chains.

Measuring things like "daily metrics" on a system that operates across timezones is not easy. When does the "day" begin and end? Is the "day" always 24 hours long, regardless of Daylight Savings changes, Leap Seconds, etc.? If not, are comparisons valid when one "day" is 23 or 25 hours long, and the next "day" is 24 hours long? What happens if your machine is located in Indiana, where you have zip codes that straddle the Eastern and Central timezones? What happens if you operate a machine in Central, and another machine in Eastern? What happens when you move one machine to the other timezone? What about Arizona, where they don't do DST?

If you think this stuff is easy, you have no idea what you are talking about. Companies like Google employ entire teams to deal with timekeeping problems and designing analytics and reporting platforms to deal with them.

So as a little test (lying I was just playing past 12) I wanted to see it my IC gave me credit for another day to the streak right at local time at midnight. Sure enough right at 12:05 my next game upped my streak. Thanks to the IC team at Stern.

It is pretty straight forward. Want something not fun... try managing scheduling with series and exceptions across timezones with DST Where you have to worry about the frame of reference for not just the time, but the date for WHEN and WHERE that time was picked and the DST rules for that pick (and the fact DST rules change). So you have the issues of what the --real intent for time-- was when the thing was created, and you have different viewers who each need to see their own perspective.

For reporting all you have to care about is adjusting for the viewer's perspective.. the source can always stay in UTC .. simple. You can just adjust the view based on the viewer's perspective...which can always be the current perspective or when it comes to computed reports, just pick the reference and make it known (Example: taking the location's timezone and compute based on that). You're only adjusting on presentation and don't really care about the real devil... which is a reference that spans multiple dates.

Easy: Show me something that happened 14:00 UTC in a time based on my timezone
Easy: Count all the entries between two UTC time points with a Offset picked based on a location's timezone
Hard: Bob in the UK picked the job to run at 9am on Oct 1, everyday for a year. Ensure the job runs at the same 9am relative to Bob every day, across DST, and when Alice in the US looks at when the job will run at a date in the future, show it at the right time FOR THAT date in Alice's correct time.. but it still is the correct 9am relative to Bob.

Reporting and counting with timezones and DST is not that difficult. Setting things to happen in the future and viewing their correct relative perspective is where it gets messy.

I managed a global scheduling product for over a decade that fully supported recurrences and DST. I'm well versed

You are right that dealing with time zones in computer programming is madness, and a great challenge.

But Stern has (presumably) already done all that work. The machines already know how to convert from local to UTC and back, as do their servers. Assuming they did that work properly, coming up with a reasonable implementation to track streaks according to local time would in fact not be all that difficult.

I will admit, the prerequisite that they have done that work properly cannot be assumed. But if not, that's still on them, and not any kind of justification for the fix to the streak-tracking to be considered to be difficult.

Now, all that said: every engineering team, even those writing software for pinball machines, has a long list of tasks, and they prioritize those tasks and do them according to that priority and the available staff time to apply to the tasks. I can well imagine that in Stern's view, the daily streak feature has a lower priority to fix than other things they are working on (many of which you and I won't see, because they involve the underlying infrastructure and not end-user visible features). And there's only so much an engineering team can do to speed up that process, a la "The Mythical Man Month". Even if they were hiring additional programmers -- and as far as I know they're not -- there's going to be a limit to just how fast everything can get done.

Fussing about whether the feature got fixed today or six months ago seems pointless to me. It's just a game, and you can keep track of your daily streaks almost as easily as letting the pin and Stern's computer servers do it for you, if it's really that important to you. At least they did eventually fix it.

Then you're also aware that keeping the schedule in UTC works only if the system actually is only tied to UTC, i.e. the local time is strictly for display purposes only.

When the scheduling is in fact tied to the local time zone, it does get a little more complicated, DST being the prime offender. Because there will be a "day" in your schedule that's only 23 hours long. And then roughly six months from then, another "day" that's 25 hours long. And your locally-based tracking system has to respect that.

See e.g. https://codeblog.jonskeet.uk/2022/10/30/handling-times-for-an-ev-charger/

I'm not saying this is an insurmountable challenge, or even one that takes literally ten months to figure out. Obviously, it's not. But it's not as trivial as "just keep everything in UTC", and of course that task might not even have been the one considered the most important to work on, so lots of time might have gone by before anyone at Stern bothered to look at it.

This isn't that complicated because you only have one frame of reference to worry about... where the executor is. Your complexity comes on the transitions, not every day. The displayed information is dynamic and can always be adjusted from your fixed reference on the fly. Having a dynamic perspective is easy because your data's reference is constant. The challenges come in when do you process aggregate data and how closely it should be available to an end-time that in itself is relative (like play streaks).

I just want easy stuff like 'todays plays' to be accurate to the location's timezone. They weren't. That is an easy stat!

But looking at today's stats... they might actually be timezone adjusted finally. At least today right now, none of my games are showing plays from Sunday. A week or so ago, that wasn't the case.

I have a lovely little anecdote that I pull out whenever talk about software engineering around timezones comes up.

I used to go to the local Alamo Drafthouse theater to watch movies. Decent food, decent service, ironclad policies against lateness, cellphone usage and talking during the movie, as well as a well-curated slate of programming catering to niche movie lovers. Basically straddling the line between an indie theater and a big multiplex.

Anyway, one day they announced a one-night showing of Commando, Arnold's quintessential 80s macho action flick (not Predator, the other one). I snagged a ticket and hit the "Add to Calendar" button on the confirmation page to add it to my phone's calendar (because if it isn't in my phone's calendar, it doesn't exist.) A couple weeks later, I showed up fifteen minutes early for showtime, only to be turned away for being 45 minutes late. I checked my calendar, it said 8pm showtime. It was 7:45pm. How could I be late? Did the showtime get moved up an hour without me knowing?

Eventually, I figured it out. I bought the ticket while I was in Chicago, on Central Time. The theater is in Brooklyn NY, on Eastern Time. The "Add to Calendar" link just indicated "7pm" without a timezone offset, so it got added to my calendar as 7pm CT, which got changed to 8pm ET when I returned to New York.

Moral of the story: in software engineering, a time is meaningless without a timezone attached. If you don't want to deal with timezones, just use the unix timestamp and let people cleverer than you work out the displayed time.

I would disagree there, because the play streak stat appears as a badge on your profile, and your profile can be viewed globally. If you dynamically show the badge based on the viewer's timezone, you'll get different results for viewers in different timezones. Someone in Japan who is already across the date line might see that you haven't played a game that day, so your streak is over, while someone in America is still on the previous day, so your streak is alive and well. If you want the profile to appear consistently for everyone globally, you have to pick a single day-boundary time for everyone. But then you get the problem being complained about in this thread; why is the boundary at 8pm local (or whatever).

No, not really. You just have to use a different absolute reference than UTC. I.e. the time zone the machine's in.

Which of course means that Stern's database has to store the machine's timezone, in addition to the other data. And of course, if the player plays the machine in one timezone, and then travels to another timezone and plays the same machine, that complicates things.

In other words, you're right that it's not quite as simple as just storing everything as UTC, and the adjusting according to whoever is viewing the stats. But I don't agree that there's no viable solution, and while it does require some fiddly detail work, it's not rocket science. You just need to think through the various scenarios, something that any decent computer programmer should be in the habit of anyway.

does it even use the local clock on the game it self?

I believe it uses the time zone from the location the machine is registered for. The clock and timezone in the machine is set by IC, not the other way around.

Is there a way to add a game to the home team with only wifi and not the full in$ider connect kit?

As far as I know, the only way to add a player to your home team is to use the QR code scanner. So, I don't think it would be useful to add a game to home team if you don't have the scanner.

Borrow a scanner, move it around to set the games and players up, return the scanner, enjoy scanner-less Insider.

They already have the timezone information, it's displayed at the top of the screen. They just didn't do anything with it until now.

Leap seconds? Dude we're trying to build a useable pallet not a piano. None of the examples you bring up would change anything about the way the thing was implemented. Account for timezone, that's it.

Note what i said and you quoted… “ The challenges come in when do you process aggregate data and how closely it should be available to an end-time that in itself is relative (like play streaks).”

Something like play streaks are not just a dynamic view but something you have computed and stored. Contrast this with something that is simply a view… like today’s plays. It’s exactly why i made that distinction in my post

Another thing is not all data is computed based on the viewer, some makes more sense to be in the location’s reference. But when dealing with just past data, it’s still much easier than dealing with a time reference into the future or having to make a comparative reference to your current date. Just keep your absolute dates.

All this is just talking in circles unless talking about a specific feature. But for simple stats and aggregates this is not rocket science. It’s all well understood. You just have to actually scope it in the requirements right… else you get the ‘everything works off server time’ like they had at launch. Just sloppy because you know their qa was more “is something there?” Instead of “does the data make sense?”.

It’s getting there … just moving at a glacial pace. Hopefully the new hired help will actually drive better requirements and acceptance testing for their outsourcing partners.

Games that are added to your gameroom will get all players listed in your home team, no need to scan on each machine. But yes, the machine needs a wifi-dongle and an SD-card. Very simple and cheap.

You guys are awesome! Looks like I have a project over the Thanksgiving break. I don't feel like shelling out for a full kit at the moment.

$25 at Office Depot, curbside later this morning.

Update: this dongle isn't being recognized by the game. Do I need a specific USB wifi?

It could also be your home network. IC is designed to work on 2.4ghz wireless while many home networks are now on 5ghz. So first I would check that you are able to broadcast a 2.4ghz signal. If are you able broadcast at 2.4ghz and it is till not connecting you may have to adjust advanced "band sterring" settings on your router that help push devices to the proper signal.

But you could also test that dongle in a different device to rule out that it is not the dongle itself that is giving you grief.

You can't buy just any wifi dongle. It has to use the same chipset as the one Stern already provides, so that the software on the motherboard has the right driver.

You can search this thread for recommendations. I believe TP-Link makes one that's compatible with Stern machines and which works much better than what Stern gives you.

I was able to make it work with a Stern dongle, but I have tried three dongles from office max and no dice. It seems like Stern wants me to buy their kit. The last one was a tp link ac600.

Check this post: https://pinside.com/pinball/forum/topic/stern-insider-connected/page/44#post-6681716

The AC600 is one of the models that other people have specifically said does not work with Stern machines. So not very surprising it also doesn't work for you.

It sounds like you have access to a Stern-provided dongle, so if you want to be more analytical about it, plug that dongle into a PC, check the hardware info to find out what chipset it uses, and then look for a different brand that uses the same chipset.

Also, while it hasn't been my experience, some have said that the wifi dongle will work only in one of the two USB ports. So if you think you have a model that should work and it still doesn't, try the other port (IIRC, on my Rush machine, the wifi dongle is in the left hand port).