View Full Version : Not receiving expected result from Comm_RECV
Hello,
New to thinBasic so please excuse the newbie question. I'm attempting to modify an existing sample script to send/receive commands to an Amateur Radio Transceiver. I'm sending a simple command to read the frequency as instructed in the manual (the "FA;" command, see attached). It is returning 3 bytes, instead of 12, and it appears to be binary instead of plain ASCII text (also attached). The COMM parameters are correct, as the radio is talking okay to various other software.
Here's the script template I used. Can anyone assist? I don't see much traffic in the COMM subforum. Thank you!
Uses "COMM"
Uses "CONSOLE"
Dim hcomm as Long
Dim sBuffer as string
Dim nBytes as Long
Dim errnumbr as Long
hcomm = COMM_FreeFile
COMM_Set(hcomm, %COMM_BAUD, 4800)
COMM_Set(hcomm, %COMM_BYTE, 8)
COMM_Set(hcomm, %COMM_NULL, False)
COMM_Set(hcomm, %COMM_PARITY, False)
COMM_SET(hcomm, %COMM_PARITYTYPE, 0)
COMM_Set(hcomm, %COMM_STOP, 2)
COMM_Set(hcomm, %COMM_RXBUFFER, 128)
'---Open the port
COMM_Open("COM4", hcomm)
If Err<>0 Then MsgBox 0, "Error opening comm port"
Comm_SEND(hcomm,"FA;")
Sleep 200
nBytes = COMM_GET(hcomm, %COMM_RXQUE) ' Get size of incoming data
Console_writeline(nBytes)
Comm_recv(hComm, nBytes, sBuffer)
Console_WriteLine(sBuffer)
Sleep 1000
'closing comm
COMM_Close(hcomm)
Console_WaitKey
After experimenting a bit, I found that after setting the RTS on the radio to "enable", the results were different (albeit still incorrect). The only settings available on the radio are RATE (set to 4800 baud), TIME OUT (10m sec), and RTS. So, I wonder if there are some flow control things I need to change in thinBasic?
Petr Schreiber
28-09-2020, 20:36
Hi Ray,
thanks for trying thinBASIC. May I kindly ask for the following information?:
- which version of thinBASIC do You run?
- could You please add the following lines at the end of Your program? It will allow You to view the binary data byte values:
dim byteValues(nBytes) as byte at strptr(sBuffer)
printl join$(byteValues, ", ")
- is there a manual available for Your ART?
- what does the thinBasic\SampleScripts\COMM\COMM_ListDevices.tbasic return for Your device?
Petr
Hello Petr,
Thank you for the reply, and sorry for the delay in getting back to you.
I am running version 1.10.7.0 (that's what thinAir is reporting in the "about" dialog).
I added the two lines of code and three bytes are displayed as: 254, 120, 126
It appears that no matter what command is sent, the radio returns the same 3 bytes. So, it's probably something simple, like mismatched baud rate? or number of stop bits? As I mentioned earlier, several communication software programs are talking to the radio without any problems.
Regards,
Ray
Petr Schreiber
01-10-2020, 14:42
Hi Ray,
thank you for your reply. Could you please try a bit fresher version 1.11.6.0?
https://www.thinbasic.biz/projects/thinbasic/thinBasic_1.11.6.0.zip
Let us know if the issue persists. Thanks a lot.
Petr
Hello again Petr,
Thank you for your patience.
I installed the latest version 1.11.6.0 after grappling with firewall and false virus warnings and tried again.
This time... I'm receiving a "Process - Runtime Error" (see attached). When using debug mode, the script posts the error immediately.
--Ray
Petr Schreiber
03-10-2020, 17:24
Hi Ray,
what I see on screenshot is not a sign of error - it is an automatic script CPU and Memory profiling, new feature in 1.11.x.x series. You will get this for any script launched from thinAIR.
Should you produce run time error, you would see the Run time tab active, here I see Process tab active, which is fine.
What does the console of your program display? Does it show anything this time?
Thank you,
Petr
Hi Ray,
what I see on screenshot is not a sign of error - it is an automatic script CPU and Memory profiling, new feature in 1.11.x.x series. You will get this for any script launched from thinAIR.
Should you produce run time error, you would see the Run time tab active, here I see Process tab active, which is fine.
What does the console of your program display? Does it show anything this time?
Thank you,
Petr
Hi Petr,
The console consistently displays "0", no matter what I try. The nBytes variable contains zero. Nothing is being returned. :(
Thanks,
Ray
EDIT: I set the baud rate down to 4800 in the script and on the device, and I did get something returned. Still not the correct data, however.
EDIT2: After trying all baud rates... it works! at 38400. Curious that it doesn't work at slower rates.
Petr Schreiber
04-10-2020, 20:00
Hi Ray,
I am happy to hear it worked :drink:. I do remember Eros refactored the COMM module recently, so good to hear 1.11.6.0 works.
As for why it works with higher baud rate... 38400 is 8x4800. That seems very suspiciously equivalent to relationship between bits and bytes. Could it be a clue? I am sadly not experienced with serial communication.
Petr
Hi Ray,
I am happy to hear it worked :drink:. I do remember Eros refactored the COMM module recently, so good to hear 1.11.6.0 works.
As for why it works with higher baud rate... 38400 is 8x4800. That seems very suspiciously equivalent to relationship between bits and bytes. Could it be a clue? I am sadly not experienced with serial communication.
Petr
Hey Petr,
Yes, I was happy too! However, I also got the program to run at 9600 baud after stepping through all the possible baud rates on both the radio and thinBasic. But now, the 38400 baud rate doesn't work again. Strange!
But, if can get one baud rate to stick, then I will continue with thinBasic for further development of my project.
Again, thank you for all the attention you have given this issue.
Regards,
Ray
Hello guys,
Can I introduce me in your conversation.
You can investigate more deeply in serial communication by using another PC
as a spy.
You connect another PC to the comm line between radio and pc running your ThinBasic program.
Obviously connecting only rx_data on the spy, and running on it a serial terminal emulation
like Putty or TTYEmulator , permetting hex display of received chars.
And also these programs allow easy changing of transmission charcteristics (rate, bits , parity etc)
And connecting spy input alternatively to each way of data ( from or to radio set)
The conversation I read from you tend to lead me to an incorrect setup of comm port.
I have no clues of what appends for you now, but from my past communication eng life, I always sayed
that between two comm devices unable to communicate, a third device I called in french :
"Juge de paix " can help.
Cordially.
Dany
Edit : I forgotted an important thing : For the spy PC you should not use an USB/serial adapter but a motherboard based
serial controller.