Serial Communication Question, Please

[jmltinc]

Decades too late, I am just learning RS-232 communication and the only resource that has a Com Port library is LabVIEW.  I am having problems understanding how I should send the data and really could use some pointers...

I have a Ham radio which I would like to communicate with through the computer.  It is as Plain Jane as you can get:

• 4800 Baud
• 1 Start Bit
• 8 Data Bits
• 2 Stop Bits
• No Parity
• No Flow Control

The radio expects 5 bytes - the first four are parameters either in BCD or Hex and a fifth Command code in Hex.  Any of the four Parameter bytes not needed are padded to provide 5 bytes, which the radio expects.

There are two commands I would like to send - one requires only the Hex command (and padded Parameter bytes); the other BCD Parameters.  Walk before I run...

1) The easiest is transferring the VFO contents from VFO-A to VFO-B.  The Command is 85 (Hex) with the four Parameter bytes padded (I tried zeros).  I had a friend create a simple routine in C++ and QT which does this nicely - so the radio works.  While I cannot see inside his exe, I presume the 5 bytes are 00 00 00 00 85.  

2) The other command is to change VFO-A to the frequency 14.250.00 MHz.  The parameters contained the frequency in BCD Packed Decimal) and the Command 0A (Hex) to complete the five bytes.  The five bytes are formatted as such:

Byte 1:  00

Byte 2:  50

Byte 3: 42

Byte 4:  01

Byte 5:  0A

Per the radio manufacturer, sent in this order will change the frequency.  But no matter what I try, I cannot even perform the simple task of copying VFO-A to B.  I have tried arrays writing within a loop, sending a string, typecasting, flattening - all examples I found online.  I don't know how LabVIEW handles data through VISA Write.  Worse, the radio manufacturer gives a BASIC example of command 2 (changing frequency) as:

Print #2

CHR$(&H00);CHR$H50);CHR$(&H42);CHR$(&H01);CHR$(&HA)

I recognize this BASIC syntax as converting Hex into String and sending them off to the Port, but cannot convert this in LabVIEW.

Yes, I use VISA Configure Port matching what the radio expects.  I think my problem is what I am feed VISA Write - I am hopelessly lost here.  I am not even sure 85H is 85 when sent as a string.  Are the 5 bytes converted to an array and sent as one string or sent in 5 iterations (if the latter, do I convert a single U8 from a byte array to a string?  If there is a conversion, what is it?

Thanks for helping the dinosaur.

John

 

 

[ensegre]

 

Edited yesterday at 08:48 PM by ensegre

[jmltinc]

I appreciate your quick response and (I think) I recreated your work.  But neither command does anything.  Is there something I am missing?

John

ensegre1.vi

[ensegre]

Can't say without seeing the rig's documentation (if at all good) and some amount of trial and error. These old devices may be quirky when it comes to response times (the internal uP has to interpret and to effect the command) and protocol requirements. Are you sure the message does not require an EOT or a checksum of some sort? Does the rig respond with some kind of ACK or error, which you could read back? Are you sure of your BCD encoding? Wikipedia lists so many flavours of it: https://en.wikipedia.org/wiki/Binary-coded_decimal 

If there are read commands, returning a known value, like the current frequency or the radio model, I would start with them, to make sure that the handshake works as expected.

[ShaunR]

When you know the baud and parity etc; issues that result in the instrument not responding at all are almost always the termination character.

Initalise the com port and try a few term chars (CR,LF, CR+LF). ensegre's example turns off the term char. You may just need to add 0D0A to the array.

There are examples shipped with LabVIEW and you can also play around with VISA using the NI MAX software.

Note that if you right click on the string control and select "Hex Display" you can enter the hex values:

[jmltinc]

Thank you for the thoughts.

The radio expects no termination characters.  it demands only 5 bytes - four Parameters and the fifth byte being a Hex Command, and 2 Stop Bits (and 4800 Baud, No Parity, No Flow Control).

The C++/QT exe built by another to test the radio (changes VFO-B to what is in VFO-A) works fine.  I have a USB to RS-232 adapter with a Female DB-9 so I configured it as another Serial Port to read what his exe is spitting-out to make sure my formatting is correct.  I wrote a VI to open and read the Com Port and return the string.  While I did not do a String to Byte Array conversion, the string outputs exactly what I am sending - the 5 bytes Null, Null, Null, Null, ... (without the commas).  This string corresponds with 0,0,0,0,85.  I am reasonably sure that the formatting is correct.  (Screenshot attached).

For the heck of it, I inserted a Property Node after configuring and opening the port to make sure nothing is amiss in the settings.  All settings returned are what I set (amended VI attached).  If I add the property Is Port Connected, the VI throws a Error-1073807331 The Specified attribute is not defined or supported by the referenced resource. Is it possible that I am missing something in how LabVIEW handles Serial Communications?

I appreciate your patience on this.  It seems there are several layers to VISA and I may be missing something here.

Thank you for your time and insight,

John

ensegre2.vi Read EXE File.vi

Edited 6 hours ago by jmltinc

[bbean]

6 hours ago, ShaunR said:

When you know the baud and parity etc; issues that result in the instrument not responding at all are almost always the termination character.

or there's an issue at the hardware level eg. the TX and RX pins are swapped

[ensegre]

Just to make sure - if you read 5 bytes, you get the first 5 bytes. If you increase the number to 'byte count', you would get a timeout warning if the other program really outputs only 5 bytes, but you would see the trailing ones, if there were.

Also, right-click the string indicator, check 'Hex display' may come handy.

[ensegre]

1 minute ago, bbean said:

or there's an issue at the hardware level eg. the TX and RX pins are swapped

i.e. crossover cable vs. null modem cable. But the OP says that the exe succeeds with the command, so that doesn't seem to be the issue here.

[ShaunR]

 "Port Connected" is only applicable to NI products and doesn't work with OS Com Ports.

[jmltinc]

ShaunR, I realized that exception 90 minutes after I posted.  I removed the property - thanks for the heads-up.

Yes, ensegre, the cable is a straight cable and the C++/QT exe works fine.  If I increase the byte count, it does time-out and error.

I am totally flummoxed as to what might be the problem...

 

Thanks, Folks.