Got an idea - let me know what you think:

Got an idea - let me know what you think:

There’s now these very cheap ESP8266 stand-alone WiFi modules. How about writing a firmware for the ESP8266 that act’s like the JSON Serial Port Server and then connect the serial-port of the ESP8266 to TinyG?

I’m about to finish a MQTT Client for the ESP8266, so I already got the development-system for it (but no TinyG)…

Note: Haven’t studied the details of TinyG yet, so I don’t know if it’s possible to connect the two modules.

How much do they cost?

I got two (the ESP-01) for USD 7.60…

Looking at the diagram for TinyG V8: J13 has connections to pins labelled RXD1/TXD. And the ATxmega MCU is 3.3V - perfect :slight_smile:

I wonder how those differ from the nRF24L01+ that had been out for a while. The Amazon page says the ESP01 is very new and support documentation is limited right now, whatever that really means!

The ESP8266 is standard WiFi, the nRF24L01+ is not :slight_smile:

And yes, the SDK is somewhat of a mess, but we get along anyway…

Silly me, I thought no way based on the cost. I will pull up a data sheet next time instead of being lazy on my phone. :slight_smile:

This would be awesome. You could have the interface to your CNC be Ethernet effectively. And you wouldn’t need a separate machine or RaspberryPi to drive serial.

The interface to grbl should be the same as TinyG in terms of serial (at least I would think) so if you made it work the same as SPJS (meaning it is agnostic about what is hooked up to each serial port), then this should work for both (which I would appreciate).

I think the big issue is that SPJS is actually doing quite a bit and using multiple threads I believe, so it may be difficult to get a tiny device like this to really reproduce the functionality.

I’ll hazard a guess that it could be made to work. Many folks bypass USB and use the TxRx interface in specific applications. In this thread, a user replaced the USB connection with Bluetooth. I share Frank’s concerns about porting and performance of SPJS, but I bet it could be done, once at least.
Perhaps the larger issue, over time, would be implementing an update mechanism for tinyG fw, SPJS FW, WiFi FW, etc. FW updates to these micro-controllers have some rather unique requirements. For sure, tinyG and SPJS will continue to improve and need download support. Should you pursue, it would seem that GRBL (Uno based) or tinyG2 on Due would actually be easier to develop/debug, although G2 being natively implemented in USB (rather than serial) might also add challenges.
Good luck!

I thought about this some more. Given that @jlauer ​ has already done the work to get SPJS running on the RaspberryPi, this would only save about 20 bucks or so. So, you would lose performance, but you would gain on real estate and cost. I think it might be easier to put a RaspberryPi in the box with the TinyG (or a beaglebone or an odroid c1) like john did in his recent video with the 3040 cnc

Yet another version of Michael’s thought: Port SPJS to run as an application on a spare wireless router that has a USB port. Anyone familiar with dd-wrt or tomato would recognize this as an optware-like opportunity. Configure the wireless as an APclient. Self contained power and perhaps(?) more robust tool chain.
A major side benefit of all these ideas: wireless isolation between the server (the whatever[PC, tablet] that is running CP) and the CNC machine itself. More than a few folks have fried their laptops when tinyG ground became an unexpected voltage due to wiring mishap. We are dealing (on the machine side) with numerous high voltage floating power supplies and lots of electrically noisy motors . Best grounding strategies for safety and noise are sometime a challenge.

How about using the esp8266 to set up a serial link over wifi. Then you could run spjs on whatever’s running chilipeppr. This would allow you to update tinyg firmware over the link (or get a terminal) and save the programming effort of porting spjs to that litle thing.

Be aware that the esp8266 has a max baud of 921600 bits per second, this means around 115kb/s, not sure what the bandwidth usage is for gcode sending but its worth paying attention to.