So if I’m understanding this correctly, the only reason you need the cap and/or resisitor is to prevent you from having to press the boot button when flashing? I was under the impression that is just standard operation procedure anyway.
If you may be planning additional component pads for the work-arounds, perhaps add an SMD already attached, and all the user would have to do is either solder bridge two pads, or jumper. Also, if this was just added permanently, would it effect boards that dont require it?
The only reason not to (assuming no difference in performance, etc) might be that if the drivers or the ESP32 have a tendency to go bad, it’d be a lot harder to drop in a new one.
Which I guess would also maybe make it harder to troubleshoot as well if one being bad was even a possibility.
I don’t know if that’s a genuine concern or not, but I guess something Ryan would have to weigh for future board support, etc.
Yes on the USBC board. The resistor is the other board to prevent having to unplug to reboot when flashing. Neither are a big deal and I didn’t actually think it was an issue until it was proven to me. AND…there might be software workarounds in the works.
It actually costs more, the tmc chips are very expensive, and we would have to move the heatsinks to the bottom of the board. No easy way to do that…and it would increase the footprint of the size of the capacitor (this was the original plan).
Honestly, this makes far more sense to me. Even if you don’t use all of the channels, the on-board drivers eliminate several issues and reduce redundant hardware.
Ok, fair enough. And I hadn’t though of the heat sink issue.
I would think the ESP32 module (not carrier board) would carry the certification. That’s the part with the FCC ID. But there may be constraints on the scenarios where the certification remains valid for the integrated product. Someone more knowledgeable than me would have to check that.
One benefit of using the plug in board instead of on-board is if there’s ever a ESP33 created that’s an upgrade to the 32 but pin compatible, then the plug in board would easily allow for upgrades without having to replace the carrier board.
The best part of all this is, I feel confident I could actually make something that works now. All sorts of changes are possible. I have learned so much. It might not be perfect but someone could point out some changes and we would have a new board. I feel so free!!!
Nothing that I’m aware of for a DIYer. Certainly nothing that is going to change between using one of the castellated modules and the devkits.
Unless the items are being sold as finished products, it doesn’t matter. The onus is on the manufacturer of the product which, in this case, is the end user.
My take on the situation regarding direct integration vs using modules is that it’s all a trade-off. In favour of retaining the modules, the quantities here will likely never be big enough to obtain the level of pricing that someone making those modules will achieve. The price of the ESP32 module and TMC chip are likely the vastly dominant costs involved. The modules can also allow some flexibility, like wiring things in from off-board or using different drivers/controllers if the pinout is common enough. They also allow things to be easily swapped out for troubleshooting or repair.
In favour of integration, I think you’re all getting a glimpse into why we tend to head in this direction for the more ‘professional’ side of the industry. Ultimately it’s more about having control over your product and avoiding these kinds of issues. If you keep a running tally how much time gets eaten by a counterfeit board, or one that is populated wrong and not caught in QC, or was just wrong in the first place etc. then it’s not hard to see how it only takes a small amount of bad luck for the advantages behind modules to become an albatross around your neck with difficult to find and diagnose late-stage problems. It may end up costing more up front and need slightly more design time, but it provides a deeper level of trust/reliability in the production process.
For my money, as I’ve said before, I’d be heading towards integrating the ESP32 castellated modules directly onto the board. I don’t think I would bother with the drivers themselves. I would think the drivers are far more likely to be damaged, be swapped for different units or left out altogether in the case of different configurations of system. The drivers also seem vastly more reliable and standardised in their configuration/features, so much less chance of things just being weird.
The metal can over the chip on that base package is typically fcc ID issued and as long as it has that, you are good.
I didn’t realize everyone was making their own dev boards out of the esp32 castellated board, but that would be the part to find, but only in volume. It is crazy the markdown that accompanies volume.
For intentional radiators, the Certification cost is more like $10,000-$12,000, unless an approved module is used. It may be that you will fail, of course, which will require retesting.
Oof. That is a lot of jackpots to make up that difference. Especially if it failed for some reason. I didn’t think about that.
Yeah, and that’s exactly why nearly everything uses pre-certified modules and does whatever they can to stay under other limits. Lots of stuff gets sold in kit form to skirt rules like this, even when it’s just a few minutes of lego-like assembly to make the final product.
I guess I’m somewhat immune to it by now but yeah, it’s rough. Hidden stuff like that is what torpedoes a lot of kickstarters etc. There are a lot of certification requirements out there for various things. In NZ/Australia we have classes of products that require independent testing to the appropriate standards before sale. That can add a $40k cost if you’re not careful.
On the plus side, a failure isn’t normally a black and white thing, it’ll be ‘you’ve failed in this way’, which gives you the info the re-make things and then have them re-tested, either as part of the original fee or for a small additional fee.
That’s not actually even super expensive, honestly. One of the product lines I was involved with had to send their equipment to TuV in Germany because they were the only company with an EMC test chamber large enough. Between shipping the equipment, sending 2 engineers along to run the system and make the changes needed to get the tests passing, booking the test chamber etc. I think EMC compliance cost something like 300-500k? Much different scale of product, but ultimately the cost never really goes away, it just scales in line
I’d vote strongly that the genuine controller be the default option. Maybe sell the bare board for people that want to bring their own (maybe they have a brand type they’re comfortable with from other projects they’ve built.)
The piece of baltic birch plywood I’m about to throw into the machine was $25, the aluminum I’ll be trying to cut struts will be $70. Even the plywood from the big orange box store is $50 a sheet. If the genuine controller is even slightly more reliable and durable, I’d pay $20 for it in a heartbeat. Some of the jobs are long, and I do value some confidence in my hardware.
Thanks for everything you create for this community! You are appreciated.
(I just looked at the genuine board at Digi-Key and it’s $9.80 retail. Yours could come with FluidNC preloaded and your config files. The board and design are tested. In my mind, $20 as an add-on is acceptable. Perhaps you could sell a “bring your own controller” version.)
I kind of left it last night, but was curious to go look into and learn a little more about the ESP stuff.
It looks like the ESP I have is ESP-WROOM-32D. This does, if I’m not mistaken, have the 4MB of PSRAM.
Out of curiosity, just wondering if Bart had these same issues with his own controller, I went to look to see what he was using.
He is using ESP32-WROVER-E, which I believe has double the PSRAM at 8MB like this one for $10.78.
If this is compatible, I will buy one and test it on my machine in the Jackpot.
While I totally understand your commitment to making things lower cost, and we all appreciate it, what I wouldn’t want to see happen as the use of the Jackpot spreads is that issues related to memory, etc. cause massive amounts of support and headache for you.
After all, this is the brains, so if there is ever a place to spend an extra $7, this is it. If $7 makes it more stable, it is well worth the cost, and I don’t feel like it should be non-starter for anyone that is already willing to spend $500-$1000 building machines like this.
The last thing we want, and I’m sure you want, is $7 standing in the way of actually being able to use this fancy new toy we just created.
So I think in normal terms the Flash is the storage, like a Hard Drive in your computer.
For memory, the default is like 380KB of RAM, but there are external PSRAM chips that can be embedded as well, so I think for memory use, what we are looking for is the increase here:
My board is the ESP32-WROOM-D, which according to the Datasheet
“ESP-WROOM-32D and ESP32-WROOM-32U integrates 4 MB of external SPI flash. The 4-MB SPI flash can be memory-mapped onto the CPU code space, supporting 8, 16 and 32-bit access. Code execution is supported. The integrated SPI flash is connected to GPIO6, GPIO7, GPIO8, GPIO9, GPIO10 and GPIO11. These six pins cannot be used as regular GPIOs.”
So it looks like it has 4MB on board, and I assume FluidNC must be taking advantage of that, but I don’t think they print out max memory anywhere in FluidTerm. I only see Low Memory warnings when it gets under 15KB or something like that
