🚀 go-pugleaf

budgie <budgie@nowhere.cantech.net.au> wrote:

>This request is for info to assist in the above.  I'm not after
>general "how-to" stuff, rather I'd like to get some clues from someone
>who has "been there".

>I have a HP34970A on loan, c/w all manuals.  Normally I'm quite
>capable of writing Basic code for RS232 comms for pretty much
>anything, but this one has me stumped.  I've read the user manual for
>far too long - all aussie support have gone for the weekend :-(

>All the commands to the instrument seem to be accepted OK, but all
>attempts to actually receive any data from it are met with a "hang" on
>the input statement.  DOS platform, QBasic and/or QB4.5 in use ('cos
>VB-DOS and serial comms don't get along).

>Anyone been there?  All help appreciated.

Peter,

Post/email a bit of your code, specifically the open comms stmt and
the input for comms.

Are you using the LOC (n) function to see if there is anything at the
port?  If yes send that code as well.

You may not have the right open options set and then your device
doesn't set the correct control lines to be compatible with Basic's
port settings - RTS, CTS, DTR, DSR, CD, etc. - that kind of stuff.

How many wires do you have connected end to end - 3? 5? 7? What?

Do your DB9/DB25 plugs have anything shorted to loop back?

Are the port parameters set right in the HP device?

Do you have one of those blinkie-lights thingees that you can use to
verify that the HP device is actually wanting to send data?

Can you verify that your cable does not have an open/shorted solder
connection somewhere in one or more of the pins on one of the
connectors?  (Meter?)

Have you been a bad boy or forgotten to say your prayers or something?

If you are sending an email, send the whole effing program because
it's probly fairly short - I can just fix it for you if there's
something wrong.

 - Tom

On Fri, 08 Feb 2002 14:20:01 GMT, DeductThisPart.gpsnav@pacific.net.sg
(Tom Werry) wrote:

>budgie <budgie@nowhere.cantech.net.au> wrote:
>
>>This request is for info to assist in the above.  I'm not after
>>general "how-to" stuff, rather I'd like to get some clues from someone
>>who has "been there".
>
>>I have a HP34970A on loan, c/w all manuals.  Normally I'm quite
>>capable of writing Basic code for RS232 comms for pretty much
>>anything, but this one has me stumped.  I've read the user manual for
>>far too long - all aussie support have gone for the weekend :-(
>
>>All the commands to the instrument seem to be accepted OK, but all
>>attempts to actually receive any data from it are met with a "hang" on
>>the input statement.  DOS platform, QBasic and/or QB4.5 in use ('cos
>>VB-DOS and serial comms don't get along).
>
>>Anyone been there?  All help appreciated.
>
>Peter,
>
>Post/email a bit of your code, specifically the open comms stmt and
>the input for comms.


Will do - it's on another box elsewhere.  Probably in about 20 hours
from now I can post some of it ...

>Are you using the LOC (n) function to see if there is anything at the
>port?  If yes send that code as well.

Not at this stage.  I have just got an INPUT# sitting waiting.  Once
the HP actually sends some strings I will look further at how I will
best absorb them into QB(asic).

>You may not have the right open options set and then your device
>doesn't set the correct control lines to be compatible with Basic's
>port settings - RTS, CTS, DTR, DSR, CD, etc. - that kind of stuff.

Tried RTS/CTS intially at both ends - no difference to now, when i
have moved to XON/XOFF (HP's preferred mode).

>How many wires do you have connected end to end - 3? 5? 7? What?

It's the supplied HP lead.  The HP is a DTE (also), so it is a null
modem config with (IIRC) all leads employed.

>Do your DB9/DB25 plugs have anything shorted to loop back?

No, all end-to-end with crossovers.  When I next grab the book I can
give you the pinouts, but I can't see that being the problem.  No
breaks - checked that first.

>Are the port parameters set right in the HP device?

Yes.  9600-8N1 both ends.

>Do you have one of those blinkie-lights thingees that you can use to
>verify that the HP device is actually wanting to send data?

Yes, and it isn't sending a cracker.  That's the problem - all the
SCPI commands I saw  resulted in data in the HP output port, but I
couldn't find an SCPI command to force it to actually Tx any data ..

>Can you verify that your cable does not have an open/shorted solder
>connection somewhere in one or more of the pins on one of the
>connectors?  (Meter?)

Done.

>Have you been a bad boy or forgotten to say your prayers or something?
>

Ahah!!  That could be it ;-)

>If you are sending an email, send the whole effing program because
>it's probly fairly short - I can just fix it for you if there's
>something wrong.

You speak SCPI?


Tnx Tom

Peter

Peter,

>Will do - it's on another box elsewhere.  Probably in about 20 hours from 
>now I can post some of it ...

Okay - are you east or west - Sydlley I think is 5 hrs ahead of
Singgers, Perve is about the same as me?

>Yes, and it isn't sending a cracker.  That's the problem - all the SCPI 
>commands I saw  resulted in data in the HP output port, but I couldn't find 
>an SCPI command to force it to actually Tx any data ..

Sounds like all the obvious stuff is okay - are you saying that the
(HP?) it is not sending and not that the (PC?) it is not sending?  And
that therefore your PC stuff may all be okay?

>You speak SCPI?

Unfortunately I don't know what on earth SCPI is - I can just get the
PC side sorted out for you once you get the HP to send data.

I apologize if I shouldn't have answered this, not knowing SCPI, but
if it is any kind of a PC/QB serial problem, I have probably done more
work with that than anyonbe else on the planet when it comes to
connecting to all kinds of other serial devices like data loggers,
sensors etc.

Is it possible that HP is waiting for a control line to go on from the
PC side, or for the PC to send an initial XON or something dopey like
that, before transmitting any data?

To verify that QB is not doing something stupid for you, can you
(easily?) try hooking the HP up to a terminal program like the old
CROSSTALK or similar, or possibly Windows hyperterminal without
getting too bogged down in that as a separate exercise?  This used to
be an easy way for me to sort stuff out on occasion.

 - Tom

On Sat, 09 Feb 2002 05:56:34 GMT, DeductThisPart.gpsnav@pacific.net.sg
(Tom Werry) wrote:

>
>Peter,
>
>>Will do - it's on another box elsewhere.  Probably in about 20 hours from 
>>now I can post some of it ...
>
>Okay - are you east or west - Sydlley I think is 5 hrs ahead of
>Singgers, Perve is about the same as me?


Perth - GMT+8.  Siddley is 2 (3 when they go silly) ahead of me.

>>Yes, and it isn't sending a cracker.  That's the problem - all the SCPI 
>>commands I saw  resulted in data in the HP output port, but I couldn't find 
>>an SCPI command to force it to actually Tx any data ..
>
>Sounds like all the obvious stuff is okay - are you saying that the
>(HP?) it is not sending and not that the (PC?) it is not sending?  And
>that therefore your PC stuff may all be okay?

The commands I am sending are basically (no pun intended) out of the
VBA/XL7 example in the userman.  They are just string commands.
Unfortunately the only examples they give are the VBA/XL7 and C - and
I don't speak C :-((

The first command sent/received causes the HP to go into remote mode -
which is part of the correct response.  I sincerely believe the PC end
to be sound.

Since I posted previously, I found a QB example in the HP34901 manual.
(The 34970 is really a 34901 DMM with a three-mux-card extension).
Tried that with no greater success.  In fact, it gives an "invalid
separator/delimiter" error after a certain number of commands are sent
- almost like it is concatenating them and getting an overflow.

>>You speak SCPI?
>
>Unfortunately I don't know what on earth SCPI is - I can just get the
>PC side sorted out for you once you get the HP to send data.

SCPI is Standard Commands for Programmable Instruments - sort of an
industry standard which HP stick to albeit not religiously.

>I apologize if I shouldn't have answered this, not knowing SCPI, but
>if it is any kind of a PC/QB serial problem, I have probably done more
>work with that than anyonbe else on the planet when it comes to
>connecting to all kinds of other serial devices like data loggers,
>sensors etc.

No apology needed.  I welcome your input.  I also have a long history
in sorting (usually other people's) RS232 interfacing problems on all
sorts of gear - including building custom interfaces when required.
Some bizarre things such as a bidi C64 to a LA35 DECwriter which had
only a current loop interface.

>Is it possible that HP is waiting for a control line to go on from the
>PC side, or for the PC to send an initial XON or something dopey like
>that, before transmitting any data?

Assuming it IS actually receiving the commands and interpreting them
correctly, it MUST be waiting for SOMETHING ...

I started using XON/XOFF (which is the HP factory default) and sent
one after a couple of setup commands, but didn't seem to make any
difference.  I then tried RTS/CTS and finally set up the HP to "no
handshake".  All to no avail.

I am still suspecting that it has data in its o/b but isn't sending.
Handshake lines are all connected.  The 9M/9M cable is:

1 (DCD) straight
2/3 crossed (TxD/RxD)
4/6 crossed (DTR/DSR)
5 Gnd - straight
7/8 crossed (RTS/CTS)
9 straight (RI).

This is the standard HP cable supplied for the instrument for DTE-DTE
use.

>To verify that QB is not doing something stupid for you, can you
>(easily?) try hooking the HP up to a terminal program like the old
>CROSSTALK or similar, or possibly Windows hyperterminal without
>getting too bogged down in that as a separate exercise?  This used to
>be an easy way for me to sort stuff out on occasion.

Can't do the Windoze thing on this box.  Could drag another box down
there I suppose.  But I know exactly what QB is sending.  I can see
the LEDs on the breakout box for all lines of interest.  Data goes but
no flicker on the HP TxD line.  It simply aint talking.  When it does
send a string I can certainly interpret/dismember it.

I see these possibilities:
(a) the HP is ignoring me, or at least ignoring enough commands to
frustrate bidi communication.
(b) I'm not sending the "magical" command/handshake/? to get it to
send data.
(c) the HP is broken

.Peter

UPDATE:

It turns out that to get the HP instrument to actually interpret and
act on commands, the OPEN COM has to include the LF parameter.

My suspicion that it was ignoring me was well founded.

Several other quirky bits came out in the wash.  All I can say is that
I am glad I don't have to deal with HP-Basic!!!!!!

In the final form, I am using LINE INPUT# and stripping all the
leading <LF>'s to get the raw data.

Thanks for all the suggestions.

Peter

budgie <budgie@nowhere.cantech.net.au> wrote:

>UPDATE:

>It turns out that to get the HP instrument to actually interpret and
>act on commands, the OPEN COM has to include the LF parameter.

Peter,

What?  You mean you weren't adding a CRLF pair of bytes to the end of
each command you sent?  I'll have to add this to my list of silly
things not to omit which I went thru with you before, hahaha - if I'd
thot of it before it would have been there in my list, but I just do
this so automatically for any controlled device that I forgot it.

I find it never screws things up if you put it in and it is not
needed.  My output statements ALWAYS have CRLF added explicitly and
end with a semi-colon - then there's no doubt about what's going down
the wire.  You also have to be careful, some dipshit devices actually
want to see these 2 chars. the other way round!!!???

Just a note about another way I sometimes use to sort out the
undocumented or misdocumented stuff sometimes:

If there is a sample controller program that comes with a unit that
you can run on a PC, and it starts the unit okay but you cannot do the
same with your own code which you wrote to improve upon the
controller, then you use a "piggy-in-the-middle" program and another
PC with 2 serial ports to scope out what their program is doing.

(If you check their web site you might find such a test program from
HP if there wasn't one in the box).

You wire this second PC in between the PC running the supplied sotware
and the device with a second cable that duplicates the one supplied.

This PITM program transfers every byte in one port out the other, for
both ports.  On the way by, it records all bytes going both ways in a
file or two, depending on how you feel about interspersed bytes on
bi-directional comms.  You might want to wait for a CRLF on each port
before recording the accumulated line for that machine.

If you also wosh to display the bytes/msgs on screen on the way by,
you must filter the control codes that will beep & scroll the scree -
or just ignore these as it is running, depending on how much screwing
around you want to do as opposed to just solving thew immediate
problem.

I've sorted out a few troublesome situations with the
"piggy-in-the-middle" and gotten a few raised eyebrows from smartass
manufacturers reps. in the process.

 - Tom

On Sun, 10 Feb 2002 07:49:59 GMT, DeductThisPart.gpsnav@pacific.net.sg
(Tom Werry) wrote:

>budgie <budgie@nowhere.cantech.net.au> wrote:
>
>>UPDATE:
>
>>It turns out that to get the HP instrument to actually interpret and
>>act on commands, the OPEN COM has to include the LF parameter.
>
>Peter,
>
>What?  You mean you weren't adding a CRLF pair of bytes to the end of
>each command you sent?

I wasn't explicitly adding one in the sense of the LF parameter in the
OPEN, but wasn't terminating string PRINTs with a semi either.

> I'll have to add this to my list of silly
>things not to omit which I went thru with you before, hahaha - if I'd
>thot of it before it would have been there in my list, but I just do
>this so automatically for any controlled device that I forgot it.

I had tried just about every other combination, and I figured this was
unlikely but worth a try.  Suddenly "bingo" and of course the rest
fell into place.

>I find it never screws things up if you put it in and it is not
>needed.  My output statements ALWAYS have CRLF added explicitly and
>end with a semi-colon - then there's no doubt about what's going down
>the wire.  You also have to be careful, some dipshit devices actually
>want to see these 2 chars. the other way round!!!???

I've seen them.  See the LINE INPUT statement for the other half of
the same problem - takes the <CR> out of the buffer and leaves the
<LF> so it needs to be stripped from the next string pulled ...

>Just a note about another way I sometimes use to sort out the
>undocumented or misdocumented stuff sometimes:

(snip)

>(If you check their web site you might find such a test program from
>HP if there wasn't one in the box).

Nope.  Tried that avenue.  As I mentioned, the only code was two
samples - VBA/XL7 and C.  Neither gave any clue to what the stumbling
block turned out to be.  I left a message with the local Agilent man
late Friday.  Even though he has lent me the instrument for 2-3 weeks,
I think I'll give him a serve regarding how unhelpful the UserMan was
in this case.  Don't all these problems flare up late on a Friday :-(

I have a couple of "PITM"-type programs but in this case they wouldn't
have been able to provide any more info than the breakout box.

Once again, thanks for your input and interest.  That's what makes
usenet one damned big help desk ;-)

As a small aside, if you are in Singers can you tell me who are the
Maxim distributors up that way?  We have only Arrow and they are about
as useless as an ashtray on a motorbike.  I've located one in NZ who
is better, but i figure the volume thru Singers would have to be ten
times the NZ throughput.

Peter

budgie <budgie@nowhere.cantech.net.au> wrote:
>As a small aside, if you are in Singers can you tell me who are the
>Maxim distributors up that way?  We have only Arrow and they are about
>as useless as an ashtray on a motorbike.  I've located one in NZ who
>is better, but i figure the volume thru Singers would have to be ten
>times the NZ throughput.

We got a big RS depot here that'll quickly get you just about
anything, but at 10 times the price.  For one off's, it's okay.

If it's easy tomorrow I'll look around, but it's chinese new year here
- everything's on hold for a week.  I play ice hockey with a european
tech guy for RS - I'll ask him thursday night when we next play if
he's not out of town for the holiday.

Gong Xi Fa Cai!  (or Kong Hee Fatt Choi if you're cantonese!)

On Tue, 12 Feb 2002 07:43:51 GMT, DeductThisPart.gpsnav@pacific.net.sg
(Tom Werry) wrote:

>budgie <budgie@nowhere.cantech.net.au> wrote:
>>As a small aside, if you are in Singers can you tell me who are the
>>Maxim distributors up that way?  We have only Arrow and they are about
>>as useless as an ashtray on a motorbike.  I've located one in NZ who
>>is better, but i figure the volume thru Singers would have to be ten
>>times the NZ throughput.
>
>We got a big RS depot here that'll quickly get you just about
>anything, but at 10 times the price.  For one off's, it's okay.

Yes, we have RS here too - with all the same features ;-)

>If it's easy tomorrow I'll look around, but it's chinese new year here
>- everything's on hold for a week.  I play ice hockey with a european
>tech guy for RS - I'll ask him thursday night when we next play if
>he's not out of town for the holiday.

No problems.  But a direct Maxim distributor would be a better
prospect than RS.

Tnx for your assistance.

budgie <budgie@nowhere.cantech.net.au> wrote:
>>>UPDATE:
>>
>>>It turns out that to get the HP instrument to actually interpret and
>>>act on commands, the OPEN COM has to include the LF parameter.

Peter,

Want a laff: read the last para. of this from the gps group.

=====================
"Savio Landonio" <savio.landonio@unimi.it> writes:
>Does anyone know a software to configure this smart antenna ?
>In the manuals, Garmin wrote about a SNSRCFG or GPSCFG.
>Please if you have some usefull software send it to me.

Have you tried asking Garmin for the software they recommend?

I haven't used the GPS 17, but I have worked with a GPS 20 and 25LP.
Both of them were easy to configure using nothing more than a terminal
emulator on a computer.  The manuals document all of the commands that
you can send to the GPS receiver.  With a cable connected to a serial
port on the computer (which you'll need anyway to use the unit's
output),
fire up a terminal emulator.  You should see the NMEA data stream
coming
from the unit if you get the serial parameters set right.

Then, just type the necessary commands.  Or store them in a file
first,
and use the terminal emulator to send them to the GPSR.

The one thing that's easily missed is that Garmin units want commands
to be terminated by *both* carriage return and line feed.  Hitting
RETURN
in the terminal emulator will probably only send CR.  You need to type
CNTL-J as well to send the LF.

	Dave
======================

On Wed, 13 Feb 2002 09:28:22 GMT, DeductThisPart.gpsnav@pacific.net.sg
(Tom Werry) wrote:

>budgie <budgie@nowhere.cantech.net.au> wrote:
>>>>UPDATE:
>>>
>>>>It turns out that to get the HP instrument to actually interpret and
>>>>act on commands, the OPEN COM has to include the LF parameter.
>
>Peter,
>
>Want a laff: read the last para. of this from the gps group.
(snip)

You having a cheap shot at me?   ;-)

budgie <budgie@nowhere.cantech.net.au> wrote:
>You having a cheap shot at me?   ;-)

Not at all, ya touchy SOB - just thought you'd get a laff outta the
coincidence with me - hahahahaha.

Hey - are you the guy was up here doing some work on ROV's for Stolt
last year?  Name seems vaguely familiar.

On Wed, 13 Feb 2002 14:14:13 GMT, DeductThisPart.gpsnav@pacific.net.sg
(Tom Werry) wrote:

>budgie <budgie@nowhere.cantech.net.au> wrote:
>>You having a cheap shot at me?   ;-)
>
>Not at all, ya touchy SOB - just thought you'd get a laff outta the
>coincidence with me - hahahahaha.

;-)

>Hey - are you the guy was up here doing some work on ROV's for Stolt
>last year?  Name seems vaguely familiar.

Nope, haven't been up there for a couple of years, and never worked
there - only hols/tourist..