[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linrad] little programs to control Ft1000 MP on another computer from within Linrad
Hello, All!
I took Dan's suggestion and with help from Leif I was able to write a
visual basic program for the windows machine and c code to go within
Linrad that is enough for now for me to easily use the FT1000MP Mk V
here as the transmitter with Linrad receiving. I have not yet
implemented the LO switching, and don't know when/if I will do that, as
this is fully functional for my purposes for doing 144 MHz CW EME.
Here is what the pair of programs does:
1. With Linrad running, when I type "Q" it takes the current AFC
frequency and sends that over the serial port from the Linrad machine to
the Windows machine.
2. The windows machine receives the frequency via its serial port
(com9) and massages the data to a) correct for the frequency error of
the FT1000MP / LT2S MK II tranverter combination (200 Hz) relative to Linrad
b) put it into the backwards BCD coded format that the FT1000MP
expects and
c) displays the data in a little window on the Windows machine
and sends it to the FT1000MP via the serial port com8 on the windows
machine..
The limitations of the program that are immediately recognized are
1. It doesn't know the LO frequency, so it alwayss assumes the band
segement is 144.000 to 144.100. Not a problem for MY eme use.
2. I have a single correction 'offset' programmed in. If this
changes with my current program I must recompile it.
3. It only works for the Ft1000MP, and only if COM9 is receiving the
Linrad data, and COM8 is sending it to the MP.
4. It requires some manual input (typing 'Q' in Linrad) to send the
data to the Ft1000 MP.
5. IT only works if the AFC is on in Linrad.
6. I have to dial in the Doppler offset using the tx clarifier
control on the FT1000MP.
None of these is a major problem for me so I am quite happy with the
result. With Leif's pointing me to the correct variables within Linrad
it was really not difficult at all. My main stumbling block was that it
took me a while to figure out that I had to enable both DTR and RTS on
the windows com port for the two machines to talk to one another. Once
that was figured out, everything fell into place with Leif's gracious
help and great expertise.
The changes required in Linrad were minimal
1. adding the statement
#include "serialtest2.c"
to the include statements at the beginning of wcw.c
2. adding after the 3 "case 'F' statements further down in wcw.c the
statements
case 'Q';
serialtest2();
break;
3. putting the file serialtest2.c in the linrad directory. This file
consists of the following statements:
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <termios.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <stdlib.h>
void serialtest2(void)
{
char ft2[80];
int n;
char ft[80];
float freq;
int fd1; /* file descriptor for the port */
struct termios options;
fd1=0;
fcntl(fd1,F_SETFL,0);
fd1=open("/dev/ttyS0",O_RDWR | O_NOCTTY | O_NDELAY);
fcntl(fd1,F_SETFL,0);
if (fd1 == -1)
{
perror("open_port: Unable to open /dev/ttyS0 - ");
}
else
/* set up port parameters */
tcgetattr(fd1,&options);
cfsetispeed(&options,B9600);
cfsetospeed(&options,B9600);
options.c_cflag |= (CLOCAL | CREAD);
/* No parity */
options.c_cflag &= ~PARENB;
options.c_cflag |= ~CSTOPB;
options.c_cflag &= ~CSIZE;
options.c_cflag |= CS8;
options.c_oflag &= ~OPOST;
tcsetattr(fd1, TCSANOW,&options);
freq=(((mix1_fq_mid[fftx_nx])/1000)+28000)*1000;
sprintf(ft,"%6f",freq);
strncpy(ft2,ft,8);
strcat(ft2,"r");
n=write(fd1,ft2,9); /*send data to the port */
return;
}
--------------end of code.
Then you just do ./configure and make and run linrad. No errors should
result (I get none here).
The visual basic code on the other end is not difficult either. It is,
for the main module, "serial"
======================================
Public instring As String
Public fr, freq As String
Public b1, b2, b3, b4, b5 As String
Public f1, f2, f3, f4 As String
Public c1, c2, c3, c4, c5 As Variant
Public freqflo As Double
Public freqlon As Long
Public h As String
Private Sub Command2_Click()
Close
MSComm1.PortOpen = False
Unload Form1
Unload Form1
End
End Sub
Rem com 9 is rocketport P6 is hooked to P4 running Linrad
Rem com 8 is rocketport P5 is hooked to FT1000
Private Sub Form_Load()
h = "&H"
Form1.Show
linsend:
' Use COM9.
MSComm1.CommPort = 9
MSComm1.InputMode = comInputModeText
' 9600 baud, no parity, 8 data, and 2 stop bits.
MSComm1.Settings = "9600,N,8,2"
MSComm1.DTREnable = True
MSComm1.RTSEnable = True
MSComm1.RThreshold = 1
MSComm1.PortOpen = True
MSComm1.InBufferCount = 0
instring = ""
Do
DoEvents
instring = instring & MSComm1.Input
Loop Until Right(instring, 1) = "r"
Text3.Text = Left$(instring, 8)
freq = instring
MSComm1.PortOpen = False
freqflo = Val(freq)
freqflo = freqflo / 10
freqlon = CLng(freqflo)
freqlon = freqlon - 20 + 20000
freq = CStr(freqlon)
f1 = Mid$(freq, 6, 2)
f2 = Mid$(freq, 4, 2)
f3 = Mid$(freq, 2, 2)
f4 = Left$(freq, 1)
b1 = h & f1
b2 = h & f2
b3 = h & f3
b4 = h & f4
c1 = Val(b1)
c2 = Val(b2)
c3 = Val(b3)
c4 = Val(b4)
c5 = &HA
MSComm1.CommPort = 8
MSComm1.InputMode = comInputModeText
' 4800 baud, no parity, 8 data, and 2 stop bits.
MSComm1.Settings = "4800,N,8,2"
' Tell the control to read entire buffer when Input
' is used.
MSComm1.RTSEnable = False
MSComm1.RThreshold = 1
MSComm1.InputLen = 0
MSComm1.InBufferCount = 0
' Open the port.
MSComm1.PortOpen = True
fr = Chr$(c1) & Chr$(c2) & Chr$(c3) & Chr$(c4) & Chr$(c5)
MSComm1.Output = fr
MSComm1.PortOpen = False
GoTo linsend
End Sub
Private Sub MSComm_OnComm()
Select Case MSComm1.CommEvent
' Handle each event or error by placing
' code below each case statement
' Errors
Case comEventBreak ' A Break was received.
Print "break"
Case comEventCDTO ' CD (RLSD) Timeout.
Print "CD timeout"
Case comEventCTSTO ' CTS Timeout.
Print "CTS timeout"
Case comEventDSRTO ' DSR Timeout.
Print "DSR timeout"
Case comEventFrame ' Framing Error
Print "framing error"
Case comEventOverrun ' Data Lost.
Print "data lost"
Case comEventRxOver ' Receive buffer overflow.
Print "Rx buffer overflow"
Case comEventRxParity ' Parity Error.
Print "parity error"
Case comEventTxFull ' Transmit buffer full.
Case comEventDCB ' Unexpected error retrieving DCB]
' Events
Case comEvCD ' Change in the CD line.
Print "CD line change"
Case comEvCTS ' Change in the CTS line.
Print "CTS change"
Case comEvDSR ' Change in the DSR line.
Print "DSR change"
Case comEvRing ' Change in the Ring Indicator.
Print "ring"
Case comEvReceive ' Received RThreshold # of
Print "received chars"
' chars.
Case comEvSend ' There are SThreshold number of
' characters in the transmit
' buffer.
Print "Threshold"
Case comEvEOF ' An EOF charater was found
in ' the input stream
Print "EOF found"
End Select
End Sub
==================
End of code.
You just run linrad at one end and run the windows visual basic program
at the other end and everything is hunky dory.
I hope this is helpful to someone wanting to build their own program.
It makes using Linrad with another transmitter much easier. And as you
can see, the modifications to Linrad are Minimal.
73,
Roger
W3SZ
Dan Hammill wrote:
> Hi Roger,
>
> I have a suggestion re. using the NI GPIB in your WindBlowz
> machine for auto-control with Linrad. Treat the Microsoft
> box with the NI card as a RS-232 controlled instrument by
> writing a small VB or C app (or LabVIEW, or HP VEE, etc.)
> that takes serial commands from the Linrad machine via
> RS-232, then routes them to the signal generator via GPIB.
> Do just the reverse if you want to get a response from the
> sig gen with Linrad. Same goes for any other I/O hardware
> that works under Windoze but not under Linux.
>
> I've actually done something very similar to this in my
> professional life, and it worked very well. The bad news
> is that I was a good boy and didn't take the code home
> with me when I left that company several years ago. In
> retrospect, that company no longer exists, but I still do,
> so I guess it really wouldn't have mattered to anyone but
> me in the long run.
>
> I also have a NI AT-GPIB board, so I guess there really is
> a good reason to keep my old ISA/PCI Pentium machines.
>
> 73,
> Dan KB5MY
>
LINRADDARNIL