I was hoping anyone could share some advice. We are implementing some atomisation and are considering mesh vs standard tcp for communication between end points and repeater/gateway.
In short, we have a trolley(end point) with land cells, that needs to stop in 6 different locations to get components from augers(end point). The trolley will need to “tell” the auger when it has arrived in position before the auger starts dispensing. Based on the load cell reading on the trolley, the trolley will then communicate back to the auger “telling” it to continue dispensing or stop if out has sufficient product.
We will also need a “server” (perhaps the gateway) hosting the recipes . I suppose all endpoint can “talk” back to the gateway?
Would appreciate some advice as I am not familiar with Bluetooth Mesh and this will depend on whether we design the PCB’s to accommodate Photon or Xenon.
@friedl_1977, Particle Mesh does not use Bluetooth. Instead it uses OpenThread over LowPanWan (802.5.14). In particular, Particle Mesh uses UDP for communicating within a mesh. An Argon or Boron can communicate outside a mesh using UDP or TCP.
The application of mesh to your solution would depend on worst-case distance from the trolley(s) to the augers, how many endpoints (augers) you want connected to a gateway and the amount of simultaneous data being sent on the mesh. Mesh bandwidth is not like that of raw WiFi and node-to-node distance, number of hops, etc need to be considered.
Thank you for the info, yet another learning curve, sorry for the obvious mistake. I will refrain from asking Google and rather peruse forums
Currently we will have 8 end points, it might increase to 12 later. When ever trolley needs to communicate with an auger, it will be in very close proximity to the Auger, less that 1m. It might however not be in close proximity to the Gateway. Having said that, along either X,Y and Z axis, the furthest it will ever be form the Gateway is 10m. Every endpoint will always be within a 10m radius from the Gateway.
Initially I designed PCB’s to accommodate Photons. After I ask the all-knowing Google, I realised my mistake about assuming Photon’s support Mesh. I then designed another PCB, same functionality but can accommodate either Xenon or Argon. I am now trying to figure out the best way to proceed.
will all the trolleys and augers be continuously powered - i.e. no sleepy endnodes?
do the communications to the augers need to be wireless (presumably they don’t move)? Augers could be controlled from the central device/gateway if that were the case - I am guessing a simple signal to a motor to run or stop.
comms between nodes and gateway will best be performed using pub-sub mechanism, the trouble with UDP is that it is not guaranteed, and whilst it is low latency it is not immediate. So if the trolley said “I’m full” and that didn’t get back to the auger control or rather took a bit longer it might be a ruined recipe? In that case a better and more failsafe approach might be to use bluetooth to the auger to control the feed motor and then if comms failed it would stop.
There are lots more questions - you get the idea. You would need to implement the pub-sub yourself with the messages required. I have something working now for an application and I started with the marco-polo application idea.
Thank you for taking the time to respond to this thread.
It does indeed present some challenges to say the least, but this is what innovation is all about isn’t it We do have a current system, running on Arduino and ESP8266 combination, but since my introduction to Particle, the switch and upgrade to particle was inevitable
To answer your questions:
As the trolley can only stop at one auger at a time, I suppose the other five can sleep until such time that it is their turn to dispense.
hhmmm… YES. I hate wires, haha. Initially with the Arduino system we used serial comms, but soon upgraded to WiFi modules.In hind sight, I should have gone with ESP32 as apposed to ESP8266 but did not know better at the time. It seems to work ok. The auger stops dispensing when the trolley reaches 90% of the desired weight, then it dispenses small amounts until it reaches the desired weight.
Does pub-sub work via Particle Cloud or ‘local network’ ? I did a previous project posting RFID data to mySQL using particle.Publish and Webhooks. To the naked eye it seems quick enough, but when a lot of handshaking needs to happen between two devices in order to error check, I am not sure whether it will suffice.
Basically, I am looking for the most reliable way to connect devices, Mesh or normal wifi and TCP. This will determine the devices I use, Photon for WiFi and TCP or Xenon if I go with a Mesh network.
Many Thanks and my apologies off some of the questions are obvious.
If you don’t need to sleep (for power saving) then don’t - it just causes more issues.
There is a cost angle, I have one product that uses 1 Photon to control 4 lift motors all wired - there is a safety angle so wired was the way to go. That’s your choice - I don’t understand why you went away from wires - ease of installation?
Both - pub-sub is a mechanism to handle messages between devices or services. The mesh events are very quick/low latency but there is less bandwidth than WiFi.
IMO WiFi is not reliable/subject to interference but TCP provides confirmation of delivery, Mesh is better in terms of resistance to interference but is still on 2.4GHz band and then there is no confirmation of delivery with UDP. You can implement your own confirmation of receipt by having a reverse of the pub-sub whereby gateway sends to slaves (note a broadcast to all), if slave receives then sends a receipt event to gateway. You can make the events apply only to one device by including the DeviceID of the slave in the event and then each slave that receives will need to check whether the message was for it. A lot of the things you would want are implemented on OpenThread Profiles but not for Particle Mesh so this is a develop yourself activity!
Seems like a couple of points to consider and some trade-off’s.
1.) They don’t need to sleep. I switched from DRV8825 to TMC drivers, so no annoying squeaking sound even whiles steppers are running.
2.) I am a huge advocate for modular systems, so I designed this system each silo with its own “control” unit. It does not only control the Auger, it also opens/closes two solenoid valves, have two Analog sensors as well and two and cells and couple of LED for system status, so all pins are utilised. I understand that nothing beats wired connection, but I always consider consequence. In this case, aesthetics is very important and if anything goes wrong in comms, it is not the end of the world. i.e. In the current system, If the auger does not get the message that the trolley is in place, the auger does not dispense and the systems halts.
As I was pressed for time, I had to make the call and opted to use Mesh
I will post my project in the forum as soon as I am done. Some custom items need to be made like enclosures, so it might take a while. Thanks for all the help!!
