Hello,
Just got hold of an old HP436A power meter and would like to do some automated measurements. Controlling the instrument is simple using the 82357B USB-GPIB module (I can set range etc), but reading data? As a first step I'd like to test using Agilent Interactive IO from Connection Expert. If that works, I'm fairly sure I can get it working in a program also.? The 436 is set to NORMAL, i.e., not TALK ONLY. It does have the HP-IB option 022 installed. My guess is that I need to address the instrument to Talk in some other way than the "Read Response" used in Interactive IO.
Anyone with experience of this?
Regards, ? Staffan
|
Hi Staffan
Yes, you need to meter to be in addressable mode (or as you say,
"normal").
If you use the interactive IO, you would use the "Send and Read"..?
Type the command to fetch the reading in the text box, and use the
"Send and Read" button, which will set the computer as the talker,
send the command, and then it sets it up so the meter is the
talker.? You should see the results show up in the history below.?
It puts the actual results there, with no additional formatting so
you can see exactly what it sends back.? Of course you can also do
it individually using the separate "Send Command" and "Read
Response" as well. The "Send and Read" just combines the two
actions.
What language do you plan to use for your program?
Daun
On 11/17/2018 4:52 PM, Staffan wrote:
Hello,
Just got hold of an old HP436A power meter and would like to do
some automated measurements. Controlling the instrument is simple
using the 82357B USB-GPIB module (I can set range etc), but
reading data? As a first step I'd like to test using Agilent
Interactive IO from Connection Expert. If that works, I'm fairly
sure I can get it working in a program also.?
The 436 is set to NORMAL, i.e., not TALK ONLY. It does have the
HP-IB option 022 installed. My guess is that I need to address the
instrument to Talk in some other way than the "Read Response" used
in Interactive IO.
Anyone with experience of this?
Regards,
? Staffan
--
Daun E. Yeagley II, N8ASB
|
Hello,
Thanks for the suggestion. I have tried this, but it doesn't seem?to work. Any recommendations to how I should configure Interactive IO? I will use Visual Basic in Excel for later programming - hopefully using Agilent VISA libraries... ? In general, anyone with experience of communicating over USB-GPIB 82357 with _very_ old instruments (single character commands etc...)? Is there a fundamental limitation?
Is there any way of performing low level communication/control of the 82357, i.e., controlling the separate digital lines?
Regards, ? Staffan?
toggle quoted message
Show quoted text
On Sun, Nov 18, 2018 at 2:45 AM Daun Yeagley < daun@...> wrote:
Hi Staffan
Yes, you need to meter to be in addressable mode (or as you say,
"normal").
If you use the interactive IO, you would use the "Send and Read"..?
Type the command to fetch the reading in the text box, and use the
"Send and Read" button, which will set the computer as the talker,
send the command, and then it sets it up so the meter is the
talker.? You should see the results show up in the history below.?
It puts the actual results there, with no additional formatting so
you can see exactly what it sends back.? Of course you can also do
it individually using the separate "Send Command" and "Read
Response" as well. The "Send and Read" just combines the two
actions.
What language do you plan to use for your program?
Daun
On 11/17/2018 4:52 PM, Staffan wrote:
Hello,
Just got hold of an old HP436A power meter and would like to do
some automated measurements. Controlling the instrument is simple
using the 82357B USB-GPIB module (I can set range etc), but
reading data? As a first step I'd like to test using Agilent
Interactive IO from Connection Expert. If that works, I'm fairly
sure I can get it working in a program also.?
The 436 is set to NORMAL, i.e., not TALK ONLY. It does have the
HP-IB option 022 installed. My guess is that I need to address the
instrument to Talk in some other way than the "Read Response" used
in Interactive IO.
Anyone with experience of this?
Regards,
? Staffan
--
Daun E. Yeagley II, N8ASB
|
Hi re? HPIB
?
I am not a computer programmer but I either
use? HP basic 4.1 with a HP computer that has a HPIB port
?or ?national instruments lab view
?on windows xp ??and the hardware is either a NI card for the PC
or a NI ???USB converter
Paul B ??south cost UK
?
?
Hello,
Thanks for the suggestion. I have tried this, but it doesn't
seem?to work. Any recommendations to how I should configure Interactive
IO? I will use Visual Basic in Excel for later programming - hopefully using
Agilent VISA libraries...
In general, anyone with experience of communicating over USB-GPIB 82357
with _very_ old instruments (single character commands etc...)? Is there a
fundamental limitation?
Is there any way of performing low level communication/control of the
82357, i.e., controlling the separate digital lines?
?
toggle quoted message
Show quoted text
On Sun, Nov 18, 2018 at 2:45 AM Daun Yeagley <daun@...> wrote:
Hi Staffan
Yes, you need to meter to be in addressable mode (or as you say, "normal").
If you use the interactive IO, you would use the "Send and
Read"..? Type the command to fetch the reading in the text box, and
use the "Send and Read" button, which will set the computer as the
talker, send the command, and then it sets it up so the meter is the
talker.? You should see the results show up in the history below.? It
puts the actual results there, with no additional formatting so you can see
exactly what it sends back.? Of course you can also do it individually
using the separate "Send Command" and "Read Response" as
well. The "Send and Read" just combines the two actions.
What language do you plan to use for your program?
Daun
On 11/17/2018 4:52 PM, Staffan wrote:
Hello,
Just got hold of an old HP436A power meter and would like to do some automated
measurements. Controlling the instrument is simple using the 82357B USB-GPIB
module (I can set range etc), but reading data? As a first step I'd like to
test using Agilent Interactive IO from Connection Expert. If that works, I'm
fairly sure I can get it working in a program also.?
The 436 is set to NORMAL,
i.e., not TALK ONLY. It does have the HP-IB option 022 installed. My guess is
that I need to address the instrument to Talk in some other way than the
"Read Response" used in Interactive IO.
Anyone with experience of this?
Regards,
? Staffan
?
--
Daun E. Yeagley II, N8ASB
No virus found in this message.
Checked by AVG -
Version: 2016.0.8048 / Virus Database: 4793/15883 - Release Date: 08/14/18
Internal Virus Database is out of date.
|
Many older instruments don't use the EOI line, but also "Must" have the correct command terminator byte (if one is specified) no more, no less..
It'll all be documented in the individual instruments manual.? The fun bit these days is getting "modern" bus controllers to play nice with older non IEE488.2 devices.
Don't rely on the more modern high level function calls, start with the low level byte by byte stuff, and run a bus traffic capture too, guessing Agilent has an equivalent to NI's 'I/O Trace' (was NI Spy) program.
Regards
Dave B (G0WBX)
|
Hello,
I can control the instrument so I guess termination is correct, but reading isn't working. I'd really like to do the low level byte by byte communication, but anyone knows hos to do this with 82357? Any hints would be highly appreciated!
Regards, ? Staffan
|
Staffan,
Have a look at python?
I am from the generation that used to use FORTRAN IV and punchcards but you have to move up with times at some point. Python has a few?idiosyncrasies that drive me mad but it's here to stay
I am using python as a goto choice for all my GPIB needs now.
Leo
toggle quoted message
Show quoted text
On 18 Nov 2018, at 15:55, Staffan wrote: Hello,
I can control the instrument so I guess termination is correct, but reading isn't working. I'd really like to do the low level byte by byte communication, but anyone knows hos to do this with 82357? Any hints would be highly appreciated!
Regards, ? Staffan
|
And if you're into Linux, there is a GPIB driver package available with bindings for python and perl. It's at
and supports USB adapters as well as older boards.
John ----
toggle quoted message
Show quoted text
On 11/18/18 11:14 AM, Leo Bodnar wrote: Staffan, Have a look at python I am from the generation that used to use FORTRAN IV and punchcards but you have to move up with times at some point. Python has a few?idiosyncrasies that drive me mad but it's here to stay I am using python as a goto choice for all my GPIB needs now. Leo On 18 Nov 2018, at 15:55, Staffan wrote:
Hello,
I can control the instrument so I guess termination is correct, but reading isn't working. I'd really like to do the low level byte by byte communication, but anyone knows hos to do this with 82357? Any hints would be highly appreciated!
Regards, ? Staffan
|
Hello,
Thanks for the suggestions. I tried to figure out how to do low-level communication, but don't seem to find any way.? I hope I'm just missing something trivial here. If anyone has an example of communicating with the 436 (or similar - old HP-IB) using 82357 USB-GPIB, preferably using the VISA library, that would be the best - that would give a good starting point for digging further.
Regards, ? Staffan
|
Hello,
Short update. Just recalling I had an Arduino setup for GPIB-USB (many thanks to Emanuele Girlando!). It works using that one to do a ++read and get a response, but then I don't seem to be able to write to the instrument...
Any hints on doing everything on 82357 would be much appreciated...
Regards, ? Staffan
|
Steffan...
Maybe I missed you saying so, but with the Keysight IOLibraries installed the 82357A/B should be essentially transparent to you. Connection Expert will let you assign it a name such as GPIB0 and then you just send commands to the 436's address. I don't recall the exact details but there is a box to check to use 488.2 vintage protocol but that's about it. Unless there is something amiss with it, I doubt that the adapter is the problem. Since it appears to be at least sending commands, that doesn't seem likely.
From Tom Holmes, N8ZM
|
Hello,
Some more findings... It seems like my Arduino can talk to the instrument after all. Pulling REN low (active) makes it listen to commands sent to its listen address.? However, with the REN (remote enable) active, it _won't_ return any readings! Releasing REN, I get readouts again...
Can it be that the 82357B keeps the REN line low the whole time it has the instrument addressed? If so, anyone can hint me how to pull it high when I want to read from the instrument?
Thanks to the code in the Arduino project (again, thanks to Emanuele Girlando!) I'm fairly sure what sequence to send (control lines). Anyone know how this can be bit-banged (for example) on the 82357B? The Interactive IO does not give many options unfortunately.
Regards, ? Staffan ? Staffan
toggle quoted message
Show quoted text
On Mon, Nov 19, 2018 at 2:07 PM Tom Holmes < tholmes@...> wrote: Steffan...
Maybe I missed you saying so, but with the Keysight IOLibraries installed the 82357A/B should be essentially transparent to you. Connection Expert will let you assign it a name such as GPIB0 and then you just send commands to the 436's address.
I don't recall the exact details but there is a box to check to use 488.2 vintage protocol but that's about it. Unless there is something amiss with it, I doubt that the adapter is the problem. Since it appears to be at least sending commands, that doesn't seem likely.
From Tom Holmes, N8ZM
|
Hi Saffan, I sent you in PM some military manual for 436A. Go from page 3-18 onward, there is about HPIB communication. Milan
toggle quoted message
Show quoted text
Hello,
Some more findings... It seems like my Arduino can talk to the instrument after all. Pulling REN low (active) makes it listen to commands sent to its listen address.? However, with the REN (remote enable) active, it _won't_ return any readings! Releasing REN, I get readouts again...
Can it be that the 82357B keeps the REN line low the whole time it has the instrument addressed? If so, anyone can hint me how to pull it high when I want to read from the instrument?
Thanks to the code in the Arduino project (again, thanks to Emanuele Girlando!) I'm fairly sure what sequence to send (control lines). Anyone know how this can be bit-banged (for example) on the 82357B? The Interactive IO does not give many options unfortunately.
Regards, ? Staffan ? Staffan
On Mon, Nov 19, 2018 at 2:07 PM Tom Holmes < tholmes@...> wrote: Steffan...
Maybe I missed you saying so, but with the Keysight IOLibraries installed the 82357A/B should be essentially transparent to you. Connection Expert will let you assign it a name such as GPIB0 and then you just send commands to the 436's address.
I don't recall the exact details but there is a box to check to use 488.2 vintage protocol but that's about it. Unless there is something amiss with it, I doubt that the adapter is the problem. Since it appears to be at least sending commands, that doesn't seem likely.
From Tom Holmes, N8ZM
|
Hello,
Many thanks. Notice that I replied to your direct mail. I don't think the problem lies in the 436, but rather in how the USB dongle 82357 performs communication. Don't know if the GPIB standard was updated - 488.2 seems to be from 1992, whereas the instrument predates 1980. It would be great to have a configuration within VISA to support different standards for different instruments - or is this perhaps not needed? Sounds strange that there shouldn't be sufficient backwards compatibility for a data bus!
Regards, ? Staffan
|
Hi Staffan
The physical layer for IEE-488 itself is essentially unchanged from
the original.? 488.2 deals more with the messaging protocol.
This is where all the "universal" commands originated (all the *
commands like *IDN?, etc.).
If you saw my PM to you a bit ago, you saw an example of a
"non-488.2" communication using the Agilent IO libraries.? In other
words, those nifty commands are not available to the old "R2D2"
command structure instruments.? I guess I'll include that listing
here, for others to see as well.? This code sets up and gets
readings from an HP3478A voltmeter, which is pre-488.2 (R2D2
"language")
Daun
Daun E. Yeagley II, N8ASB
On 11/19/2018 4:01 PM, Staffan wrote:
toggle quoted message
Show quoted text
Hello,
Many thanks. Notice that I replied to your direct mail. I don't
think the problem lies in the 436, but rather in how the USB
dongle 82357 performs communication. Don't know if the GPIB
standard was updated - 488.2 seems to be from 1992, whereas the
instrument predates 1980. It would be great to have a
configuration within VISA to support different standards for
different instruments - or is this perhaps not needed? Sounds
strange that there shouldn't be sufficient backwards compatibility
for a data bus!
Regards,
? Staffan
|
Hello,
Is this working with the 82357, it would be a great starting point. Although I just don’t understand why interactive IO doesn’t work.?
Has anyone experienced differences between interactive IO and using the libraries - I guess interactive IO just is an interface to the libs?
My best bet right now is that REN should be controlled (pulled inactive) for reading data from the 436. I just don’t know how to test this with the 82357/VISA libraries.?
Regards, ?Staffan
toggle quoted message
Show quoted text
On Monday, November 19, 2018, Daun Yeagley < daun@...> wrote:
Hi Staffan
The physical layer for IEE-488 itself is essentially unchanged from
the original.? 488.2 deals more with the messaging protocol.
This is where all the "universal" commands originated (all the *
commands like *IDN?, etc.).
If you saw my PM to you a bit ago, you saw an example of a
"non-488.2" communication using the Agilent IO libraries.? In other
words, those nifty commands are not available to the old "R2D2"
command structure instruments.? I guess I'll include that listing
here, for others to see as well.? This code sets up and gets
readings from an HP3478A voltmeter, which is pre-488.2 (R2D2
"language")
Daun
Daun E. Yeagley II, N8ASB
On 11/19/2018 4:01 PM, Staffan wrote:
Hello,
Many thanks. Notice that I replied to your direct mail. I don't
think the problem lies in the 436, but rather in how the USB
dongle 82357 performs communication. Don't know if the GPIB
standard was updated - 488.2 seems to be from 1992, whereas the
instrument predates 1980. It would be great to have a
configuration within VISA to support different standards for
different instruments - or is this perhaps not needed? Sounds
strange that there shouldn't be sufficient backwards compatibility
for a data bus!
Regards,
? Staffan
|
Hi,
Red Herring alert!
FWIW I use Prologix interfaces (with the 'auto-read-after-write'
feature disabled) and program using mostly AutoIT or EZGpib/Pascal
s but I don't have to treat the 436 or 438 any different from any
other HP or Tek instrument as far as reading data is concerned.
Adrian
On 11/20/2018 7:15 AM, Staffan wrote:
toggle quoted message
Show quoted text
Hello,
Is this working with the 82357, it would be a great starting
point. Although I just don’t understand why interactive IO
doesn’t work.?
Has anyone experienced differences between interactive IO and
using the libraries - I guess interactive IO just is an
interface to the libs?
My best bet right now is that REN should be controlled
(pulled inactive) for reading data from the 436. I just don’t
know how to test this with the 82357/VISA libraries.?
Regards,
?Staffan
On Monday, November 19, 2018, Daun Yeagley < daun@...>
wrote:
Hi Staffan
The physical layer for IEE-488 itself is essentially
unchanged from the original.? 488.2 deals more with the
messaging protocol.
This is where all the "universal" commands originated (all
the * commands like *IDN?, etc.).
If you saw my PM to you a bit ago, you saw an example of a
"non-488.2" communication using the Agilent IO libraries.?
In other words, those nifty commands are not available to
the old "R2D2" command structure instruments.? I guess I'll
include that listing here, for others to see as well.? This
code sets up and gets readings from an HP3478A voltmeter,
which is pre-488.2 (R2D2 "language")
Daun
Daun E. Yeagley II, N8ASB
On 11/19/2018 4:01 PM, Staffan wrote:
Hello,
Many thanks. Notice that I replied to your direct mail. I
don't think the problem lies in the 436, but rather in how
the USB dongle 82357 performs communication. Don't know if
the GPIB standard was updated - 488.2 seems to be from
1992, whereas the instrument predates 1980. It would be
great to have a configuration within VISA to support
different standards for different instruments - or is this
perhaps not needed? Sounds strange that there shouldn't be
sufficient backwards compatibility for a data bus!
Regards,
? Staffan
|
A simple task...
But it is NOT IEE488.2 compliant, so will not respond to such things as *IDN? etc.? (In fact, traffic like that can totally mess it up at times, as can other automated tricks to attempt to catalogue "live" devices on the bus..)
Modern GPIB systems will handle all the global un-listen, selected device addressing and so on for you, making life much easier.? If you create your own GPIB controller, you have to do all that yourself.
Make sure you know it's device address on the bus.? Ours is defaulted to a primary address of '13' (decimal.)??? AFIK (oddly, I cant find the detail in our manual!)? The address setting is a bank of switches internally.??? If you need to "scan the bus" to find it, you may need to manually reset the thing after you know it's address, as it's a simple state machine in hard logic internally, and can get "upset" by command data it cant understand.
Anyway, when you know it's bus address...?? And it's Talk Mode is set to "Normal".
Send it the command '9A+I' (not the quotes!) with no trailing terminator byte, with or without EOI asserted, it doesn’t care about that.? That command instructs it to send back a reading scaled in Watts.? (Or '9D+I' in which case It will scale in dB/dBm.)
Use Watt's initially, as a no input signal condition, will still result in a valid reading!
Give it a little time to figure things out...
When you then ask the system to read back the resulting "measurement".
The 436A will send a 14 byte fixed format ASCII string to the controller, ending in a CR/LF pair, so your GPIB system needs to be configured to stop reading when it sees a LF byte (ASCII code 10, or 0x0A)? The 436A does not use the EOI line, so you MUST configure your bus controller to recognise that LF byte to signify the end of it's reply, or to stop reading after 14 bytes have been received.
The first byte (byte 0) is the status. ('P' = valid reading.? Anything else is under/over range.)
Bytes 3 to 11 represent the measured value, in scientific format (Mantissa).
Byte 3 is a sign (ASCII space = +) or and ASCII -
Bytes 4..7 are the measured value, an implied decimal point is immediately after byte 7.
Byte 8 is always an 'E'.
Byte 9 is always a - sign.
Bytes 10 .. 11 is the Exponent.
Bytes 12..13 are CR/LF
It's all ASCII characters, so no "funny" stuff.
The above comes from table 3-4 on page 3-25 of the operating and service manual.
It's up to you to process that string to test for validity, and extract the value.
It is highly recommended to get a copy of at operator/service manual.? (I only have a dead tree version.)
Hope this helps.
Dave B (G0WBX)
-- Created on and sent from a Unix like PC running and using free and open source software. ::
|
Hello,
Many thanks. I have been successful in all the steps you mention using the Arduino converter, but I need to activate REN for sending a command and then deactivate REN before reading.? This is not possible (controlling REN) using 82357 - or is there a way? I’m fairly sure this is the issue with the 436 (REN).
Regards, ?Staffan
toggle quoted message
Show quoted text
On Tuesday, November 20, 2018, Dave_G0WBX via Groups.Io <g8kbvdave= [email protected]> wrote: A simple task...
But it is NOT IEE488.2 compliant, so will not respond to such things as
*IDN? etc.? (In fact, traffic like that can totally mess it up at times,
as can other automated tricks to attempt to catalogue "live" devices on
the bus..)
Modern GPIB systems will handle all the global un-listen, selected
device addressing and so on for you, making life much easier.? If you
create your own GPIB controller, you have to do all that yourself.
Make sure you know it's device address on the bus.? Ours is defaulted to
a primary address of '13' (decimal.)??? AFIK (oddly, I cant find the
detail in our manual!)? The address setting is a bank of switches
internally.??? If you need to "scan the bus" to find it, you may need to
manually reset the thing after you know it's address, as it's a simple
state machine in hard logic internally, and can get "upset" by command
data it cant understand.
Anyway, when you know it's bus address...?? And it's Talk Mode is set to
"Normal".
Send it the command '9A+I' (not the quotes!) with no trailing terminator
byte, with or without EOI asserted, it doesn’t care about that.? That
command instructs it to send back a reading scaled in Watts.? (Or '9D+I'
in which case It will scale in dB/dBm.)
Use Watt's initially, as a no input signal condition, will still result
in a valid reading!
Give it a little time to figure things out...
When you then ask the system to read back the resulting "measurement".
The 436A will send a 14 byte fixed format ASCII string to the
controller, ending in a CR/LF pair, so your GPIB system needs to be
configured to stop reading when it sees a LF byte (ASCII code 10, or
0x0A)? The 436A does not use the EOI line, so you MUST configure your
bus controller to recognise that LF byte to signify the end of it's
reply, or to stop reading after 14 bytes have been received.
The first byte (byte 0) is the status. ('P' = valid reading.? Anything
else is under/over range.)
Bytes 3 to 11 represent the measured value, in scientific format (Mantissa).
Byte 3 is a sign (ASCII space = +) or and ASCII -
Bytes 4..7 are the measured value, an implied decimal point is
immediately after byte 7.
Byte 8 is always an 'E'.
Byte 9 is always a - sign.
Bytes 10 .. 11 is the Exponent.
Bytes 12..13 are CR/LF
It's all ASCII characters, so no "funny" stuff.
The above comes from table 3-4 on page 3-25 of the operating and service
manual.
It's up to you to process that string to test for validity, and extract
the value.
It is highly recommended to get a copy of at operator/service manual.?
(I only have a dead tree version.)
Hope this helps.
Dave B (G0WBX)
--
Created on and sent from a Unix like PC running and using free and open source software.
::
|
REN should not be deactivated to take a reading. 436 must stay in Remote. I have sent you a 436A Operating and Service Manual. Read Section 3. ? Bill Lauchlan ?
toggle quoted message
Show quoted text
From: [email protected] [mailto:[email protected]] On Behalf Of Staffan Sent: Tuesday, November 20, 2018 8:13 AM To: [email protected] Subject: Re: [HP-Agilent-Keysight-equipment] Readings from 436A power meter using 82357B USB-GPIB?? Hello, Many thanks. I have been successful in all the steps you mention using the Arduino converter, but I need to activate REN for sending a command and then deactivate REN before reading.? This is not possible (controlling REN) using 82357 - or is there a way? I’m fairly sure this is the issue with the 436 (REN). ?Staffan
On Tuesday, November 20, 2018, Dave_G0WBX via Groups.Io <g8kbvdave=[email protected]> wrote: A simple task...
But it is NOT IEE488.2 compliant, so will not respond to such things as *IDN? etc.? (In fact, traffic like that can totally mess it up at times, as can other automated tricks to attempt to catalogue "live" devices on the bus..)
Modern GPIB systems will handle all the global un-listen, selected device addressing and so on for you, making life much easier.? If you create your own GPIB controller, you have to do all that yourself.
Make sure you know it's device address on the bus.? Ours is defaulted to a primary address of '13' (decimal.)??? AFIK (oddly, I cant find the detail in our manual!)? The address setting is a bank of switches internally.??? If you need to "scan the bus" to find it, you may need to manually reset the thing after you know it's address, as it's a simple state machine in hard logic internally, and can get "upset" by command data it cant understand.
Anyway, when you know it's bus address...?? And it's Talk Mode is set to "Normal".
Send it the command '9A+I' (not the quotes!) with no trailing terminator byte, with or without EOI asserted, it doesn’t care about that.? That command instructs it to send back a reading scaled in Watts.? (Or '9D+I' in which case It will scale in dB/dBm.)
Use Watt's initially, as a no input signal condition, will still result in a valid reading!
Give it a little time to figure things out...
When you then ask the system to read back the resulting "measurement".
The 436A will send a 14 byte fixed format ASCII string to the controller, ending in a CR/LF pair, so your GPIB system needs to be configured to stop reading when it sees a LF byte (ASCII code 10, or 0x0A)? The 436A does not use the EOI line, so you MUST configure your bus controller to recognise that LF byte to signify the end of it's reply, or to stop reading after 14 bytes have been received.
The first byte (byte 0) is the status. ('P' = valid reading.? Anything else is under/over range.)
Bytes 3 to 11 represent the measured value, in scientific format (Mantissa).
Byte 3 is a sign (ASCII space = +) or and ASCII -
Bytes 4..7 are the measured value, an implied decimal point is immediately after byte 7.
Byte 8 is always an 'E'.
Byte 9 is always a - sign.
Bytes 10 .. 11 is the Exponent.
Bytes 12..13 are CR/LF
It's all ASCII characters, so no "funny" stuff.
The above comes from table 3-4 on page 3-25 of the operating and service manual.
It's up to you to process that string to test for validity, and extract the value.
It is highly recommended to get a copy of at operator/service manual.? (I only have a dead tree version.)
Hope this helps.
Dave B (G0WBX)
-- Created on and sent from a Unix like PC running and using free and open source software. ::
|