Hey theNbomr!

Thanks! let me check this too by sending a response command to the modem.

In the mean time to keep the discussion going on, can you tell me if you (or anybody reading these posts) have any experience with sending HDLC commands to the controller (or modem) using minicom program? I have to send the HDLC frames once the controller starts communicating and I have made some frames too but again I wonder if there is some specific way to send those frames through Minicom connection -

Regards,

Well, since minicom is an interactive terminal emulator, I don't think it is likely to be able to send anything that has non-human-readable content. How are you composing your HDLC frames? If you are using C code, you should be able to transmit & receive it as a generic data buffer using standard RS-232 techniques.

See the following for details:
Serial-Howto
Serial Programming Howto
Serial Programming Guide for POSIX OS's

--- rod.

Hi!
Thanks for providing me with excellent links! I am going through them but in the mean time:
I am not using C language right now to send the HDLC code but yeah eventually I will have to once I get to know how and through which commands I can communicate to the controller.
A typical example of my HDLC frame is:
"7E 01 0A 00 FE FF 73 50 18 AD 7E"
Here 7E are the delimiters and each hex code has its own meaning according to the proprietorial information provided to me by the controller makers. Until now, I have been plainly writing this string on the minicom screen and hoping that the controller gets it and responds, but it doesn't respond to whatever I write.
Any light you can shed upon this issue?

Umair

You are sending the ASCII representation of binary data. To send HDLC frames, you need to be sending the raw binary form. I'm not sure, but I think you may be able to accomplish some interactive sending/receiving of binary data with serlook.

--- rod.

Is there any link confirming your comment that I should be sending out the binary form of my HDLC frame? because my understanding until now is that I need to make a Hex values frame, maybe add some delimiters and carriage return before/after the frame and write it on the minicom screen to be sent to the device connected.
I wonder that would be a nightmare if I need to send a raw binary data for so many HDLC frames -
See
http://www.lammertbies.nl/forum/viewtopic.php?t=607
and read under "Encoding an HDLC message frame".

Thanks!

The Wikipedia HDLC page explains the details. Among those details are particular bit patterns which are used at a low level for extraction of synchronization clock information when the link layer is not RS-232. So yes, definitely, you don't want to be sending ASCII-Hex strings. Framing of HDLC encoded data is done with headers and frame check sequences, not textual line oriented delimiters suh as carriage returns and line feeds.
ASCII-hex is just a way of allowing humans to be able to read the data in a printable form. Seldom is it a straight substitute for the raw binary data which it represents.
--- rod.

Hey theNbomr!

I tested responding back to the controller's "AT&FS0=1" command by writing "OK", but it didn't work. Honestly, I am not sure if I am typing up the AT commands in a right way. Her is what I am doing:
Controller sends me the command I can see on the Minicom screen ----> AT&FS0=1
In response, I plainly write (echo disabled, I can't see) ---> "OK" and press enter.
I feel something is wrong here because Minicom or controller won't take this as a command, rather some characters.

So my question is: Is there a special way to write commands in the Minicom, like using ~, ^M, etc signs?

Thanks!

I don't use minicom as a terminal emulator so I'm not sure if it has any capability to send non-printing bytes. It may also be that minicom translates the 'Enter' key to any combination of CR & LF (although this should be configurable).

Now, if my melon has retained anything that it knew about Hayes modem commands, I think the 'S0' register is used to set a modem to auto-answer, and setting it to 'one' means that it should auto answer on the first ring. If so, the controller is probably expecting something like a 'RING' response, followed by whatever else a modem spews out when it picks up an incoming call. I think that would include possibly the word 'CARRIER' &/or 'CONNECT'. Damn, I used to know this stuff...
This leads to some possibly bad news. If the controller is expecting your host to act like a modem, it may also require your host to control a lot of the non-data-carrying lines on the RS-232 port. Things like RTS, CTS, CD, DTR, etc. That is going to be a lot trickier than simply sending some bytes on the Tx line. For sure, no terminal emulator is going to be able to do that.
If, on the other hand, you are successful at spoofing the controller into thinking your host is a modem receiving a call, you might consider using C-Kermit as your terminal emulator. It does have the capability of sending raw binary data from files, and is highly scriptable.

--- rod.

Okay, on re-reading this thread, it is starting to make some sense. The controller is expecting to have someone log in by dialing up a connection on a modem. Your problem/question has now been transformed into 'How can I emulate a Hayes modem?'. One man's Hayes modem reference may help you get started.

--- rod.

Hey Rod!

First of all thanks for your comments. I installed the c-kermit and was able to establish connection with the remote device but the problem is that eventually I need to send my commands to the remote device using the C-language and using c-kermit won't help me (I think) understanding when and What I need to send to communicate effectively with the controller.

The other suggestion that you made, to emulate the Hayee's modem, looks logical and I went through that document that you linked in your post, but again my main concern is to know if writing plain commands on the minicom would help me or not? You wrote that no emulator is gonna do that for me, setting the control pins, then how would I ever be able to solve this problem?

Thanks!

Your problem may very well not be satisfied with a fully software solution. The relationship between a modem and a computer involves more than just the bits and bytes that travel as data. There is a specific behavior of signaling at the hardware level that may need to be implemented. It is quite possible that by using a properly configured cable and by also controlling the modem control lines from software (that you or someone will have to write), you will be able to spoof the controller into thinking that there is a modem picking up the line. It is also possible that the interface does rely entirely on the data transmitted and received, and if so that would make the problem a great deal simpler.
To really get a good view of the interface, I would start by connecting a real modem to a phone line, and hook up your C-Kermit emulator to it. Dial the number from another modem, and observe the data sent by the modem. This is very likely to be the data expected by the controller, and you can start by sending that data to the controller from an emulator, or from your own program.
If it was my project, I would fully expect to need some kind of test gear to monitor the interface; an oscilloscope would be best, or at minimum a DVM. It would also be extremely beneficial to get a good understanding of the nature of RS-232 communications. Finally, if your program is going to be written on a Linux platform, you will want to read and understand much of the programming-related mater in the documents I referenced earlier.
With respect to emulating a modem, you can do that interactively with a terminal emulator, at least form the standpoint of the ASCII data sent. All of the commands and result codes are conveyed using plain human-readable ASCII strings. I have used an emulator to talk to a modem many times (although I've never used one to emulate a modem, but the principle is the same).


--- rod.

Hey Rod!

I tried a couple of things like testing the signalling of my laptop, sending a different initialization string to the remote modem etc. My MINICOM program is working fine as long as it is connected to some other modem, but not the one I am trying to communicate with. I have come up with some other queries:
1. Is it really required to send the default initialization string Minicom sends to the remote modem? I mean what does it do?
2. Searching over the internet, i found that some people gave an idea of removing the reset string and init string from the minicom setup and then running the new saved profile by writing $minicom -o so am thinking maybe my laptop isn't sending the right init string for that specific controller. If so where can i get that specific init string?

I contacted the controller representatives and asked them of helping me connect with that controller using linux laptop. They have sent me some HDLC commands to write out to the controller. But the point they are missing is that controller is just NOT RESPONDING!

Regards!

I don't use minicom, and one of the reasons is that I don't want it to do anything that I don't tell it to do, and that includes sending anything like init strings of any sort. That's (one reason) why I prefer C-Kermit. It is entirely possible that minicom is confusing the whole process by sending that stuff. Strongly recommend to ditch it.

I'm a bit confused about what you're trying. My hypothesis is that the controller is expecting a Hayes compatible modem to be picking up an incoming call. The incoming call would be from a distant modem, of course. Have you tried connecting the controller to a modem in this way? Using a fully populated RS-232 cable? Were you able to use a second, distant modem to make a connection? If so, I would expect the controller to have seen the incoming call and subsequently been able to respond to the incoming queries, or possibly emit its own data.

Using this method, I would expect you to be able to divine what communication takes place between a real modem and the controller. Then, armed with this knowledge, make a wired connection directly, with no intervening modem pair. Once you know what data is transferred in each direction, you may be able to spoof the controller into thinking your linux host is a modem. Still, there may be a requirement to control the interface beyond just sending bytes.

Do you have any working system that communicates with the controller? Any evidence that the controller is actually functional?

--- rod.

Hey Rod!

I got successful in getting hold of the guys who built that sign controller. You were right in saying that the modem is trying to get a response like OK from linux to establish the connection. That guy asked me to try writing out number zero (0) and pressing enter in response to the "AT&FS0=1" string. But this didn't help either! So he asked me to tell him the whole process I was following. He also said that since there were some characters in the main string that I wanted to send out to the controller, like "7e 01 09 00 ff ff 53 42 bc b7 7e" string which the software might not be able to convert to hex before sending out to the controller. Rod, do you know what this is all about? I have no idea about what is happening and if the software is converting the characters to hex or not. Assuming hyperterminal of window 7, how can I tell the program to send out hex and not the ASCII?


Just like you, he also wasn't comfortable with me using minicom. He instead asked me of using hyperterminal on window7.
What I am trying to do is to first establish a connection with the controller so that I could send it some commands which that guy provided to me. The reason to do that is because i wanted to know if the controller can communicate or not because i didnt want to waste time writing a program and running it without knowing if the controller and my laptop are properly configured or not. But after a month I think I should have done it the other way around! That guy asked me to write a program which opens the tty0 port and writes out a simple hello world program. Rod, can you provide me a reliable link to any simple yet reliable code that i can build upon to communicate with the controller?

Controller is functional since it is a variable message sign controller and I have a hand held terminal which laymen use to run a message on the sign board. I can run it too on the message board and this justifies the controller is working fine!

Thanks and I hope I am near to solving this problem out soon! Looking forward for your helpful response -
Umair

The person you spoke to is reiterating what I said earlier about the difference between the ASCII representation of binary data, and the actual binary format. The string "7e 01 09 00 ff ff 53 42 bc b7 7e" is a bunch of ASCII characters that represent the digits of the 11 bytes of data. In order to send those 11 bytes, you will need to write code. In all likelihood, that will mean either reading the binary data from a file, or reading and translating the ASCII representation of the data, using something like scanf(), in C, or sending data that is hardcoded in the program. It is probable that there is also a conversational aspect to the data sent and received, where you will send some data, and receive some sort of response, so you will probably need to interpret the response data.
Using an interactive application like any terminal emulator in Linux or Windows may provide a means to establish the connection by spoofing the behavior of a modem, as all communication there is done using ASCII characters that you can type with a keyboard. It sounds very much like once the connection is established, further communication must use binary data; you mentioned sending HDLC frames. C-Kermit does have the capability to send arbitrary binary data from a file specified with the 'transmit' command. You may be able to exploit that mechanism to make a little more progress using an interactive tool.
The three links I cited in message #32 in this thread have working examples upon which to build your code. I think you need to get a good understanding of the distinction between the raw binary data and it's human-readable representation. This seems to be a source of confusion for you, and getting past that will be fundamental to your success. I would also emphasize the possibility that the data alone may not be the only part of the solution. There is a strong possibility that the receiving controller needs to see the behavior of a modem on all signals of its RS-232 interface. That is why I suggested performing a test using two modems, so you can actually make a dial-up connection for the purpose of testing. Fully implemented RS-232 communication involves more than just sending and receiving bytes.

--- rod.