Unique port name in GPSOut

[dfournie]

Can IP addresses and specific TCP ports be entered into the unique port name field in GPSOut? Something like 192.168.1.1:4600, etc... Or a computer network name? Basically I want to send the raw output out of GPSOut directly to a specific port on another TCP address on my network.

Would instead (in a future FSUIPC release) it be possible to have a dialog box in the GPSOut tab that would accept a network name/ip address and a box for sending the output to specific TCP ports? ( 2 - 3 ports) Perhaps accepting a range of ports to send the data to?

[Pete Dowson]

Can IP addresses and specific TCP ports be entered into the unique port name field in GPSOut? Something like 192.168.1.1:4600, etc... Or a computer network name? Basically I want to send the raw output out of GPSOut directly to a specific port on another TCP address on my network.

I doubt it, unless such names can take the place of device names or filenames in standard I/O operations.

What would be receiving the data at the other end? I don't know of any specification for NMEA data to operate over Networks.

Would instead (in a future FSUIPC release) it be possible to have a dialog box in the GPSOut tab that would accept a network name/ip address and a box for sending the output to specific TCP ports? ( 2 - 3 ports) Perhaps accepting a range of ports to send the data to?

If you set the port to WideFS it is already sent over the Network, but of course the receiving program has to operate the WideFS protocol.

I really cannot imagine what the application for anything like you are suggesting could be. Perhaps you could elaborate? What Network protocol are you thinking of anyway?

Regards

Pete

[dfournie]

It's a Serial-Ethernet adapter that works over wireless. Basically it has 2 physical DB-9 ports on it that you can plug into any serial devices. You assign it an IP address (I'm doing it over DHCP), then you open a session (telnet, for example) to it and can send data directly to the IP address and the port (Serial port 1 on the unit uses 4600, port 2 uses 4601). The GPS gets the data and doesn't know it's not connected to a PC. The software the company provides with it is pretty useless. I've managed to get it to work with GPSOut using a third party program that creates a virtual com port and re-directs it to TCP. I was guessing I could try the same thing in the unique name port. I just wasn't sure if you were using it for standard I/O operations.

[Pete Dowson]

It's a Serial-Ethernet adapter that works over wireless. Basically it has 2 physical DB-9 ports on it that you can plug into any serial devices. You assign it an IP address (I'm doing it over DHCP), then you open a session (telnet, for example) to it and can send data directly to the IP address and the port (Serial port 1 on the unit uses 4600, port 2 uses 4601). The GPS gets the data and doesn't know it's not connected to a PC.

I still don't really understand. What protocol does TelNet use? All my Network programming has been done by using th WinSock interface, which is completely different (no similarity whatsoever) with what I do to drive a serial port. I just can't imagine how one can be mapped onto the other. Is it connectionless like UDP? If not who does the connection and who does the listening?

Maybe I don't know enough about Networks. All the stuff I did in WideFS was copied direct from MS examples.

I've managed to get it to work with GPSOut using a third party program that creates a virtual com port and re-directs it to TCP.

See, that's where I'm lost. What does "redirect it to TCP" mean? TCP is a protocol. Yes, its datagrams can contain data, but there are connections to be made. The making of the connection is asymmetric -- WideServer and WideClient for instance are different, even though they indulge in two-way data exchanges.

There is a "mailshot" facility in Windows XP and later, which I use for the server to broadcast its availability to any who may listen. I suppose that could broadcast GPS data, but will anything be listening for specific broadcasts. They have to know what to expect.

I'm not averse to adding facilities if they will be genuinely useful, it is just that I don't understand what I'd have to do in this case. Do you have any examples or specifications?

Regards

Pete

[dfournie]

All that needs to be done is open a Winsock socket connection to the specified port of a specified IP address.

On my PC, if I open port 4600 on address 192.168.1.100 (my assigned address for the serial-ethernet converter box) I can send a stream of NMEA data from my PC followed by carriage return/line feed directly to that opened socket. The serial-ethernet adapter box (192.168.1.100) just receives the data on that port (4600) and directs it to its built in DB-9.

The serial-ethernet adapter has a built in web server to configure each of its COM ports. Either port can be configured as a TCP server, client, or just to listen for any broadcast UDP. I have it configured for UDP listen. I set up GPSOut to send everything over a virtual com port on my PC. The 3rd party software I have (GPSGate) just takes the serial NMEA data and redirects it to port 4600 on 192.168.1.100. The GPS connected to the serial-ethernet adapter sees the NMEA data and gives the proper position.

The actual TCP/UDP connection between the PC and the serial-ethernet converter box is handled by this other software I'm using.

My train of thought was that if the unique port name dialog box could accept ip address/port information (or a range of ports) then GPSOut could broadcast directly over UDP. All I would have to do is have the serial-ethernet box look for the broadcast and the GPS would have the data it needs.

[Pete Dowson]

All that needs to be done is open a Winsock socket connection to the specified port of a specified IP address.

On my PC, if I open port 4600 on address 192.168.1.100 (my assigned address for the serial-ethernet converter box) I can send a stream of NMEA data from my PC followed by carriage return/line feed directly to that opened socket.

TCP is a connected protocol. The process of creating a socket and getting data across involves, for the Server (with parameters omitted for now):

WSAStartup(..., ...); to initialise WinSock

SOCKET s = socket(..., ..., ...); to get a socket assigned

a series of setsockopts according to needs

bind(..., ..., ...); to associate an address with the socket

listen(..., ...); wait for a connection

WSAAsyncSelect(..., ..., ..., ...); to send message to window when a connection attempt is made

The action on the Client is different, but equally complex. In both cases either a separate thread has to be used or a lot of trouble is taken over getting everything to operate asynchronously and thus not ruining performance.

I've left out all the errors checks and clean up actions they need. And even UDP involves most of those steps. I think you just miss out the "listen" bit.

Now, tell me, how do you see that as equating to your "All that needs to be done is open a Winsock socket connection to the specified port of a specified IP address."?

Let me see your code (in C please), without using any fancy libraries not available or not wanted inside the FS process.

I am on holiday from late tomorrow (Thursday) until Monday 25th June. Maybe you'll have some easy short source code by then? Honestly, nothing I've seen in networks is as simple as you are making it sound, so I'd really like to see this.

Regards

Pete

[dfournie]

I didn't mean to trivialize the process required to get a TCP connection up. I haven't used my CIS degree is a long time - I doubt I could code much anything useful anymore. The more time I spend flying, the less I use and remember basic computer principles.

I have been very successful in getting GPSOut to connect with the serial-ethernet converter. It drives the moving maps quite nicely. I'm finding that using UDP is working far better because it really doesn't matter if the moving maps lose a few NMEA sentences here or there.