The laser is less than four feet from my wifi hub - can’t get much closer and there isn’t anything around that could cause interference. It’s running at the moment (huzzah!), but seems to be a crap shoot. I suspect I will have more trouble this evening. We’ll see.
I wonder if enabling Qos and giving priority to the forge might be enough to overcome some of these issues.
You might want to check to see what the channel width your wireless router is set to. Modern wireless routers allows either 20 or 40 MHz widths on 2.4 GHz frequencies, but a number of factors like your neighbors traffic and compatibility with your existing wireless devices can affect the reliability. Newer routers like to try using default settings of 40 MHz.
For myself, I’ve had to force my 2.4 GHz frequency to only use a 20 MHz channel width because I have as many as 25 foreign access points within listening distance. With so much traffic, a 40 MHz channel width is ineffective because it’s always getting shouted down by my neighbors. This wouldn’t be as much of a problem if I did a site survey and only had 1-2 neighbors visible.
Thankfully, there’s many ways to do QoS. Depending on the firmware your router has, you might be able to avoid all the elaborate settings of traditional QoS packet marking and just set it based on an IP address. I personally use DD-WRT firmware on my Netgear routers, and it lets you set an ip+netmask.
3 Likes
How much ambient light do you have? I recall somebody saying that can affect that process
Probably over saturated with WAPs or repeaters. There is a threshold for when your devices will switch (or look to switch) as signal strength falls. Often times with too much overlap you’ll get stuck on a low strength signal when a much stronger one is in range. The low signal wasn’t low enough to trip the release threshold so you sit on a sucky connection when you can see the stronger one because you’re looking right at the repeater or WAP. You can have too much of a good thing. The solution is to spread them out or disconnect some of them altogether.
1 Like
It’s a good idea to do this, but where this gets tricky is when you have closely matched signal strengths between multiple satellite access points in your installation. It’s not uncommon for AP signal strength to fluctuate by several dB, even when you’re not moving around. But since the endpoint is the one that chooses which access point to connect to, and depending on the network driver, some devices have insanely (read: annoyingly low) tolerances for when they’ll re-hunt for a better access point.
Unfortunately, when it’s hunting / switching from the now quieter AP to the louder AP in your network, traffic comes to an abrupt halt while it reconnects. As I said about APs being around the same signal strength, some devices will repeatedly dance from one AP to the other and back again… over and over again…
The 802.11r protocol provides a mechanism to provide fast handoffs between access points. It’s mainly used for mobile VOIP devices though, so that someone walking around with a handset doesn’t get disconnected from their call as they move from AP to AP.
That doesn’t help Glowforge owners, though, because you’re not likely to see consistent 802.11r support in consumer wireless routers. It’s mostly enterprise routers that support it.
Short of moving it closer to one of your access points, what I would recommend people do if you have near the same near quality connection among your mesh of Access Points is try using the MAC FILTERING features to try locking it to only one of them and not the others.
What I’d like to see Glowforge do is add a wireless firmware feature that allows it to be set to STOP HUNTING for better signals, or let people set a timer of how long to endure a poor signal before hunting again.
3 Likes
Not to fully derail this thread, but I feel obligated to update. After sitting for 60 hours without power over the weekend, my Glowforge powered up and ran flawlessly on a test cut this morning. I’m somewhat puzzled because of its behavior on Friday and supports’ diagnosis that it needs to be returned that it now seems to work as intended. I’m suspicious that something going on at the server level caused it not to respond last Friday.
It seemed to me that the servers were acting a bit weird this past weekend. What I noticed were long delays when scanning the material. A couple of times I had a cut-only job (about 1.5 minutes total) that would take 5 minutes or so to scan and process before the job actually started. It seemed like every job took longer than normal to process. Overall, everything still worked for me, though, so no major complaints.
It looks like your unit is experiencing an intermittent issue that I can’t resolve remotely. I want you to have a reliable unit, so I’m recommending we replace this one. I’ll be in touch via email to sort out the details. I’m so sorry for the bad news.