I am not sure if this question has been asked many times before but I have searched and yielded nothing, not with the following:
I want two Photons on the Internet, each connected to a different home Wi-Fi network, be able to communicate with each other in real-time (or close to), one of them will be a transmitter, transmitting the reading of various accelerometers ( integer data) at a rate of ~100 samples per second, and the other as a receiver, receiving the data and controlling a mirror reflecting a laser beam. The transmitter would normally be at the same location as the end of the laser beam and could be kilometers away from the receiver.
I don’t think it can be done via the spark.publish(), because of the rate, right?
Is there any good suggestion how I should approach this problem?
Out of curiosity, what’s more important to you regarding your realtime-ness? Absolute lowest latency imaginable, or a reliable, continuous stream? Putting Photons aside for a moment, whatever you use you’d have to deal with potential lag spikes and lost packets over a network, particularly when kilometers are involved. If you need a constant, steady, reliable stream of data then it means you’d have to buffer sufficient data to factor in the worst case lag spike.
Another question I have for you is: are these devices going to have unique, publically addressable IP addresses? Or maybe you can open up a port in a firewall or use something like UPNP? I ask because your best bet might be to have them speak to each other directly. If they have public IP addresses I see the “TCPServer” and “TCPClient” APIs which may be of interest to you. You could use publish to broadcast your IP address until they connect to each other, that way they can “discover” each other.
Not sure if it supports UPNP, but if you can get that working then you’d also publish the port number you opened up.
With 100 packets a second I would suggest using UDP with a simple packet counter and CRC value.
For example
XXXX data CRC
On the receiver you check if the packet number is higher than the last packet received (or if its below with a certain safety margin and the last value was above some margin).
For example if last packet was #950 and next one is #49 then 99 packets was lost, but we still accept the new one.
If the last one was #800 and “new” one is #750, then its a old packet that arrived late.
This will however require a open port, known ip or a 3rd party relay station, like @Sauce mentioned.
Realtime-ness is not too important but I’d like to keep the data as “fresh” as possible. It is ok to have some lag or dropped packets due to network condition. As for the connectivity part, I agree with you the best way is to have them to talk to each other directly, however, the question is, those Photons could be well sitting behind the home router, and NAT’ed, I am not sure if there is any easy way to get them talk directly without using a relay station.
Thanks for the suggestion, I will look into uPnP, not sure how the Photons could support this, but it’s worth a try.
You can use the particle cloud to exchange ips, then send a outgoing UDP packet from the receiver to some external server that does not even have to exist, in theory that should be enough for the firewall to open an incoming UDP rule on the same port.
Let both photons subscribe to a IP event, when this event happens on the receiver, send a UDP packet to the published ip to open up the port.
Right, lasers huh... You could point a second laser beam from the sender to a light sensitive diode on the receiver. Control the second laser with the Photon, and you've got the fastest means of communication the universe allows.
(Sorry, I got carried away when I saw 'lasers' )
Be aware that UDP on the great unwashed internet is going to demonstrate all the behaviours that UDP rarely displays on a LAN. There will be packet loss (possibly significant), packets may well get reordered, thankfully duplication is still unlikely.
As others suggest, you will need to either:
Rendezvous at some agreed location (that you might be able to use subscribe()/publish()/function()/webhooks to nominate instead of hardcoding)
Open up firewall ports and instantiate inbound forwarding rules at at least the receiving location
You should certainly make sure that either your rendezvous server or your UDP receive code has extensive error checking, in case you receive some errant packets.
I know UDP isnt 100% reliable on the internet, thats one of its selling points.
No setup time, no ack/nak to keep track of, perfect for packages that are not critical.
I use UDP on my proton node to send data to a server over the internet, some packages may have gotten lost, but since its sensor data and it really does not matter if a packet or 10 is lost, so be it
I use json and a CRC to make sure packages are still ok, most errors will cause a json decode error, and if a error still happens to be valid json the 8bit crc most likely wont match.
@edwintam: If you’re talking long-range laser beams, I’d suggest a large magnifying glass or Fresnel lens in front of your receiver. That will allow a little bit of “slop” in the aiming of your laser: a beam of light hitting anywhere on the magnifying glass/Fresnel lens will be focused to a pinpoint on your sensor.
Those lasers are not for communication so no need for glasses and lens. Thanks for the pointer anyway and it will definitely be useful in some future projects.
)