Amiga.org
Coffee House => Coffee House Boards => CH / Science and Technology => Topic started by: motorollin on May 24, 2008, 10:16:52 PM
-
I've got a device which connects via Ethernet, and then has software which emulates a serial port and bridges the virtual serial port to the ethernet device. You then send commands to the virtual serial port and they are received by the ethernet device.
The software is only for Windows, and I want to use it with a Mac. Unfortunately I can't find an equivalent. I do, however, have a couple of USB serial ports which work on the Mac. Does anyone know whether those Ethernet to Serial adapters which allow networking through a serial port would allow me to communicate with the ethernet device through a real serial port?
Here (http://www.lantronix.com/device-networking/utilities-tools/com-port-redirector.html) is a link to the COM port redirector software for Windows if it helps.
--
moto
-
Seems all right to me, PC side has serial emulation, and RS232 is RS232, there's not much fuss about that. You only have to know the baud rate, start/stop bits, parity and whether it uses XON/XOFF.
RS232 on wikipedia (http://en.wikipedia.org/wiki/RS232)
-
motorollin wrote:
I've got a device which connects via Ethernet, and then has software which emulates a serial port and bridges the virtual serial port to the ethernet device. You then send commands to the virtual serial port and they are received by the ethernet device.
The software is only for Windows, and I want to use it with a Mac. Unfortunately I can't find an equivalent. I do, however, have a couple of USB serial ports which work on the Mac. Does anyone know whether those Ethernet to Serial adapters which allow networking through a serial port would allow me to communicate with the ethernet device through a real serial port?
Here (http://www.lantronix.com/device-networking/utilities-tools/com-port-redirector.html) is a link to the COM port redirector software for Windows if it helps.
--
moto
I honestly can't follow that you are trying to do here!!!
MacUSB-->Serial-->Ethernet-->Serial-->Some Device
:-?
-
@speel
Wouldn't it depend on what that software is doing? Presumably it wraps the RS232 commands inside Ethernet packets. Are you quite sure a hardware device would do something similar?
@bloodline
The original way (under Windows) is:
Software <-> virtual COM port <-> COM port redirector software <-> ethernet port <-> device
We need to do:
Software <-> real serial port <-> ethernet to serial adapter (hardware) <-> device
So what I don't know is whether the ethernet to serial adapter will carry out the same functions on the RS232 data as the COM port redirector software. Sure the RS232 data within might be the same, but it may be encapsulated differently.
--
moto
-
bloodline wrote:
motorollin wrote:
I've got a device which connects via Ethernet, and then has software which emulates a serial port and bridges the virtual serial port to the ethernet device. You then send commands to the virtual serial port and they are received by the ethernet device.
The software is only for Windows, and I want to use it with a Mac. Unfortunately I can't find an equivalent. I do, however, have a couple of USB serial ports which work on the Mac. Does anyone know whether those Ethernet to Serial adapters which allow networking through a serial port would allow me to communicate with the ethernet device through a real serial port?
Here (http://www.lantronix.com/device-networking/utilities-tools/com-port-redirector.html) is a link to the COM port redirector software for Windows if it helps.
--
moto
I honestly can't follow that you are trying to do here!!!
MacUSB-->Serial-->Ethernet-->Serial-->Some Device
:-?
Program wants to communicate with Com port device -> OS device driver transforms it into ethernet packages -> being send to ethernet to com device -> which transforms it to rs232 communication with the com port device.
-
motorollin wrote:
@speel
Wouldn't it depend on what that software is doing? Presumably it wraps the RS232 commands inside Ethernet packets. Are you quite sure a hardware device would do something similar?
RS232 is mainly a hardware protocol. A software protocol for RS232 would be something like kermit, or telnet. And I'm indeed quite sure it can handle it. It's all pretty straight-forward. It explicitly uses windows, which has a software layer for RS232 communication. So, with this layer, any communication system can be used, as long as a 1on1 communication stream can be established.
-
@speel
Sounds good. If I understand you (and I might not - I'm at the edge of my knowledge about this stuff) if it works with kermit/telnet, which wrap RS232 commands in Ethernet, then it will work with a hardware adapter, which takes the RS232 data from a real port and wrap it in Ethernet before re-broadcasting it. Right?
--
moto
-
motorollin wrote:
@speel
Sounds good. If I understand you (and I might not - I'm at the edge of my knowledge about this stuff) if it works with kermit/telnet, which wrap RS232 commands in Ethernet, then it will work with a hardware adapter, which takes the RS232 data from a real port and wrap it in Ethernet before re-broadcasting it. Right?
--
moto
Kinda, except that RS232 doesn't have commands, since it's an hardware layer. Let's say, a program asks windows to send this or that data over the serial port. The program lets Windows send it over TCP/IP to the dedicated device (which has a dedicated IP adress, which the program is aware of). This device has a com port of it's own, and sends the data over a null-modem (http://en.wikipedia.org/wiki/Null-modem) to the device.
-
Would the application need to know the IP address if the conversion is done in hardware? What I mean is, if the serial <-> Ethernet converter has its own TCP/IP stack and DHCP server (some do) then couldn't it receive raw RS232 data destined for a serial port from an app with no knowledge of the IP address, and then package it up and send it to the IP address it allocated to the Ethernet device?
--
moto
-
motorollin wrote:
Would the application need to know the IP address if the conversion is done in hardware? What I mean is, if the serial <-> Ethernet converter has its own TCP/IP stack and DHCP server (some do) then couldn't it receive raw RS232 data destined for a serial port from an app with no knowledge of the IP address, and then package it up and send it to the IP address it allocated to the Ethernet device?
--
moto
It doesn't receive raw RS232 data, since it's TCP, so that means it's in packages. I guess this program uses it's own IP port and it's own protocol 'inside' TCP/IP.
If it'd be done the way you say, it'd send the data to the very first router your computer is connected to, and this router discards the data because it doesn't recognise it as TCP/IP data.
-
Btw. May I be so free to ask what you'll be using it for?
-
Now I'm really confused... I'm not talking about connecting the Ethernet device through a router or any other kind of intranet. Just a cat5 cable going directly from the Ethernet device in to the serial adapter, then a serial cable from the other side of the adapter to the serial port of the computer.
--
moto
-
Speelgoedmannetje wrote:
Btw. May I be so free to ask what you'll be using it for?
It's a home automation device which connects via Ethernet. As I said the software for Windows sets up a virtual serial port which you can connect to directly using hyperterminal or use software like HomeSeer. The virtual COM port automatically redirects to the device connected via Ethernet (but you have to tell it the correct IP address).
Since this software doesn't work on the Mac, I want to replace it with hardware. I have a USB RS232 port, so just need a device which will connect to it and have an Ethernet port to which I can connect the home automation hardware, allowing me to send the same commands I would type in to hyperterminal on the PC to the Mac's serial port.
--
moto
-
motorollin wrote:
Now I'm really confused... I'm not talking about connecting the Ethernet device through a router or any other kind of intranet. Just a cat5 cable going directly from the Ethernet device in to the serial adapter, then a serial cable from the other side of the adapter to the serial port of the computer.
--
moto
It doesn't work that way. On the site it's stated that the device works as a server in your network.
-
motorollin wrote:
Speelgoedmannetje wrote:
Btw. May I be so free to ask what you'll be using it for?
It's a home automation device which connects via Ethernet. As I said the software for Windows sets up a virtual serial port which you can connect to directly using hyperterminal or use software like HomeSeer. The virtual COM port automatically redirects to the device connected via Ethernet (but you have to tell it the correct IP address).
Since this software doesn't work on the Mac, I want to replace it with hardware. I have a USB RS232 port, so just need a device which will connect to it and have an Ethernet port to which I can connect the home automation hardware, allowing me to send the same commands I would type in to hyperterminal on the PC to the Mac's serial port.
--
moto
hm, you WILL need a specific program on your mac to redirect the serial data to TCP/IP data. But maybe you could configure the hyperterminal in such a way, that it can communicate over TCP/IP. Then you can use a simple PC with a com port and linux installed on it, and let iptables 'bridge' all incoming data (TCP/IP data stripped) to the com-port, and all com-port data be send to your own computer.
-
Speelgoedmannetje wrote:
It doesn't work that way. On the site it's stated that the device works as a server in your network.
So there's no way for it to work unless the software knows that it is communicating with an ethernet device across a TCP/IP stack?
--
moto
-
Speelgoedmannetje wrote:
hm, you WILL need a specific program on your mac to redirect the serial data to TCP/IP data. But maybe you could configure the hyperterminal in such a way, that it can communicate over TCP/IP. Then you can use a simple PC with a com port and linux installed on it, and let iptables 'bridge' all incoming data (TCP/IP data stripped) to the com-port, and all com-port data be send to your own computer.
Well, the idea was to use just the Mac Mini :-( If there's no software solution for the Mac, then we might as well run the Windows software on a separate box.
I'll keep looking for equivalent Mac software. At least now I know it's definitely required. Cheers Speel.
--
moto
-
motorollin wrote:
Speelgoedmannetje wrote:
hm, you WILL need a specific program on your mac to redirect the serial data to TCP/IP data. But maybe you could configure the hyperterminal in such a way, that it can communicate over TCP/IP. Then you can use a simple PC with a com port and linux installed on it, and let iptables 'bridge' all incoming data (TCP/IP data stripped) to the com-port, and all com-port data be send to your own computer.
Well, the idea was to use just the Mac Mini :-( If there's no software solution for the Mac, then we might as well run the Windows software on a separate box.
I still have no idea what you were trying to do... but if you haven't already... get Parallels, in coherence mode it is unbelievable :-)
I'll keep looking for equivalent Mac software. At least now I know it's definitely required. Cheers Speel.
Hmmm...
-
Say, Moto, you could do some programming, not? You could make such yourself. It's really not much work. I can't do it for you, unfortunately, because I don't have a mac. Maybe you could ask someone who has a mac. :-)
-
Speelgoedmannetje wrote:
Say, Moto, you could do some programming, not? You could make such yourself. It's really not much work. I can't do it for you, unfortunately, because I don't have a mac. Maybe you could ask someone who has a mac. :-)
Indeed... but first one would need to understand the problem...
-
bloodline wrote:
Speelgoedmannetje wrote:
Say, Moto, you could do some programming, not? You could make such yourself. It's really not much work. I can't do it for you, unfortunately, because I don't have a mac. Maybe you could ask someone who has a mac. :-)
Indeed... but first one would need to understand the problem...
Moto wants this (http://www.lantronix.com/device-networking/utilities-tools/com-port-redirector.html), but then instead of running it on Windows, running it on MacOS. He asked whether this could be used directly without the OS involved.
-
@bloodline
We have Parallels and yes coherence is pretty cool. But we'd rather get it working on the Mac since AppleScript is perfect for writing the intelligence behind the system.
@speel
Yes I have done some programming, but nothing like this. It's the low-level stuff, actually capturing, manipulating and re-broadcasting the data that I struggle with.
--
moto
-
motorollin wrote:
@speel
Yes I have done some programming, but nothing like this. It's the low-level stuff, actually capturing, manipulating and re-broadcasting the data that I struggle with.
--
moto
On the Linux side, it's a case of scripting (look for a bridging script on the internet to use as example), on the mac side I don't know, it might be as simple as changing properties of the telnet program to use TCP/IP.
Just have a look, it can be very simple. There are plenty of scripts and libraries to make your life very easy.
And if you don't understand stuff, well, we're here for you to help :-)
-
Speelgoedmannetje wrote:
bloodline wrote:
Speelgoedmannetje wrote:
Say, Moto, you could do some programming, not? You could make such yourself. It's really not much work. I can't do it for you, unfortunately, because I don't have a mac. Maybe you could ask someone who has a mac. :-)
Indeed... but first one would need to understand the problem...
Moto wants this (http://www.lantronix.com/device-networking/utilities-tools/com-port-redirector.html), but then instead of running it on Windows, running it on MacOS. He asked whether this could be used directly without the OS involved.
Software that write to a serial port --> Software that encapsulates the Serial data into TCP packets --> MAC-Ethernet Port --> Ethernet wire --> Ethernet-BOX-Serial port -->Some device that wants to plug into a Serial port
Right?
-
bloodline wrote:
Software that write to a serial port --> Software that encapsulates the Serial data into TCP packets --> MAC-Ethernet Port --> Ethernet wire --> Ethernet-BOX-Serial port -->Some device that wants to plug into a Serial port
Right?
precisely :-)
-
Speelgoedmannetje wrote:
bloodline wrote:
Software that write to a serial port --> Software that encapsulates the Serial data into TCP packets --> MAC-Ethernet Port --> Ethernet wire --> Ethernet-BOX-Serial port -->Some device that wants to plug into a Serial port
Right?
precisely :-)
Ok then the problem is the encapsulation software... Which should be quite easy to write, as there are only two problems: It needs to fake a com port... easy enough to do with MacOSX, this is where its Unix roots show up... but we don't know the protocol that the ethernet/serial box uses... what is the format of the packets that it expects?!?
-
bloodline wrote:
Software that write to a serial port --> Software that encapsulates the Serial data into TCP packets --> MAC-Ethernet Port --> Ethernet wire --> Ethernet-BOX-Serial port -->Some device that wants to plug into a Serial port
Right?
Almost :-)
Software that write to a serial port --> Software that encapsulates the Serial data into TCP packets --> MAC-Ethernet Port --> Ethernet wire --> Some device that wants to plug into an Ethernet port
I know what you're thinking - if it connects directly to the Ethernet port why not just write to it directly? Because we don't know how. And since there is already a way of writing to it using a terminal, or even using a script to write bytes to a serial port, we doing the same on the Mac would work.
--
moto
-
Speelgoedmannetje wrote:
On the Linux side, it's a case of scripting (look for a bridging script on the internet to use as example), on the mac side I don't know,
Hmm, will look in to that! I bet the principle would be the same on the Mac since device drivers are exposed in much the same way (/dev/*)
Speelgoedmannetje wrote:
it might be as simple as changing properties of the telnet program to use TCP/IP.
Well we don't actually want to use telnet since we need it to be scriptable (input and output need to be considered).
Speelgoedmannetje wrote:
Just have a look, it can be very simple. There are plenty of scripts and libraries to make your life very easy.
And if you don't understand stuff, well, we're here for you to help :-)
Thanks :-)
--
moto
-
bloodline wrote:
Ok then the problem is the encapsulation software... Which should be quite easy to write, as there are only two problems: It needs to fake a com port... easy enough to do with MacOSX, this is where its Unix roots show up...
Do you know how? I tried to find out how to spoof a com port but couldn't find anything.
bloodline wrote:
but we don't know the protocol that the ethernet/serial box uses... what is the format of the packets that it expects?!?
No idea. Would it help to snoop the com port under Windows and see what's being transmitted?
(Edit - I *really* need to do some revision... ;-) )
--
moto
-
quote]
motorollin wrote:
bloodline wrote:
Software that write to a serial port --> Software that encapsulates the Serial data into TCP packets --> MAC-Ethernet Port --> Ethernet wire --> Ethernet-BOX-Serial port -->Some device that wants to plug into a Serial port
Right?
Almost :-)
Software that write to a serial port --> Software that encapsulates the Serial data into TCP packets --> MAC-Ethernet Port --> Ethernet wire --> Some device that wants to plug into an Ethernet port
[/quote]
Ok... you've lost me again...
The device you want to use already has an ethernet port? then why bother with all this serial nonsense?
Let me try again:
Software ±±> Port : software taking to a serial port.
Software __> : Port : software taking to an Ethernet port.
Computer --> Device : connected via a serial cable.
Computer ==> Device : Connected via Ethernet.
So the basic set up would be:
Software ±±> Computer --> Device
Now you want to use Ethernet... I assumed that this was the setup:
Software ±±>Encapsulator software __> Computer ==>E2S-Box --> Device
But we are missing the Encapsulator software that wraps the data sent via serial into TCP packets to be converted back to serial data once it's reached the E2S Box...
But what you are saying is that the Device already plus into Ethernet...
I know what you're thinking - if it connects directly to the Ethernet port why not just write to it directly? Because we don't know how. And since there is already a way of writing to it using a terminal, or even using a script to write bytes to a serial port, we doing the same on the Mac would work.
So the device has both Serial an Ethernet... but you don't know how to access it via ethernet?
Just fire up a Terminal and connect to its IP...?
-
bloodline wrote:
Ok... you've lost me again...
The device you want to use already has an ethernet port? then why bother with all this serial nonsense?
Because there is no documentation on how to communicate directly over Ethernet. The documentation only tells you how to communicate with it via the virtual COM port.
bloodline wrote:
Now you want to use Ethernet... I assumed that this was the setup:
Software ±±>Encapsulator software __> Computer ==>E2S-Box --> Device
But we are missing the Encapsulator software that wraps the data sent via serial into TCP packets to be converted back to serial data once it's reached the E2S Box...
I hoped that the ethernet to serial device would do that for us...
bloodline wrote:
But what you are saying is that the Device already plus into Ethernet...
Yes, but that doesn't help us for the reasons stated above.
bloodline wrote:
So the device has both Serial an Ethernet... but you don't know how to access it via ethernet?
It *only* has Ethernet, but yes, we don't know how to address it via ethernet other than via the virtual COM port which then somehow redirects to the ethernet port.
bloodline wrote:
Just fire up a Terminal and connect to its IP...?
Tried that. Telnet in to it and get some kind of configuration console but no way of actually controlling it. SSH is rejected.
--
moto
-
motorollin wrote:
bloodline wrote:
Now you want to use Ethernet... I assumed that this was the setup:
Software ±±>Encapsulator software __> Computer ==>E2S-Box --> Device
But we are missing the Encapsulator software that wraps the data sent via serial into TCP packets to be converted back to serial data once it's reached the E2S Box...
I hoped that the ethernet to serial device would do that for us...
Wait... if your device has a serial port then plug it to the Mac with the USB serial port adaptors you have and write data directly to it via the /dev/xxx interface...?
Why can't I understand this? What's wrong with me? I'm going to get a drink...
-
bloodline wrote:
Wait... if your device has a serial port then plug it to the Mac with the USB serial port adaptors you have and write data directly to it via the /dev/xxx interface...?
Why can't I understand this? What's wrong with me? I'm going to get a drink...
:lol:
I'll start again ;-)
The device has ONLY an Ethernet port. No serial port at all. Once it is on the network, you can telnet to it to do some config, but cannot actually control it this way.
Documentation for the device details only how to communicate with it by writing hex bytes to a serial port. Since the device doesn't actually have a serial port, you install the virtual COM port and write them to that. The virtual COM port then redirects the information to the device using TCP/IP through it's Ethernet port. This works - under Windows. I can't find any equivalent software for the Mac.
The idea of the ethernet to serial adapter was to replace the Windows software. So instead of writing hex bytes to a virtual COM port which translates them to TCP/IP and then to Ethernet, you write them to a real serial port to which you connect some hardware which encapsulates the data, and then connects to the device's Ethernet port. From what Speel said though, this won't work, which puts me back at square one looking for a way to do it in software.
I hope that makes sense - perhaps I should have been clearer to start with :-)
--
moto
-
motorollin wrote:
(Edit - I *really* need to do some revision... ;-) )
When I started University, I decided that I had two options...
1. Spend a year Learning and cram an entire year's worth of Drinking into a single night...
2. Spend a year Drinking and cram an entire year's worth of Learning into a single night...
I decided that option 2 was much safer... ;-)
-
motorollin wrote:
bloodline wrote:
Wait... if your device has a serial port then plug it to the Mac with the USB serial port adaptors you have and write data directly to it via the /dev/xxx interface...?
Why can't I understand this? What's wrong with me? I'm going to get a drink...
:lol:
I'll start again ;-)
The device has ONLY an Ethernet port. No serial port at all. Once it is on the network, you can telnet to it to do some config, but cannot actually control it this way.
Documentation for the device details only how to communicate with it by writing hex bytes to a serial port. Since the device doesn't actually have a serial port, you install the virtual COM port and write them to that. The virtual COM port then redirects the information to the device using TCP/IP through it's Ethernet port. This works - under Windows. I can't find any equivalent software for the Mac.
The idea of the ethernet to serial adapter was to replace the Windows software. So instead of writing hex bytes to a virtual COM port which translates them to TCP/IP and then to Ethernet, you write them to a real serial port to which you connect some hardware which encapsulates the data, and then connects to the device's Ethernet port. From what Speel said though, this won't work, which puts me back at square one looking for a way to do it in software.
I hope that makes sense - perhaps I should have been clearer to start with :-)
Ok.. so what is really missing is basically the device driver software for the device... regardless of the fact that it's implemented as a virtual com port... this is simply the interface that is exposed to the controlling software....
No... you are screwed, and not in the good way :-)
You could capture the TCP/IP packets sent when issuing command and then disassemble them... but I fear that is more work than worth it... says the man who tried to run a PowerMac with no way to interface with it :-D
-
bloodline wrote:
When I started University, I decided that I had two options...
1. Spend a year Learning and cram an entire year's worth of Drinking into a single night...
2. Spend a year Drinking and cram an entire year's worth of Learning into a single night...
I decided that option 2 was much safer... ;-)
Well I don't really drink, so my options are:
1. Spend a year learning
2. Spend a year doing nothing and cram an entire year's worth of learning into a single night
I've got an exam on Tuesday on the auditory system, genetic inheritance and embryological development of the head and neck. The first two I think I'm ok on, as I know the auditory system very well and genetics is all very logical anyway. Development of the head and neck is really dull, so I'm thinking of just winging it. I just feel guilty because I used revision as an excuse to get out of a tedious family event, so I feel like I really should be revising :lol:
--
moto
-
bloodline wrote:
Ok.. so what is really missing is basically the device driver software for the device... regardless of the fact that it's implemented as a virtual com port... this is simply the interface that is exposed to the controlling software....
Yes, I suppose so.
bloodline wrote:
No... you are screwed, and not in the good way :-)
You could capture the TCP/IP packets sent when issuing command and then disassemble them... but I fear that is more work than worth it...
I agree, and it would be way above my head and too much trouble to learn if I'm honest. That's why I wanted to reproduce the Windows setup on the Mac - so I don't have to analyse what it's actually doing, just interface with it in the same way I did under Windows.
bloodline wrote:
says the man who tried to run a PowerMac with no way to interface with it :-D
I sometimes wonder what people who aren't geeks actually *do* with their lives... ;-)
--
moto
-
motorollin wrote:
bloodline wrote:
Wait... if your device has a serial port then plug it to the Mac with the USB serial port adaptors you have and write data directly to it via the /dev/xxx interface...?
Why can't I understand this? What's wrong with me? I'm going to get a drink...
:lol:
I'll start again ;-)
The device has ONLY an Ethernet port. No serial port at all. Once it is on the network, you can telnet to it to do some config, but cannot actually control it this way.
Documentation for the device details only how to communicate with it by writing hex bytes to a serial port. Since the device doesn't actually have a serial port, you install the virtual COM port and write them to that. The virtual COM port then redirects the information to the device using TCP/IP through it's Ethernet port. This works - under Windows. I can't find any equivalent software for the Mac.
The idea of the ethernet to serial adapter was to replace the Windows software. So instead of writing hex bytes to a virtual COM port which translates them to TCP/IP and then to Ethernet, you write them to a real serial port to which you connect some hardware which encapsulates the data, and then connects to the device's Ethernet port. From what Speel said though, this won't work, which puts me back at square one looking for a way to do it in software.
Ah, if the device actually has an ethernet port, this'd make things more easy. You only need to know the protocol of that device, then. But it sounds strange to me that you can do so little with telnet :-? You must be able to do everything with telnet, because telnet is dedicated to do everything; including scripts, running programs, etcetera.
If you plug this converter to your Apple's com-port, you can attach it directly using a cross-link cable. Still, you need the protocol. But all this fuss is not necessary.
-edit-Oh, ehm and the device needs to be able to interact with the ethernet-to-comport adapter, and since it doesn't know the protocol of that adapter, so, that's a no-go anyway.
-
motorollin wrote:
bloodline wrote:
When I started University, I decided that I had two options...
1. Spend a year Learning and cram an entire year's worth of Drinking into a single night...
2. Spend a year Drinking and cram an entire year's worth of Learning into a single night...
I decided that option 2 was much safer... ;-)
Well I don't really drink, so my options are:
I drink. Oh boy do I drink... I drink to forget... I drink to cope... I drink out of boredom... I drink out of depression... I drink out of habit... I drink because I can... I drink because I can always find an excuse to drink.
Suffice to say... I like a drink...
1. Spend a year learning
Waste of time... I've spent over 6 months learning German... and yet I'm still crap... I say learning is pointless.
2. Spend a year doing nothing and cram an entire year's worth of learning into a single night
Sounds like a good plan... and since you learned just before the Exam... you're less likely to forget it... makes sense really!! Lets crack open a beer and celebrate!
I've got an exam on Tuesday on the auditory system, genetic inheritance and embryological development of the head and neck. The first two I think I'm ok on, as I know the auditory system very well and genetics is all very logical anyway. Development of the head and neck is really dull, so I'm thinking of just winging it.
It's not that dull... you just need to find what bit is the most interesting and focus on that...
I just feel guilty because I used revision as an excuse to get out of a tedious family event, so I feel like I really should be revising :lol:
Never feel guilty about avoiding your family... you owe them nothing!!! :madashell:
-
Speelgoedmannetje wrote:
motorollin wrote:
bloodline wrote:
Wait... if your device has a serial port then plug it to the Mac with the USB serial port adaptors you have and write data directly to it via the /dev/xxx interface...?
Why can't I understand this? What's wrong with me? I'm going to get a drink...
:lol:
I'll start again ;-)
The device has ONLY an Ethernet port. No serial port at all. Once it is on the network, you can telnet to it to do some config, but cannot actually control it this way.
Documentation for the device details only how to communicate with it by writing hex bytes to a serial port. Since the device doesn't actually have a serial port, you install the virtual COM port and write them to that. The virtual COM port then redirects the information to the device using TCP/IP through it's Ethernet port. This works - under Windows. I can't find any equivalent software for the Mac.
The idea of the ethernet to serial adapter was to replace the Windows software. So instead of writing hex bytes to a virtual COM port which translates them to TCP/IP and then to Ethernet, you write them to a real serial port to which you connect some hardware which encapsulates the data, and then connects to the device's Ethernet port. From what Speel said though, this won't work, which puts me back at square one looking for a way to do it in software.
Ah, if the device actually has an ethernet port, this'd make things more easy. You only need to know the protocol of that device, then. But it sounds strange to me that you can do so little with telnet :-? You must be able to do everything with telnet, because telnet is dedicated to do everything; including scripts, running programs, etcetera.
I don't believe the device is actually being controlled via the Serial interface.
The virtual com device, is probably not just encapsulating the commands issued via serial... I expect it's is interpreting the serial commands and then issuing proprietary control packets... that would mean Telnet would not control the device.
The fact that it is controlled via virtual com device is a red herring...
If you plug this converter to your Apple's com-port, you can attach it directly using a cross-link cable. Still, you need the protocol. But all this fuss is not necessary.
-
Speelgoedmannetje wrote:
Ah, if the device actually has an ethernet port, this'd make things more easy. You only need to know the protocol of that device, then.
I will try to run a packet sniffer on the Ethernet port and have a look at the traffic. Might give some clue.
Speelgoedmannetje wrote:
But it sounds strange to me that you can do so little with telnet :-? You must be able to do everything with telnet, because telnet is dedicated to do everything; including scripts, running programs, etcetera.
Ok, well I'll have another look at the telnet services on the device just in case I missed something.
Speelgoedmannetje wrote:
If you plug this converter to your Apple's com-port, you can attach it directly using a cross-link cable. Still, you need the protocol. But all this fuss is not necessary.
-edit-Oh, ehm and the device needs to be able to interact with the ethernet-to-comport adapter, and since it doesn't know the protocol of that adapter, so, that's a no-go anyway.
Shame - that would have made things a LOT easier.
--
moto
-
bloodline wrote:
Suffice to say... I like a drink...
So I can see! I would probably drink a lot more if I wasn't painfully obvious of its effects...
bloodline wrote:
Waste of time... I've spent over 6 months learning German... and yet I'm still crap... I say learning is pointless.
Well, 6 months isn't enough time to learn a language, and I bet you have improved. So it's not pointless, it just takes time. But, of course you know that really ;-)
bloodline wrote:
2. Spend a year doing nothing and cram an entire year's worth of learning into a single night
Sounds like a good plan... and since you learned just before the Exam... you're less likely to forget it... makes sense really!! Lets crack open a beer and celebrate!
I can afford to forget it TBH - it's superfluous. Which makes it even more frustrating having to learn it just to get through the exam :roll:
bloodline wrote:
It's not that dull... you just need to find what bit is the most interesting and focus on that...
Well the process as a whole is fascinating, and so complex it is both beautiful and terrifying. But learning by rote which pharyngeal arches develop in to which structures and how they are innervated *is* pretty dull.
bloodline wrote:
Never feel guilty about avoiding your family... you owe them nothing!!! :madashell:
They're not even my family - they're the in-laws!
--
moto
-
bloodline wrote:
I don't believe the device is actually being controlled via the Serial interface.
The virtual com device, is probably not just encapsulating the commands issued via serial... I expect it's is interpreting the serial commands and then issuing proprietary control packets... that would mean Telnet would not control the device.
The fact that it is controlled via virtual com device is a red herring...
Then for now I will disregard the serial aspect and concentrate on working out what is happening post-encapsulation. If I can work that out, maybe I can start thinking about a way to create those data myself. Presumably that would require low-level access to the TCP/IP stack? ("Here is a packet of data I have manually created. Send it please...")
--
moto
-
motorollin wrote:
bloodline wrote:
I don't believe the device is actually being controlled via the Serial interface.
The virtual com device, is probably not just encapsulating the commands issued via serial... I expect it's is interpreting the serial commands and then issuing proprietary control packets... that would mean Telnet would not control the device.
The fact that it is controlled via virtual com device is a red herring...
Then for now I will disregard the serial aspect and concentrate on working out what is happening post-encapsulation.
Remember, this is just my theory... If you can Telent, that make sure you explore that avenue FULLY!!
But yes... I think the solution... if there is one, will come from examining the packets.
If I can work that out, maybe I can start thinking about a way to create those data myself. Presumably that would require low-level access to the TCP/IP stack? ("Here is a packet of data I have manually created. Send it please...")
Well, if it is a fixed function device... then you could easily build a library of packets that correspond to the commands you issue...
-
bloodline wrote:
Never feel guilty about avoiding your family... you owe them nothing!!! :madashell:
What have you people always against family? I love my family, and vice versa (aunts still treat me as the benjamin of the family :oops:)
-
bloodline wrote:
Remember, this is just my theory... If you can Telent, that make sure you explore that avenue FULLY!!
Have just checked, and it's definitely a config interface only. After outputting the current config, the telnet interface gives you the following options, none of which allow any control or monitoring of what is happening in the device.
Change Setup:
0 Server
1 Channel 1
2 Channel 2
3 E-mail
5 Expert
6 Security
7 Defaults
8 Exit without save
9 Save and exit Your choice ?
bloodline wrote:
But yes... I think the solution... if there is one, will come from examining the packets.
It should be fairly easy to have a look at the packets. But I have no idea how I would go about writing an app to custom make a packet and shove it in to the TCP/IP stack. Furthermore, the app would have to monitor traffic coming from the device to detect state changes. I'm losing enthusiasm for this now...
bloodline wrote:
Well, if it is a fixed function device... then you could easily build a library of packets that correspond to the commands you issue...
Yes, there will be only a limited number of commands I will ever need to send to it, so once the I/O was working I could easily tweak the data it sends to make it do different things. That's the easy part...
--
moto
-
Doesn't offer the export mode a CLI?
Btw. you can use Wireshark to observe the communication, as raw data.
-
motorollin wrote:
bloodline wrote:
Remember, this is just my theory... If you can Telent, that make sure you explore that avenue FULLY!!
Have just checked, and it's definitely a config interface only. After outputting the current config, the telnet interface gives you the following options, none of which allow any control or monitoring of what is happening in the device.
Change Setup:
0 Server
1 Channel 1
2 Channel 2
3 E-mail
5 Expert
6 Security
7 Defaults
8 Exit without save
9 Save and exit Your choice ?
bloodline wrote:
But yes... I think the solution... if there is one, will come from examining the packets.
It should be fairly easy to have a look at the packets. But I have no idea how I would go about writing an app to custom make a packet and shove it in to the TCP/IP stack. Furthermore, the app would have to monitor traffic coming from the device to detect state changes. I'm losing enthusiasm for this now...
Post the IP... I wanna log on :-D
-
Speelgoedmannetje wrote:
bloodline wrote:
Never feel guilty about avoiding your family... you owe them nothing!!! :madashell:
What have you people always against family?
I didn't choose my family... I am disappointed with some of their decisions and actions.
I love my family, and vice versa (aunts still treat me as the benjamin of the family :oops:)
Yet, she still hasn't learned your name?
-
Benjamin means the youngest son.
-
Speelgoedmannetje wrote:
Benjamin means the youngest son.
Ahhh right you are! I though she might have dementia or something :-)
-
bloodline wrote:
Ahhh right you are! I though she might have dementia or something :-)
No, they're all very well. It's just very coincidental that they all love to talk about how I was when I was a kid, (it always has to be me) The whole female side of the family loves to talk about that.
Yes we all know I was a bit weird as a kid. :lol:
-
Right, we're going to have a look at the packets going to the RFXCOM's IP address so we can see what is being sent. Then I'm going to try hacking up a socket application in OS X. Shouldn't be a mammoth task to write a small console app which will take the RFXCOM command and IP address as arguments and then transmit the command to the correct IP.
Where this will get more difficult will be receiving data from the RFXCOM. Apparently the software is configured with the RFXCOM's IP address so it knows where to send data. But it also listens for events coming from the RFXCOM so it can act upon them. How would this work? Would I have to maintain an open socket with the RFXCOM's IP address? If I do this, will packets coming from the RFXCOM automatically be delivered via the Mac's TCP/IP stack to my application?
--
moto
-
motorollin wrote:
Where this will get more difficult will be receiving data from the RFXCOM. Apparently the software is configured with the RFXCOM's IP address so it knows where to send data. But it also listens for events coming from the RFXCOM so it can act upon them. How would this work? Would I have to maintain an open socket with the RFXCOM's IP address? If I do this, will packets coming from the RFXCOM automatically be delivered via the Mac's TCP/IP stack to my application?
--
moto
Yeps, TCP uses sockets.
-
Do I need to open a socket specifically between the application and the software on the RFXCOM? Or do I just open a socket to the Mac's TCP/IP stack and send a packet addressed with the RFXCOM's IP address?
--
moto
-
You must know what port the RFXCOM works on, and it's IP-port. As far as my experience goes, this will be done in a program (on your mac in this case). It can of course also be done using scripts.
-
I'm in way over my head here. I found some examples of BSD sockets, one of which "calls" a socket. The main function of it seems to call socket() and connect(). But I don't know whether this is as a client or a server :crazy:
--
moto
-
The device is a server.
-
Ok, just need to figure out whether the code I have written is for a client or server. Ugh, I need to put this away until after my exam...
--
moto
-
Hmm Wikipedia actually helped :-)
http://en.wikipedia.org/wiki/Berkeley_sockets#TCP
Explains how to set up a client and a server. I guess the RFXCOM is doing all the server business, so I'll have a look at the client setup tomorrow after the Exam Of Doom.
--
moto
-
motorollin wrote:
Hmm Wikipedia actually helped :-)
http://en.wikipedia.org/wiki/Berkeley_sockets#TCP
Explains how to set up a client and a server. I guess the RFXCOM is doing all the server business, so I'll have a look at the client setup tomorrow after the Exam Of Doom.
--
moto
Good luck tomorrow!
-
Thanks :-)
--
moto
-
motorollin wrote:
Thanks :-)
--
moto
You should get some sleep.
-
I know. Up at 06:30 tomorrow to get to Brum in time. Can't sleep though :crazy:
--
moto
-
motorollin wrote:
Hmm Wikipedia actually helped :-)
http://en.wikipedia.org/wiki/Berkeley_sockets#TCP
Explains how to set up a client and a server. I guess the RFXCOM is doing all the server business, so I'll have a look at the client setup tomorrow after the Exam Of Doom.
--
moto
Have succes, Moto :-)
-
motorollin wrote:
I know. Up at 06:30 tomorrow to get to Brum in time. Can't sleep though :crazy:
--
moto
It's okay if you can't sleep, as long as you're lying in bed (reading a book or something). You'll get enough rest.
-
Thanks :-D And I can stop thinking about this little project now I have had a small success. I compiled the example code from Wikipedia and got it working. It connects and disconnects a socket to my MacBook's IP address on port 80. I know it's working because if I specify a bogus IP it hangs (no intelligence to time-out) and if I turn off the web server it errors that the connection failed.
So now I just need to work out reading and writing, but that can wait until after 12:00 tomorrow when I can remove embryology from my brainbox.
--
moto
-
Ah...the joy of last minute studying and the relief of forgetting it all instantly the moment you walk out of the room where the exam was =).
-
odin wrote:
Ah...the joy of last minute studying and the relief of forgetting it all instantly the moment you walk out of the room where the exam was =).
The exam was actually quite fun :crazy:
--
moto
-
Ok here's a packet being sent to the RFXCOM, sniffed from the Ethernet port of the computer, when it turns on a power socket:
00000000 21 70 00 00 12 04
3
So I'm guessing if I just write that to the socket from my test app, it should have the same effect as the original Windows app sending it? :-?
--
moto
-
Hmm, ok the data inside that Ethernet packet (21 70 00 00 12 04) corresponds to the hex values you would send to the virtual COM port for the same command. So perhaps the COM port redirector isn't doing anything fancy after all, just wrapping those hex bytes up in a TCP packet. I'm going to try something which will probably seem overly elaborate, but will test a theory:
Windows machine running terminal emulator <-> real COM port <-> serial cable <-> real COM port <-> Mac <-> MultiCOM (http://www.versiontracker.com/dyn/moreinfo/macosx/32799) redirector <-> RFXCOM (over Ethernet)
If that works then I will know it's possible to use MultiCOM on the Mac as the COM port redirect. I am already in contact with the author of MultiCOM who reckons it should work with a virtual COM port, making the setup like this:
Application on Mac sending hex bytes <-> virtual COM port <-> MultiCOM (http://www.versiontracker.com/dyn/moreinfo/macosx/32799) redirector <-> RFXCOM (over Ethernet)
Bloodline, you reckon it's quite simple to set up a virtual COM port under OS X. I have Googled it but can't find out how. Would you mind pointing me in the right direction?
--
moto
-
Right! First test worked. Snooped the serial port while pressing a button to turn a light on and got the hex values it sends. Then under Windows, opened a terminal and sent the same values to that COM port, and the light turned on! :-)
Next step is to make sure Multicom works as a redirect on the Mac side of serial data to the Ethernet port.
--
moto
-
Eeehmm, isn't it a good idea to get a datasheet of this thingy, rather than do this possibly extremely time-consuming reverse engineering?
-
Eventually yes. I just snooped one code to test it.
--
moto
-
By the way there is practically no documentation about what is actually happening "behind the scenes", which is why we don't know how to replicate it. That's why we're having to "reverse engineer" it piece by piece.
--
moto
-
The datasheet must have all the data you need to use that thing.
-
Yes, it has all the information you need to use it via the HomeSeer interface, but no information which is useful for developing your own interface.
--
moto
-
motorollin wrote:
Bloodline, you reckon it's quite simple to set up a virtual COM port under OS X. I have Googled it but can't find out how. Would you mind pointing me in the right direction?
--
moto
What you need to do is set up a loopback device... I used to use them all the time before we had Rewire and Core Audio/Network MIDI.
It craetes two COM device on the system that are actually conencted so that you put data in to one and it pop out the other... then you connenct one end to your Terminal and the other end to the MultiCOM software.
-Edit- If you can't do it in software... use two serial ports on the Mac and put a Null Modem cable between them... Einfach!:-)
-
motorollin wrote:
Yes, it has all the information you need to use it via the HomeSeer interface, but no information which is useful for developing your own interface.
--
moto
Ehm, I don't really know what kind of device you use, and what kind of software you use. But I've got the idea you don't have the right datasheet. A normal datasheet should describe every single bit a programmer and needs to know. Maybe it also has an SDK which you can use (which makes things much easier).
-
bloodline wrote:
What you need to do is set up a loopback device... I used to use them all the time before we had Rewire and Core Audio/Network MIDI.
It craetes two COM device on the system that are actually conencted so that you put data in to one and it pop out the other... then you connenct one end to your Terminal and the other end to the MultiCOM software.
Do you know how to do it with serial ports in BSD? (Will Google loopback devices in the meantime)
bloodline wrote:
-Edit- If you can't do it in software... use two serial ports on the Mac and put a Null Modem cable between them... Einfach!:-)
That's the fall-back option :-)
--
moto
-
BTW just soldered up a serial cable and connected a PC running a terminal to the Mac Mini via its USB serial port. Ran Multicom and configured it to bridge the USB serial port to the IP address and port of the RFXCOM, typed a command in to the terminal emulator on the PC and it worked! Soooooo Multicom works as a redirector. Just need a virtual serial port or an additional USB one to loop back and we should be set! :-D
--
moto
-
Got another USB serial port and created a serial port loopback. I then pointed my test Applescript at one of the ports, and told Multicom to redirect the other one to the IP and port of the RFXCOM. Sent a serial command from my Applescript and....... it worked :-D I also knocked up a listener app which can detect commands coming back the other way and act upon them. So I now have total control over the RFXCOM from Applescript!
Anyone every used socat? It's a redirector which supports pty ports, so I believe I can use it to create a software loopback. The syntax looks extremely complicated though, and I don't really know what I'm doing!
Thanks for all the help so far :-)
--
moto
-
motorollin wrote:
Got another USB serial port and created a serial port loopback. I then pointed my test Applescript at one of the ports, and told Multicom to redirect the other one to the IP and port of the RFXCOM. Sent a serial command from my Applescript and....... it worked :-D
Had you ever doubts?!?! ;-)
Now can we please figure out a way to get my damn PowerMac going :-D
-
bloodline wrote:
Had you ever doubts?!?! ;-)
Of course not! Ok, well maybe a bit :-P It's an interim solution IMO. We need bidirectional control, which due to the way the RFXCOM works requires two separate connections on different IP ports. That means we need two serial interfaces, so two serial loopbacks, and therefore four serial ports! If I can get it working with socat then I will be very happy as it will be an entirely software solution.
bloodline wrote:
Now can we please figure out a way to get my damn PowerMac going :-D
BUY A KEYBOARD! :-P
--
moto
-
motorollin wrote:
bloodline wrote:
Had you ever doubts?!?! ;-)
Of course not! Ok, well maybe a bit :-P It's an interim solution IMO. We need bidirectional control, which due to the way the RFXCOM works requires two separate connections on different IP ports. That means we need two serial interfaces, so two serial loopbacks, and therefore four serial ports! If I can get it working with socat then I will be very happy as it will be an entirely software solution.
A software solution is totally possible... I'm pretty sure you can use pipes or something... I foget how this all works on Unix...
But since the hardware solution proved it would work, I'm feeling quite satisfied!
bloodline wrote:
Now can we please figure out a way to get my damn PowerMac going :-D
BUY A KEYBOARD! :-P
To that sir, I say bum!
-
bloodline wrote:
A software solution is totally possible... I'm pretty sure you can use pipes or something... I foget how this all works on Unix...
I'm waiting for a reply on a Linux forum where I asked for help with the syntax for socat. Hopefully that will do the trick!
bloodline wrote:
But since the hardware solution proved it would work, I'm feeling quite satisfied!
Yeah, it's great that we finally got it working! At least now I can get the Applescript to a level where it can replace Homeseer, and then it's goodbye Parallels :-D
bloodline wrote:
To that sir, I say bum!
Hmm, not really sure how to respond to your bum...
--
moto
-
Done it :-D Here is the syntax for socat:
socat GOPEN:/dev/ptyp0 TCP:10.0.1.93:10002
Then I configured my app to send the commands to /dev/ttyp0 (the other side of the pty) and it worked! :-D
Cheers guys!
--
moto
-
:-D
We rule, except when it comes to doing something simple... Like getting an old PowerMac up headless...
-
bloodline wrote:
:-D
We rule, except when it comes to doing something simple... Like getting an old PowerMac up headless...
Well we don't even know whether that is working. The autorun VNC CD was a great idea, but obviously not much help if the OS isn't up!
When's your birthday? I'll get you the bloody VGA adapter! ;-)
--
moto
-
motorollin wrote:
bloodline wrote:
:-D
We rule, except when it comes to doing something simple... Like getting an old PowerMac up headless...
Well we don't even know whether that is working. The autorun VNC CD was a great idea, but obviously not much help if the OS isn't up!
When's your birthday? I'll get you the bloody VGA adapter! ;-)
:lol: But the point is I don't want an adaptor! It's all about not having to get any adaptors to support legacy ports... The challenge was there... we failed.
-
Or we just gave up to easily! If you don't want to buy an adapter, you'll have to solder a cable directly on to the old port ;-)
--
moto
-
motorollin wrote:
Hmm, not really sure how to respond to your bum...
--
moto
Use your instinct.
-
Speelgoedmannetje wrote:
motorollin wrote:
Hmm, not really sure how to respond to your bum...
--
moto
Use your instinct.
We were doing so well... :-D
-
bloodline wrote:
Speelgoedmannetje wrote:
motorollin wrote:
Hmm, not really sure how to respond to your bum...
--
moto
Use your instinct.
We were doing so well... :-D
Almost 5 pages until deterioration. :-D
-
Speelgoedmannetje wrote:
bloodline wrote:
Speelgoedmannetje wrote:
motorollin wrote:
Hmm, not really sure how to respond to your bum...
--
moto
Use your instinct.
We were doing so well... :-D
Almost 5 pages until deterioration. :-D
Indeed!
Let the sock jokes flow forth...
-
bloodline wrote:
Indeed!
Let the sock jokes flow forth...
My washing machine has died recently...
-
Speelgoedmannetje wrote:
My washing machine has died recently...
Then you'll have to do it by hand...
...your washing, that is.
--
moto
-
motorollin wrote:
Speelgoedmannetje wrote:
My washing machine has died recently...
Then you'll have to do it by hand...
...your washing, that is.
--
moto
Ooooh Matron!
-
motorollin wrote:
Speelgoedmannetje wrote:
My washing machine has died recently...
Then you'll have to do it by hand...
...your washing, that is.
--
moto
I paid some people to do it for me. Busy man I am, lots of work to do and too little time for nuisances like this, no, I'll happily let this be done by professionals.
And my socks never felt so soft!