Garbage internet can be defined in different ways though (and I know you know all of this - probably more than me lol). I’m not a network engineer by any means but I can think of:
speed : doesn’t seem to be a huge issue, except you have to download the wav form that is processed. Others have said this can be up to 100mb - this could be a few minutes of waiting, depending on your connection.
latency : shouldn’t be an issue since the wav form is being downloaded and then processed… not gaming, unless maybe some kind of problem checking/verifying packets? I guess latency could challenge TCP throughput.
packet loss : seems like this could be a big one, especially for calibration etc depending on how it’s programmed to be handled
signal strength: impacting all of the above
My iphone 6s sitting on top of the Glowforge where the wireless receiver is has a 79% signal versus a 69% signal for the Glowforge as indicated in my router administration screen (Netgear Genie only gives % - not db).
Garbage in the sense of on the edge of coverage range (How does it cope with that) ridiculously slow (<256Kbit/s) crazy high latency (Cellular hotspots).
Before Makerfaire, I reconfigured our PRU to the hotspot we where going to use and moved the hotspot into the garage. The unit is on the second floor in the house so 120ft ‘as the crow flies’ thru 4 walls and a floor. Our garage is standalone and concrete. Surprisingly it worked. Slowly but it worked.
Random thought. A smaller Glowforge with a hotspot built-in. Glowforge Mobile.
Lid cam pictures are ~400KB, and the resulting PULS files are typically around 20KB or less depending on how far it has to move. Figure about 10KB per second of commanded motion.
Latency can play merry hob with data transfers on a weak signal.
You are probably aware of this, but spelling it out for those less knowledgeable. Each of those files get broken into a whole bunch of chunks (called packets), each roughly 1.5K in size. Any one of those can get corrupted or lost along the way. TCP (the networking protocol that http/https runs on top of) will guarantee that (as it appears to the application) all of the packets get there, and assembled in the correct order–or the entire transfer is failed. But that process includes a series of back-and-forth handshakes and acknowledgements. This can cause a large transfer to be delayed by significant amounts of time.
Games work around this by using the UDP protocol (upon which TCP is built) and handling dropped and out-of-order packets. This allows them to never have to wait for the guarantees that TCP provide. Netflix and other streaming services work around this by using Buffering and Forward Error Correction.
Edited to add: This is not a suggestion that the Glowforge should use the techniques games or Netflix use. TCP is great for file transfer…just setting expectations and fostering understanding of what goes on.
No disagreement there. I just believe that the bulk of the homing problems cannot be explained by a weak signal.
If you have a tolerable web browsing experience via the connection (good enough to post on this forum about the problem), there should be no problem using the Glowforge over it.
Most of the homing process is the Glowforge waiting on the cloud for the motion file after it has uploaded the lid cam image. This seems to take an average of about 5 seconds, and is independent of the quality of the Internet connection. (A poor connection would certainly affect the upload and download times - which can be seen in the logs on the device itself - but would have no affect on the cloud’s processing time).
I have a decent amount of experience with embedded WiFi. Most chipsets for anything other than brand-name computers and phones are pretty crappy. If your iPhone works great in the basement, that’s because the richest company in the world has poured countless hours of the best wireless experts around into antenna design, handoff, band selection, working around all the little nuances of 802.11, etc. A chip antenna on a single board computer with WiFi built into the chipset along with an FM radio and smoothie maker is likely to fall off the network if you look at it wrong. I don’t know where the Glowforge falls on this spectrum, though. I think it has an Intel something or other. I have not disassembled mine.
Seems like the virtual machines in the cloud are actually less powerful than the ARM chip in the machine!
Have you looked at what the camera sees when the head is under it? Does it block everything else out or does it still see the corners of the bed?
When you say the last thing cut was a rectangle is the material still in the machine or do we think the cloud is failing to get a new image and is processing the last picture it took of the material over and over again?
Believe he is saying that the S/W is misinterpreting a black cutout in material left on the bed as the head itself. So the the S/W thinks the head is in the wrong place and moves it in the wrong direction hitting the side. I have experienced this and can easily repeat it. Put the material in a certain location and I will get head banging during calibration. Remove it, I don’t. No problem otherwise.
That’s not to say everyone is experiencing the same thing. Lots of reasons why the S/W would lose track of the head and calibrate incorrectly. Shadows from overhead lights, or the sun coming in a window for example. Lots of reasons why the calibration might fail in other ways that have nothing to do with those examples.
What I find interesting, is that they don’t seem to be checking to see if the head had moved between images. They also don’t seem to keep track of whether or not they are continuously driving the head into the stop.
If I leave it be, it will keep going and going. You would think that at some point they would say, “Golly Gee, we sent enough steps to send it clear across the full possible X/Y distance. Maybe we stop and indicate an error.”
You don’t need to take apart your GF to find this information. It is hidden in plain sight in the FCC ID number. It’s a Texas Instruments WiFi module. And a pretty decent one, too. They also use diversity antennas that are mounted to the front and right side of the case, away from the metal bits.
Mine is about 25 ft from the access point, and gets very good signal (“iw dev wlan0_sta link” from the console will give you the current signal strength).
I’ve suspected for a while now that the calibration is suffering by mistaking the “black boxes” of the holes of cut material left on the bed during calibration. I’m curious to try seeing how bad it really is by cutting a square the size of the Glowforge head when mine arrives.
I’m also curious to see if calibration improves by placing clean white (or perhaps grey, to prevent light flares) paper down inside the gantry before powering up.
I don’t know if they’ve changed the calibration process or what, but mine has been perfect the past couple of weeks or so - material or no material, blinds open or closed, overhead (though diffused) light on or off.
It also matters where the cutout is on the bed. I was able to take a piece of material with cutouts and lay it on the bed and get a calibration failure every time. Move the material just an inch or so and it calibrated fine. Not definitive but, if the machine can clearly recognize the head or can easily see that the cutout is not the head then it calibrates fine.