To date, most of my headless embedded development has been either entirely stand-alone, or has communicated with the outside world via serial. Serial is kinda old, and getting clunky. Yes, you can use a USB to serial converter from FTDI or whoever, but then you have a USB connection that needs to have a baud rate specified, which is just strange. On the other hand, USB and Bluetooth both seem to have development models that demand that if you're going to do something new and unique that you spend $$$$$$ to create some new class of device, with vendor ID and all that associated folderol. It's nice if you're building 100,000 a year or more, but not so nice if you're building a few hundred per year. I'm working on a device that has a need for robust and graceful communication with PCs. On the one hand, data rates are not at all high -- once or twice a second the thing needs to report that some action has happened, and possibly cough up a measurement at the same time. On the other hand, they need to work in harsh environments that make wired connections expensive, so having them communicate wirelessly is a good thing. It can't be assumed that these things will have a 1:1 connection with PC's, either -- it should be assumed that up to a dozen could all be at work, funneling data to one PC. So, if YOU were going to build a device than needed to communicate with a PC in a reasonably robust and seamless fashion, and it was going to be fairly low production volume, and if wireless were desirable but not necessary, how would YOU do it? If I were to ignore the desired "wireless" part, I think I'd be looking at how the PLC manufacturers network their boxen on Ethernet. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
USB? Ethernet? Bluetooth?
Started by ●September 19, 2014
Reply by ●September 19, 20142014-09-19
Tim Wescott <seemywebsite@myfooter.really> writes:> If I were to ignore the desired "wireless" part, I think I'd be looking at > how the PLC manufacturers network their boxen on Ethernet.Bluetooth serial profile doesn't seem that bad. You drop in a chip with all the stuff already on it. You could also look at Zigbee and friends, which are like Bluetooth but simpler.
Reply by ●September 19, 20142014-09-19
On 9/19/2014 10:43 AM, Tim Wescott wrote:> To date, most of my headless embedded development has been either entirely > stand-alone, or has communicated with the outside world via serial. > > Serial is kinda old, and getting clunky. Yes, you can use a USB to serial > converter from FTDI or whoever, but then you have a USB connection that > needs to have a baud rate specified, which is just strange. > > On the other hand, USB and Bluetooth both seem to have development models > that demand that if you're going to do something new and unique that you > spend $$$$$$ to create some new class of device, with vendor ID and all > that associated folderol. It's nice if you're building 100,000 a year or > more, but not so nice if you're building a few hundred per year. > > I'm working on a device that has a need for robust and graceful > communication with PCs. On the one hand, data rates are not at all high > -- once or twice a second the thing needs to report that some action has > happened, and possibly cough up a measurement at the same time. On the > other hand, they need to work in harsh environments that make wired > connections expensive, so having them communicate wirelessly is a good > thing.Are the connections expensive because of labor costs of stringing wires (in a "protected" manner)? Or, because of electrical noise interfering with those comms? Are the distances appropriate for wired *or* wireless?> It can't be assumed that these things will have a 1:1 connection with > PC's, either -- it should be assumed that up to a dozen could all be at > work, funneling data to one PC. > > So, if YOU were going to build a device than needed to communicate with a > PC in a reasonably robust and seamless fashion, and it was going to be > fairly low production volume, and if wireless were desirable but not > necessary, how would YOU do it? > > If I were to ignore the desired "wireless" part, I think I'd be looking at > how the PLC manufacturers network their boxen on Ethernet.Don't forget the exposure to which wireless leaves your system. I.e., a wired solution means "protect the wires" (physically) and you're reasonably guaranteed continued operation. Wireless allows unintentional (and intentional) radiators to potentially interfere with your comms at any (unexpected) time. "Gee, the system stopped working, suddenly!" "When did this happen?" "Oh, right about the time we installed the arc welder..." Also, wired solutions can have an advantage in bringing *power* to these (remote) devices (instead of requiring internal batteries or locally provided power source). Here, I went to a lot of effort (labor) to run wire everywhere. I simply couldn't conceive of how to "protect" the comms from intentional or unintentional interference/jamming in a MORE CONVENIENT wireless solution. It also gave me the advantage of being able to route power to all of these remote nodes without having to hope I could find an outlet nearby (and have to see all those wall warts around the house... as well as hoping that none of them get unplugged!) You can look into other wireless technologies based on your data rates, usage profiles, etc. And, can always develop your own protocols on top of those carriers (for added flexibility or reliability). ZigBee seems like it will become a big player -- in certain markets. Also think about what other "things" you might want to talk with (alternatively, might want to PREVENT talking with). E.g., any value to a smart-phone interface to your devices?
Reply by ●September 19, 20142014-09-19
Le 19/09/2014 19:43, Tim Wescott a écrit :> To date, most of my headless embedded development has been either entirely > stand-alone, or has communicated with the outside world via serial. > > Serial is kinda old, and getting clunky. Yes, you can use a USB to serial > converter from FTDI or whoever, but then you have a USB connection that > needs to have a baud rate specified, which is just strange. > > On the other hand, USB and Bluetooth both seem to have development models > that demand that if you're going to do something new and unique that you > spend $$$$$$ to create some new class of device, with vendor ID and all > that associated folderol. It's nice if you're building 100,000 a year or > more, but not so nice if you're building a few hundred per year. > > I'm working on a device that has a need for robust and graceful > communication with PCs. On the one hand, data rates are not at all high > -- once or twice a second the thing needs to report that some action has > happened, and possibly cough up a measurement at the same time. On the > other hand, they need to work in harsh environments that make wired > connections expensive, so having them communicate wirelessly is a good > thing. > > It can't be assumed that these things will have a 1:1 connection with > PC's, either -- it should be assumed that up to a dozen could all be at > work, funneling data to one PC. > > So, if YOU were going to build a device than needed to communicate with a > PC in a reasonably robust and seamless fashion, and it was going to be > fairly low production volume, and if wireless were desirable but not > necessary, how would YOU do it? > > If I were to ignore the desired "wireless" part, I think I'd be looking at > how the PLC manufacturers network their boxen on Ethernet. >We have used serial + Zigbee, no hassles.
Reply by ●September 19, 20142014-09-19
Tim Wescott <seemywebsite@myfooter.really> writes:> So, if YOU were going to build a device than needed to communicate with a > PC in a reasonably robust and seamless fashion, and it was going to be > fairly low production volume, and if wireless were desirable but not > necessary, how would YOU do it?Bluetooth serial port profile with a module. Works with PC and mobile devices / tablets. I see more and more mobile/tablet devices being used as configuration/field display devices. Wireless connections have problems every now and then. For example in out office all the BT devices lost connection every now and then for two months. -- Mikko OH2HVJ
Reply by ●September 19, 20142014-09-19
Tim Wescott <seemywebsite@myfooter.really> writes:> So, if YOU were going to build a device than needed to communicate with a > PC in a reasonably robust and seamless fashion, and it was going to be > fairly low production volume, and if wireless were desirable but not > necessary, how would YOU do it?Oh yeah, the wired part. Ethernet with HTTP REST api. Even a low end controller can serve an HTML5 application to client for nice web browser based UI. -- Mikko OH2HVJ
Reply by ●September 19, 20142014-09-19
On Fri, 19 Sep 2014 12:43:36 -0500, Tim Wescott <seemywebsite@myfooter.really> wrote:>If I were to ignore the desired "wireless" part, I think I'd be looking at >how the PLC manufacturers network their boxen on Ethernet.Just remember some old PLCs that used standard Ethernet hardware, but you had to configure those 48 bit MAC addresses all over the places. Data transfer was just raw Ethernet frames in both directions. Later on some added UDP support, with more or less constant IP and UDP headers. By implementing the ARP protocol (a few lines of code) it became quite easy to use a Windows PC as a communication partner and diagnostics tool. For simple PLC type applications on a LAN, there is no need for any heavy TCP/IP stacks, simple request/response protocols (such as Modbus) work just fine with UDP or raw Ethernet frames. The nice thing about Ethernet is that you automatically have galvanic isolation. Optionally remote devices could be powered over the same Ethernet cable using PoE (Power over Ethernet).
Reply by ●September 19, 20142014-09-19
On Fri, 19 Sep 2014 12:43:36 -0500, Tim Wescott wrote:> To date, most of my headless embedded development has been either > entirely stand-alone, or has communicated with the outside world via > serial. > > Serial is kinda old, and getting clunky. Yes, you can use a USB to > serial converter from FTDI or whoever, but then you have a USB > connection that needs to have a baud rate specified, which is just > strange. > > On the other hand, USB and Bluetooth both seem to have development > models that demand that if you're going to do something new and unique > that you spend $$$$$$ to create some new class of device, with vendor ID > and all that associated folderol. It's nice if you're building 100,000 > a year or more, but not so nice if you're building a few hundred per > year. > > I'm working on a device that has a need for robust and graceful > communication with PCs. On the one hand, data rates are not at all high > -- once or twice a second the thing needs to report that some action has > happened, and possibly cough up a measurement at the same time. On the > other hand, they need to work in harsh environments that make wired > connections expensive, so having them communicate wirelessly is a good > thing. > > It can't be assumed that these things will have a 1:1 connection with > PC's, either -- it should be assumed that up to a dozen could all be at > work, funneling data to one PC. > > So, if YOU were going to build a device than needed to communicate with > a PC in a reasonably robust and seamless fashion, and it was going to be > fairly low production volume, and if wireless were desirable but not > necessary, how would YOU do it? > > If I were to ignore the desired "wireless" part, I think I'd be looking > at how the PLC manufacturers network their boxen on Ethernet.This is what the kids seem to be doing: <http://zeflo.com/2014/esp8266-weather-display/> ESP8266 WiFi module speaks 115200 baud serial on the microcontroller side. Mel.
Reply by ●September 19, 20142014-09-19
On Fri, 19 Sep 2014 10:54:28 -0700, Don Y wrote:> On 9/19/2014 10:43 AM, Tim Wescott wrote: >> To date, most of my headless embedded development has been either >> entirely stand-alone, or has communicated with the outside world via >> serial. >> >> Serial is kinda old, and getting clunky. Yes, you can use a USB to >> serial converter from FTDI or whoever, but then you have a USB >> connection that needs to have a baud rate specified, which is just >> strange. >> >> On the other hand, USB and Bluetooth both seem to have development >> models that demand that if you're going to do something new and unique >> that you spend $$$$$$ to create some new class of device, with vendor >> ID and all that associated folderol. It's nice if you're building >> 100,000 a year or more, but not so nice if you're building a few >> hundred per year. >> >> I'm working on a device that has a need for robust and graceful >> communication with PCs. On the one hand, data rates are not at all >> high -- once or twice a second the thing needs to report that some >> action has happened, and possibly cough up a measurement at the same >> time. On the other hand, they need to work in harsh environments that >> make wired connections expensive, so having them communicate wirelessly >> is a good thing. > > Are the connections expensive because of labor costs of stringing wires > (in a "protected" manner)? Or, because of electrical noise interfering > with those comms? Are the distances appropriate for wired *or* > wireless?Connections are expensive because the device is for use around salt water, so any wiring has to be water-tight. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●September 19, 20142014-09-19
On 9/19/2014 2:41 PM, Tim Wescott wrote:> On Fri, 19 Sep 2014 10:54:28 -0700, Don Y wrote:>> Are the connections expensive because of labor costs of stringing wires >> (in a "protected" manner)? Or, because of electrical noise interfering >> with those comms? Are the distances appropriate for wired *or* >> wireless? > > Connections are expensive because the device is for use around salt water, > so any wiring has to be water-tight.OK, then you don't want *any* exposed conductors. Even power delivery will be an issue (early in my career, I designed marine/maritime equipment -- sea breezes will eat things almost as rapidly as if they were dunked in salt water. And, of course, the inevitable spray/dunk *in* sea water) Assuming, of course, you *mean* seaside use... have you considered what the RF spectrum looks like in that environment? A fair bit of high frequency hash abounds (as all equipment operates off DC-DC converters; ship to shore radio; shipboard RADAR, etc.). What about fiber? What are the consequences of a comms failure? Attended or unattended use?
