Do you ever see some weird hardware and you just think to yourself: Okay,
this looks kind of interesting, this looks kind of promising, but is it a genius idea,
or is it something that is just immensely stupid and it’s just not going to work?
Today we have one of those hardware pieces here. This is the SD-WiFi by FYSETC,
a brand you’ve probably heard of before if you’ve ever been
on Aliexpress. They make mostly Prusa clones – just straight-up
one-on-one clones – but the SD-WiFi is something that is actually based on an open-source project.
On the one side, it’s an SD card – a PCB in the shape of an SD card – on the other
side it’s a micro SD card slot and basically, this is just a micro SD to SD card adapter. But
it’s also got a little ESP8266 module on it that provides Wi-Fi.
So what does that allow you to do? Well, basically, you plug it into any 3D printer
with an SD card slot (or with an adapter into a micro SD card slot) and it works like a regular
SD card. But at the same time, you can access the card through your Wi-Fi and you can read and write
to that card while it’s in the printer. So that’s what we’re going to try out today,
how well does that actually work. Is there going to be glitches? Well… I’ve done some pre-testing:
Yes it’s not a perfect solution, but is it actually worth trying the SD Wi-Fi over
something like a regular OctoPrint setup, that just runs on a cheap Raspberry Pi.
We’re going to find out, we’re going to benchmark some things and I’ll walk you through what this
does, how to set it up, and how to work around some of the glitches that occur when using this.
So, how does this actually work, because typically an SD card is just a single sender,
single receiver? Basically one-in-one-out system, and if you now take the same host and the same
receiver card and try to intercept what’s happening between that, that’s going to be
a bit of a problem. Now the thing is, SD cards have two different ways of working.
The classic one, for example, the camera I’m recording onto right now is using is “SDIO”,
that’s a specific SD card protocol, that is high speed, and high throughput, high everything,
but what SD cards also support is at least the older SDHC is SPI, which is really just
a microcontroller bus. And that’s actually how most 3D printers access these SD cards.
Now what SPI actually is: Basically it’s a landline connection and then a separate line,
that says “okay, I want to talk to you, to you, or to you”, so to that same landline
you can have as many devices as you want connected, and then you have a separate
line that says “okay I’m addressing you now”. That’s the cs chip select line.
And what the SD Wi-Fi is making use of is basically the 3D printer is telling
the SD card “Hey, I’m talking to you now!” and while the 3D printer is talking to the card,
the ESP pauses. So basically, whenever the 3D print is not accessing the card
ESP takes over and now that provides you the web service and the connectivity to the SD card.
During the entire rest of the time, this is basically just an electrical adapter
from SD card to microSD. And again, if you don’t have a
full-size SD slot on your 3D printer you can actually get one of these cool adapter ribbons,
that are basically a micro SD, or trans flash size on one side,
and just an SD card slot on the other so you can take this and adapt it back into a microSD size.
So if you have something like an Ender3, that just has microSD,
you can use this as well. Also, I don’t see that FSYETC is still making these two actively
and Big3tech, the guys that make the SKR boards, are making something that is
practically identical to these, and they also make them with a microSD size.
So, how do you set this up? There are two ways that FSYETC
provides to set this up. The first one is through an ini file you write to the SD card.
That’s one way that I just couldn’t get to work.
But this thing also has a USB plug and there’s a little switch, that you can switch between
card reader mode, the way that you use it in your 3D printer, and USB to UART.
So basically you just take a USB cable, you plug this in, and it shows up as a little serial port.
And with something like Pronterface, which is what I found actually works best for this, you can
just connect to the basically ESP that’s on this board. And then you give it just three m codes:
First m50 and then the Wi-Fi name, in my case that’s Edimax, and it echoes back with edimaxok,
then you give it m51, and then the Wi-Fi password, which is verysecurepassword, and it echoes that
back with ok, and then you do m52, and at this point, it’s going to try to connect to that Wi-Fi.
There we go, we are blinking which means, it’s connected and we get a response:
Access to SD at the Run Prompt with 192.168.178.39/DavWWWRoot,
so basically, this thing runs a webDAV server and with a webDAV server you can do a bunch of
really fun things. For example, you can take this, go to your Windows explorer and you can say “add a
network location” – “custom network location” – yes – you enter your address,
and this is going to be the “SD Wi-Fi”. Open, when I click “finish”,
and there we go. There’s our content from this SD card now accessible over the network.
And we can use this like any other drive. We can add files, remove files, rename stuff
like it’s plugged into the computer directly. So the config is done, this is all saved now,
I can unplug this and I can switch it back to the card reader, and basically,
we plug this into a 3D printer – this is still showing up as an SD card in the printer – but we
can now, whilst in the printer, also access the files that are on here.
Now that looked really easy and really straightforward, but it took me a bunch
of tries to get to this point. First of all, the ini config, that you put onto the SD card,
I could not get to work at all. Also, there is an issue with the firmware, where spaces
in the SSID or in the password are a problem, and also spaces in the file names on your SD card
are a bit of a problem, too. So I believe right now, you can upload files that have
spaces but you can’t modify or delete any. Then if you don’t have the drivers installed
for the cheap CH340 chip that’s used as a USB to the serial bridge on this part,
you’re going to have to find the driver for that, and also baud rates to connect to this
are really weird. So the bootloader, that runs on the ESP, actually needs 76800
and then for the actual config to write your config information in there it’s 115200,
so the standard baud rate, that you’d also use for a 3D printer.
But, once you figure that out, it’s really straightforward, it’s blinking right now,
so it is connected and we can access the files on here.
And sometimes Windows messes up …..
That’s just something that I did run into, you sometimes have to restart the connection,
or you have to restart the SD Wi-Fi to get it to work again.
So, what I want to find out about the SD Wi-Fi right now are two things,
that are going to be pretty relevant in practice.
First of all: How does it perform against a regular OctoPrint setup?
This is a Raspberry pi 2 plus, the Raspberry pi b2 plus, or whatever it’s called, not the most
recent version. It’s connected through ethernet to the same router that does Wi-Fi for the SD Wi-Fi.
So, how fast is it compared to the OctoPrint setup, and does it really make a difference to the
point where it’s not usable? And also, probably the obvious question is: What happens when we try
to upload new files while the printer is active? So, we’re going to try that. We’re going to slice
a fresh file right here. I’ve prepared something… When we have this mounted or set up as a network
map we can just say “export gcode”, we go to this pc and we see it as network locations right here,
and after a quick troubleshooting session you can actually just save straight to
the network drive, straight to the SD Wi-Fi, and that’s going to take a second.
You can see we’re sending it 2.3 megabits per second,
and there we go. “Exporting finished” – that took quite a while. So average send was like 3mbit
per second, and then it apparently read it back all the way at like 1.5 mbit a second. And that is
roughly what I also got during preliminary testing that I did before I started recording this video,
which was about one mbit a second, which means it’s 0.125 megabytes per second, so each megabyte
of gcode is going to take roughly eight seconds to transfer. Typically the files on this SD card
are like eight megabytes, two and a half megabytes, let me see the one that we just wrote
to it, that’s eight megabytes, that does take a while to transfer onto the SD card and back.
So let’s try if we actually just export this file to the desktop
and let’s see how long this takes to upload to OctoPrint.
We do upload locally, not to the SD card, and it’s done! That was maybe a bit over a second.
That´s a drastically different upload speed to OctoPrint or to the SD Wi-Fi,
probably a factor of about 50. There’s also a file size limit on the SD Wi-Fi,
I guess just due to limitations of what the ESP8266 can handle,
and I’ve gotten errors with 60 megabyte files already, which is i mean a large complex detailed
g-code is going to be that size your typical small parts are all going to be like under 20 megabytes.
I don’t know where that limit is exactly but so far for small stuff, it seems to be fine.
Okay, we’ve just uploaded the file to the printer, let’s do “print from SD” – that’s the one we just
uploaded, so let’s just get this printing and see if we can upload stuff to the printer while it’s
actually printing. Okay, so the print has started and the printer is reading from the SD card that’s
in the SD Wi-Fi and it’s working as expected because this is just a microSD to SD adapter.
To answer the question “Can you access or upload stuff to the SD
card while the printer is working without interrupting the printer?”
No! Like it’s not interrupting the printer but it’s also not giving you access to the
SD card at all. It’s just giving you that file “Marlin is reading from SD card”.
Closing thoughts: Who is this for? What does this do versus an OctoPrint setup? This is cheap!
You got to keep that in mind. I think I paid like eight bucks for it
which I would consider actually pretty expensive for an ESP module and the PCB, but
it’s less than 10 bucks. let’s just leave it at that raspberry pi if you get the three or four or
something that’s going to be 30 bucks or something it’s a bit more expensive but not that much
One thing I’ve not mentioned about the SD Wi-Fi yet is that it doesn’t give you any sort of access
control. There are no usernames, no passwords, no nothing. Anyone on the same network as the SD
Wi-Fi can access everything on the card. Because you don’t get all the real-time control features
of OctoPrint (temperature monitoring and setting with actually controlling the printer remotely,
starting and stopping prints, webcam feed) so it’s a lot lower stakes to actually put this
on your network unsecured. But of course, it also means you don’t get all of those
features that make OctoPrint just a really comfortable, user-friendly, and feature-rich
setup to have. You know to me this is more like an in-between solution when in my case I have my
main computer second floor and the printers are in the basement, where you don’t want to grab the
SD card from the printer, run back up to your computer, put your gcode on there,
run back down to the printer…. This is more like you do your slicing on a separate computer,
you transfer the gcode onto this, and then you just walk up to the printer make sure it’s ready
and start the print. For that, I can actually see this being pretty useful.
Now the fact that this is still a fairly buggy experience with Windows cutting out on the WebDAV
server integration. That needs to be fixed! I feel like that is both: A combination of just software,
that’s running on this, as well as being the power supply on this SD Wi-Fi board being weak,
or actually, the power supplied from the SD card slot being weak. That might be something that can
be addressed in a hardware revision, but so far this is kind of a buggy experience. Honestly, I
wouldn’t recommend anyone to actually buy this or choose it over OctoPrint, because it’s just such a
limited experience. But even though this isn’t working totally flawless yet,
I still think the way that they’re addressing the SD card is pretty interesting. Where they’re just
taking that SPI bus and just being a parasite on that bus between the printer and the SD card,
I think that is a pretty cool solution even though it has its drawbacks.
So, I hope you found this interesting as well.