USB? Ethernet? Bluetooth?

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 
 Click to see the full signature
Reply to
Tim Wescott
Loading thread data ...

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 to
Paul Rubin

We have used serial + Zigbee, no hassles.

Reply to
Lanarcam

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?

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 to
Don Y

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 to
Mikko OH2HVJ

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 to
Mikko OH2HVJ

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 to
upsidedown

This is what the kids seem to be doing:

ESP8266 WiFi module speaks 115200 baud serial on the microcontroller side.

Mel.

Reply to
Mel Wilson

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 
 Click to see the full signature
Reply to
Tim Wescott

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?

Reply to
Don Y

Ethernet. Hands down. TCP,UDP, it's there; you decide. You have complete separation of concern with respect to wireless.

Badly. That's slightly unfair, but ... PLC vendors are largely mired in

*koff* MODBUS TCP - although this is changing rapidly.

A Beaglebone Black has more comms capability in its little finger than most PLCs have ... all week. At least a Cubie does; you'd hope the Black does as well.

This is okay; PLCs grew up differently.

Learn to write select() loops in 'C' or the equivalent in a non-.., binary language of your choosing ( the nonblocking socket handlers in the Brent Welch book using Tcl are among the most beautiful software anywhere ).

You can cut and paste a 'C' select() loop from the IBM website.

--
Les Cargill
Reply to
Les Cargill

IP67-rated female 4-pin D-coded M12 connector ...

--
Les Cargill
Reply to
Les Cargill

Microchip will sublicense a USB product ID to you, using their vendor ID, at no cost. Volume is restricted to a maximum of 10K parts, and obviously you have to use a Microchip USB part.

Reply to
John Temples

ls

u

or

are you sure?

I'm sure I read that the USB-if strictly forbids any sublicensing of IDs

Someone tried something like a kicstarter to buy an ID and share it, it was quickly shut down by the USBif if you don't need to put USB logos on your stuff a Vendor ID is "only" $500

0

-Lasse

Reply to
langwadt

Microchip certainly sub-licenses the VendorID; I've done so for customers for designs I've done with Microchip parts.

IIRC a number of other uC vendors do the same (sorry I can't certainly name others without checking)...

Hope that helps, Best Regards, Dave

Reply to
Dave Nadler

I googled a bit and you are right most of the USB uC manufactures and also FTDI lets you use their VID

I wonder how they do it? this is a part of the Vendor ID agreement

.. The company set forth above hereby applies for a USB Vendor ID Number and agrees to the following: The USB Implementers Forum is the authority which assigns and maintains all USB Vendor ID Numbers. Each Vendor ID Number is assigned to one company for its sole and exclusive use, along with associat ed Product ID Numbers. They may not be sold, transferred, or used by others, directly or indirectly, except in special circumstances, and then only upon prior written approval by USB-IF. Unauthorized use of assigned or unassigne d USB Vendor ID Numbers and associated Product ID Numbers are strictly prohibited. ..

-Lasse

Reply to
langwadt

"They may not be sold, transferred, or used by others, directly or indirectly, except in special circumstances, and then only upon prior written approval by USB-IF." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

--

Rick
Reply to
rickman

Which you can probably get if you're ginormous.

--
www.wescottdesign.com
Reply to
tim

I suspect a decision allowing FTDI and other vendors to sub-licence ID numbers from from a hope the USB standard would expand.

Otherwise some other standard such as Firewire could have been adopted as the de-facto standard for specialist equipment that requires an interface to a PC.

--
Mike Perkins 
Video Solutions Ltd 
 Click to see the full signature
Reply to
Mike Perkins

Yeah, that's my point. Microchip, NXP, etc have likely paid some fee and are on the panel so they get what they want and share it with us.

--

Rick
Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.