6

I work for a medical company and we produce systems which typically are composed by a data-acquisition device connected via USB to a PC where some desktop application runs so that it can control the hardware and display the connected data in realtime. Our desktop software platform is C#/.Net/WPF.

We are considering to build a prototype where a Pi would control a handful of sensing devices, pre-process the data, and send this data to the PC or laptop. The Pi would also respond to commands and requests sent by the PC application.

I have looked around, but apparently the preferred way for us - direct USB connection - is not available, since the Pi USB is a "master".

I got confused, because I had the impression that it should be easy to connect PC and Pi via physical cable so that they could "talk" to each other, so the questions are:

Is there a way to physically connect Pi and PC so that applications could talk to each other through this connection?

If physical connection is not feasible, what is the most direct way to connect a PC and a Pi for the described purpose?

By "direct" I mean least dependent on external infrastructure (modems, routers, etc.) which might be non-existent on site.

|improve this question
6

Two common and fairly flexible methods would be:

  • Direct ethernet connection. This requires you have an ethernet jack on the PC that is not otherwise in use. You connect that to the Pi, and you can create a subnet with two nodes. Once upon a time this required an ethernet "cross-over" cable but generally contemporary jacks, including those on the pi, do not. This provides a relatively high bandwidth (100 Mbps) compared to the second option, and allows you to use familiar network protocols and applications. Since it is a network layer connection, it also means you can have various forms of independent communication occurring simultaneously without implementing anything special. E.g., You can have whatever client-server stuff is necessary running for your general purpose and log into the pi at the same time.

  • UART. You can use a USB serial cable to connect the PC to the serial port pins on the pi. This option is much slower (< 1 Mbps) than ethernet and, unless you write some fancy software, is awkward to use for more than one purpose at a time.

|improve this answer
  • For direct ethernet connection would require you to change the PC to static IP address every time or is there a way around it? – bakalolo Aug 30 '18 at 7:43
  • @bakalolo Not exactly. If also connected to the internet via a WLAN, the PC would have two IP addresses, one associated with the wifi adapter provided by the WLAN router, and one with the ethernet jack for the private subnet used by it and the Pi, which might as well be static since you can use whatever you want within normal private network -- but do not overlap them with the ones used on the WLAN. BTW, you can also route the Pi though the PC to connect it to the internet this way. – goldilocks♦ Aug 30 '18 at 12:57
5

You can run this as a serial USB device (FTDI-based cable) to GPIO pins

http://elinux.org/RPi_Serial_Connection

or you can use the raspberry pi in OTG mode to run the PI as a USB peripheral. The raspberrypi zero fits this form factor very well and I think the design intent was to have folks using the zero as a USB peripheral.

https://learn.adafruit.com/turning-your-raspberry-pi-zero-into-a-usb-gadget/overview

The OTG solution is much more elegant and will impress your friends more in my opinion

on another note (being a medical device engineer myself) as regards to software and computer systems validations, please understand that if your "prototype" will be used to collect any sort of quality data (design, process monitoring, etc) it will need to undergo some sort of assessment based on the 21 CFR part 11 with regards to software validation.

|improve this answer
  • I have actually used a raspberry pi for remote monitoring and verification of an offsite piece of equipment (at a manufacturing site). It is outside the scope of this site but message me and I'd be happy to point you in the right direction with regards to staying FDA compliant with your system – bk79 Aug 16 '16 at 22:59
  • 1
    Note that the OTG gadget route is the equivalent of either an ethernet or serial link, so it doesn't actually offer anything that other models of pi do beyond the fact that you can use a USB -> microUSB cable for it. – goldilocks♦ Aug 17 '16 at 2:11
  • OTG is also available on the Compute Module, which may be more suitable for building into devices. – pjc50 Aug 17 '16 at 9:21
  • @goldilocks thanks for that tip - I did not realize you could only run serial over USB OTG. Thanks for clearing that up for me. I have to imagine in the near future someone will have HID and MSD figured out - isn't is just software configurations? But for OP, this might be too late in development for your project. – bk79 Aug 17 '16 at 12:06
  • At the end of that adafruit tutorial it has the other device modes listed with the disclaimer that this is all experimental learn.adafruit.com/… Am I missing something here? These would all be USB gadget mode (i.e. not host) correct? and not serial / ethernet only? Personally, I've only used the serial and ethernet modes for the zero, I'll try out some others this weekend perhaps Further thought process on the details going in the tutorial seem to be here: github.com/raspberrypi/linux/issues/1212 – bk79 Aug 17 '16 at 12:16
5

I'd go for Ethernet, either point-to-point or through the router. Why?

  1. It handles transmission errors, correction etc. "out of the box" - I guess it's important for medical purposes (your heart rate is now doubled because one bit changed - whoops)
  2. It can be long (up to 100 m - and can be extended)
  3. It's cheap and commonly available
  4. You can get decent quality shielded cable which would (help to) get rid of noise (some devices like an old TV or iron are real problems)
  5. If you write some kind of REST API for your product, you can connect easily with C# - and with other languages too!
  6. If you change your mind and don't want RPi anymore - you can migrate easily - just by implementing the same interface (if it's REST - it's even easier, but you can go with sockets as well)
  7. If you need wireless - plug in an USB adapter and you are ready to go.
  8. A lot of existing stuff already works with it - you don't have to start from scratch - by immibis
|improve this answer
  • 8 (or 5b). A lot of existing stuff already works with it - you don't have to start from scratch. – immibis Aug 17 '16 at 7:11
  • Regarding option 7, which seems the more universal one (since a given random PC might or might not have a spare ethernet port, but most probably will have a USB port), do you have any example link? Say, for a commercially available adapter, or a tutorial on how to use such adapter...? Thanks! – heltonbiker Aug 17 '16 at 20:06
  • @heltonbiker RPi compatible adapters (they work with PC's too): elinux.org/RPi_USB_Wi-Fi_Adapters , most of them should work plug-and-play. Installation instructions are available there too. – Mark Aug 18 '16 at 6:09
2

The simplest, fastest, and probably most reliable connection would be a point-to-point Ethernet cable.

Alternatively a serial to USB dongle. The serial end could be on the Pi from the UART (pins 8/10) or on the PC end with a suitable RS232 adapter.

|improve this answer
-1

You can raspberry pi with mobile only using some adaptor which can work as two way communication. There is no any in built facility in raspberry pi to place two way communication modem. GPIO and serial port is not enable for this facility.

|improve this answer
-3

If you want a wireless approach write a nodejs socket app

|improve this answer
  • Welcome to Raspberry Pi! Whilst this may theoretically answer the question, it would be preferable to include some explanation here to make it a more useful answer. – Ghanima♦ Aug 17 '16 at 1:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.