Communicating directly from PC to a Photon via Wifi

Hi All

Apologies if this subject has been covered but I cannot find a close enough answer.

I want to control a machine from a PC, using serial. I dont know if a Photon is the right thing to use.

Currently we use an interface at the pc, which converts serial to current loop. The current loop connects via cables(up to 100m), to the machine. What I want to do is convert this to wireless(Wifi). Would it be possible and practical, to communicate via wifi to a Photon at the machine, then from the Photon, convert to current loop which will connect to the machine.

Any suggestions would be welcome.

You will have to consider using TCP/UDP communication and run a server/program on the machine to capture it :slight_smile:

Unfortunately I dont have access to the machine firmware and cannot change it. Can I communicate from the PC to Photon via TCP/UDP and then convert to current loop for the machine. Also being in mind I dont
want to go via the internet, but directly to the Photon from the PC via wifi.

Machine serial ----> Photon serial ----> Wifi ------> Router <------- Ethernet/Wifi <------ PC

I hope the above makes it clearer…

Also i recommended TCP/UDP as that’s what you precisely need; local and not :cloud: communication.

Yes that is what I want. I am still a newbie with the Spark/Photon so please bear with me.

A few more questions.

  1. What is the reliability of wifi? Is it prone to interference.
  2. There are multiple machines which will be controlled by a single PC. I suppose each Photon could
    have a unique ID?
  3. Has anyone done a conversion from Photon to current loop. Could I use the serial port of the Photon
    to output to current loop?
  4. Is the Photon the best fit for this application



I understand your current system is as follows

PC —> Serial —> Current Loop --> Machine

And you would like to have it as below

PC ------> (Wifi) Photon —> Serial -> Current Loop —> Machine

Ultimately you would like to have many Machines connected to a single PC through multiple photons

PC -----> (Over Wi-Fi) Photon-1 ----> Serial -> Current Loop --> Machine-1
------> (Over Wi-Fi) Photon-2 —> Serial --> Current Loop —> Machine-2

------> (Over Wi-Fi) Photon-n —> Serial --> Current Loop —> Machine-n

To your question #2, each Photon has a unique device ID and access token. You can connect to the Photon using TCP/UDP. Using TCP/UDP will be local as @kennethlimcp mentioned. You can also use Particles REST APIs to send information to Photon, but this goes over the cloud. Please check

To your question #3, please check if the link is useful. This is done for Arduino, but must be applicable to photon as well. @kennethlimcp will have better suggestions.

To your question #1, reliability can be trusted with TCP. With UDP, you need to build it into your PC side and Photon side software.

1 Like

Thanks for the info

<<PC -----> (Over Wi-Fi) Photon-1 ----> Serial -> Current Loop --> Machine-1
------> (Over Wi-Fi) Photon-2 —> Serial --> Current Loop —> Machine-2

------> (Over Wi-Fi) Photon-n —> Serial --> Current Loop —> Machine-n>>

Yes this is exactly what I would like to do, but before I start the project, is the Photon the way to go?
Is the Photon my best option for this project?

If so, I will have to order a Photon, hope i can get stock. :flushed: I only have a spark currently.
I would like to start with the first step. Are there any libraries/code samples available for Photon
for the “PC----->(over wifi and using TCP) Photon-n to serial” step?

If you can’t change the PC you could do this:

PC -> serial -> photon -> wifi -> photon -> serial -> current loop -> machine

Then you basically create a wifi serial port and if it is done right the PC wouldn’t even know.

Yes, I was considering that. Would it make the project simpler?

The only problem I have with that is, in the future I would like to use a tablet instead of the pc and there is one problem with this. You only have one usb(otg) port on most tablets and this port is also used for charging. I cannot find a solution that allows me the charge and communicate from the same otg port.


Hope you have taken into account porting of the PC code into the tablet environment. Porting challenges will depend on the language used on the PC and the Tablet OS considerations(android or Windows OS)

There are USB-Serial converters availablehe for mobile/tablet platforms. You can see a demonstration of USB-Serial converter use with Android at

Do you have any constraints to use the PC code on the tablets?

1 Like

Yes I use Embarcadero Delphi which can compile for Windows and Android without too many changes to be made. Mainly just the user interface.

There usb to serial in not the problem. The problem is when the usb to serial is plugged into the tablet, the tablet does not charge. This is fine if you are doing some communication and then disconnecting, but I want the tablet to monitor the machines permanently 24/7.

@fletch, I do have to add a caveat to @TheVelozGroup’s response to the wifi reliability question. It is true that TCP is more reliable than UDP, by design. However, wifi as a protocol is not as reliable as a hardwire connection and is prone to noise and interference. If your application cannot tolerate disconnects, then a non-wifi solution may be required.

Am I correct in assuming your PC/Tablet application can ONLY talk via serial/current loop to the machines? Also, is each machine on a separate loop or on a single loop using an addressing scheme?

In my opinion, the first issue is moving the control software from a serial I/F protocol to TCP. This has to be done by the program since the tablet will ideally not need to use the OTG connector. Any thoughts on that?

1 Like

The system is tolerant to a certain extend as we currently poll the machines and if we do not get a response we will continue and come back later. However the information is critical and must be correct. The machines are fuel pumps at a gas station. We cannot control what vehicle pulls up at the pump and how it may interfere with the comms. The main thing is the comms must not be stopped by interfere for long periods.

At present we only use a PC—>Serial---->Current Loop---->Pump. We dont use a tablet currently because of the serial port/charging problem.

Our interface hardware currently only supports serial. Moving to TCP now, with the current hardware would not gain much. I would really like to move to wireless to make the installation easier. Laying cables is a pain.

I am looking for a wireless communications platform to start with, but later could add more intelligence at the end point to handle more of the comms and minimize the comms back to the pc.

Just have to take into consideration that now still the case if you lose connection to the internet is blocked the execution of the cycle. There is an option to turn off the connection to the Cloud. But also may cause some blockage in the router. For critical applications I think Wifi connection is not exactly the most appropriate …
I think that for this type of application is the most suitable solution is by using Xbee modules.


I may be just stating the solution you may have thought about already.

Given the following may be the ideal design you may want to see:

PC/tablet -> wifi -> photon -> serial -> current loop -> machine

Given the interference on the Wi-fi, would you want consider having caching/recovery mechanisms in your PC/tablet software? If the data communication has to be close to real-time, this is not the right solution…

Other option is look at XBee as @developer_bt suggested However, you may want to use the Xbee 900 MHz version as the XBee 2.4GHz version could have the same interference issues as Wi-Fi.

1 Like

Yes I think XBee may be the way to go.

Would I use it with a standard Arduino board? I would like to make the project as compact
as possible.

Does it do mesh networking? This would make the comms more robust.

Been looking at XBee. Does have mesh networking.

Are there any boards out there which have arduino and xbee combined on one board, similar to the Spark.
Arduino and xbee start getting quite expensive.


I think Particle is compact compared to Arduino (atleast the versions of Arduino we used). Also if you decide to use cloud functions, Particle is better.

We haven’t across a single board of Arduino with Xbee. We used an XBee shield with the Spark core module for one of our prototype projects. Also, please note that not all versions of Xbee support mesh. Here is a link that may be useful

1 Like

@fletch, you may want to look at this: