Hello im new to mesh network concepts. I have played with photons etc and borons and understand the publish / subscribe concepts. I’m getting ready to start a project which requires a xenon to display real time information from a sensor on a near by argon. It needs to be pretty real time. ie displaying the values of say a sensor. I need a point in the right direction on how to achieve that conceptually. Again the data needs to be pretty real time ie a meter showing real time data from a flow sensor. Or even lets just say for simplicity i need the xenon to access the “near” real time input from a potentiometer from a boron. Thanks for any tips. Again i understand the publish and subscribe concept but that doesnt seem to apply for fine real time communication. Thanks
Welcome to the community. Real time is a complex topic. You may need to define this more specifically I.e. response in less than n milliseconds etc.
This being said, setup a simple test with xenon starting a mesh subscribe and printing result and the argon doing mesh publish and test. You will need to serially connect them in this test so you can send a timing mark from one to the other such as a request to send from xenon and then check how long it takes to receive the message
Post some code for comments
Building on @shanevanj reply. It sounds like you are conceiving a potentially over complicated and “fragile” solution. I would consider using a Xenon where I needed a battery powered solution - but making a long lasting battery powered solution is a lot more complicated that a powered solution. If you can power something then maybe a wired rather than wireless solution would be quicker and cheaper to implement - would deliver on real-time and might be more robust in your environment?
I think step one i just need to wrap my head around the higher level concepts of mesh network communication. I’m not a super advanced programmer but have messed with enough to be dangerous.
I’ll experiment with mesh publish / subscribe and see how quick it is as soon as my xenon gets here. I just originally assumed it was pretty slow. As for your question of speed im just looking at making a remote user interface which will show feedback. This is just a example not the actual application but for instance say you turned a knob on the other system id like the display to show the feedback at a “generally” relatively acceptable rate wouldn’t have to be absolutely real time perfection.
As for Armor,
Thanks also for the feedback. The one key that this current project needs is for the display to be wireless. I cant get into the details for it but I would have loved if it could have been wired.
@S2Jesse, what you are proposing - a Boron in a mesh with a single Xenon - will provide decent performance for your “real time” display. @armor suggestion of doing a mock-up to get a feel for the performance is a great idea.
Mesh is not unlike a LAN but without wires where every node (typically a Xenon) both receives and forwards messages to its neighbours on its way to a gateway. The Particle mesh uses the Nordic nRF52840 since it supports the IEEE 802.15.4 low-rate wireless personal area wireless network protocol on which it runs OpenThread to create mesh networks based on IPv6. The nRF52840 implements all this in the 6LoWPAN using the 2.4GHz spectrum which, as you may know, is quite busy (WiFi, BLE, Zigbee, etc.), providing a maximum bitrate of 250Kbps or roughly 20-25KBps. This does not speak to any latency related to DeviceOS overhead in creating, sending, receiving or decoding the messages.
Particle’s implementation of their Mesh uses broadcast UDP packets to minimize protocol overhead but without the verified reception that TCP provides. So a Xenon publishing a message to a Boron is not guaranteed that it was received unless the programming on the Boron is such that an ACK is published back to the Xenon which is waiting for it.
Now, add many Xenons in the Mesh, each trying to publish to the Boron, each expecting an ACK and you have a recipe for a busy Mesh network. This is why @armor asked about how “real” what your “real time” and why with a single Xenon I believe you will be pleased with the results.
Ok perfect thanks. I actually got my boards and tried it. It works nicely. I just did a test with a potentiometer on the argon and an analog out led on the xenon. I only send the info when the values change and seems to work nice and responsively. However I do get a little slight glitch here and there. I get a tiny little green blip on teh status led when the glitch happens. I wonder what that is. some corrupt data maybe?
How do you do that?
When you send everytime the value only changes the slightest, you may be still producing tons of traffic which may (maybe?) overwhelm the network at times.
You could try adding some delay (e.g. 10-50ms) when you detect a continous change in value.
Adding a threshold may also help reduce the impact of ADC jitter.
Ina addition to @ScruffR comments - some potentiometers do not allow for a “clean” signal as they are mechanical devices and dirt or corrosion with affect the output signal at the centre pin. The argon is fast enough to detect any “bouncing” on a I/O due to dirt or a poor contact on the pot. So add a small decoupling capacitor from the centre of the pot to 0V and another to +VCC to smooth any spikes and then use the delay in readings as mentioned