Using two Photons as a cable replacement system

General
1

I read the post "WiFi Direct with Photon’. I have a similar request. I work with
a piece of Test Equipment that has a Control Panel box. The CP connects to the TE
using and RS232 serial cable. I would like to use two Photons to replace the serial
cable, in the same way that Bluetooth can replace a printer cable connection to a PC.
Some details of the system are shown below along with some questions for the
community. Any ideas or comments are welcome.

Original ‘wired’ system:
[ Control Panel ]<=================================================>[ Test Equipment ]
(LCD, buttons) (RS232 serial cable)

Updated ‘wireless’ system:
[ Control Panel ]<==>[ Photon-A ] (((- WiFi -))) [ Photon-B ]<==>[ Test Equipment ]
(LCD, buttons)

Redesigned ‘wireless’ system:
[ Control Panel ]
[ Photon-A ] (((- WiFi -))) [ Photon-B ]<==>[ Test Equipment ]
(LCD, buttons)

For the current system:
Serial cable character data rate is a maximum of 115 Kbits per second.
The average serial data rate is much lower that 115 Kbps.
Cable length is a maximum of 10 feet.
The LCD is a small ‘Adafruit’ type monochrome display.
Serial messages mostly go one way: from Test Equipment to Control Panel (LCD).

Assumptions:
Photon-A,B connect directly, not through the cloud.
Photon-A,B use a TCP/IP connection.
Photon-A,B connect to each other only and no other CP’s or TE’s.
The Control Panel would be re-designed so Photon-A manages the LCD and buttons as well as the WiFi connection.
Photon-B connects to the Test Equipment using ‘Serial1’ (UART TX, RX pins).

Questions:

  1. Can a wireless ‘cable replacement’ system be made using 2 Photons?
  2. What are the biggest challenges for this design?
  3. Which Photon would be the Soft AP and which would be the client? Does it matter?
  4. Would WiFi Direct be a better choice (if it’s available)?
  5. Photon-B connects to the Test Equipment using ‘Serial1’ (UART TX,RX pins).
    It can receive a block of up to 100 serial characters at time. The serial
    receive buffer on Photon can only handle 64 bytes at a time. Can Photon-B
    manage this interface without missing characters?
2

@JWaters, here are some answers:

  1. Yes it is feasible given your data rates
  2. Designing good error recovery. Will you be expecting an 'ack" back from the receiving Photon? You could consider using UDP which is much lighter than TCP. With an ack/nak approach, you could make the transmission more reliable.
  3. SoftAP is not available for user code at this time. Your receiving Photon would run a TCPServer or UDP listener.
  4. WiFi Direct is not supported at this time and is not required IMO
  5. If you compile locally, you can change the buffer size. Your application can create its own buffer and just receive into that using the new serialEvent() function for receiving data.

It all comes down to how you manage the serial data stream. You’ll just need to try it out! :wink:

1 Like
3

Thanks for the quick response.

On point (2) the protocol used over the serial cable has an ACKs built into it. The Test Equipment always gets an ACK back from the Control Panel for every message it sends, or it re-sends the message. Most messages go from TE to CP (LCD data). These messages are always ACKed.

So it sounds like Photon-A (Control Panel) would run the TCPServer, Photon-B runs the TCPClient. Or if using UDP, use them like a peer-to-peer connection. If using UDP this way will data always arrive in the correct order (no out-or-order packet delivery)?

I plan to compile locally, so I will try out the larger buffer size. Does the reference site talk about how to create my own buffer for the UART?

Thanks.

4

Also, I haven’t found any sample code for Photons being used this way (with a private wireless

connection). Could anyone point to any sample code (UDP or TCP based) that would show how this can be

done between 2 Photon systems?

5

With UDP you can’t guarantee the order of packets. In practice, and especially with a simple enough network topology, they’re basically always in order, but there’s no algorithm ensuring this is the case.

That’s where TCP excels, making sure something gets there in one chunk (i.e. data is in the same sequence and not missing anything) just as you intended.

However, you intuition as far as server/client assignment is correct. In fact, you could just create a UDP server on Photon-A and then a UDP client on Photon-B.

6

@JWaters, you may not find any code samples but you may find code that shows Serial to TCP and some UDP data transfer examples. I believe there was a topic on using UDP multicasting for a Photon to announce itself to other Photons. There are plenty of TCP client/server examples to draw from as well. :smile:

7

Start digging here!

8

So I overlooked a point in the first response from peeykay123. If the Photons can’t act as a SoftAP

and WiFi Direct is not supported, then I will need another AP somewhere to connect the two Photons.

For my system it would be preferable to not have this requirement.

It seems like if I replace Photon-B (the one connected to the Test Equipment) with a SoftAP device,

like the ESP8266, Photon-A could remain as my Control Panel device (for the LCD).

I’ve seen where the ESP8266, connected to a small microcontroller, can act as a web server. Would this

setup work and remove the need for a separate AP?

(Control Panel/Photon-A/client) <<< WiFi >>> (ESP8266+micro/SoftAP) === (Test Equipment)

Would this work with a UDP connection?

9

The short answer to your question is: Would it work with a third party that acts as a router AP? Yes, probably. But now we’re already moving towards “why not use hardware better targetted for this particular application?”

BUT… <soapbox>

To be honest, I’m not sure if a Photon/Core is the right product for your particular application. It sounds like you want a peer-to-peer radio connection, no WiFi. There are plenty of other MCU/SoC manufacturers out there that can provide a low level radio link with a UDP API ready-to-go.

While I think the Photon hardware can physically do it (i.e. the technology exists) the problem is you need to find some finite sequence of symbols (i.e. firmware) that will make the hardware behave as you want.

But the Photon was designed from the ground up with WiFi in mind, so if you want to use a Photon peer-to-peer you’re going to be fighting an uphill battle, unless there are others out there that are also deeply interested in this application and willing to help carry the torch.

TLDR it would probably be faster for you to build this solution using products designed for peer-to-peer. Just my 2 cents!

1 Like