How to wirelessly send signals from 15 machines to one central receiver? - Page 1
Forum section: electronics / projects

author: Corporate666
author_rank: Unknown
timestamp: April 06, 2018, 04:09:54 am
content: I have a friend who works at a company that has various industrial machines in a small-ish factory (all within maybe 30 meters of each other). The operators of the machines use a numbering system and write a number on a dry-erase board attached to the machine so the worker ending their shift can let the worker starting their shift know what the current status of each machine is. It also allows management to do a walk-around and see what the status of all the machines are. We're talking *extremely* simple here, like "1 = All OK. 2 = need calibration. 3 = needs service. 4 = machine offline. 5 = other".It would be better to have an automated system where a small box is attached to the machine and the worker presses a button and one of 5 LED's light up to indicate machine status. At the same time, the machine would wirelessly broadcast machine status back to a central receiver in the management office (30 meters from the furthest machine) so that they would have a way to see the status of all machines at any given time.If the receiver were a computer displaying machine status on a screen, it could track the status of each machine on an ongoing basis and reports could be produced showing how often each machine was in "OK" status vs needing service, offline, etc. This would be valuable information.The company is owned by a European conglomerate which has very strict rules about data security and networking - so it's completely out of the realm of possibility to stick something like a Raspberry Pi on each machine and connect them using WiFi - it's just not going to happen, ever. It's also not going to happen where each machine would be wired back to the management office. They do want something "secure". I suggested those simple 433Mhz key-fob transmitters and cobbling them into a box with some buttons and lights. On the receiver end, I thought the RF receivers could simply be tied into something like a Raspberry Pi to monitor the incoming signals, and then just save the data as XML or a text file locally on the device, and have a web server running on the R-Pi which can only be accessed from the screen directly attached to it.But I would like to know if there's a better way? Cost, simplicity and ease of implementation are major factors on this one.Plot twist: The machines have industrial controls on them. I was at this shop visiting my friend recently and looked at the manuals for the control and saw that various data is exposed through the control. Most of it simple on/off outputs, but some of it can be exported from the machine over a serial bus. Let's say the scope of the project expanded to transmit more than just a handful of ON/OFF signals between the machines and the nearby office wirelessly and instead to transmit small amounts of data periodically (like hundreds of characters per minute type of throughput). What would you then suggest to achieve the wireless portion of it, given that WiFi is still an absolute non-starter and that data transmissions would need to be encrypted and the whole thing needs to be simple, quick and easy to implement? I have my idea - but curious to hear what other more knowledgeable people think.

author: Phoenix
author_rank: Frequent Contributor
timestamp: April 06, 2018, 05:01:44 am
content: A microcontroller and 433/866/905 ISM bad transceiver should make short work of it. Could also use a single chip RF SoC.I'm not sure about encryption, but a custom protocol where data is sent with an ACK response (and retry if needed) is pretty easy with CSMA/CA.

author: TJ232
author_rank: Frequent Contributor
timestamp: April 06, 2018, 05:08:12 am
content: In similar factory floor production environments setup I have used with great success encrypted radio transmission in ISM bands (433 and 869Mhz).Max distance was about 600m LOS so for robustness and high stable data transmission data rate was choosen low at 9600bps. It was more than enough to send all the desired status information's from about 238 production units back to the central HUB where was processed and displayed on a 2x2m screen.Before doing anything else if you want to use radio transmissions in a factory environment it's do to a full site survey, including full radio spectrum check. You might find a lot of nasty interefereces so finding the right RF Channel for your tranceivers it's a very important task.Ah, almost forgot about, ask for a proper factory detailed layout plan, remember a story that was giving us nighmares, in a factory installation all where working nice and dandy but not on Tuesdays and Fridays. It was a crazy thing until we find out that they missed to inform us that in the next building is a big 4500 ton punch press working full steam, guess when?

author: TJ232
author_rank: Frequent Contributor
timestamp: April 06, 2018, 05:12:43 am
content: Quote from: Phoenix on April 06, 2018, 05:01:44 amPhoenix has 100% right, you want to implement a proper addressed, reliable datagram protocol with acknowledgement and retransmission.

author: georges80
author_rank: Frequent Contributor
timestamp: April 06, 2018, 05:36:02 am
content: Digi makes some nice compact wireless modules (accessed via uart) that support encryption, meshing, retries, etc etc. They run on 3.3V. ISM band.cheers,george.

author: Corporate666
author_rank: Unknown
timestamp: April 06, 2018, 05:45:44 am
content: Thanks for the responses so far.My idea for the expanded system was putting a small microcontroller in the button/LED box with an ISM transceiver talking back to the receiver in the management office.I've never worked with pre-built ISM transceivers before, however, and my immediate concerns were that now you either need to buy something that supports negotiating transmission time-slots with 15+ other transceivers also potentially transmitting, or you have to custom-write your own software to handle that. Which is very much outside the scope of a product I can tell my friend to buy online and we can cobble something together in an afternoon, and if I start writing custom code and making custom PCB's, it can quickly kill the "low cost" requirement.The Digi recommendation above is interesting, I will check it out. Any comments on the software difficulties of having 15 or so transceivers all possibly trying to communicate? Something inexpensive that handles that problem would be ideal, since I really don't have much time right now to devote to doing something custom for a friend and I know he doesn't have much beyond a shoestring budget for this.

author: PartialDischarge
author_rank: Super Contributor
timestamp: April 06, 2018, 06:12:24 am
content: I have experience in managing plants so I would propose a solution that is more capable and supports future needs in the production system (cause there will be, rest assured). Like they may want to inform of the real time state of the production, they are probably using paper for all of this stuff right now.Privacy concerns: use a wifi router that is not connected to the internet and connects to a single computer, easy and cheap. Any future improvement in the shop floor will benefit from it.In each machine place a cheap android tablet that connects to this wifi 'isolated' hotspot. A web browser is enough here, no special app needed here.In the computer connected to the wifi router and not connected to the internet, place a Apache server, a SQL database (in a shared disk for example) and have someone program a PHP server webpage with all the formularies needed. A formulary for a machine state (1,2,3,4...) takes an hour to program.I know that this solution is not your initial idea, however believe me that this solution could take the same or less developing time with MUCH higher returns.

author: Corporate666
author_rank: Unknown
timestamp: April 06, 2018, 06:18:36 am
content: Quote from: MasterTech on April 06, 2018, 06:12:24 amI don't disagree with you on functionality, but there is exactly zero chance that this can happen. As soon as words like WiFi, database and server are mentioned, the corporate people necessarily need to be involved, and there is an immutable rule that you do not set up any sort of network other than that which is provided by corporate and you do not create any sort of server other than that which is brought and installed by corporate. It doesn't matter that it's a private WiFi network unconnected to anything but the internal network of machines... it wouldn't be allowed and if it was done anyway, people responsible would be in serious hot water (possibly terminated), so they would never ever do it.

author: Phoenix
author_rank: Frequent Contributor
timestamp: April 06, 2018, 06:50:50 am
content: Quote from: Corporate666 on April 06, 2018, 05:45:44 am15 is bugger all!CSMA/CA - check for carrier signal (e.g. nRF905 has a carrier sense pin - simple) for a period of time (few ms) - if air is clear transmit else delay for psudorandom period (a few ms), once transmitted wait say 20ms for Ack if no ack delay for psudorandom period (a few 10s ms) and try again. Your on air time is going to be bugger all e.g. nRF905 transmits at 125kbps so risk of continuous collisions is incredibly low.A lot of transceiver ICs also have built in addressing and CRC. The RXer will have a different address to the TXers, but each TXer can have the same address if they then have an additional device ID contained in the message to possibly simplify the firmware since there should only be one (or very few if a TX collision) units listening for ack any any one time.

author: TomS_
author_rank: Frequent Contributor
timestamp: April 06, 2018, 07:59:52 am
content: Quote from: Corporate666 on April 06, 2018, 06:18:36 amIt sounds to me like people "creatively re-interpreting" corporate rules in order to circumvent those rules.There is really no difference between a wifi network and "simple 433MHz key-fob transmitters" with devices either end sending data back and forth other than the capability of those devices to do bigger things, like open a web page, for example.Dont get me wrong, it sounds like a project I would love to work on myself. But saying you cant setup a private "wifi" network with a "server" and "database" when that is essentially exactly what you plan to do, only with products that wouldnt traditionally be described as such, does sound like youre being a little "clever".But hey, at the end of the day if they sign it off... whos complaining.

author: David Chamberlain
author_rank: Frequent Contributor
timestamp: April 06, 2018, 08:01:09 am
content: "European conglomerate which has very strict rules about data security and networking" solution roll own security to avoid the rulesDon't get your friend fired

author: David Chamberlain
author_rank: Frequent Contributor
timestamp: April 06, 2018, 08:02:30 am
content: SNAPQuote from: TomS_ on April 06, 2018, 07:59:52 am

author: Corporate666
author_rank: Unknown
timestamp: April 06, 2018, 08:40:24 am
content: Quote from: TomS_ on April 06, 2018, 07:59:52 amI would strongly disagree that there is no difference... it's the same difference between the key fob that unlocks your car and your cell phone connected to your home WiFi router. In the case of the key fob transmitter idea, the data transmission is essentially one-directional and encrypted. The transmitter isn't listening for incoming signals, nor can it respond to them, so there's nothing to hack. The receiver is just waiting for one signal and writing a log to a text file, so it's not susceptible to hacking either.If the above was done via WiFi, both the transmitters and receivers are open to a whole slew of hacks, attacks and insecurities. That's the reason for the corporate policy which would forbid using WiFi in this scenario.These policies are quite common. They aren't so draconian that they are spelling out limits on radio frequencies and emission strengths. They are meant to stop satellite divisions of the company compromising security because some manager thinks they know IT when they really don't, and so they decide to plug in a WiFi router because it's easier than running ethernet, or they set their password to "PASSWORD"But I agree, it does seem like a fun project... wish I had more time to work on it, but I think I'll have to keep the initial revision very simple so he can do this himself with off-the-shelf repurposed parts.

author: David Chamberlain
author_rank: Frequent Contributor
timestamp: April 06, 2018, 09:36:05 am
content: I would strongly disagree with your disagreement that their is no differenceAnd before I go further I would like to say I am also very nostalgic for a time when security and electrical compliance were a non issue and you could hack together an industrial solution for a friend and be called a god and given a few crates of beer for your trouble. Unfortunately or fortunately we don't live in those times now.Just because data is one way and encrypted does not make it safer, in fact it can be much less secure than two way cryptographic links. If it's one way traffic then you have no method of performing a key exchange... so you have to hard code the keys in to the devices or use rolling codes, both potentially suffer from replay attacks.If you use a symmetric key then consider the key security and what would happen if an adversary were to gain access to one of your transmitters? Could they read the prom get the key and be able to inject bad packets with a hacked device?I would argue (if you intent is security through obscurity - AKA not security) is to use a Nordic or other transceiver then any one can buy those, They can look at the setup between your micro and the radio and get keys and so on.Diffie Hellman key exchange between the slave and master points and while that is easy to understand from an academic perspective I would not want to be the guy to implement it say - hand on my heart - it was perfect first time.BUT if as you say the company only cares about security if it's data transmitted over WiFi ( a ridiculous statement to be sure) then anything goes.The old adage here is that rolling your own security is asking for trouble.

author: Rerouter
author_rank: Super Contributor
timestamp: April 06, 2018, 10:00:00 am
content: To avoid the security experts. Limit your scope and keep it simple.If the machine just needs to output, then dont built a connection to the expensive controllers RX. Equally have a resistor between your device and the controllers TX, things go wrong and you dont want to overdrive it.Have the nodes and the reciever be a micro. Use state machines with timeout, packet checking and heavy input sanitation. And just have it spew out 1 way data to whatever your display is. Keep the encryption in that bubble away from the rasberrypi or pc. With no way to go back and request. Only read.

author: Nusa
author_rank: Super Contributor
timestamp: April 06, 2018, 10:10:53 am
content: A "network" is formed when you connect things. The method of connection is merely a technical detail, not what defines it.When clients are connected to a central point, that central point is called a "server".When you save data for creating reports, you've created a "database".The words are all very generic. You can't say a security policy is restricted only to the familiar setups unless the policy itself says exactly that. Or there is a clarifying memo from corporate that covers the situation.Since you say jobs could be on the line if you misinterpret the policy, caution may be called for.

author: David Chamberlain
author_rank: Frequent Contributor
timestamp: April 06, 2018, 10:25:14 am
content: Quote from: Rerouter on April 06, 2018, 10:00:00 amYou can't avoid us, we are everywhere and have very high consultancy fees to recoup

author: Avacee
author_rank: Unknown
timestamp: April 06, 2018, 10:40:04 am
content: Going back the OP's problem I'm confused - the requirement seems to be for machine state information to make it from the machines to staff+management and it doesn't matter how it's done and therefore doesn't necessarily need to be wireless.Since wireless options actually appear to be out along with cables back to the management office then I'm racking my tiny confused brain for other ideas and came up with running cables from the machines to a unit (eg pi/arduino) on the shop floor that can write to a removable media that can then be transported to the management office as required - even if it's paper since sd card/usb stick/etc sounds likely to be ruled out due to being an attack vector.Not real-time but no real-time requirement has been mentioned, only assumed.Another option for seeing machines states is for the previously suggested LEDs to be duplicated in a location they can be seen. ie above the machine, cabled back to the whiteboard, both, a.n.other, place etc ...

author: David Chamberlain
author_rank: Frequent Contributor
timestamp: April 06, 2018, 11:06:01 am
content: Quote from: Avacee on April 06, 2018, 10:40:04 amI wholeheartedly agree, the collective is solving this problem. I think we can all agree the real security threat in this model is the machine operators - god only know what they are telling their partners, children / friends about the code they got on a machine today. "3 = needs service" could be used as a coded message to the enemy to STRIKE NOW!!! ( the iron was hot, but now it's cold due to the machine being off)The solution is simple, replace all human operators with robots that run over WiFi... oh wait, that could be a security problem. How about Robots running over WiFi that write error codes on whiteboards for other robots to read?

author: nali
author_rank: Frequent Contributor
timestamp: April 06, 2018, 01:07:55 pm
content: I would be tempted to use something like one of these as a quick n dirty solution.https://www.lairdtech.com/products/bl652-ble-moduleEach machine can be a BLE beacon, the management console can scan them and drive LEDs. It shouldn't take too long to whip up a simple bit of code using the inbuilt BASIC.

author: David Chamberlain
author_rank: Frequent Contributor
timestamp: April 06, 2018, 01:13:58 pm
content: @OP were just having a little fun but the idea is that not all problems need engineering solutions.In the scenerio you described, where a manager walks the shop floor looking for probelms, she or he is really performing other tasks at the same time.. interacting with personal is a big one. Interpersonal relations with staff in a poisitive way. Making them feel like they are not just machines or robots like i joked about.

author: TK
author_rank: Super Contributor
timestamp: April 06, 2018, 01:31:58 pm
content: You can use RFM69HCW modules (ISM band). You can define a network with multiple nodes and the module handles all the RF stuff including retransmission. Max output power is around +20dBm.http://www.hoperf.com/rf_transceiver/modules/RFM69HCW.htmlThere are breakout boards available from SparkFun and Adafruit.

author: grifftech
author_rank: Frequent Contributor
timestamp: April 06, 2018, 03:13:39 pm
content: 5 LAZERs per machine aimed at a chart taped to a wall.

author: rstofer
author_rank: Super Contributor
timestamp: April 06, 2018, 03:37:08 pm
content: Quote from: David Chamberlain on April 06, 2018, 01:13:58 pmThis is just such a case! The problem likely can't be solved to the satisfaction of 'corporate'. No wireless scheme is more secure than any other and WiFi is probably the most developed. If that isn't satisfactory and wire isn't an option then carrier pigeon is about the only thing left. And they can probably be bribed!So, don't solve it! If it becomes a real requirement, the boundaries will change and the project will become workable. At the moment, nobody cares enough about the problem to force a change.We used to have some 3 color light 'wands' on our NC machines. Green - Up and running, Blue - Tool change or part change, Red - Down for maintenance. These were visible across a very large shop.

author: BrianHG
author_rank: Super Contributor
timestamp: April 06, 2018, 03:42:58 pm
content: Quote from: grifftech on April 06, 2018, 03:13:39 pmOk, if we are going down this route, use audio, ultrasonic modems.

author: ejeffrey
author_rank: Super Contributor
timestamp: April 06, 2018, 04:49:23 pm
content: So I think it is worth taking a moment to reconsider the purpose and scope of the project.In particular, what are you *really* gaining over the white board solution? If it is just the convenience of management walking across the floor of a small factory and looking at the status of 30 machines, I would say there is no reason to implement any electronic system. Just keep using the white boards. They are simple, reliable, and if they "break" any joe shmoe can get replacement parts at the nearest office supply store.If you want to collect more data, do the collection automatically without intervention of the operators, store it over long periods of time, or make it available to do trend analysis, and there are real business benefits to that, then let that define your implementation and how much you are willing to spend to develop *AND SUPPORT* it.Managers are really good at looking at a primitive solution that works and saying "man, it would be cool if we had XYZ instead". Engineers are really good at saying "XYZ should be easy and sounds like a fun project to work on". You have to try to honestly evaluate whether it is actually worth it.