a computer has to communicate with a remote unit. The length of the link (optical fiber) is about 500 m. I need to transmit data in both direction and a video stream from the remote unit to the PC.
This is my idea:
On the remote board I use a Rabbit Module or something else with Ethernet capability. Thus, I may open a data stream on a port and a video stream on another.
Some questions:
1) How to convert the video signal (from a camera) to a digital video stream in order to send it over the Ethernet? I'm looking a stand-alone solution, the Rabbit Module has to manage the whole board and it can't spend time with the video.
2) What equipment do I need to create an Ethernet link between a PC and the board on a fiber?
Do you have other ideas? If you need further details to suggest me something, please feel free to ask!
You're right, but the user might want to use a special camera for his own purpose. In this case the video output must be encoded and transmitted over the Ethernet.
The board is not designed yet. So I can select what I need. As first attempt I would use a Rabbit Core Module with Ethernet on-board. So I have to interface the eth connector to the fiber.
Great :)
What kind of details?
Some inputs:
the host sends to the remote board a string of about 50 bytes. This contains commands or configuration data
the board receives the commands, decodes them and moves motors or other actuators
into the remote unit there are several sensors and data acquired is sent to the host. The video stream is also sent.
The PC has two monitors. One for the camera and the other to display sensors data.
On a sunny day (Sat, 01 Sep 2007 17:14:18 GMT) it happened Marco Trapanese wrote in :
mm, I cannot help you with the optical interface board. But somehow you will have to specify what sort of cameras you want to connect (support). There are several types, from analog, to firewire, to USB, to ethernet, to other digital standards. To send info via ethernet you very likely need some sort of compression, and if that is not in the camera, then 'the board' needs to have a powerful enough processor to do that, faster then 500MHz I'd say. This also depends on picture size and frames per second, quality etc..
Once it is TCP/IP, the control data can be send to one server running on the PC, the camera stream to an other server. So 'the board' needs much of the properties of a normal PC, and you need programing experience to write the required soft, both for the PC, and for 'the board'.
I have done this thing, except for the optical part, with cameras and camera control, as I was free to choose my own format, and have no problem writing soft like that, it was not much work. Maybe you need to look for an embedded system for 'the board' that runs Linux, as then you have compiler and library support.... I wonder if 'the board' can be a normal PC with a PCI card to interface to the fiber? That would give you firewire, USB, ethernet, etc interfaces and drivers for different cameras. Else drivers will be your biggest problem. So more details on what type of cameras, what you can do on the software level, The control part can be really simple I think, the smallest embedded system could do it. No need to design these even, these are cheap, but I have not tried these:
formatting link
Design just a plugin for your fiber perhaps, use with an ethernet camera and switch, and you are done, apart from the software.
Maybe an embedded system could be an acceptable trade-off. I'm wondering if there are any integrated modules to compress an input video signal into an output digital stream in real-time (without use a PC).
Another server or another port of the same TCP (or UDP) connection, right?
No problem, I wrote software for PC, for networks and for embedded systems.
It's a good solution, but I prefer to use a lower-level architecture.
No, it can't. It should be like a machine, rather than a PC. Safety is very important so I'm trying to avoid operative systems.
So you imagine that you can build a task schedular and resource allocator by hand that is less likely to have bugs than a RTOS with years of testing and use by a wide variety of users? Let me know how that works out for you.
mmm, maybe there was a misunderstanding. The firmware on the remote board is simpler than you may expect. The current version of the project uses a small PIC: it receives data, updates DACs, reads ADCs and transmits back new data. It's straight and short. The next step is to implement a PID controller (so the need of a fast processor) and eventually manage the eth link (so the need of a module with eth on-board).
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.