I have an OSD(atmega88p inside), which is reading data from GPS through serial connection as I understand and I would like to connect second device (FEZ Cerb40) to read GPS data, wondering if that will cause any problems, may be serial device can be read only by one device at the time? Could FEZ Cerb40 work as a proxy (I mean read data from GPS for it self and then pass same data further)?
1
-
\$\begingroup\$ As a side note, this will probably work fine, you can always find out by plugging them in and testing. Worst case you damage your GPS, but I would bet malfunction would not cause permanent damage. \$\endgroup\$– KortukOct 23, 2012 at 2:11
Add a comment
|
3 Answers
\$\begingroup\$
\$\endgroup\$
2
You can electrically buffer and route the serial signal from the GPS to as many devices as you like. This does not work for the line to send to the GPS. Only one device can send to it, but any number can listen. As long as the single sending device sets up the GPS to produce a stream that the other devices can interpret, then all should work.
Note that I mentioned buffering. Only a limited number of electrical loads should be on the GPS transmit line. If too many, then the line will be loaded too much. This can cause invalid signal levels or low pass filter it to oblivion. If the multiple devices are just additional CMOS inputs on the same board, then there is unlikely to be a problem. If the multiple devices are dispersed and want to connect to a RS-232 as apposed to digital signal, then you have to consider the loading of each device.
answered Oct 22, 2012 at 17:12
-
\$\begingroup\$ I'm a noob at electronics, so could you give me idea, how such buffer could look like or where to read about it? \$\endgroup\$– GiedriusOct 22, 2012 at 17:14
-
1\$\begingroup\$ @Giedrius A Buffer Amplifier is what you are looking for. Specifically, an easy one to build at home is an op amp with the input the non-inverting input, the output shorted the the inverting input, as is shown here. In this case the input impedance of the op-amp is very high, so it does not draw much current from the source signal and the output of the amplifier can source a relatively large current(if you pick a good one). \$\endgroup\$– KortukOct 22, 2012 at 19:31
\$\begingroup\$
\$\endgroup\$
In general, it is easy to have communications from one device routed to many, and harder to have communications from many devices routed to one. The ease or difficulty of having multiple devices receive data from the GPS device will primarily be a function of the extent to which the data recipients have to talk to the GPS device in order to get information from it. If one device can ask it to output all of the information which the other devices will ever need, then you may be able to connect the GPS device's input to one of your devices, which will feed it the appropriate request(s), and while the data output gets routed to all of your devices. For this approach to work, it should be possible for each of your devices to identify which communications from the GPS it is interested in, and which ones it isn't.
Proxy devices can be useful in cases where many devices would each want to be able to issue their own requests to a common device. The complexity of the proxy can vary considerably based upon the extent to which it must keep track of the common device's state or the individual devices' perception of it. If, for example, once device is expecting to be sent coordinates in decimal degrees, while another is expecting coordinates in degrees-minutes-seconds, a proxy device could precede GPS requests from the first device with a command to switch to decimal mode, and those from the second with a command to switch to DMS mode, or a proxy could always request coordinates in decimal mode and convert them to DMS mode when handling coordinate requests from devices expecting that format. If all devices will want coordinates in the same format, it would be easiest to simply set the GPS device to use that format and then ignore the issue, but if the devices expect different formats, each of the other approaches will have its own advantages.
\$\begingroup\$
\$\endgroup\$
The G-OSD II Mini OSD System with enhanced GPS module looks very interesting and specifically designed for aviation hobby market. GPS modules for tracking have two types of serial ports RS232 and std logic levels. Given the size of this system, there is no need for long distance communication and RS232, so std UART signals would be expected Rx, Tx & Gnd. Loading on signals and ground noise coupling of multiple digital systems may require the use of ferrite torroidal filter to isolate common mode noise, but I suspect you can easily monitor Rx with several devices but only control from one.
This UART communication is probably a primitive subset of serial ports, so there wont be any handshaking hardware signals just a 3 wire interface. Setup the device for the best data rate possible without interfering with the OSD processing unless their improved version has a fully buffered UART to prevent overruns during video processing.
Since this is custom, and I do not have the specs, just the pictures of wiring, you can expect the GPS data to come out the serial port as a pre-defined periodic burst of data e.g. every second or on demand. If it is really improved, then the information rate may support more frequent updates without being polled for data. Usually for flying, you don't often need to change the data format, just want it to come with steady updates for real-time fast tracking purposes. Automotive and aeronautical GPS types for commercial use would have a totally different set of requirements.
I believe this GPS device may be similar to almost all the APRS trackers on the market that support NMEA 0183 with 4800 Baud, but it may have a few pleasant surprises.
