@MakerJim this went through my head too.
I had one instance that it happened when using my mini rambo that I had wander. but not like this.
Like I said, the pen drawing test was just fine - this was to test accuracy without any load. it seams that when its moving the router through the wood that it wanders.
I’ll check my grub screws as Ryan mentioned and go from there.
I did notice that I have a crack in one of my parts, so who know is there aren’t other crack and weak spots that effect it too.
Well the streak continues. Since this data point to today, the jackpot is outselling the Skr by 225%…and the jackpot was out of stock for probably two weeks of this 6 week period. Dang, that is pretty cool.
That part is finally getting better with the new v1.2. When I flash and test I am starting to learn the issues. Really though the issue is the cheap esp32’s. Out of the last 50-70 I tried I found 4 bad ones. Not enough to spend 3x on genuine, but maybe I will look into making some myself.
I am finding some that of the esp32’s will connect and all that but have bad communication. I tried some basic troubleshooting but can not find any quick test to weed them out. I have to boot all the way in and Do a couple $ss in a row to see it. I am starting to notice a pattern at the login so I might be able to weed them out faster.
I have half a schematic done for a esp32, I hope to poke at it a bit tonight. Just to see if they are any better.
I wonder if you could make another esp32 that always connects to the default AP and tries to do some basic connection tests, and then lights up red/green.
I’ve seen a lot of people geeling out over test setups eith lots of pogo pins and python scripts. Adding a wifi connection would be another level of geek.
I have a whole bunch of pogo pin stuff, and for the most part even the bad ones work, sometimes. But when you do a $SS you will get differnt readouts each time.
I was ready to make a test bench (I will make something for faster connections), but only the really bad ones won’t move a stepper (like a poor solder job of missing resistors). I only want to pass along good ones.
So I need to make something to boot by the power supply only, no USB, then run $ss 3 times to see if they are all matching. I am sure there are some other easier way to test that. I have the funky esps set aside. I am sure there is a common fault point. I tried the resistance of a few pin sets but nothing crazy obvious different yet.
At this point I am not frustrated by it enough to push super hard, I just poke at them once and a while for a few minutes. I am hoping when I at least do the schmatic for an esp32 I will understand them a bit better and know where to look for testing.
We used to debug linux network connections my looking at the tx/rx packet loss. Good wifi networks would have 1-10 per week and bad ones had thousands per minute. I don’t know what the equivalent in esp32 would be. But I am sure it is there somewhere.
I am leaning towards saying it is something to do with the RF antenna design. Maybe it is a bit fickle and some fail. But that is the easy answer (because I don’t know RF. so it is my scapegoat).
As I find more I will update here. So far they are all kinda bad in a different way. I don’t think I have tested USB vs Wifi on the bad ones, I will do that next time.
Are you tracking the types of failures you’re seeing? That would potentially be helpful for figuring out comprehensive test setups.
Makes me wonder what the actual root cause of these issues are. Knock-off modules, modules sourced from QC failures, PCB issues, handling issues, assembly issues, etc. Plenty of options, it’s just weird because the devkits are so simple…
10% failure rate is apocalyptically bad. My last production order was 200 units and there was 1 unit that failed test due to head-in-pillow solder joint failures down half the pins on one side of an IC. That was enough to be worth documenting it and querying with our contract manufacturer why inspection hadn’t caught it.
I have seen a few percent of those just missing resistors and stuff, easy catch. Had my first bad jackpot ever, still need to dig deeper. Little holiday rush keeping me too busy to dig deeper.
Bummer that you’re seeing a 10% failure rate, as noted above that’s horribly bad. If you spend 5 additional minutes extra dealing with each one, your actual cost per batch is up closer to the genuine when you factor in the value of that time.
The dev kits are open source, maybe you do end up building your own ESP32s at some point.
I wonder if there are ESP32 options with more PSRAM or with dual antennas or otherwise more suitable for running in your application.
The ESP WROVER has 4MB PSRAM built in, but you lose GPIO 16/17 in order for that to happen.
You can add the external PSRAM to the current models, but you still have to sacrifice the GPIO for that to happen
I think the ESP32-S3 has 45 GPIO, so you can get the devkit boards with enough GPIO and the external PSRAM up to like 8MB (supports up to 1GB), and 8MB of Flash instead of 4MB, but FluidNC doesn’t fully support S3 yet. I believe there has been work done on it, but it’s not complete.
There are some tradeoffs with the S3, of course, but I think for the purposes of the Jackpot, it would probably be much better if FluidNC was fully working with it. You get Bluetooth 5.0, but lose Bluetooth LE, lose some LED PWM outputs, etc. Full comparison Here
I don’t know what the long-term plans of FluidNC regarding the S3 is though.
Well 1 actual bad one the others seem to do everything else fine just not fluidnc, a lot to learn yet. I just set them aside to look at later. Time wise only about a minute each is wasted, less probably. I just flash test and go. I don’t sit and wait for things to happen, I keep moving.
I am working on a schematic right now, but most of my time has been spent trying to figure out which one to base it on. I think I am going for the esp32-wroom-32E (N4/N8). E is supposed to be the current version but all the same functions…who knows. Worth poking at the schematics look the same with a quick glance.
I don’t know enough about this stuff and I can’t just learn it reading the docs page I have to “make” something to not skim over little choices (like capacitor type).
Interesting. The -S3 moves up from the LX6 core to the LX7.
Those can support up to 1Gb of PSRAM (!!!)- but I can’t quite tell from the comparison if there’s variants with built in PSRAM.
Also interesting is that the dev board for the -S3 has dual USB ports, which might be a boon to those wanting to leave a controller permanently hooked up to the UART.
After looking at the specs of the -S3 in the post above, that would be a pretty interesting part long term.
Maybe for the 2nd revision of the V1 ESP-32.
I bet you’d get pretty good support here if you were to embark on a V1 variant of ESP32. There’s a lot of enshitification in the ultra-cheap dev boards, just using decent (but still inexpensive) parts would likely make them much better behaved.
